Cómo elegir un lenguaje de programación

La semana pasada mantuve una entretenida discusión en twitter con Sergio Navarro (@jersiovic) sobre TypeScript y Javascript que, como tantas otras veces, acabó derivando en tipado dinámico vs tipado estático, pero lo interesante es la cuestión subyacente, ¿por qué elegimos un lenguaje de programación u otro? ¿Qué factores afectan (o deberían afectar) a esa decisión?

Muchas veces el lenguaje que usamos viene impuesto por la empresa en que trabajamos, la plataforma que usamos o el proyecto concreto, pero cuando podemos decidir qué lenguaje utilizar, hay varios factores que es importante tener en cuenta.

El equipo de desarrollo

Por desgracia para algunos, al final, hay un equipo de desarrollo formado por personas que tienen que usar el lenguaje. En un mundo ideal, estas personas serían expertos en cualquier tipo de lenguaje, pero en la vida real, todos tenemos lenguajes que manejamos mejor que otros.

Aunque un lenguaje pueda parecer mucho más productivo que otro, si hace falta invertir 6 meses en formar al equipo de desarrollo, la productividad media del proyecto baja considerablemente.

El peligro de esta política es que no se puede mantener en el tiempo. Esto es darwinismo en estado puro, si el equipo de desarrollo no evoluciona y se adapta para usar mejores herramientas, no sobrevivirá.

Hace falta buscar un equilibrio entre efectividad hoy y evolución. Siempre se pueden introducir lenguajes nuevos en proyectos menos arriesgados, en pequeñas partes del sistema… hay formas de conseguirlo y merece la pena.

El proyecto

Hablo de proyecto en el sentido más amplio de la palabra. Puede ser un gran proyecto para un cliente concreto, el desarrollo de un producto o la creación de unos scripts para uso interno, pero en todos los casos hay que tener en cuenta los requisitos concretos: la plataforma, el problema, los plazos de ejecución, etc.

La plataforma es un factor muchas veces determinante, aunque sólo sea para acotar los lenguajes disponibles. Si tenemos que automatizar procesos batch en un servidor linux, está claro que Powershell no es una buena idea. Sin embargo, si el servidor es un Windows Server, puede ser la solución ideal.

El problema a resolver va a marcar también el tipo de aplicación a realizar y eso tiene una influencia clara en la elección del lenguaje. No creo que haya muchas aplicaciones para iPhone en Erlag, pero a Whatsapp le va bien con Erlang.

El futuro

Por definición, el futuro es incierto, por lo que sacrificar el presente en aras de un futuro que tal vez no llegue no es una actitud recomendable. Es algo que hemos aprendido de las metodologías ágiles y su YAGNI.

Sin embargo, es necesario tener una visión a medio/largo plazo de lo que queremos conseguir, puesto que habrá decisiones que pueden ser complicadas de revertir y es mejor tratar de no cerrarnos puertas anticipadamente.

Un ejemplo claro son las aplicación para móviles. Aunque inicialmente sólo nos enfoquemos en una plataforma, por ejemplo iOS, puede que más tarde tengamos previsto distribuir también la aplicación sobre Android. En ese caso, hay lenguajes que son más fáciles de portar entre plataformas y por tanto deberíamos tenerlos en cuenta.

Además, hay ocasiones en que merece la pena hacer un esfuerzo por aprender una nueva tecnología si consideramos que va a suponer una ventaja estratégica de cara al futuro. Aunque pueda suponer un retraso en un proyecto concreto, esta inversión en conocimiento puede significar la diferencia entre morir con una plataforma o dar el salto a la siguiente (recuerdo empresas que desarrollaban tenían ERPs para MS-DOS y no dieron el salto a tiempo a Windows).

El propio lenguaje

Puede resultar curioso, pero creo que las características del propio lenguaje no son tan críticas a la hora de decidir usarlo o no. Si es dinámico o estático, orientado a objetos o funcional, compilado o intepretado; son factores importantes, pero sin el contexto que establecen los puntos anteriores, no ayudan demasiado a tomar una decisión.

Hay una expresión muy popular que es “para el que tiene un martillo, todo parecen clavos”. La respuesta a esto suele ser que hay que usar “la herramienta adecuada para el trabajo”.

El lenguaje no deja de ser una herramienta más a la hora de desarrollar software. Muy importante, sí, pero una herramienta. Hay que buscar la herramienta que se ajuste a las necesidades de cada momento, pero con un poco de sentido común.

A veces es mejor usa una herramienta un poco peor, que acabar con una caja de herramientas enormes en la que no encuentras nada, y mezclar en un proyecto 17 lenguajes sólo porque son “un poco mejores” para desarrollar cada módulo, puede resultar excesivo, especialmente si usan paradigmas de programación distintos y te obligan a cambiar de forma de pensar cada vez que pasas de un lenguaje a otro.

Lo que sí es muy importante es el soporte del lenguaje. Las herramientas que hay alrededor de él, la documentación, la comunidad, la madurez, las expectativas de vida. Iniciar un proyecto en un lenguaje supercool que está en alpha y no se sabe si sobrevivirá, es un suicidio.

Conclusiones

Aunque haya centrado el post en los lenguajes de programación, los factores son aplicables a otras decisiones tecnológicas (frameworks, librerías, plataformas, etc.)

Excepto algún caso crítico, como que un lenguaje no esté soportado por tu plataforma objetivo, ninguno de los factores es determinante por si mismo y han de ser analizados todos de forma conjunta.

No tiene mucho sentido hablar de lenguajes mejores o peores en términos absolutos.

Establece un contexto, comprende tus necesidades, tus conocimientos y tus limitaciones, y en base a eso toma una decisión. Es más complicado que ser un fanboy de un lenguaje (o un estilo de programación) concreto, pero también es más práctico.


Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

*

Puedes usar las siguientes etiquetas y atributos HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>