EM Hernández-Novich

Los protocolos de Elixir son una imitación (con otro nombre) del despacho dinámico de lenguajes Orientados Objetos, injertado en las llamadas de funciones.

---

El mecanismo de protocolos de Elixir, en efecto, termina haciendo despacho dinámico: el programa tiene que correr y al llegar al punto de la llamada *decidir* a cuál función particular llamar. Lo hace para todos los casos. Sólo para que quede muy claro: eso es *lento* y puede causar errores a tiempo de ejecución en determinadas circunstancias que no son inusuales en programas concurrentes. Por otro lado, tiene que ver con el hecho de correr sobre una máquina virtual (BEAM) cuya noción de tipos requiere verificación dinámica.

---

No lo pueden hacer mejor, porque no están sobre una plataforma que les permita hacerlo mejor. Están tratando de emular una operación que viene de Orientación a Objetos, sobre una máquina virtual dinámica.

---

El enfoque puramente funcional con un sistema de tipos completo es utilizar Polimorfismo Paramétrico (como en Haskell), que permite tomar esa decisión a tiempo de compilación para todos los casos en los que se pueda, generando código de *máquina* que llame directamente a la rutina que hace falta.

---

El sistema de tipos de Elixir es dinámico y un poco mejor que el de Erlang, pero está muy lejos de (y no puede avanzar hasta) el de Haskell por la plataforma subyacente. Es mejor que Erlang y mejor que usar cualquiera de los lenguajes mixtos «populares», pero hasta ahí.

---

Es similar a la relación entre Scala y Java: la mayor limitación es la JVM, una máquina de pila con muy pocas oportunidades de optimización y la obligación de incluir verificaciones dinámicas..

View more

Los «routers» y «access points» necesitan software para funcionar. Cada fabricante provee uno diferente (el «firmware»). Todos los routers económicos traen, casi sin excepción, un firmware precioso pero con funcionalidad mediocre o malo, y además no los actualizan con suficiente eficiencia. Eso hace que la experiencia del usuario final sea regular a mala. Y te hacen comprar uno nuevo porque «nueva versión optimizada para redes sociales».

---

DD-WRT es un firmware basado en Linux, que funciona en la mayoría de los routers, es mucho más versátil, consume menos recursos, y se actualiza con regularidad.

---

Solamente por el hecho de que DD-WRT incluye un caching resolver, ya te ahorras ancho de banda por no tener que hacer consultas DNS redundantes.

---

Encima, los firmware comerciales intencionalmente reducen la potencia de las antenas. Con DD-WRT puedes aumentarla al máximo. Uno de mis routers está en el 7 piso y tengo 60% de señal en el jardín de planta baja. El otro router tiene diez años, y es igual de rápido que el primer día.

---

Aprovechar al máximo el hardware, sólo con Software Libre.

View more

Aprendí con dos libros: «Basic Category Theory for Computer Scientists», Benjamin Pierce; y «Categories and Computer Science», R.F.C. Walters.

---

Me parecieron suficientes, tomando en cuenta que tuve la ventaja de haber estudiado Conexiones de Galois antes de enfrentarme a Teoría de Categorías; no son un requisito, pero tienen parecidos que me ayudaron a ir más rápido.

---

De todas formas, esos libros son perfectamente accesibles si has estudiado Matemática Discreta y Lógica, aunque tendrás que ir despacio porque son densos: pocas palabras que requiren mucho razonamiento.

---

Dicen que «Category Theory» de Awodey es muy bueno, pero no lo he revisado. No enseño ese tópico así que no ando averigüando qué libro es más práctico.

---

Si preguntas por la base matemática de Monads, eventualmente lo estudiarás en Teoría de Categorías. Si preguntas por la aplicación práctica de Monads en Haskell, hasta ahora mi técnica pedgagógica es aprender y dominar Monoid, luego Functor, luego Applicative, y finalmente Monad. «All about Monads» solía ser bastante práctico, antes que Applicative estuviera entre Functor y Monad; «A Fistful of Monads» en Learn You a Haskell también ayuda. Es un tópico amplio que no se aprende en poco tiempo y requiere practicar bastante. Toma en cuenta que *un* Monad, aislado, es relativamente útil; una combinación de transformadores de Monads son mucho más útiles, pero para eso tienes que comprender todos los Monad individuales. Entonces, al principio parece que aprendes cosas sueltas que no son muy útiles, hasta que aprendes a usar transformadores. Y en ese momento te das cuenta que necesitas MonadPlus y MonadFail; y luego aparecen MonadFix y Comonad.

