Saltar al contenido

Impresionante ensayo de Paul Graham del que he extraido y traducido (con ayuda google, no es una traducción perfecta) algunas reflexiones. Yahoo tenía el potencial para convertirse en lo que ahora es Google pero, a pesar del éxito pasado, está cayendo en desgracia. Según Graham, el fracaso se debe a que Yahoo no tenía a los mejores hackers dentro de la empresa. Se dejaron llevar por el dinero fácil obtenido por los banners publicitarios y no invirtieron en software de calidad:

The worst consequence of trying to be a media company was that they didn't take programming seriously enough. Microsoft (back in the day), Google, and Facebook have all had hacker-centric cultures. But Yahoo treated programming as a commodity. At Yahoo, user-facing software was controlled by product managers and designers. The job of programmers was just to take the work of the product managers and designers the final step, by translating it into code.

One obvious result of this practice was that when Yahoo built things, they often weren't very good. But that wasn't the worst problem. The worst problem was that they hired bad programmers.

La peor consecuencia de tratar de ser una empresa de medios fue que no se tomaron suficientemente en serio la programación. Microsoft (en su día), Google y Facebook han centrado su cultura empresarial en los hackers. Pero la programación en Yahoo era tratada como una mercancía. En Yahoo, el software diseñado para los usuarios era controlado por los jefes de producto y los diseñadores. El trabajo de los programadores era sólo para tomar el trabajo de los directores de producto y los diseñadores en la etapa final, para su traducción al código.

Un resultado obvio de esta práctica era que las cosas que hacía Yahoo a menudo no eran muy buenas. Pero ese no fue el problema más grave. El peor problema fue que contrataron a malos programadores.

Si el software supone una ventaja competitiva muy grande en una empresa, entonces la diferencia en tecnología es fundamental. Es España todavía no se comprende esto:

So which companies need to have a hacker-centric culture? Which companies are "in the software business" in this respect? As Yahoo discovered, the area covered by this rule is bigger than most people realize. The answer is: any company that needs to have good software.

¿Qué empresas necesitan tener una cultura  centrada en los "hacker"? ¿Qué empresas están "en el negocio del software"? Como Yahoo descubrió, el área cubierta por esta regla es más grande de lo que la mayoría de la gente piensa. La respuesta es: cualquier empresa que necesite tener un buen software.

Una visión muy personal sobre los problema de Yahoo, por parte de una de las personas que mejor conocen la empresa. Si pensamos en España la situación es muy parecida a la de Yahoo: las empresas tecnológicas en España son en muchos casos vendedoras de carne que tratan el software cómo una mercancía. Mientras sea más rentable sacar dinero de la carne que de vender productos tecnológicos, seguiremos tendiendo una industria cárnica de baja calidad (aunque aparentemente sean empresas tecnológicas de primera línea).

A los pocos días de eharle un vistazo a haile, robot percusionista, apareció esta viñeta en xkcd:

xkcd.com recipes

Nunca he tenido muy claro cuando es mejor utilizar un algoritmo genético, pero el ejemplo de Haile me ha servido para comprender mejor en qué situaciones usar estos algoritmos: cuando haya una población de elementos  muy amplia y que haya que seleccionar los elementos más apropiados según algún criterio (con una función de selección). Puede que el nombre sea un poco engañoso porque es más un algoritmo estadístico que biológico, que según la wikipedia converge en probabilidad a la solución óptima.

Curiosamente, también según la wikipedia, en 1999 se concedió la primera patente a un objeto no diseñado por un ser humano: se trataba de una antena diseñada con un algoritmo genético. No he encontrado información adicional sobre esta antena, pero recuerdo leer la noticia de esta antena y ver una foto de la extraña forma que tenía.

Hace un tiempo escribí que estaba de acuerdo con Paul Graham en que los lenguajes de programación se están lispificando. Entre los pasos de esa lispificación están los siguientes:

  • uso de máquinas virtuales en vez de lenguajes compilados (a través de técnicas mixtas como la compilación a códigos intermedios como MSIL de .net ó bytecode de java, pero son máquinas virtuales)
  • unificación de datos y programas a nivel funcional (uso funciones como tipo de datos, closures, etc.)
  • meta programación (DSL's)

Microsoft también está trabajando en su propio lenguaje de programación funcional que ejecutaría sobre la máquina virtual de .net. El leguaje es F# y soporta tanto programación funcional cómo orientada a objetos, con una sintaxis sucinta, expresiva con tipado fuerte. La descripción podría aplicarse a muchos lenguajes, pero en particular creo que apunta al éxito de ruby. En microsoft es raro que trabajen en algo si realmente no observan una tendencia en el mercado en ese sentido, así que parece que sí estamos en camino de una lispificación.

Hace poco he visto este chiste en xkcd que refleja a la perfección el sentimiento que se tiene al programar en lisp:


"Elegantes armas, para una época mucho más civilizada."

Lisp es el lenguaje de programación de la inteligencia artificial (clásica) por antonomasia. Paul Graham, que además de emprendedor es un gran defensor de lisp, tiene varios artículos a favor de lisp. Estos son algunos de sus argumentos a favor de este lenguaje (escribo de memoria, que alguien me corrija si me equivoco):

  • Tiene una sintaxis concisa. Paul sostiene que cuanto más conciso es un lenguaje de programación, más potente es.
  • Es posible redefinir el propio lenguaje, permitiendo crear nuevos lenguajes, por lo que en realidad es un meta-lenguaje.

Paul argumenta que los lenguajes de programación se están lispificando y creo que esto es más o menos lo que está pasando. Tomemos por ejemplo ruby y groovy. Ruby es un lenguaje de programación interpretado muy potente. Groovy es la versión javaficada de ruby (también existe Jruby, que es ruby ejecutado sobre la máquina virtual de java). Groovy es más bien una reinterpretación de java como lenguaje interpretado y creo que terminará imponiendose a medio plazo al propio java, para ciertos ámbitos de aplicación. Ambos son lenguajes relativamente modernos, ambos son interpretados y tienen closures que a su vez (y entre otras cosas) permiten la creación de lenguajes específicos de dominio (DSL's). Aún así, no llegan a la potencia de las macros de lisp que permite redefinir el lenguaje y que existan dialectos del lenguaje (como scheme). ¿Máquinas virtuales? Lisp ya era interpretado en los años 60 y sólo ahora que el hardware lo permite se están redescubriendo las ventajas de los lenguajes interpretados.
El principal problema de lisp es su sintaxis, recargada de paréntesis como los del chiste, lo que lo hace difícil de mantener porque ser muy difícil de leer, aunque Paul Graham lo ve cómo un problema menor. Pero en esto discrepo y creo que es mejor usar ruby o groovy, que mantienen parte de las ventajas de lisp, sin la desventaja del mantenimiento.
En general también pienso que los lenguajes se están lispificando. Es lógico que cuanto más haga un ordenador por tí, mejor. Y por eso creo que no sólo se están lispificando, sino que poco a poco los lenguajes se están convirtiendose en algo más cercano al lenguaje natural, hasta que (idealmente) algún día no programemos, sino que hablemos directamente con los ordenadores.
Pero tampoco abogo por el "todo en ruby". Es impensable implementar ciertas aplicaciones con un lenguaje interpretado (en particular en robótica) pero a alto nivel, es mejor tender hacia lenguajes cada vez más abstractos, que permitan, como lisp desde hace mucho tiempo, decir mucho con poco y adaptar el lenguaje a cada situación.