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?

https://media.licdn.com/dms/image/C4D03AQGjo_xKaOp-ig/profile-displayphoto-shrink_200_200/0?e=1537401600&v=beta&t=xC4BScsLVXLjhsXVgQI2iHUd08UzmHfN7NUJ7o0JhZY
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.

11 de julio de 2018

PyCon 2018

Del 9 al 17 de mayo se llevó a cabo PyCon USA 2018 en la ciudad de Cleveland, Ohio, en los Estados Unidos.


Este evento reúne a más de tres millares de personas que forman parte de la comunidad de usuarios y entusiastas del lenguaje de programación Python. Programadores, científicos, educadores y aficionados se dieron cita para aprender y discutir sobre técnicas, herramientas y prácticas relacionadas con el ecosistema de Python, así como para conocer y convivir con otras personas con intereses afines.

Con Guido van Rossum (creador de Python).

En esta entrada del blog comentaré sobre los aspectos que me parecieron más relevantes de este gran evento.

La importancia de las plataformas

La primera conferencia magistral de PyCon 2018 corrió a cargo de Dan Callahan. Dan tiene seis años trabajando en la fundación Mozilla, la cual es una organización sin fines de lucro que encabeza el desarrollo de diversos productos de software libre para la web, siendo Firefox el más conocido.

Dan Callahan en su conferencia magistral
titulada “La importancia de las plataformas”.

Dan comenzó su presentación hablando de su experiencia con el uso de tecnología cuando era niño y adolescente. En la década de los ochenta y noventa aprendió a programar la computadora IBM PC Junior y la calculadora gráfica TI-82. Ambos dispositivos tenían en común que se programaban a través del lenguaje BASIC. En aquel entonces él no tuvo que decidir qué lenguaje de programación utilizar, ya que la plataforma estableció de antemano el único lenguaje disponible.

Lo anterior nos lleva la siguiente conclusión: la plataforma dicta la herramienta. Y es por eso que la plataforma es muy importante si tenemos el interés en promover alguna herramienta en particular (Python, por ejemplo).


La siguiente imagen muestra las plataformas de cómputo disponibles desde tiempo atrás, así como las que están surgiendo en épocas más recientes y las que podríamos ver en un futuro. Todas estas plataformas tienen una cosa en común: están conectadas a la web.


Lo anterior significa que la plataforma computacional más generalizada hoy y en años venideros es la web. Dado que la plataforma dicta la herramienta, ¿cuál es la herramienta (específicamente el lenguaje de programación) disponible para la web? (alerta de spoiler: lamentablemente no es Python). Para acceder a la web necesitamos usar un programa conocido como “agente web”, típicamente un navegador (por ejemplo Chrome o Firefox). Hay miles de millones de dispositivos en el mundo (desde teléfonos celulares hasta supercomputadoras) con navegadores web que soportan un solo lenguaje de programación: JavaScript.

Entonces, ¿no se puede usar Python para programar la web? Claro que se puede, pero es importante realizar algunas precisiones. La web funciona bajo una arquitectura de software conocida como “cliente-servidor”. Esto quiere decir que un cliente realiza peticiones a otro programa, el servidor, quien le da respuesta. Del lado del servidor un programa puede estar escrito prácticamente en cualquier lenguaje, pero del lado cliente, como ya se mencionó, JavaScript es la única opción soportada casi de manera universal. Así pues, por ejemplo, aunque podemos correr código de Python dentro de un notebook (cuaderno) de Jupyter directamente sobre un navegador, el hecho es que dicho código realmente se ejecuta en un servidor que bien puede estar corriendo a su vez de manera local sobre la misma computadora.

Un cuaderno de Jupyter con
código de Python dentro
del navegador Firefox.

Para que Python pueda correr directamente en un navegador se requiere que éste tenga un intérprete de Python. Aunque ya se han hecho algunos intentos en este sentido (por ejemplo el proyecto Skulpt, el cual es un intérprete de Python escrito en JavaScript), Dan Callahan sugirió que el camino más viable es a través de un nuevo estándar de web llamado WebAssembly. Este estándar define un formato de código binario portable (conocido también como bytecode) que es ejecutado de manera íntegra por el navegador de manera más rápida que el código de JavaScript. La versión 1.0 de WebAssembly ya está incorporada en los cuatro principales navegadores web (Firefox, Chrome, Safari y Edge). Así mismo, ya existen también compiladores de C/C++ que producen código objeto de WebAssembly.

