lunes, octubre 10, 2011

Dart el nuevo lenguaje Google

Google acaba de lanzar hace unas horas su nuevo lenguaje de programación, pues al parecer no estaban muy satisfechos con javascript, así que se han hecho un lenguaje a la medida de sus necesidades.

El lenguaje tiene tipos graduales y se supone que se podrá evolucionar desde un simple prototipo dinámico hasta aplicaciones complejas y modulares.

Por ahora lo que he visto del lenguaje luce bien, el modelo de procesamiento es similar al de Erlang, pero sin embargo no se dice nada sobre la optimización de llamadas terminales (tail call optimization), y tiene algunas peculiaridades que parecieran ser problemáticas, pero eso es solo una opinión después de un vistazo muy rápido de la especificación, espero que solo sea una impresión inicial y que el lenguaje sea más útil que "go", aunque me parece irreal que vaya a desplazar a javascript en el corto plazo.

Por ahora parece un clon de Java o C# con "gradual typing" y algo de programación funcional.

jueves, marzo 31, 2011

Confesiones de un converso

Cuando ingresé en mi nuevo empleo me tocó hacerme cargo del proyecto de inteligencia de negocios de la organización, en aquel momento pensaba ¿por qué me tenia que tocar a mi la penuria de encargarme de una solución donde lo único que no era Java, eran los productos propietarios de inteligencia de negocios? sobre todo cuando yo no sabía casi nada del tema.

Hoy aprecio que gracias a una plataforma como Java, con su lenguaje simple pero de altísimo nivel, sin el cual, sería inconcebible el desarrollo de aplicaciones de categoría enterprise, excepto por la plataforma .Net, que no se compara en portabilidad.

Aprendí que las aplicaciones por naturaleza son una amalgama de datos "inteligentes", por ello los datos deben llevar con ellos su inteligencia, es decir todas las operaciones que sobre ellos actúan, por lo cual la orientación a objetos es la única manera de modelar las aplicaciones, eso es tan obvio que incluso existen lenguajes universales de modelado basados no solamente en los objetos, sino hechos a la medida de lenguajes empresariales como Java y C#.

Antes solía apreciar la belleza de lenguajes como Perl y Lisp, pero esta claro que sin tipos de datos estrictos como los Java, la programación es solo una actividad informal en la que las personas se divierten probando código, sin realmente estar seguros de que funcionará, es claro que son lenguajes de hackers, y de más esta advertir que esos tíos son peligrosos.

Después de algunas mesas de trabajo para evaluar nuevos ambientes de desarrollo, lenguajes como Haskell y Ocaml afortunadamente fueron descartados, porque son funcionales y las verificaciones de tipos son tan estrictas que es prácticamente imposible lograr que compile el código, a menos que esté prácticamente correcto, lo cual es muy difícil lograr, por ello no pueden competir con el dinamismo de un lenguaje como Java.

En otro orden de ideas no hay forma de que una basecita de datos de software libre como PostgreSQL pueda competir con bases de datos comerciales de calidad enterprise, sobre todo cuando se trata de trabajo serio de negocios con un alto grado de especialización, que en nuestro caso es un Data Wharehouse.

La suite de inteligencia de negocios que estamos utilizando es lo máximo, tal vez una de las mejores cosas que me conseguí cuando llegué, al principio no me dí cuenta, pero después de ver productos como el ETL, que con solo arrastrar, soltar figurillas y unos cuantos clicks extraen, transforman y cargan datos con una mágica facilidad, me han hecho reflexionar sobre la pérdida de tiempo que ha sido utilizar Perl, cuando existen herramientas como esta a solo unos miles de dólares de distancia.

A todos los que me conocen como un apasionado defensor del software libre solo me queda saludarlos y desearles con todo mi corazón que pasen un feliz 1ro de Abril.

lunes, enero 03, 2011

Popularidad versus tecnología

Me conseguí un artículo que confirma algunas de las cosas que siempre digo sobre el desarrollo de software, en particular, insisto en que Java es una gran pérdida de tiempo y dinero para la sociedad, sobre todo cuando desde hace mucho tiempo hay mejores lenguajes y plataformas.

En el artículo se cuenta la historia de éxitos que se lograron utilizando Lisp en el JPL de la NASA, como el reparar una nave espacial que se encontraba a más de 100 millones de millas de la tierra, debido justamente a las características del lenguaje y su plataforma de ejecución.

Hoy en día tal vez suene raro eso de usar Lisp, debido a la percepción (tal vez debería decir el prejuicio) de que es anticuado, o incluso arcaico, sin embargo después de jugar un rato con SBCL uno se puede dar cuenta de lo fácil y dinámico que es el ambiente, es como trabajar con Perl o Python. Lisp resuta ser tan divertido que incluso estoy usando Emacs (sorry Vim, el ambiente SLIME de Emacs es la merma para trabajar con Lisp).

