EM Hernández-Novich

Cuando se dice que el conocimiento es libre, lo que se afirma es que el conocimiento está allí para que cualquiera lo tome por su propio esfuerzo. Si se tiene la habilidad, la dedicación y la motivación, se puede crear nuevo conocimiento. Pero para los menos afortunados, están los libros. Hay muchos libros muy buenos, muy densos y muy complejos que permiten adquirir conocimiento extenso sobre variados temas. Son mucho mejores que Google, porque en lugar de darte una respuesta rumiada, te obligan a razonar, representar, articular y construir to propio modelo de conocimiento. Es la diferencia entre jugar ludo y jugar ajedrez.

---

Si me pides que comparta ese libro, seguro que lo hago. Pero si quieres el resumen ejecutivo del libro, con los puntos importantes que te permitan sacarle provecho, más una comparación con otro conocimiento relacionado, y quieres que sea yo el que lo haga, vas a tener que pagar, y eso suponiendo que yo quiero hacerlo. Mi tiempo no es un recurso renovable, y parte de ser un humano competente está en admitir que no somos iguales, que cada quien tiene diferentes habilidades (en particular para adquirir conocimiento) y que es injusto exigir de otros lo que nosotros no podemos proveer.

---

La experiencia no es libre. La experiencia sólo se comparte por voluntad del que la posee y en los términos de éste. Por ejemplo, yo decido compartir mi experiencia en lenguajes formales y lenguajes de prrogramación con todo el que pregunta, porque es la que se me antoja compartir. Lo mismo pasaría si quieres conocimiento sobre los efectos de la capsaicina en el cuerpo humano, o la variedad de infusiones que se consumen en el mundo.

---

Pero para compartir mi experiencia en otras áreas, mis criterios de selección de interlocutor son diferentes. En muchos casos, reciben la experiencia los que me han demostrado que saben adquirir conocimiento, y muchos de ellos te dirán que lo que recibieron no fue una receta sino más preguntas y muchos libros para revisar. En otros casos, el interlocutor es alguien que sólo quiere un resultado: esos pagan.

---

Dicho ésto, visto que están migrando bases de datos a MySQL «porque es suficientemente bueno para Uber», quizás deberían pedirle a Uber que comparta su experiencia con Uds. Podría encontrar muchos ejemplos de sistemas grandes y complejos, de organizaciones mucho más grandes y relevantes a la humanidad que Uber, que usan Postgres hace mucho más tiempo. Pero eso sería utilizar la «Falacia de la Fuerza» para justificarme, y evito usar falacias porque adquirí el conocimiento de la lógica y es satisfactorio practicoarlo con frecuencia.

View more

Un sobrino me pregunta ocasionalmente, pero como es autodidacta simplemente le indico lo que tiene que investigar. Lo hace, y le resulta. Sus preguntas tienen que ver con algún problema no trivial al cual no puede «darle la vuelta» y no encuentra nada ni parecido que copiar en internet -- suelen ser problemas que no puedes resolver a menos que hayas estudiado algoritmos formales o estructuras de datos. El comprende que programar es relativamente fácil, pero programar bien es bastante más complicado, y está aprendiendo a manejar la complejidad. Cuando me insiste con un ejemplo, se lo hago con un lenguaje que él no conozca pero que exprese bien el problema -- después el intenta traducirlo al lenguaje que le gusta, usualmente comentando que «fue difícil, no quedó tan resumido y es lento».

---

A MiniMe no le ha interesado el asunto. Le han puesto tareas con Scratch, las hemos resuelto con LOGO, y luego traducido a Scratch. Llegó a la conclusión de que LOGO es mucho mejor aunque Scratch sea «bonito». Aún no ha explotado su lado analítico, ni estratégico.

---

Si tuviera que describir el «método» sería: *nunca* les doy la solución, los obligo a «pelearse» con el problema y usar todas las herramientas disponibles (aritmética, geometría, lenguaje, relaciones) hasta llegar a comprender el problema y poder explicarlo bien, antes de ponerse a escribir una solución. Trato de que valoren la actividad de pensar en el problema y comprenderlo a fondo; eso es lo que hace mejorar tus habilidades y no «buscar la respuesta en Google».

