EM Hernández-Novich

Comencé a trabajar al inicio del sexto trimestre, en una empresa que desarrollaba sistemas de información sobre XENIX (el Unix comercial para PC de la época). Por ese tiempo, las fórmulas para calcular pasivos laborales cambiaban con mucha frecuencia por Ley, así que el sistema tenía almacenada la fórmula en la base de datos (como un campo de texto) y el sistema tenía un interpretador (escrito en C) para evaluar la fórmula usando un mini-lenguaje. De ese modo el usuario tenía independencia para escribir sus propias fórmulas y no había que recompilar el sistema. Clever language people are clever and lazy.

---

Me enseñaron a escribir interpretadores con Lex y Yacc en C, para que pudiera hacer mejoras al interpretador de fórmulas. Allí comencé a usar Software Libre (GCC y GNU Make). Aprendí a usar Unix como el IDE que es. También me enseñaron SQL, que tenía que poner embebido en C. Trabajé seis meses allí, hasta que uno de mis jefes me dijo que no continuara con ese trabajo, porque me iba a conseguir el permiso para ver la cadena de lenguajes en los trimestres ocho y nueve -- nunca dejaré de darle gracias por todo eso.

---

Cuando ocurrió el «gran cambio de pensum» en 1988, aparecieron Laboratorio de Lenguajes y Traductores (no la tuve que ver -- Lenguajes II de la época era todo Traductores y algo más). Tuve el privilegio de ser el preparador de la primera versión de Traductores, pues el mismo profesor del permiso, me pidió que lo ayudara -- nobleza obliga.

---

Después que terminé la cadena de lenguajes, y la de gráficas, volví a una empresa «spin-off» de la original, a seguir usando Unix, en todas sus formas, y cada vez más Software Libre, hasta que me gradué.

---

Trabajar te ayuda no sólo en lo académico, sino también en aprender lo que cuestan las cosas, lo que vale el tiempo de una persona productiva, y lo equivocado que está el que pretende ponerle precio a tu trabajo o decidir el valor de tu experiencia. Eso si, nunca puse mi trabajo como excusa para no cumplir con los estudios, ni el estudio para no cumplir con el trabajo, además de nunca llevarme trabajo para la casa.

---

El trabajo sólo es castigo para el esclavo de sus vicios.

View more

No.

---

En el caso de Elixir, un bloque `do` no es más que «syntactic sugar» para pasar una lista de claves/valores. Es decir el bloque lo que hace es convertir sus componentes en un valor lista, con cada componente como un elemento. Nada de imperativo en eso.

---

En el caso de Haskell, un bloque `do` es «syntactic sugar» para expresar composición en el contexto de un Monad particular. Cada una de las líneas del bloque `do` es una expresión que se evalúa y su resultado se pasa a la siguiente expresión cuando es necesario

---

do
result <- this
that result

---

en realidad se convierte en

---

this >>= \result -> that result

---

usando bind (>>=) para el Monad en contexto. Si usas cualquier Monad que no sea IO ni STM, todo el cómputo es absolutamente puro. En IO y STM, el cómputo es controlado por el ambiente de ejecución. En ningún caso es imperativo (no hay efectos de borde, ni noción de estado global)-- es composición funcional generalizada y en secuencia.

---

Si usas el Monad State, ST, o IO en presencia de IORef tienes la ilusión de que hay un estado mutable, pero si prestas atención a la implementación de ambos, notarás que en realidad hay copia de valores. Nunca hay aliasing ni modificación «en sitio».

---

Como los IORef sólo tienen sentido cuando estás interactuando con una librería externa en C, otros usos probablemente reflejan que el programador no ha podido expresar su solución funcional correctamente y apela a sus nociones imperativas.

View more

No puedo contestar en horas. Nunca le presté atención a ese detalle.

---

Apliqué dos principios: nunca trasnocharme estudiando y nunca hacer las cosas apurado a última hora.

---

Dormir siempre fue una prioridad, porque el cerebro cansado es más estúpido que el estudiante universitario promedio. En toda la carrera me trasnoché tres veces: una porque la máquina era compartida, en el campus, y me tocó un turno a las 02:00; otra, porque eran grupos de tres equipos de dos, y los otros cuatro tenían que integrar con nuestro API y «otros grupos»; y la última porque yo quería los puntos extras de Lenguajes III (spoiler: no los tuve por estar cansado). El resto del tiempo, me trasnoché jugando AD&D, King/Space Quest, Leisure Suit Larry, Tetris, y Nethack, o escuchando radio/televisión en inglés.

