[pyar] ¿Volvemos a empezar?

Fernando Pelliccioni fpelliccioni en gmail.com
Mie Abr 30 16:48:43 ART 2014


Hola Ángel,

Estoy de acuerdo en casi todo, salvo en lo de fibonacci y demás, me gustan
los algoritmos relacionados con teoría de números :)
Pueden parecer sin utilidad, pero a veces las utilidades están, pero no las
conocemos o se descubren en un futuro.

Tiro una que puede parecer una boludés...
   - Determinar si una secuencia de elementos es un palíndromo.
Parece un ejercicio de introducción a la programación, ... , pero... si les
va, la hacemos (sin medir tiempos, no hace falta) y después vemos la
utilidad.

Saludos,
Fernando.





2014-04-30 16:23 GMT-03:00 Angel Java Lopez <ajlopez2000 en gmail.com>:

> Bien, comento algunas cosas:
>
> - Los benchmarks tipo fibonacci y demas, pueden ser interesantes, pero no
> se, se me hace que no ganamos mucho. Es una primera aproximacion al tema de
> la velocidad de los lenguajes, pero puede que no nos acerquemos a algo real.
>
> - Los que involucran entrada/salida (de disco, red), pienso que caen fuera
> de la esfera del lenguaje. Tal vez a discutir mas tarde
>
> - Mas interesante me parece comparar, conseguir datos de velocidades de
> algunos escenarios que veo mas comunes.
>
> Los tres escenarios que se me ocurren ahora:
>
> - Cuan veloces seran las implementaciones de, digamos, un Redis en
> memoria, en proceso (key-value store), en C vs Java, vs C#, vs Python, vs
> Ruby, vs JavaScript. No me preocuparia por multithreading, como tampoco lo
> hace Redis. Hay diferencias de velocidad de ejecucion? Luego de un Redis,
> no se, un MongoDB en memoria, en proceso (quiero decir, no un servidor que
> escucha por una puerta TCP/IP. En ambos casos, Redis, MongoDB, me imagino
> una implementacion de una libreria en memoria, sin usar disco ni red)
>
> - El otro escenario, es la serializacion. Ejemplo: una aplicacion web que
> tiene que devolver un JSON, cuanto tarda en armarlo? O en leer y pasarlo a
> un objeto nativo? O aplicaciones que tienen que mandar un mensaje a otra
> aplicacion, cuando tarda en serializar el mensaje y luego en
> deserializarlo? Saquemos la red de la ecuacion. Tenemos un arreglo de bytes
> o caracteres, deserializar eso a un objeto, y un objeto, serializarlo a
> bytes o caracteres.
>
> - Y otro escenario: cuantos mensajes se pueden procesar en memoria? Me
> imagino comparar procesos de Akka (actor model en Java/Scala), Erlang, y
> demas lenguajes. Por ejemplo, la gente de Akka menciona que puede procesar
> 3 millones de mensajes (simples me imagino) por segundo. No encontre la
> referencia. Yo en C#, en una notebook, llegue a 1.5 millones de mensajes
> por segundo. Ni quiero probar en JavaScript ;-)
>
> Bueno, me imagino eso
>
> Comentarios?
>
> Nos leemos!
>
> Angel "Java" Lopez
> @ajlopez
>
>
>
> 2014-04-30 16:07 GMT-03:00 Fernando Pelliccioni <fpelliccioni en gmail.com>:
>
> Gracias capo!
>> También acepto tus disculpas...
>>
>> Un abrazo para vos!
>>
>>
>> 2014-04-30 15:49 GMT-03:00 Pablo Gabriel Celayes <pablocelayes en gmail.com>
>> :
>>
>> Disculpas aceptadas. De mi parte también las pido por prejuzgarte como
>>> incapaz de autocrítica, cuando ahora gratamente descubro que no es así. :)
>>>
>>> Te creo que no fue de mala leche el mail original, nunca tuve dudas de
>>> eso, es cómo se manejó la cosa de ahí en más lo que no me cerraba. Pero
>>> buenísimo que nos tranquilicemos todos y empecemos a sacar provecho de lo
>>> que, más allá de ese ruido, era un propuesta interesante.
>>>
>>> Saludos, un abrazo y bienvenido!
>>>
>>>
>>> 2014-04-30 15:33 GMT-03:00 Fernando Pelliccioni <fpelliccioni en gmail.com>
>>> :
>>>
>>>> Gente,
>>>>
>>>> Eliminé mis comentarios inapropiados de Youtube, los hice por calentura
>>>> y estuvo muy mal.
>>>>
>>>> Tuve una charla que con Joaquín, que me ayudó a serenarme un poco y
>>>> entender como funcionan como comunidad.
>>>>
>>>> Les pido disculpas a todos por juzgarlos como comunidad, metí a todos
>>>> en la misma bolsa, estuve mal.
>>>>
>>>> Mi email original no fue de mala leche, ni en pedo, espero puedan
>>>> creerme.
>>>>
>>>> Gracias Joaquín y saludos para todos!
>>>> Fernando.
>>>>
>>>> PD: Y si quieren que re-construyamos la charla sanamente, estoy
>>>> dispuesto!
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>
>>>
>>>
>>> --
>>>  *ıl**l**ıl**l**ı* ρąβℓ๏ *ıllı**lı*
>>> We are the problem. And we should provide the *solution*.
>>>
>>> _______________________________________________
>>> 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
>>>
>>
>>
>> _______________________________________________
>> 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
>>
>
>
> _______________________________________________
> 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
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20140430/48a3b314/attachment.html>


More information about the pyar mailing list