---

A veces pienso que los jóvenes tienen dificultades con estas cosas porque no fueron aficionados a los juegos estratégicos tradicionales, en los cuales vale más la planificación pausada y la organización de líneas de razonamiento, que la habilidad para presionar botones rápido. Y cada vez me asombra menos cuando me toca hablar de algún juego de mesa o acertijo para explicar algoritmos, y la mayoría no tiene ni idea del juego ni del acertijo.

---

No sabría cómo enseñar a programar. Para mí programar «no podía ser de otra forma» cuando aprendí hace 35 años. Aprendí por imitación, consciente que por ser imitador lo estaba haciendo mal, y de no haber sido por el estudio (formal e informal), seguramente sería un «coder» produciendo muchas líneas con resultados promedio. Hoy en día, no podría estar a cargo de un curso para «enseñar a programar». Hasta ahora, sólo puedo enseñar a programar mejor o en maneras «diferentes» a las «populares».

View more

En el caso general, nunca.

---

Hay casos particulares en los cuales, por ser muy celoso en el diseño relacional o por no aprovechar correctamente el sistema de tipos de PostgreSQL, puedes tener alguna instancia de integridad controlada por triggers en la cual haya dificultades. Eso se resuelve haciendo profiling y ajustando el diseño (posiblemente denormalizando alguna parte). Es notablemente infrecuente -- al que le ocurre mucho, tiene problemas diferentes en la conceptualización de su aplicación.

---

En todo caso la base de datos fue diseñada para hacer esas cosas. Los lenguajes de programación de propósito general, no. Darle «más recursos» a la plataforma de un lenguaje que no está preparado para un problema específico es, a priori, un error, que termina generando más errores por tratar de resolver el problema «a realazos» con el «gestor» equivocado. Es más fácil hacer escalar la base de datos aplicando todo lo que uno estudió de sistemas de operación, procesos distribuidos y lenguajes de programación. Si uno estudió esas cosas, claro, o tiene acceso a alguien que lo haya hecho.

---

Ser el «más popular» es muy diferente a ser «el mejor». La popularidad de un estilo de diseño de aplicaciones descentralizado, lo único que dice es que mucha gente prefiere ese «lugar común», que comprender a fondo las herramientas que utiliza. No es «popular» escribir aplicaciones 100% dentro de la base de datos -- tampoco es «popular» leer gente que tenga problemas con eso (¿será porque rara vez los tiene y cuando los tiene **sabe** lo que tiene que hacer?). Ahora, ¿cuán «popular» es escuchar historias de terror de aplicaciones que no escalan vertical, horizontal, circular, elíptica ni intensamente, parapeteadas con toda suerte de andamiaje externo con el consecuente costo extra de operaciones y monitoreo, que después no escalan...? Exacto.

---

No pierdes tiempo si lo intentas, porque o te convences de que es mejor, o te convences que es mejor que aprendas más. Ganar-ganar.

View more

No lo sé. Tendrías que preguntarle a las que se inscribieron, por qué lo hicieron, y a las que no se inscribieron, por qué no lo hicieron. No obstante, una opinión sin números es sólo un prejuicio...

---

Observando la información histórica que tengo sobre los cursos electivos que ofrezco, y tomando en cuenta solamente los estudiantes que han inscrito y terminado la materia:

---

* CI4251, la electiva corta Programación Funcional Avanzada -- 17% mujeres..

---

* CI4721, primera parte de la «cadena de Lenguajes» -- 13% mujeres.

---

* CI4722, segunda parte de la «cadena de Lenguajes» -- 12% mujeres.

---

Sólo dos mujeres abandonaron electivas inscritas, nueve hombres abandonaron electivas inscritas y dos reprobaron.

---

Observando la información histórica que tengo de los cursos obligatorios que ofrezco en el área de lenguajes, y tomando en cuenta solamente los estudiantes que han inscrito y terminado la materia:

---

