Informática, desarrollo, sistemas...

En octubre de 2014, tuve la oportunidad de hablar de Elixir en una reunión Erlunge en Madrid. Las diapositivas están  aquí Son muy pesadas y cargarlas todas toma su tiempo. El código fuente de las mismas…  aquí La experiencia fue fantástica, pero quise abarcar demasiado. La reunión fue muy larga a pesar de tratar los temas a gran velocidad. Quise aprovechar la ocasión para tratar temas básicos y otros nada básicos que son realmente importantes para entender la aportación que puede hacer Elixir al ecosistema Erlang. En definitiva, demasiado alcance y contenido. No obstante, reitero que la experiencia fue sensacional.

He escrito mis primeros dos programas  cliente web . El primer programa, una prueba de concepto sencilla…  link El segundo, consiste en un puzle con la característica fundamental de que se puede configurar con tres topologías…  link Se trataba de crear aplicaciones interactivas 100% cliente (ejecución en el navegador). Son pruebas de concepto escritas con el lenguaje  Dart . Una vez superado este punto, ya es posible crear interfaes para aplicaciones y servicios, que seguramente consistirán en la entrega del programa  cliente web  (página  html ), y esta realizará peticiones  http  y/o  REST , recibiendo respuestas casi seguro  JSON . Además de utilizar en algunos casos  websockets . Investigo con frecuencia nuevos lenguajes de programación. Muchos de estos, por lo nuevo que son o su orientación, no disponen de  bindigns  con  toolkits  gráficos tipo  Qt ,  WxWidgets ,...

Hoy un compañero de trabajo me preguntó ¿qué opinas de los threads? Lo he explicado muchas veces, pero no tengo inconveniente en repetirlo y tratar de ser lo más claro posible. Así que le contesté lo siguiente... To thread or not to thread… And the winner is… NO. Pero sólo para empezar. “NO” es una palabrita muy suave, muy flojita, breve, pequeña, insignificante en ocasiones. La respuesta se merece un poco más de atención, un poco más de elocuencia y contundencia que un simple, raquítico y triste “NO”. Trataré de completar un poco la respuesta. Este NO, no significa un rechazo a la concurrencia o al paralelismo (está de moda decir que concurrencia no es paralelismo, pero creo que con concurrencia nos entenderemos lo suficiente). Espero poder dejar eso claro en la siguiente explicación. En el origen de los tiempos, los sistemas ejecutaban una cosa, y bastante merito tenían (algunos). Hacer varias cosas simultáneamente fue una gran idea y una gran neces...

Para ser  telnet friendly  recibiremos y enviaremos texto separado por retornos de carro. El programa se limitará a responder lo mismo que reciba. Para trocear los mensajes en líneas separadas por retorno de carro, leeremos byte a byte y los meteremos en un buffer. Sí, hay otra forma de hacerlo más sencillo, pero hacerlo a mano es más didáctico. Al final también indicaremos la forma  erlangish ¿Es mejor que el buffer sea un  binary  o una  lista ? iex> {microsecs, :ok} = :timer.tc fn -> (1..1000 |> Enum.each fn _ -> (1..1000 |> (Enum.reduce [], &( [rem(&1, 10)+48|&2])) |> Enum.reverse |> to_string) end) end; IO.puts microsecs/1000000.0 3.493395 iex> {microsecs, :ok} = :timer.tc fn->(1..1000 |> Enum.each fn _ -> (1..1000 |> Enum.reduce "", &(&2 <> (<<rem(&1, 10)+48>>))) end) end; IO.puts microsecs/1000000.0 7.098454 La respuesta es una lista. Cre...