EM Hernández-Novich

Fue un lenguaje diseñado para enseñar a programar, inventó el concepto de «máquina virtual» (aunque no se llamaba así), y se aprovechó de eso para ser portátil: todo el mundo podía tener Pascal relativamente rápido. Además, el lenguaje salió más o menos al mismo tiempo que un libro de algoritmos y técnicas básicas de programación, del mismo autor del lenguaje, Eso fue un «primera vez» que lo hizo popular -- otros lenguajes se han hecho «populares» copiando la idea.

---

Incluye muchas metidas de pata en diseño de lenguajes, que parecían una buena idea hasta que los llevaron a la práctica: el tipo de dato conjunto, procedimientos anidados con alcance estático, arreglos pasados por valor con dimensiones variables...

---

Nadie debería estar usando Pascal, ni Modula-2, ni Oberon, en ningún tipo de sistema de producción. Sólo tienen utilidad como elemento didáctico para ilustrar esos conceptos, no porque vayan a aparecer en nuevos lenguajes, sino precisamente para que no venga ningún «creativo» a reinventarlos.

View more

Más conocimientos, sobre todo prácticos.

---

«Programming Language Pragmatics» es una descripción general, basada en ejemplos, de los conceptos de diseño de lenguajes de programación y una aproximación muy superficial a cómo implantarlos. Con «superficial» quiero decir que está descrito con un nivel de abstracción alto (intencionalmente). Es un libro muy denso, y usualmente requiere varias lecturas para realmente aprehender lo que se explica.

---

«Concept, Techniqus, and Models of Computer Programming» te hace recorrer de manera práctica todos los conceptos de estilo de programación usando un sólo lenguaje (Mozart). Ese recorrido se hace con ejemplos prácticos, y demuestra que en un sólo lenguaje podrías tener todos los estilos y pasar de uno a otro. Adicionalmente, te hace pensar en tópicos de correctitud, eficiencia, implantación de lenguajes, y comparar soluciones para el mismo problema usando diferentes técnicas.

---

Por ejemplo, la sección en «Declarative Programming» es particularmente buena para esa gente que hace «programación funcional» en lenguajes que no son funcionales y que quiere hacer «programación reactiva» en lenguajes que no son ni funcionales, ni favorecen la construcción data-flow sintácticamente.

---

Un par de capítulos interesantes son «Declarative Concurrency» y «Message-Passing Concurrency» nuevamente para abrir los ojos a los que siguen usando hilos en pleno siglo XXI.

---

El capítulo sobre semántica me aburrió -- probablemente porque cuando llegué a este libro, ya había estudiado semántica, así que el discurso del libro no me atrajo.

---

Lo único que no enseña ninguno de los dos es el funcionamiento de un sistema de tipos fuertes -- eso no limita en nada lo que puedes aprender de ambos libros. El segundo libro está pensado para leerse mientras pruebas todo en Mozart -- desafortunadamente, Mozart sólo funciona en plataformas de 32-bits (y leer el libro te hace entender por qué) así que puede ser complicado de hacer trabajar.

---

El lenguaje que usa el libro, Mozart, es un perfecto ejemplo de un lenguaje que hace prácticamente todo (excepto tipos fuertes), que es una maravilla para enseñar cualquier concepto de lenguajes de programación, pero que sería increíblemente impráctico para usar en la industria -- si lees el libro y lo procesas bien, entenderás por qué.

View more

Cualquier edición de texto la hago con VIM: archivos de configuración, escribir programas, escribir documentos. En el caso de aplicaciones web que tienen campos de texto libre (TEXTAREA), tengo un plugin para que se abra VIM, edito allí, y cuando salvo se copian los contenidos al campo de texto. Lo único que no escribo con VIM es el correo electrónico por Razones Histéricas.

---

Para mis «notas estructuradas» que viven en el tiempo («chuletas», notas sobre clientes, notas sobre instalaciones, etc.) empleo un compilador de wikis que guarda los documentos en Git. Entonces edito con VIM usando markdown, salvo, commit/push, y así tengo copias en los lugares que me conviene, en particular se genera un sitio web con las notas, que incluye buscador, y al cual accedo con usuario y clave si es que necesito leerlo. No me interesa cambiar las notas remotamente, y cuando tengo que tomar nota de algo, me envío un correo al sistema de seguimiento.

---

Nunca usaría EverNote ni similares por dos razones: la primera es de privacidad, pues no controlo los datos enteramente; la segunda es de comodidad, pues no tengo necesidad de andar desesperadamente tomando notas en todos lados, mucho menos con el teléfono que es bastante odioso para eso.

---

Soy un flojo muy organizado.