* CI3641, Lenguajes de Programación I -- 28% mujeres
* CI3661, Laboratorio de Lenguajes de Programación I -- 26% mujeres
* CI3725, Traductores e Interpretadores -- 27% mujeres

---

Es público y notorio que estas materias son difíciles. Muchos estudiantes requieren más de dos intentos para aprobarlas y muchos abandonan después del primer examen. La proporción es más o menos la misma en esos casos. («Converger a la media», le llaman).

---

La proporción en las obligatorias es bastante parecida, y la proporción en las electivas está muy cerca de ser la mitad de aquella. Pensar que a una de cada dos estudiantes de Ingeniería de Computación le parecen interesantes las electivas del área de lenguajes, me parece un éxito rotundo de las materias obligatorias..

---

Lo que debes notar es que de cada cuatro estudiantes en computación, sólo una es mujer. Entonces, necesitamos que haya más mujeres en el área de computación, y para eso hace falta que la carrera no sea vista como algo «sólo para hombres» o «poco femenino» (ambos conceptos absolutamente ridículos -- uno estudia lo que quiere porque le gusta y se siente útil al hacerlo).

---

Además, es necesario que las mujeres sean apreciadas y respetadas como iguales. El rol de las mujeres en nuestra carrera siempre ha estado en minusvalía, por múltiples razones, y en realidad son muchas las mujeres que han hecho aportes sustanciales. Ya que mencionas el área de lenguajes, el primer compilador lo escribió una mujer; los conceptos de orientación a objetos y compatibilidad de sub-tipos los inventó una mujer; eso sólo por nombrar dos tópicos.

---

Ojalá haya cada vez más mujeres en computación, y ojalá siga teniendo la oportunidad de despertar la curiosidad y colaborar en desarrollar las habilidades de aquellas que se interesen en el área de lenguajes de programación. Son mis personas favoritas, hombres o mujeres, los que aprecian la compleja estructura del pensamiento y lo difícil de expresarlo e interpretarlo mecánicamente.

View more

Si vas a administrar sistemas, vi *siempre* va a estar allí y sin ambiente gráfico. Así que si tienes que hacer Sysadmin, DevOps o como se llame este mes, saber vi te permite defenderte en cualquier Unix.

---

Editores como vi e EMACS son extensibles — ambos tienen lenguajes de programación embebidos que permiten al usuario agregar funcionalidad al editor. Esto ha permitido que exista una cantidad notable de herramientas satélite que ayudan al administrador, al programador, y al escritor. Desde integrarse con compiladores para compilar, indicar los errores en tu programa, pasando por referencias cruzadas, integración con las págins de manual, arneses de pruebas automatizadas, y en los lenguajes que aplique, integración con el REPL *sin* salir del editor. Adicionalmente, ambos tienen soporte excelente para expresiones regulares, que son invaluables para la edición y manipulación de texto.

---

Ah, tanto vi como EMACS ponen colores a la sintaxis y eso... pero es lo menos importante.

---

Personalmente, prefiero vi (VIM hoy en día) porque no necesito usar ni el ratón, ni las flechas, para desplazarme — mover la mano fuera del teclado es una pérdida de tiempo y de concentración. El concepto de editor «modal» me parece más cómodo que la combinación de acordes que tiene EMACS, y la menera de crear comandos de una sola tecla me parece eficiente. Soy un flojo muy organizado.

View more

Siempre es mejor usar procedimientos almacenados por razones simples:

---

1. Los datos no tienen que moverse desde la base de datos hasta la aplicación. Nunca deja de sorprenderme que «programadores» e «ingenieros de software» modernos no se den cuenta cuán obvio es esto: Leer los datos en el caché/RAM locales y procesarlos inmediatamente es OBVIAMENTE más rápido que leer los datos en el caché/RAM locales, montarlos en paquetes, enviarlos a través de la red, copiarlos a memoria de usuario y procesarlos en el lenguaje que te dé la gana del otro lado.

---

2. Los lenguajes de programación que corren dentro de la base de datos están pensados precisamente para... wait for it, *PROCESAR DATOS* de la manera más rápida y eficiente posible. No son «lenguajes de propósito general».

