EM Hernández-Novich

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

Si toda la lógica está en la base de datos, necesariamente las únicas cosas que puedes hacer sobre la base de datos son conectarte, y hacer SELECT, INSERT, UPDATE o DELETE, manejando las excepciones que generará la base de datos.

---

Puedes escribir un programa increíblemente simple en el lenguaje favorito del mes que sólo tenga que hacer eso. Cuando cambias de mes, cambias el lenguaje favorito. Pero la base de datos sigue están all, con todas sus reglas, importándole muy poco cual es el lenguaje de moda del mes, porque es independiente y el centro de atención de la lógica del negocio.

---

Si estás usando PostgreSQL, adicionalmente tienes la posibilidad de generar eventos asíncronos, i.e. pedir que se ejecute una consulta y que la base de datos te avise cuando esté listo. El lenguaje de moda del mes seguramente es capaz de hacer eso.

---

Si no estás usando PostgreSQL, probablemente estás escribiendo demasiadas cosas en el lenguaje del mes, y eso dificulta mucho garantizar la integridad de los datos cuando la aplicación comience a hacer agua.

---

Si le echas un vistazo a PostgreSQL verás que incluso el CRUD se puede generar automáticamente gracias a PostgREST. Es decir, ni siquiera hace falta un programador para escribir la pasarela GET por SELECT, POST por INSERT, etc. porque PostgREST analiza el esquema y genera el API. Entonces, sólo lo que necesitas es el reemplazable front-end que cada vez tiene que hacer menos cosas de manipulación de datos, sino simple presentación.

---

Esta es la dura vida de los que escriben programas que generan programas. Mi gente de Lenguajes :-D

View more

Desarrollar el lenguaje escrito y hablado, prestando particular atención a la amplicación del vocabulario y la expresión precisa. Nunca ceder ante el lenguaje coloquial e impreciso. El esfuerzo mental por hablar y escribir bien reditúa en procesos mentales más organizados. You should also do this for English. Más aún, estudiar cómo funcionan idiomas como el Latin, el Alemán, el Húngaro, o el Japonés, te enseñará nuevas maneras de organizar ideas (cómo funcionan no quiere decir «hablarlos») y podrían orientarte en formas interesantes de manifestación del pensamiento a las cuales no estás acostumbrado porque sólo piensas en español.

---

Desarrollar el lenguaje de la lógica, y practicar la traducción de las expresiones del mundo real en ese lenguaje. Es una frase corta, pero sustanciosa.

---

Desarrollar la habilidad de comprender y preparar argumentaciones razonadas correctas. Esto aplica tanto para las demostraciones matemáticas formales («hay infinitos números primos») como para las discusiones que la gente sostiene.

---

Comprender demostraciones matemáticas se premia por sí sola porque vas a poder tomar cualquier libro de cualquier tópico y comenzar a aprender. Comprender las argumentaciones (en particular las falaces), tiene como consecuencia que en conversaciones con gente sobre cualquier tema, podrás identificar a los que no razonan ordenadamente y así no perder tiempo con ellos (usualmente dicen «contigo no se puede hablar», y eso quiere decir que lo estás haciendo bien). De paso, una argumentación sólida y razonada es la firma del pensamiento analítico.

---

Finalmente, descomponer cualquier todo en sus partes, recomponerlo comprendiendo las relaciones, y recomponerlo de maneras creativas. Los acertijos de lógica y matemática son la mejor manera de practicar. Construir LEGO con una figura ejemplo, sin instrucciones, también.

---

El libro «Introduction to Mathematical Thinking» de Keith Devlin es una buena referencia previa a un estudio formal de Lógica y Técnicas Matemáticas. El libro «42 fallacies» de Michael LaBossiere es un resumen interesante de falacias que la gente grita y las respuesta que hay que darles para sacarlos de su error.

View more

No importa si tus conocimientos son muchos o pocos. Lo que importa es que tu mente es la única responsable de adquirirlos: nadie aprende por experiencia ajena. Todo lo que aprendes se convierte en un bien intrínseco a tu existencia que nadie puede quitarte, y que debes utilizar siempre para evaluar la evidencia a tu alrededor, juzgar las cosas, y actuar inteligentemente. Dejar de usar cosas que sabes, es estúpido, inmoral, o ambas.

---

Acepta que tu mente puede cometer errores, por vacío de conocimiento o por conocimiento imperfecto: perfecciónalo. Pero nunca dejes que los vacíos sean llenados por las autoridades (de hecho o de derecho), o por la «opinión de las mayorías»: Un error cometido por ti mismo, es mucho más seguro para tu integridad que aceptar información como acto de fé o requisito para la membresía en un grupo; tus errores de razonamiento puedes corregirlos con diligencia, pero los errores del militante son una peste descontrolada que destruye tu capacidad de distinguir los hechos de los errores sustentados por las bajas pasiones.

---

«Vive y actúa hasta los límites de tu conocimiento, y expande tu conocimiento hasta los límites de tu vida»

---

El uso del cerebro no es opcional.

View more

Creo que tiene problemas de compromiso. Eso y que, como diría Iñigo Montoya, sigue usando «escalar» sin saber exactamente lo que quiere decir «escalar».

---

Una de las razones por las cuales escogí la base de datos es, precisamente, para aprovecharla al máximo, porque no necesito otra -- claro, si no estoy convencido de conocer la base de datos a fondo, el dominio del problema que quiero resolver, y la plataforma en la que la voy a desplegar, no puedo tomar ese compromiso.

