Ricardo Galli, de software libre

En inglés se suele decir que una persona -especialmente un blogger- es opinionated cuando opina frecuente y públicamente, además es obstinado en esas opiniones. Quizás en castellano la palabra sea terco, obstinado, aunque me parecen que son demasiada peyorativas. De todas formas seguro que yo entro en ese conjunto de personas opinionated

Salvando las distancias en calidad y éxito, suelo hacer lo mismo que Jeff Atwood de The Coding Horror –que por cierto hace poco habló bien del WP-Cache, a pesar que está “abandonado” hace más de un año por falta de tiempo y motivación –. Hoy  explica su estilo en Strong Opinions, Weakly Held.

Lo saco a colación a raíz de su artículo –con el típico titular de un opinionated– PHP Sucks, But It Doesn’t Matter. Yo llevo programando PHP desde hace años, pero su titular y estilo no me molestó, al contrario, me gustó bastante. Primero porque entiendo muy bien –y lo comparto– ese estilo de escribir. También porque sé que el PHP como “diseño de lenguaje” es muy malo. Luego porque el apunte es divertido, pero fundamentalmente porque invita a una reflexión sobre la paradoja y contradicciones del tema.

Lo realmente importante está en la segunda parte del título y en la última del apunte:

But I’m also here to tell you that doesn’t matter.

The TIOBE community index I linked above? It’s written in PHP. Wikipedia, which is likely to be on the first page of anything you search for these days? Written in PHP. Digg, the social bookmarking service so wildly popular that a front page link can crush the beefiest of webservers? Written in PHP. WordPress, arguably the most popular blogging solution available at the moment? Written in PHP. YouTube, the most widely known video sharing site on the internet? Written in PHP. Facebook, the current billion-dollar zombie-poking social networking darling of venture capitalists everywhere? Written in PHP. (Update: While YouTube was originally written in PHP, it migrated to Python fairly early on, per Matt Cutts and Guido van Rossum.)

Notice a pattern here?

Some of the largest sites on the internet — sites you probably interact with on a daily basis — are written in PHP. If PHP sucks so profoundly, why is it powering so much of the internet?

Coincido con él en muchas cosas, aunque describiría de otra forma a los problemas fundamentales del PHP:

1. No fue diseñado desde el principio como un lenguaje basado en objetos y polimorfismo, que es uno de los problemas que genera la superpoblación de funciones. Así en vez de tener un $array.shift() o $array.pop() existen funciones como array_shift() o array_pop().
2. Tampoco tiene las facilidades de tratamiento de listas que tiene cualquier lenguaje dinámico desde hace dos décadas como mínimo, como por ejemplo slices nativos, por lo que se necesita otra función como array_slice() a substr() en vez de poder usar $array[i:j] o $string[i:j].
3. No hay soporte nativo uniforme de módulos que permita tratar de forma transparente –como el use de Perl,  import de Python o include en Ruby–, a módulos desarrollados en PHP y a los llamados “módulos PHP” que se cargan dinámicamente por el interprete.
4. No soporta los namespaces independientes para evitar evitan la polución del espacio de nombres global.
5. No tiene soporte nativo para frameworks o abstracciones tan básicas como las de acceso a bases de datos como DBI en Perl, PyDB en Python, DBI o ActiveRecord en Ruby. Así cada sistema gestor de base de datos tiene sus propias funciones, con sus propios nombres y métodos de acceso.
6. Otros et cetera.

Pero unas críticas de este tipo son incompletas, hay que analizar también el porqué tuvo tanto éxito, su contexto histórico y qué tipo de problemas fue capaz de resolver.

El contexto histórico es que el PHP surgió como un hack rápido para poder generar páginas HTML dinámicas en un momento –1995, antes que existiese ASP o VB Script de Microsoft– en que no había demasiadas opciones y que la Internet comercial y ommipresente estaba todavía en sus inicios.

El lenguaje, por su sencillez, podía ser compilado e interpretado muy eficientemente. Hoy en día, en un programa “pequeño” el PHP sin precompilar (o sin cachear, lo que hace el eaccelerator) sigue siendo más rápido que un Python precompilado (que a su vez es mucho más eficiente que Ruby). En unas pruebas que hicimos en clase de AdmSO, un “hola mundo” en PHP generaba casi 6000 páginas por segundo en mi portátil. En el mismo ordenador, Python no llegaba a 4000. Esta velocidad y eficiencia tiene su coste, por ejemplo la falta de polimorfismo, la diversidad de funciones, la falta de namespaces, etc.

