1 de agosto de 2018

Cuando el dictador se jubila

En días pasados recibí un correo electrónico de Jaime Tovar, un destacado ex-alumno mío que actualmente trabaja en el Reino Unido como desarrollador de software sénior. En su mensaje me dio la noticia de que Guido van Rossum había renunciado un día antes a su rol de BDFL (siglas en inglés de “dictador benevolente de por vida”) del lenguaje Python. Jaime me sugirió que escribiera una entrada en este blog para dar a conocer mi opinión al respecto. Inicialmente no estaba muy convencido de que pudiera aportar algún comentario interesante a este hecho, pero después de pensar varios días me di cuenta de que sí tengo algunas reflexiones que puedo compartir con mis apreciables lectores.

Guido van Rossum, creador de Python.
Fuente: www.gacetaholandesa.com

Antecedentes

Guido van Rossum comenzó a escribir la primera implementación del lenguaje Python en diciembre de 1989. Desde aquel entonces, Guido había sido el líder moral indiscutible de la comunidad de Python y el encargado de dirigir la evolución del lenguaje. En 1995, a manera de broma, se le otorgó a Guido el título de “primer BDFL interino”.

Guido (centro) en la primera conferencia de Python en el
Instituto Nacional de Estándares y Tecnología (NIST),
noviembre de 1994 en Gaithersburg, Maryland.
Fuente: legacy.python.org

Pero, ¿qué es exactamente un BDFL? La wikipedia provee la siguiente definición:
BDFL es un título informal que se otorga a ciertos individuos de la comunidad de desarrolladores de software de código abierto que tienen la tarea de asignar las directrices generales y, en ciertas situaciones, las decisiones finales dentro del ámbito de un proyecto. La traducción de Benevolent Dictator for Life es Dictador Benevolente De por vida, lo que conlleva un tanto de informalidad y humor. 
Después de Guido han habido otras personas con el título de BDFL otorgado por parte de sus respectivas comunidades, por ejemplo Linus Torvalds (creador del núcleo o kernel de Linux) y Yukihiro Matsumoto (creador del lenguaje Ruby), por mencionar a un par.

Fuente: image.thmeythmey.com

En su ensayo titulado “Cultivando la noosfera”, Eric Raymond explica cómo la naturaleza del código abierto obliga a que una “dictadura” sea benevolente. Cuando un proyecto se enfrenta a una situación difícil se espera que su BDFL escuche y evalúe pacientemente los argumentos de todas las partes involucradas y finalmente tome la decisión que resulte más conveniente para los intereses de toda la comunidad. Sin benevolencia un desacuerdo mayor puede ocasionar una bifurcación (fork). En este caso una persona o grupo toma el código fuente del proyecto (que al ser abierto cualquiera tiene acceso a él) y comienzan a extenderlo y modificarlo en una dirección distinta a la original. Esto ha ocurrido varias veces en el pasado, por ejemplo cuando MySQL fue bifurcado para crear MariaDB en 2009. Esto fue debido a las preocupaciones que tenían algunos de los desarrolladores principales con respecto a la adquisición anunciada de Sun Micrsoystems (dueños en ese momento de MySQL) por parte de Oracle. La comunidad temía que Oracle, la compañía de bases de datos relacionales más grande del mundo, tuviera como objetivo eliminar eventualmente a MySQL y reducir así su competencia.

Un BDFL usualmente es el autor original de un proyecto. Esto significa que, por lo general, esta persona cuenta con un nivel técnico que otros respetan e incluso admiran. Sin embargo, su destreza tecnológica es tan solo una de varias cualidades que debe tener un buen BDFL. El reto principal de un líder de un proyecto de código abierto es lidiar con personas y coordinarlas, y esto resulta complicado debido a que la mayoría (o incluso todos) son voluntarios y no reciben remuneración económica alguna por su participación. Aquí el respeto, el agradecimiento y el reconocimiento juegan un papel fundamental.

Fuente: www.sieuthichungcu.info

En el año 2009, como broma de April Fool´s Day (equivalente al día de los santos inocentes en muchos países de habla hispana), se coqueteó con la posibilidad de la abdicación de Guido como BDFL. En esa ocasión se presentó el PEP 401 en donde se nombraba a Barry Warsaw como sucesor de Guido. En lugar de BDFL, el título de Barry iba a ser FLUFL (Friendly Language Uncle For Life,  o “tío amistoso del lenguaje de por vida”). Es importante enfatizar que esta noticia tan solo fue una broma de un 1º de abril. Sin embargo, ¿sería esto un augurio de lo que ocurriría casi una década después?

