gerkrt escribió:
Creo que todo lo contestable ya esta contestado, a menos que exista un módulo para poner booleanos,
use boolean;
my $var = true;gerkrt escribió:
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 escribió:
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 escribió:
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 escribió:
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 escribió:
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 escribió:
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 escribió:
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):
Using perl Syntax Highlighting
my $ref = [ qw(Buster Mimi Ginger Ella) ];
sub get_perros { [ qw(Nicki Addy) ] }
push @$ref, 'Addy'; # <==
say "Animales domésticos: @$ref";
my $perro = shift @{ get_perros() }; # <==
say "Perro es $perro";
se podrá reescribir en Perl v5.14 así:
Using perl Syntax Highlighting
my $ref = [ qw(Buster Mimi Ginger Ella) ];
sub get_perros { [ qw(Nicki Addy) ] }
push $ref, 'Addy'; # <==
say "Animales domésticos: @$ref";
my $perro = shift get_perros(); # <==
say "Perro es $dog";
que, al menos, es un poco más claro.
gerkrt escribió:
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 escribió:
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:
Using perl Syntax Highlighting
my $se_ha_leído_el_fichero;
...;
if ($se_ha_leído_el_fichero) {
...;
}
...;
if (es_válido($siguiente_registro)) {
...;
}
gerkrt escribió:
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:
Using perl Syntax Highlighting
# abrir fichero en modo slurp
{
local $/ = undef; # definimos un comportamiento local para $/
my $fichero = ...; # variable local solo para este contexto
...;
}
my $fichero = 'fichero.txt'; # otro contexto
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
)
2011-02-17 15:06 @671
tengo que escribir muy pocas cosas, más bien copio y pego (SOY PROGRAMADOR WEB EN Perl). En otras palabras: ya encuentro en Perl la solución a casi todos mis problemas y rara vez tengo que programar algo.
