From jjmerelo en gmail.com  Mon Dec  1 05:51:23 2014
From: jjmerelo en gmail.com (JJ Merelo)
Date: Mon, 1 Dec 2014 14:51:23 +0100
Subject: [Madrid-pm] Ayuda con Perl 6
Message-ID: <CAJoLtgcRB2C=M2+n28z3BrsEN-B6RoAMxVCqJd6iD6_oKXvzyg@mail.gmail.com>

Por mucho que he buscado, no me entero de qué significa esto en Perl 6

my @uniq_results= @all_results.uniq(:as(*.url));

(a partir del :as)

Está en la presentación de Reactive Perl de Worthington, transpa 11
http://jnthn.net/papers/2014-nlpw-reactive.pdf

De hecho, no sé ni qué es :as. ¿Un placeholder? Supongo que *.url es algo
así como $_.url antiguamente, pero no sé que hace :as.

Saludos y gracias.
-- 
JJ
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://mail.pm.org/pipermail/madrid-pm/attachments/20141201/4fca06e5/attachment.html>

From roberto en freekeylabs.com  Mon Dec  1 07:30:04 2014
From: roberto en freekeylabs.com (Roberto Henriquez)
Date: Mon, 01 Dec 2014 16:30:04 +0100
Subject: [Madrid-pm] Ayuda con Perl 6
In-Reply-To: <CAJoLtgcRB2C=M2+n28z3BrsEN-B6RoAMxVCqJd6iD6_oKXvzyg@mail.gmail.com>
References: <CAJoLtgcRB2C=M2+n28z3BrsEN-B6RoAMxVCqJd6iD6_oKXvzyg@mail.gmail.com>
Message-ID: <547C897C.2050500@freekeylabs.com>

On 12/01/2014 02:51 PM, JJ Merelo wrote:
> Por mucho que he buscado, no me entero de qué significa esto en Perl 6
>
> my @uniq_results= @all_results.uniq(:as(*.url));
>
> (a partir del :as)
>
> Está en la presentación de Reactive Perl de Worthington, transpa 11
> http://jnthn.net/papers/2014-nlpw-reactive.pdf
>
> De hecho, no sé ni qué es :as. ¿Un placeholder? Supongo que *.url es
> algo así como $_.url antiguamente, pero no sé que hace :as.
>

