viernes, 22 de abril de 2011

Ya viene Perl 5.14

[English translation by google]

Hace unas horas salió el primer candidato a lo que será Perl 5.14 (ahora tenemos nuevas versiones de perl a cada rato :) en esta versión vienen nuevas características convenientes y algunas optimizaciones (sobre todo en windows).

Simetría entre arreglos, hashes y sus referencias

Esta es una de las características que más me gustan de Perl 5.14, pues simplifica la sintaxis cuando se manipulan referencias.

En el caso de los arreglos las primitivas como push, shift, unshift, pop y slice ahora aceptan referencias permitiendo cambiar el código:

  push @{ $arr->[1] }, 8
  $head = shift @{ $obj->arrayref }

por versiones más sencillas que ya no necesitan la dereferencia:

  push $arr->[1], 8
  $head = shift $obj->arrayref

lo que sin duda se ve mejor, sobre todo para los novatos.

Adicionalmnete keys, values y each trabajan con referecias a hashes, pero también trabajarán con arreglos y sus referecias, en este último caso se asumirán los valores del arreglo y las claves seran los índices enteros, así que se podrán hacer cosas como:

  for ( values $obj->arrayref ) { ... }
  for ( keys $obj->arrayref ) { ... }
  for ( keys %{$hoh->{genres}{artists}} ) {...}

En vez de:

  for ( @{ $obj->arrayref } ) { ... }
  for ( 0 .. @{ $obj->arrayref } ) { ... }
  for ( keys $hoh->{genres}{artists}    ) {...}

simplificando igualmente la sintaxis.
 
Una tabla de la documentación da varios ejemplos adicionales:

  |----------------------------+---------------------------|
  | Sintaxis tradicional       | Sintaxis compacta         |
  |----------------------------+---------------------------|
  | push @$arrayref, @stuff    | push $arrayref, @stuff    |
  | unshift @$arrayref, @stuff | unshift $arrayref, @stuff |
  | pop @$arrayref             | pop $arrayref             |
  | shift @$arrayref           | shift $arrayref           |
  | splice @$arrayref, 0, 2    | splice $arrayref, 0, 2    |
  | keys %$hashref             | keys $hashref             |
  | keys @$arrayref            | keys $arrayref            |
  | values %$hashref           | values $hashref           |
  | values @$arrayref          | values $arrayref          |
  | ($k,$v) = each %$hashref   | ($k,$v) = each $hashref   |
  | ($k,$v) = each @$arrayref  | ($k,$v) = each $arrayref  |
  |----------------------------+---------------------------|

Paquetes con bloques

Generalmente cuando se hace un script rápidamente, es más fácil declarar los paquetes (clases) en el mismo archivo, de igual manera es fácil caer en alguna trampa debido a que se tienen varios paquetes en un mismo entorno léxico, así cuando se declaran pragmas o variables léxicas, estas terminan afectando a otras clases o paquetes porque las declaraciones tienen como alcance léxico a todo el archivo, la manera estándar de evitar esto es declarando cada clase dentro de un bloque que acota su alcance léxico:

  {
    package Uno;
    ...
  }
  {
    package Dos;
    ...
  }
  ...

En perl 5.14 un paquete puede tener un bloque, haciendo que la construcción anterior se vea mejor:

  package Uno {
    ...
  }
  package Dos {
    ...
  }
  ...

Substitución no destructiva

Se implementa utilizando el modificador /r a una substitución, logrando que la variable ligada a la operación no sea afectada por la misma, en su lugar se retornará el valor modificado, así que el siguiente código:

  $result = do {
    my $ret = $text;
    $ret =~ s/pedro/juan/;
    $ret;
  };

Se podrá escribir de manera mas concisa en 5.14:

  $result = $text =~ s/pedro/juan/r

Este modificador también se agregó a la transliteración: tr///r

given devuelve valores

Siendo un fanático de Lisp esta característica me gustó, pues con frecuencia suelo simular (cond ...) en Perl haciendo:

my $result;
given ($val) {
    when(1) { $result = "uno" }
    when(2) { $result = "dos" }
    default { $result = undef }
}

En Perl 5.14 se podrá retornar un valor directamente, encapsulando toda la logica y sin necesidad de utilizar variables auxiliares fuera de la estructura:

