La perlificación de Python

You know, FOX turned into a hardcore sex channel so gradually I didn’t even notice

Marge Simpson, Los Simpson

Recientemente ha salido Python 3.7, con interesantes novedades. También han salido los primeros artículos hablando de las novedades que podrá traer Python 3.8. Como muchos ya conoceréis, y si no es así explico, Python funciona a base de PEPs (Python Enhancement Proposal). Cualquier persona puede abrir un PEP, que es un documento que describe la funcionalidad que se quiere añadir/modificar/eliminar. Estas PEPs se discuten y finalmente Guido, creador de Python, las aprueba y se codifican.

Dentro de las PEP relacionadas con Python 3.8 hay algunas bastante controvertidas que han hecho saltar la voz de alarma. No ha faltado gente que ha opinado que cada vez Python se parece más a Perl. Este proceso habría empezado con Python 3 pero se habría ido haciendo más evidente hasta llegar a hoy. Cada vez con más sintaxis poco utilizada, con más elementos, más cómodo de escribir para el experimentado aunque menos legible si no dominas el lenguaje.

Y resulta curioso, porque Python es en parte una respuesta a la excesiva complejidad que podían tener los programas hechos en Perl. Su popularidad se debe a que es fácil de aprender y eso parece que ya no está tan claro.

Con la introducción de operadores como := o ?? o anotaciones como @dataclass se va, en cierta medida, perdiendo el espíritu original de Python. Y es cierto que otros lenguajes tienen algo similar, pero precisamente Python había sido muy selecto en incluir un conjunto bastante reducido de características, que todo el mundo pudiese dominar. Al final se sacrifica legibilidad y facilidad de aprendizaje por una ergonomía que beneficia a unos pocos en unos casos concretos.

Lenguajes de programación barrocos

Universidad de Valladolid, ejemplo de barroco civil. Foto: https://artevalladolid.blogspot.com

Python lleva un tiempo entrando en un proceso de perlificación pero en mi opinión no es el único lenguaje que ha entrado en una espiral parecida. Cada vez más lenguajes han pasado del renacimiento, donde se buscaba la consistencia, la simetría, la sencillez sin perder la funcionalidad, hacia el barroco, donde los lenguajes son más recargados, con más elementos sintácticos, que cubren mejor casos concretos, pero que de por sí no son tan esenciales, no cambian aspectos fundamentales del lenguaje y normalmente introducen diversas formas de hacer algo en un mismo lenguaje.

Veamos más ejemplos: en C++20 se propuso añadir funcionalidad de dibujado 2D a la librería estándar (propuesta que fue rechazada en una historia bastante larga para este post) y se han propuesto conceptos, módulos, comparación de tres vías, reflexión, metaclases,… En C# 8.0 se han propuesto también bastantes cosas como records, tipos non-nullable, interfaces con métodos ya implementados (traits) y rangos. Y eso sin contar con las características que estos dos lenguajes ya tienen, que son bastante más extensos que Python.

Retablo lateral de la Iglesia de San Miguel y San Julián (Valladolid). Barroco puro. Foto: https://commons.wikimedia.org/wiki/File:San_Miguel_-_retablo_relicario.jpg

Hay un horror vacui, horror al vacío, a funcionalidades. Siempre se añade y casi nunca se elimina. ¿Pero es realmente necesario? Es evidente que durante mucho tiempo, los lenguajes evolucionaban de forma muy lenta y muchos de los cambios que han hecho eran necesarios. Desde hace unos años, se ha aumentado la velocidad de los cambios, pero esto no puede seguir así eternamente, porque el ritmo que llevan muchas veces es superior al de los avances en lenguajes de programación y la retrocompatibilidad impide ir quitando cosas al mismo ritmo que se añaden. De este modo, todos los lenguajes que entran en esta espiral crecen y crecen. No se llegan a pulir, simplemente crecen.

La perfección no se alcanza cuando no hay nada más que añadir, sino cuando no hay nada más que quitar