Por lo que veo aquí 
(https://github.com/perl6/specs/commit/c313c2918ecdf5d72a0fa989670fed332d317d67) 
el :as se usaría para especificar una función con la que generar los 
valores únicos, en este caso ?supongo, porque yo de perl6 poco? llamar 
el método .url de cada elemento.

saludos!

-- 
Roberto Henríquez
roberto en freekeylabs.com

From jjmerelo en gmail.com  Mon Dec  1 07:47:27 2014
From: jjmerelo en gmail.com (JJ Merelo)
Date: Mon, 1 Dec 2014 16:47:27 +0100
Subject: [Madrid-pm] Ayuda con Perl 6
In-Reply-To: <547C897C.2050500@freekeylabs.com>
References: <CAJoLtgcRB2C=M2+n28z3BrsEN-B6RoAMxVCqJd6iD6_oKXvzyg@mail.gmail.com>
	<547C897C.2050500@freekeylabs.com>
Message-ID: <CAJoLtgdChAwqjCJePnQSAz-BLeqOV3_q7oEcgb=tdwkYiLxjiA@mail.gmail.com>

Ah, genial. Muchas gracias.

El 1 de diciembre de 2014, 16:30, Roberto Henriquez <roberto en freekeylabs.com
> escribió:

> On 12/01/2014 02:51 PM, JJ Merelo wrote:
>
>> Por mucho que he buscado, no me entero de qué significa esto en Perl 6
>>
>> my @uniq_results= @all_results.uniq(:as(*.url));
>>
>> (a partir del :as)
>>
>> Está en la presentación de Reactive Perl de Worthington, transpa 11
>> http://jnthn.net/papers/2014-nlpw-reactive.pdf
>>
>> De hecho, no sé ni qué es :as. ¿Un placeholder? Supongo que *.url es
>> algo así como $_.url antiguamente, pero no sé que hace :as.
>>
>>
> Por lo que veo aquí (https://github.com/perl6/specs/commit/
> c313c2918ecdf5d72a0fa989670fed332d317d67) el :as se usaría para
> especificar una función con la que generar los valores únicos, en este caso
> ?supongo, porque yo de perl6 poco? llamar el método .url de cada elemento.
>
> saludos!
>
> --
> Roberto Henríquez
> roberto en freekeylabs.com
> _______________________________________________
> Madrid-pm mailing list
> Madrid-pm en pm.org
> http://mail.pm.org/mailman/listinfo/madrid-pm




-- 
JJ
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://mail.pm.org/pipermail/madrid-pm/attachments/20141201/5c71f9fd/attachment.html>

From sfandino en yahoo.com  Mon Dec  1 23:08:13 2014
From: sfandino en yahoo.com (Salvador Fandino)
Date: Tue, 2 Dec 2014 07:08:13 +0000 (UTC)
Subject: [Madrid-pm] Ayuda con Perl 6
In-Reply-To: <547C897C.2050500@freekeylabs.com>
References: <547C897C.2050500@freekeylabs.com>
Message-ID: <974292699.3646043.1417504093952.JavaMail.yahoo@jws106130.mail.bf1.yahoo.com>





----- Original Message -----
> From: Roberto Henriquez <roberto en freekeylabs.com>
> To: madrid-pm en pm.org
> Cc: 
> Sent: Monday, December 1, 2014 4:30 PM
> Subject: Re: [Madrid-pm] Ayuda con Perl 6
> 
> On 12/01/2014 02:51 PM, JJ Merelo wrote:
>>  Por mucho que he buscado, no me entero de qué significa esto en Perl 6
>> 
>>  my @uniq_results= @all_results.uniq(:as(*.url));
>> 
>>  (a partir del :as)


Si no recuerdo mal, la sintaxis :key(value) es una forma de pasar un valor por nombre a una función.


El *.url crea una subrutina anónima


Osea, que uniq(:as(*.url)) es lo que en Perl 5, típicamente se escribiría:

  uniq(as => sub { $_->url });

From explorer en joaquinferrero.com  Tue Dec  2 01:36:11 2014
From: explorer en joaquinferrero.com (Joaquin Ferrero)
Date: Tue, 02 Dec 2014 10:36:11 +0100
Subject: [Madrid-pm] Ayuda con Perl 6
In-Reply-To: <974292699.3646043.1417504093952.JavaMail.yahoo@jws106130.mail.bf1.yahoo.com>
References: <547C897C.2050500@freekeylabs.com>
	<974292699.3646043.1417504093952.JavaMail.yahoo@jws106130.mail.bf1.yahoo.com>
Message-ID: <547D880B.9050004@joaquinferrero.com>

El 02/12/14 a las 08:08, Salvador Fandino escribió:
>
>
>
> ----- Original Message -----
>> From: Roberto Henriquez <roberto en freekeylabs.com>
>> To: madrid-pm en pm.org
>> Cc:
>> Sent: Monday, December 1, 2014 4:30 PM
>> Subject: Re: [Madrid-pm] Ayuda con Perl 6
>>
>> On 12/01/2014 02:51 PM, JJ Merelo wrote:
>>>   Por mucho que he buscado, no me entero de qué significa esto en Perl 6
>>>
>>>   my @uniq_results= @all_results.uniq(:as(*.url));
>>>
>>>   (a partir del :as)
>
> Si no recuerdo mal, la sintaxis :key(value) es una forma de pasar un valor por nombre a una función.
>
>
> El *.url crea una subrutina anónima
>
>
> Osea, que uniq(:as(*.url)) es lo que en Perl 5, típicamente se escribiría:
>
>    uniq(as => sub { $_->url });
> _______________________________________________
> Madrid-pm mailing list
> Madrid-pm en pm.org
> http://mail.pm.org/mailman/listinfo/madrid-pm

Creo que en la documentación de Perl 6 se refieren a esta sintaxis como "adverbios", ya que modifican el significado del verbo.

http://perl6advent.wordpress.com/2013/12/10/day-10-adverbly-adverby-adverbs/


JF



From jjmerelo en gmail.com  Tue Dec  2 01:39:25 2014
From: jjmerelo en gmail.com (JJ Merelo)
Date: Tue, 2 Dec 2014 10:39:25 +0100
Subject: [Madrid-pm] Ayuda con Perl 6
In-Reply-To: <547D880B.9050004@joaquinferrero.com>
References: <547C897C.2050500@freekeylabs.com>
	<974292699.3646043.1417504093952.JavaMail.yahoo@jws106130.mail.bf1.yahoo.com>
	<547D880B.9050004@joaquinferrero.com>
Message-ID: <CAJoLtgfksQoDCQFGd1Ei6q4VYn_D67cZvk+aDRBm5EZZHOX1Hw@mail.gmail.com>

Genial, muchas gracias (aunque no he recibido la respuesta de Salva por
alguna razón)

El 2 de diciembre de 2014, 10:36, Joaquin Ferrero <
explorer en joaquinferrero.com> escribió:

> El 02/12/14 a las 08:08, Salvador Fandino escribió:
>
>>
>>
>>
>> ----- Original Message -----
>>
>>> From: Roberto Henriquez <roberto en freekeylabs.com>
>>> To: madrid-pm en pm.org
>>> Cc:
>>> Sent: Monday, December 1, 2014 4:30 PM
>>> Subject: Re: [Madrid-pm] Ayuda con Perl 6
>>>
>>> On 12/01/2014 02:51 PM, JJ Merelo wrote:
>>>
>>>>   Por mucho que he buscado, no me entero de qué significa esto en Perl 6
>>>>
>>>>   my @uniq_results= @all_results.uniq(:as(*.url));
>>>>
>>>>   (a partir del :as)
>>>>
>>>
>> Si no recuerdo mal, la sintaxis :key(value) es una forma de pasar un
>> valor por nombre a una función.
>>
>>
>> El *.url crea una subrutina anónima
>>
>>
>> Osea, que uniq(:as(*.url)) es lo que en Perl 5, típicamente se escribiría:
>>
>>    uniq(as => sub { $_->url });
>> _______________________________________________
>> Madrid-pm mailing list
>> Madrid-pm en pm.org
>> http://mail.pm.org/mailman/listinfo/madrid-pm
>>
>
> Creo que en la documentación de Perl 6 se refieren a esta sintaxis como
> "adverbios", ya que modifican el significado del verbo.
>
> http://perl6advent.wordpress.com/2013/12/10/day-10-
> adverbly-adverby-adverbs/
>
>
> JF
>
>
>
> _______________________________________________
> Madrid-pm mailing list
> Madrid-pm en pm.org
> http://mail.pm.org/mailman/listinfo/madrid-pm
>



-- 
JJ
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://mail.pm.org/pipermail/madrid-pm/attachments/20141202/36ab408d/attachment.html>

From alexm en caliu.cat  Tue Dec  2 07:11:14 2014
From: alexm en caliu.cat (Alex Muntada)
Date: Tue, 2 Dec 2014 16:11:14 +0100
Subject: [Madrid-pm] Ayuda con Perl 6
In-Reply-To: <CAJoLtgfksQoDCQFGd1Ei6q4VYn_D67cZvk+aDRBm5EZZHOX1Hw@mail.gmail.com>
References: <547C897C.2050500@freekeylabs.com>
	<974292699.3646043.1417504093952.JavaMail.yahoo@jws106130.mail.bf1.yahoo.com>
	<547D880B.9050004@joaquinferrero.com>
	<CAJoLtgfksQoDCQFGd1Ei6q4VYn_D67cZvk+aDRBm5EZZHOX1Hw@mail.gmail.com>
Message-ID: <CAGQ+ubpSfrZhJaAYLknvkP-fQm-bVBjXfy=wjHfigx64rXqRcw@mail.gmail.com>

JJ Merelo:

> (aunque no he recibido la respuesta de Salva por alguna razón)

Yo tenía su respuesta en la carpeta de spam.

Un saludo,
Alex

From ricardo en mones.org  Tue Dec  2 08:19:17 2014
From: ricardo en mones.org (Ricardo Mones)
Date: Tue, 2 Dec 2014 17:19:17 +0100
Subject: [Madrid-pm] Ayuda con Perl 6
In-Reply-To: <CAGQ+ubpSfrZhJaAYLknvkP-fQm-bVBjXfy=wjHfigx64rXqRcw@mail.gmail.com>
References: <547C897C.2050500@freekeylabs.com>
	<974292699.3646043.1417504093952.JavaMail.yahoo@jws106130.mail.bf1.yahoo.com>
	<547D880B.9050004@joaquinferrero.com>
	<CAJoLtgfksQoDCQFGd1Ei6q4VYn_D67cZvk+aDRBm5EZZHOX1Hw@mail.gmail.com>
	<CAGQ+ubpSfrZhJaAYLknvkP-fQm-bVBjXfy=wjHfigx64rXqRcw@mail.gmail.com>
Message-ID: <20141202161917.GG24928@trasgu>

On Tue, Dec 02, 2014 at 04:11:14PM +0100, Alex Muntada wrote:
> JJ Merelo:
> 
> > (aunque no he recibido la respuesta de Salva por alguna razón)
> 
> Yo tenía su respuesta en la carpeta de spam.

Idem (GMail).

Saludos y gracias por el aviso ;)
-- 
  Ricardo Mones 
  ~
  bash: ./signature: No such file or directory              /bin/bash


