Foro - Perl en Español

Sería interesante que se pusieran ejemplos de las "cosas malas"... para ver si te las podemos convertir en "cosas buenas", o al menos, en "cosas ligeramente molestas"

Insisto que gerkrt debería dar algún ejemplo, sencillo o no, de cada una de esa molestias, porque, seguramente, no ha encontrado la forma no-molesta de solucionarlas.

chsanch y pvaldes han comentado el tema de la instalación de los módulos.

Todavía hay mucha gente que no sabe que en su sistema ya está incluido el comando cpan, que es tan cómodo de usar como el gem (más bien, el gem es una copia del cpan).

En distribuciones más modernas se suele poner el cpanplus (comando cpanp, que es el que yo utilizo desde hace un par de años).

Lo que sí hay que tener siempre en cuenta el orden de instalación, empezando por el que nos ofrece el propio sistema operativo y siguiendo por otros métodos, cada vez más molestos. Es siempre mejor bajar el módulo como paquete de software, ya que si depende de bibliotecas en C, estarán ya compiladas para las bibliotecas de nuestro sistema.

gerkrt escribiste:-Jode un montón que tengas que perder la flexibilidad o tiempo porque las variables no son por defecto 'my', ya que si usa el strict mode... pierdes esa característica del lenguaje.

Siempre es recomendable usar 'strict'. Es una forma de decirle a Perl que a partir de ese momento, nos comprometemos (nosotros) a escribir el programa de forma estricta. Por eso hay que declarar todas las variables antes de usarlas (igual que si estuviéramos en otros lenguajes, en los que siempre debemos hacerlo).

Ahora bien, en algunas situaciones no queremos poner el 'our' o el 'my' a todas y cada una de las variables, como es el caso de los comandos Perl de una linea, en la línea de comandos del sistema. En esos casos, no ponemos 'strict', desde luego.

Lo que plantea gerkrt es algo intermedio: quiere programar en modo estricto, pero no teniendo que declarar las variables.

Eso se resuelve con las siguientes líneas:



En Perl 6, el modo estricto está activo por defecto.

Más información en strict.

gerkrt escribiste:Creo que todo lo contestable ya esta contestado, a menos que exista un módulo para poner booleanos,

use boolean;
my $var = true;

gerkrt escribiste:porque lo de los arrays, referencias y símbolos para el contexto, dudo que haya solución, ¿no? Tampoco el {} y el ;.

En efecto, los sigils son inherentes al lenguaje. Si los quitas o cambias, es otro lenguaje.

Los sigils indican el modo de acceder al contenido de las variables. Por ejemplo:

@conserjes = @funcionarios{ 'Juan', 'Francisco', 'Manuel' };

%funcionarios es un hash, pero estamos obteniendo más de un valor a la vez, por lo que ponemos un '@', para indicar -visualmente- que estamos obteniendo una lista de valores.

Esto es una de las cosas más complicadas que encuentran los novatos, sin duda. Hasta que se dan cuenta que, a la hora de leer el código, no se debe ver @funcionarios como un array, sino que estamos extrayendo una lista de valores de la variable %funcionarios.

En Perl 6 lo han vuelto a cambiar. Parece ser que la presión de este juego cambiante de sigils es más duro para los principiantes, así que los diseñadores han decidido que si un array se escribe con '@', que sea así en todas las circunstancias. Entonces, ya no se escribirá $array[0] para referirse al primer elemento del @array, sino como @array[0].

gerkrt escribiste:Lo de no tener que declarar las variables puede ser útil para ciertas cosas, aunque está claro que es útil para tener el código ordenado. Pero el problema para mi es que si lo ideal es usar el modo strict, lo bueno sería que no se tuviera que escribir el my() para declarar una variable, como pasa en otros lenguajes, ya que ese my() me está sobrando en ese caso.

Entonces solo tienes que poner las dos líneas que he publicado en el mensaje anterior.

Repasemos:

gerkrt escribiste:las variables no son por defecto 'my', ya que si usa el strict mode... pierdes esa característica del lenguaje.

Resuelto con no strict 'vars';

gerkrt escribiste:Los usos de $,% o @... según el contexto y no por el tipo. Me sobran totalmente.

Es inherente al lenguaje. La solución es usar otro lenguaje, como Python. Si no quieres abandonar Perl, puedes escribir al estilo de Python con Acme::Pythonic o incluso usar el propio lenguaje Python dentro de tus programas Perl, con Inline::Python.

gerkrt escribiste:Los módulos de CPAN se deben instalar a mano con comandos más complejos que por ejemplo, un gem de Ruby