PHP también supo resolver los problemas de su época, aunque hoy todos estemos convencidos que un modelo MVC (o MTV) como el Django, Rails, PHP Cake o Struts sean la “bala de plata”, no es ni ha sido siempre así. En el desarrollo web se usó y sigue siendo útil el modelo de desarrollo “basado en la vista” sin “efectos colaterales” en las otras vistas que permiten un prototipado poco ordenado y quizás caótico, pero extremadamente rápido. Es decir, se pueden definir las páginas que serán visibles al usuario –lo que suelen hacer con el “árbol de navegación”– y programarlas de forma independiente sin que la modificación de una implique u obligue a cambios en las otras vistas.

Esto último no es lo habitual en el desarrollo de aplicaciones web MVC, a menos que tengas perfectamente diseñado y resuelto  de antemano cuál será el uso final y la arquitectura del sistema (algo bastante raro en proyectos novedosos o en startups, véase por ejemplo el caso paradigmático de Twitter). A diferencia del PHP “plano”, en un modelo MVC como Rails o Django (supongo que en Struts debe ser similar, no lo conozco) hay que mantener sincronizados el controlador, las vistas y las plantillas. Se puede “forzar” a tener un fichero independiente para cada vista y plantilla, pero eso exige duplicación de trabajo y se pierden algunas de las ventajas del MVC (aunque la  DRY –Dont Repeat Yourself– sigue prevaleciendo como fundamental).

Además de los puntos mencionados anteriormente –eficiencia y velocidad del intérprete, prototipado rápido– tiene otras ventajas que han tenido mucho que ver con el éxito del PHP: es libre, multitud de código y ejemplos en Internet, las librerías de PEARL, facilidad para implementar frameworks adaptados a las necesidades de una aplicación –como el EZ DB simplificado y optimizado del Menéame–, una curva de aprendizaje muy suave y quizás la fundamental, la calidad de la documentación en línea de PHP.net.

En resumen. No existen las soluciones mágicas, diseñar buenos lenguajes es muy difícil, incluso los lenguajes a priori muy malos tienen sus ventajas y no hay que descartarlos sobre todo si han tenido el éxito que tuvo el PHP, uno de los primeros lenguajes dinámicos usado de forma masiva en Internet (después de Perl –cuyo equivalente “empotrado” en el servidor web, el mod_perl– es bastante duro para programar).

Además PHP no ha dejado de evolucionar, así en la versión 4 (liberada en mayo del 2000) se incluyó  programación orientada a objetos, muy mejorada en la versión 5 (2004) que incluyó también construcciones importantes como las excepciones.

Todo esta reflexión fue generada por un artículo en principio “troll” pero en el fondo provocador, de esos que me gustan mucho. Un ejemplo de todo lo contrario se puede leer en este otro artículo que usa de excusa a PHP Sucks, But It Doesn’t Matter para demostrar públicamente la ignorancia sobre el tema. Así dice:

Siempre me ha parecido la “versión amateur” del ASP. Sin orientación a objetos hasta hace poco, Testeo unitario, manejo de excepciones y con una serie de aspectos que me han tirado siempre de espaldas cada vez que he intentado hacer algo con él.

En este apunte ya desgrané parte de la respuesta, además ya respondí brevemente y punto por punto.

Si este apunte hubiese sido de un jovencillo que empieza su andadura en el desarrollo o estudios de informática no me hubiese extrañado nada esa divulgación de mentiras, la ignorancia del tema del que habla, la falta de un mínimo de contraste –tan fácil que es recurrir a Google, la Wikipedia o PHP.net– y la defensa cerrada y numantina de una tecnología –ASP y VB Script– propietaria de una empresa y que prácticamente no tiene “mercado web” más allá de las empresas cautivas de Microsoft (módulo MySpace).

Tampoco me hubiese molestado si un “profesional” afirmase desconocer completamente el PHP, nadie está obligado, ni siquiera es posible, conocer todas las tecnologías que existen en informática. De hecho es un acto de honestidad enorme y poco frecuente que un blogger reconozca que no sabe de un tema.

Pero en este caso se hacen afirmaciones contundentes de un profesional que afirma tiene un máster, fue consultor y ahora responsable de tecnologías de la información de una empresa.