From sfandino en yahoo.com  Tue Dec  2 08:49:49 2014
From: sfandino en yahoo.com (Salvador Fandino)
Date: Tue, 2 Dec 2014 16:49:49 +0000 (UTC)
Subject: [Madrid-pm] Ayuda con Perl 6
In-Reply-To: <20141202161917.GG24928@trasgu>
References: <20141202161917.GG24928@trasgu>
Message-ID: <211697285.3858131.1417538989222.JavaMail.yahoo@jws10686.mail.bf1.yahoo.com>

Desde hace algunos meses Yahoo implementa no-se-que-protocolo para reducir el spam que no interfiere con el funcionamiento de muchas listas de correo...

Supongo que debería de cambiar de proveedor, pero despues de tanto tiempo es dificil!!!




----- Original Message -----
> From: Ricardo Mones <ricardo en mones.org>
> To: madrid-pm en pm.org
> Cc: 
> Sent: Tuesday, December 2, 2014 5:19 PM
> Subject: Re: [Madrid-pm] Ayuda con Perl 6
> 
> On Tue, Dec 02, 2014 at 04:11:14PM +0100, Alex Muntada wrote:
>>  JJ Merelo:
>> 
>>  > (aunque no he recibido la respuesta de Salva por alguna razón)
>> 
>>  Yo tenía su respuesta en la carpeta de spam.
> 
> Idem (GMail).
> 
> Saludos y gracias por el aviso ;)
> -- 
>   Ricardo Mones 
>   ~
>   bash: ./signature: No such file or directory              /bin/bash
> 
> 
> _______________________________________________
> Madrid-pm mailing list
> Madrid-pm en pm.org
> http://mail.pm.org/mailman/listinfo/madrid-pm
>

From explorer en joaquinferrero.com  Tue Dec  2 14:57:03 2014
From: explorer en joaquinferrero.com (Joaquin Ferrero)
Date: Tue, 02 Dec 2014 23:57:03 +0100
Subject: [Madrid-pm] Nueva herramienta para procesar la ingente cantidad de
 textos de la web
Message-ID: <547E43BF.3080909@joaquinferrero.com>

Hola.

«/Investigadores del centro CiTIUS de la Universidad de Santiago de Compostela han creado un software libre que acelera el procesamiento de textos y documentos publicados en la web. Su nombre es Perldoop, y permite el análisis de los datos de una forma más sencilla y eficiente.//»/ Artículo <http://vlcnoticias.com/nueva-herramienta-para-procesar-la-ingente-cantidad-de-textos-de-la-web/>

Esta gente <http://proxectos.citius.usc.es/hpcpln/index.php/en/software-tools> ha desarrollado un programa <https://github.com/citiususc/perldoop> que traduce programas escritos en Perl a Java, aumentando en doce veces <http://proxectos.citius.usc.es/hpcpln/images/documents/abuin14Perldoop.pdf> la velocidad de procesamiento de textos.

El tema está en que es la herramienta Hadoop la que permite ejecutar programas escritos en otros lenguajes, y se dieron cuenta de que al hacerlo en Perl, aunque tenía una gran facilidad para trabajar con exp. reg., iba mucho más lento que haciéndolo en Java (?) así que se han currado esa herramienta.

Lo que me llama la atención es lo de que Java sea doce veces más rápido... algo no me cuadra.

JF

From alexm en caliu.cat  Tue Dec  2 21:25:28 2014
From: alexm en caliu.cat (Alex Muntada)
Date: Wed, 3 Dec 2014 06:25:28 +0100
Subject: [Madrid-pm] Nueva herramienta para procesar la ingente cantidad
 de textos de la web
In-Reply-To: <547E43BF.3080909@joaquinferrero.com>
References: <547E43BF.3080909@joaquinferrero.com>
Message-ID: <CAGQ+uboFAy-4uaLraDauxC1cTgDrL9ykoMTozinqn-LSL8aiQw@mail.gmail.com>

Para más inri está escrito en python, casi parece una broma...

Lo de que sea más rápido en java parece ser por el modo de ejecución de
hadoop para lenguajes no java.

Un saludo,
Alex
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://mail.pm.org/pipermail/madrid-pm/attachments/20141203/e69f3754/attachment.html>

From jjmerelo en gmail.com  Tue Dec  2 22:25:25 2014
From: jjmerelo en gmail.com (JJ Merelo)
Date: Wed, 3 Dec 2014 07:25:25 +0100
Subject: [Madrid-pm] Nueva herramienta para procesar la ingente cantidad
 de textos de la web