---

A lo largo de los años, he conocido muchas empresas empujando una solución que sólo usa la base de datos como un almacén que habla SQL, y prefieren escribir sus aplicaciones «fuera» de la base de datos, bajo el argumento de que tendrán varios clientes, con diferentes bases de datos, y los van a convencer a todos. Suerte con eso.

---

Hay una guía muy sencilla. Las bases de datos (al menos las buenas) están diseñadas para ser las más eficientes haciendo:

---

* JOINS -- pero hay gente que lo hace con arreglos en «lenguaje de programación cool».
* Filtrar datos (WHERE) -- pero hay gente que lo hace con condicionales en «lenguaje de programación cool».
* Proyectar datos (escoger columnas) -- pero hay gente que hace lo mismo con arreglos/mapas en «lenguaje de programación cool».
* Agregados (SUM, MAX, AVG) -- pero hay gente que lo hace con «machine learning» y «data science» en «lenguaje de programación cool».
* Integridad de identidad (clave primaria) -- pero hay gente que lo hace con dobles consultas y toda suerte de «trucos» (incorrectos) en «lenguaje de programación cool».
* Integridad referencial (claves foráneas) -- pero hay gente que lo hace con dobles consultas y toda suerte de «trucos» (incorrectos) en «lenguaje de programación cool».
* Validez de datos (sistema de tipos en la base de datos) -- pero hay gente que lo hace con doble trabajo (en el front-end y en el back-end), además de trabajar con los «tipos de datos del pobre» (i.e. String y JSON).

---

No amarrarse a la base de datos es descartar todas estas cosas, en mayor o menor medida, y cambiarlas por escribir más código fuera de la base de datos, lejos de los datos, usualmente en lenguajes con sistemas de tipos más pobres, sin agregar ningún valor, generando más trabajo ingenuo de debugging y pruebas.

---

Ningún equipo humano escala lo suficiente para abandonar todas esas ventajas, y pretender ser más eficiente que un manejador de base de datos completo.

---

No estoy incluyendo, intencionalmente, las cosas que se pueden hacer cuando tienes CTE, SQL recursivo, funciones con despacho múltiple, y un sistema de tipos completo. Esas cosas traen aún más poder y capacidad de adaptación y crecimiento para la aplicación.

---

Pero requiren compromiso y atencion al detalle. Quizás lo que no escala es esa parte de la manera de pensar de tu pana.

View more

No se puede ser papá de todo el mundo. La disciplina es algo que se enseña con el ejemplo, pero se aprende sólo por convicción.

---

Aquel que no desarrollo la paciencia, la constancia, la atención al detalle, el estudio de las alternativas, y el pensar en los problemas antes de atacarlos, siempre será un excelente echador de líneas de código en el lenguaje moderno de turno. Y por eso se lo merecen.

---

Programar es fundamentalmente pensar en el problema, diseñar la estructura de datos que lo modela, y luego expresar las relaciones (que serán obvias si el diseño es correcto). Apurarse en el diseño lleva a perder tiempo. Perder tiempo lleva a improvisar. Improvisar lleva a crear nuevos problemas. Y así en el círculo vicioso de «coding». Súmale a ésto la terrible selección de lenguajes de programación típica de la industria moderna, y la necesidad de «tener algo para mostrar» porque la improvisación ajena se convierte en la urgencia del que tiene que hacerlo funcionar.

---

La recomendación que tengo es la misma que hago a estudiantes y colegas: no lo dejes para última hora, no comiences a programar si no comprendes completamente el problema, no escribas ni una sola línea de código hasta que la estructuras de datos representen el problema, y no insistas en arreglar algo que está mal diseñado.

---

Pero todo el mundo es sabio en su propia enciclopedia.

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

Lo que realmente importa es lo que aprendiste, que lo sepas aplicar y, más importante todavía, que lo sepas explicar. Si no eres capaz de explicar lo que «sabes», no lo sabes. Eso incluye tanto los conceptos como el uso preciso del lenguaje para exponerlo.

---

Es por eso que las mejores universidades del país tenían pruebas de admisión: para determinar con sus propios criterios, ajustados a su exigencia académica, y enfocados en las carreras particulares, si un candidato tenía los conocimientos que decía tener, y los sabía aplicar. Cada estudiante universitario es una inversión para el Estado: no se puede invertir en cualquier cosa. Ese mecanismo no garantizaba el éxito de todos los estudiantes, pero apuntaba a reducir el fracaso y la deserción por causas académicas. Sólo un necio discutiría en contrario, pues la evidencia está a la vista..

---

Es una decisión lamentable que ahora sólo se use el promedio y razones subjetivas para decidir si alguien entra o no a una universidad. Quizás un estudiante que tiene el mismo promedio, pero tiene peores aptitudes, ingrese a estudiar una carrera que «quiere» pero para la cual no tiene «pasión». El que «perdió el tiempo» en bachillerato, no puede exigir prebendas: su conducta no fue la de un estudiante productivo, y el ingreso a una universidad será contraproducente para el estudiante y para la universidad.

---

Claro que hoy en día, con las alteraciones que ha sufrido la educación media, ese promedio alcance para muchas carreras. Bajar intencionalmente la barra de acceso académica ha causado un notable descenso en la calidad de la «materia prima» con la cual trabajar en la universidad (y además, llegan «sabiendo todo»). Más que promedio, lo que hace falta es educación, buena actitud, y quitarse esa tara de que «hay que tener un título para ser alguien en la vida».