Ya ha llovido mucho, pero no deja de soprenderme el nivel de disfunción metacognitiva de los supuestos profesionales –mis colegas–, ¿cómo se puede ser consultar con tanta ignorancia de lo que “hay allí fuera”? ¿cómo este tipo de profesionales pueden llegar a ser responsables informáticos de una empresa?

¿Cómo pueden tener las empresas semejantes responsables? ¿No es una contradicción que sean las mismas que se quejan de la capacidad de los técnicos o de la formación universitaria? ¿No saben aplicar filtros para sus directivos? ¿O valoran más otras capacidades y luego se quejan de la carencia de las que ignoran?

Aunque hace años que se lleva la moda new age de pensar erróneamente que todas las opiniones son respetables.  Lo único respetable son las personas, en cambio hay opiniones que no se merecen nada de respeto. Si además se trata de obviar o mentir sobre temas técnicos objetivos de un profesional, deberían ser consideradas basura absoluta.

Deberíamos aprender de una vez a opinar como verdaderos profesionales, conocedores de lo que hablamos y/o contrastar mínimamente antes de hacer afirmaciones tan gruesas. No se trata de usar las “provocaciones inteligentes” de otros para manipularlas y usarlas de excusa para “salvar el culo”.

Porque al final me parece que este tipo de FUDs son [mala] excusa para justificar años  de decisiones incompetentes que han dejado a su empresa totalmente cautiva de lo que pueda hacer o dejar de hacer Microsoft.

I’m really pissed at Microsoft. Why?… Amazon doesn’t offer EC2 for Windows, just Linux… And I’m stuck with two Windows boxes at my hosting company, hosting a dead fucking end. My bet on Microsoft in the late 90s just ran out of gas. — Dave Winer en  Early notes on GoogleApps.

Vale. Salvad vuestros culos como podáis, pero no echéis mierda alrededor, que nos pringamos y cabreamos todos.

La buena noticia es que hace unos pocos días finalmente han aceptado el atestado policial de la Guardia Civil –varios juzgados se habían declarado incompetentes–  por nuestras denuncias de los ataques DDoS. Lo malo es que a pesar que estamos “negociando” para apersonarnos en la causa, hoy recibo un telegrama con la citación a los juzgados de Madrid… a las 9:30 de la mañana.

No sé qué da más trabajo y estrés, los ataques o los procedimientos legales

El 21 y 22 de mayo estuve en Murcia para dar la charla “Redes sociales de noticias: Menéame“. El título y tema no lo pusimos nosotros, sino que fue propuesto (¿o pedido?) por la organización. En ningún caso solicitamos ir allí, mucho menos proponer hablar de este tema.

Pero en el panel del WordPress veo un enlace entrante sobre el tema, con la siguiente crítica:

Por la tarde, sobre las 16:30 estuvo Ricardo Galli, Creador de Menéame. No estuvo mal la ponencia pero fue una publi incesante de su producto.

Lo siento María si te quedó esa impresión.

Aunque el título no dejaba mucho márgen, intenté quitar toda solemnidad al tema –como sale en las primeras transparencias, no me gusta ir de gran pensador de lo “2.0″– y fui lo más honesto que pude, la crítica tiene su parte de razón. Por eso es que somos muy reacios a asistir a estos saraos y rechazamos muchas invitaciones.

Cuando el público es “genérico”, si la charla se trata de explicar “tu proyecto” siempre saldrá, o se interpretará, como autopromoción. Sobre todo si sientes pasión por ese proyecto, como es mi caso con el Menéame.

La solución de muchos es el recurrir al big thinking, pero me niego. Ya hay demasiada solemnidad forzada, charlatanería y pseudociencias sobre el “web 2.0″, “redes sociales”, “economía de la información” y “periodismo ciudadano” para que un no iniciado como yo agregue más ruido al que ya sobra.

Hace unos días fui a poner en la estantería el libro Beatiful Code y se abrió en un capítulo llamado Treating Code As an Essay, de Yukihiro Matsumoto. Enseguida me llamó la atención el título, no sé cómo se me pudo haber pasado ese capítulo.

Mis alumnos de informática pueden atestiguar que no aprueban las prácticas sin el código bien sangrado y “legible” (también hablé de ese tema varias veces en mi blog, últimamente en Belleza, fealdad y complejidad o Colega, let’s see the code). Les doy el coñazo que no inventamos lenguajes para facilitar el trabajo de las máquinas, sino el de los humanos, los programadores.