In-Reply-To: <CAGQ+uboFAy-4uaLraDauxC1cTgDrL9ykoMTozinqn-LSL8aiQw@mail.gmail.com>
References: <547E43BF.3080909@joaquinferrero.com>
	<CAGQ+uboFAy-4uaLraDauxC1cTgDrL9ykoMTozinqn-LSL8aiQw@mail.gmail.com>
Message-ID: <CAJoLtgfgkae=t9wQiVit-ExqyoQ-5QXEWAn2YWazPFJGjmKogg@mail.gmail.com>

¿Y por qué no map-reduce directamente en Perl?
http://search.cpan.org/~drrho/Parallel-MapReduce-0.09/lib/Parallel/MapReduce.pm

El 3 de diciembre de 2014, 6:25, Alex Muntada <alexm en caliu.cat> escribió:

> Para más inri está escrito en python, casi parece una broma...
>
> Lo de que sea más rápido en java parece ser por el modo de ejecución de
> hadoop para lenguajes no java.
>
> Un saludo,
> Alex
>
> _______________________________________________
> Madrid-pm mailing list
> Madrid-pm en pm.org
> http://mail.pm.org/mailman/listinfo/madrid-pm
>



-- 
JJ
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://mail.pm.org/pipermail/madrid-pm/attachments/20141203/e1263794/attachment.html>

From roberto en freekeylabs.com  Wed Dec  3 00:12:58 2014
From: roberto en freekeylabs.com (Roberto Henriquez)
Date: Wed, 03 Dec 2014 09:12:58 +0100
Subject: [Madrid-pm] Nueva herramienta para procesar la ingente cantidad
 de textos de la web
In-Reply-To: <CAGQ+uboFAy-4uaLraDauxC1cTgDrL9ykoMTozinqn-LSL8aiQw@mail.gmail.com>
References: <547E43BF.3080909@joaquinferrero.com>
	<CAGQ+uboFAy-4uaLraDauxC1cTgDrL9ykoMTozinqn-LSL8aiQw@mail.gmail.com>
Message-ID: <547EC60A.7030005@freekeylabs.com>

On 12/03/2014 06:25 AM, Alex Muntada wrote:
> Para más inri está escrito en python, casi parece una broma...
>
> Lo de que sea más rápido en java parece ser por el modo de ejecución de
> hadoop para lenguajes no java.
>

Eso es lo que yo entiendo, según el readme: «Even though Hadoop 
Streaming is a very useful tool, important degradations in the 
performance were detected using Hadoop Streaming with respect to Hadoop 
Java codes.»

Parece que el problema viene de algún overhead de Hadoop Streaming.

saludos!
-- 
Roberto Henríquez
roberto en freekeylabs.com

From explorer en joaquinferrero.com  Wed Dec  3 13:03:11 2014
From: explorer en joaquinferrero.com (Joaquin Ferrero)
Date: Wed, 03 Dec 2014 22:03:11 +0100
Subject: [Madrid-pm] Nueva herramienta para procesar la ingente cantidad
 de textos de la web
In-Reply-To: <547EC60A.7030005@freekeylabs.com>
References: <547E43BF.3080909@joaquinferrero.com>	<CAGQ+uboFAy-4uaLraDauxC1cTgDrL9ykoMTozinqn-LSL8aiQw@mail.gmail.com>
	<547EC60A.7030005@freekeylabs.com>
Message-ID: <547F7A8F.5010404@joaquinferrero.com>

El 03/12/14 a las 09:12, Roberto Henriquez escribió:
> On 12/03/2014 06:25 AM, Alex Muntada wrote:
>> Para más inri está escrito en python, casi parece una broma...
>>
>> Lo de que sea más rápido en java parece ser por el modo de ejecución de
>> hadoop para lenguajes no java.
>>
>
> Eso es lo que yo entiendo, según el readme: «Even though Hadoop Streaming is a very useful tool, important degradations in the performance were detected using Hadoop Streaming with respect to Hadoop Java codes.»
>
> Parece que el problema viene de algún overhead de Hadoop Streaming.
>
> saludos!

Estoy sospechando que el tema puede estar en el tiempo que Perl "pierde" en el proceso de compilación de los programas, antes de ejecutarlos, cosa que los de Java no tienen (se compilan una vez).

O algo peor... que estén usando un Perl v5.8.8 en Red Hat 2008-2010... entonces sí que queda claro: el intérprete de Perl tenía un bug en la reserva de memoria, que lo hacía mucho más lento de lo normal.

Es que, otra razón, no se me ocurre. Y eso que he visto cantidad de ejemplos en los que la ejecución de Perl es más rápida y con muchos menos recursos que Java, haciendo la misma tarea.


JF

From sfandino en yahoo.com  Wed Dec  3 13:49:59 2014
From: sfandino en yahoo.com (Salvador Fandino)
Date: Wed, 3 Dec 2014 21:49:59 +0000 (UTC)
Subject: [Madrid-pm] Nueva herramienta para procesar la ingente cantidad
 de textos de la web
In-Reply-To: <547F7A8F.5010404@joaquinferrero.com>
References: <547F7A8F.5010404@joaquinferrero.com>
Message-ID: <1923689285.4661392.1417643399180.JavaMail.yahoo@jws10671.mail.bf1.yahoo.com>





