[OT] sobre un "segundo" lenguaje...

[Alejandro Zamora Fonseca]

Hola a todos:
espero que no ser demasiado "hereje" con lo que voy a preguntar...

Comienzo.
Todos sabemos de las muchísimas virtudes de python como lenguaje y
tecnología pero también de su problema con la eficiencia(aunque sé hay
varias opciones para acelerarlo un poco).

Entonces estoy metido en un projecto donde hace falta bastante
eficiencia y casi que estoy obligado a no usar python, entonces bueno...
sé que hay muchísimas opciones... pero tiene que ser un lenguaje con
implementaciones muy eficientes...
Pero el kid de la cuestión es que no quiero perder la riquez en
expresividad de Python y por tanto no quiero usar ninguno de los
"mainstreams languages(C/C++/Java)" que realmente ya me desagradan por
su sintaxis a pesar de todas sus IDEs y demás ventajas.
Quiero un lenguaje que sea bastante eficiente(me refiero por supuesto a
uso de memoria y rapidez de ejecución) pero quiero quiero que sea
tambien bastante expresivo como python, ahh!! y multiparadigma, por lo
que por ahí desecho otro grupo de lenguajes importantes...
Entonces he pensado en LISP(específicamente Common Lisp) para mi
proyecyto¿qué creen?

Saludos ..

Alejandro




--

Este mensaje le ha llegado mediante el servicio de correo electronico que ofrece Infomed para respaldar el cumplimiento de las misiones del Sistema Nacional de Salud. La persona que envia este correo asume el compromiso de usar el servicio a tales fines y cumplir con las regulaciones establecidas

Infomed: http://www.sld.cu/

_______________________________________________
pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
http://listas.python.org.ar/listinfo/pyar

PyAr - Python Argentina - Sitio web: http://www.python.org.ar/

La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de Argentina - http://www.usla.org.ar

[Angel Java Lopez]

Si van a ver Lisp, vean Clojure. Es dinamico, compila a Java por abajo (hay
version para .NET CLR), con lo que es eficiente, compila opcionalmente a
JavaScript, y podes aprovechar el ecosistema Java. Hasta supongo, solo
supongo, que podes llegar a usar algo de Jython. Un purista de Lisp le
encontraria "peros", pero como nombran eficiencia como un objetivo, tal vez
este sea el paso a seguir.

Pero personalmente, iria por JavaScript con V8/Node.js primero, a ver si el
tema eficiencia de ahi les satisface o no.

- Es expresivo (yo diria mas que Python)
- Es dinamico
- Poca ceremonia
- La engine V8 esta muy "afiatada"
- Es ubicuo (poca friccion multiplataforma)
- Ecosistema de paquetes vibrante
- El manejador de paquetes que tiene es de lo mejorcito que vi hasta ahora
- Las funciones son ciudadanos de primera clase
- El module pattern es muy bueno para ir armando sistemas, es el "ladrillo"
que faltaba (escribir todo en un archivo, y exponer solo lo que se quiere
exponer para afuera)(todos los quirks de JavaScript pueden esconderse en un
modulo)
- Hay varias librerias para soporte de TDD
- Y hay (perdon lo sexista, pero es la mejor expresion que encuentro por
estos lares) "programacion macho" es decir, pelas el editor y programas, ya
esta
- Me gusta ... .jejeje... se nota? ;-)

Pero no se cuales son los requerimientos de "eficiencia".

Volviendo a Python, cuando hizo falta eficiencia se puede llamar a C. NumPy
es un ejemplo paradigmatico. No necesariamente hay que abandonar Python

Ahora, si es eficiencia por sacarse el GIL de encima, sin tener experiencia
personal, vi que hay gente que lanza sus aplicaciones en Jython.

Y dejenme dejar un consejo de tipo "el diablo sabe por diablo, pero mas
sabe por viejo" (es decir, de alguien como yo que esta mas cerca del arpa
que de la guitarra ;-). Por el tema de eficiencia, siempre medir. No
dejarse llevar por "esto asi corre mas rapido". Medir, medir, medir. Y ver
que la eficiencia realmente agregue valor al negocio (he visto a gente
optimizando varios ordenes la eficiencia de algo ... que se ejecuta una vez
CADA SEIS MESES ;-)

Nos leemos!

Angel "Java" Lopez
@ajlopez





