Archive by Author

Abstracción sintactica

le coq

Le Coq - Joan Miro

Recordemos algunas nociones básicas.

La misión del desarrollador de software consiste en escribir programas que sean faciles de entender. Un programa es facil de entender cuando esta escrito como un conjunto sencillo de relaciones entre conceptos. Como estos conceptos pueden ser a su vez complejos, el programador retiene de ellos unicamente la información necesaria para entender sus relaciones con los demás conceptos. Cada concepto del programa principal es representado por otro pedazo del programa, escrito de manera similar. Este mecanismo de reducción del nivel de detalle de una parte del programa se conoce como abstracción.

Si en un programa existen pedazos de código muy similares, el programador debe preguntarse si no existe un concepto implicito que merezca ser representado por una abstracción.

Los dos tipos de abstracción mas conocidos son tal vez el procedimiento, que captura una serie de acciones, y los tipos de datos, que representan la entidades sobre las cuales un programa actua. Los diferentes tipos de abstracción permiten reducir la complejidad de los programas de diferentes maneras. Cada lenguaje de programación ofrece sus propios mecanismos de abstracción según el estilo de programación que promueven, por ejemplo funcional u orientado a objetos.

Railway Crossing

Railway Crossing - Leger

La abstracción sintactica permite regrupar formas sintacticas similares. Para explicar a que me refiero con “formas sintacticas similares” daré un ejemplo. En el lenguaje java, en las versiones anteriores a 1.5, la manera mas familiar de iterar sobre un arreglo era escribir algo asi:


int[] arreglo = {1,2,3};

for (int i = 0; i < arreglo.length ; i++){
int var = arreglo[i];
doSomethingWith(var);
}

Al escribir código como este muchas veces, es obvio que hay algo que puede generalizarse. Java 1.5 ofrece la siguiente forma de escribir esto mismo:

int[] arreglo = {1,2,3};

for (int var : arreglo){
doSomethingWith(var);
}

La ganancia en legibilidad es enorme cuando se tiene en cuenta el enorme número de iteraciones sobre un arreglo que pueden aparecer en un programa. Como java no ofrece soporte a la abstracción funcional, los programadores de java tuvimos que esperar hasta que los encargados de el lenguaje ofrecieran esta nueva forma de iterar sobre un arreglo, sin poder hacer nada al respecto. En un lenguaje como lisp que permite la abstracción sintactica el programador podría haber creado su propia versión de “for”, de considerarlo necesario. En lisp esto se hace gracias a un poderoso sistema de macros.

Veamos otro ejemplo, basado en common lisp pero explicado en pseudo código. Si imaginamos una librería que permita escribir lineas de texto a un archivo, su uso en un lenguaje tradicional se parecerá a esto:


variable stream = open("archivo");
try {
print(stream, "hello");
print(stream, "world");
}
finally {
close(stream);
}

Luego de escribir código parecido al anterior muchas veces, podemos imaginar lo conveniente que sería reducir lo anterior a una forma mas pura, algo parecido a esto:


with-open-file (stream "archivo") {
stream.print("hello world");
}

que “esconda” los detalles de captura de excepciones y de cerrar el stream al final de su uso.

En lisp existe un macro que hace exactamente eso. Pero el punto aquí no es que lisp soporte esta sintaxis sino que, de no existir, el programador podria introducirla sin ningun problema.

Programación interactiva

Una de las cosas que mas me gustan de programar en Lisp es que encuentro facil mantener la concentración cuando lo hago. Creo que esto se debe en buena parte a la programación interactiva que facilitan los ambientes de desarrollo en lisp. La programación interactiva consiste en ir modificando un programa poco a poco mientras éste se encuentra activo. Es decir, el termino de programación interactiva no tiene que ver con el estilo en el queesta escrito un programa sino con el proceso de escritura del código. Veamos esto un poco mas en detalle.

Teclado symbolics

En ambientes no interactivos los programadores trabajan intercalando dos tipos de actividades bien separadas: la edición y la ejecución. La programación es entonces una secuencia de sesiones de edición de código y de sesiones de ejecución (y a veces también de fases de compilación). Al terminar una sesión de edición, se lanza el programa y se observan los efectos sobre el comportamiento del programa. Una vez se ha observado el programa en ejecución, se interrumpe el programa para empezar una nueva sesión de edición. Cada actividad esta claramente delimitada e implica un tipo de gestos distinto. El cambio entre una actividad y otra implica un cambio de contexto mental que se convierte en un esfuerzo adicional. El programador tiende entonces a programar en sesiones de edición largas para evitar el tener que cambiar frecuentemente de actividad.