Lo anterior da lugar a que utilicemos la web como si fuera una plataforma computacional “convencional”. En teoría, ya se debería poder compilar el código fuente del intérprete de Python (CPython), que está escrito en lenguaje C, para que corra sobre la web. En la práctica aún hay ciertos problemas que no se pueden resolver fácilmente, ya que WebAssembly funciona con las mismas restricciones del entorno aislado (sandbox) que tiene JavaScript en el navegador (por ejemplo, no se pueden leer y/o escribir archivos arbitrarios).


Dan Callahan considera que debemos buscar una manera de combinar los mejores aspectos de la web con los elementos más sobresalientes que ofrece Python. La pregunta que lanza al público es: ¿cómo podemos llevar Python a la web en una manera en que le haga sentido a la web? Dan desconoce la respuesta, pero considera que tenemos todas las piezas que hacen falta para resolver este problema. Estamos frente a un territorio desconocido esperando a ser explorado. Depende de la comunidad de Python encontrar la solución a este formidable reto.

PyCon Charlas 

Por primera vez en PyCon USA se destinó un track completo dedicado exclusivamente a una serie de pláticas en idioma español. Esto ocurrió el día viernes 11 de mayo. PyCon Charlas fue el primer producto del programa Hatchery, el cual busca apoyar ideas innovadoras para PyCon y su comunidad.


Así fue como se justificó este nuevo evento:
Un porcentaje significativo de la población estadounidense, más del 12%, habla español y las comunidades hispanohablantes de Python en América Latina y Europa están creciendo rápidamente con una gran aceptación en conferencias y reuniones. PyCon Charlas dará visibilidad a los pythonistas hispanohablantes dándoles un espacio en la PyCon más grande del mundo para dar y recibir charlas en español.
En total hubo ocho presentaciones en esta avenida, con ponentes provenientes de Paraguay, México, Nicaragua, Colombia, Estados Unidos y Brasil. Se trataron temas muy diversos, desde ciencia de datos hasta internet de las cosas.

En las PyCon Charlas. De izquierda a derecha: 
Camila Remolina (presentadora en las PyCon Charlas),
Guido van Rossum (dictador benevolente de por vida),
Naomi Ceder (chair de las PyCon Charlas) y 

Mario Corchero 
(chair de las PyCon Charlas).

Motivando a niños de escasos recursos

Una conferencia magistral que me pareció muy conmovedora fue la que impartió Qumisha Goss. Ella trabaja en la Biblioteca Pública de Detroit y se especializa en instrucción tecnológica. Por su propia cuenta aprendió a programar en Python y está certificada como educadora de Raspberry Pi.

Qumisha Goss en su conferencia
magistral titulada “La gente y Python”.

Qumisha lleva más de tres años encargada de un proyecto en su biblioteca que busca enseñar razonamiento computacional a niños desde 6 y hasta 17 años utilizando robots y programación con Python. Tristemente, muchos de sus alumnos provienen de familias muy pobres. Aún así, hay personas que le llegan a cuestionar sobre la falta de diversidad en su salón de clase. Pero ella responde afirmando que la “diversidad” debe tomar un segundo plano cuando se tienen alumnos que pasan hambre en sus casas o que a los nueve años aún no han aprendido a leer. Los resultados de la labor de Qumisha son realmente admirables e inspiradores.

Conclusión 

Este año PyCon nos ofreció nuevamente una gran oportunidad para ponernos al corriente en todo lo relacionado con el lenguaje Python y su vibrante comunidad. Los videos (en inglés) de las conferencias y talleres están disponibles en el canal de PyCon 2018 de YouTube.



26 de marzo de 2018

Nueva certificación de Microsoft: Introducción a la programación usando Python

Introducción

Una certificación profesional es un proceso por el cual una organización valida y dictamina el nivel de conocimiento y/o competencia que tiene una persona para un cierto trabajo o tarea. En el área de TI (Tecnologías de Información) las certificaciones profesionales comenzaron a popularizarse en la década de los años noventa a través de diversas empresas como Cisco, Novell, IBM, Oracle y Microsoft. Con ello cualquier individuo tiene, desde entonces, la posibilidad de ganarse las credenciales que avalan su dominio en el manejo de ciertas herramientas tecnológicas demandadas en la industria.

Fuente: www.certifiedeo.com

Hasta hace relativamente poco había tan solo un puñado de certificaciones relacionadas con Python, las cuales se podían obtener después de tomar uno o varios cursos presenciales o en línea (por el ejemplo los cursos ofrecidos por la Universidad de Illinois a través de la O’Reilly School of Technology) o presentando un examen no supervisado por Internet (como los ofrecidos por la empresa Brainbench). Sin embargo, no existía una certificación de Python que tuviera un amplio reconocimiento en la industria a nivel mundial. Por decir, algo equivalente a la certificación de Sun Microsystems/Oracle para el lenguaje Java o la certificación de Ruby ofrecida por la Ruby Association. Al parecer esta situación está cambiando a partir de hace unos meses.


