@iamemhn

EM Hernández-Novich

Ask @iamemhn

Sort by:

LatestTop

Previous

Cuál combinación de [paradigma de programación + lenguaje de programación + librerías + prácticas] utilizarías si tuvieras que desarrollar un producto web cuya lógica (magia que no quieres que decifren) debe estar en un servidor local del cliente final?

Haskell con Yesod (aplicación web completa) o Servant (servicios RESTful). Como es un lenguaje compilado, vas a entregar ejecutables binarios. El servidor correría Debian GNU/Linux, la aplicación estaría empaquetada correctamente, y se desplegaría utilizando algún administrador de configuraciones (cfengine o puppet, porque propellor todavía está comenzando). Es decir, nunca compilaría en el servidor de producción porque es una pésima práctica «arreglar en producción» — se le entrega un .deb con ejecutables binarios y nada más.
Un contrato draconiano hecho por un buen abogado nunca está de más.

Por qué hay tanta ahínco en aprender a programar en x lenguaje y no en enseñar métodos formales?

Por la misma razón que son más populares las películas que los libros.
Liked by: Izrra Lugo™

Qué tan cercanos estamos de lograr superinteligencia artificial? Corremos el riesgo de ser descartados por un sistema así?

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

Related users

¿Por casualidad no eres familia lejana de Stefany la medallista de bronce de las Olimpiadas? .Creeo que es de tu tierra natal.

No. Tampoco.

¿Sigues la informaciones que salen de conferencias como DEFCON?

No es de mi interés entrar en esos detalles. Es demasiada información, que rara vez me resulta práctica.
Estoy suscrito a las listas de seguridad que se enfocan en aquellas fallas que afectan el software que empleo. Si una falla es llamativa, puede que la estudie, sobre todo si se trata de una falla responsabilidad de un lenguaje de programación mal implantado o mal utilizado.

En la pregunta sobre Scala tu dices - "Python no cuenta, porque tiene más verrugas que lunares." - . En general, ¿cuáll es el problema con Python?, ¿por qué no te agrada?

- Las reglas de alcance con creación automática de variables «sólo porque se usan» facilitan bugs oscuros de difícil detección. «Bueno, pero puedes usar esta otra herramienta que chequea eso» es una tontería — ¿por qué necesito una herramienta adicional si eso es **responsabilidad** del front-end del compilador?
Usar espacios en blanco para estructurar el código imperativo secuencial, como en Python o Ruby, no es ni simpático ni una buena idea, como cualquier estudiante que ha tratado de escribir un interpretador o compilador puede comentarte.
- Librería «estándar» es insuficiente cuando la comparas con cualquier otro lenguaje dinámico. Tener que comenzar a instalar librerías adicionales porque la estándar no es suficiente, es una demora para el desarrollo. El argumento «es que es muy díficil escoger cuál librería incluir como estándar» habla mal de la coordinación de la comunidad para organizar el ecosistema.
- Vas a encontrar un montón de «perlitas» que demuestran las inconsistencias en el sistema de tipos derivadas de hacer conversión implícita (*coercion* en inglés). Ese montón de «perlitas» no son «ja, ja, qué loco», sino evidencia de que su sistema de tipos dinámico es frágil y aumenta la cantidad de cosas que el programador tiene que conocer para no cometer errores.
Es cierto que un sistema de tipos dinámico tiene que hacer muchas cosas por el programador, pero tiene que hacerlas de manera **consistente**. JavaScript y Python tienen la mayor colección de cosas insólitas que ocurren al combinar inocentemente operadores y tipos de datos en formas razonables. Eso no es ayudar al programador, y tampoco favorece el aprendizaje.
El argumento «bueno, pero no hagas esas cosas» es equivalente a «si no te gustan esas palabras del diccionario, no las leas». Si están allí, es para usarlas, y si producen resultados absurdos, la herramienta incluye el absurdo.
- El trastorno neurótico de múltiple personalidad de las listas.
- Concurrencia mal construida. Comparado con otros lenguajes imperativos de tipos dinámicos, luce mal. Comparado con lenguajes de programación de sistemas estáticos, luce lamentable. Su modelo de hilos es lento (y no puede ser rápido debido a la máquina virtual), el soporte para co-rutinas es externo, y el soporte para operaciones asíncronas es demasiado simple (y lento).
El argumento «bueno, pero haces fork y ya» es equivalente a «bueno, pero cómprale un autobús a cada miembro de la familia».
Python 3.5 promete resolver el problema. Lo cual me lleva a:
- In Soviet Python, you are not backward compatible. Ni un poquito.
- Sistema de objetos y habilidades de reflexión e introspección primitivos y antiguos, sin composición horizontal.
- No tiene optimización de recursión de cola. Eso afecta la recursión explícita bien escrita, y la implícita del lenguaje en su parte «funcional».
No lo usaría profesionalmente, ni para enseñar a programar. «A mi me parece fino y sirve en lo que hago» — Carry on and enjoy the ride dude!.