En ambientes interactivos, el programa todo el tiempo esta en ejecución y el programador modifica su comportamiento haciendo un pequeño cambio a la vez. El programador trabaja en micro-sesiones de edición tras las cuales observa inmediatamente el resultado de la edición. La sensación del programador es que las dos actividades, modificar el programa y observar el resultado de las modificaciones, se funden en una sola actividad.

Los programadores de common lisp suelen usar el editor de texto Emacs junto a Slime, una adaptación que permite programar interactivamente. Una sesión de trabajo consiste habitualmente en:

  1. Cargar el sistema en el que se va a trabajar, a partir del editor;
  2. Escribir nuevas funciones o modificar las existentes y hacer que el sistema en ejecución use estas nuevas definiciones tan pronto se van escribiendo;
  3. Probar constantemente estas nuevas funciones ejecutando fragmentos de código, que luego pueden deshecharse.

Como se puede ver, el programador “lanza” el sistema al inicio de una sesión de trabajo y no lo detiene sino cuando termina de trabajar.

En java se puede lograr un cierto nivel de interactividad usando un buen ambiente de desarrollo integrado, por ejemplo Eclipse, en el que un programa puede facilmente ejecutarse en modo “debug” y modificar las clases “en caliente” sin tener que detener la ejecución. Aún así, en java muchas veces es necesario detener la ejecución del programa, por ejemplo cuando se cambia el nombre de un método.

Turbo C

Aparte del ambiente de desarrollo, el lenguaje en si mismo influye en que tan interactivamente se pueda programar. Por ejemplo, muchas veces en java, para poder usar una cierta librería, es necesario crear sub-clases. Crear una clase implica una sesión de tecleo relativamente larga, que destruye la fluidez de la programación interactiva.

Uno de los ambientes menos interactivos en los que he trabajado lo sufrí desarrollando una cierta aplicación en java que solo podia ejecutarse en un servidor de aplicaciones instalado en otra máquina. Cada vez que modificaba el código y queria probar mis cambios, debia detener la aplicación, subir el programa usando una interfaz web y relanzarlo. Para una persona como yo, a la que le cuesta concentrarse, mantener la cabeza en lo que estaba haciendo era una odisea en esas condiciones.

Creo que la academia debería interesarse al tema del placer en la programación. Por que puede ser mas placentero programar de una cierta manera que otra y cómo se refleja el placer del programador sobre el resultado final.

Sobre la importancia de saber programar en C

Hace cerca de 15 años, en la Universidad de los Andes, la programación se enseñaba usando “C“, un lenguaje de programación muy popular desarrollado en los 70, en paralelo con el desarrollo del sistema operativo UNIX.  En los 90, lenguajes de programación como Java fueron reemplazando al lenguaje C tanto en la empresa como en las aulas. Hoy en día, según me dicen, la programación se enseña usando Java y los estudiantes simplemente no aprenden C.

Este cambio preocupa a ciertos de mis colegas quienes consideran que, aún si no se va a usar este lenguaje, un programador debería saber programar en C. Muchos de estos colegas se quejan de los programadores más jovenes acusandolos de “no saber que es un apuntador”, lo cual parece ser, por el tono de la queja, algo muy grave. Qué tan realmente es importante saber programar en C para un programador? Cual es el realmente el fondo del asunto.

Yo supongo que lo que deploran mis colegas es el hecho de que al no haber tenido contacto con un lenguaje con manejo explicito de la memoria, aritmetica de apuntadores, acceso directo a ciertas funciones del sistema, etc, los programadores de hoy en dia sean menos concientes de qué es lo que ocurre con los recursos de la maquina cuando un programa es ejecutado. El verdadero debate es entonces sobre que tanto necesita conocer un programador sobre la manera como sus programas actuaran en terminos de los mecanismos de base de un computador. Personalmente creo que es importante. Por esta misma razon, creo que es importante tener idea de como está implementado un compilador.

Por otra parte, recordemos a Edsger Dijkstra, quién dijo: “computer Science is no more about computers than astronomy is about telescopes”.

Buen diseño

Dieter Rams es una de las personas que mas han influido en la práctica del diseño industrial. Muchos de los productos que Rams ha diseñado durante su trabajo en la empresa Braun son admirados mundialmente. Rams ha resumido su pensamiento sobre el diseño en los siguientes principios:

  • Un buen diseño es innovador
  • Un buen diseño hace un producto util
  • Un buen diseño es estético
  • Un buen diseño no obstruye
  • Un buen diseño ayuda a entender un producto
  • Un buen diseño es honesto
  • Un buen diseño no envejece
  • Un buen diseño es coherente hasta en el mas mínimo detalle
  • Un buen diseño tiene en cuenta el medio ambiente
  • Un buen diseño es tan poco diseño como sea posible

