EM Hernández-Novich

Python y Perl son los nombres de los lenguajes, mientras que `python` y `perl` son los nombres de los interpretadores.

---

Tanto Python como Perl son lenguajes mucho más flexibles en términos de expresividad. En particular Perl tiene disponible varias implantaciones (Moose, Mouse, Moo) de un modelo de objetos superior al de Python y ampliamente superior al de Java. Así, lo que usan Orientación a Objetos No-Jerárquica tienen mejores oportunidades de expresar los problemas de forma simple y eficiente con Perl y Python, que con Java.

---

Python y Perl tienen modelos de recolección de basura que hacen la ejecución y consumo de memoria razonablemente predecibles, en contraste con Java, que usa un modelo de recolección de basura que desperdicia mucha memoria y que en ocasiones es impredecible. Agrega a eso, que Python y Perl tienen herramientas de instrumentación y análisis de desempeño mucho más completas que las de Java, lo cual facilita identificar problemas relacionados con pérdidas de memoria.

---

Finalmente, encuentras mejores librerías y más organizadas para Python y Perl, que para Java. Hoy en día el costo de tiempo de programación es notablemente mayor que el costo de CPU y RAM, así que tener tantas librerías disponibles y fáciles de encontrar, hace mucho más cómodo el proceso.

---

Personalmente no escogería Python, porque aún siendo más flexible que Java, sigue siendo rígido en términos de lo que se puede hacer. Mucha gente que pasa de Java a Python se siente a gusto precisamente con esa filosofía: «ésta es la forma en que tienes que hacerlo».

---

Finalmente, y en un aspecto MUY técnico, los tres lenguajes son de «máquina virtual»: Java lo exhibe abiertamente en la dualidad `javac`/`java`, Python te lo ofrece como una opción, y Perl lo hace implícitamente. Si uno compara las tres máquinas virtuales, las de Python y Perl son superiores a la de Java en términos de la familia de instrucciones virtuales disponibles; comparar las de Python y Perl es más complicado.

---

El hecho de que Java sea un «lenguaje compilado» no hace que sus programas sean necesariamente más rápidos que los de Python o Perl, precisamente por limitaciones inherentes a su máquina virtual (que es una simple máquina de pila).

---

Por último, Python y Perl son lenguajes que evolucionan y se enriquecen de nuevos conceptos, muchísimo más rápido que lo que logra Java. Eso tiene que ver con su comunidad de usuarios y con la gobernanza de los proyectos. Java está hoy, donde Python y Perl estaban a principios de siglo, y con muchas dificultades para adaptarse de manera limpia a los tiempos modernos.

---

Java es el nuevo COBOL.

View more

Para la autenticación (verificar credenciales) si la aplicación está respaldada en una base de datos, usa a la base de datos para autenticar. Esto NO quiere decir tener una tabla 'usuarios' y volver a inventar la rueda; quiere decir que cada usuario del API tiene su CREATE USER en la base de datos. Si usas PostgreSQL, la documentación te explica cómo tener el usuario definido en PostgreSQL y la clave en un mecanismo externo accesible via PAM. Nada es más eficiente y flexible que esto. Si no usas PostgreSQL, es momento de usarlo.

---

Con eso resuelves el primer factor de autenticación. Para tener otro factor de autenticación, puedes usar PAM via la base de datos, o directamente a través del API a tu proveedor favorito. Aquí no tengo preferencia pues depende del segundo factor -- algunos son triviales via PAM, otros no.

---

Para la autorización (cuáles elementos de información puede acceder cada usuario), si la aplicación está respaldada por una base de datos, emplea el mecanismo ACL de la misma (GRANT) y maneja las excepciones en el API. Para la mayoría de los APIs es más que suficiente con la granularidad provista por PostgreSQL. Nuevamente, reinventar la rueda con una tabla de permisos es la receta para trabajar de más y probablemente meter la pata. Las herramientas de desarrollo que acostumbro usar (Perl Catalyst o Haskell Yesod) tienen mecanismos para expresar en el lenguaje del frente restricciones que se representan con estructuras (y posiblemente datos) en la base de datos, para los casos en los cuales no bastan los GRANT (que es muy raro).

---

No mencionaste Auditoría (¿quień hizo qué y cuándo?). Es la tercera «A» de un sistema AAA completo y correcto. Aquí te conviene llevar al menos dos registros. Primero, el registro de tu servidor HTTP, asegurándote de incluir el token de identificación (¿quién?) -- si lo guardas en la base de datos o en archivos es lo mismo; la realidad es que no se consulta con mucha frecuencia, y las herramientas de detección de anomalías o fraude deberían hacerlo inicialmente por lotes. Segundo, el registro de transformaciones a los datos dentro de la base de datos SQL para las operaciones que cambiaron los datos (usualmente cuestión de poner unos triggers y tener tablas históricas de transformación). Puntos extra si la tabla tiene «time travel» para poder revisar cómo estaban los datos en cualquier momento del tiempo.