Barry Warsaw, el FLUFL o
“tío amistoso del lenguaje
de por vida”.
Fuente: hwww.linkedin.com

NOTA: Un PEP, o Python Enhancement Proposal, es un documento oficial de la comunidad de Python en el que se informa de una propuesta para mejorar el lenguaje o algún proceso. Posterior a la publicación de un PEP, los miembros de la comunidad discuten sobre la viabilidad de la propuesta y ofrecen sugerencias. La decisión final para aprobar un PEP corre a cargo del BDFL o, en su defecto, por algún delegado del BDFL. Todos los cambios relevantes que ocurren en Python comienzan con uno o varios PEPs. Tristemente, como veremos en un momento, fue a consecuencia de las reacciones negativas que recibió después de aceptar un PEP que Guido optó por anunciar su retiro como BDFL.


La noticia

El pasado jueves 12 de julio, Guido van Rossum comunicó lo siguiente a través de la lista de correo de python-committers:
Asunto: Transferencia de poder

Ahora que está concluido el PEP 572 ya no quiero tener que pelear por un PEP y descubrir que mucha gente detesta mis decisiones.

Quiero descartarme por completo del proceso de toma de decisiones. Seguiré allí por un tiempo como cualquier otro desarrollador del núcleo de Python, y todavía estaré disponible para guiar a las personas, posiblemente ahora con mayor disponibilidad. Pero básicamente me estoy dando unas vacaciones permanentes del puesto de BDFL, y ahora todos ustedes estarán por su propia cuenta.

Esto iba a suceder eventualmente de cualquier manera. Aún está ese autobús al acecho a la vuelta de la esquina, y no me estoy haciendo más joven... (evitaré compartirles mi lista de problemas médicos).

No voy a nombrar un sucesor.

Entonces, ¿qué van a hacer? ¿Crear una democracia? ¿Una anarquía? ¿Una dictadura? ¿Una federación?

No me preocupan las decisiones cotidianas que surgen del sistema de seguimiento de incidentes o desde GitHub. Raramente solicitan mi opinión, y por lo general no es realmente importante. Así que esto continúa como siempre.

Las decisiones que más importan probablemente son:
  • ¿Cómo se deciden las PEPs?
  • ¿Cómo iniciar a los nuevos desarrolladores del núcleo de Python?
Es posible que podamos escribir procesos para estas cosas vía PEPs (quizás dichas PEPs podrían conformar una especie de constitución). Pero hay un truco aquí. Voy a dejar que todos ustedes (los autores de los “commits”) lo resuelvan por sí mismos.

Tengan en cuenta que aún existe un código de conducta. Si no les gusta dicho documento, la única opción podría ser dejar este grupo voluntariamente. Quizás hay detalles aún por decidir, por ejemplo: ¿cuándo debería ser expulsada alguna persona? (esto implica restringirle el acceso a las listas de correo de python-dev o python-ideas, ya que éstas también están cubiertas por el código de conducta).