Por otro lado en la asignatura –de libre configuración– Seducciones de la Informática les pido como trabajo final un ensayo, en la definición e idea original de Montaigne.

Volviendo al tema del capítuo. Cuando lo ví no tenía tiempo, estaba saliendo de viaje, pero hoy me acordé y  lo leí. El primer párrafo dice:

Los programas comparten algunos atributos con los ensayos. La cuestión más importante para los ensayos es “¿de qué se trata?”. Para los programas la fundamental es “¿qué hace?”. De hecho el propósito  debe ser lo suficientemente claro para evitar que siquiera nos formulemos esas preguntas. No obstante, para los ensayos y programas, es siempre importante prestar atención a cómo está escrito cada uno. Aún si la idea es buena, será difícil transmitirla a la audiencia deseada si es difícil de entender. El estilo en el que están escritos es tan importante como su propósito. Ambos, ensayos y líneas de código, existen –antes que nada– para ser leídos e interpretados por seres humanos.

Yikihiro luego explica los aspectos que considera más relevantes para los programas. Aunque los explica para justificar el diseño de Ruby, pueden servir como regla general (especialmente, para mi gusto,  la primera y tercera):

1. Brevedad: La brevedad es una virtud, definitivamente hay un coste de lectura para el ojo humano, el código debe eliminar la información redundante [*]
2. Familiaridad: Las personas son más conservadoras de lo que pensamos. Las curvas de apredizaje elevadas crean estrés y reducen productividad. Un lenguaje no debe oblighar a los progamadores a trabajar con conceptos nuevos y complejos. No ser demasiado innovador es también una ayuda para el “código bello”.
3. Simplicidad: Si un programa es complicado de entender no puede tener belleza.
4. Flexibilidad: Lo define como la “libertad de los hábitos forzados por las herramientas”. Cuando un programador es forzado a hacer algo en contra de suis inenciones se genera más estrés, lo que afecta negativamente al programador.
5. Balance: Ninguno de los elementos anteriores hará que el código sea bello, sino un adecuado balance entre ellos.

[*] Como contraste de brevedad muestra el siguiente código para el “Hola mundo”:

Java:

class Sample {}

public static void main(String[] argv) {
    System.out.println("Hola mundo")
}

Y luego la siguiente línea que hace exactamente lo mismo funciona igual en Ruby, Perl, PHP y Python (en Python es aún más breve, no hace falta el \n):

print "Hola mundo\n"

Unas pocas páginas más adelante del capítulo mencionado hay otro, Code in Motion, hacen referencia a otro ensayo Seven Pillars of Pretty Code, que da unos parámetros relacionados:

• Fusión: El estilo del código nuevo debe ser similar al ya existente. No debe notarse la diferencia entre ambos.
• Estilo libro: Hay que mantener las columnas limitadas ya que exigen un esfuerzo de desplazamiento de los ojos. La primera parte debe mantener la estructura fundamental, la derecha los detalles.  Si una línea es muy larga se puede hacer nombres más cortos, agrupar por similaridad  (pro ejemplo separando argumentos por líneas).
• Separar bloques: Separar los bloques lógicos en cada función, así se facilita la lectura más rápida y en “diagonal”.
• …

Mañana en clase de AdmSO (optativa) haré una demonstración de cómo se desarrolla para Google App Engine (GAE). Es una especie de “cierre” de la clase anterior, hice una demo de Django. En esta demo desarrollaremos exactamente lo mismo, pero para ejecutarlo sobre GAE

Preparar la demo de Django me tomó más de 5 horas. La de GAE bastante menos, pero es que los templates son los mismos y el modelo de datos casi igual, salvo el tipo de la “propiedades”.

No sé si hago bien.

Aunque técnicamente está muy bien, el lenguaje y el SDK son libres, al fin y al cabo es dedicar 45 min – 1 hora de clase en universidad pública para mostrar la tecnología de una empresa. Ya, todos los hacen, algunos peor –como esas clases con software privativo obligatorio, o los mata neuronas-ingenieriles como el Dreamweaver y similares–, pero tampoco me consuela.

PS: Es a las 15:30 en el A5. No hace falta que nadie me pida permiso para entrar si quiere verlo, claro que se puede.

… not to purge indexes in GAE, it takes hours to build them again.

