Foro - Perl en Español

Pues nada, me ha dado por opinar sobre este lenguaje tras trastear y aprender un tiempo. Aunque en cuanto a teoría he devorado la mayor parte de los manuales de referencia que tengo.


Cosas buenas:
-El uso de los contextos, variables dinámicas, escalares y autoconversiones lo convierten en un lenguaje muy especial e hiperpotente aunque demasiadas veces tienes la sensación de perder un poco el control, aunque me gusta y facilita las cosas si sabes. Lo del $_ es casi mágico xDDDDDDDDD

-El gigantesco CPAN.

-Algo bueno es que es un lenguaje con mucha personalidad, o sea, algo muy distinto. Probé el bash y me pareció similar en cuanto a ser de otro universo, pero era exagerado. Yo creo que Perl está en su justa medida.

-Reconozco que me mola la idea de hacer las cosas de mil maneras, me gusta ir descubriendo cosas nuevas cada vez. El Python, por ejemplo, me aburre.

-La mayoría de trucos no me parecen mal, tampoco el uso de distintos símbolos para variables.

-No estoy en contra de las referencias, aunque sobren para algunas cosas.


Cosas malas:
Hay cosas que me parecen imperdonables como todo el trapicheo que hay que hacer para tener OO o algunas limitaciones de las subs (argumentos nombrados y default fácilmente...)

-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.

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

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

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

-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...

-Además ayudaría una OO más fácil para crear fácilmente tus propias clases contenedoras.

-Que no haya un booleano real.

-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 ().

Notad que obviamente no todas ellas son objetivas, muchas son gustos personales, pero quería dar mi opinión. Acabaré mi aplicación actual... (usa OO, referencias... quizás Tk) pero no me apasiona para muchas cosas.

Estaré al tanto de Perl 6.

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"

gerkrt escribiste:
Cosas malas:
-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.

Esto no lo entendí, en todo caso siempre es recomendable usar Strict, o hacer uso del módulo Modern::Perl que activa todas estas funcionalidades por defecto.

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

Creo que no conoces App::cpanminus revísalo y vas a ver que no existe mejor forma de instalar módulos. Y combinado con local::lib puedes crear un entorno de desarrollo bastante bueno.

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

Revisa Moose, vas a conocer lo mejor para OO.

Saludos.

"cosas ligeramente molestas de perl", que joya de frase para un hilo

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

mmmh... no necesariamente: en Linux puedes instalar automáticamente muchos de ellos desde paquete y luego cargarlos con gran facilidad: use módulo; no es algo que llegue ni a la categoría de ligeramente molesto... no será lo ultimísimo de lo último pero a cambio es sumamente cómodo.

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.

Creo que todo lo contestable ya esta contestado, a menos que exista un módulo para poner booleanos, porque lo de los arrays, referencias y símbolos para el contexto, dudo que haya solución, ¿no? Tampoco el {} y el ;.

Aparte lo del booleano es fácil solo con declarar un par de constantes, aunque se debería ver cómo funcionara la autoconversión con ellos. Otra opción sería crear una clase propia boolean.

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.

Apunto lo de Moose, desde luego le da muchas vueltas al OO default. Todo lo demás también, está claro.

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 )

Muchas gracias por todas las respuestas, las usaré todas ellas.

Solo un detalle: a mi no me apasiona el Python, prefiero el Ruby o Perl, y lo del sangrado puede ser un rollazo. Aunque lo he usado para algunas cosas.

En Ruby no usas el ';' sino el "\n" como fin de línea, pero lo bueno es que es opcional, así que si quieres escribir diversas instrucciones en una línea lo haces... (a veces mejora mucho la legibilidad, entre otras cosas...)

Las '{}' son necesarias. No digo algo en plan PHP cuando no los usas o la idea de Python, sino por ejemplo, de nuevo, la expresión end de Ruby. Con ella los bloques, sean cuales sean, se cierran con un end.

Nota que el end es en sí, más largo de escribir que el '{}', pero personalmente me gusta más. En PHP existe un valor raro que es alternativa al '{}', también.

De nuevo me refiero a Ruby diciendo que cuando tu pasas un array a una función no pasas el dato entero, sino la referencia, pero el manejo de ésta es automática.

Y sobre lo de gustarme Perl, no me desagradaba y desde luego mejora mucho con todo lo comentado actualmente. Tengo planeado aprenderme al 100% las expresiones regulares usando Perl, por ejemplo, aunque estoy planeando qué tipo de programa crear para practicar y sacarle partido.

De todas formas, todas estas mejoras son difíciles de captar para el novato y son opcionales. No digo que esté bien o mal, ya que Perl veo que es un lenguaje que un módulo lo puede modificar casi por completo, pero es muy fácil perderse entre tantas opciones... aunque eso irá a gustos, claro. No sé si existirá, pero podrías escribir algún tipo de FAQ o algo así con este tipo de cosas.

P.D.: ¿no hay ningún módulo que mejore el uso de argumentos de las sub(), o algo así?

En la universidad yo estoy aprendiendo Java, y mis conocimientos en Perl me han ayudado mucho y encuentro muchas cosas en Perl que extraño en Java (aunque aun no lo conozco bien).

Yo prefiero Perl que Java, no sólo por las características del lenguaje, sino que también el desempeño del interprete (perl) me parece más liviano y rápido que la máquina virtual de Java.

En cuanto al lenguaje quería compartir un par de opiniones, que irónicamente son contradichas por gerkrt y seguro que por muchos más.

• Boolean: En mi opinión es muy largo tener que escribir true o false. No creo que tener una variable de este tipo traiga ventajas ante variables enteros (0 o menor para falso, mayor para verdadero), es más: las variables tipo entero dan la posibilidad de devolver distintos errores o mensajes dependiendo del caso (tal como se hace en ANSI C).
  
• Yo tengo un profesor que no se toma el tiempo en sangrar y si el código tiene un poco de if sin el uso de las llaves ({}) la comprensión del código se dificulta aún más.
  
• Ya llevo como una semana aprendiendo OOP y la he entendido muy bien, pero lo que no comprendo es por qué los programadores prefieren la OOP como la de Java y no les gusta la de Perl. Yo prefiero la de Perl porque los atributos no están regados en la clase, no hay sobrecarga de constructores, no hay que crear una variable del tipo objeto y después decirle new objeto (Objeto cosa = new Objeto) lo cual encuentro redundante.

Para mi el problema de la OO de Perl era la sintaxis tan pobre, Moose lo soluciona. La sobrecarga de constructores es una opción más. De hecho no es particularmente necesaria aunque es una técnica que da una solución más para ciertos problemas, pero se puede de hacer en todos los lenguajes...

Sobre los boolenos, va a gustos. A mi me gusta más usar el true/false, y eso que empece con C. Aparte, es mucho más claro y coherente, también.

Supongo que te referirás al if (x) x++, ¿no? Bueno, es como el condicional de una línea de Perl, solo que al revés.