En la imprescindible novela 1984 de George Orwell, el "Gran Hermano", un ícono videográfico, controla el pensar y hacer de las masas con dos estrategias:
Como estoy de papá solo, me ha tocado preparar comida por lo menos dos veces al día todos los días. Para ello he buscado preparaciones que, sin dejar de ser ricas y sanas, sean sencillas y rápidas (el tiempo vuela cuando hay que llegar al colegio antes de las 7:00 AM). Esta es una receta que le encantó a los chamines.
Pienso que el Banco Central de Venezuela (BCV) debería intervenir en el mercado de bonos que genera el valor del dolar "permuta". La razón es que los altos precios del dólar paralelo producen un efecto psicológico que va en contrade las políticas anti-inflacionarias del mismo BCV y del gobierno.
El BCV ya interviene en el mercado a través de la emisión, venta y compra de papeles para controlar la liquidez en bolívares, pagando intereses que resulten atractivos a los inversionistas.
Está dentro de la potestad del BCV participar también en el mercado de papeles denominados en dólares y ejercer política monetaria con ello. Resulta para mi incomprensible el por qué el BCV no lo hace.
El BCV podría, por ejemplo, entrar al mercado comprando y terminar el día de bolsa vendiendo x% por debajo del último precio, día tras otro. Eso llevaría el dólar paralelo a la baja, y las pérdidas, de ser necesarias, serían estimables y justificables.
En una nota anterior expliqué las razones por las cuales es conveniente considerar una reconversión monetaria como la introducción de una nueva moneda, y adaptar los sistemas informáticos para el manejo de múltiples monedas.
¿Cómo se hace eso?
En un sistema que maneja múltiples monedas, un monto aislado carece de significado mientras no se sepa en qué moneda está expresado. Por eso los montos deben pasar de ser solo cifras a pares ordenados:
[monto, moneda]Con eso las capas superiores de una aplicación pueden solicitar valores en una moneda en particular, delegando en librerías especializadas el llevar cuenta de los tipos de cambio, su conversión, su aritmética, y su presentación.
# Venezuela
# Zone NAME GMTOFF RULES FORMAT [UNTIL]
Zone America/Caracas -4:27:44 - LMT 1890
-4:27:40 - CMT 1912 Feb 12 # Caracas Mean Time?
-4:30 - VET 1965 # Venezuela Time
-4:00 - VET 2007 Dec 9 3:00
-4:30 - VET
zdump -v America/Caracas
vo.2 Agregada nota sobre nueva fecha para el cambio de horario.
NOTA: El cambio de huso horario será el 9 de diciembre de 2007 a las 3:00 AM.El anunciado cambio de huso horario en Venezuela tiene una aplicación sencilla en la mayoría de los casos: atrasar el reloj media hora.
Al revisar la literatura producida en torno a la adopción del Euro en la Unión Europea llama la atención la relativa poca importancia que se le da a los retos informáticos en comparación a otros temas como el efecto neto sobre el negocio por los posibles cambios de percepción en clientes y proveedores. Más aún, muchas de las recomendaciones se enfocan no en los problemas sino en las nuevas oportunidades que la introducción de la moneda común podría traer.
Ese enfoque sobre un cambio aparentemente tan grande se debe a que la formación de la Comunidad Económica Europea y luego la Unión fue un proceso gradual añadido a siglos de intercambio comercial a través de las fronteras. La mayoría de las empresas de mediano tamaño en adelante ya manejaban múltiples monedas en sus transacciones y su contabilidad (una empresa inglesa comercializaba productos franceses que se producían con insumos españoles, y se vendían en Alemania; ese tipo de cosas).
Para el empresariado europeo, la introducción del Euro significó desde el punto de vista técnico solo la introducción de una nueva moneda entre tantas otras. Por eso el énfasis sobre las percepciones y las oportunidades.
Hay cosas importante que aprender de la experiencia europea. En Venezuela tendemos a pensar en que la adopción de la nueva moneda, el Bolívar Fuerte (BsF o VEF), significa una (re)conversión, cuando la perspectiva adecuada es tratarla como la introducción de una nueva moneda.
En ese sentido el reto es el de hacer los sistemas informáticos y los procesos capaces de manejar múltiples monedas, con ello abriendo la oportunidad de manejar de forma transparente y simple transacciones en, por ejemplo, dólares de EEUU, pesos colombianos o argentinos, reales brasileros, o, por que no, en la moneda común de un mercado suramericano.
Nadie en su sano juicio propondría que la manera de acometer la introducción del BsF en cuanto informática es hacer un paseo por las bases de datos para ubicar los registros que figuren montos en Bs para dividirlos por mil.
Para comenzar, una estrategia tan ingenua quebraría la consistencia entre los números en las bases de datos con los documentos físicos (facturas, recibos, cheques,....) que se les corresponden, así como aquella con los registros digitales de clientes y proveedores.
Es por eso que el problema de la introducción del BsF debe ser manejado como un reto de adaptación de sistemas y procesos al manejo de múltiples monedas, y jamás como uno de transformación de datos existentes.
Continuará...
El Banco Central de Venezuela (BCV) reportó ayer que la inflación del último mes fue de 0.5%, un aumento cónsono con la meta de inflación para el año.
Sin esperar un instante, ya los profetas chimbos (ellos se dicen economistas) sacaron sus bolas de cristal también chimbas para predecir (como lo han hecho por años sin acertar predicción alguna) que, a pesar de las cifras recientes, estamos encaminados hacia un pronto desastre económico.
Uno de ellos apareció esta mañana en la tele contando que la inflación promedio de los últimos ocho años, los del gobierno actual, ha sido de 19%, y que su bola de cristal decía que la de este año va a cerrar en 21%, como mínimo.
Es cierto que en los últimos ocho años los precios se han multiplicado por cuatro (400%).
Pero lo que no cuentan estos profetas chimbos es que, según el mismo BCV, en los ochos años anteriores, los de los "Chicago Boys", los de los "IESA Boys", los de Teodoro Petkoff en el Ministerio de Coordinación y Planificación (CORDIPLAN), los de ellos mismos estableciendo la política económica nacional... los precios se multiplicaron por veintiseis.
Hubo DOS MIL QUINIENTOS NOVENTA Y SIETE POR CIENTO DE INFLACIÓN en los ocho años durante los cuales nos dejamos guiar por estos "economistas" de "estamos mal pero vamos bien".
¿Hasta cuándo van a seguir dándole tribuna a estos charlatanes?
Es difícil de por sí, y más difícil aún por las actitudes que a veces despierta en otros. Por eso a veces hace falta explicarlo así:
No estoy buscando ser mejor que tú. Lo que pasa es que estoy poniendo todo mi esfuerzo en ser mejor que ese quien fui ayer.
Hace unas semanas compré un computador de escritorio con todos los hierros que el presupuesto predeterminado podía lograr: Pentium D a 3.0 GHz, 1 Gb de RAM, 160 Gb en disco, etc., más un monitor de 19" a 1990x1400.
Una de las razones por las cuales compre desktop es porque estoy harto de las laptops, las cuales se han convertido en artículos desechables al cabo de año y medio de uso; pero eso es tema para otro post.
Mi otra intención (ya que estoy decidido a mantenerme alejado de Windows Vista el mayor tiempo posible) era la de correr Windows XP (todavía necesario) sobre Linux en la nueva compu. Esto es lo que aprendí:
A friend pointed me to a Kodak announcement about new filter-array patterns for digital camera sensors. In short, what they do is to add panchromatic pixels to the filter array patterns.
I don't see a breakthrough because adding specialized pixels (for luminosity in this case) is an obvious evolution when you have increased pixel densities in sensors and lower prices. Previously, in contrast, a lot of thought had to go into designing filter array patterns to capture both luminosity and color resolution with many less pixels.
Today one can have 16 mega pixels in a 35mm sensor, which is the resolution of 35mm film. Each additional mega pixel can be used to capture more and more specific information, and nothing prevents manufacturers from using sensors lager than 35mm.
Para los hermanos Mazzei y Jetty mamá
Hace unos meses hablaba con un amigo quien estaba sufriendo de una de esas enfermedades crónicas que cuando no es una cosa un día, es la otra. Yo le dije que, a pesar de que estaba entero, seguramente las épocas de alto "estrés" en su vida (que fueron intensas) habían cobrado lo suyo, y que dejara de levantarse a las 5:30 de la mañana, y recorrer tanta carretera. Que a sus sesenta y dele se podían tomar las cosas con más calma.
Su respuesta me dio a entender que encerrarse en su casa no era para él descanso sino prisión, y una manera de renunciar a la vida y acercarse a la muerte.
¿Qué es la vida?
John Lennon dijo que "La vida es eso que te pasa mientras estás ocupado haciendo otros planes".
¿Qué es la vida?
¿Es el trajín diario del tráfico caraqueño, las doce horas de trabajo, los chamos al colegio, vuelta a la casa y otra cola, demasiado cansado para conversar mejor veo tele hasta que me aburra y me duerma?
La máxima común a todas las filosofías de vida (incluidas las religiones) parece ser que la vida consiste en "experimentar este día como si fuera el último". ..
Y yo me pregunto: si me aseguraran que sin lugar a dudas mañana va a ser el último, ultimito día ¿Qué haría mañana?
Creo que llamaría a varias personas para decirles cosas que no les he dicho, como que las amo desde siempre y para siempre. Me iría a cortar el pelo donde el Sr. Lino, el italiano, no por el corte, sino por la conversa (hablamos muy poco con los viejos). Me comería una reina pepiada y me tomaría un batido de mango sin azúcar (o tal vez un mondongo con mucho picante y una cervecita). Jugaría una partida de dominó con mis amigos. Haría el amor, mucho. No se.
Si se que antes de hacer todo eso probablemente me levantaría bien temprano en la mañana a correr, a escuchar el despertar de los pájaros, oler el rocío de la mañana, y sentir el amanecer.
Van algunos comentarios en torno al artículo que mi amigo Pedro escribió sobre "peer reviews".
[versión 0.1]
En el mundo del software una revisión por pares no es solo una oportunidad para mejorar la calidad del producto (el "código fuente") a través de la detección temprana de defectos, como errores de programación, o desviaciones de la especificación, de la arquitectura, o de las buenas prácticas.
Es también una importante oportunidad de aprendizaje para los participantes, y en ello una opotrunidad de mejorar el entorno.
Una revisión por pares enfocada solo en encontrar anomalías, o "el qué", pierde la valiosa oportunidad valiosa de analizar también el "cómo" y el "por qué":
2010-03-12 Amendment: After doing the research right, my conclusion is that the tools are available for Python, that Python is an excellent software development platform, and one that allows more productivity than, say, Java.
This article is about programming languages in the context of professional software work. While considering several programming languages with very attractive features for my next project I had to take a pause and think about what the objective choice criteria should be. My conclusion, as argued below is that programming language choice should be dictated by programming pragmatics.
I've been programming for some thirty years now, twenty of them doing it for a living. In my work I've come well acquainted with several programming languages, including Fortran, Basic and Visual Basic, Pascal and Object Pascal, C, C++, Java, and C#. During my university training I had to deliver assignments in Concurrent C, Simula, LISP, and Prolog, among others. I specialized in Computer Languages (compilers) and became a professor of the subject later. I have studied the innards of programming language implementation and have implemented several programming languages from scratch. I've studied every promising programming language I have come upon, including AWK, Perl, Python, CAML, Haskell, Nemerle, Groovy, and Boo, among others.
My experience with compilers in particular has brought me some understanding into what some call "programming language beauty", but that subject is better dealt with elsewhere
. Here I want to talk about what makes a programming language work.
By "makes it work" I mean which features of a programming language let you get the job done in an efficient way. By "in an efficient way" I mean in a way that lets you do better than just survive in the ever more competitive field of software development.
It turns out that what makes a programming language work has less to do with the idiosyncrasies of the language and much more to do with how the language allows and provides for a good software writing environment. The first breakthroughs in programming language, in Fortran, LISP, and Algol68, consisted in raising the level of abstraction so programs could be more about the solution space than the machine. But the first breakthrough I remember, at least in the context of programming languages that work, came with the Integrated Development Environment (IDE), the first comercialization of which was provided by Borland for its Turbo Pascal programming language.
Turbo Pascal came with an IDE that included an interactive, full-screen editor, an incredibly fast compiler, and a debugger. It was the first time that a generally-available tool reduced the edit-compile-run-debug cycle to a matter of seconds. Today, IDEs are common-place, and few professional programmers would think of doing any significant work without the aid of one.
But what do IDEs have to do with specific programming languages? Turbo Pascal was a simple, structured, and well defined language, and that allowed Borland to build a very fast compiler that fitted in the few kilobytes of RAM remaining in the machines of the time after having loaded an editor.
By the end of the 1980's Apple's MacIntosh had made the advantages of Graphical User Interfaces (GUIs) for users obvious, and GUIs became not just desireable but a necessity. The common language of choice at the time was C. Programmers spent hours dealing with single event-handling functions (like WindProc) and trying to manage modal contexts through innumerable heap structures and casts, while loading and exiting the GUI environment to run a command-line compiler. The next breakthrough came again in the IDE. GUI designers had been around for a while, but the linking between UI elements and event-handling code had to be handcrafted. In 1991 Microsoft launched Visual Basic. Visual Basic was built around an IDE that was itself graphical and that, besides edit-compile-run-debug allowed hooking UI elements and events to individual event handlers with a few clicks. Writing GUIs suddenly became easy. The language feature that allowed for it all was Visual Basic's component model, a form of object orientation.
As computers became more powerful, the size and complexity of the programs we attempted to write increased. Programmers spent an important part of their time studying and trying to memorize Application Programming Interfaces (APIs) and third party libraries. The next breakthrough came again in the IDE in the form of context-sensitive help, and later in coding assistance. Instead of having to browse over a huge API reference, the press of a key would make the IDE produce the exact piece of documentation pertinent to the context in the editor, or provide assistance in filling out a method call.
The language features that enabled the new IDE functionality were static-typing and object- orientation. They are the same features that today enable automated refactorings, a functionality that is indispensable while we try to tackle even more complex programs with iterative and agile methods.
So, Which are the features a working programmer should look for in a programming language? They are the ones that enable good tool support for the act of programming: static-typing, and object-orientation. But wait... Shouldn't the tools actually be available? Of course! This means that the primary criteria for choosing a programming language is the availability of the tools that make us efficient at writing the programs we have to write. The breakthroughs in programming of today are still happening in the tooling.
Fans of programming languages without those features or without the tools available say that their language of choice allows them to think better and write less code. That criteria is completely a non-issue for the simple reason that modern programming language are converging to include every characteristic that programming experience has identified as useful: first-order and anonymous functions, closures, list and map literals, partial classes and AOP features, type inference, and duck typing. You name it. None of then offset the pragmatic need for a complete development environment that makes us competitive at what we do.
Posts
All Comments