---

Tienes que estudiarlos todos.

View more

C es muy cercano a la máquina, con un sistema de tipos precario, para programar cosas con un nivel muy refinado de control, tanto en la utilización de memoria, como en la eficiencia de ejcución. Tienes que haber aprendido a manejar memoria explícitamente con disciplina, y estar preparado para las sutiles diferencias de implantación de cada compilador de C en cada plataforma. Es el lenguaje típico para escribir kernels, controladores de dispositivo, y en el cual están escritas las más importantes piezas de software de plataforma sin las cuales NADIE podría hacer nada.

---

C++ nació como un «C con objetos» en cuanto imitó la sintaxis de C, conservó la mayoría de las cosas habituales de C, y la enriqueció con los conceptos de clases y herencia (¡múltiple!), además de incluir despacho dinámico a juicio del programador. A lo largo del tiempo, el lenguaje ha incorporado montones de extensiones y «casos especiales» para cubrir cosas disponibles en otros lenguajes orientados a objetos. Desafortunadamente, una de las cosas que copió de C es el «modelo de valor» y el manejo manual de memoria, lo cual lo hace extremadamente confuso para programadores que no han estudiado el tópico o que han trabajado con lenguajes orientados a objetos mejor diseñados. Muchas aplicaciones complejas están escritas en C++, sin embargo es un lenguaje impráctico para cosas de bajo nivel (ni kernel, ni controladores de dispositivos) y hay muchas herramientas de infraestructura que diseñadas orientada a objeto son demasiado lentas para uso en masa. Tienes otras dificultades horribles derivadas de su manera de representar internamente los valores para compilación separada, y el despacho dinámico es notablemente lento para aplicaciones de alto desempeño. No es imposible, pero cuesta mucho hacerlas rápidas, cuando se puede..

---

Anécdota: BIND (el DNS «de facto») se escribió en C, el mismo equipo de personal altamente competente en ambos lenguajes quiso re-escribirlo en C++: fue un fracaso en desempeño y en otros aspectos de integración, en buena medida por usar C++.

---

C# es la respuesta de Microsoft a C++ y Java. Es un lenguaje de plataforma, orientado a objetos, razonablemente estandarizado, que tiene varias implantaciones, comerciales y libres. Fue influenciado por Java, así que ninguno de los dos es particularmente innovador ni cambia treinta años de dificultades en el ámbito orientado a objetos. Si bien hace una década que la evolución de C# se diferenció de Java, en realidad han implantado las mismas ideas (por ejemplo, «generics») de maneras diferentes pero igualmente ineficientes.

---

Tanto C++ como C# (y Java) no han querido «quedarse atrás» con la moda de la programación funcional, y han incorporado construcciones adaptadas al modelo imperativo. Tienen clausuras, tipos anónimos, entre otras cosas, pero inferiores a las de un lenguaje funcional verdadero.

---

C y LISP son necesidades para el programador. A mi, después de aprender C++, Java y C# no me enseñaron nada nuevo.

View more

No escribo juegos, así que mi experticia es limitada en cuanto al status quo. Puedo hacer una lista de las destrezas no artísticas y las herramientas que harían falta. En principio:

---

- HOpenGL es el API de OpenGL en Haskell. Si usas OpenGL en C/C++, no solamente te va a resultar familiar, sino que amarás el hecho de no tener que escribir glBegin() ni glEnd() nunca más o que las operaciones gráficas sean valores de primera clase y se puedan componer.

---

- OpenAL es un API para controlar dispositivos de audio y emitir a través de ellos los sonidos necesarios (waveforms o MIDI), incluyendo ubicación espacial, efecto Doppler, etc.

---

- Waveforms are waveforms are waveforms y no hay mucho que hacer allí, pero si trabajas música (una partitura digital) puedes usar Euterpea para manipularlas como un tipo de dato algebraico.

---

- Necesitas dominar Monads y Monad Transformers. Ambas librerías lo requieren y el juego necesariamente va a trabajar con un Monad compuesto.

---