View more

¿Cuáles son tus conferencias favoritas de computación?

Las USENIX/LISA siempre me parecieron las mejores, porque había muy poco «ruido» comercial, y todas las presentaciones eran arbitradas por gente muy exigente, así que la calidad era asegurada. Participé en cinco de ellas entre 1995 y 1999.
Presenté un trabajo en las WCC/IFIP/CLEI 2006, pero no participé del resto de la conferencia, básicamente por problemas económicos y dificultades para obtener suficientes dólares (de mi bolsillo).
Quisiera participar en las ICFP, pero hasta ahora ha sido complicado.

¿Qué opinas de este artículo? https://eng.uber.com/mysql-migration/

Un caso de uso particularmente complejo, inusual y que ejercita «casos borde» a corregir, combinado con criterios subjetivos frágilmente sustentados.
Hace falta mucho contexto adicional para comprender el problema — los necios dirán «MySQL es mejor que PostgreSQL porque Über se cambió» y no se puede hacer nada al respecto :) El probema ocurrió con Pg 9.2, y no se menciona (pero se implica) que no intentaron ni el bugfix específico para uno de sus problemas, ni las versiones 9.3 o 9.4 que mitigan casi todos los demás problemas. Es el típico caso de querer usar Software Libre pero no estar interesado en mejorarlo cuando encuentras inconvenientes — libre albedrío y «free-riding», legítimo y moralmente cuestionable.
Leer todo este hilo y las referencias externas ilustra el problema y el análisis.
https://www.postgresql.org/message-id/579795DF.10502%40commandprompt.com
Además incluye una serie de discusiones derivadas muy interesantes.
En mi experiencia, ese escenario de modelado y escritura, si está *justificado*, es inusual. No puedo decir si está justificado o no, porque no conozco el modelo completo
Adicionalmente, es otro caso más de «esta herramienta es demasiado estricta y yo quiero sacrificar correctitud por velocidad». Muchas de las limitaciones indicadas son consecuencia de los mecanismos que impone PostgreSQL para ser 100% ACID con un sistema de tipos estricto (cosa que MySQL *no* tiene). No van escribir un artículo titulado «sorpresas con la replicación MySQL» ni «quiero cortarme las venas con MySQL, pero no es suficientemente afilado».

View more

¿Te quedas en Venezuela porque eres optimista?

Dejando de lado que la pregunta es un non-sequitur, y la referencia lateral a música que no me estimula, quedarme es necesario en esta coyuntura personal y el optimismo ni fomenta ni mitiga mi interés migratorio.
Liked by: Carlitos

Si no fueses computista, ¿qué serías? Sino fuese en Venezuela, ¿dónde vivirías?

Se es lo que se es y se está donde se está, porque es lo más conveniente según las decisiones tomadas. No tiene sentido conjeturar en algo menos conveniente, porque para nosotros el tiempo sólo avanza. No cambiaría nada.
Liked by: Rafael Quintero

Tengo entendido que solías ser bastante activo en lo que suelen llamar "Comunidad de Software Libre" en Venezuela. ¿Qué te alejó? ¿Fue la politiquería? ¿Fue el hablar mucho y no hacer nada? ¿Qué fue?