---

Para ser alguien, lo que necesitas es aprender por el simple gusto de aprender, trabajar para mejorarte y ayudar a mejorar a los que están a tu alrededor, no esperar nada de nadie, tener constancia, persistir, y no involucrarse en actividades que te hagan perder el tiempo. Ese es el verdadero promedio que debes mantener alto todos los días.

View more

Comienza por aprender a diseñar y escribir programas bien. Hazte un favor y evita la estrategia «copiar y pegar cosas de $SITIO_DONDE_HAY_ALGO_PARECIDO» -- piensa en los problemas, compréndelos usando papel, lápiz y dibujos, antes de sentarte a escribir una línea de código.

---

Para aprender a diseñar y escribir programas, lee los siguientes libros y completa los ejercicios. No te asustes por el lenguaje, que «nadie» conoce -- vas a tener una ventaja incluso sobre montones de gente que estudiaron computación pero fueron seducidos por la popularidad en lugar de calidad

---

http://www.htdp.org/ -- «How to design programs»
https://mitpress.mit.edu/sicp/ -- «Structure and Interpretation of Computer Programs»

---

Estudiar computación te hace escribir los mejores programas posibles en términos de estructuras de datos y algoritmos. Cualquiera puede programar, pero para programar bien, además de práctica, hacen falta técnicas que no son evidentes y deben estudiarse. Para tu aprendizaje inicial no hacen falta, pero tan pronto puedas escribir programas, es importante que amplíes tu investigación.

---

Para cómputo científico hay muchas cosas que debes aprender, sobre todo relacionadas con el mantenimiento de la precisión y algoritmos específicos para hacer cálculo numérico. En este sentido, hay muchos libros de texto que te van a orientar.

---