- Seguramente tendrás que aprender programación concurrente en Haskell, pero usando Memoria Transaccional (STM) y Canales Transaccionales, para olvidarte de deadlocks, starvation y condiciones de carrera.

Para este punto, puedes hacer cosas «pico y pala». Como siempre, es mejor tener una librería de un nivel un poco más alto. En este sentido sé que existen:

---

- hsSDL (y otras más, no sé cuál será la «preferida»), que permite aprovechar SDL. SDL encapsula gráficos, audio, entrada/salida, en un sólo API.

---

- Yampa, que permite aprovechar Programación Funcional Reactiva (de hecho, fue el primer ejemplo de FRP aplicada, del cual todo el mundo ha copiado ideas). Aprender a usar Yampa tiene como hito previo aprender Arrow, una generalización de Monad.

---

- Estructuras de datos especializadas para particionamiento eficiente del espacio, tanto para determinar presencia, como para transformaciones. No basta con tomar, digamos, kd-trees e «imitarlos imperativamente». Seguramente hay librerías disponibles para eso.

---

Si alguien que lee piensa «pero yo uso el software X que hace todo eso», estoy seguro que es así y por eso suelo decirle a la gente que no tienes que estudiar Computación para hacer juegos, sino guionista, artista y camarógrafo. Si estudias Computación sabes cómo funciona una de esas herramientas, e inclusive cómo hacerlas (que fue lo que yo estudié -- nada de Maya ni Blender), para que otros disfruten expresándose.

---

Piensa si lo que quieres es hacer juegos o hacer una herramienta para hacer juegos. Son dos niveles diferentes de discurso, y dos conjuntos diferentes de habilidades. Ambas necesarias en el mundo.

---

Comienza por leer

---

https://wiki.haskell.org/Game_Development

---

y sigue desde allí.

---

Si es provechoso o no, requiere contemplar tantas dimensiones que no puedo opinar. Busca en Youtube las opiniones de Carmack al respecto.

---

Quizás el @chiguire en Twitter tenga más cosas que decir, y estoy seguro que estará dispuesto a orientarte

View more

Por favor escribe el apellido Turing en mayúsculas, siempre.

---

Tener «un lenguaje L1 Turing completo» es equivalente a decir que tengo una definición para ese lenguaje — un papel. Hace falta tener una implantación concreta de ese lenguaje (interpretada o compilada) y con ella puedo implantar cualquier otro lenguaje.

---

C11 es el lenguaje y GNU GCC es una implantación. Con GNU CC (el compilador) puedo escribir un interpretador o un compilador para cualquier otro lenguaje, Turing completo (Pascal, C, C++) y, por supuesto, inferiores (lenguajes que no sirven para escribir programas, como HTML o CSS).

---

Ahora bien, hay lenguajes para los cuales sólo se puede escribir un interpretador, pues tienen construcciones que no pueden resolverse estáticamente. Por ejemplo, LISP y Perl tienen evaluación dinámica de expresiones: para esos lenguajes no puedo escribir un compilador en el sentido que sólo podría compilar las partes estáticas del lenguaje, cosa que para esos lenguajes sería una pérdida de flexibilidad. El interpretador puede ser puro o basado en alguna máquina virtual, pero sigue siendo un interpretador.

View more

No.

---

No programo «para terceros», no programo «aplicaciones tradicionales» de cara a un usuario «final», y la gente que revisa o aprovecha lo que programo, usualmente soy yo o es alguien técnico. Es un lujo.

---

Test Driven Design/Development salpicado de «lo más conveniente» según el problema, cuando es OOP. con una gran dosis de separación entre identidad y comportamientos (para que sea no-jerárquica y no perder tiempo). También uso Test Driven Design/Development para procedimientos almacenados imperativos, aunque la realidad es que casi siempre los efectos de borde los efectúa SQL.

---

Type Driven Design, Extreme Currying Composition with Higher Order, Context-Driven Application, Transformadores, y Domain Specific Models & Languages para FP. Sólo con tipos estáticos, porque cualquier otra cosa sería incivilizada.

---

Memoria Transaccional o Modelo de Actor para concurrencia y paralelismo, siempre en lenguajes funcionales — la vida es muy corta para usar hilos tradicionales.

---

Algebra relacional, mucha práctica y mucho profiling, para definir modelos relacionales y objeto-relacionales.

View more