Ah, cony, que esto era mi blog y no Twitter. Ya me parecía raro que funcionase. Perdón.

Esta semana estuve en SICARM. El miércoles por la noche nos invitaron a una cena de gala. Donde todas las mujeres estaban muy guapas, de largo y con tacones. Los hombres todos de trajes, salvo yo, con mis vaqueros y mis zapatos todo terreno. No me avisaron que era fiesta de gala, aunque de haberlo sabido tampoco hubiese mejorado demasiado.

El tema es que sí había bastantes frikis camuflados. En una de las frikiconversaciones hablábamos de Python y Java. Uno programador de Java me dice:

Es que no me fio nada de los lenguajes dinámicos, no me fio de los lenguajes que no se pueden compilar.

Ya había ingerido par de cervezas y jamones, así que me lo tomé de buen humor y hasta me reí del típico FUD. Pero hoy leí Dynamic Languajes Strike Back (vídeo, puaj, yo lo puedo ver), una buena y humorística presentación en la Universidad de Stanford sobre los mitos que hay con los lenguajes dinámicos (la “cultura informática” en Stanford parece ser muy  fanática C y C++).

La siguiente transparencia contestaría al planteamiento de la noche en Murcia de forma muy breve y expeditiva:

Dice más o menos:

Una vez que terminemos de resolver los problemas de rendimiento y herramientas (IDEs), ¿qué nos quedaría?

• Programadores necios, ignorancia, FUD.
• “Mantenibilidad”, la herramienta de FUD más moderna.
• La única solución: toneladas de marketing.

El sábado 31 de mayo a partir de las 12 de la noche estaremos en el tercer maratón de podcast hablando del Menéame. La idea, a propuesta de JR Mora, es que primero los entrevistadores nos harán  “preguntas difíciles”, de esas cosas que todos hablan o comentan, o críticas, pero no suelen preguntar o pedir nuestra opinión en “directo”. Luego me parece que los participantes podrán preguntar lo que quieran. Sólo puse una condición, que los que hagan preguntas estén mínimamente identificados –email, nick, o blog–. En eso parece que estamos de acuerdo y así se hará. Espero que salga divertido y que nos pongan en aprietos

A continuación habrá otro podcast de los usuarios habituales en la fisgona. Pero en ese sólo participan los usuarios, ya me han prohibido cualquier tipo de intromisión.

Mi mujer no deja de reñirme porque no cierro la tapa del váter –algo completamente masculino– y dejo las puertas de los armarios y los cajones abiertos. También una amiga –Cati– me riñe siempre porque dejo destapadas las botellas.

Hoy me ocurrió algo que me dejó muy sorprendido.

Voy al bar que está a metros de mi casa, La Pikota. El bar es de una pareja, Gori –mallorquín– y Hannele –finlandesa–. Cuando fui sólo estaba Gori, pido el café y busco un periódico. Gori me cuenta que hace un par de días llegó Janele y le dijo “Ricardo estuvo aquí, ¿verdad?”. Él le dice, que sí, y le preguntó cómo lo sabe. Janele le contestó:

Porque está el periódico abierto, Ricardo siempre lo deja así.

Pensé que me estaba haciendo una broma. No podía ser que tuviese otra manía de dejar “abierto” otra cosa más, y menos que fuese el único en el bar que hace siempre eso.

Pero cuando me estaba por ir llega Janele, entonces cierro el periódico y le digo en voz alta “Mira Hannele, estoy cerrando y doblando el periódico”.

Ella se ríe y le dice a Gori, “¡Se lo has contado!”

Aluciné con las manías que podemos llegar a tener, tanto que entre decenas de personas son capaces de identificarnos por ellas.

Por otro lado, en unas horas salgo hacia Alicante y de allí a Murcia –espero que me vayan a buscar– para el Sicarm 2008. Seguramente me olvidaré otra vez las tarjetas guapas de Moo, perderé algunos de los cargadores porque me olvido abierta la mochila y no seré capaz de ser “serio” en la conferencia, me pasa siempre que hablo del Menéame o de la blogocosa. Curioso, porque en las conferencias de software libre me decían que era muy serio, ¿será que les tengo poco respeto a todo esto del 2.0?

Pequeñas diferencias. El famosísimo MIT (vía Darth_Vapor), mi universidad, a pesar que la ley la “protegía”, a diferencia de lo que se está jugando el MIT, además montando por una asociación de alumnos.

Universidades con collons.