El recién creado Python Institute anunció que está preparando dos certificaciones de tipo vendor-neutral (independientes de proveedor). El primero y más básico es el Python Certified Associate Programmer (PCAP), que será liberado supuestamente en este mismo mes (marzo de 2018). El segundo y más avanzado es el Python Certified Professional Programmer (PCPP), el cual está programado para ofrecerse a partir de julio de 2018. PCAP no tiene requisitos previos, pero, como es de esperarse, para ser PCPP primero se tiene que ser PCAP. Cada una de estas certificaciones se obtendrá pasando un examen supervisado en alguno de los más de cinco mil centros autorizados de evaluación Pearson VUE localizados alrededor del mundo. El costo anunciado de estos dos exámenes es de $295.00 USD, con la posibilidad de obtener un descuento del 50% si se toman los cursos en línea correspondientes, los cuales no tienen costo.

Otra opción para certificarse en Python apareció apenas en agosto de 2017. 98-381 “Introducción a la programación usando Python” es la clave y el nombre del nuevo examen ofrecido por Microsoft. Conviene mencionar que además de esta certificación, Microsoft recientemente ha hecho un esfuerzo encomiable para apoyar al lenguaje Python y a su comunidad. Por ejemplo, Python ahora corre en Visual Studio 2017, Visual Studio Code y el Subsistema de Windows para Linux; así mismo, Azure (el servicio de cómputo en la nube de Microsoft) permite crear Jupyter Notebooks (documentos que contienen código fuente, ecuaciones, visualizaciones y texto explicativo) de forma gratuita.

Fuente: www.microsoft.com

Desde el año 2000 he obtenido más de una decena de certificaciones profesionales, principalmente relacionadas con la plataforma Java. La verdad es que me gusta el desafío que representa obtener una certificación en algún área de mi interés. Así que cuando me enteré de que Microsoft estaba ofreciendo una certificación con Python no pude mas que sentirme intrigado y decidí aceptar el reto.

Meme generado en: imgflip.com

En lo que resta de esta entrada del blog comentaré los detalles más importantes de la nueva certificación de Microsoft así como mi experiencia personal presentando este examen.

Información general sobre el examen

NOTA: La información que se presenta a continuación fue recopilada durante los meses de febrero y marzo de 2018. Algunos datos podrían diferir en el futuro. Recomiendo consultar el sitio oficial de Microsoft para obtener la información actualizada.

El examen 98-381 (Introducción a la programación usando Python) está basado en la versión 3.6 (o superior) de Python y va dirigido en particular al siguiente público:
  • Profesionales de TI
  • Desarrolladores de software
  • Trabajadores de la información (information workers)
El sitio oficial además agrega esto:
Los candidatos a este examen deben poder reconocer y escribir de forma sintácticamente correcta código de Python, reconocer tipos de datos compatibles con Python y poder reconocer y escribir código de Python que resuelva lógicamente un problema concreto.

Se espera que los candidatos hayan tenido, como mínimo, clases y/o experiencia práctica de aproximadamente 100 horas con el lenguaje de programación Python, estén familiarizados con sus funciones y capacidades, y comprendan cómo escribir, depurar y mantener código de Python bien formado y documentado.
Específicamente se evalúan las siguientes habilidades:
  • Realizar operaciones usando tipos de datos y operadores.
  • Controlar el flujo con decisiones y ciclos.
  • Realizar operaciones de entrada y salida.
  • Documentar y estructurar código.
  • Diagnosticar problemas y gestionar errores.
  • Realizar operaciones usando módulos y herramientas.
En mi trabajo como profesor en el Tecnológico de Monterrey he impartido varias veces el curso de Fundamentos de programación usando Python, en el que cubrimos una gran porción de los temas mencionados arriba. Así que la mayor parte del contenido del examen ya lo manejaba bastante bien. Solo tuve que concentrarme en estudiar la parte del API de Python, específicamente los módulo math, datetime, io, sys, os, os.path y random. En total le habré dedicado unas tres o cuatro horas de estudio.

Al acreditar el examen 98-381 se obtiene la certificación MTA (Microsoft Technology Associate). Su costo varía según el país. Para México y otros países de Latinoamérica el costo del examen es de $62.00 USD. En Estados Unidos el examen cuesta $127.00 USD. El costo del examen en España y otros países de la Unión Europea es de €127.00 EUR. El examen se lleva a cabo por computadora y es necesario acudir a un centro de evaluación autorizado de Pearson VUE o Certipoint para presentarlo.

