Barrapunto

No le veo ninguna lógica a dedicar esfuerzos para posicionar Ruby por encima de Python o al revés. Lo que está claro es que cualquiera de los dos le dá mil vueltas a lenguages más tradicionales como C++, Java, VB o COBOL (si, todavía hay gente programando en COBOL). Si, si, ja sé que existe un 5% de los proyectos donde la velocidad de ejecución es algo crítico, pero para el 95% restante la velocidad de desarrollo y la claredad del resultado es lo realmente crítico.

¿Comparando python con cobol? A esto le llamo yo mezclar churras con merinas.

Llevo muchos años en un campo, concretamente el de las aplicaciones de gestión, y he usado multitud de leguages. Por lo tanto, al menos en ese campo, creo que tengo cierto criterio. En ese mundo los criterios son 1) Productividad 2) Productividad y 3) Productividad. Como criterios complementarios están 4) Que el resultado sea mantenible y 5) Que el rendimiento sea suficiente para que el listado salga en el tiempo de hacerse un café

Te doy toda la razón con sistema embebido, que entraría dentro del 5% de los casos que comentaba.

Joer, chaval, ¿ a ti te suspendieron en lógica, verdad ?

El otro dia me lei un articulo [kapcoweb.com] sobre LISP. Ponen un ejemplo de exito de una aplicación escrita en LISP, y el proyecto no consistia en rellenar el temario de una asignatura de Inteligencia Artificial :-)

Hay un par de cosas de ese articulo que me parecen muy interesantes:
1.- En ensamblador existe el patrón llamada a función. No es lo mismo pasar los parametros por registro, pila o pagina cero (como en el 6502). Con C desaparece el patron llamada a función porque de eso se encarga el compilador. LISP necesita menos patrones que C++. ¿Crees que un programador de python necesita saber más o menos patrones que uno de C++? ¿En que campos te aporta esto una ventaja?
2.- Otro punto interesante de vista es el tema de la complejidad maxima que cabe en la cabeza de un programador. Hay cosas que mantenerlas en la cabaza es facil en python, laborioso en C++, complejo en C (mardita ausencia de namespaces) y practicamente imposible en ensamblador. Mientras que se puede hecer con muy pocas lineas un quicksort en un lenguaje interpretado, ¿te atreverías a hacer algo más complejo que la ordenación por burbuja en ensamblador? Esto hay que extrapolarlo a cada linea de código que realices en tu aplicación. Recuerdo que cuando era chaval y queria hacerme un videojuego lei: "Programa rapido en C y lo que vaya lento optimizalo en ASM, asi podras probar rapido la funcionalidad." Y eso hacia entonces, ahora digo: "Optimiza el algoritmo en un lenguaje interpretado y cuando necesites velocidad o no desperdiciar memoria reescribelo en C".
Y el que se haya leido el articulo vera que los ejemplos que pongo son lo que yo he interpretado de este, que nadie me diga que no pone el ejemplo de la programación de videojuegos, que ya lo se ;-)