Antoine de SaintExupéry

Uno podría comparar esto con lenguajes naturales, como el español o el inglés. En estos idiomas, pese a existir reglas, existen numerosas excepciones. Es posible que lenguajes como Python se estén viendo influenciados por las mismas mecánicas humanas que rigen los lenguajes naturales y que han hecho que existan excepciones. Tendría bastante sentido que ocurriese así. Pero personalmente, me gustaría que aprender Python no costase tanto como aprender alemán o francés.

Los procesos comunitarios

Para mí, gran parte de esta sobrecarga viene dada por los procesos comunitarios. En un proceso comunitario como PEP, comité de C++ o similares es mucho más fácil añadir que eliminar. En C++ la situación ha llegado a un punto en el que Bjarne Stroustrup, creador de C++, ha pedido que se relajen con las propuestas en Remember the Vasa!, en honor a un bonito barco sueco que se hundió por exceso de carga. No tanto por su peso, sino por su disposición y las reformas que hubo que hacer para que todo encajase.

El Vasa fue recuperado después de su naufragio y se expone en Estocolmo. Foto: https://rachelannsblog.wordpress.com/2016/08/03/set-sail-set-at-the-bottom-of-the-sea/

Es por ello que las personas encargadas de elegir que se añade al lenguaje o no deben de ser muy conscientes de lo que supone, ya que una vez se introduzca, va a ser casi imposible eliminarlo.

No estoy en contra de añadir nuevas características (¡al contrario!) pero se debe respetar la visión de conjunto del lenguaje, que todo cuadre y esté cohesionado. No siempre tener más es mejor.

¿Te ha gustado el artículo?

Si es así, puedes ayudar al blog. Dentro de unos días es el Amazon Prime Day. Como muchos de vosotros seguro que os compraréis algo, no quiero dejar la oportunidad de deciros que este blog tiene enlace de referidos y que por cada cosa que compréis con el enlace, me llevo una pequeña parte (a vosotros no os va a costar más caro).

Enlace Amazon.es

Será muy bien recibido

 

¡Haz scripts!

¡Haz scripts! ¡Escribe scripts! ¡Programa scripts! ¡Ejecuta scripts! ¡Automatiza! Escribir scripts tiene muchas ventajas. Escribir scripts es la mejor manera de ser productivo, mantener el entorno actualizado y evitar el error humano. ¡Automatiza!

Automation

Se es más productivo

Escribir scripts es la mejor manera de ser productivo. Perdemos parte de nuestro tiempo inicialmente para posteriormente recuperarlo en el futuro. Escribir un script es una inversión.

Estan siempre actualizados

Puede que hoy sepas el procedimiento exacto a realizar para una determinada tarea pero en el futuro puede que no lo sepas. El script siempre está actualizado, pues en cuanto deja de funcionar se debe reparar para seguir usándose. La documentación por ejemplo

bash

Menos errores

Tener un script reduce la posibilidad de error humano. Piensa que cada vez que hacemos algo de memoria podemos fallar. ¡Y puede que no sepamos cuando ha pasado eso!

Fáciles de compartir

Hoy día es muy fácil compartir scripts con el mundo. Cualquier programa de ‘paste’ funciona y sirve. Pastebin, BitBin.it, DesdeLinux Paste, GitHub Gist, BitBucket Snippets, Mozilla Paste, Ubuntu Paste, CryptoBin, Pasted, …

Algunos incluso te pagan por las visitas

Son TUS herramientas

Eres programador. Usas herramientas diseñadas por otros programadores. ¿Por qué no hacer tú alguna de tus herramientas? Agilizan tu entorno de trabajo como solo tu sabes. El verdadero maestro conoce sus herramientas al dedillo, si las diseñas todo ya tendrás mucho trecho hecho.

powershell

¿A qué esperas?