Uribe se entera de que la corte no aprobó el referendo

La gravedad de los últimos sucesos nacionales me obligan a interrumpir la programación habitual de este blog para revelar una grabación robada de lo que parece ser el presidente de la república enterandose de que la corte constitucional no aprobó el referendo reeleccionista.

Sigan en sintonía

Diferentes trabajos en programación

Como programador he pasado por solo tres trabajos diferentes. El primero como freelance (es decir, como programador independiente) en Colombia, labor bastante desagradecida excepto por la experiencia que permite adquirir. Creo que en Colombia hay mucha gente trabajando de esa manera no tanto por gusto como por la dificultad de encontrar un empleo estable. Puede que para una persona ya reconocida en el medio puede ser atractivo vivir haciendo freelancing por la libertad que permite.

El segundo trabajo fue en una gran compañia europea, trabajando como desarrollador en distintos sistemas de infraestructura de desarrollo CAD. Dede el punto de vista de la estabilidad laboral y de diferentes ventajas como empleado era una situación bastante buena, incluso envidiable. Desde el punto de vista técnico fue muy interesante el trabajo de entender un gran ecosistema tecnologico con todas sus idiosincracias y el poder disponer de grandes recursos, así como el tener que interactuar con diferentes grupos en diferentes partes del mundo. El punto negativo era tener que lidiar con toda la inercia de una gran organización donde cualquier cambio es visto con recelo y donde las decisiones técnicas están fuertemente influenciadas por los distintos conflictos de poder al interior de la empresa. Una cosa dificil de trabajar en una gran organización es el poder sentirse conectado con lo que la empresa produce ya que finalmente uno solo participa en una pequeña parte del resultado final.

Mi trabajo actual es en una empresa de desarrollo donde lo que creamos es algo mas “pequeño” por lo cual mi participación tiene una influencia relativa mucho mas grande. Esto me parece que facilita mucho sentirse unido al grupo y encontrar satisfacción en lo que se está haciendo.

Sobre la metida de pata de Buzz

Google metió la pata en su lanzamiento de Buzz (una especie de servicio de mensajeria estilo twitter): los contactos mas “cercanos” de un usuario quedaban visibles para todos justo después de activar la cuenta y hasta no cambiar las preferencias para evitarlo. Esta información hace parte de lo que mucha gente considera como información personal y es dificil entender como en Google pudieron decidir que era una buena idea exponerla de esa manera. Siendo malicioso uno podría pensar que es un cálculo acertado de la parte de Google, a la mayoría de la gente esto le parece un detalle sin importancia y en cambio la conveniencia de tener una “red social” estilo facebook/twitter armada sin ningún esfuerzo hace el servicio atractivo inmediatamente. Digo “siendo malicioso”, pero en realidad ese sería el juicio que todo el mundo haría de tratarse de Microsoft y no de Google. Desconfiemos.

Dos herramientas recomendadas

Hay dos herramientas que uso desde un buen tiempo para organizar mis cosas. La primera es simplemente un wiki, usado como una libreta de notas. No deja de ser curioso escribir documentos de uso personal usando una herramienta concebida para escribir documentos abiertos de manera colaborativa. Funciona muy bien, es como usar una libreta de notas con la ventaja de poder re-escribir cualquier parte. El software que uso es dokuwiki.

La segunda herramienta es un programa para administrar listas de cosas por hacer (to-do lists). Inicialmente intenté usar un plugin para dokuwiki que sirve para editar to-do lists pero me parece que la interfaz de edicion de texto de un wiki no es optima para llevar to-do lists. Ahora estoy usando mytinytodo que siendo bastante minimalista es perfecto para mis necesidades.

Menos es más

Manuel Cerón opina en mi post anterior que la calidad de las interfaces de usuario de las aplicaciones en la web no es aceptable. Para Manuel, estas interfaces no son ni siquiera comparable a las que tenían las aplicaciones de Windows 95. Siguiendo esta idea, lo ideal sería tener interfaces avanzadas unidas a las ventajas de la web (ubicuidad, propagación automática de mejoras, etc). La popularidad de las aplicaciones web hoy en día se explicaría no gracias a su ergonomía sino a pesar de carecer de ella.