----- Original Message -----
> From: Joaquin Ferrero <explorer en joaquinferrero.com>
> To: madrid-pm en pm.org
> Cc: 
> Sent: Wednesday, December 3, 2014 10:03 PM
> Subject: Re: [Madrid-pm] Nueva herramienta para procesar la ingente cantidad de textos de la web
> 
> El 03/12/14 a las 09:12, Roberto Henriquez escribió:
>>  On 12/03/2014 06:25 AM, Alex Muntada wrote:
>>>  Para más inri está escrito en python, casi parece una broma...
>>> 
>>>  Lo de que sea más rápido en java parece ser por el modo de ejecución de
>>>  hadoop para lenguajes no java.
>>> 
>> 
>>  Eso es lo que yo entiendo, según el readme: «Even though Hadoop Streaming 
> is a very useful tool, important degradations in the performance were detected 
> using Hadoop Streaming with respect to Hadoop Java codes.»
>> 
>>  Parece que el problema viene de algún overhead de Hadoop Streaming.
>> 
>>  saludos!
> 
> Estoy sospechando que el tema puede estar en el tiempo que Perl 
> "pierde" en el proceso de compilación de los programas, antes de 
> ejecutarlos, cosa que los de Java no tienen (se compilan una vez).
> 
> O algo peor... que estén usando un Perl v5.8.8 en Red Hat 2008-2010... entonces 
> sí que queda claro: el intérprete de Perl tenía un bug en la reserva de memoria, 
> que lo hacía mucho más lento de lo normal.
> 
> Es que, otra razón, no se me ocurre. Y eso que he visto cantidad de ejemplos en 
> los que la ejecución de Perl es más rápida y con muchos menos recursos que Java, 
> haciendo la misma tarea.


Perl es un lenguaje interpretado, por un interprete diseñado hace mas de 20 años y que en esos 20 años la mayoría de los cambios que le han echo han sido chapuzas que no se adaptaban bien al diseño original (tie, prototipos, threads, overload, etc.) y que aunque no han tenido un gran impacto en el rendimiento si que han sido bloqueantes a la hora de mejorarlo.

Por el otro lado, cuando apareció Java hace también casi 20 años, el runtime, la JVM, era una porquería, pero en este tiempo lo han reescrito varias veces, aplicado todas las técnicas de optimización conocidas. El HotSpot actual que viene a ser un JIT que optimiza de forma dinámica los puntos calientes, es una pasada. Lo mismo pasa con los algoritmos de gestión de memoria, de lo mejorcito que hay (¡y en Perl seguimos contando referencias!). Hoy en día, el rendimiento en la JVM es similar al de programas en C o C++. Solo, en código de muy bajo nivel puede quedarse Java un poco atrás.


La cuestión es que si hubiese una definición del lenguaje o este fuese más simple, acabarían apareciendo nuevas implementaciones para otras tecnologías como ha pasado con Python (PyPy, IronPython, Jython) o con Ruby... pero como el lenguaje es lo que es, y la definición del lenguaje es la propia implementación en C del mismo, nadie ha tenido las pelotas o el conocimiento para hacerlo.

Perl de todas formas aun tiene sus puntos fuertes, al proveer al usuario de estructuras de datos y algoritmos (por ejemplo el motor de expresiones regulares) de alto nivel implementados en C muy optimizado, se evitan "cagadas" que en otros lenguajes de más bajo nivel programadores mediocres pueden cometer de forma más o menos frecuente. Por ejemplo, es fácil que una operación simple como push(@a) acabe teniendo un coste O(N) o incluso O(N^2) en vez de O(1) que es el óptimo y el que tiene en Perl.

Perl solia salir bien parado en cuestiones de rendimiento cuando se comparaba con otros lenguajes de scripting o dinamicos, hace tiempo que no investigo ese tema, pero de todas formas es una disculpa burda, Python esta diseñado para ser lento... y mirad como van ha día de hoy otros lenguajes en los que ha habido un esfuerzo por acelerarlos, como por ejemplo JavaScript (con técnicas inventadas la mayoría hace varias décadas, cuando el state-of-the-art era Smalltalk (como hemos atrasado!!!))

Pero recordad que lo bueno que tiene Perl es que es rápido a la hora de desarrollar!!

Fin del rant, os tengo que dejar que me reclama un demonio de 2 años que corre por mi casa...

From jjmerelo en gmail.com  Wed Dec  3 23:11:32 2014
From: jjmerelo en gmail.com (JJ Merelo)
Date: Thu, 4 Dec 2014 08:11:32 +0100
Subject: [Madrid-pm] Nueva herramienta para procesar la ingente cantidad
 de textos de la web
In-Reply-To: <547F7A8F.5010404@joaquinferrero.com>
References: <547E43BF.3080909@joaquinferrero.com>
	<CAGQ+uboFAy-4uaLraDauxC1cTgDrL9ykoMTozinqn-LSL8aiQw@mail.gmail.com>
	<547EC60A.7030005@freekeylabs.com>
	<547F7A8F.5010404@joaquinferrero.com>
Message-ID: <CAJoLtgfr_eVAvcPtZJwUp0tvut5JOnDUbE8Gp5xw+mj-6cwNCg@mail.gmail.com>

Bueno, en expresiones regulares al menos lo es. En proceso de cadenas,
depende. Y en el resto, "your mileage may vary". Aquí, por ejemplo
http://scholar.google.com/citations?view_op=view_citation&hl=es&user=gFxqc64AAAAJ&cstart=20&citation_for_view=gFxqc64AAAAJ:LI9QrySNdTsC
la velocidad de Perl era, si mal no recuerdo, del orden de magnitud de la
de una librería equivalente en Java, pero no la alcanzaba. De hecho, el
autor de la otra librería cambió dos o tres cosas en la JVM y me dio un
felpón.

JJ
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://mail.pm.org/pipermail/madrid-pm/attachments/20141204/369283ec/attachment.html>

From sfandino en yahoo.com  Thu Dec  4 02:05:24 2014
From: sfandino en yahoo.com (Salvador Fandino)
Date: Thu, 4 Dec 2014 10:05:24 +0000 (UTC)
Subject: [Madrid-pm] Nueva herramienta para procesar la ingente cantidad
 de textos de la web
In-Reply-To: <CAJoLtgfr_eVAvcPtZJwUp0tvut5JOnDUbE8Gp5xw+mj-6cwNCg@mail.gmail.com>
References: <CAJoLtgfr_eVAvcPtZJwUp0tvut5JOnDUbE8Gp5xw+mj-6cwNCg@mail.gmail.com>
Message-ID: <1938893435.4900359.1417687525024.JavaMail.yahoo@jws106150.mail.bf1.yahoo.com>