View more

Para los que sabemos usar vi (del cual vim es su encarnación más moderna), es sumamente cómodo porque no tenemos que perder tiempo moviendo la mano o los dedos hacia el ratón. Para los que no saben usar vi «sin las flechas», es una oportunidad de practicar.

---

Sin embargo, no es una idea original, ni moderna. Los primeros juegos para Unix (de los años 70 y 80, antes del PC) utilizaban esas combinaciones de teclas con el doble propósito de facilitar su uso a usuarios de vi, y acostumbrar su uso a los usuarios de vi. Juegos como Rogue, Hack, NetHack, wumpus, snake, robots, y otros tantos, usan los movimientos de vi. En particular, usé una versión de Tetris que funcionaba con las teclas de vi en lugar de las flechas y se me hacía mucho más fácil -- es una cuestión de costumbre y ahorro de movimientos.

---

apt install bsdgames

View more

Sé lo suficiente del tema como para proteger mis máquinas y recorrer un camino de operaciones minimizando los riesgos. Aprendí estudiando libros de texto y manuales de las herramientas, simulando escenarios, y practicando con mi propia red. Colaboré con colegas para hacerlo asimétrico, y eventualmente me aburrió.

---

Tengo suficientes máquinas propias para probar cosas interesantes, como para ponerme a investigar máquinas ajenas. Además, un hacker no rompe, destruye, ni abusa; es desafortunado que los medios hayan logrado darle una connotación peyorativa al término que define a las personas que son extremadamente buenas creando, construyendo y resolviendo problemas de maneras creativas.

---

Cuando practicaba con colegas, en efecto nos pedíamos permiso y anunciábamos el inicio y el final, simplemente para que el otro pudiera comprobar, de su lado, que sus medidas de detección y contención hacían lo que tenían que hacer.

View more

Las preguntas apropiadas para el problema para el cual se contrata al programador. Lo más reciente que me pidieron fue diseñar una evaluación para un equipo (que no es el mío, porque yo no tengo equipo) que requiere mucha habilidad demostrable, en varios tópicos de desarrollo.

---

Por eso diseñé un problema cuyo enunciado tenía errores de redacción, ambigüedades, y requerimientos «abiertos», todo ésto para saber si el candidato sabe leer, de diseño, es capaz de preguntar cuando no sabe, y proponer con inteligencia. El ejercicio concreto requería resolver dos problemas de procesamiento de datos, uno de los cuales «parece» un subconjunto del otro, pero no sólo no lo es, sino que cualquiera que lo resolviera así demostraba no tener preparación adecuada. Finalmente, el problema requería justificar técnicamente la selección de un parser, de un modelo de datos, de los cuatro algoritmos, escribir una parte con el lenguaje favorito del candidato, y otra con un lenguaje para procedimientos almacenados (no me importa si lo conocen o no -- es *su* problema aprenderlo). De paso, el problema termina con «¿cómo comprueba que su solución funciona de extremo a extremo?», y la respuesta esperada es una batería de pruebas.

---

En este caso, el candidato tenía que saber de algoritmos, de reconocedores, de estructuras de datos recursivas, del modelo relacional, de lenguajes para procedimientos almacenados, y desacoplamiento (porque TODO eso es lo que pedía el problema).

---

El candidato tenía tres días para resolver el problema, podía pedir todas las aclaratorias que quisiera a través de un intermediario «no técnico» (intencional, a ver si sabe leer y escribir correctamente), y enviar su solución como una «distribución de software» en el lenguaje que escogió.

---

Fue fácil filtrar las mentes apuradas sin destino y con más hype que type, de todas las edades y sin presionarlos delante de una pizarra. El equipo en cuestión no puede darse el lujo de enseñar buenas prácticas y preparar en temas teóricos, de allí lo estricto y artero de la evaluación.

View more

Mi experiencia con portátiles Thinkpad Serie T y X:

---

* Cuando llegue al 35%, ponla a cargar y continúa trabajando.

---

* Cuando llegue a 100%, desconecta el cargador.. En el caso de las Thinkpad, el docking station desactiva el cargador automáticamente cuando la batería llega a 100%, así que es una inversión inteligente para cuando vas a trabajar «seguido» en un mismo sitio.

---

* Si se descarga por debajo del 10%, lo mejor es cargarla apagada o suspendida hasta que tenga más del 50% antes de usarla de nuevo.

---

* Cuando se esté cargando, procura que esté en un lugar fresco. Es decir, no es buena idea ponerla a cargar encima de las piernas, de un cojín, de un mantel o de cualquier material que dificulte disipar calor.

---