Esta es mas o menos la misma idea que motivó la creación de los applets de java hace ya cerca de 15 años y que está detrás de productos como silverlilght o flash. El objetivo mas o menos explícito de estas tecnologįas es reemplazar a la web como plataforma de aplicaciones por algo igual de conveniente pero con mejores interfaces de usuario.

Creo que calificar las interfaces de usuario en la web de pobres es algo simplista. La razón es que para una gran categoría de aplicaciones, tal vez la mayoría, las interfaces web no son solo suficientes sino óptimas. Esto puede parecer raro, así que intentaré explicar por qué lo creo así.

Las aplicaciones web estan restringidas a un pequeño numero de elementos de interacción con el usuario y a su comportamiento estándar. Basicamente, texto, imágenes, enlaces, campos de texto, menus y botones. Por otro lado, las tecnologías generales de creación de interfaces de usuario permiten crear virtualmente cualquier tipo de componente visual y  de interacción imaginable y frecuentemente incluyen un gran numero de componentes predefinidos mas o menos sofisticados.

En teoría si una tecnología “puede lo más” también “puede lo menos” y deberia preferirse. La realidad es mas complicada. Las interfaces HTML no solo permiten hacer casi todo lo que necesitan la mayor parte de aplicaciones gráficas sino que además su sencillez tiene beneficios secundarios como el que:

  • La curva de aprendizaje para usarlas sea muy baja.  No se requiere entender muchos conceptos.
  • Las aplicaciones sean mas robustas.

Por supuesto, hay categorias de aplicaciones  para las cuales HTML no es suficiente. Creo que esta categoría de aplicaciones se restringe principalmente a las aplicaciones cuya función principal es interpretar pequeños gestos del usuario como operaciones de edición. Me refiero a programas como editores de texto o  programas de edicion gráfica. Los juegos son otra categoría que también escapa al rango que cubre HTML, pero los juegos son una categoria de software especial en muchos otros aspectos.

Muchas de las limitaciones de la web como plataforma de aplicaciones están desapareciendo a medida que la velocidad de las implementaciones javascript mejora y que el soporte a nuevas maneras de enriquecer las interfaces web se hacen comunes entre los navegadores. Sin embargo creo que la continuidad del exito de la web como plataforma de desarrollo de aplicaciones ni siquiera depende de esas mejoras. A veces, menos es más.

Por qué no creo que el iPhone, el iTablet y la AppStore sean la plataforma del futuro

Los programas de computadorse se escriben para una plataforma determinada: windows, macintosh, linux, la web, etc. Plataformas como Windows y Mac OS están bajo el control total de sus fabricantes. Esto hace que los desarrolladores de software y los usuarios que deciden usar estas plataformas se ponen a si mismos en una situación de dependencia frente a aquellos que las controlan.

Una de las grandes ventajas de la web como plataforma de software es entonces el hecho de que no hay un único amo que la controle. La web es abierta, las reglas del juego son las mismas para todos. Si Microsoft decidiera cobrar por el uso de Internet Explorer, los usuarios podrían pasarse facilmente a Firefox. Si gnu/linux resulta un ambiente dificil para programar aplicaciones web, los desarrolladores pueden desarrollar en Macintosh o en cualquier otro sistema. Nadie depende de nadie. Todos dependen del respeto a las reglas de base, que son públicas, sencillas y estables. Aunque hay muchas otras ventajas que hacen de la web una plataforma atractiva para desarrollar software, es este aspecto social el que en mi opinión asegurará su ascenso como la principal plataforma de software en el mediano plazo.

Es por esto que la fulgurante popularidad del iPhone y el AppStore son en mi opinión un accidente histórico que no durará mucho. El control de Apple sobre el iPhone es aun mas tiránico que el que Microsoft nunca tuvo sobre Windows: Apple controla no solo cómo funciona la plataforma sino que aplicaciones se pueden escribir para ella, la única tienda en la que se pueden vender y las únicas herramientas con las que se pueden desarrollar. Solo la singular excelencia técnica del iPhone y la enorme distancia con competidores mas abiertos le han dado al iPhone el exito que tiene como plataforma de software. Pero es seguro que los competidores llegaran.

La necesidad de un aparato de ese tamaño, capaz de correr aplicaciones sofisticadas y con una buena calidad gráfica existe, eso es claro. Yo apostaría por el Google Nexus o algun clon basado en aplicaciones web. En su forma actual, el iPhone está condenado a volver al nicho de lujo de donde solo escapan los productos de Apple de vez en cuando.

Powered by WordPress. Designed by Woo Themes