---

En las materias que requerían práctica (cálculo, álgebra, lógica) hacía *todos* los ejercicios. En las materias que requerían programar, nunca echaba una línea de código a menos que supiera por qué la estaba escribiendo. No me funcionó para Sistemas Lineales, ni Estadística, y por eso tuve que verlas dos veces. Siempre inscribí generales que, cuadraran con mi horario primero, y se basaran en mi habilidad de argumentar, naturalmente -- fueron entretenidos.

---

Hacía un poco todos los días. Había días en que sólo pensaba en los problemas, hacía dibujos, y los botaba. Había días en que sólo escuchaba a mis compañeros en el frenesí de «echar código», y hacían preguntas tipo «¿cómo hago X en Y?» sin saber explicarme por qué querían hacer X, y allí tenía revelaciones sobre la naturaleza del problema. Había días en que escribía programas que no tenían nada que ver con el proyecto, pero eran para practicar con el lenguaje de turno (porque cuando yo estudié, eran lenguajes diferentes todos los trimestres, y uno tenía que aprenderlos por su cuenta). Después de aprender LISP, en todas las materias me preguntaba «¿cómo haría esto en LISP?».

---

No pertenecí al LDC, y si había otras organizaciones como ahora, ni me enteré. La mayoría de mis actividades eran fuera de la universidad, tanto para el trabajo (a partir del segundo año, y fue utilísimo para facilitarme el resto de la carrera) como para lo extracurricular.

---

Tengo la impresión de haber pasado desapercibido, porque nunca tuve ninguno de los rasgos de computista gregario. Fui preparador de la primera edición de Traductores y de Lenguajes, por tres trimestres, porque no necesitaba preparar nada. Tuve compañeros muy interesantes, a los cuales espero haber apoyado tanto como ellos me apoyaron a mi, a pesar de mi preferencia por trabajar sólo y con flojera admistrada. Mi estilo de trabajo es irritante para la mayoría de la gente, por aquello de «al pie de la letra y no estoy para enseñarte castellano, ni dibujo libre». La improvisación de los demás nunca será mi apuro, y su incapacidad nuca recibirá mi paciencia.

---

Por eso Haskell, Perl, PostgreSQL y Debian, antes que las alternativas apuradas sin destino, digo yo...

View more

I don't know if there's a «best way» to show an e-mail address publicly.

---

I have some e-mail addresses that are public and I rarely ever get spam. I do have very stringent anti-spam policies in place for e-mail addresses I operate personally, and try to cooperate with others to improve on that. So, I've received spam but I make it «expensive» to spam me.

---

I have a few tricks when giving e-mail addresses, so I can pinpoint who gave my e-mail address away without my consent and make them miserable about it. This, of course, requires operating my own e-mail service, a thing I've been doing for over 20+ years now -- at least for the e-mail addresses I care about in terms of privacy.

---

Over the years, the Internet has been easier to access for anyone (that's good), including the annoying and the naïve, extremes (that's bad, but unpreventable). They both have access to e-mail. Operating e-mail has been increasing in complexity, in order to prevent the annoying to behave abusively and the naïve to put other people's privacy at risk.

---

Your regular e-mail message today requires A LOT MORE of background work to make sure it's «legitimate» than it required ten years ago. The annoying but lazy are almost gone, leaving the annoying but crafty -- the naïve (and sometime idiotic) are not going away, and there lies the problem -- it's hard to determine if an idiot is actually sending e-mail or is a crafty annoying one abusing the Internet newbie.

---

If you're getting too much spam, ask your ESP to improve, or change your ESP to a better one. Even better, ditch the ESPs, operate your own domain, and become «expensive» to annoy. Then publish your spam trap e-mail, and make them suffer.

View more

Hacerlas. No sé si hay tutoriales o libros sobre ese tema específico.

---

Escribir las aplicaciones dentro de la base de datos fue una conclusión a la que llegué después de observar:

---

1. La base de datos tiene un sistema de tipos estricto, rico, y extensible (hablo de PostgreSQL -- a MySQL no aplica y NoSQL no es mejor que una carpeta con archivos). Eso me permite representar los valores sin ambiguedad y sin pérdida de información. Las aplicaciones son mucho más que INT, DATE y definitivamente TEXT (el tipo de datos del pobre). Un número de identificación fiscal no es un TEXT -- es mucho más en estructura y condiciones, y la base de datos la puede expresar sin necesidad de ayuda externa.

---