Pero las baterías pierden sus propiedades con el uso, así que la vida no es indefinida. Aprende a usar las herramientas de tu sistema operativo para determinar si la batería ha perdido capacidad -- cuando pierde la mitad de su capacidad, corres el riesgo de que al cargarla, el calor adicional haga que entre en cortocircuito, así que es mejor comprar una nueva. De paso, cuando pierden el 25-30% de su capacidad nominal, nunca van a mostrarse como «100% cargada», de modo que cárgala hasta el 95-97% antes de desconectar el cargador.

View more

La primera prueba es usar el sistema de tipos del lenguaje para que detecte la mayoría de los errores derivados de inconsistencias. En un lenguaje con un sistema de tipos como el de Haskell, eso evita tener que escribir muchas pruebas porque el compilador ya garantizó muchas cosas antes de correr el programa. Mientras más estricto es el sistema de tipos, menos pruebas tienes que escribir.

---

Los tipos son «proposiciones», cada programa es una «demostración», y el compilador verifica que todas las proposiciones sean «teoremas». Un sistema de tipos débiles, sólo puede expresar teoremas triviales, y por eso al programador se le «escapan» muchos errores por tener poca expresividad. En lenguajes como Idris o Agda, las posibilidades son aún mayores (y uno escribe menos pruebas).

---

En lenguajes funcionales verdaderos, que separan el cómputo puro del cómputo con efectos de borde, empleo pruebas basadas en propiedades como las que se escriben con QuickCheck. Uno escribe propiedades, e.g. reverse x == reverse (reverse x), y la librería genera una cantidad arbitraria de pruebas, exhibiendo contraejemplos si los encuentra. Erlang tiene una variante de QuickCheck muy buena. Otros lenguajes imitan lo que pueden (porque no tienen separación de I/O).

---

Para este punto, sólo queda escribir pruebas unitarias para aquellas cosas que no puedan expresarse como propiedades. Ahora bien, la cantidad de pruebas que hay que escribir es muchísimo menor que si se usa un lenguaje dinámico con un sistema de tipos débil, y sin separación de I/O, así que el aburrimiento es menor.

---

Cuando trabajo con Perl en lugar de Haskell, la librería Test::More y todas las Test::* permiten escribir pruebas unitarias para probar lo que se espera del código «normal», para simular excepciones y verificar que se manejan, para probar el comportamiento de las aplicaciones (simulando un navegador y haciendo clicks), simular la existencia de bases de datos/sockets/archivos, simular que se llenó el disco, simular que no hay red, simular que no hay base de datos -- porque Uds. prueban esas cosas, ¿no?. La herramienta `prove` ejecuta las pruebas y muestra los resultados en formato TAP -- de allí a tener un reporte de pruebas exitosas y fallidas, combinado con un reporte de cobertura, hay un par de liberías en Perl para hacerlo.

---

Es más, uno de los servicios que ofrezco es escribir pruebas de infraestructura para terceros: ¿puedes recibir correo? ¿tu página funciona? ¿la aplicación está activa? Y para eso uso Perl -- no hay lenguaje que tenga más ni mejores librerías y programas de soporte para probar cosas, por ahora.

View more

Hacer ejercicio, comer bien, evitar movimientos innecesarios de las manos (esto es, evitar el uso del ratón), usar múltiples pantallas con tipos de letra grandes, apreciar el mundo alrededor, tener buena postura, no confundir el hambre con sed, no confundir el aburrimiento con hambre. En general, no tratar tu cuerpo como un relleno sanitario.

---

Todas son cosas para las cuales basta aceptar que dependen de ti mismo, y que si no dedicas tiempo para mantenerlas, reducirá el disfrute de tu vida y tu profesión.

---

Los defectos visuales propios (miopía, hipermetropía, astigmatismo) deben ser corregidos lo antes posible y contrarrestados no sólo con los lentes correctivos, sino con hábitos adecuados. Hoy en día hay mucha gente miope, porque nunca usan la vista para mirar lejos (literalmente) -- entonces, ponte tus lentes y sal a mirar el paisaje, caminando.

View more

Determinar si una línea de programa es «peligrosa», para cualquier definición de «peligro» suficientemente general, es no-decidible. Por tanto, es imposible construir un lenguaje que diga si cualquier programa es «peligroso» o no.

---

Si restringes el contexto a construcciones específicas en programas, existen herramientas que te advierten de «cosas potencialmente peligrosas», pero no pueden garantizar que lo que es estás haciendo está mal o no.

---

Por ejemplo, hay herramientas que revisan tu código en C, y si encuentran llamadas a gets() se quejan de que eres un imbécil que no debería usarla -- pero la herramienta no «detectó» que gets() era peligroso, sino que alguien incorporó esa regla en la herramienta.