Siendo SBCL un ambiente tan dinámico como Perl o Python, con uno de los mejores y más flexibles sistemas de OOP, que sirvió de inspiración para desarrollar Moose en Perl, extraña que pueda competir con Java en poder de procesamiento, pero consumiendo mucho menos  memoria que este. Además con una semántica bien definida y conocida, producto de: su fundamento matemático, un estándar formal, y una tradición que tiene más de 5 décadas.

Un benchmark demuestra que aún después de casi dos décadas de echarle dinero al pote de Java, todavía ambientes como SBCL (mantenidos únicamente por una comunidad de voluntarios), son más eficientes, y eso no es una casualidad, es una característica de su diseño.

Sin embargo, preferimos un producto corporativo, porque nos vendieron sus grandes innovaciones, tales como: el manejo automático de la memoria y la portabilidad, características que Lisp tiene desde finales de los años 50, unos 30 años antes que Java.

Ahora el daño está hecho, se ha invertido una gran cantidad de tiempo, esfuerzo y dinero en Java, hay que ver que se hace con el monstruo, no puedo estar más de acuerdo con el autor del artículo sobre Lisp en el JPL:
Es muy frustrante ver que todo esto ocurra. Mi trabajo hoy (trabajando en la verificación y validación del software) es resolver problemas que se remontan directamente a la uso de lenguajes puramente imperativos con semántica mal definida como C y C++ (la situación es un poco mejor con Java, pero no mucho). Pero, por supuesto, la solución obvia -- utilizar lenguajes no imperativos con semántica bien definida, como Lisp -- no es una opción. Ni siquiera puedo decir la palabra Lisp sin afianzar mi reputación como un loco que piensa que Lisp es la respuesta a todo. Así que decidí mantener la boca cerrada (la mayor parte del tiempo) y ver con impotencia cómo se gastan millones de dólares de los impuestos.

Por eso es que no escribo demasiado sobre el tema, sin embargo de vez en cuando es bueno revivir la discusión a ver si alguien escucha y se puede corregir el error.

Este es un tiempo interesante, la tecnología funcional se ha reconocido como la única vía para explotar la potencia de las nuevas arquitectura del hardware, por ello Microsoft promueve F#, mientras aparecen lenguajes como Clojure que funcionan sobre la JVM, y es pertinente avisar que hay lenguajes como Haskell, que son mejores que F#, y otros como Lisp y Scheme que son mejores que Cojure.

Para todos los que fans del software corporativo: que dirían si les vendiera el lenguaje BigLisp con las siguientes características:
  • sano
  • seguro
  • con manejo automático de la memoria
  • alto rendimiento
  • bajo consumo de recursos
cuyos programas pueden ejecutarse sin modificación en cualquier plataforma Unix y Windows que tenga un compilador de C, en la máquina virtual de Java, en el ambiente .NET y también en Mono, pero con la capacidad de explotar lo mejor de cada una de estas plataformas y utilizar sus librerías y servicios directamente a cambio de pérdida de la portabilidad.

¿ Me lo comprarían ?

Y si les dijera que lo que aprendan utilizando ese lenguaje, les servirá para toda una familia de lenguajes similares, que van desde herramientas grandes y complejas como los verificadores de teoremas, hasta librerías de scripting de menos de 300kB (no es un error son 300 kilobytes) que podrían simplificar y extender con facilidad programas de C y C++.

¿ Me lo comprarían ?

Seguro que no, incluso habría gente que me diría que eso es vaporware o ciencia ficción, sin embargo llega una empresa como Sun vendiendo la basura de Java y todo el mundo lo compra sin ni siquiera navegar por internet a ver si existe algo mejor.

En realidad BigLisp no existe, sin embargo hay una versión de Scheme llamada Bigloo que tiene casi todas las características que antes mencioné pero que casi nadie usa, porque quien lo hace no es una corporación multinacional, sino un centro de investigación que además hace otro lenguaje espectacular llamado OCaml, que tampoco tiene demasiados usuarios.

Por otra parte los conocimientos de Lisp adquiridos al aprender Scheme, serán útiles para aprender a utilizar herramientas como ACL2 o para extender los programas C, como lo hicieron con Gimp al agregarle ScriptFu, que no es mas que TinyScheme embebido.

Aún así estoy seguro de que muy poca gente me va a comprar eso, mientras no este en las noticias, y nada de eso va a ser noticia porque es casi tan viejo como las primeras computadoras, así que no es noticia, como tampoco es noticia la tecnología de la electricidad, aunque sin ella estaríamos todavía en el siglo XVII.

Mi esperanza es que se comiencen a usar plataformas modernas, que tienen ventajas comparables a las de Lisp, con comunidades que están llegando al punto de masa crítica, y cuyas plataformas avanzan cada vez más rápido, como por ejemplo: Haskell.