2. La base de datos tiene un lenguaje declarativo para expresar las restricciones que deben cumplir los datos que se pretende insertar/cambiar/borrar. Es un lenguaje diseñado para eso, coopera con el sistema de tipos, se ejecuta más cerca de los datos que NINGÚN otro lenguaje y lo hace tan pronto se *pretende* cambiar la base de datos. Cualquier cosa fuera de la base de datos es más lenta, menos expresiva, y más frágil -- además, si las verificaciones se hacen fuera, la base de datos es vulnerable a cambios manuales por cualquier usuario.

---

3. SQL en toda su extensión es mucho más que CRUD. Es capaz de expresar tanto restricciones de acceso (a través de vistas) como relaciones complejas entre los datos (en forma de CTEs, incluyendo las recursivas). SQL es declarativo, y el planificador de consultas es MUY superior a cualquier humano tratando de obtener y masticar los datos en $LENGUAJE_QUE_NO_ES_SQL. Tan pronto aprendes a usar WITH, «window functions», y todos los JOINS, ocurre que todos los cómputos se hacen dentro de la base de datos, cerca de los datos, sin tener que mover nada a un lenguaje inferior por fuera, ni tener que reinventar esas cosas en lenguajes de propósito general, usualmente imperativos, que están muy mal preparados para la tarea en cuestión.

---

4. Para casos complicados en los cuales hay que hacer cómputos dependientes del estado de la base de datos, o bien con restricciones que involucran múltiples condiciones, tienes un lenguaje dentro de la base de datos para expresarlas. Nuevamente, un lenguaje diseñado para eso, que corre cerca de los datos, que está protegido de montones de condiciones de carrera gracias a la naturaleza transaccional, y sin tener que llevarlos fuera de la base de datos.

---

5. El mecanismo de control de acceso de la base de datos es más completo que el típico «gestión de perfiles» de las aplicaciones. Usar ROLEs y GRANTs es más rápido y seguro.

---

Tu objetivo tiene que ser tal, que si no existieran los lenguajes en el frente, tu aplicación funcione sólo con SQL sin riesgo de inconsistencia. El lenguaje del frente tiene que ser irrelevante.

---

Lee toda la documentación de PostgreSQL y para cada cosa piensa «¿estoy aprovechando ésto?». Te sorprenderás.

---

Hasta ahora, me ha ido mucho mejor que la alternativa popular

View more

Es muy difícil comer mal en Argentina. Tampoco sé cuál es tu presupuesto ni tus gustos, así que hablo de mis gustos y de que no pago ni de menos, ni de más, por las cosas que me gustan.

---

«El Club de la Milanesa» nunca me ha dejado mal. «El Palacio de la Papa Frita» tampoco.

---

Nunca son demasiadas medialunas en «Lucío», pero seguramente encontrarás muy buenas en cualquier cafetín o panadería. Con café con leche, o con un submarino.

---

«Don Julio» para asado y vino, con sobremesa.

---

«Margherita Piazza» si quieres una pizza italiana, «1893» si quieres una pizza tipo galleta, y para la pizza porteña, o te metes en cualquier pizzería por porción o te sientas en «Los Inmortales» o «Los Maestros» frente a la plaza.

---

Las empanadas (carne, maíz con queso, atún, acelga) cómelas en todos lados hasta que encuentres la que te gusta. Los choripanes, en el Monumental o en la costanera, porque «Chori» y «Choripán» no me parecieron nada del otro mundo.

---

Los domingos solía haber una feria de comida a cielo abierto en Mataderos, y eso es lo más cercano a «street food» en Buenos Aires. Ahí puedes probar un poco de todo.

---

El helado es bueno en cualquier parte, a cualquier hora, igual que el dulce de leche, y los alfajores. Y si pasas por algún localcito de planta baja, en cualquier esquina, y huele bien, lo más probable es que sepa muy bien.

View more

Puedes usar Concurrent Haskell [1] para construir sistemas distribuidos con el modelo de actor y pasaje de mensajes. Si bien provee un API muy parecido al OTP (por ejemplo, para gen_server) no es exactamente igual. Hay cosas de OTP que no están en Cloud Haskell; podemos discutir sobre si deberían o no estar, y estaríamos perdiendo el tiempo. Hay cosas que en Erlang no existen, por ejemplo, la habilidad de tener varios procesos asíncronos usando STM para cooperar, así como un mecanismo de cola de trabajos similar a RabbitMQ pero sin la persistencia. Así mismo, se diseñó para separar los procesos de la capa de transporte, de manera que puedes «conectar más cosas» a través de diferentes protocolos.

---