2014-02-06 13:47 GMT-03:00 Alejandro Zamora Fonseca <terefv-pNGfD4lFfPfph/***@public.gmane.org>:

> Hola a todos:
> espero que no ser demasiado "hereje" con lo que voy a preguntar...
>
> Comienzo.
> Todos sabemos de las muchísimas virtudes de python como lenguaje y
> tecnología pero también de su problema con la eficiencia(aunque sé hay
> varias opciones para acelerarlo un poco).
>
> Entonces estoy metido en un projecto donde hace falta bastante eficiencia
> y casi que estoy obligado a no usar python, entonces bueno... sé que hay
> muchísimas opciones... pero tiene que ser un lenguaje con implementaciones
> muy eficientes...
> Pero el kid de la cuestión es que no quiero perder la riquez en
> expresividad de Python y por tanto no quiero usar ninguno de los
> "mainstreams languages(C/C++/Java)" que realmente ya me desagradan por su
> sintaxis a pesar de todas sus IDEs y demás ventajas.
> Quiero un lenguaje que sea bastante eficiente(me refiero por supuesto a
> uso de memoria y rapidez de ejecución) pero quiero quiero que sea tambien
> bastante expresivo como python, ahh!! y multiparadigma, por lo que por ahí
> desecho otro grupo de lenguajes importantes...
> Entonces he pensado en LISP(específicamente Common Lisp) para mi
> proyecyto¿qué creen?
>
> Saludos ..
>
> Alejandro
>
>
>
>
> --
>
> Este mensaje le ha llegado mediante el servicio de correo electronico que
> ofrece Infomed para respaldar el cumplimiento de las misiones del Sistema
> Nacional de Salud. La persona que envia este correo asume el compromiso de
> usar el servicio a tales fines y cumplir con las regulaciones establecidas
>
> Infomed: http://www.sld.cu/
>
> _______________________________________________
> pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar
>

[Ariel Gerardo Ríos]

Hola :)

Preguntando al amigo Google encontré ésto: http://cython.org/ Python
que compila a código C/C++. Según su
overview<http://docs.cython.org/src/quickstart/overview.html>
:

*"The source code gets translated into optimized C/C++ code and compiled as
Python extension modules. This allows for both very fast program execution
and tight integration with external C libraries, while keeping up the high
programmer productivity for which the Python language is well known."*

Personalmente no tengo experiencia en otras implementaciones de Python,
por lo que mi contribución llega hasta acá. Espero te sea útil y nos
cuentes qué encontraste como solución :)

Saludos.



2014-02-06 Alejandro Zamora Fonseca <terefv-pNGfD4lFfPfph/***@public.gmane.org>:

> Hola a todos:
> espero que no ser demasiado "hereje" con lo que voy a preguntar...
>
> Comienzo.
> Todos sabemos de las muchísimas virtudes de python como lenguaje y
> tecnología pero también de su problema con la eficiencia(aunque sé hay
> varias opciones para acelerarlo un poco).
>
> Entonces estoy metido en un projecto donde hace falta bastante eficiencia
> y casi que estoy obligado a no usar python, entonces bueno... sé que hay
> muchísimas opciones... pero tiene que ser un lenguaje con implementaciones
> muy eficientes...
> Pero el kid de la cuestión es que no quiero perder la riquez en
> expresividad de Python y por tanto no quiero usar ninguno de los
> "mainstreams languages(C/C++/Java)" que realmente ya me desagradan por su
> sintaxis a pesar de todas sus IDEs y demás ventajas.
> Quiero un lenguaje que sea bastante eficiente(me refiero por supuesto a
> uso de memoria y rapidez de ejecución) pero quiero quiero que sea tambien
> bastante expresivo como python, ahh!! y multiparadigma, por lo que por ahí
> desecho otro grupo de lenguajes importantes...
> Entonces he pensado en LISP(específicamente Common Lisp) para mi
> proyecyto¿qué creen?
>
> Saludos ..
>
> Alejandro
>
>
>
>
> --
>
> Este mensaje le ha llegado mediante el servicio de correo electronico que
> ofrece Infomed para respaldar el cumplimiento de las misiones del Sistema
> Nacional de Salud. La persona que envia este correo asume el compromiso de
> usar el servicio a tales fines y cumplir con las regulaciones establecidas
>
> Infomed: http://www.sld.cu/
>
> _______________________________________________
> pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar
>



--
Ariel Gerardo Ríos
linkedin <http://www.linkedin.com/pub/ariel-gerardo-rios/33/158/227> |
twitter <https://twitter.com/ariel_17_>

[Angel Java Lopez]

Ah! Parece lindo Cython, gracias por el enlace

Si la idea es "quedarse en Python", el otro camino es RPython, un python
reducido que compila a C, parte de PyPy

http://doc.pypy.org/en/latest/translation.html

Hay que cumplir con algunas restricciones, pero dependiendo del proyecto a
encarar, podria no ser problema.

Jeje... yo tambien quiero divertirme, mini mini pet project, compilando
Python a C, ya me funciona
https://github.com/ajlopez/RedPython/blob/master/samples/simple/primes.py

Nos leemos!

Angel "Java" Lopez
@ajlopez




2014-02-06 13:51 GMT-03:00 Ariel Gerardo Ríos <arielgerardorios-***@public.gmane.org>:

> Hola :)
>
> Preguntando al amigo Google encontré ésto: http://cython.org/ Python
> que compila a código C/C++. Según su overview<http://docs.cython.org/src/quickstart/overview.html>
> :
>
> *"The source code gets translated into optimized C/C++ code and compiled
> as Python extension modules. This allows for both very fast program
> execution and tight integration with external C libraries, while keeping up
> the high programmer productivity for which the Python language is well
> known."*
>
> Personalmente no tengo experiencia en otras implementaciones de
> Python, por lo que mi contribución llega hasta acá. Espero te sea útil y
> nos cuentes qué encontraste como solución :)
>
> Saludos.
>
>
>
> 2014-02-06 Alejandro Zamora Fonseca <terefv-pNGfD4lFfPfph/***@public.gmane.org>:
>
> Hola a todos:
>> espero que no ser demasiado "hereje" con lo que voy a preguntar...
>>
>> Comienzo.
>> Todos sabemos de las muchísimas virtudes de python como lenguaje y
>> tecnología pero también de su problema con la eficiencia(aunque sé hay
>> varias opciones para acelerarlo un poco).
>>
>> Entonces estoy metido en un projecto donde hace falta bastante eficiencia
>> y casi que estoy obligado a no usar python, entonces bueno... sé que hay
>> muchísimas opciones... pero tiene que ser un lenguaje con implementaciones
>> muy eficientes...
>> Pero el kid de la cuestión es que no quiero perder la riquez en
>> expresividad de Python y por tanto no quiero usar ninguno de los
>> "mainstreams languages(C/C++/Java)" que realmente ya me desagradan por su
>> sintaxis a pesar de todas sus IDEs y demás ventajas.
>> Quiero un lenguaje que sea bastante eficiente(me refiero por supuesto a
>> uso de memoria y rapidez de ejecución) pero quiero quiero que sea tambien
>> bastante expresivo como python, ahh!! y multiparadigma, por lo que por ahí
>> desecho otro grupo de lenguajes importantes...
>> Entonces he pensado en LISP(específicamente Common Lisp) para mi
>> proyecyto¿qué creen?
>>
>> Saludos ..
>>
>> Alejandro
>>
>>
>>
>>
>> --
>>
>> Este mensaje le ha llegado mediante el servicio de correo electronico que
>> ofrece Infomed para respaldar el cumplimiento de las misiones del Sistema
>> Nacional de Salud. La persona que envia este correo asume el compromiso de
>> usar el servicio a tales fines y cumplir con las regulaciones establecidas
>>
>> Infomed: http://www.sld.cu/
>>
>> _______________________________________________
>> pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
>> http://listas.python.org.ar/listinfo/pyar
>>
>> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>>
>> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
>> Argentina - http://www.usla.org.ar
>>
>
>
>
> --
> Ariel Gerardo Ríos
> linkedin <http://www.linkedin.com/pub/ariel-gerardo-rios/33/158/227> |
> twitter <https://twitter.com/ariel_17_>
>
> _______________________________________________
> pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar
>

[Claudio Freire]

2014-02-06 13:47 GMT-03:00 Alejandro Zamora Fonseca <terefv-pNGfD4lFfPfph/***@public.gmane.org>:
> Comienzo.
> Todos sabemos de las muchísimas virtudes de python como lenguaje y
> tecnología pero también de su problema con la eficiencia(aunque sé hay
> varias opciones para acelerarlo un poco).
>
> Entonces estoy metido en un projecto donde hace falta bastante eficiencia y
> casi que estoy obligado a no usar python, entonces bueno... sé que hay
> muchísimas opciones... pero tiene que ser un lenguaje con implementaciones
> muy eficientes...
> Pero el kid de la cuestión es que no quiero perder la riquez en expresividad
> de Python y por tanto no quiero usar ninguno de los "mainstreams
> languages(C/C++/Java)" que realmente ya me desagradan por su sintaxis a
> pesar de todas sus IDEs y demás ventajas.
> Quiero un lenguaje que sea bastante eficiente(me refiero por supuesto a uso
> de memoria y rapidez de ejecución) pero quiero quiero que sea tambien
> bastante expresivo como python, ahh!! y multiparadigma, por lo que por ahí
> desecho otro grupo de lenguajes importantes...


Probaste PyPy?

Las últimas versiones tienen pseudotipos, que aunque su nombre *no* lo
indica, ahorra mucha memoria comparado con CPython. De hecho, hace que
todas las estructuras (clases simples) que implementes en Python
terminen ocupando lo que ocupan en C (maso - con algo de overhead -
pero cosa que es muy impresionante si me preguntás).

El ejemplo es PyPy para traducir PyPy (traducir = compilar).
Haciéndolo con CPython usa como el doble de RAM que con PyPy (y tarda
un montón más también).

Honestamente, incluso si PyPy no fuera suficiente, te seguiría
recomendando Python. Tengo mucha experiencia con Python, C++, y Java,
y de todos los lenguajes, incluso cuando necesito ultra-performance,
elijo Python. ¿Por qué? Pues porque es tremendamente sencillo tomar un
módulo o función python que es un cuello de botella, y sólo eso
transformarlo en C++ y tener lo mejor de ambos mundos. Es la
anti-epítome de la optimización prematura. Es lo ideal.
_______________________________________________
pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
http://listas.python.org.ar/listinfo/pyar

PyAr - Python Argentina - Sitio web: http://www.python.org.ar/

La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de Argentina - http://www.usla.org.ar

[Alejandro Zamora Fonseca]

Muchas gracias a todos,
es verdad que tengo que profundizar en las últimas implementaciones de
Python para ver hasta que punto mejoran la eficiencia, pero lo que si no
quiero es tocar nada del grupito C/C++/Java, no porque no lo haya hecho
antes(sobre todo en C/C++ o Java) sino porque quiero hacerlo todo o casi
todo en un lenguaje como Python .
Así que por eso no quiero, a priori, usar ctypes ni nada parecido.
Así que por eso trataré de encontrar una imp. de Python así en PyPy
pero si no tendré que buscar un nuevo lenguaje, por eso hablaba de Lisp.

gracias de nuevo

El 2014-02-06 18:00, Claudio Freire escribió:
> 2014-02-06 13:47 GMT-03:00 Alejandro Zamora Fonseca
> <terefv-pNGfD4lFfPfph/***@public.gmane.org>:
>> Comienzo.
>> Todos sabemos de las muchísimas virtudes de python como lenguaje y
>> tecnología pero también de su problema con la eficiencia(aunque sé
>> hay
>> varias opciones para acelerarlo un poco).
>>
>> Entonces estoy metido en un projecto donde hace falta bastante
>> eficiencia y
>> casi que estoy obligado a no usar python, entonces bueno... sé que
>> hay
>> muchísimas opciones... pero tiene que ser un lenguaje con
>> implementaciones
>> muy eficientes...
>> Pero el kid de la cuestión es que no quiero perder la riquez en
>> expresividad
>> de Python y por tanto no quiero usar ninguno de los "mainstreams
>> languages(C/C++/Java)" que realmente ya me desagradan por su sintaxis
>> a
>> pesar de todas sus IDEs y demás ventajas.
>> Quiero un lenguaje que sea bastante eficiente(me refiero por supuesto
>> a uso
>> de memoria y rapidez de ejecución) pero quiero que sea tambien
>> bastante expresivo como python, ahh!! y multiparadigma, por lo que
>> por ahí
>> desecho otro grupo de lenguajes importantes...
>
>
> Probaste PyPy?
>
> Las últimas versiones tienen pseudotipos, que aunque su nombre *no* lo
> indica, ahorra mucha memoria comparado con CPython. De hecho, hace que
> todas las estructuras (clases simples) que implementes en Python
> terminen ocupando lo que ocupan en C (maso - con algo de overhead -
> pero cosa que es muy impresionante si me preguntás).
>
> El ejemplo es PyPy para traducir PyPy (traducir = compilar).
> Haciéndolo con CPython usa como el doble de RAM que con PyPy (y tarda
> un montón más también).
>
> Honestamente, incluso si PyPy no fuera suficiente, te seguiría
> recomendando Python. Tengo mucha experiencia con Python, C++, y Java,
> y de todos los lenguajes, incluso cuando necesito ultra-performance,
> elijo Python. ¿Por qué? Pues porque es tremendamente sencillo tomar un
> módulo o función python que es un cuello de botella, y sólo eso
> transformarlo en C++ y tener lo mejor de ambos mundos. Es la
> anti-epítome de la optimización prematura. Es lo ideal.
> _______________________________________________


--

Este mensaje le ha llegado mediante el servicio de correo electronico que ofrece Infomed para respaldar el cumplimiento de las misiones del Sistema Nacional de Salud. La persona que envia este correo asume el compromiso de usar el servicio a tales fines y cumplir con las regulaciones establecidas

Infomed: http://www.sld.cu/

_______________________________________________
pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
http://listas.python.org.ar/listinfo/pyar

PyAr - Python Argentina - Sitio web: http://www.python.org.ar/

La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de Argentina - http://www.usla.org.ar

[Enrique Gabriel Baquela]

Proba cython. Básicamente es python con declaración opcional de tipos.
Corre bastante mas rápido y nunca salís de python.
La opción de algún lisp también es buena.
Saludos
El 06/02/2014 18:24, "Alejandro Zamora Fonseca" <terefv-pNGfD4lFfPfph/***@public.gmane.org>
escribió:

> Muchas gracias a todos,
> es verdad que tengo que profundizar en las últimas implementaciones de
> Python para ver hasta que punto mejoran la eficiencia, pero lo que si no
> quiero es tocar nada del grupito C/C++/Java, no porque no lo haya hecho
> antes(sobre todo en C/C++ o Java) sino porque quiero hacerlo todo o casi
> todo en un lenguaje como Python .
> Así que por eso no quiero, a priori, usar ctypes ni nada parecido.
> Así que por eso trataré de encontrar una imp. de Python así en PyPy pero
> si no tendré que buscar un nuevo lenguaje, por eso hablaba de Lisp.
>
> gracias de nuevo
>
> El 2014-02-06 18:00, Claudio Freire escribió:
>
>> 2014-02-06 13:47 GMT-03:00 Alejandro Zamora Fonseca <terefv-pNGfD4lFfPfph/***@public.gmane.org>:
>>
>>> Comienzo.
>>> Todos sabemos de las muchísimas virtudes de python como lenguaje y
>>> tecnología pero también de su problema con la eficiencia(aunque sé hay
>>> varias opciones para acelerarlo un poco).
>>>
>>> Entonces estoy metido en un projecto donde hace falta bastante
>>> eficiencia y
>>> casi que estoy obligado a no usar python, entonces bueno... sé que hay
>>> muchísimas opciones... pero tiene que ser un lenguaje con
>>> implementaciones
>>> muy eficientes...
>>> Pero el kid de la cuestión es que no quiero perder la riquez en
>>> expresividad
>>> de Python y por tanto no quiero usar ninguno de los "mainstreams
>>> languages(C/C++/Java)" que realmente ya me desagradan por su sintaxis a
>>> pesar de todas sus IDEs y demás ventajas.
>>> Quiero un lenguaje que sea bastante eficiente(me refiero por supuesto a
>>> uso
>>> de memoria y rapidez de ejecución) pero quiero que sea tambien
>>> bastante expresivo como python, ahh!! y multiparadigma, por lo que por
>>> ahí
>>> desecho otro grupo de lenguajes importantes...
>>>
>>
>>
>> Probaste PyPy?
>>
>> Las últimas versiones tienen pseudotipos, que aunque su nombre *no* lo
>> indica, ahorra mucha memoria comparado con CPython. De hecho, hace que
>> todas las estructuras (clases simples) que implementes en Python
>> terminen ocupando lo que ocupan en C (maso - con algo de overhead -
>> pero cosa que es muy impresionante si me preguntás).
>>
>> El ejemplo es PyPy para traducir PyPy (traducir = compilar).
>> Haciéndolo con CPython usa como el doble de RAM que con PyPy (y tarda
>> un montón más también).
>>
>> Honestamente, incluso si PyPy no fuera suficiente, te seguiría
>> recomendando Python. Tengo mucha experiencia con Python, C++, y Java,
>> y de todos los lenguajes, incluso cuando necesito ultra-performance,
>> elijo Python. ¿Por qué? Pues porque es tremendamente sencillo tomar un
>> módulo o función python que es un cuello de botella, y sólo eso
>> transformarlo en C++ y tener lo mejor de ambos mundos. Es la
>> anti-epítome de la optimización prematura. Es lo ideal.
>> _______________________________________________
>>
>
>
> --
>
> Este mensaje le ha llegado mediante el servicio de correo electronico que
> ofrece Infomed para respaldar el cumplimiento de las misiones del Sistema
> Nacional de Salud. La persona que envia este correo asume el compromiso de
> usar el servicio a tales fines y cumplir con las regulaciones establecidas
>
> Infomed: http://www.sld.cu/
>
> _______________________________________________
> pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar
>

[Ezequiel Brizuela [aka EHB or qlixed]]

Cobra? Googlealo. Lo vi el otro dia y parece bueno sintactica y
semanticamente... es casi python q compila bytecode clr compatible con .net
y mono.
El feb 6, 2014 1:28 PM, "Alejandro Zamora Fonseca" <terefv-pNGfD4lFfPfph/***@public.gmane.org>
escribió:

> Hola a todos:
> espero que no ser demasiado "hereje" con lo que voy a preguntar...
>
> Comienzo.
> Todos sabemos de las muchísimas virtudes de python como lenguaje y
> tecnología pero también de su problema con la eficiencia(aunque sé hay
> varias opciones para acelerarlo un poco).
>
> Entonces estoy metido en un projecto donde hace falta bastante eficiencia
> y casi que estoy obligado a no usar python, entonces bueno... sé que hay
> muchísimas opciones... pero tiene que ser un lenguaje con implementaciones
> muy eficientes...
> Pero el kid de la cuestión es que no quiero perder la riquez en
> expresividad de Python y por tanto no quiero usar ninguno de los
> "mainstreams languages(C/C++/Java)" que realmente ya me desagradan por su
> sintaxis a pesar de todas sus IDEs y demás ventajas.
> Quiero un lenguaje que sea bastante eficiente(me refiero por supuesto a
> uso de memoria y rapidez de ejecución) pero quiero quiero que sea tambien
> bastante expresivo como python, ahh!! y multiparadigma, por lo que por ahí
> desecho otro grupo de lenguajes importantes...
> Entonces he pensado en LISP(específicamente Common Lisp) para mi
> proyecyto¿qué creen?
>
> Saludos ..
>
> Alejandro
>
>
>
>
> --
>
> Este mensaje le ha llegado mediante el servicio de correo electronico que
> ofrece Infomed para respaldar el cumplimiento de las misiones del Sistema
> Nacional de Salud. La persona que envia este correo asume el compromiso de
> usar el servicio a tales fines y cumplir con las regulaciones establecidas
>
> Infomed: http://www.sld.cu/
>
> _______________________________________________
> pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar
>

[Sebastián Seba]

El 6 de febrero de 2014, 21:09, Ezequiel Brizuela [aka EHB or qlixed] <
qlixed-***@public.gmane.org> escribió:

> Cobra? Googlealo. Lo vi el otro dia y parece bueno sintactica y
> semanticamente... es casi python q compila bytecode clr compatible con .net
> y mono.
> El feb 6, 2014 1:28 PM, "Alejandro Zamora Fonseca" <terefv-pNGfD4lFfPfph/***@public.gmane.org>
> escribió:
>
> Hola a todos:
>> espero que no ser demasiado "hereje" con lo que voy a preguntar...
>>
>> Comienzo.
>> Todos sabemos de las muchísimas virtudes de python como lenguaje y
>> tecnología pero también de su problema con la eficiencia(aunque sé hay
>> varias opciones para acelerarlo un poco).
>>
>> Entonces estoy metido en un projecto donde hace falta bastante eficiencia
>> y casi que estoy obligado a no usar python, entonces bueno... sé que hay
>> muchísimas opciones... pero tiene que ser un lenguaje con implementaciones
>> muy eficientes...
>> Pero el kid de la cuestión es que no quiero perder la riquez en
>> expresividad de Python y por tanto no quiero usar ninguno de los
>> "mainstreams languages(C/C++/Java)" que realmente ya me desagradan por su
>> sintaxis a pesar de todas sus IDEs y demás ventajas.
>> Quiero un lenguaje que sea bastante eficiente(me refiero por supuesto a
>> uso de memoria y rapidez de ejecución) pero quiero quiero que sea tambien
>> bastante expresivo como python, ahh!! y multiparadigma, por lo que por ahí
>> desecho otro grupo de lenguajes importantes...
>> Entonces he pensado en LISP(específicamente Common Lisp) para mi
>> proyecyto¿qué creen?
>>
>> Saludos ..
>>
>> Alejandro
>>
>>
>>
>>
>> --
>>
>> Este mensaje le ha llegado mediante el servicio de correo electronico que
>> ofrece Infomed para respaldar el cumplimiento de las misiones del Sistema
>> Nacional de Salud. La persona que envia este correo asume el compromiso de
>> usar el servicio a tales fines y cumplir con las regulaciones establecidas
>>
>> Infomed: http://www.sld.cu/
>>
>> _______________________________________________
>> pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
>> http://listas.python.org.ar/listinfo/pyar
>>
>> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>>
>> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
>> Argentina - http://www.usla.org.ar
>>
>
> _______________________________________________
> pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar
>

¿Probaron Numba [0]? En algunos benchmarks llega a ser más rápido que
Cython.

[0] http://numba.pydata.org/

[Enrique Gabriel Baquela]

Buen dato Numba!!!
Supongo que estás buscando algo de propósito general, pero si lo que
necesitás es hacer cálculos rápidos, podes probar Julia:
http://julialang.org/ . Tiene conectividad con python inclusive:
http://blog.leahhanson.us/julia-calling-python-calling-julia.html . Está
todavía en pañales pero tiene buena pinta.
Y si necesitás hacer cálculos estadísticos, podes usar R:
http://www.r-project.org/ , que también se vincula con python:
http://www2.warwick.ac.uk/fac/sci/moac/people/students/peter_cock/r/rpy/

Saludos!!!


El 6 de febrero de 2014, 23:02, Sebastián Seba <ssebastianj-***@public.gmane.org>escribió:

> El 6 de febrero de 2014, 21:09, Ezequiel Brizuela [aka EHB or qlixed] <
> qlixed-***@public.gmane.org> escribió:
>
> Cobra? Googlealo. Lo vi el otro dia y parece bueno sintactica y
>> semanticamente... es casi python q compila bytecode clr compatible con .net
>> y mono.
>> El feb 6, 2014 1:28 PM, "Alejandro Zamora Fonseca" <terefv-pNGfD4lFfPfph/***@public.gmane.org>
>> escribió:
>>
>> Hola a todos:
>>> espero que no ser demasiado "hereje" con lo que voy a preguntar...
>>>
>>> Comienzo.
>>> Todos sabemos de las muchísimas virtudes de python como lenguaje y
>>> tecnología pero también de su problema con la eficiencia(aunque sé hay
>>> varias opciones para acelerarlo un poco).
>>>
>>> Entonces estoy metido en un projecto donde hace falta bastante
>>> eficiencia y casi que estoy obligado a no usar python, entonces bueno... sé
>>> que hay muchísimas opciones... pero tiene que ser un lenguaje con
>>> implementaciones muy eficientes...
>>> Pero el kid de la cuestión es que no quiero perder la riquez en
>>> expresividad de Python y por tanto no quiero usar ninguno de los
>>> "mainstreams languages(C/C++/Java)" que realmente ya me desagradan por su
>>> sintaxis a pesar de todas sus IDEs y demás ventajas.
>>> Quiero un lenguaje que sea bastante eficiente(me refiero por supuesto a
>>> uso de memoria y rapidez de ejecución) pero quiero quiero que sea tambien
>>> bastante expresivo como python, ahh!! y multiparadigma, por lo que por ahí
>>> desecho otro grupo de lenguajes importantes...
>>> Entonces he pensado en LISP(específicamente Common Lisp) para mi
>>> proyecyto¿qué creen?
>>>
>>> Saludos ..
>>>
>>> Alejandro
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Este mensaje le ha llegado mediante el servicio de correo electronico
>>> que ofrece Infomed para respaldar el cumplimiento de las misiones del
>>> Sistema Nacional de Salud. La persona que envia este correo asume el
>>> compromiso de usar el servicio a tales fines y cumplir con las regulaciones
>>> establecidas
>>>
>>> Infomed: http://www.sld.cu/
>>>
>>> _______________________________________________
>>> pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
>>> http://listas.python.org.ar/listinfo/pyar
>>>
>>> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>>>
>>> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
>>> Argentina - http://www.usla.org.ar
>>>
>>
>> _______________________________________________
>> pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
>> http://listas.python.org.ar/listinfo/pyar
>>
>> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>>
>> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
>> Argentina - http://www.usla.org.ar
>>
>
> ¿Probaron Numba [0]? En algunos benchmarks llega a ser más rápido que
> Cython.
>
> [0] http://numba.pydata.org/
>
> _______________________________________________
> pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar
>

[Alejandro Zamora Fonseca]

Bueno bueno....
qué cantidad de opciones supongo que no había buscado bien...
Es que siempre había estado muy "casado" con CPython...

Muchas gracias

--

Este mensaje le ha llegado mediante el servicio de correo electronico que ofrece Infomed para respaldar el cumplimiento de las misiones del Sistema Nacional de Salud. La persona que envia este correo asume el compromiso de usar el servicio a tales fines y cumplir con las regulaciones establecidas

Infomed: http://www.sld.cu/

_______________________________________________
pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
http://listas.python.org.ar/listinfo/pyar

PyAr - Python Argentina - Sitio web: http://www.python.org.ar/

La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de Argentina - http://www.usla.org.ar

[Mariano Aquino]

que intersante lo de cobra! parece Boo (de Unity) pero funciona stand alone.
alguien tiene algo de experiencia con este lenguaje como para compartir?
si la llega a tener, quizas sea mejor abrir un hilo por separado..
Saludos!

Mariano


2014-02-07 Alejandro Zamora Fonseca <terefv-pNGfD4lFfPfph/***@public.gmane.org>:

> Bueno bueno....
> qué cantidad de opciones supongo que no había buscado bien...
> Es que siempre había estado muy "casado" con CPython...
>
> Muchas gracias
>
> --
>
> Este mensaje le ha llegado mediante el servicio de correo electronico que
> ofrece Infomed para respaldar el cumplimiento de las misiones del Sistema
> Nacional de Salud. La persona que envia este correo asume el compromiso de
> usar el servicio a tales fines y cumplir con las regulaciones establecidas
>
> Infomed: http://www.sld.cu/
>
> _______________________________________________
> pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar
>

[Fernando Pelliccioni]

Hola Alejandro, ¿qué tal?

Respondo un poco tarde, espero que a tiempo :)

Me intriga saber qué tipo de proyecto vas a encarar.
Creo que dependiendo de eso, de ahí surge que lenguaje te conviene usar.

Según mi consideración, que puede estar un poco viciada, hay casos en los
que no podes escapar de usar C, C++, D(¿?), y... creo que paro de contar.
(Bueno, Fortran y assembly languages también, pero...)
Pero bueno, todo depende del caso.
Justamente estos lenguajes que recomiendo son los que pensaste descartar
por su sintaxis. Me interesaría saber si existe alguna otra razón para
descartarlos.

(Al margen, me da "cosita" poner en el mismo grupo a C y C++ con Java...)

C++ con C++11 y el próximo C++14 se ha vuelto un lenguaje bastante más
expresivo y simple, yo creo.
Podríamos comenzar un PingPong sobre qué cosas te gustan de Python y yo
puedo contestar con su contraparte en C++, quizás te hago cambiar de
opinión.

Comparto el link de él que considero uno de los mejores y más detallados
artículos que vi al respecto del análisis de lenguajes cuya prioridad en el
diseño (del lenguaje) NO es la eficiencia.
Concretamente trata de Javascript, pero aplica a muchos más.
http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/

Un abrazo,
Fernando.



2014-02-06 13:47 GMT-03:00 Alejandro Zamora Fonseca <terefv-pNGfD4lFfPfph/***@public.gmane.org>:

> Hola a todos:
> espero que no ser demasiado "hereje" con lo que voy a preguntar...
>
> Comienzo.
> Todos sabemos de las muchísimas virtudes de python como lenguaje y
> tecnología pero también de su problema con la eficiencia(aunque sé hay
> varias opciones para acelerarlo un poco).
>
> Entonces estoy metido en un projecto donde hace falta bastante eficiencia
> y casi que estoy obligado a no usar python, entonces bueno... sé que hay
> muchísimas opciones... pero tiene que ser un lenguaje con implementaciones
> muy eficientes...
> Pero el kid de la cuestión es que no quiero perder la riquez en
> expresividad de Python y por tanto no quiero usar ninguno de los
> "mainstreams languages(C/C++/Java)" que realmente ya me desagradan por su
> sintaxis a pesar de todas sus IDEs y demás ventajas.
> Quiero un lenguaje que sea bastante eficiente(me refiero por supuesto a
> uso de memoria y rapidez de ejecución) pero quiero quiero que sea tambien
> bastante expresivo como python, ahh!! y multiparadigma, por lo que por ahí
> desecho otro grupo de lenguajes importantes...
> Entonces he pensado en LISP(específicamente Common Lisp) para mi
> proyecyto¿qué creen?
>
> Saludos ..
>
> Alejandro
>
>
>
>
> --
>
> Este mensaje le ha llegado mediante el servicio de correo electronico que
> ofrece Infomed para respaldar el cumplimiento de las misiones del Sistema
> Nacional de Salud. La persona que envia este correo asume el compromiso de
> usar el servicio a tales fines y cumplir con las regulaciones establecidas
>
> Infomed: http://www.sld.cu/
>
> _______________________________________________
> pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar
>

[Emiliano Dalla Verde Marcozzi]

Cantidad de opciones! Leí el thread y creo no haber visto que nombraran
a Go de google, se 'vende' siendo expresivo como python, pero hecho para
escalar 'nativamente' (?), aunque no lo usé personalmente.
Saludos!

--
"Code without tests is broken by design." - Jacob Kaplan-Moss
Broken code @ https://github.com/edvm
jabber: edvm-+ZN9ApsXKcFd+***@public.gmane.org

[Carlos Miguel FARIAS]

Una solución interesante es el paquete Lianja..
Es de pago, si, pero permite programar en varios lenguajes (VFP, Python,
PHP, JS)
Y es multiplataforma.
Saludos: Miguel, Santa Rosa (LP)


El 1 de marzo de 2014, 0:03, Emiliano Dalla Verde Marcozzi <
edvm-rxtnV0ftBwyoClj4AeEUq9i2O/***@public.gmane.org> escribió:

> Cantidad de opciones! Leí el thread y creo no haber visto que nombraran
> a Go de google, se 'vende' siendo expresivo como python, pero hecho para
> escalar 'nativamente' (?), aunque no lo usé personalmente.
> Saludos!
>
> --
> "Code without tests is broken by design." - Jacob Kaplan-Moss
> Broken code @ https://github.com/edvm
> jabber: edvm-+ZN9ApsXKcFd+***@public.gmane.org
>
> _______________________________________________
> pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar
>

[Alejandro Zamora Fonseca]

Bueno gracias por las últimas sugerencias.
Fernado, yo siempré respetaré a C/C++, de hecho de ahí provengo, los
prefiere frente a Java, pero, aunque no esté actualizado en el tema de
los últimos "releases" de C++ creo que Python es más expresivo que
ellos.
De todas formas es verdad que para muchas cosas es muy difícil
desprenderse de ellos, pero para ese proyecto ya me decidí por
Lisp(específicamente Common Lisp (CL)) porque es tan o más expresivo que
Python, normalmente es casi tan eficiente como C/C++(se dice que hay
algunas implementaciones que incluso son más rápidas) y muchas otras
cosas más... pero bueno no me voy a poner a hacer ping-pong yo tampoco
jaja
Para mi de ahora en adelante(si no pasa otra cosa) hay 4 lenguajes
Python, LISP(la familia, pero CL ppalmente) y C/C++, me gustaría pensar
que con alguna combinación de ellos puedo atacar cualquier problema.
ahh!! y gracias por el link, voy a echarle un vistazo...

un abrazo
Alejandro


El 2014-02-28 23:39, Fernando Pelliccioni escribió:
> Hola Alejandro, ¿qué tal?
>
> Respondo un poco tarde, espero que a tiempo :)
>
> Me intriga saber qué tipo de proyecto vas a encarar.
> Creo que dependiendo de eso, de ahí surge que lenguaje te conviene
> usar.
>
> Según mi consideración, que puede estar un poco viciada, hay casos en
> los que no podes escapar de usar C, C++, D(¿?), y... creo que paro de
> contar. (Bueno, Fortran y assembly languages también, pero…)
> Pero bueno, todo depende del caso.
> Justamente estos lenguajes que recomiendo son los que pensaste
> descartar por su sintaxis. Me interesaría saber si existe alguna otra
> razón para descartarlos.
>
> (Al margen, me da "cosita" poner en el mismo grupo a C y C++ con
> Java...)
>
> C++ con C++11 y el próximo C++14 se ha vuelto un lenguaje bastante
> más expresivo y simple, yo creo.
> Podríamos comenzar un PingPong sobre qué cosas te gustan de Python y
> yo puedo contestar con su contraparte en C++, quizás te hago cambiar
> de opinión.
>
> Comparto el link de él que considero uno de los mejores y más
> detallados artículos que vi al respecto del análisis de lenguajes cuya
> prioridad en el diseño (del lenguaje) NO es la eficiencia.
> Concretamente trata de Javascript, pero aplica a muchos más.
> http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ [5]
>
> Un abrazo,
> Fernando.
>
> 2014-02-06 13:47 GMT-03:00 Alejandro Zamora Fonseca
> <***@ltu.sld.cu>:
>
>> Hola a todos:
>> espero que no ser demasiado "hereje" con lo que voy a preguntar...
>>
>> Comienzo.
>> Todos sabemos de las muchísimas virtudes de python como lenguaje y
>> tecnología pero también de su problema con la eficiencia(aunque sé hay
>> varias opciones para acelerarlo un poco).
>>
>> Entonces estoy metido en un projecto donde hace falta bastante
>> eficiencia y casi que estoy obligado a no usar python, entonces
>> bueno... sé que hay muchísimas opciones... pero tiene que ser un
>> lenguaje con implementaciones muy eficientes...
>> Pero el kid de la cuestión es que no quiero perder la riquez en
>> expresividad de Python y por tanto no quiero usar ninguno de los
>> "mainstreams languages(C/C++/Java)" que realmente ya me desagradan por
>> su sintaxis a pesar de todas sus IDEs y demás ventajas.
>> Quiero un lenguaje que sea bastante eficiente(me refiero por supuesto
>> a uso de memoria y rapidez de ejecución) pero quiero quiero que sea
>> tambien bastante expresivo como python, ahh!! y multiparadigma, por lo
>> que por ahí desecho otro grupo de lenguajes importantes...
>> Entonces he pensado en LISP(específicamente Common Lisp) para mi
>> proyecyto¿qué creen?
>>
>> Saludos ..
>>
>> Alejandro
>>
>> --
>>
>> Este mensaje le ha llegado mediante el servicio de correo electronico
>> que ofrece Infomed para respaldar el cumplimiento de las misiones del
>> Sistema Nacional de Salud. La persona que envia este correo asume el
>> compromiso de usar el servicio a tales fines y cumplir con las
>> regulaciones establecidas
>>
>> Infomed: http://www.sld.cu/ [1]
>>
>> _______________________________________________
>> pyar mailing list ***@python.org.ar
>> http://listas.python.org.ar/listinfo/pyar [2]
>>
>> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/ [3]
>>
>> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre
>> de Argentina - http://www.usla.org.ar [4]
>
>
>
> Links:
> ------
> [1] http://www.sld.cu/
> [2] http://listas.python.org.ar/listinfo/pyar
> [3] http://www.python.org.ar/
> [4] http://www.usla.org.ar
> [5] http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/
>
> _______________________________________________
> pyar mailing list ***@python.org.ar
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre
> de Argentina - http://www.usla.org.ar

--

Este mensaje le ha llegado mediante el servicio de correo electronico que ofrece Infomed para respaldar el cumplimiento de las misiones del Sistema Nacional de Salud. La persona que envia este correo asume el compromiso de usar el servicio a tales fines y cumplir con las regulaciones establecidas

Infomed: http://www.sld.cu/

_______________________________________________
pyar mailing list ***@python.org.ar
http://listas.python.org.ar/listinfo/pyar

PyAr - Python Argentina - Sitio web: http://www.python.org.ar/

La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de Argentin

[Claudio Freire]

2014-03-03 12:09 GMT-03:00 Alejandro Zamora Fonseca <terefv-pNGfD4lFfPfph/***@public.gmane.org>:
> Bueno gracias por las últimas sugerencias.
> Fernado, yo siempré respetaré a C/C++, de hecho de ahí provengo, los
> prefiere frente a Java, pero, aunque no esté actualizado en el tema de los
> últimos "releases" de C++ creo que Python es más expresivo que ellos.
> De todas formas es verdad que para muchas cosas es muy difícil desprenderse
> de ellos, pero para ese proyecto ya me decidí por Lisp(específicamente
> Common Lisp (CL)) porque es tan o más expresivo que Python, normalmente es
> casi tan eficiente como C/C++(se dice que hay algunas implementaciones que
> incluso son más rápidas) y muchas otras cosas más... pero bueno no me voy a
> poner a hacer ping-pong yo tampoco jaja


Qué entendés como "más expresivo"?

Me cuesta entender la comparación entre dos lenguajes turing-completos...
_______________________________________________
pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
http://listas.python.org.ar/listinfo/pyar

PyAr - Python Argentina - Sitio web: http://www.python.org.ar/

La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de Argentina - http://www.usla.org.ar

[Fernando Pelliccioni]

2014-03-03 19:00 GMT-03:00 Claudio Freire <klaussfreire-***@public.gmane.org>:

> 2014-03-03 12:09 GMT-03:00 Alejandro Zamora Fonseca <terefv-pNGfD4lFfPfph/***@public.gmane.org>:
> > Bueno gracias por las últimas sugerencias.
> > Fernado, yo siempré respetaré a C/C++, de hecho de ahí provengo, los
> > prefiere frente a Java, pero, aunque no esté actualizado en el tema de
> los
> > últimos "releases" de C++ creo que Python es más expresivo que ellos.
> > De todas formas es verdad que para muchas cosas es muy difícil
> desprenderse
> > de ellos, pero para ese proyecto ya me decidí por Lisp(específicamente
> > Common Lisp (CL)) porque es tan o más expresivo que Python, normalmente
> es
> > casi tan eficiente como C/C++(se dice que hay algunas implementaciones
> que
> > incluso son más rápidas) y muchas otras cosas más... pero bueno no me
> voy a
> > poner a hacer ping-pong yo tampoco jaja
>
>
> Qué entendés como "más expresivo"?
>
> Me cuesta entender la comparación entre dos lenguajes turing-completos...
> _______________________________________________
> pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar
>



Yo me pregunto lo mismo, otro tema importante es ver qué tipo de proyecto
vas a encarar.

Imagino que no vas a escribir el kernel de un sistema operativo (exagero)
ni un sistema real-time, ya que Common-Lisp es un lenguaje con
GarbageCollection NO opcional, así el lenguaje no sería muy adecuado para
escribir aplicaciones que necesiten un rendimiento determinístico.

Realmente no creo que Common-Lisp tenga una eficiencia comparable a C++ (o
C).
Para comprobarlo tendrías que implementar el sistema en C++ y Common-Lisp
(bien escrito en ambos) y luego medir la eficiencia de ambos sistemas.
Considerando también que compilador e implementación de bibliotecas estás
usando (En C y C++ es muy común que exista diferencia en performance por la
implementación ineficiente de algún compilador y biblioteca, por ejemplo
MSVC).
Obviamente hacer esto sería impracticable, así que, cada uno tendrá su
forma de medir la eficiencia y capacidad de abstracción de los lenguajes.

Para mí lo importante en un lenguaje es que provea facilidades de
abstracción y que el uso de esas facilidades no haga perder eficiencia.
¿Cómo medimos esas capacidades de abstracción de un lenguaje?
Yo uso un método que aprendí de Alex Stepanov que consiste en implementar
tres programas simples de forma genérica:

- Swap de dos elementos
- Min (o Max) de dos elementos
- Búsqueda lineal de una secuencia de elementos.

Una vez implementados, ¿cómo sabemos si son eficientes?.

Bueno, en realidad tenemos dos tipos de eficiencia:
* Un programa es relativamente eficiente, si funciona igual de rápido que
si hubiéramos escrito el código a mano usando el mismo lenguaje de
programación.
* Un programa es absolutamente eficiente, si es tan eficiente como el
código maquina (o Assembly) escrito para una determinada arquitectura.

Algunos dirán, bueno, estos problemas son muy simples como para calificar
la eficiencia de un lenguaje, pero, si no podemos hacer cosas simples,
difícilmente podamos hacer cosas complejas.


Entonces, para evaluar un lenguaje de programación es adecuado para
escribir componentes de forma eficiente, trato de implementar estos tres
programas y que al menos sea "Relativamente Eficiente".
Ese es el método que uso, quizás les sirva.

Según mi conocimiento, C++ es el único lenguaje que provee Genericidad y
"Eficiencia Absoluta". Imagino que D y Rust también lo son, pero realmente
desconozco, tengo que medirlo.

Saludos,
Fernando.

[Fernando Pelliccioni]

2014-03-03 22:22 GMT-03:00 Fernando Pelliccioni <fpelliccioni-***@public.gmane.org>:

>
>
>
> 2014-03-03 19:00 GMT-03:00 Claudio Freire <klaussfreire-***@public.gmane.org>:
>
> 2014-03-03 12:09 GMT-03:00 Alejandro Zamora Fonseca <terefv-pNGfD4lFfPfph/***@public.gmane.org>:
>> > Bueno gracias por las últimas sugerencias.
>> > Fernado, yo siempré respetaré a C/C++, de hecho de ahí provengo, los
>> > prefiere frente a Java, pero, aunque no esté actualizado en el tema de
>> los
>> > últimos "releases" de C++ creo que Python es más expresivo que ellos.
>> > De todas formas es verdad que para muchas cosas es muy difícil
>> desprenderse
>> > de ellos, pero para ese proyecto ya me decidí por Lisp(específicamente
>> > Common Lisp (CL)) porque es tan o más expresivo que Python, normalmente
>> es
>> > casi tan eficiente como C/C++(se dice que hay algunas implementaciones
>> que
>> > incluso son más rápidas) y muchas otras cosas más... pero bueno no me
>> voy a
>> > poner a hacer ping-pong yo tampoco jaja
>>
>>
>> Qué entendés como "más expresivo"?
>>
>> Me cuesta entender la comparación entre dos lenguajes turing-completos...
>> _______________________________________________
>> pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
>> http://listas.python.org.ar/listinfo/pyar
>>
>> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>>
>> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
>> Argentina - http://www.usla.org.ar
>>
>
>
>
> Yo me pregunto lo mismo, otro tema importante es ver qué tipo de proyecto
> vas a encarar.
>
> Imagino que no vas a escribir el kernel de un sistema operativo (exagero)
> ni un sistema real-time, ya que Common-Lisp es un lenguaje con
> GarbageCollection NO opcional, así el lenguaje no sería muy adecuado para
> escribir aplicaciones que necesiten un rendimiento determinístico.
>
> Realmente no creo que Common-Lisp tenga una eficiencia comparable a C++ (o
> C).
> Para comprobarlo tendrías que implementar el sistema en C++ y Common-Lisp
> (bien escrito en ambos) y luego medir la eficiencia de ambos sistemas.
> Considerando también que compilador e implementación de bibliotecas estás
> usando (En C y C++ es muy común que exista diferencia en performance por la
> implementación ineficiente de algún compilador y biblioteca, por ejemplo
> MSVC).
> Obviamente hacer esto sería impracticable, así que, cada uno tendrá su
> forma de medir la eficiencia y capacidad de abstracción de los lenguajes.
>
> Para mí lo importante en un lenguaje es que provea facilidades de
> abstracción y que el uso de esas facilidades no haga perder eficiencia.
> ¿Cómo medimos esas capacidades de abstracción de un lenguaje?
> Yo uso un método que aprendí de Alex Stepanov que consiste en implementar
> tres programas simples de forma genérica:
>
> - Swap de dos elementos
> - Min (o Max) de dos elementos
> - Búsqueda lineal de una secuencia de elementos.
>
> Una vez implementados, ¿cómo sabemos si son eficientes?.
>
> Bueno, en realidad tenemos dos tipos de eficiencia:
> * Un programa es relativamente eficiente, si funciona igual de rápido que
> si hubiéramos escrito el código a mano usando el mismo lenguaje de
> programación.
> * Un programa es absolutamente eficiente, si es tan eficiente como el
> código maquina (o Assembly) escrito para una determinada arquitectura.
>
> Algunos dirán, bueno, estos problemas son muy simples como para calificar
> la eficiencia de un lenguaje, pero, si no podemos hacer cosas simples,
> difícilmente podamos hacer cosas complejas.
>
>
> Entonces, para evaluar un lenguaje de programación es adecuado para
> escribir componentes de forma eficiente, trato de implementar estos tres
> programas y que al menos sea "Relativamente Eficiente".
> Ese es el método que uso, quizás les sirva.
>
> Según mi conocimiento, C++ es el único lenguaje que provee Genericidad y
> "Eficiencia Absoluta". Imagino que D y Rust también lo son, pero realmente
> desconozco, tengo que medirlo.
>
> Saludos,
> Fernando.
>
>

Me olvidaba,...
Otro tema importante es cuan compactas son las estructuras de datos típicas
del lenguaje.
Creo que un problema que tenían los primeros LISP's era que no existían
estructuras de memoria continua (arrays), sino que eran listas enlazadas,
quizás luego las incluyeron, no lo sé.
En las arquitecturas modernas, las estructuras de datos y objetos que
consumen poca memoria son fundamentales porque cuanto menos memoria, menos
probabilidad de "d-cache misses".

Realmente no conozco nada de Common-Lisp, pero que sea un lenguaje dinámico
y tenga GC me hace creer que no es muy eficiente.

Pero, más allá de todo, la pregunta es, ¿cuán eficiente necesitas que sea?
Quizás para lo que necesitas hacer, ¡es perfecto!

Saludos,
Fernando.

[Claudio Freire]

2014-03-03 22:29 GMT-03:00 Fernando Pelliccioni <fpelliccioni-***@public.gmane.org>:
>
> Me olvidaba,...
> Otro tema importante es cuan compactas son las estructuras de datos típicas
> del lenguaje.
> Creo que un problema que tenían los primeros LISP's era que no existían
> estructuras de memoria continua (arrays), sino que eran listas enlazadas,
> quizás luego las incluyeron, no lo sé.
> En las arquitecturas modernas, las estructuras de datos y objetos que
> consumen poca memoria son fundamentales porque cuanto menos memoria, menos
> probabilidad de "d-cache misses".
>
> Realmente no conozco nada de Common-Lisp, pero que sea un lenguaje dinámico
> y tenga GC me hace creer que no es muy eficiente.


Hay dos formas de lograr eficiencia ante la presencia de abstracción
en el lenguaje (o, mejor dicho, voy a mencionar 2).

Una, es optimización en tiempo de compilación. Que el compilador
elimine la abstracción y genere código concreto y eficiente. Esto es
C++.

Pero un lenguaje dinámico y con GC no necesariamente está excluído,
puesto que esta tarea también se puede hacer en tiempo de ejecución,
como lo demuestran PyPy, Java, Smalltalk y tantos otras
implementaciones de lenguajes dinámicos con JIT.

A diferencia de una optimización estática, la optimización JIT se
adecua al input del programa, y tiene el potencial de ser aún más
eficiente.

No es un tema sencillo ni es blanco ni negro, pero ciertamente
considerar programas minimalistas para evaluar la "capacidad de
abstracción eficiente" de un lenguaje es un esquema inadecuado, dado
que lo que nos interesa es la habilidad de la *implementación* de
*eliminar la abstracción*, cosa que realmente no se puede poner a
prueba en programas pequeños con escasa arquitectura.

Y ahora quiero llamar la atención a cómo fui cambiando el lenguaje
para empezar a hablar de implementaciones y no lenguajes. Python es un
ejemplo clarísimo de por qué hace falta considerarlos separados:
cython, jython, pypy, CPython, todos implementan el mismo lenguaje
pero con características de performance completamente diferentes.

Aún así, creo que los lenguajes por excelencia en su capacidad de
"abstraer eficientemente" son Java y C++. Java en menor medida que
C++, pero sigue realizando un trabajo estelar en eliminar el costo
computacional (aunque no en memoria) de la abstracción.

PyPy se acerca a Java cada día, y lo mantengo vigilado, pues creo que
puede llegar a superarlo, pero no puedo decir aún que esté a la altura
de esos dos. Python como lenguaje me encanta, pero ninguna
implementación te permite abstraer sin remoridimientos,
lamentablemente. La abstracción en Python cuesta performance, siempre.
_______________________________________________
pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
http://listas.python.org.ar/listinfo/pyar

PyAr - Python Argentina - Sitio web: http://www.python.org.ar/

La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de Argentina - http://www.usla.org.ar

[Angel Java Lopez]

Ah! Interesante discusion.

Algun comentario:

Los compiladores JIT hay mejorado con los anios. Y si el lenjuage original
es tipado, la compilacion a VM, y luego, la compilacion de VM a codigo de
maquina anfitriona (sea JIT o no), tambien ha ido mejorando.

El gran tema es como se implementa

a+b

a.m(b)

en el lenguaje. En un lenguaje tipado, con Virtual Machine por debajo, y
Garbage Collector, como Java/C#, el

a+b

es bastante eficiente, por lo que vi. No recuerdo ahora Java, pero .NET
tiene desde el vamos el concepto de compilar a codigo nativo cuando va a
ejecutar lo de su VM. Y las optimizaciones que se pueden hacer ahi (no se
hasta donde llegaron ahora), tanto en C# Microsoft, como Mono, harian que
a+b se acerque al codigo de assembler.

En lenguajes dinamicos como Python y Ruby, no hay otra que ir haciendo JIT
por tipo. Cuando ve que a+b son ambos enteros, genera un codigo de maquina
adecuado a ello. Eso lo vi tambien en la HipHop de PHP de Facebook, en
IronPython, en IronRuby y debe estar en otros. Pero hay un chequeo de tipos
cada vez que pasa por ahi. Lo que si puede hacerse es:

def add(a,b):
a+b

chequear los tipos a la entrada del def, y generar todo un codigo
optimizado nativo para cuando se llama a add con enteros. Otra mas que
puede hacerse: descubrir que add solo se llama con enteros, hacer
inferencia de los tipos de llamada

Otra bestia a domar es:

a.m(b)

Como resolver el metodo m? En lenguajes como JavaScript, e imagino Python
tmb, el metodo puede ser del objeto, no de la clase. Hay que hacer lookup
cada vez que pasamos por ahi. En Java, los metodos son virtuales, y de
nuevo, no escapamos de lookup. En C#, los metodos puede no ser virtuales. y
el llamado es como en C clasico: resuelto a nivel de compilacion en esos
casos.

Pero si, lo que ha traido Lisp, Smalltalk, y en tiempos modernos, Java, C#,
es garbage collector. Pueden ver la influencia de GC en el enlace enviado
por Fernando Pelliccioni

http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/

Hmmm... no se recuerdo como era el common lisp, pero
(+ a b)
puede ser compilado en algunas implementaciones a nativo

Clojure tiene type hints para mejorar la experiencia de compilacion, que
recuerde.

Lo que si tiene C, C++ es la capacidad de metodos inline. El caso

abs(a,b)

en vez de llamar a una funcion, puede expandirse en ese momento a codigo en
ese lugar. En .NET 4.5 empieza aparecer algo como inline, pero no se cuanto
se ha llegado a poner eso en la libreria core

Resumen:
- Tipado vs no tipado a tiempo de compilacion: lo tipado permite
implementacion nativa o a VM

- Compilacion de VM (bytecodes?) a nativo
- sobre tipado, puede generar codigo nativo, la eficiencia depende de las
optimizaciones del compilador de esta fase
- sobre no tipado, puede ver los tipos que llegan (a entero?, b entero?)
y determinar generar codigo para ese caso

- Llamada a metodo
- se puede transformar a inline?
- es metodo virtual, no zafamos de lookup?

- Garbage collector
- el precio a pagar

Nos leemos!

Angel "Java" Lopez
@ajlopez



2014-03-04 1:32 GMT-03:00 Claudio Freire <klaussfreire-***@public.gmane.org>:

> 2014-03-03 22:29 GMT-03:00 Fernando Pelliccioni <fpelliccioni-***@public.gmane.org>:
> >
> > Me olvidaba,...
> > Otro tema importante es cuan compactas son las estructuras de datos
> típicas
> > del lenguaje.
> > Creo que un problema que tenían los primeros LISP's era que no existían
> > estructuras de memoria continua (arrays), sino que eran listas enlazadas,
> > quizás luego las incluyeron, no lo sé.
> > En las arquitecturas modernas, las estructuras de datos y objetos que
> > consumen poca memoria son fundamentales porque cuanto menos memoria,
> menos
> > probabilidad de "d-cache misses".
> >
> > Realmente no conozco nada de Common-Lisp, pero que sea un lenguaje
> dinámico
> > y tenga GC me hace creer que no es muy eficiente.
>
>
> Hay dos formas de lograr eficiencia ante la presencia de abstracción
> en el lenguaje (o, mejor dicho, voy a mencionar 2).
>
> Una, es optimización en tiempo de compilación. Que el compilador
> elimine la abstracción y genere código concreto y eficiente. Esto es
> C++.
>
> Pero un lenguaje dinámico y con GC no necesariamente está excluído,
> puesto que esta tarea también se puede hacer en tiempo de ejecución,
> como lo demuestran PyPy, Java, Smalltalk y tantos otras
> implementaciones de lenguajes dinámicos con JIT.
>
> A diferencia de una optimización estática, la optimización JIT se
> adecua al input del programa, y tiene el potencial de ser aún más
> eficiente.
>
> No es un tema sencillo ni es blanco ni negro, pero ciertamente
> considerar programas minimalistas para evaluar la "capacidad de
> abstracción eficiente" de un lenguaje es un esquema inadecuado, dado
> que lo que nos interesa es la habilidad de la *implementación* de
> *eliminar la abstracción*, cosa que realmente no se puede poner a
> prueba en programas pequeños con escasa arquitectura.
>
> Y ahora quiero llamar la atención a cómo fui cambiando el lenguaje
> para empezar a hablar de implementaciones y no lenguajes. Python es un
> ejemplo clarísimo de por qué hace falta considerarlos separados:
> cython, jython, pypy, CPython, todos implementan el mismo lenguaje
> pero con características de performance completamente diferentes.
>
> Aún así, creo que los lenguajes por excelencia en su capacidad de
> "abstraer eficientemente" son Java y C++. Java en menor medida que
> C++, pero sigue realizando un trabajo estelar en eliminar el costo
> computacional (aunque no en memoria) de la abstracción.
>
> PyPy se acerca a Java cada día, y lo mantengo vigilado, pues creo que
> puede llegar a superarlo, pero no puedo decir aún que esté a la altura
> de esos dos. Python como lenguaje me encanta, pero ninguna
> implementación te permite abstraer sin remoridimientos,
> lamentablemente. La abstracción en Python cuesta performance, siempre.
> _______________________________________________
> pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar
>

[Fernando Pelliccioni]

Atención: OFF-TOPIC creciendo exponencialmente!


2014-03-04 1:32 GMT-03:00 Claudio Freire <klaussfreire-***@public.gmane.org>:

> 2014-03-03 22:29 GMT-03:00 Fernando Pelliccioni <fpelliccioni-***@public.gmane.org>:
> >
> > Me olvidaba,...
> > Otro tema importante es cuan compactas son las estructuras de datos
> típicas
> > del lenguaje.
> > Creo que un problema que tenían los primeros LISP's era que no existían
> > estructuras de memoria continua (arrays), sino que eran listas enlazadas,
> > quizás luego las incluyeron, no lo sé.
> > En las arquitecturas modernas, las estructuras de datos y objetos que
> > consumen poca memoria son fundamentales porque cuanto menos memoria,
> menos
> > probabilidad de "d-cache misses".
> >
> > Realmente no conozco nada de Common-Lisp, pero que sea un lenguaje
> dinámico
> > y tenga GC me hace creer que no es muy eficiente.
>
>
> Hay dos formas de lograr eficiencia ante la presencia de abstracción
> en el lenguaje (o, mejor dicho, voy a mencionar 2).
>
> Una, es optimización en tiempo de compilación. Que el compilador
> elimine la abstracción y genere código concreto y eficiente. Esto es
> C++.
>
> Pero un lenguaje dinámico y con GC no necesariamente está excluído,
> puesto que esta tarea también se puede hacer en tiempo de ejecución,
> como lo demuestran PyPy, Java, Smalltalk y tantos otras
> implementaciones de lenguajes dinámicos con JIT.
>
> A diferencia de una optimización estática, la optimización JIT se
> adecua al input del programa, y tiene el potencial de ser aún más
> eficiente.
>


Aclaración: C++ no está atado a ser compilado estáticamente, hay
implementaciones que pueden hacer JIT compiling (Clang/LLVM) o incluso ser
interpretado (Cling), aunque no es común.

Lo del "potencial de ser más eficiente" se viene hablando desde los 90's,
hasta el momento no he visto ninguna implementación de un JIT que supere en
eficiencia a la compilación "tradicional".
Algunas optimizaciones son costosas y la diferencia entre un compilador
estático y un JIT es que el usuario está ahí, esperando a que la
optimización se lleve a cabo.
Así que la mayoría de los JIT compilers están forzados a omitir esas
optimizaciones, ya que el costo de optimizar es mayor que el beneficio.
Otra contra es que las optimizaciones de un JIT compiler son difíciles de
predecir y la documentación a veces es muy pobre (.Net / Java). Por esta
razón hay cierto tipo de aplicaciones donde no es posible usar JIT, porque
se necesita determinismo.

El GC es otro tema.
Con GC se requiere hacer un análisis en tiempo de ejecución para determinar
que memoria está siendo utilizada y cuál puede ser liberada. Y este
análisis puede ocurrir en cualquier momento y por una cantidad de tiempo
indefinida. Otro problema es cuando tenemos múltiples threads, cuando el GC
se ejecuta, todos los threads se pausan. Y por último, la mayoría de las
implementaciones no ejecutan el GC hasta que el sistema se queda sin
memoria.
Así que resumiendo: 1. nuestro sistema va a consumir cada vez más y más
memoria. 2. El programa se va a frizar aleatoriamente cuando el GC ejecute.

Ojo, el GC tiene grandes ventajas, ya que ahorra al programador
concentrarse en la administración de recursos, en realidad un recurso, el
más importante, la memoria.
Y hay casos, en donde los expertos aseguran que es imprescindible contar
con GC, como en algunas estructuras de datos lock-free.

En C++ contamos con otros mecanismos para administrar recursos y con la
posibilidad de *opcionalmente* usar un GC.
Esto es porque C++, al igual que C, son lo que se denomina "system
programming language". Esto es, lenguajes que sirven para escribir sistemas
(en vez de aplicaciones), ejemplos: Sistemas operativos, drivers,
compiladores, colisionadores de hadrones, sistemas de misión critica, Java
Virtual Machine, etc... :)
Los lenguajes para programación de sistemas no se pueden dar el lujo de
atarse a JIT o GC, por eso estos mecanismos son opcionales.

Por eso es que en ciertas áreas/industrias algunos lenguajes no son una
opción.
A eso iba mi pregunta a Alejandro... ¿qué necesitás hacer? ¿"cuanta"
eficiencia necesitás?



>
> No es un tema sencillo ni es blanco ni negro, pero ciertamente
> considerar programas minimalistas para evaluar la "capacidad de
> abstracción eficiente" de un lenguaje es un esquema inadecuado, dado
> que lo que nos interesa es la habilidad de la *implementación* de
> *eliminar la abstracción*, cosa que realmente no se puede poner a
> prueba en programas pequeños con escasa arquitectura.
>
>
Pienso justamente lo contrario.
Parafraseando un poco a Stepanov:
"Si un lenguaje/implementación es incapaz de optimizar cosas simples, es
muy poco probable que sea capaz de optimizar cosas más complicadas."

Pensamiento que comparto 100%.
La capacidad/incapacidad de un lenguaje/implementación de "eliminar la
abstracción" puede medirse con estos simples programas.
Pero bueno, entiendo que no todo el mundo piense igual, en ese caso,
hagamos el trabajo duro, implementemos el total de nuestra aplicación en N
cantidad de lenguajes/implementaciones y luego midamos. (Cuidado con las
mediciones tendenciosas).
Si quieren, estoy dispuesto a encarar el ejercicio, me gustan los desafíos
:)




> Y ahora quiero llamar la atención a cómo fui cambiando el lenguaje
> para empezar a hablar de implementaciones y no lenguajes. Python es un
> ejemplo clarísimo de por qué hace falta considerarlos separados:
> cython, jython, pypy, CPython, todos implementan el mismo lenguaje
> pero con características de performance completamente diferentes.
>
>
Comparto y tengo clara la diferencia. Por eso advertí en un email anterior
algunas implementaciones de C++ son menos eficientes que otras. Ídem en
otros lenguajes.
Pero más allá de las implementaciones, hay lenguajes que han sido diseñados
con la eficiencia como principio fundamental y hay otros que no. En C++ lo
llamamos Zero-Overhead.



> Aún así, creo que los lenguajes por excelencia en su capacidad de
> "abstraer eficientemente" son Java y C++. Java en menor medida que
> C++, pero sigue realizando un trabajo estelar en eliminar el costo
> computacional (aunque no en memoria) de la abstracción.
>
>

Creo que vamos a debatir eternamente :)
Yo creo que poner escribir "Java" y "eficiencia" en la misma oración podría
enojar a varios (a mi :)).
Ahora, fuera de broma, realmente creo que Java no es un lenguaje
caracterizado por su eficiencia, y más allá de los esfuerzos y mejoras
hechas, es un lenguaje que dista mucho de C o C++ y como dije antes, es un
lenguaje totalmente descartado para ciertas aplicaciones.
Creo que para comprobarlo tenemos que explorar un poco la realidad. Busquen
cuantos ejemplos de aplicaciones, de áreas donde la eficiencia es un MUST,
que hayan sido implementados eficientemente en Java (o lenguajes
similares). Creo que el porcentaje es mínimo comparado a los proyectos que
han "fracasado".
Analicen cual es la tendencia de los grandes de la industria (Google,
Microsoft, Apple, Amazon, Adobe, Facebook, ..., Electronic Arts, ...)


> PyPy se acerca a Java cada día, y lo mantengo vigilado, pues creo que
> puede llegar a superarlo, pero no puedo decir aún que esté a la altura
> de esos dos. Python como lenguaje me encanta, pero ninguna
> implementación te permite abstraer sin remoridimientos,
> lamentablemente. La abstracción en Python cuesta performance, siempre.
> _______________________________________________
> pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar
>


No existe un lenguaje perfecto, cada lenguaje es bueno en algo, ...pero, de
nuevo, si hablamos de eficiencia, la pregunta es: ¿cuánta necesitas?
Dependiendo de eso, el abanico de opciones se te acota a unos pocos
lenguajes, y no veo a Java incluido en ese conjunto.

Muchos de los temas que estamos hablando son de discusión eterna entre los
expertos, así que no creo nos pongamos de acuerdo nosotros los mortales.
Lo que me parece piola es encarar ciertos desafíos/programas en varios
lenguajes y medir la eficiencia, eso sirve como base para elegir que
lenguaje usar a la hora de encarar un proyecto.

Aquí datos sobre algunas aplicaciones "importantes" y el lenguaje en la que
están desarrolladas.
http://www.lextrait.com/vincent/implementations.html
http://www.stroustrup.com/applications.html

Un abrazo,
Fernando.

[Claudio Freire]

2014-03-04 13:37 GMT-03:00 Fernando Pelliccioni <fpelliccioni-***@public.gmane.org>:
>> Hay dos formas de lograr eficiencia ante la presencia de abstracción
>> en el lenguaje (o, mejor dicho, voy a mencionar 2).
>>
>> Una, es optimización en tiempo de compilación. Que el compilador
>> elimine la abstracción y genere código concreto y eficiente. Esto es
>> C++.
>>
>> Pero un lenguaje dinámico y con GC no necesariamente está excluído,
>> puesto que esta tarea también se puede hacer en tiempo de ejecución,
>> como lo demuestran PyPy, Java, Smalltalk y tantos otras
>> implementaciones de lenguajes dinámicos con JIT.
>>
>> A diferencia de una optimización estática, la optimización JIT se
>> adecua al input del programa, y tiene el potencial de ser aún más
>> eficiente.
>
>
>
> Aclaración: C++ no está atado a ser compilado estáticamente, hay
> implementaciones que pueden hacer JIT compiling (Clang/LLVM) o incluso ser
> interpretado (Cling), aunque no es común.
>
> Lo del "potencial de ser más eficiente" se viene hablando desde los 90's,
> hasta el momento no he visto ninguna implementación de un JIT que supere en
> eficiencia a la compilación "tradicional".

Acá[0] tenés algunos ejemplos (para citar de nuevo the benchmark game).

En síntesis, Java funciona *muy bien* para procesamiento numérico,
porque tiene la habilidad de eliminar por completo la abstracción,
pero sólo a nivel de instrucciones. Sigue manteniéndose un overhead
muy grande en las estructuras en memoria, y se ve en el benchmark.

> Algunas optimizaciones son costosas y la diferencia entre un compilador
> estático y un JIT es que el usuario está ahí, esperando a que la
> optimización se lleve a cabo.

Muchas de esas optimizaciones que mencionás involucran probar
propiedades del programa estáticamente, mirando sólo al código. Los
JIT no necesitan eso. Los JIT insertan "guardas" (testeos para
verificar que las asunciones se siguen cumpliendo) y listo, el resto
del código puede proceder como si se hubiera hecho todo ese análisis.

> El GC es otro tema.
> Con GC se requiere hacer un análisis en tiempo de ejecución para determinar
> que memoria está siendo utilizada y cuál puede ser liberada. Y este análisis
> puede ocurrir en cualquier momento y por una cantidad de tiempo indefinida.
> Otro problema es cuando tenemos múltiples threads, cuando el GC se ejecuta,
> todos los threads se pausan. Y por último, la mayoría de las
> implementaciones no ejecutan el GC hasta que el sistema se queda sin
> memoria.
> Así que resumiendo: 1. nuestro sistema va a consumir cada vez más y más
> memoria. 2. El programa se va a frizar aleatoriamente cuando el GC ejecute.

Ese artículo tan popular sobre JavaScript y por qué Java nunca va a
funcionar bien para celulares está lleno de falacias. Es cierto que
las implementaciones todavía no pueden correr perfectamente en
celulares, pero es "todavía".

Las técnicas clásicas de GC implementadas en las máquinas virtuales
modernas, por ejemplo, no requieren pausas. Son incrementales o
concurrentes, las primeras generan pausas pequeñas, las segundas no
generan pausa alguna. En multi-threading, usan guarderías, una
generación inicial local al thread, lo que hace que funcione mucho
(pero *mucho*) mejor que, por ejemplo, C++ con new o malloc.

Es común, cuando se quiere performance, en C++, empezar a eliminar el
uso de malloc y a codear nuestro propio "allocator". En sí, el manejo
de memoria sin GC no está libre de overhead, como cualquiera que haya
programado en C++ algún sistema de alta performance debería saber.

Sin ir muy lejos, hay GC para C++. Uno muy común y muy usado, es el
contador de referencias. Que es mucho más propenso a leaks que los GC
que vienen ya embebidos en Java o Python. Yo personalmente aborrezco
el GC de Java. Tiene ciertas características que lo hacen una hoja de
doble filo muy peligrosa. Pero no por eso hay que creerse que C++ está
libre de problemas, incluso excluyendo el error humano.


[0] http://benchmarksgame.alioth.debian.org/u32/java.php
_______________________________________________
pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
http://listas.python.org.ar/listinfo/pyar

PyAr - Python Argentina - Sitio web: http://www.python.org.ar/

La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de Argentina - http://www.usla.org.ar

[Fernando Pelliccioni]

2014-03-04 20:27 GMT-03:00 Claudio Freire <klaussfreire-***@public.gmane.org>:

> 2014-03-04 13:37 GMT-03:00 Fernando Pelliccioni <fpelliccioni-***@public.gmane.org>:
> >> Hay dos formas de lograr eficiencia ante la presencia de abstracción
> >> en el lenguaje (o, mejor dicho, voy a mencionar 2).
> >>
> >> Una, es optimización en tiempo de compilación. Que el compilador
> >> elimine la abstracción y genere código concreto y eficiente. Esto es
> >> C++.
> >>
> >> Pero un lenguaje dinámico y con GC no necesariamente está excluído,
> >> puesto que esta tarea también se puede hacer en tiempo de ejecución,
> >> como lo demuestran PyPy, Java, Smalltalk y tantos otras
> >> implementaciones de lenguajes dinámicos con JIT.
> >>
> >> A diferencia de una optimización estática, la optimización JIT se
> >> adecua al input del programa, y tiene el potencial de ser aún más
> >> eficiente.
> >
> >
> >
> > Aclaración: C++ no está atado a ser compilado estáticamente, hay
> > implementaciones que pueden hacer JIT compiling (Clang/LLVM) o incluso
> ser
> > interpretado (Cling), aunque no es común.
> >
> > Lo del "potencial de ser más eficiente" se viene hablando desde los 90's,
> > hasta el momento no he visto ninguna implementación de un JIT que supere
> en
> > eficiencia a la compilación "tradicional".
>
> Acá[0] tenés algunos ejemplos (para citar de nuevo the benchmark game).
>
>
Perdón, me perdí, ¿ejemplos con respecto a que cosa?
Tengo pendiente chequear el código de algunos lenguajes y cuál es el
mecanismo de medición.
Después les digo.


> En síntesis, Java funciona *muy bien* para procesamiento numérico,
> porque tiene la habilidad de eliminar por completo la abstracción,
> pero sólo a nivel de instrucciones. Sigue manteniéndose un overhead
> muy grande en las estructuras en memoria, y se ve en el benchmark.
>

En procesadores modernos Memoria está relacionado con Cache y Cache está
relacionado con eficiencia en ejecución.
Ni hablar de entornos con limitaciones de memoria, como embedded.
No confío en ese BM, luego de analizarlo les digo si estuve equivocado o no.


>
> > Algunas optimizaciones son costosas y la diferencia entre un compilador
> > estático y un JIT es que el usuario está ahí, esperando a que la
> > optimización se lleve a cabo.
>
> Muchas de esas optimizaciones que mencionás involucran probar
> propiedades del programa estáticamente, mirando sólo al código. Los
> JIT no necesitan eso. Los JIT insertan "guardas" (testeos para
> verificar que las asunciones se siguen cumpliendo) y listo, el resto
> del código puede proceder como si se hubiera hecho todo ese análisis.
>
>
No creo haber nombrado ninguna técnica de optimización en particular de los
JIT's.
Pero ninguna es Zero-cost, ya que se hace en runtime.
En ejecuciones largas, quizás pueda ser beneficioso, pero, uno también
puede obtener los mismos beneficios usando PGO y evitar optimizar en
runtime.



> > El GC es otro tema.
> > Con GC se requiere hacer un análisis en tiempo de ejecución para
> determinar
> > que memoria está siendo utilizada y cuál puede ser liberada. Y este
> análisis
> > puede ocurrir en cualquier momento y por una cantidad de tiempo
> indefinida.
> > Otro problema es cuando tenemos múltiples threads, cuando el GC se
> ejecuta,
> > todos los threads se pausan. Y por último, la mayoría de las
> > implementaciones no ejecutan el GC hasta que el sistema se queda sin
> > memoria.
> > Así que resumiendo: 1. nuestro sistema va a consumir cada vez más y más
> > memoria. 2. El programa se va a frizar aleatoriamente cuando el GC
> ejecute.
>
> Ese artículo tan popular sobre JavaScript y por qué Java nunca va a
> funcionar bien para celulares está lleno de falacias. Es cierto que
> las implementaciones todavía no pueden correr perfectamente en
> celulares, pero es "todavía".
>
>
¿Cuáles son las falacias? Las podemos analizar en detalle.
Hoy en día es una realidad y las aplicaciones escritas en ciertos
lenguajes, en celulares "se arrastran".



> Las técnicas clásicas de GC implementadas en las máquinas virtuales
> modernas, por ejemplo, no requieren pausas. Son incrementales o
> concurrentes, las primeras generan pausas pequeñas, las segundas no
> generan pausa alguna. En multi-threading, usan guarderías, una
> generación inicial local al thread, lo que hace que funcione mucho
> (pero *mucho*) mejor que, por ejemplo, C++ con new o malloc.
>
>
En los GC incrementales las pausas no son pequeñas. (y las pausas pequeñas
son pausas al fin y al cabo)
Y los GC concurrentes no están libres de pausas, las pausas se reducen con
respecto al anterior, pero las hay en caso de necesitar Full-GC.
Igualmente, más allá de que el usuario note una pausa o no, ¿todo este
análisis es sin costo?, y reitero, ¿qué pasa con los sistemas que requieren
determinismo?
Me agrego otra tarea, hacer un programita que provoque una pausa en un GC
Java Moderno y medirla.

Me queda una pregunta, ¿cómo es eso de "generación inicial local al
thread"? ¿qué es lo que es local al thread?



> Es común, cuando se quiere performance, en C++, empezar a eliminar el
> uso de malloc y a codear nuestro propio "allocator". En sí, el manejo
> de memoria sin GC no está libre de overhead, como cualquiera que haya
> programado en C++ algún sistema de alta performance debería saber.
>
>
En C y C++ muchas veces ni siquiera es necesario "allocar" memoria en el
free-storage (heap).
Pero en el caso de ser necesario, como dijiste, están los Allocators, y
también hay implementaciones de malloc mucho más eficientes, como por
ejemplo:
jemalloc (usada por defecto en FreeBSD)[1] y TCMalloc de Google[2], entre
otras.
Uno puede reemplazar malloc por alguna de estas. ( y también new, que por
defecto usa malloc )
Tarea nro 3: medir la eficiencia en "allocación" de memoria dinámica de
Java con su moderno GC contra C++ con mallocs modernos.



> Sin ir muy lejos, hay GC para C++. Uno muy común y muy usado, es el
> contador de referencias. Que es mucho más propenso a leaks que los GC
> que vienen ya embebidos en Java o Python. Yo personalmente aborrezco
> el GC de Java. Tiene ciertas características que lo hacen una hoja de
> doble filo muy peligrosa. Pero no por eso hay que creerse que C++ está
> libre de problemas, incluso excluyendo el error humano.
>
>
Sí, hay GC para C y C++, creo haberlo comentado, pero el GC es opcional.
Uno bien podría usar el "Boehm GC" (creado por Hans Boehm, miembro del C++
committee y colaborador de Alex Stepanov en Sillicon Graphics, por allá en
los 90's) o cualquier otro existente.
También existe el concepto de Ownership, Unique y Shared. Shared ownership
es implementado usando conteo de referencias.
Unique ownership es Zero-overhead con respecto a la implementación
"manual", es como hacer:

auto x = new X;
delete x;

El conteo de referencias tiene el problema de las referencias circulares,
pero es solucionado, en C++, usando Weak pointers. Igualmente no es muy
común casos como este.

Igual, de nuevo, todo esto es heap allocation, y en C++ no estamos obligado
a usarlo.

En C++ el concepto de ownership va más allá de la memoria, aplica a
recursos en general (files handles, sockets, conexiones a DB, etc...)

El error humano está en todos lados, un leak puede cometerse por olvidarse
eliminar un elemento de una Lista.

C++ realmente no está libre de problemas, para nada, pero uno que no tiene
es la eficiencia.

Saludos,
Fernando.

[1] http://www.canonware.com/jemalloc/
[2] http://goog-perftools.sourceforge.net/doc/tcmalloc.html



>
> [0] http://benchmarksgame.alioth.debian.org/u32/java.php
> _______________________________________________
> pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar
>

[Claudio Freire]

2014-03-04 23:51 GMT-03:00 Fernando Pelliccioni <fpelliccioni-***@public.gmane.org>:
> 2014-03-04 20:27 GMT-03:00 Claudio Freire <klaussfreire-***@public.gmane.org>:
>> Acá[0] tenés algunos ejemplos (para citar de nuevo the benchmark game).
>>
>
> Perdón, me perdí, ¿ejemplos con respecto a que cosa?
> Tengo pendiente chequear el código de algunos lenguajes y cuál es el
> mecanismo de medición.
> Después les digo.

Casos donde Java corre más rápido que C++

Ahí hay uno, aunque sólo uno. Es muy probable que la diferencia fuera
mucho mayor si Java pudiera evitar el overhead de memoria (que como
bien notaste, afecta el runtime).

Claro, hay otros casos donde funciona mucho más lento, y como bien
dijo alguien (vos?), no es muy predecible cuándo el JIT va a funcionar
bien y cuándo no. Bue, en realidad es bastante predecible a grandes
rasgos (no a lo preciso).

>> > Algunas optimizaciones son costosas y la diferencia entre un compilador
>> > estático y un JIT es que el usuario está ahí, esperando a que la
>> > optimización se lleve a cabo.
>>
>> Muchas de esas optimizaciones que mencionás involucran probar
>> propiedades del programa estáticamente, mirando sólo al código. Los
>> JIT no necesitan eso. Los JIT insertan "guardas" (testeos para
>> verificar que las asunciones se siguen cumpliendo) y listo, el resto
>> del código puede proceder como si se hubiera hecho todo ese análisis.
>>
>
> No creo haber nombrado ninguna técnica de optimización en particular de los
> JIT's.
> Pero ninguna es Zero-cost, ya que se hace en runtime.
> En ejecuciones largas, quizás pueda ser beneficioso, pero, uno también puede
> obtener los mismos beneficios usando PGO y evitar optimizar en runtime.

Sí, bue, estoy asumiendo. Igual, si leés la tesis que dio origen a
PyPy, vas a notar que las optimizaciones de los JIT son muy baratas en
comparación, en cuanto a análisis. Casi no hay. Es simplemente
instrumentación del bytecode para registrar cómo se ejecuta, y luego
optimizar el código más ejecutado asumiendo que va a seguir
cumpliéndose lo que vino cumpliéndose. Las guardas simplemente
verifican que así sea, y si deja de serlo, se pasa a ejecución de
bytecode nuevamente (hasta conseguir otro camino optimizado).

Es una idea elegante y muy efectiva.

>> Ese artículo tan popular sobre JavaScript y por qué Java nunca va a
>> funcionar bien para celulares está lleno de falacias. Es cierto que
>> las implementaciones todavía no pueden correr perfectamente en
>> celulares, pero es "todavía".
>>
>
> ¿Cuáles son las falacias? Las podemos analizar en detalle.
> Hoy en día es una realidad y las aplicaciones escritas en ciertos lenguajes,
> en celulares "se arrastran".

Me parece perfecto, sólo que no lo tengo a mano, tendría que re-leerlo.

OTOMH, decía "tiene y siempre va a tener overehead", lo cual es cierto
sólo superficialmente: el overhead no tiene por qué ser ni
considerable ni relevante. Es más, el overhead de JIT puede hasta
recuperarse con las optimizaciones de JIT.

>> Las técnicas clásicas de GC implementadas en las máquinas virtuales
>> modernas, por ejemplo, no requieren pausas. Son incrementales o
>> concurrentes, las primeras generan pausas pequeñas, las segundas no
>> generan pausa alguna. En multi-threading, usan guarderías, una
>> generación inicial local al thread, lo que hace que funcione mucho
>> (pero *mucho*) mejor que, por ejemplo, C++ con new o malloc.
>>
>
> En los GC incrementales las pausas no son pequeñas. (y las pausas pequeñas
> son pausas al fin y al cabo)

Cierto. Yo mismo lo estoy sufriendo en una app que necesita casi
real-time (tiene requerimientos de latencia muy estrictos), y CPython
mismo me genera pausas molestas.

> Y los GC concurrentes no están libres de pausas, las pausas se reducen con
> respecto al anterior, pero las hay en caso de necesitar Full-GC.

No hay razón teórica para requerir full-gc. Eso en general sucede
cuando el proceso de GC no da a basto para limpiar la memoria
suficientemente rápido, problema que tiene Java (y los GC del estilo
de Java), pues permiten que la aplicación cree objetos mucho más
rápido de lo que puede limpiarlos el GC. Pero hay mucha literatura al
respecto que sería aplicable, no me sorprendería que fuese
desapareciendo ese problema (no en Java, Java ya está casi frizado en
ese respecto, pero otras implementaciones más modernas como PyPy
pueden llegar a evitar ese problema).

> Igualmente, más allá de que el usuario note una pausa o no, ¿todo este
> análisis es sin costo?, y reitero, ¿qué pasa con los sistemas que requieren
> determinismo?

El costo no necesariamente es prohibitivo, y a eso voy. Depende de la
aplicación, es posible que Java o PyPy sea mucho mejor que C++. Por
ejemplo, cuando lo que importa es el thoughput, o cuando el
requerimiento de latencia sea permisivo.

Por ejemplo, en mi app, que necesita latencias aseguradas, aún así
PyPy me viene de maravilla. Las pausas son manejables, y estoy
completamente seguro (porque he programado mucho C++) que implementar
el mismo sistema en C++ me hubiera llevado mucho más tiempo, sin
conseguir mucha más performance.

> Me agrego otra tarea, hacer un programita que provoque una pausa en un GC
> Java Moderno y medirla.

Java es un paseo por el parque. Te recomendaría Python (es más difícil
hacerlo pausarse, pero posible).

> Me queda una pregunta, ¿cómo es eso de "generación inicial local al thread"?
> ¿qué es lo que es local al thread?

Se llaman guarderías[0]. En el link, hacen una diferencia entre las
guarderías normales (nursery) y las thread-local (TLA). Es el mismo
concepto, llevado a más detalles. La idea está igual.


>> Es común, cuando se quiere performance, en C++, empezar a eliminar el
>> uso de malloc y a codear nuestro propio "allocator". En sí, el manejo
>> de memoria sin GC no está libre de overhead, como cualquiera que haya
>> programado en C++ algún sistema de alta performance debería saber.
>>
>
> En C y C++ muchas veces ni siquiera es necesario "allocar" memoria en el
> free-storage (heap).

En Java también[0].

> Pero en el caso de ser necesario, como dijiste, están los Allocators, y
> también hay implementaciones de malloc mucho más eficientes, como por
> ejemplo:
> jemalloc (usada por defecto en FreeBSD)[1] y TCMalloc de Google[2], entre
> otras.
> Uno puede reemplazar malloc por alguna de estas. ( y también new, que por
> defecto usa malloc )
> Tarea nro 3: medir la eficiencia en "allocación" de memoria dinámica de Java
> con s,u moderno GC contra C++ con mallocs modernos.

Va más allá de eso. Ningún allocator genérico funciona a veces, y
tenés que ir a pools o freelists. Para eso la stdlib tiene los
allocators configurables en cada colección. La performance de malloc
es tan poco aceptable, que incluso CPython no usa malloc puro. No hay
VM respetable que use malloc puro. Es simplemente muy lento para hacer
todo con malloc.

La falta de facilidades básicas para administrar la memoria de maneras
más inteligentes fue justamente central en c++0x. C++, aunque es
genial y lo banco, está muy por detrás de cualquier lenguaje dinámico
en cuanto a administración de memoria. Lo groso es que te da libertad
absoluta. Pero lo malo, es que tenés que trabajar con el equivalente
informático del martillo y cincel.

> El conteo de referencias tiene el problema de las referencias circulares,
> pero es solucionado, en C++, usando Weak pointers. Igualmente no es muy
> común casos como este.

Hay casos que las referencias débiles no te solucionan. Yo en Python
mismo las uso mucho, porque no me gusta abusar del colector de ciclos.
Pero no siempre son la solución. En esos casos, en C++ se complica
bastante.

> Igual, de nuevo, todo esto es heap allocation, y en C++ no estamos obligado
> a usarlo.

Bue, eso es exageración. Es como decir que no estamos obligados a usar
un monitor. Y, claro, no hace falta. Pero no tenerlo y que te pisotee
un camión Scania no es muy diferente.

> C++ realmente no está libre de problemas, para nada, pero uno que no tiene
> es la eficiencia.

Me gustaría que pruebes MySQL workbench.

Cuando lo levanté, hubiera jurado que estaba hecho en Java. Porque
tarda día y medio en levantar[*]. Pero no... es C++.

[0] http://docs.oracle.com/cd/E13150_01/jrockit_jvm/jrockit/geninfo/diagnos/garbage_collect.html
[*] Exagero, pero casi
_______________________________________________
pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
http://listas.python.org.ar/listinfo/pyar

PyAr - Python Argentina - Sitio web: http://www.python.org.ar/

La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de Argentina - http://www.usla.org.ar

[Alejandro Santos]

2014-03-04 2:29 GMT+01:00 Fernando Pelliccioni <fpelliccioni-***@public.gmane.org>:
>
> Realmente no conozco nada de Common-Lisp, pero que sea un lenguaje dinámico
> y tenga GC me hace creer que no es muy eficiente.
>

El GC fue inventado por la gente de LISP para resolver el problema de
las dependencias circulares[1], y muchos de los algoritmos modernos ya
sea de Java, .Net, etc, estan inspirados en este trabajo.

De todas formas no creo que por decir que "tenga GC" sea razon
suficiente para decir que no sea muy eficiente. Depende mucho de la
vara de bambu que uses para medir, porque por ejemplo tenes estos
micro benchmarks donde C++ es solo el doble de r'apido que (SBCL) LISP
y Haskell:

http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=sbcl&lang2=gpp&data=u64
http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=ghc&lang2=gpp&data=u64

Ambos con Garbage Collection.

Me gusto mucho la pregunta de Claudio Freire porque todo depende de lo
que cada uno entienda "Expresivo", porque si por expresivo queres
decir que queres usar hasta la ultima capacidad de expresion de tu
CPU, deberias estar usando ASM ya que es la unica manera de usar cada
posible optimizacion.

A mi personalmente me parece que, en general, un lenguaje de
programacion es una forma para que los programadores nos comuniquemos
ideas entre nosotros, y en menor medida como un mecanismo para
comunicarse con una computadora.

Es cierto que hay algunos problemas que se requiere eficiencia bruta y
cruda, pero otros donde no es tan importante el tiempo "wall clock" de
ejecucion sino la productividad de los programadores. Esto es asi
cuando hay que tener en cuenta la economia completa del proyecto:
?qu\'e es m\'as barato, comprar m\'as procesamiento o pagarle a mas
programadores?

Si en cambio estas trabajando en un proyecto donde estas vos por tu
cuenta entonces usa el lenguaje que mas comodo te resulte.

Aca donde trabajo usamos C++, Java y Python. C++ para codigo con
fuertes limitaciones de tiempo que corran en el datacenter (10,000
servidores), Python para programas que no importe la eficiencia de CPU
o memoria, y Java para todo lo demas.

[1] http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29


--
Alejandro Santos
_______________________________________________
pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
http://listas.python.org.ar/listinfo/pyar

PyAr - Python Argentina - Sitio web: http://www.python.org.ar/

La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de Argentina - http://www.usla.org.ar

[Fernando Pelliccioni]

2014-03-04 10:38 GMT-03:00 Alejandro Santos <listas-***@public.gmane.org>:

> 2014-03-04 2:29 GMT+01:00 Fernando Pelliccioni <fpelliccioni-***@public.gmane.org>:
> >
> > Realmente no conozco nada de Common-Lisp, pero que sea un lenguaje
> dinámico
> > y tenga GC me hace creer que no es muy eficiente.
> >
>
> El GC fue inventado por la gente de LISP para resolver el problema de
> las dependencias circulares[1], y muchos de los algoritmos modernos ya
> sea de Java, .Net, etc, estan inspirados en este trabajo.
>
> De todas formas no creo que por decir que "tenga GC" sea razon
> suficiente para decir que no sea muy eficiente. Depende mucho de la
> vara de bambu que uses para medir, porque por ejemplo tenes estos
> micro benchmarks donde C++ es solo el doble de r'apido que (SBCL) LISP
> y Haskell:
>
>
> http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=sbcl&lang2=gpp&data=u64
>
> http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=ghc&lang2=gpp&data=u64
>
> Ambos con Garbage Collection.
>
>

En general, sobre los benchmarks:
A veces los benchmarks pueden ser manipulados para obtener uno u otro
resultado.
Para considerar cualquier benchmark como una prueba, en mi opinión, tendría
que confiar que la fuente y verificar que haya buena intensión.
A veces es imposible probarlo, así tendría ponerme a analizar el código
fuente de los lenguajes que están siendo comparados.
Hay veces que los benchmarks son escritos por expertos de un lenguaje X,
comparándose contra código ineficiente implementado en un lenguaje Y.
También hay que ser conscientes a veces no estamos comparando lenguajes,
sino implementaciones de los mismos. (No es lo mismo comparar Java contra
C++ compilado usando MSVC, por ejemplo)
(Fin de pensamientos acerca de Benchmarks)

Ahora específicamente sobre tus ejemplos, no vi los links pero decís que
"solo es el doble de rápido".
Para mí el doble de rápido es "un montón". El doble de rápido puede
significar el doble de energía consumida, la mitad de la batería de tu
celular, el doble de usuarios concurrentes, la mitad de $$$, etc...

Fíjense el video este video, a desde 00:02:45, hasta 00:03:30, menos de un
minuto (Seguramente ya lo viste)
El que habla es un investigador que actualmente trabaja en Facebook.
Y dice que midieron que una mejora de un 1% en el JIT Compiler significa
aprox. 10 años de sueldo del programador mejor pago.

http://channel9.msdn.com/Events/GoingNative/2013/Writing-Quick-Code-in-Cpp-Quickly

Así, ¿cuánto significaría 2x para Facebook? Mucha $$$



> Me gusto mucho la pregunta de Claudio Freire porque todo depende de lo
> que cada uno entienda "Expresivo", porque si por expresivo queres
> decir que queres usar hasta la ultima capacidad de expresion de tu
> CPU, deberias estar usando ASM ya que es la unica manera de usar cada
> posible optimizacion.
>
>
Es un muy buen punto, por eso me pareció piola hacer el PingPong Python /
C++ sobre "expresividad" ya que quizás podía cambiar su opinión.
Pero creo que es al revés, que expresivo significa "capacidad de
abstracción", cuando más expresivo más nos alejamos de assembly code.



> A mi personalmente me parece que, en general, un lenguaje de
> programacion es una forma para que los programadores nos comuniquemos
> ideas entre nosotros, y en menor medida como un mecanismo para
> comunicarse con una computadora.
>
> Es cierto que hay algunos problemas que se requiere eficiencia bruta y
> cruda, pero otros donde no es tan importante el tiempo "wall clock" de
> ejecucion sino la productividad de los programadores. Esto es asi
> cuando hay que tener en cuenta la economia completa del proyecto:
> ?qu\'e es m\'as barato, comprar m\'as procesamiento o pagarle a mas
> programadores?
>


Comparto totalmente!
2x en rendimiento puede ser mucha $$$ para Facebook, pero quizás para
nuestra simple aplicación rinde más ganar un 2x de velocidad de
codificación de mis programadores.
Sin embargo, siempre que pienso en esto, me surgen sentimientos
encontrados. Se me cruza por la cabeza: el trabajo científico vs la
administración de la economía de una empresa por reducción del tiempo de
programación. A veces pensar en eso me da escalofríos.




>
> Si en cambio estas trabajando en un proyecto donde estas vos por tu
> cuenta entonces usa el lenguaje que mas comodo te resulte.
>
> Aca donde trabajo usamos C++, Java y Python. C++ para codigo con
> fuertes limitaciones de tiempo que corran en el datacenter (10,000
> servidores), Python para programas que no importe la eficiencia de CPU
> o memoria, y Java para todo lo demas.
>
>

Me parece genial el esquema.


> [1] http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29
>
>
> --
> Alejandro Santos
> _______________________________________________
> pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar
>


Un abrazo,
Fernando.

[r***@public.gmane.org]

Hola,

Hace mucho que no escribo en la lista, pero ahora que me confirmaron que estoy seleccionado para ser un desarrollador para un dispositivo nuevo y, que a mi entender, revolucionario, es que quiero armar un equipo.


En primera medida, me gustaría contactar con gente que esté estudiando o cursando o tenga relación con la UNQUI (Universidad Nacional de Quilmes).

Motivos:


Yo soy de Bernal y trabajo en Bernal, casi ni cruzo el riachuelo a capital



Mi trabajo es a pocas cuadras de la UNQUI dónde hace un par de años se realizó la PyCon Ar.


Si mal no recuerdo Sebastián Bassi (creo que así se escribe) da clases allí y me gustaría hablar con él. (Perdí su mail)


Me gustaría presentar el proyecto a la UNQUI y que sea un proyecto Universitario.



Actualmente no estoy programando, estoy más como Analista Funcional, pero cada tanto no me cuesta nada arremangarme y ponerme el overol


Lo malo es que en mi trabajo se utilizan herramientas de Microsoft.

En forma particular también estoy como Asesor IT de un Partner de Microsof en Sao Paulo.

Pero este proyecto para el dispositivo que les voy a mostrar en un video oficial de la empresa Thalmic Labs, es muy interesante y quiero hacerlo con software libre.


Tengo varios proyectos para dicho dispositivo, no solo para manejar la interfaz de un juego, si no también para mejorar la calidad de vida de las personas discapasitadas, etc
.


Si creen que esto es un Off Topic, pido disculpas, pero también podría ser un Topic como #MYO y Python.

#MYO es el nombre del dispositivo, y este un video para enterarnos del potencial que puede tener:


http://www.youtube.com/watch?v=7o62TzZrw5s


Desde ya, muchas gracias


Roberto Luis Bozzacchi

@RLBozzacchi

https://www.facebook.com/rlbozzacchi

[Angel Java Lopez]

Podes ubicar a @sbassi por Twitter tmb


2014-03-04 14:56 GMT-03:00 <robbie-9sP+***@public.gmane.org>:

> Hola,
> Hace mucho que no escribo en la lista, pero ahora que me confirmaron que
> estoy seleccionado para ser un desarrollador para un dispositivo nuevo y,
> que a mi entender, revolucionario, es que quiero armar un equipo.
>
> En primera medida, me gustaría contactar con gente que esté estudiando o
> cursando o tenga relación con la UNQUI (Universidad Nacional de Quilmes).
> Motivos:
>
>
> 1. Yo soy de Bernal y trabajo en Bernal, casi ni cruzo el riachuelo a
> capital...
> 2. Mi trabajo es a pocas cuadras de la UNQUI dónde hace un par de años
> se realizó la PyCon Ar.
> 3. Si mal no recuerdo Sebastián Bassi (creo que así se escribe) da
> clases allí y me gustaría hablar con él. (Perdí su mail)
> 4. Me gustaría presentar el proyecto a la UNQUI y que sea un proyecto
> Universitario.
>
>
> Actualmente no estoy programando, estoy más como Analista Funcional, pero
> cada tanto no me cuesta nada arremangarme y ponerme el overol...
> Lo malo es que en mi trabajo se utilizan herramientas de Microsoft.
> En forma particular también estoy como Asesor IT de un Partner de Microsof
> en Sao Paulo.
> Pero este proyecto para el dispositivo que les voy a mostrar en un video
> oficial de la empresa Thalmic Labs, es muy interesante y quiero hacerlo con
> software libre.
>
> Tengo varios proyectos para dicho dispositivo, no solo para manejar la
> interfaz de un juego, si no también para mejorar la calidad de vida de las
> personas discapasitadas, etc....
>
> Si creen que esto es un Off Topic, pido disculpas, pero también podría ser
> un Topic como #MYO y Python.
> #MYO es el nombre del dispositivo, y este un video para enterarnos del
> potencial que puede tener:
>
> http://www.youtube.com/watch?v=7o62TzZrw5s
>
> Desde ya, muchas gracias...
> Roberto Luis Bozzacchi
> @RLBozzacchi
> https://www.facebook.com/rlbozzacchi
>
>
>
> _______________________________________________
> pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar
>

[r***@public.gmane.org]

Gracias Angel
. Ya lo sumo a mi twitter.








Enviado desde Correo de Windows





De: Angel Java Lopez
Enviado el: ‎martes‎, ‎04‎ de ‎marzo‎ de ‎2014 ‎15‎:‎55
Para: Python Argentina





Podes ubicar a @sbassi por Twitter tmb




2014-03-04 14:56 GMT-03:00 <***@metasigno.com>:




Hola,

Hace mucho que no escribo en la lista, pero ahora que me confirmaron que estoy seleccionado para ser un desarrollador para un dispositivo nuevo y, que a mi entender, revolucionario, es que quiero armar un equipo.




En primera medida, me gustaría contactar con gente que esté estudiando o cursando o tenga relación con la UNQUI (Universidad Nacional de Quilmes).

Motivos:




Yo soy de Bernal y trabajo en Bernal, casi ni cruzo el riachuelo a capital



Mi trabajo es a pocas cuadras de la UNQUI dónde hace un par de años se realizó la PyCon Ar.


Si mal no recuerdo Sebastián Bassi (creo que así se escribe) da clases allí y me gustaría hablar con él. (Perdí su mail)


Me gustaría presentar el proyecto a la UNQUI y que sea un proyecto Universitario.





Actualmente no estoy programando, estoy más como Analista Funcional, pero cada tanto no me cuesta nada arremangarme y ponerme el overol


Lo malo es que en mi trabajo se utilizan herramientas de Microsoft.

En forma particular también estoy como Asesor IT de un Partner de Microsof en Sao Paulo.

Pero este proyecto para el dispositivo que les voy a mostrar en un video oficial de la empresa Thalmic Labs, es muy interesante y quiero hacerlo con software libre.




Tengo varios proyectos para dicho dispositivo, no solo para manejar la interfaz de un juego, si no también para mejorar la calidad de vida de las personas discapasitadas, etc
.




Si creen que esto es un Off Topic, pido disculpas, pero también podría ser un Topic como #MYO y Python.

#MYO es el nombre del dispositivo, y este un video para enterarnos del potencial que puede tener:




http://www.youtube.com/watch?v=7o62TzZrw5s




Desde ya, muchas gracias


Roberto Luis Bozzacchi

@RLBozzacchi

https://www.facebook.com/rlbozzacchi








_______________________________________________
pyar mailing list ***@python.org.ar
http://listas.python.org.ar/listinfo/pyar

PyAr - Python Argentina - Sitio web: http://www.python.org.ar/

La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de Argentina - http://www.usla.org.ar

[Sebastian Bassi]

2014-03-04 14:56 GMT-03:00 <robbie-9sP+***@public.gmane.org>:


> 1. Yo soy de Bernal y trabajo en Bernal, casi ni cruzo el riachuelo a
> capital

>
>
Bien que haces. Horrible el viaje todos los dias a capital.


>
> 1. Si mal no recuerdo Sebastián Bassi (creo que así se escribe) da
> clases allí y me gustaría hablar con él. (Perdí su mail)
>
>
Soy graduado de la UNQ y he dado cursos de postgrado y algunas clases como
profesor invitado a un par de catedras, pero nunca fui profesor regular en
la UNQ.


>
> 1. Me gustaría presentar el proyecto a la UNQUI y que sea un proyecto
> Universitario.
>
>
Te puedo contactar con Leo Marina que tiene un cargo relevante para esto,
aunque no sé que se podrá hacer porque ya te anticipo que hay bastante
burocracia.
Y si el proyecto se termina haciendo con Python este mensaje no habrá sido
OT :)

[Roberto Bozzacchi]

El 5 de marzo de 2014, 14:33, Sebastian Bassi
<sebastian.bassi-***@public.gmane.org>escribió:

>
> Te puedo contactar con Leo Marina que tiene un cargo relevante para esto,
> aunque no sé que se podrá hacer porque ya te anticipo que hay bastante
> burocracia.
> Y si el proyecto se termina haciendo con Python este mensaje no habrá sido
> OT :)
>

Gracias Sebastián, le voy a escribir también a Fidel.
Yo me anoté para ser desarrollador del MYO de Thalmic Lab
Estoy en la lista de espera y todo....
Pero me gustaría armar un grupo para no estar sólo desarrollando....
Y porque para una de mis ideas necesitaré gente que entienda más de
electrónica que yo...

Pero bueno... desde ya agradezco a todos los que me fueron contestando...
Y estimo que se va a poder hacer en Python, aún no tengo acceso a la API,
pero estimo que no va a haber problemas...


--

Robbie Bozzacchi
Metasigno Brain

[Alejandro Santos]

2014-03-04 18:24 GMT+01:00 Fernando Pelliccioni <fpelliccioni-***@public.gmane.org>:
>
> En general, sobre los benchmarks:
> A veces los benchmarks pueden ser manipulados para obtener uno u otro
> resultado.
> Para considerar cualquier benchmark como una prueba, en mi opinión, tendría
> que confiar que la fuente y verificar que haya buena intensión.
>

Acá está explicado de qué trata el "The Benchmarks Game", basicamente
es un proyecto que existe desde el 2004 en alioth.debian.org y que
cualquiera puede enviar soluciones, la mejor enviada es la que queda:

http://benchmarksgame.alioth.debian.org/play.php

>
> Ahora específicamente sobre tus ejemplos, no vi los links pero decís que
> "solo es el doble de rápido".
>

Si mirás otros lenguajes, "solo el doble de rápido" está bastante bien,

http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=python3&lang2=gpp&data=u64

50x de mejora en promedio. Esto es, 5 segundos vs. 200 segundos.

>
> Así, ¿cuánto significaría 2x para Facebook? Mucha $$$
>

Si, y tenés toda la razón.

Pero también es todo muy relativo, porque Facebook maneja el concepto
del $$$ de manera muy diferente a vos y yo; por ejemplo ahora me estoy
haciendo unos fideos con manteca para calentarme la comida mañana
porque estoy tratando de ahorrar algo de plata, mientras que Facebook
gasta 19 mil millones de dolares en una empresa (que personalmente no
se si lo valía).

http://thingsthatarecheaperthanwhatsapp.tumblr.com/

Me encantan las discusiones académicas y ligeramente desligadas de la
realidad (soy docente por cierto) pero acá lo que estamos hablando
(creo) es qué pasa cuando alguien como nosotros que no tenemos la
billetera de Facebook se tiene que poner a codear en un lenguaje ya
existente.

Facebook hizo su propia implementación de PHP con su propio JIT. Creo
que la mayoría de los que está acá cuando quiere hacer su propio sitio
web no se pone a codear un compilador con JIT from scratch, se baja de
php.net/python.org/ruby-lang.net/java.sun.com la última versión, y a
picar código.

--
Alejandro Santos
_______________________________________________
pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
http://listas.python.org.ar/listinfo/pyar

PyAr - Python Argentina - Sitio web: http://www.python.org.ar/

La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de Argentina - http://www.usla.org.ar

[Fernando Pelliccioni]

2014-03-04 15:51 GMT-03:00 Alejandro Santos <listas-***@public.gmane.org>:

> 2014-03-04 18:24 GMT+01:00 Fernando Pelliccioni <fpelliccioni-***@public.gmane.org>:
> >
> > En general, sobre los benchmarks:
> > A veces los benchmarks pueden ser manipulados para obtener uno u otro
> > resultado.
> > Para considerar cualquier benchmark como una prueba, en mi opinión,
> tendría
> > que confiar que la fuente y verificar que haya buena intensión.
> >
>
> Acá está explicado de qué trata el "The Benchmarks Game", basicamente
> es un proyecto que existe desde el 2004 en alioth.debian.org y que
> cualquiera puede enviar soluciones, la mejor enviada es la que queda:
>
> http://benchmarksgame.alioth.debian.org/play.php
>
> >
> > Ahora específicamente sobre tus ejemplos, no vi los links pero decís que
> > "solo es el doble de rápido".
> >
>
> Si mirás otros lenguajes, "solo el doble de rápido" está bastante bien,
>
>
> http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=python3&lang2=gpp&data=u64
>
> 50x de mejora en promedio. Esto es, 5 segundos vs. 200 segundos.
>
> >
> > Así, ¿cuánto significaría 2x para Facebook? Mucha $$$
> >
>
> Si, y tenés toda la razón.
>
> Pero también es todo muy relativo, porque Facebook maneja el concepto
> del $$$ de manera muy diferente a vos y yo; por ejemplo ahora me estoy
> haciendo unos fideos con manteca para calentarme la comida mañana
> porque estoy tratando de ahorrar algo de plata, mientras que Facebook
> gasta 19 mil millones de dolares en una empresa (que personalmente no
> se si lo valía).
>
> http://thingsthatarecheaperthanwhatsapp.tumblr.com/
>
> Me encantan las discusiones académicas y ligeramente desligadas de la
> realidad (soy docente por cierto) pero acá lo que estamos hablando
> (creo) es qué pasa cuando alguien como nosotros que no tenemos la
> billetera de Facebook se tiene que poner a codear en un lenguaje ya
> existente.
>
> Facebook hizo su propia implementación de PHP con su propio JIT. Creo
> que la mayoría de los que está acá cuando quiere hacer su propio sitio
> web no se pone a codear un compilador con JIT from scratch, se baja de
> php.net/python.org/ruby-lang.net/java.sun.com la última versión, y a
> picar código.
>
> --
> Alejandro Santos
> _______________________________________________
> pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar
>



Comparto lo que decís, pero ignoro si Alejandro va a hacer un sitio web
para una ferretería o tiene que re-escribir Facebook.
Supongo que en Facebook decidieron hacer su propio JIT compiler porque les
salía más barato que re-escribirlo en un "lenguaje eficiente".

Igual, estamos hablando de Web, pero Alejandro menciono Common-Lisp, y
desconozco totalmente, pero supongo que no es un lenguaje muy amigable con
la web, ya que imagino que no tendrá tantas bibliotecas y frameworks como
tienen otros lenguajes.
Así que de movida supuse que no era Web lo que quería hacer, quizás estoy
equivocado.

Nunca le presté atención a esos benchmarks, y eso que los he visto varias
veces. No sabía que uno podía postear código. Me voy a poner a revisar un
poco.
¡Gracias por el link!

Abrazo.

[Alejandro Zamora Fonseca]

Bueno, en mi muy humilde opinión tengo que decir que para mi Common
Lisp es u

--

Este mensaje le ha llegado mediante el servicio de correo electronico que ofrece Infomed para respaldar el cumplimiento de las misiones del Sistema Nacional de Salud. La persona que envia este correo asume el compromiso de usar el servicio a tales fines y cumplir con las regulaciones establecidas

Infomed: http://www.sld.cu/

_______________________________________________
pyar mailing list pyar-+ZN9ApsXKcFd+***@public.gmane.org
http://listas.python.org.ar/listinfo/pyar

PyAr - Python Argentina - Sitio web: http://www.python.org.ar/

La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de Argentina - http://www.usla.org.ar

[Enrique Gabriel Baquela]

Muy buena elección!!!. Ya que sos lispero y pythonero, quizás te interese
esto también: http://hy.readthedocs.org/en/latest/
Saludos!!!!

Enrique Gabriel Baquela
http://www.egbaquela.com.ar
http://www.modelizandosistemas.com.ar
http://www.gisoiweb.com.ar
http://ar.linkedin.com/in/egbaquela
Skype ID: egbaquela


El 3 de marzo de 2014, 12:09, Alejandro Zamora Fonseca
<terefv-pNGfD4lFfPfph/***@public.gmane.org>escribió:

> Bueno gracias por las últimas sugerencias.
> Fernado, yo siempré respetaré a C/C++, de hecho de ahí provengo, los
> prefiere frente a Java, pero, aunque no esté actualizado en el tema de los
> últimos "releases" de C++ creo que Python es más expresivo que ellos.
> De todas formas es verdad que para muchas cosas es muy difícil
> desprenderse de ellos, pero para ese proyecto ya me decidí por
> Lisp(específicamente Common Lisp (CL)) porque es tan o más expresivo que
> Python, normalmente es casi tan eficiente como C/C++(se dice que hay
> algunas implementaciones que incluso son más rápidas) y muchas otras cosas
> más... pero bueno no me voy a poner a hacer ping-pong yo tampoco jaja
> Para mi de ahora en adelante(si no pasa otra cosa) hay 4 lenguajes Python,
> LISP(la familia, pero CL ppalmente) y C/C++, me gustaría pensar que con
> alguna combinación de ellos puedo atacar cualquier problema.
> ahh!! y gracias por el link, voy a echarle un vistazo...
>
> un abrazo
> Alejandro
>
>