my $result = do {
  given ($val) {
    when(1) { "uno" }
    when(2) { "dos" }
    default { undef }
} };

El do todavía es necesario ya que el parser de Perl todavía no reconoce la instrucción given como una expresión, aunque probablemente lo haga en el futuro.

\o{...} para incluir caracteres en código octal

Desde siempre Perl permite especificar caracteres como "\0376" sin embargo esta secuencia solo se permite para caracteres hasta 0777 (511), con la nueva secuencia se pueden especificar caracteres unicode con códigos mucho mayores, además el uso de esta secuencia permite eliminar confusiones con las retro-referencias (backreferences) en las expresiones regulares.

Mejoras en Unicode

Ahora se reconocen todo los nombres del unicode incluyendo abreviaturas y nombres de los caracteres de control, así que se pueden escribir caracteres como: "\N{ACK}", "\N{NBSP}", "\N{BEL}", entre otros. Estos nombres también se reconocen tanto en \N{} como en charnames.

Se introduce el pragma:  use feature "unicode_strings" que permite resolver la mayoría de las inconsistencias en la búsqueda de expresiones regulares con unicode, este pragma permitirá que el resultado funcione igual sin importar si la cadena es utf8 o no.

Se introducen los modificadores /d, /l y /u en las expresiones regulares:
  • /l para compilar la expresión regular como si estuviera en el contexto del pragma: use locale
  • /u para compilar la expresión regular como si estuviera en el contexto del pragma: use feature "unicode_strings"
  • /d permite anular los efectos de los pragmas: use locale y use feature "unicode_strings"
  • /a para interpretar la expresión como si fuera ASCII así \s encontrará exactamente los caracteres [ \f\n\r\t], \d encontrará exactamente [0123456789], \w encontrá exactamente los 63 caracteres [A-Za-z0-9_], y las clases de caracteres [[:posix:]] solamente conseguiran los caracteres apropiados del ASCII, también se afectan apropiadamente: \b y \B. Los complementos de estas clases consiguen cualquier cosa fuera de esto, como se debe.

Filehandle cargará automáticamente IO::File

Ahora cualquier filehandle se comportará como un IO::File, cuando se invoque un método inexistente para un filehandle perl cargará automáticamente IO::File, y reintentará la invocación nuevamente.

Mejoras en las funciones tipo printf

Ahora todas las funciones de la familia printf entienden los modificadores del estándar C90: "hh" (char), "z" (size_t), and "t" (ptrdiff_t), si además perl se compila con un compilador C99 también se interpretará el modificador "j" (intmax_t).

Introspección sobre el proceso de compilación

La nueva variable global ${^GLOBAL_PHASE} permitirá a los programas hacer introspección sobre la fase de compilación que se lleva a cabo, lo que permitirá en el futuro mejorar las capacidades de autoextensión del lenguaje.

Para aquellos que no esten al tanto de las capacidades de Perl, enterense que los programas en Perl pueden ejecutarse en tiempo de compilación para alterar el mismo proceso de compilación del programa, por eso aparecen características como está, que facilitará el desarrollo de nuevas extensiones al lenguaje.

Inyección de operaciones en la máquina virtual

Ahora se pueden registrar nuevas operaciones en la máquina virtual de perl, esto facilitará en el futuro la extensión de la máquina virtual con nuevas propiedades y operaciones.

Otras mejoras

Se optimizó la concatenación de cadenas de caracteres que pueden llegar a ser hasta 100 veces más rápidas en ciertas plataformas (como windows).

Se optimizó el uso de %+ y %- para programas que no los utilizan.

viernes, 8 de octubre de 2010

Moose acelerando

El más reciente y exitoso sistema de OOP para Perl, se esta haciendo cada vez más veloz.

En el blog de Moose podemos apreciar que se trabaja continuamente en perfilar el consumo de recursos y mejorar el rendimiento de este sistema, que en su última versión (1.15) es un poquito más lento compilando, mientras incluye más código "en linea" acelerando la ejecución de los programas.

martes, 5 de octubre de 2010

Aplicaciones no tradicionales en Perl