---

3. Las bases de datos tienen sistemas de autenticación, autorización y separación, que son más que suficientes para cualquier sistema de información, están mejor probadas que la rueda cuadrada que todo el mundo reinventa, y se integran mucho mejor con la plataforma externa (PAM, LDAP, GSSAPI, y otras cosas que si el ingeniero de software no conoce, probablemente está haciendo la autenticación mal).

---

4. El sistema de tipos de la base de datos y sus lenguajes procedurales es mucho más estricto que cualquiera de los lenguajes usados para hacer front-end hoy, de modo que protegen al programador de errores triviales y reducen la cantidad de programas que hay que escribir pues no hay que hacer tantas pruebas unitarias.

---

Estos comentarios aplican para cualquier base de datos relacional moderna y decente (eso excluye a MySQL y sus derivados, y ni me pregunten por qué porque no hay espacio suficiente en ASK). En el caso particular de PostgreSQL, que es la que deberías estar usando, aplican algunas cosas adicionales:

---

* «Pero yo hago Machine Learning/Data Mining, y Python y sus librerías»

---

PostgreSQL permite correr R dentro de la base de datos. Python es un mal chiste al lado de R y CRAN, tanto para estadísticas como para Machine Learning, que termina siendo estadística también.

---

* «Pero yo tengo que hacer criptografía, y C»

---

PostgreSQL ya tiene librerías para criptografía, y si no tuviera lo que estás buscando, puedes hacer procedimientos almacenados en C.

---

* «Pero yo tengo que manejar información geográfica y Python...»

---

PostgreSQL tiene soporte para información geográfica, polígonos, mapas de elevación y otro montón de bondades... desde el siglo pasado.

---

* «Pero yo tengo unos procesos batch que tardan mucho...»

---

PostgreSQL tiene soporte para procesos asíncronos. Los activas y pides que te avisen cuando están listos.

---

Usa PostgreSQL. Usa procedimientos almacenados siempre. Expresa todas las reglas de negocio usando constraints y triggers. Lanza excepciones desde el SQL. De ese modo, puedes usar cualquier lenguaje en el frente (énfasis en «cualquier») porque la aplicación es la base de datos, y el lenguaje es reemplazable.

---

* «Pero yo no me quiero casar con PostgreSQL»

---

Ese es tu problema.

View more

SI una máquina con Unix está comprometida, una instalación completa, incluyendo una obliteración intencional [1] de los contenidos del disco garantiza que en el disco duro no queden rastros de nada [2]. La obliteración debe incluir el sector de arranque, que luego será reemplazado con el gestor de arranque de la distribución Unix que vas a instalar. Una máquina con Windows siempre estará comprometida, por eso no las toco desde 1995...

---

En algunas máquinas, es posible reemplazar el BIOS desde el sistema operativo, y en este caso podría inyectarse código malicioso allí. Si el BIOS de tu computador es de los «tontos» (que es la mayoría de los PC y portátiles de consumidor final), no hay espacio en el BIOS para código malicioso sin que sea aparente que el BIOS ha cambiado.

---

De modo que, en general, la respuesta a tu primera pregunta es «si», y la respuesta a tu segunda pregunta es «a efectos prácticos, si, porque si tuvieras una máquina con un BIOS poderoso, sabrías lo suficiente para no formular la pregunta».

---

[1] Usando `shred` o `wipe` desde un Live CD confiable.
[2] Si te interesa hacer el análisis forense, deberías obtener una imagen de todo el disco duro antes de obliterarlo.

View more

Como es público y notorio, no tengo ningún problema manipulando máquinas de estado sin dibujarlas, así que un editor modal como `vi` encaja perfectamente en mi estilo de trabajar, tanto para programar, escribir, y completar actividades de administración de sistemas. Uso `vi`[1] desde 1988 y no tengo intenciones de cambiarlo. Más aún, es mucho más frecuente que use `vim` en la cónsola, que `gvim` en ambiente gráfico — usar el ratón y las flechas de cursor son una pérdida de tiempo y concentración en mi flujo de trabajo.

