viernes, 27 de febrero de 2009

Tendencia referente a los lenguajes de programación

Todos los años en O'Reilly Radar, publican tendencias relativas a la venta de libros de computación. El los últimos días publicaron una serie de 5 artículos comentando las tendencias del 2008.

En particular, me resultó muy interesante el cuarto artículo de la serie, donde se analizan las ventas de libros por lenguaje de programación.

En este artículo publican dos gráficas que me tomo la libertad de publicar acá.

En la primer gráfica, se muestra que proporción de mercado corresponde a cada lenguaje, así como la variación que tuvo con respecto al 2007.


En la segunda gráfica, se muestra la evolución de los principales lenguajes de programación durante los últimos 5 años.


Algunas cosas que me llamaron la atención:
  • En la primer gráfica se ve que Objective-C creció un 965% con respecto al año anterior. Obviamente este crecimiento no es sostenible, y tiene una explicación muy sencilla... es el lenguaje de programación para desarrollar aplicaciones para el iPhone.
  • También se ve que Ruby tuvo una caida del 51%, lo que parece demostrar que el boom del 2007 fue solo eso...
  • En la segunda gráfica llama la atención como viene creciendo C# y como va perdiendo terreno Java. De hecho por primera vez C# pasó a Java en cuanto a libros vendidos.
  • Lo otro que me llama la atención es que venga cayendo JavaScript, porque con todo el tema de AJAX se debería estar usando bastante.

miércoles, 25 de febrero de 2009

En las noticias GeneXus

En la edición de ayer de las noticias GeneXus publicaron las últimas dos notas de este blog que hablaban sobre la legibilidad del código.


La noticia en el sitio de GXTechnical se puede ver acá.

Actualización (25/2/09 11:59): Me acaban de avisar de un comentario que se ingresó, y me pasaron el link de la nota en portugués. Además veo que está en inglés. Así que ahora puedo decir que los artículos del blog (son dos, por eso en plural) se tradujeron a varios idiomas (también dos, por eso otra vez el plural) :D

jueves, 19 de febrero de 2009

Acceso rápido a aplicaciones y documentos

Una funcionalidad interesante y creo que poco usada que tiene Windows (al menos XP...) es poder agregar una carpeta a la barra de aplicaciones, que se muestra como un menú desde donde se puede acceder a todo el contenido de dicha carpeta (ver imagen más abajo).

El menú de Inicio de Windos a mi me resulta bastante poco usable, por la cantidad de cosas que hay ahí, además de que por defecto solo se muestran los programas y no los documentos.

Entonces, lo que yo hago son dos cosas:

1) tengo todas las aplicaciones que uso frecuentemente en la barra de inicio rápido de Windows. Como son unas cuantas (27 en este momento...), agrandé la barra de tareas para que quede de dos filas de alto, y entonces en una fila tengo los accesos directos y en la otra las aplicaciones que están corriendo.



2) tengo una carpeta con varios accesos directos a otras aplicaciones, scripts SQL, programas batch de DOS, documentos, etc. que agregué a la barra de tareas de Windows, con el resto de las cosas que uso en el día a día.


A mi me resulta muy práctico, a lo mejor a alguien le sirve el tip...

viernes, 13 de febrero de 2009

Mejorando la legibilidad del código II

Muchas veces cuando programamos, mezclamos el código de la función que resuelve un determinado problema con código auxiliar, lo cual entorpece mucho la lectura del código, sobre todo cuando se trata de programas grandes.

Un par de ejemplos...

En GeneXus la función round() recibe el número a redondear y la cantidad de decimales, pero la cantidad de decimales no puede ser una variable, tiene que ser una constante (yo me pregunto, ¿por qué será así?, con GX9u4 al menos es así). Entonces si queremos redondear un valor a una cantidad variable de dígitos decimales, hay que hacerlo "a mano".

El código que usamos habitualmente es como el que sigue:
Do case
case &Digitos = 0
    &vLinImpTot = round( PedPreNet * &PedCntSdo , 0 )
case &Digitos = 1
    &vLinImpTot = round( PedPreNet * &PedCntSdo , 1 )
case &Digitos = 2
    &vLinImpTot = round( PedPreNet * &PedCntSdo , 2 )
Otherwise
    &vLinImpTot = PedPreNet * &PedCntSdo
endcase
El problema con esto, es que estamos escribiendo 10 líneas de código que no hacen al problema, y que distraen la atención, ¡cada vez que queremos asignar un importe!. Si esto aparece una sola vez en el programa, entonces no hay problema, pero cuando en un mismo procedimiento aparece 8 veces, tenemos 80 líneas de código innecesarias, casi 2 página en mi monitor...

Además esto tiene otro problema, que el código no es reutilizable... pero ese es tema para otra nota.

El código de arriba se puede escribir mucho más claro, por ejemplo con:
&vLinImpTot = PedPreNet * &PedCntSdo
&vLinImpTot = udp(PFRedondeaADigitosN132, &vLinImpTot, &Digitos)
Otro ejemplo.

Hay casos en los cuales tenemos un programa que hace algo, y que además genera un listado o una planilla Excel, que no hace al problema que se quiere resolver, pero que es necesario generar.

Siendo más concreto, tengo un programa que genera un asiento contable, que además crea una planilla Excel con la información que usó para generar el asiento. El programa en cuestión tiene unas 1.200 líneas, y la generación del Excel está mezclada con el programa.

Como tenía que cambiar bastante este programa, lo primero que hice fue sacar la generación del Excel a subrutinas, con lo cual en el código del programa, en vez de quedar 50 o 60 líneas con &excelDoc.Cells(...), quedó una sola línea con
do 'Excel: Graba línea'
¿Más claro, no?

Las otras tres subrutinas que cree fueron:
Sub 'Excel: Crea archivo y genera cabezal'
Sub 'Excel: Graba subtotales'
Sub 'Excel: Finaliza'
Como comentario adicional, cada vez me gusta más el uso de las subrutinas... Si se usa un nombre realmente descriptivo como en los casos anteriores, entonces mejora muchísimo la legibilidad del código. Es importante usar un nombre adecuado, por ejemplo en el caso anterior no sirve tener rutinas con nombre Excel1, Excel2 y Excel3.

martes, 10 de febrero de 2009

Mejorando la legibilidad del código

En GeneXus, cuando invocamos un objeto tenemos la posibilidad de hacerlo con un call o con un udp.

Supongamos que tenemos un procedimiento que realiza alguna operación y devuelve un valor. Solo para el ejemplo, supongamos que tenemos un procedimiento Suma que recibe dos valores, &a y &b, y devuelve su suma.

¿Cuál es la diferencia entre invocar dicho procedimiento con call o con udp? Las invocaciones serían así
call(PSuma, &a, &b, &result)
o
&result = udp(PSuma, &a, &b)
¿Cuál de las dos es mejor?

Desde el punto de vista del código generado, son casi idénticos. En realidad no tiene por qué haber diferencia, porque el resultado debe ser exactamente el mismo.

Pero desde el punto de vista de la legibilidad del código, el udp es mucho mejor que el call, porque nos dice cual fue la intensión de la invocación: cargar la variable &result con lo que devuelve el procedimiento.

Citando el blog Coding Horror (que a su vez cita una frase de un libro):
Programs must be written for people to read, and only incidentally for machines to execute.
PD: la palabra legibilidad existe, me quedaban dudas por eso la busqué en el diccionario de la Real Academia Española...