Conclusiones Erradas

Investigando sobre Lisp, he encontrado muchísimos textos. Tutoriales, lecciones, ejercicios, y más.

Lisp es un lenguaje poderoso, y sus macros lo hacen maravillosamente modificable. Lisp se basa en unas cuantas funciones básicas, en una manera como axiomas matemáticos. A partir de estas bases se puede crear un intérprete para el lenguaje… Pero divago… (pueden encontrar más información en el sitio de Paul Graham.

Como dije antes, en algún post perdido, algo que me molesta de los juegos es que para jugar a un juego nuevo es necesaria una computadora nueva.

Entiendo que es bueno mantener el código claramente legible, y que ciertas optimizaciones lo ofuscan. También sé que es necesaria la exactitud (excepto en algunos medios, como los gráficos y el sonido, por eso los codecs con pérdidas son aceptables), y sólo se puede conseguir hasta cierto punto… y que la optimización, eventualmente, llega al debate entre memoria ocupada, y tiempo de procesador.

Pero aún así, lo que más me molesta es una frase que se ocupa obsesivamente: «¿Para qué optimizar, si se puede conseguir la misma ganancia con más hardware?». Una actualización para todos: Eso recién se aplica cuando el coste de la optimización (en horas-hombre de programación) es notablemente mayor que el del hardware. Y, además, hay que tomar en cuenta que si un programa no-optimizado funciona bien con mejor hardware, y uno optimizado funciona bien con el hardware viejo, el código optimizado y hardware nuevo van a dar ¡aún mejores resultados!…

Pero bien, si empecé hablando de Lisp es por una razón: Un documento que estaba leyendo decía que Lisp, como lenguaje de alto nivel, es más lento que uno de bajo nivel, pero «Lisp no es lento, era el hardware que era insuficiente»… Aunque coincido con la parte de que casi no hay excusas para no usar Lisp hoy en día, Lisp sigue siendo lento. Espectacular, pero lento. (Lisp está lejos de ser la primera opción para una librería gráfica…)

powered by performancing firefox