Llegó un punto en que la mayoría de los participantes querían «hacer» sin pensar acerca de lo que estaban haciendo — sólo querían una solución, sin comprenderla, para poder decir que sabían hacerlo. Eso es trabajo perdido para todos.
Paulatinamente, la minoría que pensaba antes de hacer, era criticada por no «hacer más» o juzgada por «no ser solidaria», y eso es peligroso — la ignorancia no es un punto de vista, mucho menos otorga el privilegio de la crítica, y cada quien es dueño de su tiempo, sus conocimientos y su experiencia como se le venga en gana. Algunos intentaron educar al resto al respecto, pero yo no tengo por qué sustituir la educación social, moral y cívica fallida.
Los que no pueden dejar de hablar de política, usualmente lo hacen porque no saben hablar de otra cosa, y necesitan la validación del grupo con frases como «el software libre es político» o «el software libre es -ista», y así. En general los ignoraba o, como pasa con «el dólar no vale eso», los despacho con el sarcasmo «por la casa». Tienen cosas más importantes que aprender en la vida y por eso les pasa lo que les pasa. Lo nefasto es que usaron su influencia, que no su autoridad, para generar cada vez más ruido, y muchos ni siquiera aprendieron Netiquette. Ignorarlos era ineficaz e ineficiente, haciendo inviable la coexistencia.
Así que, naturalmente, me alejé porque pensé que aprendería mucho más, y podría ser más útil en la Universidad, trabajando en tópicos bastante más interesantes. He aprendido muchísimo de mis colegas y mis alumnos, y me gustaría pensar que el sentimiento es recíproco.
Aún sigo participando en actividades relacionadas con el Software Libre, pero en grupos menos públicos y donde no se quiere dividir para que todos sean iguales, sino que se enseña a que cada uno multiplique por el factor que sea capaz de producir. Todos somos diferentes.
De todas formas, la gran cantidad de gente que ha desarrollado destrezas formales e informales en Software Libre, es más que suficiente para continuar con el esfuerzo de educar y fomentar esa manera de compartir conocimiento. Espero que sean más los que lo hacen con el ánimo de ver a otros aprender y mejorar las herramientas, que por hacerse de aplausos y reconocimientos pasajeros.

View more

¿Qué opinas de Canaima GNU/Linux? No tan solo como SO, sino como proyecto.

Siempre estuve en desacuerdo con la creación de una distribución GNU/Linux «propia» desde antes que se iniciara el proyecto. Cuando se inició el proyecto, abogué para que se hiciera una distribución derivada basada en Debian, pero nunca independiente — en otras palabras no intentar hacer lo que Ubuntu, sino simplemente aprender a usar Debian Installer y construir paquetes con las cosas específicas. Puesto que de los presentes en esa reunión nadie tenía idea de lo que había que hacer ni tenían experiencia en el tema, pero tenían que cumplir una promesa adquirida desde la improvisación y el proverbial «lo que usted diga», la primera versión de la distribución la hizo una sola persona, de un día para otro, como un Custom Debian Distribution, incluyendo las instrucciones públicas de cómo construirla y una lista de instrucciones cubriendo todas las cosas que NO tenían que hacer si querían mantener la estabilidad, el dinamismo y la sanidad mental.
Es público y notorio que ninguna de las tres cosas fue considerada con la gravedad del caso — quizás el que escribió las instrucciones usó un idioma ajeno o fue cándido al pensar que explicaba con claridad lo que podría suceder de tomarse decisiones fáciles pero incorrectas en la evolución del producto. Claro que los autores son responsables de lo que escriben y no de lo que otros comprenden — las ideas no son responsables de las tonterías que se hacen a su nombre. Y con tonterías quiero decir barbaridades.
Como se trata de un proyecto de Software Libre, hicieron lo que les pareció más conveniente (de seguro democráticamente) y por eso la distribución y el proyecto son lo que han llegado a ser, y no podría ser de otra forma sino así: es la Ley de Evolución aplicada al software, y se han adaptado tanto como la capacidad de su equipo de trabajo y la exigencia de su comunidad de usuarios. Como en todos los proyectos hay gente muy trabajadora y con la mejor intención de hacer las cosas bien, pero también hay «free-riders» y oportunistas. Para que los primeros sean más, tienen que ser rápidos y enérgicos, cosa que debe ser muy difícil si no tienen la motivación adecuada y el necesario respeto a sus opiniones expertas o la evidencia de resultados.
No participo en el proyecto desde el día siguiente que se entregó la primera versión con los dos manuales, porque sólo me interesa contribuir a Debian GNU/Linux.

