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

[Fernando Pelliccioni]

2014-03-03 22:22 GMT-03:00 Fernando Pelliccioni <fpelliccioni en gmail.com>:

>
>
>
> 2014-03-03 19:00 GMT-03:00 Claudio Freire <klaussfreire en gmail.com>:
>
> 2014-03-03 12:09 GMT-03:00 Alejandro Zamora Fonseca <terefv en ltu.sld.cu>:
>> > 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 en 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
>>
>
>
>
> 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.
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20140303/7d65749e/attachment-0001.html>