Acabo de ver una aplicación de esas que tal vez inicialmente no se me hubiera ocurrido hacer en Perl: "The Lacuna Expanse", esta aplicación es un juego y es masivamente paralelo, así que yo hubiera investigado como hacerla en Erlang o Haskell, sin embargo hicieron el servidor 100% en Perl, el cliente genérico esta en Javascript y luego hay otros clientes para telefonos hechos en variedad de lenguajes.

Se explota el uso de JSON RPC, y el CPAN les permitió utilizar Plack, Moose, DBIx::Class y la estrella de la fiesta: JSON::RPC::Dispatcher.

Si quieren más información pueden leer el artículo de Ovid y el de JT Smith.

Aquí les dejo el trailer para que alucinen.

Mi proveedor favorito

Hoy entrevisté a un proveedor que pudiera convertirse en uno de mis favoritos, voy a hacer una interpretación libre de la conversación y a lo mejor se imaginan porque quede gratamente impresionado:

Yo: los llamé porque estoy abrumado con tantas cosas por hacer y necesito alguien que ayude a migrar bases de datos Oracle y aplicaciones de Power Builder.

Proveedor: Nosotros somos especialistas en Oracle y Power Builder entre otros, pero estamos trabajando mucho con PostgreSQL, Perl, Python.

Yo: Y si les pido ayuda para migrar aplicaciones Power Builder a la Web que tecnologías me recomiendan.

Proveedor: Bueno nosotros trabajábamos principalmente con Python usando Django, que es un ambiente excelente, sin embargo nos hemos dado cuenta de que aunque Perl no se ve tan bonito, nos rinde más para nuestro trabajo, así que últimamente estamos trabajando más con Catalyst y Perl en general.

Necesito más proveedores así, porque donde yo trabajo si vamos a migrar a software libre.

domingo, 15 de agosto de 2010

La nueva trampa de Java

[ Este artículo es una copia del que se encuentra en Radar Libre ]

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.

miércoles, 17 de marzo de 2010

Un tutorial de catalyst en español

Como ando colapsado sin poder escribir, les dejo el blog de un amigo que va a escribir una serie de artículos sobre Catalyst.

domingo, 31 de enero de 2010

Moose de dieta

[English translation]

¿Te parece que Moose es demasiado pesado para tus aplicaciones?

La compilación de los objetos de Moose puede tomar un tiempo considerable durante el arranque de una aplicación, esto podría dar la impresión de que los programas que utilizan Moose son lentos, sin embargo la compilación solamente ocurre al cargar el programa, y dependiendo de la aplicación pude ser que Moose no sea tan pesado como parece.

Un ejemplo de ello es una aplicación en Catalyst (en versiones mayores a la 5.8), cuando arranca se deben compilar todos los objetos hechos en Moose y se siente la diferencia con las versiones anteriores, pero como Catalyst se va a ejecutar durante dias o meses, no importa mucho el tiempo de arranque.

Si la aplicación que quieres desarrollar es un comando que ejecuta una tarea rápida y termina tal vez Moose es muy pesado para tí, sobre todo cuando ejecutas los comandos repetidamente a través de otros comandos como xargs(1) o find(1).

Para los casos donde el tiempo de arranque de la aplicación no se amortiza bien con la ejecución, hay una solución en el CPAN: Mouse.

Mouse es un reemplazo de Moose muy optimizado que permite utilizar la gran mayoría de las características de Moose, pero es mucho más ligero porque esta desarrollado en XS (es decir en C) y se omiten algunas características para aligerar la ejecución.

Según la página del manual de Mouse, Moose solamente falla en el 1% de los tests de  Mouse, haciendo al último muy compatible con el primero, pero la batería de pruebas se ejecuta 400% más rápido y en mi experiencia yo no puedo notar la diferencia entre utilizar Mouse y cosas como Class::Accessor::Fast, y aunque la segunda pudiera ser algo más rápida (algo que no he probado formalmente), tener a disposición un sistema de OOP como Moose definitivamente vale la pena.

Usar Mouse es muy simple, solo hay que cambiar Moose por Mouse, todo lo demás sigue igual.

Las características presentes en Mouse permiten hacer la mayoría de los programas y objetos que necesitas para aplicaciones y herramientas sencillas, y si llegas a necesitar las características adicionales de Moose, como la metaprogramación, Moose es la única opción razonable y no queda otra que pagar el precio de la compilación inicial.