View more

¿Que piensas de Elm?

No me interesó el front-end. No me interesa el front-end. No me interesará el front-end.
Si me viera en la necesidad de hacer cosas en el front-end que no pueda resolver con Hamlet, Julius, Cassius o Lucius, seguramente utilizaría Elm. Aunque lo más probable es que diga «búscate alguien que haga el front-end».
Elm aprovecha correctamente las ideas funcionales puras para resolver de manera concisa y elegante, buena parte del problema de preparar ese deleznable pasticho técnico que un gentío cree comprender y dominar porque «coders».

¿Puedes darme algún consejo útil?

«Dar consejos es lo único que le queda a las personas demasiado viejas para dar ejemplos», dijo (más o menos) La Rochefoucauld. Y con el tiempo, y el ejemplo de otros, uno aprende que si se es lo suficientemente sensato para dar un consejo, lo más sensato es no darlo al que lo pide sin saber para qué lo quiere.
Así que no tengo ningún consejo útil para dar.

Y también que los lenguajes funcionales se usan cada vez más en industria. ¿Cuáles recomendaciones tendría para un matemático quien desea mejorar su habilidades de programador? tomando en cuenta la discusión que Ud. abrió sobre lenguajes funcionales. 2/2

Julián Rojas Millán
Así que como venía diciendo, aprender R. Ahora bien, hay un par de lenguajes adicionales que podrían ser de mucha utilidad, tanto en lo necesariamente profesional como en lo lúdicamente existencial.
Octave siempre me ayuda a hacer prototipos de ML tan rápido, que muchas veces «quedan». Es mucho más extenso que R en términos de cálculo numérico, y además es capaz de sacar provecho de múltiples núcleos mucho mejor de lo que R puede hacer — las operaciones vectorizadas son efectivamente vectorizadas si el hardware tiene la capacidad. Corre en las tres plataformas de computación personal importantes (Linux, BSD y como se llame esta semana el OS de Apple), y corre razonablemente bien en Android.
A diferencia de R, Octave [1] se apoya en toda la historia de FORTRAN para cálculo numérico, tanto en algoritmos, como en la correcta generación de código de máquina para mantener los errores a raya. Modernamente, tiene hasta una GUI y saca provecho de OpenGL para sus gráficas — yo siempre uso la interfaz de línea de comandos porque obviamente es más expresiva.
Resuelve ecuaciones diferenciales ordinarias y algebraicas. Las operaciones con matrices son mejores (o más perturbadoras, depende del ánimo) que las de R.
Muchos consideran que Octave es un clon de Matlab — yo creo que es un doppelgänger más culto.
Finalmente, Julia [2] es seductora. Tine co-rutinas, paralelismo basado en algo en medio de un RPC y un mensaje a lo Erlang, además de tener macros y metaprogramación a lo LISP. Es lo más «programación funcional» que se puede llegar en el nicho de cálculo numérico.
Yo no utilizaría estos lenguajes para otra cosa que no fuese estrictamente cálculo numérico, pero no utilizaría ningún otro lenguaje para cálculo numérico sabiendo que existen estos lenguajes. Sería incivilizado.
Si quieres aprender a pensar funcionalmente, considerando que pretendes usar R y Octave, vale la pena que leas el HTDPv2 usando Racket [3]. Si bien Racket no te va a servir para cálculo numérico, es un buen vehículo para aprender programación funcional con un lenguaje interpretados con tipos dinámicos.
[1] https://www.gnu.org/software/octave/
[2] http://julialang.org
[3] http://htdp.org

View more

Soy matemático y me llamó mucho la atención su respuesta sobre los lenguajes funcionales. Trabajo en el área de probabilidades y análisis de datos, nunca a tan bajo nivel, mayormente uso Matlab pero últimamente uso Python. Investigando leí que R se considera funcional 1/2