---

Aprendí a usar EMACS, pero:

---

* EMACS = EMACS Makes Any Computer Slow.
* EMACS = Escape Meta Alt Control Shift daña las muñecas.
* EMACS = Eventually malloc()'s All Computer Storage
* EMACS = EMACS Makers Are Crazy Sickos (que no se bañan).

---

Así que, paso. Y lo que no me gusta de los «editores» modernos es que ni son modernos, ni son `vi`.

---

[1] Una vez me pidieron un curso sobre el «editor seis» — si, gracioso.

View more

Claro. Me ha tocado:

---

* Escribir un controlador de dispositivo para una tarjeta de red y para una controladora de cámaras de video. Ambas cosas se escribieron en C y no tiene sentido escribirlas en ninguna otra cosa.

---

* Escribir un componente «experto» para contestar consultas que requieren explorar un espacio de soluciones grande y encima manipulando relaciones. Eso se escribió en Prolog, y se desplegó como un servidor (en Prolog) que recibe preguntas via un socket.

---

* Aplicaciones de base de datos: TODO está dentro de la base de datos en PL/pgSQL o PL/R. Los ETL a veces los hago en Perl, a veces en Haskell (Conduit es amor).

---

Para el resto de las cosas que se me atraviesan hoy en día, casi todo se puede hacer con Haskell más rápido (tiempo de desarrollo) y con eficiencia igual o superior a otros lenguajes.

---

Por otro lado, hay problemas para los cuales tengo otro lenguaje favorito con el cual hago el prototipo (más rápido que la competencia) y después, si hace falta más velocidad final, se escribe en Haskell. Caso específico: uso Octave para los prototipos de Machine Learning.

View more

Presumo que la pregunta completa, para que la entiendan otros lectores, es «¿por qué no recomientas instalar GHC 8 para el curso CI3661 de este trimestre?».

---

Porque si ya 7.10 incluía cambios importantes, 8.0 cambia el Prelude notablemente, acompañado de otra cantidad de modificaciones que hacen que lo explicado en clase no coincida con lo que ocurre cuando vayan a probar por su cuenta, y tampoco garantiza que funcionen los ejemplos de código desarrollados en clase.

---

Los cambios introducidos en 7.10 y 8.0 son muy buenos tanto en lo general de programación funcional como en lo particular de su manifestación en Haskell, pero requieren más tiempo para aprehenderse y maneras diferentes de presentarlos. Este curso es para aprender técnicas funcionales verdaderas (para lo cual, desde hace una década, Haskell es el mejor lenguaje disponible) pero no es un «curso de Haskell». No es para usar la «última vesión de Haskell» sólo porque existe, y arcoiris y ponies, sino aprender de la manera más sucinta posible el uso de funciones de orden superior, abstracción de formas de recursión, y generalización de cómputo estructural aprovechando un sistema de tipos completo.

---

Uso GHC 7.10 regularmente y aún estoy convirtiendo cosas a GHC 8.0, para que otras personas que tienen un nivel inicial de Haskell puedan comprender los cambios.. Ambas versiones funcionan muy bien, pero sería irresponsable de mi parte presentar el curso CI3661 con cualquiera de esos dos sin antes reorganizarlo. Eso está ocurriendo en este trimestre. De paso, no es la primera vez que pasa — tuve que hacer algo similar cuando ocurrió la transición de GHC 6 a GHC 7.

---

Esa es la razón por la cual en la primera clase se explicó que estamos en un curso de transición para poder ir adaptando el material a las nuevas formas en que el lenguaje evoluciona. Y como dije en la primera clase, ambos profesores vamos a corregir usando GHC 7..6 o 7.8, y por eso los estudiantes deben instalar esas versiones.

---

Entonces, no puedo impedir que instalen lo que les venga en gana — total, son sus máquinas y su tiempo. Pero lo que si puedo es no corregir usando 8.0 ni 7.10, y tampoco cambiar el curso improvisadamente para explicarle a alguien por qué en su 8.0 no sale como lo presentamos en clase — total, es mi máquina y mi tiempo.