>________________________________
> From: JJ Merelo <jjmerelo en gmail.com>
>To: Lista de correo de Madrid Perl Mongers <madrid-pm en pm.org> 
>Sent: Thursday, December 4, 2014 8:11 AM
>Subject: Re: [Madrid-pm] Nueva herramienta para procesar la ingente cantidad de textos de la web
> 
>
>

>Bueno, en expresiones regulares al menos lo es.

Depende. Las expresiones regulares son un mundo en si mismo. Algunas cosas en Perl son muy rápidas, otras no tanto.

El motor de Perl en teoría usa algoritmos que dejan mucho que desear (para poder dar ciertas funcionalidades), y es posible escribir expresiones regulares que resultan en programas con complejidad NP.

Afortunadamente, en la practica lo que se usan son expresiones regulares sencillas que hacen poco uso del backtracking y por eso el rendimiento suele ser muy bueno, porque la implementación si esta micro-optimizado al límite. Tambien, desde hace algunas versiones, es posible usar en Perl motores de expresiones regulares alternativos.


Por otro lado esta el caso de Java que viene con su propia librería de expresiones regulares, similar a la de Perl, y que tendrá su rendimiento. Pero además de la que viene por defecto, en Java hay muchas más librerías. Algunas escritas en C que son cuando menos tan rápidas como la de Perl, otras que usan motores determinitas con complejidad lineal garantizada, etc.


Al final de lo que se trata es de que A no es mejor que B, si no que en algunos casos A es mucho mejor, en otros es B y en otros hay un C que les da mil vueltas a ambos.


>En proceso de cadenas, depende.

Nope, nope. En Java, si sabes como hacerlo, el proceso de cadenas es más rápido que en Perl. El problema es que es fácil (y más cómodo) hacerlo mal.


>Y en el resto, "your mileage may vary". Aquí, por ejemplo http://scholar.google.com/citations?view_op=view_citation&hl=es&user=gFxqc64AAAAJ&cstart=20&citation_for_view=gFxqc64AAAAJ:LI9QrySNdTsC la velocidad de Perl era, si mal no recuerdo, del orden de magnitud de la de una librería equivalente en Java, pero no la alcanzaba. De hecho, el autor de la otra librería cambió dos o tres cosas en la JVM y me dio un felpón. 

En el fondo esto del rendimiento es una cuestión de concepto: si tu coges a dos tíos que sean unos máquinas en temas de rendimiento en Perl y en Java respectivamente y los pones a resolver el problema, en general y salvo que sea algo muy especifico que en Perl se pueda resolver llamando a un par de built-ins, lo normal es que la solución en Java sea al menos un orden de magnitud más rápida que la de Perl.

Luego esta la otra forma de evaluar el rendimiento: si tu pones a dos tíos con un conocimiento intermedio de Perl y Java, a resolver el mismo problema, entonces lo que obtengas probablemente si sea el "your mileage may vary".

Es lo que comentaba en el correo anterior, Perl es un lenguaje de más alto nivel y te da un conjunto de estructuras de datos (como las cadenas y los arrays) y unos algoritmos que operan sobre ellos de manera optima y rápida al estar implementados en C. En Java en cambio, lo que tienes son unas primitivas de bajo nivel y encima de ellas tu puedes implementar los algoritmos que quieras, es responsabilidad del programador que sean los óptimos. También es cierto que en algunos casos, como cuando se usan Strings Java parece que te invita a utilizar los no-optimos.

From explorer en joaquinferrero.com  Thu Dec  4 04:23:41 2014
From: explorer en joaquinferrero.com (Joaquin Ferrero)
Date: Thu, 04 Dec 2014 13:23:41 +0100
Subject: [Madrid-pm] Fwd: Re: Nueva herramienta para procesar la ingente
 cantidad de textos de la web
In-Reply-To: <1923689285.4661392.1417643399180.JavaMail.yahoo@jws10671.mail.bf1.yahoo.com>
References: <1923689285.4661392.1417643399180.JavaMail.yahoo@jws10671.mail.bf1.yahoo.com>
Message-ID: <5480524D.9060409@joaquinferrero.com>

Reenvío el correo de Salva, porque me dicen que no les llega a algunos listeros


-------- Mensaje reenviado --------



----- Original Message -----
> From: Joaquin Ferrero <explorer en joaquinferrero.com>
> To: madrid-pm en pm.org
> Cc:
> Sent: Wednesday, December 3, 2014 10:03 PM
> Subject: Re: [Madrid-pm] Nueva herramienta para procesar la ingente cantidad de textos de la web
>
> El 03/12/14 a las 09:12, Roberto Henriquez escribió:
>>  On 12/03/2014 06:25 AM, Alex Muntada wrote:
>>>  Para más inri está escrito en python, casi parece una broma...
>>>
>>>  Lo de que sea más rápido en java parece ser por el modo de ejecución de
>>>  hadoop para lenguajes no java.
>>>
>>
>>  Eso es lo que yo entiendo, según el readme: «Even though Hadoop Streaming
> is a very useful tool, important degradations in the performance were detected
> using Hadoop Streaming with respect to Hadoop Java codes.»
>>
>>  Parece que el problema viene de algún overhead de Hadoop Streaming.
>>
>>  saludos!
>
> Estoy sospechando que el tema puede estar en el tiempo que Perl
> "pierde" en el proceso de compilación de los programas, antes de
> ejecutarlos, cosa que los de Java no tienen (se compilan una vez).
>
> O algo peor... que estén usando un Perl v5.8.8 en Red Hat 2008-2010... entonces
> sí que queda claro: el intérprete de Perl tenía un bug en la reserva de memoria,
> que lo hacía mucho más lento de lo normal.
>
> Es que, otra razón, no se me ocurre. Y eso que he visto cantidad de ejemplos en
> los que la ejecución de Perl es más rápida y con muchos menos recursos que Java,
> haciendo la misma tarea.


Perl es un lenguaje interpretado, por un interprete diseñado hace mas de 20 años y que en esos 20 años la mayoría de los cambios que le han echo han sido chapuzas que no se adaptaban bien al diseño original (tie, prototipos, threads, overload, etc.) y que aunque no han tenido un gran impacto en el rendimiento si que han sido bloqueantes a la hora de mejorarlo.