En el fondo Cloud Haskell no es, ni pretende ser, una copia de Erlang y OTP. Ocurre que la mejor manera de explicar Cloud Haskell es describirlo como algo parecido a OTP de Erlang en principio, pero suficientemente diferente en construcción como para evolucionar de manera distinta.

---

Lo que sepas de Erlang OTP te ayudará a aprovechar Cloud Haskell, pero sólo para adaptarte más rápido. No pretendas «traducir» el código de Erlang OTP a Cloud Haskell, salvo para los ejemplos triviales.

---

No puedo decir si uno es mejor que el otro y tampoco estoy seguro de poder decidir rápidamente cuándo es mejor uno que otro. El punto de quiebre es que en Erlang todo es con tipos dinámicos y «no me importa si falla», pero en Haskell las cosas tienen que tener tipos correctos y ser serializables para que las fallas sólo sean por flujo de datos y no por mensajes inconsistentes. Esa es una diferencia más importante de lo que parece a simple vista.

---

[1] http://haskell-distributed.github.io/documentation.html

View more

Julia incluye todas las técnicas de compilación para cálculo numérico aprendidas con FORTRAN, permite generar código nativo via LLVM aprovechando varias optimizaciones específica para vectorización, incluyendo primitivas para expresar paralelismo a diferentes niveles y con mínimo esfuerzo para el programador. Basta una opción de interpretación o ejecución, y verás todos los núcleos trabajando.

---

La abstracción procedimental se logra a través de despacho múltiple, técnica que está más o menos a mitad de camino entre programación orientada a objetos simplista (como Python o Java) y programación funcional polimórifca (como Haskell o Racket), de modo que es mucho más fácil combinar ambos estilos.

---

Tiene un sistema de tipos estricto de verificación dinámica, con un mecanismo opcional de «type hinting» para permitir al compilador detectar errores antes de correr, y aplicar algunas optimizaciones.

---

El conjunto de pruebas estándar para Cálculo Numérico demuestran que el desempeño de los programas en Julia está más cerca de escribir en C, que si escribes en el popular (pero inadecuado) Python, los adecuados (pero impopulares) Octave y R, y los adecuados (pero onerosos) Mathematica y Matlab. No aplica «pero yo uso el lenguaje X con bindings para C» porque "no seas payaso y tramposo".

---

Es un lenguaje de propósito general pero está enfocado, siendo particularmente expresivo y poderoso, para cómputo numérico para simulación y visualización, análisis de datos, «Machine Learning» y cualquier problema en el dominio de análisis de datos.

---

Hay un esfuerzo adicional que permite usar librerías de otros lenguajes desde Julia. Julia no puede hacer que esas librerías corran más rápido, pero sirve para que los cautelosos puedan ir convirtiendo sus aplicaciones paulatinamente.

View more

I've used several over the years.

---

Lately I've adopted one that's been the result of several iterations at work while working on separate projects, each one with different database requirements. It has separate files for everything and are loaded using a Makefile, roughly in this order: needed (PostgreSQL extensions), custom domains or data types (with operator definitions when applicable), functions, schema, triggers, roles and grants, and seed data (when applicable). For multi-schema databases, have a directory for the specifics, repeating each sequence per schema, before the global roles and grants.

---

We handle schema changes with a particular technique I'm not going to discuss, that allows us to keep track which changes have been applied, and make sure they're applied in order and exactly once.

---

It's an interesting problem, way more complex than the naïve interpretation of «just edit the SQL and replace the objects».

View more

Comienzo con un grafo que expresa las clases y sus relaciones. El grafo se refina agregando atributos a las clases, y expandiendo las clases. Después hay varios grafos así que comienzan a combinarse.

---

Hay otro grafo que expresa los tipos de los atributos y sus restricciones. Ese grafo se refina para usar tipos duros en el sistema de tipos de PostrgreSQL, seguramente usando restricciones semánticas, y ocasionalmente diseñando un tipo nuevo con operadores a la medida. TEXT es el tipo de datos del pobre, y es de pobres verificar restricciones en el front-end.

---

Los dos grafos se construyen co-recursivamente.

---

En cierto punto se escriben como DDL y de allí en adelante es código. No escribo código sin haber pensado mucho en él. Pienso más rápido que lo que escribo, y es más fácil borrar o botar papel, que borrar código.

View more

No puedo decidir lo que para ti merece la pena aprender. Si quieres aprender Java, deja de leer inmediatamente y ponte a aprender Java.

---

