Estoy en el proceso de aprender a programación, comencé estudiando python y he realizados pequeños proyectos en python, mi curiosidad me llevo a leer el libro HTDP v2 y aprender racket. ¿ Por qué cuando paso de python a racket siento que se me lleva pensar en el problema de una manera mas eficiente?
La evolución histórica de la computación (que «ganó» Turing en lugar de Kleene o Church) y la electrónica, llevaron a que las máquinas modernas sean sumadoras sobre estado mutable. Los lenguajes de programación, y la manera de enseñarlos, apuntaron a ser metáforas de nivel más alto que la máquina — por eso han sido imperativos y se enseñan con el nefasto modelo de «hay unas cajitas en memoria», «cuidado cómo cambias las cajitas, necesitas cajitas temporales», «tienes que repetir/acumular los cambios en las cajitas» y el resto de esa letanía. Esa es una realidad, y ahora con el fanatismo de «I want to be a coder», casi todo el mundo entra por allí — «tradición» y «costumbrismo», que, valga comentar, es necesario en algunos escenarios, porque para hacer el software *realmente* importante (sistemas de operación y compiladores) necesitas dominar el modelo imperativo.
El modelo mental necesario para expresar un problema funcionalmente deja mucho menos espacio a errores que para expresar el mismo problema imperativamente. Cuando aprendas Haskell, verás que el modelo funcional apuntalado en un sistema de tipos estricto, estático y generalizable, es aún más ameno de emplear. En general, hay que pensar más para terminar escribiendo menos, porque ya no tienes que preocuparte por temas de aliasing, errores de borde flagrantes, contar antes de procesar, ni la mezcla «qué hacer»/«cuándo hacerlo»/«cómo hacerlo», porque la separación de preocupaciones no es un artefacto construido (como los «patrones OO») sino que forma parte de la construcción de expresiones fundamentales del lenguaje (sea Racket, Haskell, Erlang o cualquier otro realmente funcional).
Y como la gente que escribe el software *realmente* importante se ha tomado la molestia de estudiarlo, resulta que las construcciones funcionales son susceptibles de generar código de máquinas más eficiente en tiempo y espacio, casi siempre. Y esto se vuelve aún más importante, en nuestro mundo moderno de muchos núcleos: si programas con hilos y estado mutable, «sopórtala»; cosa que no nos pasa a los que hacemos lo mismo en lenguajes funcionales puros. El beneficio final es que te concentras en expresar el programa como transformación de expresiones, y el compilador se encarga de traducir eso a estado mutable e interacciones entre flujos de ejecución.
Así, tú usas el lenguaje matemático más elevado para expresar la solución a los problemas, y el compilador se encarga de convertirlo a «sumas sobre estado mutable». Después de todo, la computadora es la que debe trabajar, no uno.
Disfruta el camino y no te dejes confundir con los que venden lenguajes imperativos haciendo creer que son funcionales. Tampoco desprecies a los lenguajes imperativos, porque los necesitas cuando tienes que estar cerca de la máquina, o para poder conversar con los que aún no han tenido su momento «¡ajá!» con la programación funcional.
El modelo mental necesario para expresar un problema funcionalmente deja mucho menos espacio a errores que para expresar el mismo problema imperativamente. Cuando aprendas Haskell, verás que el modelo funcional apuntalado en un sistema de tipos estricto, estático y generalizable, es aún más ameno de emplear. En general, hay que pensar más para terminar escribiendo menos, porque ya no tienes que preocuparte por temas de aliasing, errores de borde flagrantes, contar antes de procesar, ni la mezcla «qué hacer»/«cuándo hacerlo»/«cómo hacerlo», porque la separación de preocupaciones no es un artefacto construido (como los «patrones OO») sino que forma parte de la construcción de expresiones fundamentales del lenguaje (sea Racket, Haskell, Erlang o cualquier otro realmente funcional).
Y como la gente que escribe el software *realmente* importante se ha tomado la molestia de estudiarlo, resulta que las construcciones funcionales son susceptibles de generar código de máquinas más eficiente en tiempo y espacio, casi siempre. Y esto se vuelve aún más importante, en nuestro mundo moderno de muchos núcleos: si programas con hilos y estado mutable, «sopórtala»; cosa que no nos pasa a los que hacemos lo mismo en lenguajes funcionales puros. El beneficio final es que te concentras en expresar el programa como transformación de expresiones, y el compilador se encarga de traducir eso a estado mutable e interacciones entre flujos de ejecución.
Así, tú usas el lenguaje matemático más elevado para expresar la solución a los problemas, y el compilador se encarga de convertirlo a «sumas sobre estado mutable». Después de todo, la computadora es la que debe trabajar, no uno.
Disfruta el camino y no te dejes confundir con los que venden lenguajes imperativos haciendo creer que son funcionales. Tampoco desprecies a los lenguajes imperativos, porque los necesitas cuando tienes que estar cerca de la máquina, o para poder conversar con los que aún no han tenido su momento «¡ajá!» con la programación funcional.