Por el otro lado, cuando apareció Java hace también casi 20 años, el runtime, la JVM, era una porquería, pero en este tiempo lo han reescrito varias veces, aplicado todas las técnicas de optimización conocidas. El HotSpot actual que viene a ser un JIT que optimiza de forma dinámica los puntos calientes, es una pasada. Lo mismo pasa con los algoritmos de gestión de memoria, de lo mejorcito que hay (¡y en Perl seguimos contando referencias!). Hoy en día, el rendimiento en la JVM es similar al de programas en C o C++. Solo, en código de muy bajo nivel puede quedarse Java un poco atrás.


La cuestión es que si hubiese una definición del lenguaje o este fuese más simple, acabarían apareciendo nuevas implementaciones para otras tecnologías como ha pasado con Python (PyPy, IronPython, Jython) o con Ruby... pero como el lenguaje es lo que es, y la definición del lenguaje es la propia implementación en C del mismo, nadie ha tenido las pelotas o el conocimiento para hacerlo.

Perl de todas formas aun tiene sus puntos fuertes, al proveer al usuario de estructuras de datos y algoritmos (por ejemplo el motor de expresiones regulares) de alto nivel implementados en C muy optimizado, se evitan "cagadas" que en otros lenguajes de más bajo nivel programadores mediocres pueden cometer de forma más o menos frecuente. Por ejemplo, es fácil que una operación simple como push(@a) acabe teniendo un coste O(N) o incluso O(N^2) en vez de O(1) que es el óptimo y el que tiene en Perl.

Perl solia salir bien parado en cuestiones de rendimiento cuando se comparaba con otros lenguajes de scripting o dinamicos, hace tiempo que no investigo ese tema, pero de todas formas es una disculpa burda, Python esta diseñado para ser lento... y mirad como van ha día de hoy otros lenguajes en los que ha habido un esfuerzo por acelerarlos, como por ejemplo JavaScript (con técnicas inventadas la mayoría hace varias décadas, cuando el state-of-the-art era Smalltalk (como hemos atrasado!!!))

Pero recordad que lo bueno que tiene Perl es que es rápido a la hora de desarrollar!!

Fin del rant, os tengo que dejar que me reclama un demonio de 2 años que corre por mi casa...
_______________________________________________
Madrid-pm mailing list
Madrid-pm en pm.org
http://mail.pm.org/mailman/listinfo/madrid-pm




From explorer en joaquinferrero.com  Thu Dec  4 04:24:27 2014
From: explorer en joaquinferrero.com (Joaquin Ferrero)
Date: Thu, 04 Dec 2014 13:24:27 +0100
Subject: [Madrid-pm] Fwd: Re: Nueva herramienta para procesar la ingente
 cantidad de textos de la web
In-Reply-To: <1938893435.4900359.1417687525024.JavaMail.yahoo@jws106150.mail.bf1.yahoo.com>
References: <1938893435.4900359.1417687525024.JavaMail.yahoo@jws106150.mail.bf1.yahoo.com>
Message-ID: <5480527B.7070709@joaquinferrero.com>

Otro mensaje de Salva, reenviado.


-------- Mensaje reenviado --------



>________________________________
> From: JJ Merelo <jjmerelo en gmail.com>
>To: Lista de correo de Madrid Perl Mongers <madrid-pm en pm.org>
>Sent: Thursday, December 4, 2014 8:11 AM
>Subject: Re: [Madrid-pm] Nueva herramienta para procesar la ingente cantidad de textos de la web
>
>
>

>Bueno, en expresiones regulares al menos lo es.

Depende. Las expresiones regulares son un mundo en si mismo. Algunas cosas en Perl son muy rápidas, otras no tanto.

El motor de Perl en teoría usa algoritmos que dejan mucho que desear (para poder dar ciertas funcionalidades), y es posible escribir expresiones regulares que resultan en programas con complejidad NP.

Afortunadamente, en la practica lo que se usan son expresiones regulares sencillas que hacen poco uso del backtracking y por eso el rendimiento suele ser muy bueno, porque la implementación si esta micro-optimizado al límite. Tambien, desde hace algunas versiones, es posible usar en Perl motores de expresiones regulares alternativos.


Por otro lado esta el caso de Java que viene con su propia librería de expresiones regulares, similar a la de Perl, y que tendrá su rendimiento. Pero además de la que viene por defecto, en Java hay muchas más librerías. Algunas escritas en C que son cuando menos tan rápidas como la de Perl, otras que usan motores determinitas con complejidad lineal garantizada, etc.


Al final de lo que se trata es de que A no es mejor que B, si no que en algunos casos A es mucho mejor, en otros es B y en otros hay un C que les da mil vueltas a ambos.


>En proceso de cadenas, depende.

Nope, nope. En Java, si sabes como hacerlo, el proceso de cadenas es más rápido que en Perl. El problema es que es fácil (y más cómodo) hacerlo mal.


>Y en el resto, "your mileage may vary". Aquí, por ejemplo http://scholar.google.com/citations?view_op=view_citation&hl=es&user=gFxqc64AAAAJ&cstart=20&citation_for_view=gFxqc64AAAAJ:LI9QrySNdTsC la velocidad de Perl era, si mal no recuerdo, del orden de magnitud de la de una librería equivalente en Java, pero no la alcanzaba. De hecho, el autor de la otra librería cambió dos o tres cosas en la JVM y me dio un felpón.

En el fondo esto del rendimiento es una cuestión de concepto: si tu coges a dos tíos que sean unos máquinas en temas de rendimiento en Perl y en Java respectivamente y los pones a resolver el problema, en general y salvo que sea algo muy especifico que en Perl se pueda resolver llamando a un par de built-ins, lo normal es que la solución en Java sea al menos un orden de magnitud más rápida que la de Perl.

Luego esta la otra forma de evaluar el rendimiento: si tu pones a dos tíos con un conocimiento intermedio de Perl y Java, a resolver el mismo problema, entonces lo que obtengas probablemente si sea el "your mileage may vary".