Creo que se ha quedado demostrado que quiero que hagas scripts; que automatices. Da igual el lenguaje que uses, pero usa tus propios scripts. Puedes usar Perl, Python, JavaScript, Ruby, Tcl, Bash, Fish, PowerShell, Lua y muchos más.

Mis predicciones para el futuro (en lenguajes de programación) I

Recientemente he estado probando nuevos lenguajes de programación, he investigado un poco en su historia y he pensado en hacer unas predicciones para el futuro de los lenguajes más populares.

Python
Python va a subir su popularidad con a corto plazo debido a su implantación en la educación. Si se consigue la transición a Python 3 que la gente lleva esperando tanto tiempo podría estabilizarse pero si no tendríamos en el problema de compatiblidad con grandes aplicaciones en Python 2. Quizá interese a largo plazo un nuevo JIT, de manera que este aumente su velocidad. Por estos motivos y teniendo en cuenta su sintaxis no de C creo que a largo plazo podría bajar considerablemente su popularidad.

Perl
Sencillamente cada vez va a bajar más. Es un lenguaje que para la mayoría resulta demasiado complejo teniendo otras alternativas para el scripting como Python, Bash o Node. Perl se seguirá usando en las tareas de compilación debido a la gran dependencia de las autotools pero no creo que evolucione mucho más de lo que es. Habrá que ver como reacciona la gente con Perl 6. Mencionar también que los sitios usando CGI van poco a poco a ir desapareciendo. De hecho el módulo de CGI está desrecomendado dentro de Perl 5.22 .

Node y JavaScript
Le veo un gran futuro a esta plataforma, al igual que a las bases de datos al estilo de MongoDB y al gran gestor de paquetes NPM. Su rapidez y el concepto de asíncrono van a ser sus grandes bazas. Me parece que va a ser un gran contrincante en el mundo web y también para el scripting, pudiendo sustituir eventualmente a Python y Perl en esas tareas. En el lado del cliente su uso es obligatorio pero va a crecer mucho con las tecnologías HTML5.

PHP
Se estabilizará bastante. Dentro de lo que cabe, es rápido para la poca memoria que gasta en comparación con otros lenguajes (Python, Java,…). Se va a seguir usando bastante sobre todo debido al gran público que conoce PHP. Además muchas empresas seguirán usando PHP antes que arriesgar con otros lenguajes más novedosos.

Java
Perderá adeptos. El modelo actual de Java es a mi parecer demasiado estricto y complejo y además cuenta con limitaciones de soporte en escritorio y perdida de velocidad en la web. Opino que si bien Java es de los lenguajes más populares, va a perder comunidad, que se va a desplazar a otros lenguajes más cómodos. Pero será muy gradual debido a la misma razón que PHP, muchas empresas seguirán usando Java un tiempo

Ruby
Ruby va a ser más importante sobre todo en scripting local, y quizá algo menos en web. La razón es que Ruby no aporta atractivas ventajas para las empresas al cambiar de PHP o Java a Ruby. Por eso creo que va a crecer más en scripting local, aunque posiblemente las startups usen Ruby para sus proyectos.

C y C++
Grandes proyectos seguirán usando C y C++ y muy dificilmente cambien. Los nuevos proyectos quizá se sientan menos atraídos por C++ teniendo Rust y Go, pero aguantará mucho.

C#
Crecerá. En cuanto la plataforma .NET se abra más a diferentes sistemas, el crecimiento será exponencial. Y ese es el rumbo que se está tomando con iniciativas como Xamarin o ASP.NET vNext, que han comunicado que será open-source y funcionará sobre Mono en Mac OS X y Linux.

Rust
Creo que este lenguaje va a dar mucho que hablar, no hoy, pero sí en un futuro a medio plazo. Rust aporta ventajas al venerado C++ y conserva su velocidad. Creo que Rust va a ocupar un lugar en los videojuegos, creo que en algún tiempo veremos algún Triple A hecho en Rust como lenguaje principal.

Seguiré con mis predicciones en otro post