Finalmente, un recordatorio de que los registros de esta lista son públicos (https://mail.python.org/pipermail/python-committers/) aunque la membresía es restringida (limitada solamente a los desarrolladores del núcleo de Python). Todavía estaré aquí, pero estoy intentado dejar que todos ustedes resuelvan algo por su propia cuenta. Estoy cansado y necesito un descanso muy largo.

— Guido van Rossum (python.org/~guido)
El PEP 572 al que Guido se refiere al inicio de su comunicado es sobre “Expresiones de asignación”, un cambio previsto para ser incorporado en la versión 3.8 del lenguaje que está programada a ser liberada en octubre de 2019. Actualmente, las asignaciones a variables en Python deben realizarse usando un enunciado (statement) de asignación. Veamos el siguiente ejemplo:
# Código para Python 3.0 y superior
r = input('¿Deseas continuar? (s/n) ')     # 1  
while r in 'Ss':                           # 2
    print('Tu respuesta fue:', r)          # 3
    print('Continuando...')                # 4
    r = input('¿Deseas continuar? (s/n) ') # 5
Las líneas 1 y 5 son enunciados de asignación. De hecho, son exactamente el mismo enunciado. Esta duplicación es necesaria aquí dado que Python no cuenta con un enunciado do-while y el valor de la variable r es requerida tanto en la condición (línea 2) como en el cuerpo (línea 3) del enunciado while.

El PEP 572 introduce un nuevo operador de asignación := (un signo de dos puntos seguido de un signo de igual) que permite realizar asignaciones dentro de una expresión. Este nuevo operador es esencialmente equivalente al operador de asignación = (un signo de igual) soportado por los lenguajes basados en C (C++, C#, Java, JavaScript, etc.). Ahora con el operador de asignación := el código de arriba podría quedar escrito de manera más compacta así:
# Código para Python 3.8
while (r := input('¿Deseas continuar? (s/n) ')) in 'Ss': # 1
    print('Tu respuesta fue:', r)                        # 2
    print('Continuando...')                              # 3
Hay que notar que la asignación de r se realiza ahora dentro de la misma expresión condicional del enunciado while (línea 1) reduciendo con ello dos líneas del programa. Cada vez que se realiza la condición del while, se realiza primero la re-asignación de la variables r.

A muchas personas no le gustó esta adición al lenguaje. Hubo a quienes simplemente no les gustó la sintaxis del nuevo operador. A muchos otros no les gustó en absoluto la idea de tener una forma alternativa de realizar asignaciones de variables por considerar que estaba quebrantando el Zen de Python, el cual es una serie de principios de software que influyen en el diseño del lenguaje.

La gente en desacuerdo comenzó a compartir su opinión al respecto con poca mesura, tanto a Guido como a la Internet. Y así fue como se abrió esta pequeña caja de Pandora.

Pandora's Box by Arthur Rackham
“Caja de Pandora” de Arthur Rackham.
Fuente: talesfortadpoles.ie

Francamente, a mí no me gustó al principio la propuesta ni la sintaxis seleccionada. Después de algunos días de asimilación me acostumbré a la idea y creo que sí utilizaría este nuevo operador, aunque solo en ciertos contextos. Sin embargo, como educador, lo más probable es que optaría por no enseñarlo a mis alumnos, al menos no durante un curso de introducción a la programación. La razón es simple: idealmente cada enunciado debe tener un solo efecto. Si un enunciado tiene dos o más efectos resulta más difícil de entender. Es preferible que cada efecto esté en su propia línea. En el último código, la línea 1 tiene dos efectos: la asignación y el resultado de la condición del ciclo. Esta complejidad no la necesita un principiante, y por tanto me parece más conveniente evitarla. Y así es como enseñamos a programar: evitando presentar a nuestros estudiantes aquellos elementos del lenguaje que no contribuyen a lograr nuestros objetivos académicos.

Reflexiones

Antes que todo, pienso que es una pena que Guido haya abandonado su puesto como BDFL. Sin embargo entiendo y respeto completamente su decisión y no puedo mas que sentir un profundo agradecimiento por todo el tiempo y la dedicación que invirtió para lograr lo que actualmente es Python y su vibrante comunidad. También hay que recalcar que Guido no va a esfumarse. De hecho, él continuará presidiendo la Python Software Foundation (PSF), que es la organización dedicada a fomentar el desarrollo de la comunidad de Python. En la biografía de su cuenta de Twitter, Guido ahora se describe como “Creador de Python y BDFL emérito”.

Es válido que la gente esté en desacuerdo con nuestras ideas y es muy valioso que podamos discutir, pero siempre y cuando lo hagamos de manera inteligente y respetuosa. Lamentablemente, en muchas ocasiones lo anterior es la excepción y no la regla. Lo que ocurrió a raíz del PEP 572 es un fenómeno que estamos viendo en otros lados. Al parecer todo el mundo se siente con la libertad de expresar su opinión y ahora, gracias a la Internet y a las redes sociales, tenemos a nuestra disposición un público de un tamaño que jamás nos hubiéramos imaginado tan solo hace algunos años. En principio esto parece algo bueno, ya que podría ser la base para una verdadera democratización, en donde todos pueden hacer oír su voz. Pero lo que ha pasado en muchos casos es que los que hablan y gritan más fuerte son los que han estado dominado el escenario. Muchas personas se sienten con todo el derecho de vociferar su opinión, no importándoles si sus argumentos cuentan o no con un sustento razonable. ¿A caso ser escandaloso tiene más peso que ser instruido?

Fuente: www.vexels.com

Un número desmedido de personas repudiaron la decisión de Guido de aprobar el PEP 572 y se lo manifestaron de manera hiriente. En una entrevista realizada por InfoWorld hace unos días, Guido comentó que sentía que había perdido la confianza de los desarrolladores del núcleo de Python cuando varios de ellos le atacaron de manera personal en redes sociales como Twitter. Al igual que la mayoría de esos desarrolladores, el rol de BDFL que desempeñaba Guido era también a título de voluntario. ¿Qué puede ser más desmoralizante que hacer un trabajo de manera generosa y a cambio de ello recibir severas críticas y agresiones?

Regresemos ahora al tema de las dictaduras benevolentes. Si vivimos en un país democrático muy probablemente consideramos que la democracia es el estilo de gobierno que nos conviene emular en otros entornos de nuestra sociedad. Pero la democracia no funciona en todos los contextos. Imaginemos un hogar conformado por cinco personas: tres hijos pequeños, la mamá y el papá. Si cada mañana deciden entre todos el menú para desayunar de manera democrática existe una alta probabilidad de que acabarán comiendo siempre helado y hot cakes. La verdad es que unos buenos padres procurarán brindar una alimentación balanceada a sus hijos, no porque quieran fastidiarlos dándoles comida que a lo mejor no les gusta, sino porque buscan su bienestar a largo plazo. En otras palabras, los padres juegan el rol de dictadores benevolentes. Unos padres amorosos seguramente escucharán y tomarán en cuenta las opiniones de sus hijos, pero finalmente tomarán decisiones que no siempre serán populares ni bien recibidas.

Fuente: www.shutterstock.com

La comunidad de Python decidió desde sus inicios que su forma de gobierno iba ser a través de un dictador benevolente. La idea era contar con una persona sabia y visionaria que pudiera tomar las decisiones difíciles, cuidando siempre los intereses de la propia comunidad. Ése era el acuerdo. Inicialmente, para cada situación importante, iba a haber un espacio para discutir los diferentes puntos de vista. Pero al final Guido tomaría la última decisión y todos tendrían que acatarla. Guido era el capitán del barco, y se le otorgó a él la confianza y el permiso para dirigir la nave de acuerdo a su criterio. Se estableció desde el principio que esto no iba funcionar como una democracia. Por lo tanto, una vez tomada una decisión por parte del BDFL ya no queda nada más que hacer, salvo apechugar en caso de que no fuera de nuestro agrado. Al parecer no todo el mundo entiende cómo funciona este estilo de gobierno. Después de que Guido anunció su decisión sobre el PEP 572 muchos inconformes sintieron que estaban en su derecho de lanzarse a la yugular del BDFL.

He podido de ver de primera mano que Guido tiene una personalidad conciliadora y no busca imponerse. Esto contrasta con otros BDFLs, como es el caso de Linus Torvalds, quien no tiene problemas en mandar al carajo a quienes no comparten su punto de vista. Incluso Torvalds alguna una vez dijo: “No soy una persona amable, y tú no me interesas. Me importa la tecnología y el núcleo de Linux; eso es lo importante para mí”. Pero Guido no es así. Él es un individuo gentil que busca llevarse bien con la gente y que pone a las personas por encima de la tecnología. Es probable que esa forma afable de ser lo llevaría a ir acumulando a través de los años una enorme presión que finalmente terminaría por reventarlo.

Lo que mucha gente se pregunta ahora es: ¿qué va a pasar con Python? ¿Qué va a ocurrir si se decide que el lenguaje evolucione bajo un esquema en donde mucha gente pueda meter su cuchara? Esto preocupa porque viene a la mente aquel viejo proverbio inglés que dice: “Demasiados cocineros echan a perder el caldo”.

https://d12m9erqbesehq.cloudfront.net/wp-content/uploads/sites/21338/2018/04/12132631/cooking.jpg
Fuente: northwoodelementary.eventsmart.com

En el pasado, algunos lenguajes de programación han sido diseñados y extendidos mediante comités conformados por múltiples compañías e individuos. Ese fue el caso de la estandarización de Common Lisp. Cada miembro del comité tenía su propia visión de lo que consideraba que debía incluir el lenguaje. El problema fue que las visiones individuales no necesariamente coincidían entre sí. Si alguien quería que se incorporara una determinada característica en el lenguaje a menudo tenía que realizar concesiones con los otros miembros del comité. Así pues quedó finalmente un lenguaje gigantesco (la especificación original consistía de más de mil páginas) y chipotudo (con inconsistencias y redundancias). Bien dijo el ingeniero automotriz británico Alec Issigonis (creador del auto Mini original): “un camello es un caballo diseñado por un comité”.

Fuente: medium.com

Otro problema que tienen los comités es que frecuentemente tardan mucho tiempo en generar resultados, sobre todo si el número de integrantes es grande. Podemos observar esta situación en la evolución que ha tenido el lenguaje Java comparada con el lenguaje C#. En el año 1995, Sun Microsystems liberó la primera versión de Java. Por su parte, Microsoft sacó C# al mercado siete años después. Aunque inicialmente C# fue denunciado por muchos como una copia deficiente de Java, al paso de los años esta situación cambió. Java poco a poco se fue rezagando a tal grado que ahora es Java quien le está copiando a C#. Por ejemplo, las funciones anónimas (conocidas también como lambdas) aparecieron en C# 3.0 en 2007, pero fue hasta el 2014 que fueron incorporadas a Java 8. El lenguaje Java tarda más tiempo en avanzar debido a que depende del Proceso de la Comunidad Java (JCP por sus siglas en inglés), que está subordinado a un comité relativamente extenso que se encarga de tomar todas las decisiones relacionadas con la plataforma Java. Por otro lado, el rápido y ágil progreso de C# ha sido producto de un pequeño equipo encabezado por el eminente ingeniero de software danés Anders Hejlsberg (creador de Turbo Pascal, Delphi y C#).

¿Tomará Python el camino de un estilo de gobierno encabezado por un comité? En la entrevista de InfoWorld previamente mencionada, Guido comentó lo siguiente:
El grupo de desarrolladores del núcleo de Python acordó una agenda para llegar a una conclusión. La fecha límite para las propuestas es el 1° de octubre de 2018. Entonces, me parece, que para el 1° de noviembre de 2018 se han comprometido a haber seleccionado una propuesta para una estructura de gobierno. Luego, para el 1° de enero de 2019, se comprometieron a elegir o designar efectivamente, o como sea que se indique en sus documentos de gobierno, a las personas que estarán a cargo.

Si una de las propuestas es que haya un solo BDFL, esa propuesta deberá redactarse detalladamente
para el 1° de octubre, indicando cómo se seleccionará, cuánto tiempo permanecerá a cargo, cómo se le puede impugnar, y todo eso. Tal vez para el 1° de enero tendrán una persona real designada.
En un podcast de PythonBytes, Carol Willing y Brett Cannon, dos de los desarrolladores del núcleo de Python, comentaron cómo creen ellos que va a quedar conformado el nuevo modelo de gobierno para Python. Al parecer se está pensando en que haya un nuevo BDFL, o alternativamente un “consejo de ancianos” compuesto por entre 3 y 5 personas. Esto me parece una muy buena noticia por la razón que ya expuse anteriormente.

Fuente: maxima.id

Haciendo a un lado la dimisión de Guido como BDFL, hay que reconocer que Python está viviendo su mejor momento y dudo que esto vaya a cambiar en el futuro inmediato. Según Stack Overlow, de los principales lenguajes de programación, Python ha sido el que más ha crecido en los últimos cinco años dentro de los países con mayores ingresos. El índice TIOBE de julio de 2018 coloca a Python como el cuarto lenguaje de programación más popular del momento, solo atrás de Java, C y C++. Por otra parte, Python aparece en el primer puesto tanto en el índice de popularidad de lenguajes de programación (PyPL) de julio 2018 como en la clasificación 2018 de los principales lenguajes de programación de la revista IEEE Spectrum.

Una gran parte de la comunidad de Python está conformada por usuarios que no son desarrolladores de software pero que sí necesitan programar para resolver problemas de cómputo científico, ciencia de datos y aprendizaje automático. Estos usuarios dependen de herramientas basadas en Python como Jupyter, NumPy, SciPy, Matplotlib, pandas y TensorFlow. No veo que el retiro de Guido les pudiera afectar, incluso si la evolución del lenguaje se detuviera por algunos años. La inmensa comunidad de Python está muy bien consolidada y eso permitirá que trascienda más allá de una sola persona. Desde luego que vamos a extrañar al buen Guido, nuestro dictador benevolente, pero me siento optimista sobre el destino de Python.

Con Guido, BDFL emérito.
Foto tomada durante PyCon USA, mayo de 2018.