Es lo que comentaba en el correo anterior, Perl es un lenguaje de más alto nivel y te da un conjunto de estructuras de datos (como las cadenas y los arrays) y unos algoritmos que operan sobre ellos de manera optima y rápida al estar implementados en C. En Java en cambio, lo que tienes son unas primitivas de bajo nivel y encima de ellas tu puedes implementar los algoritmos que quieras, es responsabilidad del programador que sean los óptimos. También es cierto que en algunos casos, como cuando se usan Strings Java parece que te invita a utilizar los no-optimos.
_______________________________________________
Madrid-pm mailing list
Madrid-pm en pm.org
http://mail.pm.org/mailman/listinfo/madrid-pm




From sfandino en gmail.com  Thu Dec  4 06:15:38 2014
From: sfandino en gmail.com (Salvador Fandino)
Date: Thu, 04 Dec 2014 15:15:38 +0100
Subject: [Madrid-pm] Nueva herramienta para procesar la ingente cantidad
 de textos de la web
In-Reply-To: <1938893435.4900359.1417687525024.JavaMail.yahoo@jws106150.mail.bf1.yahoo.com>
References: <CAJoLtgfr_eVAvcPtZJwUp0tvut5JOnDUbE8Gp5xw+mj-6cwNCg@mail.gmail.com>
	<1938893435.4900359.1417687525024.JavaMail.yahoo@jws106150.mail.bf1.yahoo.com>
Message-ID: <54806C8A.9030500@gmail.com>

On 12/04/2014 11:05 AM, Salvador Fandino wrote:
>
>
>
>
>> ________________________________
>> From: JJ Merelo <jjmerelo en gmail.com>
>> To: Lista de correo de Madrid Perl Mongers <madrid-pm en pm.org>
>> Sent: Thursday, December 4, 2014 8:11 AM
>> Subject: Re: [Madrid-pm] Nueva herramienta para procesar la ingente cantidad de textos de la web
>>
>>
>>
>
>> Bueno, en expresiones regulares al menos lo es.
>
> Depende. Las expresiones regulares son un mundo en si mismo. Algunas cosas en Perl son muy rápidas, otras no tanto.
>
> El motor de Perl en teoría usa algoritmos que dejan mucho que desear (para poder dar ciertas funcionalidades), y es posible escribir expresiones regulares que resultan en programas con complejidad NP.
>
> Afortunadamente, en la practica lo que se usan son expresiones regulares sencillas que hacen poco uso del backtracking y por eso el rendimiento suele ser muy bueno, porque la implementación si esta micro-optimizado al límite. Tambien, desde hace algunas versiones, es posible usar en Perl motores de expresiones regulares alternativos.

Y lo que digo es irrefutablemente cierto, porque el tercer o cuarto 
enlace que aparece en Google al hacer una búsqueda que ya no recuerdo, 
lleva a un documento escrito por un tío que no conozco que dice lo mismo:

http://swtch.com/~rsc/regexp/regexp1.html

PD: a ver si desde mi direccion de gmail va mejor la cosa...


From jjmerelo en gmail.com  Thu Dec  4 22:30:36 2014
From: jjmerelo en gmail.com (JJ Merelo)
Date: Fri, 5 Dec 2014 07:30:36 +0100
Subject: [Madrid-pm] Nueva herramienta para procesar la ingente cantidad
 de textos de la web
In-Reply-To: <54806C8A.9030500@gmail.com>
References: <CAJoLtgfr_eVAvcPtZJwUp0tvut5JOnDUbE8Gp5xw+mj-6cwNCg@mail.gmail.com>
	<1938893435.4900359.1417687525024.JavaMail.yahoo@jws106150.mail.bf1.yahoo.com>
	<54806C8A.9030500@gmail.com>
Message-ID: <CAJoLtgcymMtZjZCs5ON9Mg6JJmOXfbbHkVsPzu_5XtDS+dop=Q@mail.gmail.com>

Este último sí lo he recibido.

El 4 de diciembre de 2014, 15:15, Salvador Fandino <sfandino en gmail.com>
escribió:

> On 12/04/2014 11:05 AM, Salvador Fandino wrote:
>
>>
>>
>>
>>
>>  ________________________________
>>> From: JJ Merelo <jjmerelo en gmail.com>
>>> To: Lista de correo de Madrid Perl Mongers <madrid-pm en pm.org>
>>> Sent: Thursday, December 4, 2014 8:11 AM
>>> Subject: Re: [Madrid-pm] Nueva herramienta para procesar la ingente
>>> cantidad de textos de la web
>>>
>>>
>>>
>>>
>>  Bueno, en expresiones regulares al menos lo es.
>>>
>>
>> Depende. Las expresiones regulares son un mundo en si mismo. Algunas
>> cosas en Perl son muy rápidas, otras no tanto.
>>
>> El motor de Perl en teoría usa algoritmos que dejan mucho que desear
>> (para poder dar ciertas funcionalidades), y es posible escribir expresiones
>> regulares que resultan en programas con complejidad NP.
>>
>> Afortunadamente, en la practica lo que se usan son expresiones regulares
>> sencillas que hacen poco uso del backtracking y por eso el rendimiento
>> suele ser muy bueno, porque la implementación si esta micro-optimizado al
>> límite. Tambien, desde hace algunas versiones, es posible usar en Perl
>> motores de expresiones regulares alternativos.
>>
>
> Y lo que digo es irrefutablemente cierto, porque el tercer o cuarto enlace
> que aparece en Google al hacer una búsqueda que ya no recuerdo, lleva a un
> documento escrito por un tío que no conozco que dice lo mismo:
>
> http://swtch.com/~rsc/regexp/regexp1.html
>
> PD: a ver si desde mi direccion de gmail va mejor la cosa...
>
>
> _______________________________________________
> Madrid-pm mailing list
> Madrid-pm en pm.org
> http://mail.pm.org/mailman/listinfo/madrid-pm
>



-- 
JJ
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://mail.pm.org/pipermail/madrid-pm/attachments/20141205/78222f51/attachment.html>