Cuando salió Java, lo aprendí para decidir inmediatamente que no quería usarlo ni estar vinculado con nada que tuviera que ver con ese lenguaje, porque (en los noventa) no tenía nada nuevo que ofrecerme más allá de restricciones y recortes a mi libertad de expresar programas. Ese soy yo, con mis habilidades y mis maneras de resolver problemas.

---

Hoy en día, hay aún más evidencia de que Java como lenguaje al frente, no es el más expresivo ni el más conveniente. Y la JVM, como implantación atrás, no es la más eficiente, ni la más práctica para los requerimientos de cómputo del presente y del futuro.

---

Llegué a Java cuando el lenguaje estaba comenzando y con sólo seis años de experiencia con lenguajes de programación, e inmediatamente supe que no era para mi en ninguna faceta. Hoy, con 30 años de experiencia en lenguajes de programación, y viendo lo poco que ha evolucionado Java, aún menos. Es más, ver otros lenguajes como Go, Swift o JavaScript hacerse populares, es evidencia que la industria aprende poco, pero eso siempre ha sido así porque la industra no la dirigen los intereses científicos.

---

Si quieres aprender un lenguaje nuevo para «trabajar», escoge alguno de los populares y pertenecerás a una familia de mucha gente que te ayudará a producir. Si quieres aprender un lenguaje nuevo para conseguir un trabajo interesante en el cual haciendo menos produzcas más, aprende Haskell, Julia, Rust, Erlang o R. Aprende SQL y PL/pgSQL.

---

Si leíste hasta aquí, y todavía quieres aprender Java, verás que haberme preguntado no cambió tu opinión. Nadie cambia de opinión si no quiere, ni aún con toda la evidencia del mundo en sus narices, porque muy poca gente aprende por experiencia ajena, y esos pocos, usualmente aprenden sin preguntar.

View more

TL;DR No. La parte que podría ser automatizable es intratable e impondría restricciones imprácticas para mplantador y usuario.

---

Dado un conjunto de expresiones regulares Alex es un programa que genera el programa que acepta palabras en los conjuntos denotados por esas expresiones regulares. El usuario debe saber escribir expresiones regulares y Alex hace todo lo demás. Esto es consecuencia de que las palabras reservadas de un lenguaje de programación son un conjunto regular (Tipo 3)

---

Dado un conjunto de reglas gramaticales libres de contexto, Happy es un programa que genera un programa que acepta la secuencia de tokens que respeta la gramática del lenguaje. El usuario debe saber escribir gramáticas libres de contexto y Happy hace todo lo demás. Esto es consecuencia de que las gramáticas de los lenguajes de programación siempre son libres de contexto y tienen furetes restricciones de forma para que sean «razonables» (son un subconjunto propio de los lenguajes Tipo 2 que puede ser reconocido en tiempo O(n)).

---

Ahora bien, las reglas de alcance, sistemas de tipos, y abstracciones de control de todos los lenguajes de programación son sensibles al contexto. Esto quiere decir que son Lenguajes Tipo 1, los cuales necesitan el poder de una Máquina de Turing con espacio acotado (léase, cualquier computadora moderna) para ser reconocidos. Es imposible resolver el problema general de, dada una gramática sensible al contexto, determinar si una cadena (programa) puede derivarse de esa gramática, resulta ser PSPACE-completo (que es subconjunto de NP-completo). Para los no técnicos, quiere decir que es un problema intratable cuya solución general (una herramienta que genere el programa reconocedor) correría en un tiempo más allá del polinomial. Absolutamente inútil.

---

Es por eso que NO se usan gramáticas sensibles al contexto, sino que se usan gramáticas libres de contexto, y el implementador debe agregar exactamente todo lo que hace falta para establecer la correlación entre los elementos contextuales. La técnica de Gramáticas de Atributos es sumamente conveniente, aunque suele ser insuficiente para lenguajes medianamente complejos. Happy incluye facilidades para expresarlas, pero el programador siempre tiene que hacer algo más.

---

Escribir una Gramática Sensible al Contexto para un lenguaje de programación simple es una tarea complejísima que ningún implantador de traductores/compiladores querría enfrentar aún si existiera la herramienta mítica que describí antes. Describir las reglas de alcance y la semántica (operacional o denotacional) de un lenguaje de programación expresado así, sería complejo, sin contar que inútil para los usuarios del lenguaje.

---

La complejidad de los lenguajes Tipo 2 es notable en comparación con las de Tipo 1. Considerando que para los lenguajes de programación se usa un subconjunto pequeñísimo de los Tipo 2, debe resultar natural imaginar por qué no existe ni es viable una herramienta como la que propones.

View more