---

Bonus: si apoyas tu AAA en la base de datos, de seguro vas a poder enviar los eventos al SYSLOG con un facility específico, y así tienes una bitácora dedicada sólo con los eventos AAA relevantes.

---

Si tu aplicación no está respladada por una base de datos, cualquier solución va a ser bastante «ad hoc» y es difícil hacer una recomendación.

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

A programas iguales, el ejecutable generado por C++ será más rápido y tendrá un comportamiento razonablemente predecible en términos de manejo de memoria.

---

«Programas iguales» es delicado. C++ usa despacho estático a menos que digas lo contrario (rápido pero inflexible si quieres hacer polimorfismo) y Java usa despacho dinámico a menos que digas lo contrario (muy lento pero necesario si quieres hacer polimorfismo). C++ usa modelo de valor y tiene apuntadores reales (que suele ser confuso para mucha gente), mientras Java usa modelo parcial de referencia que causa muchas indirecciones en memoria (eso es lento). Así que ambos tendrían que usar despacho estático y dinámico de manera adecuada — la postura de C++ es que despacho dinámico usa el que sabe y por eso lo pone; la postura de Java es que hay que usar despacho dinámico a menos que sepas que no lo necesitas (que es la mayoría de los casos, pero el programador rara vez sabe las implicaciones de no hacerlo). C++ tendría que usar apuntadores para aproximarse a la comparación con Java; pero Java no puede usar modelo de valor para los objetos, así que es más «perjudicar a C++ para que sea similar a Java».

---

Si el problema requiere múltiples comportamientos, usar herencia múltiple en C++ usualmente es más cómodo que armar interfaces en Java o construir los CrapGeneratorEnumeratorFactoryPleaseKillMe necesarios.

---

C++ es un lenguaje cada vez más complejo de comprender enteramente. La sintaxis es sencilla, pero hay tantos casos borde y especiales, que es muy díficil dominar todo. Es el costo de explorar cosas y tratar de satisfacer a todo el mundo.

---

Java es un ejemplo de un diseño rígido orientado a evitar que los programadores se peguen tiros en el pie, facilitando que apunten más arriba eventualmente. Esa sensación de que escribir mucho es señal de buen trabajo me parece deprimente.

---

Compadezco a los que tienen que usar esos lenguajes todos los días.

View more

No son comparables pues son técnicas con diferente propósito.

---

DNSSEC permite saber si la respuesta recibida es legítima, tal cual está en la zona, sin haber sido modificada en tránsito. Esto es, si la respuesta es afirmativa («el nombre existe») o negativa («el nombre no existe»), DNSSEC permite confirmar que toda la cadena de consultas y respuestas se efectuó sin interferencia. (1)

---

DNSSEC no protege contra bloqueo de DNS en ningún nivel. Si no se permite hacer consultas DNS, no hay nada que hacer; si permiten hacer consultas DNS, las respuestas DNSSEC están firmadas pero no están cifradas, así que cualquiera puede modificarlas al paso (DNSSEC lo detectaría) o borrarlas al paso (DNSSEC no lo detectaría).

---

Lo que ofrece Google es un mecanismo para hacer consultas DNS regulares, pero en lugar de usar el protocolo DNS habitual (puerto 53) tengas que encapsularlo en una consulta HTTPS (puerto 443 (2)). Como HTTPS tiene cifrado desde la primera interacción, y está ocurriendo contra un puerto que no es el habitual de DNS, la intención es que no se pueda interferir con la consulta DNS en tránsito. Si esa consulta se hace con DNSSEC (problema del cliente), es un beneficio agregado.

---

Con esa técnica (que no es un estándar adoptado, sino una propuesta que sólo Google tiene), proteges la consulta, sacrificando la flexibilidad del procotolo DNS al «entubarlo» encima de HTTPS. Ahora bien, ¿cómo accedes al servicio HTTPS si no tienes un DNS operativo? ¿Cómo garantizas que el IP para ese sevicio DNS-sobre-HTTPS es *realmente* el IP que querías y no el de un impostor? Exaaacto. Adicionalmente, esto no prorege contra un bloqueo del HTTPS si el censor se entera que estás consultando por ahí. No uso el mecanismo de Google y no me parece razonable ni práctico.

---

Lo adecuado es tener servidores DNS autoridad para zonas, que ofrezcan DNSSEC (consultas legitimadas criptográficamente) y DNS+TLS (RFC-7858, comunicación protegida criptográficamente), además de DNS de resolución («resolvers») que los aprovechen. Lo primero se puede lograr combinando BIND9 y stunnel; para lo segundo nada como Unbound.

