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.

domingo, agosto 15, 2010

La nueva trampa de Java

La demanda iniciada por ORACLE contra Google donde se argumenta que el sistema operativo Android viola patentes propiedad de ORACLE, muestra una debilidad de lo que usualmente muchos en la comunidad (incluyendome) consideramos software libre.

Desde que Sun Microsystems liberó la mayor parte del código de la plataforma Java, este asunto ha pasado por debajo de la mesa, pues las implementaciones que se utilizan son: la original, y alguna que otra licenciada directamente del propietario.

En un debate ocurrido hace un lustro, sobre El uso de Java en el Plan Nacional de Migración a Software Libre, Simon Phipps argumentaba que Sun Microsystems era una compañía amigable, que había prometido liberar el código y que estaba trabajando para ello.

En aquel momento mi argumento fue que las corporaciones no tienen alma, sentimientos o lealdad, que son básicamente actores de guerras que solo obedecen a motivos económicos y que verlas de cualquier otra manera era un riesgo que que el Estado no debería correr.

Después de un lustro y luego de la desaparición Sun, al ser adquirida por ORACLE, quedó demostrado que Simon Phipps probablemente tenía razón, Sun finalmente liberó lo que pudo de Java y nunca aplicó tarifas al licenciamiento de la plataforma, sin embargo yo también tenía razón: las corporaciones no tienen alma y ahora que Sun fue tragada por ORACLE se lanza al ataque en contra de quien pueda rendirle beneficios.

Este ataque es hoy posible gracias a un arma secreta que Sun mantenía en su arsenal: "Patentes de Software", para evitar suspicacias como las que siempre han rodeado a Mono, Sun emitió una liberación de uso de dichas patentes para cualquier implementación de  Java, siempre y cuando la implementación incluyera todas las características y servicios de la plataforma y no se incluyera ninguna característica o servicio adicional, es decir que para evitar una demanda de propiedad intelectual por patentes el distribuidor debía asegurarse de:

implementar toda la plataforma y solo la plataforma

Aquí es donde Google cayó en la trampa porque al parecer no incluyó AWT y Swing que son parte integral de la especificación.

Sin embargo lo peligroso de todo este asunto no es la demanda de ORACLE a Google, que puede presentar una buena pelea judicial al estilo SCO, Novel e IBM, sino que la trampa ahora es mucho más sutil (pero no menos potente), ya no basta que un código sea GPL versión 2 para que sea realmente libre.

En los términos establecidos por la liberación de derechos de uso de las patentes de Sun se coarta la libertad 3, que da el derecho a modificar el código y redistribuir el resultado de la modificación, porque Oracle va a demandar por violación de patente al quedar fuera de la protección de la liberación de derechos de uso de patentes, independientemente de lo que diga la GPLv2.

Así que en realidad aunque la mayoría del código de la plataforma Java sea libre por derecho, de hecho no es libre porque ORACLE puede utilizar otros instrumentos para ejercer coacción sobre cualquiera que intente modificar la plataforma, y por lo tanto no cumple con el espíritu del decreto 3390, por ello debe prohibirse nuevamente el uso de esta plataforma en el Estado hasta que se aclare esta situación o se libere Java bajo la licencia GPL versión 3 que incluye protección legal contra las patentes.

Finalmente en un tono más personal deberíamos hacer un esfuerzo coordinado por dejar de consumir productos ORACLE para que la corporación aprenda por la única vía posible: su cuenta bancaria, que jugar con la libertad puede resultar peligroso y dañino.

Dejar de consumir productos de esta infame comañía no es difícil, casi cualquier cosa que se esté haciendo con su manejador de base de datos, se puede hacer con PostgerSQL y todo el resto de sus productos son bastante malos, incluyendo el lenguaje de programación Java (no la plataforma) así que en general, dejar de usar productos ORACLE se puede considerar de entrada como una ventaja competitiva.

lunes, enero 11, 2010

Nuevo lenguaje concurrente

Si creen que les voy a hablar de GO, se equivocan, ya todo el mundo habla de esto hasta el aburrimiento, y la verdad es que lo mas sensacional de GO es que lo lanzó google.

Pero hoy mientras navegaba por ahí me encontré con con ANI, este lenguaje me pareció interesante y tengo pendiente revisarlo más a fondo, de la descripción del compilador llamado anic:

anic es una implementación de referencia para el lenguaje de programación experimental ANI, con las siguientes características de alto rendimiento, estáticamente verificado, con total paralelismo implícito, orientado a objetos, de propósito general.

Se supone que ANI es tan facil como sh y tan eficiente como C, hay que verlo.

viernes, setiembre 25, 2009

El santo grial de la depuración es inminente

Hay algunas situaciones difíciles de depurar, por ejemplo cuando se pierde el control de un puntero que destruye la mitad de la memoria antes de causar una violación de segmento.
Si nunca han pasado por esto hay dos alternativas, o nunca han trabajado en C o son mucho más inteligentes que yo.
Lo cierto es que ese problema sería fácil de depurar con solo permitir que nuestro depurador nos deje ejecutar el programa en reverso, así solo ejecutamos el programa hacia atrás mientras vamos recuperando toda nuestra memoria, hasta el punto donde el puntero se desboca, y seguramente estaremos viendo porque se desbocó.
El problema siempre ha sido que eso es mucho más fácil de pensar que de implementar, porque lo que se requiere es prácticamente una máquina del tiempo para lograrlo.
Pues aunque Ud. no lo crea, se supone que la versión 7 de GDB permitirá la ejecución en reversa.  Lo mejor es que esta versión está prometida para este mes, por lo que asumo que es inminente su distribución, no tengo idea del precio a pagar por esta funcionalidad, pero de seguro no será barata, claro que podremos ejecutar los programas desde el final hasta el comienzo.
Filosofando un poco: un programa que se ejecuta hacia atrás se alimenta de soluciones y genera problemas, así que es mejor no dedicarle muchos recursos a esta tecnología.
Ahora en serio, si esta característica algún día fuera barata podríamos resolver algunos problemas clásicos de sistemas operativos con mucha facilidad, por ejemplo ya no nos preocuparíamos por los deadlocks, porque solamente hay que retroceder el programa adecuado un poquito hasta que se libere el recurso que causa la tranca.

martes, setiembre 22, 2009

Migrando de Subversion a Git

Este es tal vez la mejor receta que he encontrado para migrar repositorios de Subversion a Git:

  http://blog.woobling.org/2009/06/git-svn-abandon.html

Para que todo vaya bien hay que tener un archivo authors.txt que se usa en uno de los comando, mosca con eso.  Por lo demás esto parece dejar el repositorio casi como si fuera originalmente hecho en Git.