Distintivo (badge) MTA
(Microsoft Technology Associate)

El examen se ofrece en varios idiomas, incluyendo inglés y español. Yo hice mi examen en inglés, pues me inquieta la idea de no poder entender completamente las traducciones que luego se emplean para ciertos términos técnicos. Por ejemplo, en el mismo sitio en español de Microsoft usan la palabra “operarios” como traducción de operators en inglés. Sin embargo, la mayoría de la gente de habla hispana usamos el término “operadores”. De forma similar, yo uso el término “operaciones de rebanadas” como traducción de slicing operations, pero en el sitio de Microsoft le llaman “operaciones de troceado”. No dudo que otros autores traduzcan estos y otros términos de manera muy distinta. Para no tener que estar adivinando, prefiero presentar este tipo de exámenes siempre en inglés.

Fuente: www.trialinteractive.com

El estilo de las preguntas del examen es variado. Hay una serie de videos (en inglés) en los que se muestran todos los posibles tipos de pregunta. A mí principalmente me tocaron preguntas de opción múltiple o de arrastrar y soltar. En total, el examen consta de 40 preguntas, las cuales se deben responder en 45 minutos como máximo. Esto significa que se tiene, en promedio, un poco más de un minuto para responder cada pregunta. Estoy acostumbrado a terminar este tipo de exámenes con bastante tiempo de sobra, incluso alcanzo a repasar con relativa calma todas mis respuestas antes de darlo por terminado. Pero esta vez no fue así. Por primera vez no alcancé a terminar un examen de certificación en el tiempo designado. Me quedé sin poder responder las últimas dos preguntas.

Fuente: naturalsociety.com

Debo confesar que durante la recta final del examen comencé a sentirme agobiado y con dudas sobre mi capacidad para concluirlo de manera exitosa. Afortunadamente, todo salió bien al final. Se requieren 70 de un total de 100 puntos para pasar el examen. En mi caso obtuve 90 puntos, así que logré acreditarlo con bastante holgura, aún a pesar del par de preguntas que me faltaron responder.

El resultado del examen está disponible inmediatamente al terminar, el cual se proporciona en forma de un reporte como el que se muestra a continuación:


El reporte muestra el desempeño de cada una de las seis habilidades evaluadas en el examen usando barras horizontales. El desempeño es mejor entre más larga sea la barra.

Una vez acreditado el examen, el sitio de certificación de Microsoft proporciona la opción de descargar en formato electrónico el certificado correspondiente.


Y a final de cuentas, ¿conviene certificarse?

El tema de las certificaciones en TI puede llegar a ser controvertido. Los detractores de las certificaciones consideran que éstas son solo un negocio para las compañías que las emiten, que no garantizan que alguien realmente domina el material examinado, y que la experiencia práctica obtenida en el trabajo y/o proyectos FOSS (software libre y de código abierto) es mucho más valiosa. A mi parecer estas críticas son bastante válidas, pero hay que considerarlas en su justa dimensión, pues de otra forma podríamos caer en el error de usarlas también en contra de cualquier esquema de educación formal.

El sitio de Microsoft enuncia las siguientes motivaciones para obtener una certificación profesional en el área de TI:
Las certificaciones le proporcionan una ventaja profesional al ser una prueba respaldada y mundialmente reconocida por la industria del dominio de unas habilidades, demostrando su capacidad y voluntad para aceptar las nuevas tecnologías. Verifique sus habilidades, consiga más oportunidades.
Para un joven recién graduado de una carrera profesional, alguien que posiblemente tenga poca o nula experiencia laboral, una certificación puede ser un factor importante para diferenciarse de otros candidatos a un mismo puesto de trabajo. Sin embargo, para alguien que ya tiene varios años de experiencia trabajando en la industria, las certificaciones pueden ser irrelevantes, aunque esto también depende del área de especialidad. Por ejemplo, las certificaciones en el área de seguridad, redes y administración de proyectos son más trascendentes que las del área de programación. El siguiente artículo (en inglés) escrito por Bob Violino hace una reflexión interesante sobre todo este asunto: The real dirt on programming certifications.

Para mí, en lo particular, las certificaciones han sido un medio para el desafío y la superación personal. Con ellas he podido validar y complementar mis habilidades y conocimientos, ya que me han motivado a prepararme en temas particulares que de otra forma difícilmente hubiera revisado por mi cuenta. Considero que las certificaciones han sido una buena inversión de mis recursos.

Fuente: emojiisland.com