---

Con la combinación Unbound en tu cliente (3) y BIND9 en un servidor estable con dirección pública permanente, tienes una plataforma de resolución privada que no es interferible a menos que te corten el cable.

---

Nunca uses los resolvers de tu ISP. They suck mud thru tubes.

---

(1) Para que DNSSEC funcione, tiene que comenzar desde el TLD (la «raíz» del dominoi). Los dominio .ve no pueden usar DNSSEC porque NIC.ve no ofrece DNSSEC. DNSSEC es esencial para operaciones seguras de DNS, de correo electrónico y web; no ofrecer DNSSEC es una señal de atraso técnico importante.
(2) Obviamente simulable en el puerto 53, pero el cliente tiene que ser modificado, y es un rancho.
(3) Léase una máquina que corre alguna forma de Unix (Linux, BSD, MacOSX).

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

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.

---

Programar requiere, y desarrolla, la habilidad de analizar un problema, descomponerlo en partes simples, recomponerlo estableciendo orden y precedencia, para expresarlo como una serie de instrucciones.

---

Mucha gente logra eso sin programar, y programar una computadora reforzará esa habilidad. Mucha gente nunca lo logra, hasta que explora la programación.

---

Programar es la habilidad de escribir una serie de instrucciones para que cualquier persona pueda repetir el proceso sin «magia», «intuición», «oráculos», ni «suerte». Requiere dominar el lenguaje como vehículo para estructurar el pensamiento.

---

Programar no es «el código», sino todo lo que ocurre para construir el código. Los lenguajes aparecen, cambian, desaparecen; programar es poder expresarse con cualquier lenguaje, de computadora o no, para dejar de improvisar y hacer uso eficiente de los recursos (especialmente los intelectuales, para no reinventar la rueda cuadrada).

View more

Tengo tres, por razones diferentes, y no hay ninguno que, en mi opinión, combine las tres cosas y lo haga superior a los demás: En estricto orden alfabético:

---

* Algoritmo de Unificación, porque resuelve el problema obvio para el que fue diseñado, y varios problemas que no eran obvios una vez que lo estudias. Es el corazón de Prolog, de cualquier sistema de tipos decente, y de análisis estructural recursivo.

---

* Meta-evaluador funcional basado exclusivamente en λ-abstracciones. Porque demuestra que sólo necesitas funciones para calcular todo, es anterior a la Máquina de Turing, es mucho más breve (dos órdenes de magnitud — si, cien) que el evaluador equivalente imperativo, y puedes construir una «torre infinita» de meta-meta-evaluadores encima.

---

* Reconocedor LALR, porque es el más eficiente posible para el problema que resuelve, no es para nada obvio, y demuestra lo que se logra cuando se enfrenta un problema pensando matemáticamente y «fuera de la caja».. Knuth es un maestro artista.

View more

Ambos estilos de programación son exactamente igual de poderosos, en términos de lo que se puede programar -- son Turing-completos.

---

La respuesta a tu pregunta es «no». En algunos casos es obvia la manera de hacerlo para que sean igual de eficientes, en otros casos no es obvia -- pero la manera imperativa tampoco era obvia hasta que te la enseñaron.

---

Si estás pensando en «este libro de algoritmos tiene el algoritmo KMP en $LENGUAJE_IMPERATIVO y lo quiero escribir en $LENGUAJE_FUNCIONAL tal cual», perdiste. Perdiste por goleada si te pones a imitarlo en el Monad ST o IO con referencias mutables -- eso no es programación funcional.

---

Los algoritmos como KMP (y muchos otros de programación dinámica) se puede nescribir *iguales o más eficientes* que en el imperativo con arreglos, porque puedes usar «arreglos perezosos» que sólo llenan lo que realmente hace falta llenar. Pero para eso, tienes que repensar el algoritmo como flujo de datos y no como transformación de estado mutable. Eso se domina con la práctica.

---

Si miras [1] verás «Array» en el código, pero eso no es como los Array de los lenguajes imperativos. En el curso CI4251 dedico un par de clases a hablar del tema, al menos para explorar la superficie, con resultados sorprendentes para los que están transformando su mentalidad de imperativa a declarativa.

---

Así mismo, es necesario emplear estructuras de datos diferentes que favorezcan la reutilización parcial de estructuras, para evitar copias y trabajo de más. Hay una rama completa de trabajo sobre Estructuras de Datos para lenguajes funcionales, que comenzó con el trabajo de Steve Okasaki y que se mantiene activo.

---

[1] https://hackage.haskell.org/package/KMP-0.1.0.2/docs/src/Data-Algorithms-KMP.html

View more