---

Recomiendo instalar GHC 8.0 a todo el que quiera ver el estado del arte en lenguajes funcionales, pero no recomiento que lo instalen si están cursando CI3661 este trimestre. El profesor no juega carritos y no recoge pasajeros.

View more

Temo que no puedo sugerir ningún tutorial. Esta es una de esas cosas que uno deduce de manera natural cuando estudió Lenguajes de Programación y Sistemas de Operación.

---

PL/pgSQL es un lenguaje de programación. Tiene su manual. Corre dentro de la base de datos, asi que debería ser obvio que si el problema X se puede resolver con PL/pgSQL *cerca* de los datos, tiene que ser *notablemente mejor* que resolverlo con otro lenguaje menos especializado, quizás en otra máquina, teniendo que mover los datos de un lado para otro (no hay manera de darle vuelta a esta justificación a menos que uno sea necio).

---

El sistema de tipos de PL/pgSQL es el de PostgreSQL que es muy superior al de cualquier lenguaje de programación (salvo el de Haskell y sus derivados), de modo que la cantidad de errores que NO vas a cometer por haber usado un lenguaje más seguro, te ahorra tener que escribir pruebas adicionales. El esquema debe lanzar excepciones a diestra y siniestra ante inconsistencia de datos, y los programas en PL/pgSQL otro tanto cuando se violen reglas de negocios — los lenguajes del front-end que se limiten a intentar CRUD y reaccionar a las excepciones, y nada más, no sea que se cansen.

---

PostgreSQL tiene un sistema de autenticación y autorización completos, así que no pierdes tiempo reinventando la rueda (mal) como lo hacen las aplicaciones con «módulo de autenticación marca ACME» (escúchalo como cualquier doblaje del Correcaminos). Eso te permite darle un usuario PostgreSQL a cada usuario real, que sea PostgreSQL el que discrimine el acceso a los datos y que con PL/pgSQL puedas sacar provecho de eso para que tengas operaciones «opacas» que un usuario puede *ejecutar*, pero no puede ver cómo son internamente.

---

Y seguro alguien viene a decir something something Big Data something something Machine Learning, y se le contesta que existe PL/R para correr R dentro de PostgreSQL, y que no hay ninguna justificación a sacar los datos a otra parte.

---

Mucha gente usa las bases de datos SQL como «pipotes de datos que hablan SQL», y por eso todavía se deslumbran con MySQL y siguen creyendo que NoSQL es mejor porque el esquema no hace falta. En cierto modo los ORM son responsables de esa percepción desafortunada de las cosas, así como el nefasto concepto «no te cases con una base de datos» que hay en la industria.

---

La próxima vez que tengas que escribir una aplicación, intenta hacerlo exclusivamente usando PL/pgSQL. Tu «interfaz de usuario» tiene que ser psql y consultas de línea de comandos. Hecho eso, le puedes poner cualquier maquillaje de front-end, tranquilo porque la verdadera complejidad está dentro de la base de datos, cerca de los datos, y no le importa cuál es el lenguaje front-end de moda esta semana.

---

(Y es más fácil cambiar de front-end para estar a la moda).

View more

Aprendí a programar a los 12 años. Aprendí tres lenguajes de programación en tres años. Todo por imitación, sin reflexión, sin introspección y mucho menos estructura. Mis programas «funcionaban», pero todo era la ilusión del que imita, pero no medita. «A little learning is a dangerous thing», decía Pope.

---

La universidad me hizo admitir que sabía poco y nada, pues lo que sabía hacer era bastante simple y burdo, así que «desaprendí» sin ninguna vergüenza para poder hacer las cosas mejor. Así es la vida.

---

Luego estudié Lenguajes Formales y Teoría de Lenguajes de Programación. Se puede ser muy buen programador, sin estudiar Lenguajes; pero cuando sabes cómo funciona un lenguaje por dentro, has construido varios lenguajes e interiorizado todos los estilos de programación, sabes lo que es posible, lo que no es posible y es poco probable que te sorprenda. Y como todo en computación es un lenguaje, cualquier tópico se reduce a identificar el lenguaje... cosa que con la práctica se hace cada vez más fácil.