Desde el shell: cpan <módulo a instalar>

gerkrt escribiste:A veces se pasan con los truquillos y variaciones. O sea, creo que deberían tener más límites

Eso no depende del lenguaje, sino del programador. Las recomendaciones de estilo más modernas aconsejan no usar trucos ni código demasiado compacto, ya que eso, al final, degrada la calidad del código: es mucho más difícil de leer y mantener. Los anglosajones lo llaman "no te pases de listillo". Si un día quieres hacer código compacto, es porque quieres participar en el Perl Golf, hacer un poema Perl, o un código Perl ofuscado.

gerkrt escribiste:No me gustan las referencias necesarias para pasar arrays y cosas por el estilo. Creo que sería mejor que los arrays de perl pudieran tener realmente otros arrays dentro de forma directa y soportada por el lenguaje. Eso facilitaría mucho las cosas...

Las referencias (o punteros) son tan viejas como la informática. Lenguajes como C, Fortran, Pascal... necesitan de una notación para referirse a otras variables.

Cuando decimos que, en una subrutina, es mucho más eficiente pasar la referencia a un array que los propios valores de un array, es porque se ve muy claro cuando ese array puede contener miles o millones de valores. El tiempo de pasar todos esos valores a la subrutina puede ser significativo. En lugar de eso, solo pasamos la referencia a (es decir, dónde está) el array.

La notación de Perl en referencias es muy parecida a la de C, con el uso de operador de indirección '->'.

Es cierto que, algunas veces, la notación puede ser muy críptica. En esos casos, siempre es mejor dividir la tarea en pasos más sencillos o desreferenciar los valores para trabajar con ellos directamente.

En el próximo Perl v5.14, se ha permitido que las funciones push, pop, shift y unshift trabajen con las referencias de array, por lo que, el siguiente código (válido hasta Perl v5.12):


se podrá reescribir en Perl v5.14 así:

que, al menos, es un poco más claro.

gerkrt escribiste:Además ayudaría una OO más fácil para crear fácilmente tus propias clases contenedoras

En Perl existen docenas de soluciones para programar en docenas de formas distintas en OO, aunque lo recomendable es usar Moose o Mouse. En estos dos últimos años, me he dado cuenta de que cada vez más módulos de los que instalo ya dependen de ellos.

gerkrt escribiste:Que no haya un booleano real

Aparte de lo comentado antes con el módulo boolean, en Perl se definen unos pocos valores como falsos, dejando a todos los demás como verdaderos (ver la lista en la página Perl de Wikipedia o en perlsyn).

Si quisiéramos tener un representante real de lo que significa la falsedad, podríamos usar undef():

$var = undef;

que evalúa a la cadena vacía en contexto de caracteres, y al cero, en contextos numéricos. Para los valores que podrían representar la verdad, yo suelo usar el 1, '1', 'forever', etc...

La recomendación actual (extraída del libro Perl Best Practices, regla Booleans) es que las variables y las funciones que devuelven valores booleanos deberían ser nombradas en el sentido de lo que representan:

gerkrt escribiste:Creo que un lenguaje de script que pretende dar tantas facilidades y acortar trabajo debería prescindir de los {} y ; igual que lo hace de los ()

Para mí, sin esos elementos, sería complicado crear código de forma artística o formateada, más fácil de leer. Quiero decir que si quitas andamiajes del lenguaje, te obliga a construir código siguiendo otras reglas más estrictas.

Las llaves definen nuevos contextos. Y el ';' separa instrucciones. Sin las llaves no sería posible crear espacios de nombres separados del flujo normal del programa:
Y sin el carácter ';' no podría hacer programas Perl en una línea, en la línea de comandos:
perl -E 'use File::stat; $st = stat("/etc/crontab"); say "Sí es legible" if -f $st'

De todas maneras, la comunidad Perl está abierta a todo tipo de propuestas. Si deseas proponer mejoras en cuanto al lenguaje, siempre puedes enviarlas a los Perl 5 Porters.

Si quitáramos las llaves y ';' tendríamos un lenguaje parecido al Python, donde es importante el sangrado y colocación del código para significar algo.

En Perl tienes un par de módulos que te permitirán escribir programas de esa manera, como el comentado Acme::Pythonic.

Yo, particularmente, prefiero que el lenguaje me dé más libertades a la hora de escribir el código, a costa de escribir (aparentemente), algo más.

Y si no termina de convencerte el lenguaje, no pasa nada... existen muchos otros lenguajes con los que podrás sentirte más a gusto (Perl no tiene por qué gustar a todo el mundo, claro )