Si tu interés es el para cómputo científico numérico, aprende el lenguaje de programación Julia (http://julialang.org) y los lenguajes Octave o R. Si tu interés es el cómputo científico para análisis genético, eso está más cerca de lenguajes y patrones simbólicos, para lo cual lenguajes como Racket, Perl y Prolog van a ofrecerte mejores facilidades.

---

Lenguajes como C/C++, Java, Python, Ruby y JavaScript, si bien son de propósito general y puedes usarlos para atacar esos problemas, están mucho menos preparados para el problema en particular y tienes que hacer más trabajo en cosas laterales, en lugar de concentrarte en lo interesante. Es irrelevante que sean «populares», porque, citando a Les Luthiers, «La gente, ¿qué sabe?»

View more

Cuando estaba por terminar pregrado, en 1990, cursé una materia complicadísima para construir un perceptrón que reconocía letras. Letras. Algo torcidas, pero no mucho. Eso era «Inteligencia Artificial».

---

Cuando estaba comenzando la maestría en 2003 cursé una materia práctica (la teórica no la cursé y no importó) en la cual usamos Support Vector Machines para detectar rostros en un video en vivo. Rostros en un video. Mi implantación logró 8 FPS con doce rostros en pantalla.. Eso era «Inteligencia Artificial».

---

En la misma maestría, tomé un curso de Algoritmos Genéticos. La técnica es simpática, imita a la «naturaleza» y produce resultados buenos (pero nunca «perfectos»). Hice un programa que construía crucigramas; salían crucigramas «chéveres», pero nunca salían crucigramas de calidad para humanos.

---

Después de eso, reflexioné sobre un comentario de un profesor importante en mi formación, que dejé pasar prima facie como sarcástico, pero que terminó siendo significativo (como todo lo que ese profesor dice). Me dijo: «inteligencia artificial es un eufemismo por "todavía no sabemos cuáles son las cuentas para este problema"».

---

La plétora de herramientas que existen hoy en día para «aprendizaje» de máquinas e «inteligencia artificial», que son tanto útiles como interesantes, terminan siendo la aplicación de matemáticas (programación lineal, no-lineal, estadísticas) para aproximar lo mejor posible la extracción de información relevante usando patrones aproximados. En esa matemática y esos algoritmos en ejecución, a mi juicio no se manifiesta ningún comportamiento «inteligente»: inteligente es el grupo de personas que a lo largo del tiempo han dado con esos modelos y esos algoritmos.

---

Si las tareas que sabes hacer como humano son absolutamente mecánicas, de seguro serás reemplazado por una computadora que lo hará más rápido, con más precisión, y sin cansarse. Pero si las tareas que sabes hacer como humano son creativas y cuyo método depende de la improvisación o el caos universal, soy de la idea que no puede reemplazarse.

---

Hay muchísimos procesos mentales que son definitivamente «sumar rápido», que en el fondo quiere decir que son computables y son, o serán, imitados perfectamente por una computadora (o muchas computadoras). Sin embargo, soy de la opinión que existen algunos procesos mentales que no son computables (tampoco sé cómo funcionan, sólo pienso que no son computables, así como pienso que P no es igual a NP).

---

Dos lecturas muy provocativas para explorar la relación entre las máquinas y la inteligencia, «Gödel, Escher & Bach: an eternal Golden Braid» y «The Emperor's New Mind» son complementarias.

---

No encuentro mayor inteligencia en los programas de Inteligencia Artificial, pero admiro y aprecio la inteligencia que hay en mis colegas que exploran y desarrollan esos métodos.

---

Claro que la gente dice que la computadora «está pensando», y me pregunto cuál de los dos está razonando mejor.

View more

Conocí a RMS en 1996. Coincidimos en varias conferencias enre 1997 y 2001. Lo volví a ver cuando lo llevaron a Venezuela con el fomento del Software Libre.

---

En todas esas ocasiones, sus presentaciones públicas han sido exactamente iguales: mismo discurso, mismos manerismos, similar histrionismo. A lo largo de los años ha mantenido sus hábitos desagradables independientemente del tamaño de la audiencia. Hay gente que llama a eso «excentricidad» u «originalidad»; yo prefiero llamarlo mala educación y falta de civilidad.

---

En más de una oportunidad lo ví ignorando abiertamente a todos los comensales que trataban de compartir con él. En algunos casos absorto respondiendo correo, en otros casos leyendo, pero siempre porque él no era el centro de atención exclusivo. Me disgustó mucho la forma en que utilizaba a su novia como mesonera o recadera, según la circunstancia, incluso cuando la pobre estaba completamente agotada y él estaba echado en una hamaca.

---

Le agradezco muchísimo por haber escrito GCC y GDB, pues me sirvieron como herramienta de aprendizaje. EMACS realmente me tiene sin cuidado igual que su desprecio por vi. Es encomiable todo el esfuerzo que ha puesto y continúa poniendo en la construcción y difusión del Software Libre, tanto en los términos legales de la GPL, como en la motivación a terceros. Ha sido un motor.

---

Es sumamente testarudo e intransigente, cosa que se vuelve nociva cuando la combinas con su total carencia de tacto en cuanto a las relaciones humanas. Si eso fuese sólo en el contexto de la ciencia de la computación y de la libertad de acceso al software, sería tolerable y comprensible. El asunto es que es así para todas sus cosas, y eso lo hace difícil de tragar. A menos que seas uno de sus acólitos que no pueden ser cómo él porque no tienen la convicción ni el carisma. Es el tipo de persona que le encanta cualquier idea, siempre que sea la suya.

---

Yo no lo invitaría a tomar cerveza.

---

Eric Raymond es más o menos igual, pero «de derecha» (con todo lo ridículo que es hablar de «derecha» e «izquierda» en el mundo moderno).

---

Linus Torvalds es muy diferente. Lo conocí en 1996 y compartimos pizza y cerveza. Lo volví a ver en 2001, y recordaba exactamente toda la conversación que tuvimos en 1996, y volvimos a compartir pizza y cerveza. Incluso hace veinte años, ya era un «señor» en cuanto a la manera de tratar a la gente en el espacio de socialización y en no dejarse «endiosar».

---

Es implacable con aquellos que no hacen el mínimo esfuerzo de estar a la altura del compromiso técnico, y le tienen sin cuidado las discusiones filosóficas. No le importa si lo llamas Linux o GNU/Linux; lo que le importa es que seas organizado y competente. Su «brutal honestidad» es más objetiva que la de RMS.

---

Larry Wall está en esa liga, sin groserías.

---

Es imposible caerle bien a todos, pero siempre tienes que ser educado con los demás. RMS y ESR, no lo son. Linus, Larry, y otros notables sí.

View more

En primer lugar, «escalabilidad» es un término abusado, fundamentalmente porque «la gente» cree que el mundo es una «regla de tres». Para contestar, tengo que aclarar lo que quiere decir «escalabilidad» y mi respuesta sólo se puede interpretar a su luz.

---

En el contexto de cualquier sistema de información o cómputo, la escalabilidad NUNCA ha sido, NO es y JAMÁS sera lineal. Llega un punto en el cual agregar recursos no genera mejoras en el desempeño, y llega otro punto en el cual agregar recursos empeora cada vez más la situación. La Ley de Amdahl para el caso multiprocesamiento y la Ley Universal (o de Gunther) para el caso de sistemas distribuidos, lo demuestran matemáticamente.

---

De manera que hay que partir por comprender y asumir que TODO sistema tiene un tope de escalabilidad. Cuando se alcanza ese tope lo único que se puede hacer es rediseñar el sistema para cambiar la curva y ganar un poco más, pero es imposible resolver el problema con hierro.

---

Ahora, regresando a tu pregunta original. El problema para el cual las bases de datos NoSQL presuntamente son más efectivas, es para el manejo de datos clave-valor, con valores no estructurados. Simular ese escenario en una RDBMs cualquiera, conduce a una curva de escalabilidad particular, que está afectada por el principio ACID. Las bases de datos NoSQL no son, ni van a ser ACID, por lo que su curva de escalabilidad para ese problema es mejor a priori. Si no te importa la consistencia ni durabilidad de tus datos, probablemente sientas que una base de datos NoSQL es «más rápida» que usar un RDBMs tradicional.

---

Ahora bien, PostgreSQL es un ORDBMs. Además de siempre haber sido ACID, garantizando integridad, consistencia y durabilidad, tiene capacidades para el manejo de objetos libres (parejas clave-valor). Cuando se usan las habilidades para almacenar JSON en PostgreSQL, tienes exactamente las mismas facilidades de alto nivel que en las NoSQL, con condiciones de integridad/consistencia/durabilidad permanentes, y con un mecanismo de almacenamiento suficientemente eficiente.

---

Es díficil hacer cualquier cosa que no se comprende. Nunca es la flecha, siempre es el indio. Personalmente no he tenido problemas para hacer escalar PostgreSQL hasta los límites de la aplicación que sostiene, porque todas las aplicaciones han sido *simuladas* antes de ponerlas en producción, conociendo cuál es la curva de desempeño.

---

He visto fracasos rotundos de mega-super clusters de NoSQL que fueron considerados a priori mejores que PostgreSQL. Se les deja estrellarse y morir, para luego mostrarles cómo PostgreSQL maneja el problema con simplicidad. «Wow, no sabíamos que PostgreSQL podía hacer eso» suele ser lo que atinan a decir — yo solía decirles «es increíble lo que uno aprende leyendo los manuales y estudiando matemática», pero he visto que al chiquitaje le afecta más cuando no se les dice «te lo dije».

---

De paso, PostgreSQL, en mayúscula, porque se lo ha ganado independientemente del mercadeo malintencionado y los trolls

View more

Hay mucha gente que conoce Racket, y es gente con la cual se trabaja mejor que con gente que no conoce Racket. Puedes cambiar Racket por cualquier otro lenguaje puramente funcional (LISP, Erlang, Haskell, ML) y sigue siendo válido.

---

Además, Racket es un lenguaje que va a cambiar tu manera de pensar como programador, y si nunca has programado, vas a comenzar con ventaja porque te hará aprender cosas «desde cero» que los que no conocen Racket no sólo no han aprendido, sino que tienen que «desaprender» vicios para aprenderlas. Es probable que no lo comprendas ahora, y el que venga a leer esta respuesta sin conocimiento de causa piense exactamente lo mismo -- deja de pensar en lo difícil de aplicarlo después y concéntrate en aprender, deja de pensar en lo diferente como inconveniente y considéralo interesante.

---

Si el curso sigue el libro, vas a aprender dos cosas: conceptos y disciplina para diseño de programas, que son transversales a Racket y aplicables a cualquier otro lenguaje de programación inmediatamente; y estrategias de razonamiento recursivo y funcional, que son específicos de cualquier lenguaje que use recursión, así que puedes aplicarlos directamente con cualquier otro lenguaje que soporte recursión (y como la aprendiste *bien* la vas a poder usar bien y sin miedo, cosa que no les pasa a los que aprenden con iteración y les dicen que la recursión es mala).

---

El aprendizaje nunca sobra. Lo que sobra es la resistencia al aprendizaje y la falta de paciencia. No hay camino rápido para dominar ninguna cosa que valga la pena.

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

Hay dos paradigmas fundamentales: el imperativo, que requiere indicar los pasos precisos para completar un cómputo (el "cómo"); y el declarativo, que consiste en indicar las relaciones involucradas entre los datos para completar un cómputo (el "qué"). En ambos casos, el vehículo es un lenguaje de programación.

---

El paradigma imperativo es el más frecuente en los lenguajes de programación (C, Python, Ruby, Java, Smalltalk, ensamblable de cualquier procesador) porque imita directamente a las máquinas. Eso hace que la mayoría de la gente esté expuesta y aprenda a programar con lenguajes imperativos. Es típico de los lenguajes imperativos el concepto de "variables que cambian" (estado mutable) y de instrucciones para cambiar las variables (asignaciones) o controlar el flujo (condicionales e iteración). Esto no es necesariamente malo, pero dificulta enormemente razonar sobre los programas y componer programas complejos a partir de programas simples.

---

El paradigma declarativo tiene tres variantes generales: la programación funcional, que consiste en expresar el problema como una serie de funciones, que al componerse, toman un valor inicial y producen un valor final (LISP, Haskell, Erlang); la programación "lógica", que consiste en expresar el problema como una serie de relaciones entre los datos, y combinadores de inferencia para obtener el resultado (Prolog, SQL); la programación por restricciones, que consiste en expresar el problema como un grafo de dependencias que se reconstruye al cambiar valores (hoja de cálculo, Verilog). Este paradigma es mucho más matemático (no hay estado mutable, ni ciclos, sólo recursión), permitiendo razonar con mayor rigurosidad sobre los programas y facilitar la composición de soluciones. En particular, en el mundo moderno, la programación declarativa funcional es ampliamente superior para escribir sistemas concurrentes y paralelos.

---

Puede usarse cualquier paradigma para resolver cualquier problema, porque todos son igualmente poderosos (Tesis Church-Turing). Las ventajas de usar uno u otro dependen del problema específico, por eso no hay ningún lenguaje inherentemente mejor que los demás.

---

"Programming Language Pragmatics" (Scott) es un texto introductorio al tema de diseño de lenguajes de programación, en el cual se discuten los tópicos antes descritos y muchos otros relacionados con la evolución de los lenguajes de programación y su aplicabilidad.

---

Personalmente, para programación imperativa posiblemente orientada a objetos, prefiero usar Perl, y para programación declarativa uso Haskell, Erlang, Prolog y SQL99 como lo provee PostgreSQL.

---

Los lenguajes de programación son un tema de abordaje complejo, por condiciones sociológicas que son absolutamente irrelevantes para el técnico, pero fundamentales para el aficionado y las comunidades de desarrollo. No obstante, la ventaja de estudiar cómo funcionan los lenguajes, es que después es muy difícil que un lenguaje te sorprenda o te deje desarmado.

View more

Determinar si una cadena tiene la *forma* de una dirección de correo válida, debe hacerse siguiendo la gramática que se describe en RFC-5322 § 3.4.1. Eso, efectivamente, lo puedes hacer con expresiones regulares, o con un reconocedor recursivo descendiente, este último siendo algo más eficiente en tiempo y espacio.

---

Las expresiones regulares involucradas no son triviales, e incorporan restricciones de longitud que mucha gente se salta, así que siempre es mejor que uses una librería de validación pre-existente en tu lenguaje, escrita por alguien que haya tomado en cuenta esos detalles.

---

Verificar la forma no decide si la dirección de correo es válida (es decir, «funciona»). Para eso tienes que determinar si el dominio existe, si tiene servidores de correo anunciados, si esos servidores efectivamente aceptan mensajes para el dominio, y si realmente son procesados hacia esa dirección. Esto sólo lo puedes comprobar enviando un mensaje y recibiendo respuesta -- pero no garantiza que la próxima vez volverá a funcionar.

---

La librería Email::Valid de Perl hace la primera parte correctamente, y todo lo de la segunda excepto enviar mensajes de prueba. La librería Email::Address de Perl también hace un buen trabajo. El paquete email-validate de Haskell sólo hace la primera parte.

View more

Otras personas escogieron Go, con criterios diferentes a los que yo hubiera aplicado; no era mi selección. El resultado ha sido razonable, considerando las destrezas del grupo y los problemas particulares que hubo que resolver. Lo que está escrito en Go habría sido mucho más difícil de escribir en C, y la ganancia en desempeño no habría sido notable; estaba escrito en Perl, y ha sido más trabajo reescribirlo en particular por la carencia de librerías consistentes en Go, pero la ganancia en desempeño por ahorro de memoria lo ha justificado. Las carencias de Go han complicado otras áreas.

---

Puedo escribir programas en más o menos 20 lenguajes de programación diferentes. Sin embargo, sólo hay 7 u 8 que realmente me resultan efectivos y simpáticos para trabajar.

---

Son muchos los criterios para escoger. Uno es saber si voy a trabajar sólo o acompañado, y cuál va a ser la audiencia de la solución en términos de mantenimiento. Después, hay que entender el problema lo suficiente antes de escoger; aquí es donde entra en juego la experiencia y el estudio previo.

---

Si hay que resolver un problema de procesamiento de datos que están o van a estar en una base de datos, el lenguaje es PL/pgSQL de PostgreSQL, y se escribe *todo* dentro de la base de datos. Prueba superada hace más de una década. Si el problema es de análisis estadístico de esos mismos datos, probablemente quiera usar PL/R. Si los datos están fuera de la base de datos, y nunca van a estar dentro, probablemente use Octave o R, según el tipo de cómputo a realizar.

---

Para labores de administración de sistemas, transformación de datos, interacción con servicios (SMTP, IMAP, HTTP) seguramente usaría Perl.

---

Hay cosas que sólo las puedes escribir en un lenguaje. Por ejemplo, para hacer una extensión para PostgreSQL, o un módulo PAM tienes que escribir en C.

---

Ahora mismo estoy estudiando un problema que es de base de datos, pero el problema es una combinación de manipuación de símbolos y búsqueda exhaustiva. Obviamente lo estoy haciendo en Prolog. Si después resulta «lento», veré cómo lo transformo, pero para ese problema, termina siendo el mejor lenguaje.

---

Para aplicaciones concurrentes y paralelas, servicios REST puros, o hacer un lenguaje, usaría Haskell.

---

En todo caso, el fondo es que con un sólo lenguaje no puedes resolver todos los problemas eficaz y eficientemente. Es muy importante en tu vida profesional aprender y dominar más de un lenguaje; a menos que tu deseo sea dedicarte a una, y sólo una cosa, en cuyo caso es probable que con un sólo lenguaje atiendas tus necesidades razonablemente bien.

---

Finalmente, evita caer en la tentación de pensar que un problema se resuelve con un sólo lenguaje. Hay problemas en los cuales deben participar varios lenguajes, cada uno apropiado para la sección del problema que ataca. El éxito está en tener práctica con tantos lenguajes y paradigmas, que puedas romper cada problema en pedazos que son representables de manera clara y rápida con cada uno.

View more

Mi familia materna es argentina. Crecí con la cultura, tradiciones, e historia argentina y venezolana a partes iguales. Tengo doble nacionalidad, y como no quiero ser presidente de ninguno de los dos países, no tengo que ocultarlo.

---

Prefiero el mate al café, pero no cambio la arepa por pan. Prefiero el tango y el rock argentino, pero tengo espacio para Serenata Guayanesa (que varias veces tocaron en mi casa antes de llamarse así). Prefiero el rugby y el fútbol, antes que el béisbol y el basket, pero el Orinoco es más soberbio que el Río de la Plata. Prefiero la educación, la cultura, y la razón, antes que el caudillo, el «compa» y el «vivo», y ambos países tienen su cuota de ambos. Les Luthiers o Aquiles Nazoa, que los demás son todos rancios.

---

En Argentina aprendí a vivir las estaciones, y como el no tenerlas en Venezuela nos hace perder noción del tiempo y tener poca memoria. En Venezuela aprendí a tener paciencia con los pobres que desprecian cualquier cultura que no es la suya, apoyándose en prejuicios y estereotipos; ojalá pudieran viajar, aunque fuera leyendo cosas que no sean panfletos. En ambos países observé los necios de izquierda y de derecha, perdiendo energía en discusiones inútiles, en lugar de ser prácticos y aceptar la realidad.

---

La patria no es el lugar donde se nace, sino el lugar donde se pueden ejercer tus derechos y desarrollar tu vida, en libertad y paz. Hoy estoy mucho más cerca de Argentina, que de Venezuela, pero algún día espero que vuelvan a estar equidistantes. Desde pequeño aprendí, que no hay nadie más necio que aquel que piensa que un sitio es mejor que otro, y hay que serle fiel hasta la incongruencia, sólo porque se nació allí. Nací en Venezuela, pero aprendí más del mundo gracias a Argentina.

View more

Inglés y español.

---

Haskell
Perl
Prolog
C
Erlang
C++
Smalltalk
LISP - Scheme - Racket - Common LISP
Standard ML
LaTeX
Octave
R
PL/pgSQL
Shell Unix (el estándar, porque si se complica voy a Perl)
Povray
LOGO

---

Conozco muchos otros lenguajes de programación (eso es lo que hago). Los pruebo hasta el punto en que no me enseñan nada nuevo, son aburridos, o evidencian su rancho, y así me doy cuenta que no sirven para mis propósitos o atentan contra mis capacidades. También están los lenguajes que son para explorar nuevos conceptos (como Agda, Coq o Idris), pero que no voy a usar en la práctica.

---

Cosas como

---

Ruby
Golang
Rust
Elixir

---

son cuchis, pero no aguantan el aguacero. Del resto, que ni los nombro, prefiero que sea otro el que tenga que escribirlo, porque la vida es muy corta.

---

De todas formas, más importante que los lenguajes que conozco es el hecho de que estudié cómo funciona cualquier lenguaje. Hay lenguajes que uso hoy, que no existían cuando estudié, pero que me resultaron accesibles rápidamente porque: estudié compiladores, estudié los estilos de programación declarativa, y estudié teoría de la computación.

---

Un buen programador de Fortran va a programar Fortran en cualquier lenguaje. Y eso es malo. Pero peor aún es un programador que sólo sabe usar un estilo de programación y cree que hay UN sólo lenguaje de programación que sirve para resolver todos los problemas. No seas ese programador, porque vas a quedar para «echar código» hasta aburrirte, pero te perderás de resolver problemas con menos esfuerzo expresando las soluciones con más claridad.

View more

No uso dispositivos Apple porque son un descarado «vendor lock-in with forced updates». Tengo una MacBook asignada por el trabajo, a la cual le instalé Debian GNU/Linux y listo.

---

No uso teléfonos Android con firmware stock *de fabricante* ni de *operadora*. Esto es, no uso no recomiendo Samsung ni LG, ni aquellos que tienen firmware de Movistar, T-Mobile, etc. porque además de un montón de aplicaciones inútiles y sospechosas, tienen un «final de vida» anticipado para obligarte a comprar el más nuevo.

---

Sólo uso teléfonos Android con el firmware puro y simple directo desde Google (como el Nexus 6 que tengo en la mano), o aquellos en los cuales puedo instalar Cyanogen (como algunos Samsung que tuve en el pasado). Cómo ya pasó mi interés por instalar firmware en teléfonos, el próximo teléfono será, naturalmente, un Google Pixel.

View more

Con Mucho Cuidado.

---

Revisando las premisas constantemente: la mayoría de los sesgos aparentemente objetivos comienzan por tener premisas equivocadas o incompletas.

---

Aprendiendo a razonar deductiva e inductivamente de forma correcta: muchos sesgos ocurren por razonamientos falaces («falacia» no es sinónimo de falso, sino de «razonamiento incorrecto» -- una «falacia» puede llegar a un resultado cierto, cuando en realidad debería ser falso, y viceversa). Si es difícil hacerle a entender a personas aparentemente inteligentes que están razonando mal, imagínate convencerte a ti mismo de eso -- requiere mente tranquila dispuesta a aprender y no a «tener razón».

---

Aceptando que evidencia obtenida y corroborada independientemente, vale más que cualquier testimonio: no importa quién sea el que echa el cuento, ni tampoco el volumen de la «mayoría» que le parece «lógico»; si hay evidencia en contrario, tienen que aprender de la evidencia. Cambiar o ignorar la evidencia para adaptarla al mundo que «nos gusta» es una deficiencia moral e intelectual.

---

Que una opinión sin experimentos reproducibles y números para sustentarlos, se llama «prejuicio». Eso de «respeto pero no comparto» es de cobardes intelectuales: si no tienes como sostener tu opinión con lógica formal, cámbiala por aquella que si lo sostenga. Las opiniones no son para «respetarse», son para «comprobarse» o «refutarse», y el que se siente ofendido porque le desmontaste su opinión, tiene triple trabajo.

---

Finalmente, si no abres la boca cuando no sabes o cuando no estás seguro de tus razonamiento, jamás podrás meter la pata. Es mejor escuchar, revisar las premisas, corroborar el razonamiento, completar la evidencia, y luego abrir la boca para enunciar un argumento irrefutable, si es que puedes construirlo con solidez. «¿No vas a opinar?» contestado con «no tengo suficiente información para adoptar una postura de manera inteligente y razonada» es lapidario y sólo puede ser malinterpretado por personas que no están acostumbradas a razonar (y así las identificas).

---

La pasión discute, pero sólo la razón triunfa. Requiere mucho trabajo, pero cada vez estás más seguro de tus procesos mentales y te das cuenta que la «mayoría normal» en realidad sólo quiere «tener razón» en lugar de «aprender». Trata de aprender todo el tiempo, desaprendiendo las barbaridades que te llegaron por tradición, convención, participación, o pasión ajenas.

---

Una de las razones por las cuales es tan agradable discutir con colegas de las ciencias exactas, es que no sólo no gana el que más chilla o tiene «mayoría», sino el que tiene la demostración correcta, y todos los demás dan las gracias inmediatamente. Gente seria.

View more

Hay cuatro ideas fundamentales, a partir de las cuáles se derivan más beneficios:

---

1. Son más cercanos a la formulación matemática de los problemas de cómputo, por lo tanto es muchísimo más fácil razonar sobre la correctitud y complejidad en tiempo y espacio de los mismos, en comparación con los imperativos. Este es un beneficio de muy alto nivel.

---

2. La noción de inmutabilidad combinado con las estructuras matemáticas subyacentes al modelo de cómputo funcional permiten a los compiladores realizar transformaciones y mejoramiento de código que son imposibles [1] para un lenguaje imperativo convencional. Así, el ejecutable es muy eficiente, con menos esfuerzo. Este es un beneficio de muy bajo nivel.

---

3. Combinando (1) y (2) con un sistema de tipos completo (como el de Haskell) se puede lograr que sea el compilador el que verifique que no has escrito estupideces, ahorrándote escribir pruebas estúpidas. Es imposible ([1], otra vez) detectar todos los posibles errores, pero hay un grueso de errores inducidos por el «estado mutable» que desaparecen automáticamente.

---

4. La ausencia de estado mutable facilita el paso a programación concurrente o paralela, de modo que tus programas pueden explotar todos los núcleos de cómputo sin penar con hilos, semáforos, deadlock, starvation, etc.

---

Los lenguajes que combinan expresión funcional con imperativa, NO son lo mismo que un lenguaje puramente funcional. No aceptes imitaciones.

---

Si la programación funcional no transforma tu manera de pensar y de disfrutar las actividades de modelado y programación, tienes que insistir. Resistirse es inútil, serán asimilados.

---

[1] Estoy usando el término «imposible» para referirme a problemas que son indecidibles (no programables por nadie, nunca).

View more

Los lenguajes dinámicos también hacen verificaciones de tipos, sólo que las hacen a tiempo de ejecución. Hay lenguajes dinámicos con sistemas de tipos bastante estrictos, como Racket, Erlang o Prolog. No verifican nada antes de correr, pero si verifican muchas cosas durante la corrida. Evidentemente, esto permite que el desarrollador escriba muy rápido, pero difiere todos los problemas a la hora de la ejecución.

---

Hay lenguajes dinámicos con sistemas de tipos débiles, como JavaScript, Python o Perl. No verifican (casi) nada antes de ejecutar, y durante la ejecución verifican algunas cosas, pero también hacen conversiones implícitas (e.g. "42" es cadena o número o booleano o arepa de perico, según convenga).. La cosa es aún peor que en el caso anterior, pues podría haber errores de tipos que no son reportados como tales, pues hay alguna regla del lenguaje que «lo permite».

---

Esto, por supuesto, hace que la gente ataque el problema construyendo un nuevo problema: hacer suficientes pruebas para «garantizar» que no hay errores de tipos.

---

Las herramientas como las que mencionas, son herramientas complementarias de análisis estático. El lenguaje principal no va a cambiar en el futuro inmediato, pero se le ofrecen al programador algunos mecanismos para protegerse un poco más. Los mecanismos no son completos, ni sustituyen a un sistema de tipos estático de primera clase, pero son mejores que «escribir pruebas» — por supuesto que estos sistemas también son pruebas, sólo que generadas semi-automáticamente. Estos sistemas no van a prevenir errores de tipos mucho mejor que lo que hace el lenguaje, porque siempre va a venir algún idiota a poner String como tipo... después de todo String es el tipo de datos del pobre.

---

La idea ni siqueira es «original». Cuando se escribieron los primeros compiladores de C, no había suficientes recursos (RAM/CPU) para hacer todo lo que se podía hacer de verificación. Además, no se sabía lo suficiente de verificación estática y análisis de flujo para detectar errores que hoy en día son simples de implantar en cualquier compilador. Entonces, se inventó la herramienta `lint`: sólo hacía análisis estático de los programas en C, indicando malas prácticas, posibles errores e incluso formas no portátiles presentes en el código. Hoy en día, `lint` no es necesario porque los compiladores de C ya incluyen esas técnicas.

---

El atractivo fundamental de los lenguajes dinámicos es (para algunas personas), que no hay un sistema de tipos estrictos que se escandalice ante las idioteces antes de correr y que el programador es libre de (ab)usar la representación de sus datos a gusto y (ab)usar las reglas de conversión implícita. Se sabe que eso es una mala idea desde el punto de vista de mantenimiento y de seguridad del código, así que se intenta ofrecer herramientas adicionales.

---

Míralo como herramientas para ayudar a los que no quieren/pueden/saben cambiar sus prácticas, y creen que sus mentes son mejores que un sistema de tipos. Vicio sobre razón.

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