---

Puedes entender muchas cosas leyendo, puedes comprenderlas si te las explican, pero la única manera de aprenderlas es haciendo. Practica, cuestiona, lee, equivócate, admite que te equivocaste, descarta lo popular mediocre y adopta lo impopular complejo. Después de todo, la computación es la exploración del pensamiento estructurado, de las formas de manifestarlo, y de hacer que otros entiendan lo que estás pensando. Eso requiere:

---

- Dominio del lenguaje escrito y hablado, porque no puedes hacerte entender a medias.

---

- Dominio de los modelos mentales de razonamiento lógico, para que no sostengas absurdos y puedas discutir con razones y no pasiones.

---

- Una buena dosis de paciencia, constancia y audacia.

---

- Evita «resolver» por imitación — eso es lo que hace un bebé cuando aprende a hablar y los niños cuando adquieren vocabulario. Para escribir mejores programas tienes que tener un vocabulario más amplio, primero en estructuras de datos yluego en abstracciones de control. Esas cosas, al igual que con los idiomas naturales, no se aprenden imitando lo popular, sino hurgando en lo original y reflexionando con lo formal.

---

- Práctica. Ninguna destreza se adquiere ni se mantiene, sin práctica.

---

La «industria». Ah, la «industria». La industria te enseña que hay mucha gente practicando, apurada sin destino, que deja pasar una solución buena definitiva, por una apurada satisfacción comercial.

---

«¿Cómo aprendo Haskell?» me preguntan: «hazlo TODO con Haskell», les contesto. «Pero eso es muy difícil», replican. «Entonces no hagas nada y quédate feliz como estás».

---

«There is no royal road to learning; no short cut to the acquirement of any art» decía Trollope.

View more

Hay personas que son productivas de día y otras de noche. Personalmente, soy productivo de día así que de haber una ley, la estoy rompiendo conscientemente. Creo que es un estereotipo falaz, que muchos adoptan porque es «cool» y lo justifican como «el estilo de vida coder/hacker», a falta de explicaciones menos glamorosas.

---

Cuando yo estudiaba, el día se acababa a las 9:00pm (si no antes), porque siempre he sido productivo de día y tengo muchas otras cosas que hacer que no son estudiar/trabajar. Eso incomodaba mucho a mis compañeros de estudio noctámbulos cafeinómanos, que si bien no eran la mayoría, eran los que frecuentaba. Crecí en una familia donde se aprendía a ser puntual, aprovechar el tiempo, distribuirlo entre varias actividades y NUNCA aceptar que la improvisación de otros se volviera MI apuro — es una de las cosas que más agradezco a mis padres..

---

Es *mentira* que se puede ser intelectualmente productivo por tantas horas, y luego «recuperarse» durmiendo en exceso después. Hay que ser inteligente para trabajar lo justo efectivamente en lugar de mucho desesperadamente — sin importar el horario. Y no es algo que viene «con la edad» — yo lo asimilé a los 14 años, y ya mis padres me lo habían inculcado por un lustro con el ejemplo y la palabra.

---

Personalmente, desde hace una década, en la tarde y noche usualmente hago cosas de baja complejidad o simplemente no trabajo. Cada uno tiene que aprender a ser honesto consigo mismo y abandonar la obsesión de «trabajar hasta que esté listo» — en general, un maratón de trabajo (diurno o nocturno) indica una mala distribución del tiempo propio, bien sea por inmadurez propia o por dejarse transferir la improvisación de otros.

---

Además, en mi caso particular, en lugar de escribir programas, yo suelo escribir programas que van a escribir los programas que resuelven los problemas. Eso me permite dormir de noche, trabajar de día y entretenerme en las tardes.

---

Soy un flojo muy eficiente, y eso desespera a los flojos estándar.

View more

No tanto como quisiera, pero el «copioso tiempo libre» es más privado ahora.

---

El más visible, y constante, es crear y mantener paquetes para Debian

---

https://qa.debian.org/developer.php?login=emhn@usb.ve