Julián Rojas Millán
R es un lenguaje específicamente diseñado para estadística y análisis de datos, y seguramente te hará ahorrar muchísimo tiempo tanto en prototipos, como en trabajos temrinados, porque a pesar de ser un lenguaje fundamentalmente interpretado, su «máquina virtual» interna fue diseñada específicamente con eso en mente. Hay una limitación importante — todos los datos que vayas a manipular deben caber en memoria.
No es un lenguaje funcional, de hecho es fundamentalmente orientado a objetos, pero al tener tipos de datos especializados, los programas no tienen que ser tan imperativos, convirtiéndose en expresiones con muy pocos efectos de borde.
Por ejemplo, hay tipos de datos específicos para vectores y matrices, de modo que casi cualquier algoritmo alrededor de álgebra lineal puede escribirse como una expresión directa, y no como iteraciones anidadas.
También hay un tipo de datos específico para «colección de datos» — filas de campos, similares a las de una base de datos. Hablando de base de datos, PostgreSQL permite escribir funciones R *dentro* de la base de datos, así que no necesitas halar los datos desde PostgreSQL para traerlos a un cliente corriendo $OTROLENGUAJE para hacer el análisis. Let that sink in for a minute.
A diferencia de Python, la comunidad de R es muchísimo más disciplinada (en promedio y con muy pocos outliers — pun intended) por lo que CRAN representa una colección muy bien curada de librerías R para propósito general. Valga comentar que esa disciplina no es inventada por R (fue inventada por Perl, y los lenguajes con comunidades organizadas imitan la idea). Definitivamente es mucho mejor que el estado actual de las cosas en Python o Ruby.
La técnica de orientación a objetos de R es una de las más interesantes porque está inspirada parcialmente en CLOS, ya que usa el concepto de métodos genéricos sin clase (el método es «libre») que despachan según la clase del objeto específico que les haya sido entregado. Quizás estás «funciones sueltas» hayan hecho que alguien piense que R es funcional, pero no lo es.
Los dos rasgos funcionales sinceros que tiene R son la capacidad de escribir funciones anónimas,y de orden superior (funciones que reciben funciones). Así que si quieres escribir un map-reduce, no tienes que simularlo con iteraciones (como hacen en otros lenguajes que ya nombrasre). Eso te permite escribir cosas lindas, como por ejemplo
wat <- function(x) Reduce( function(u,v) u + 1 / v, x, right = TRUE )
para luego evaluar
wat(c(1,rep(2,42)))
y ver salir la raíz cuadrada de dos gracias a la fracción continua (sin «for» y probablemente más rápido).
Los gráficos son una cuchura.
Definitivamente es un lenguaje que vale la pena conocer en este nicho.

View more

Crees que Scala es un lenguaje que nos ofrece ventajas que Haskell no nos ofrece, por ser (el primero) orientado a objetos y según algunos "ofrecernos lo mejor de ambos mundos" ?

No.
Cualquier cosa que corra sobre la JVM va a ser lenta y demandar memoria, simplemente porque las máquinas de pila son lentas, generar código para máquinas de pila impide realizar muchas optimizaciones interesantes, el modelo de recolección de basura en lenguajes imperativos es lento y oneroso — ninguna de esas dos cosas se puede mejorar, porque está afectada por el problema del estado mutable. El argumento «pero tenemos JIT» es como «pero tenemos patria»: the cake is a lie. Si encima agregas el modelo de evaluación ambiciosa (eager evaluation) para poder combinar los dos estilos en el mismo lenguaje, tienes la receta para que código que utilice una combinación de transformaciones (map, fold, scan, unfoldr) *no* pueda ser fusionado, generándose código JVM lento y que consume más memoria. Estas son razones técnicas objetivas por las cuales Scala no es ni lo mejor de ambos mundos, ni siquiera algo que se pueda mejorar sustancialmente en el tiempo. Desde el punto de vista subjetivo, el programador hace un uso tímido (por no decir pusilánime) de las técnicas funcionales porque si le mete con todo, el programa corre lento.
Como siempre, no es la flecha, sino el indio — en este caso, el indio que recomendó Scala como «lo mejor de ambos mundos».
Si alguien que viene del mundo OOP comienza a usar Scala y no sigue de largo a usar lenguajes funcionales puros, que se quede con Scala o que intente cambiarse a un lenguaje multiparadigma más expresivo — pero iguales de costosos en consumo de memoria como Perl o lentos como Ruby. Python no cuenta, porque tiene más verrugas que lunares.

View more

¿Cuál es la prenda más rara que tienes?

Una bufanda de Cashmere, hecha en Kashmir, comprada regateando en Nueva Delhi.

Next

Language: English