---

Otro ejemplo es el modo «taint» en Perl. Cuando un programa Perl ejecuta en modo «taint», cualquier dato que venga «del exterior», se considera «peligroso» y sólo puede ser usado si ha sido «transformado». Esto sirve, por ejemplo, para que al recibir datos desde el teclado, desde un archivo, o desde el ambiente, el programa esté obligado a hacerle alguna «transformación» (típicamente, aplicarle una expresión regular). Naturalmente, es *imposible* determinar si en efecto se le hizo una transformación útil, mucho menos determinar si la transformació en efecto «quitó el peligro». El modo «taint» para lo único que sirve es para que el lenguaje te recuerde que no validaste los datos del usuario y que podrían ser peligrosos.

---

Los compiladores con buenos sistemas de tipos pueden protegerte de muchos problemas de seguridad a tiempo de compilación, detectando usos inconsistentes o el olvido al verificar casos, y en ese sentido usar un lenguaje compilado con un sistema de tipos estático estricto es muy superior a usar cualquier lenguaje con tipos verificados dinámicamente.

---

Y ningún lenguaje puede proteger al pobre que usa String para modelar todo, confía en reglas automáticas de conversión o, peor aún, escribe «reconocedores» a punta de expresiones regulares y audacia.

View more

Porque es controlado por una corporación, y no por los usuarios. Porque es un lenguaje cuyo diseño obliga a escribir mucho para lograr poco, pero causa la impresión de que «se trabajó». Porque es lento en ejecución y oneroso en recursos de memoria, como consecuencia de una decisión de diseño de bajo nivel (usar una máquina de pila) que al final no fue relevante. Porque la mezcla de modelo de valor y de referencia es artificial y conduce a muchas confusiones y comportamientos que son obvios para el que sabe (de lenguajes) pero extraños para el programador. Porque mantiene el estilo Orientado a Objetos Jerárquicos que ya es cosa del siglo pasado, y no pueden incorporarle Orientación a Objetos No-Jerárquica (es decir, son obsoletos por diseño).

---

Por eso y muchas cosas más, nunca perdí tiempo con Java.

View more

No me gusta y me parece que está sobrevalorada por los interesados.

---

En mi experiencia, su aplicación contribuye a que los muy buenos se vayan o dejen de poner empeño, los malos se vuelvan regulares, y los regulares se mantengan regulares. Intencionalmente logra que se pierda la motivación a crear y experimentar, porque no se puede «arriesgar» a no cumplir con la «emergencia de la semana». Además, es imposible forzar la calidad del producto — «la genialidad no se produce en líneas de ensamblaje» dijo el gran filósofo J. T. Kirk

---

La ingeniería deben hacerla los ingenieros, no la gerencia, y mucho menos «el negocio». Y si la van a hacer los ingenieros, es *necesario* y *saludable* que haya una diferencia *marcada*, entre los que tienen experiencia y visión para atacar los problemas complejos de manera creativa, y los que aún están aprendiendo a resolver problemas simples. Lo que siempre veo es que la «miseria del desarrollo» se reparte por igual entre todos, haciendo que los senior no tengan motivación para crear cosas nuevas, y los junior se sientan «a la altura» cuando en realidad no están avanzando.

---

En el fondo se trata de un mecanismo de gerencia supervisoria agresiva, generalmente no técnica, sobre un equipo que tiene poca autonomía, limitado crecimiento profesional (como no sea en el círculo vicioso del método), y que fomenta la «nivelación hacia abajo» de la calidad, de modo que sólo puede mejorar la productividad aumentando la mano de obra o «importando» recursos «mejores» que el promedio. Cualquier similitud con estados de «igualdad social» fallidos no es coincidencia.

---

Es cierto que hay mucha gente a la cual (aparentemente) le vá muy bien usando esas técnicas. Personalmente no podría estar en un equipo así, ni produciendo, ni dirigiendo -- creo que ni siquiera como «coach» porque me daría mucha tristeza la poca libertad de acción.. No creo en ingeniería por emergencia, ni en desarrolladores que «no saben lo que hacen». Además, ningún gerente va a decir que la estrategia que escogió no le funciona bien -- siempre dirá que los recursos no están a la altura (eso le incluye, pero hey, es gerente).

---

Creo que es exactamente igual de nefasto que el método tradicional cascada.

---

Prefiero XP, TDD (Test-Driven o Type-Driven) en equipos de 3-4 personas altamente competentes que no necesitan supervisión y tampoco están bajo presión impuesta, sino asumida como producto de un intervalo consciente de diseño.

View more