---

en algunos casos, escribiendo correcciones o adaptaciones. Antes había más paquetes, pero algunos desaparecieron porque ahora forman parte del «core» Perl, o bien han sido declarados obsoletos con mejores alternativas.

---

También contribuí con pequeños parches para las primeras iteraciones de las herramientas Custom Debian Distribution, antes y durante la confección de Canaima. En su mayoría, cosas que habrían sido buenas en Canaima pero no se incorporaron (y ya es tarde), que al final resultaron ser buenas en el CDD (hoy Simple-CDD).

---

Estuve parcialmente involucrado con BIND 10, haciendo lo necesario para empaquetarlo en Debian. (Des?)afortunadamente, BIND 10 nunca «vió la luz» — Python y C++ tuvieron que ver con el asunto: habría sido detestable para los administradores de sistemas porque su arquitectura rompía con todas las usanzas Unix y lo hacía consumir bastantes más recursos que BIND 9.

View more

Un lenguaje que «tiene map», «listas por comprensión» o «lambdas» no es automáticamente funcional. Son, en efecto, construcciones provenientes de lenguajes funcionales, y usarlas para expresar soluciones es mucho más elegante que iteraciones, incluso anidadas, o funciones auxiliares. Sin embargo, el lenguaje sigue siendo imperativo: todas esas cosas se traducen como iteraciones sin ningún tipo de astucia.

---

Si se escriben N map en secuencia en Python (o en Ruby, e incluso en Perl), lo que va a pasar es que eso se va a traducir a N ciclos anidados (en general) y si tienes muuuuuuuucha suerte, en N-k (k pequeño en relación a N) ciclos anidados. La razón es que como el lenguaje sigue siendo imperativo, el compilador no puede hacer suposiciones sobre lo que ocurre en el cuerpo del map y tiene que asumir que «cambia cualquier cosa» [1]. Así, sólo estás ganando en la expresión en tu programa, pero en desempeño, poco y nada.[2]

---

Pero si escribes

---

map f (map g (map h (map k (map l (...)..)

---

en un verdadero lenguaje funcional, el compilador lo va a convertir en

---

map (f . g . h . k . l)

---

gracias a teoremas de fusión que sólo pueden aplicarse cuando no hay efectos de borde. O sea, quedó UN (1, se lee uno) ciclo. Más aún, en muchas circunstancias la composición de funciones puede compactarse, nuevamente por otro montón de teoremas que sólo aplican cuando no hay efectos de borde. Así, no sólo ganas en la expresión de alto nivel, sino que el compilador genera mejor código.

---

Por último, existen muchos teoremas que permiten mejorar código en el cual se compongan map, fold, aplicación de functores y secuencia mónadica, que NO pueden existir en lenguajes imperativos por la presencia de efectos de borde. En un lenguaje verdaderamente funcional, además de lambdas, clausuras, map/fold y monads, no puede haber efectos de borde mezclados con el cómputo puro. Esto último es lo que le falta a todos los que se venden como funcionales, pero en realidad son de múltiples estilos, con mayor énfasis en el imperativo.

---

Así que, si un lenguaje NO tiene inmutabilidad global separada por tipos, no es funcional. No importa que el editor ponga los map en dorado, que los lambda salgan con λ y que tenga despacho indirecto con funciones de orden superior, si al final sigue teniendo efectos de borde arbitrarios.

---

Estoy dejando de lado intencionalmente el hecho de que los lenguajes imperativos operan con evaluación aplicativa exclusivamente, mientras que en los lenguajes funcionales hay que tener evaluación aplicativa y evaluación normal (simuladas no cuenta). También estoy dejando de lado que funciones implican operar sobre conjuntos, que para eso necesitas separar los conjuntos efectivamente, y hace falta un sistema de tipos fuerte y expresivo.

---

Lo honesto sería decir que un lenguaje es imperativo y tiene formas de expresión funcionales.

---

[1] De ahí, el rancho con perro en el techo que son los lambda en C++
[2] Peor si el lenguaje corre sobre el JVM, porque es una triste máquina de pila

View more