Barrapunto

Esta es una de las ventajas de alto nivel que a todos los que van de supergurús del C se les olvida. Cuando trabajas a alto nivel, el compilador tiene más información, así que puede optimizar mejor el código. En cambio, en un lenguaje de alto nivel tiene que fiarse más del programador.

Por otro lado, me agrada que cada vez se hable más de los lenguajes funcionales ;)

El término "lazy", referido a lenguajes de programación, nunca lo había leído en el contexto de control estricto/laxo de tipos, sino sobre evaluación "perezosa", o diferida, de expresiones. De forma que si una expresión aparece varias veces en el código, sólo hay que evaluarla una vez, cuando ya no queda más remedio para saber el valor final de una expresión compleja (en una orden condicional, por ejemplo). Es una técnica muy común en lenguajes funcionales para evitar evaluar expresiones innecesarias si el flujo del programa se va por otros derroteros.

Lo bueno es que no se programa de manera estricta, lo que hace en el artículo es programar de manera no estricta y es luego el compilador el que se encarga de analizar el programa y optimizar las partes del programa en que puede suponer una ventaja ejecutarlas de manera estricta.

En el wikibook se explica por qué puede suponer un problema ejecutar de modo no estricto algunas partes del código [wikibooks.org], aunque no termina de dejarlo muy claro. Hay un artículo mucho mejor en el wiki de haskell.org [haskell.org].

En resumen, al ser no estricto el compilador no puede evaluar los argumentos de una función y pasarselos a la función, tiene que guardar en memoria la expresión en suspensión por si acaso es necesario evaluarla después. Guardar las expresiones resulta costoso e innecesario si tienen que ser evaluadas de todos modos.

Por eso compiladores como GHC permiten hacer un análisis para intentar determinar que argumentos de funciones van a ser evaluados siempre, y evaluarlos de forma estricta con la consiguiente ganancia de rendimiento.

Si te interesa profundizar más en el tema mirate el segundo enlace que he puesto, es bastante interesante.

El artículo dice que el Haskell compilado pasa pruebas que permiten determinar cuándo hace falta ser estricto y cuándo no, para optimizar. Así, la optimización sólo se lleva a cabo cuando hace falta, sin que tengas que preocuparte de programar como si fuera estricto: ya lo resuelve por ti el compilador.