¿Cuál es el lenguaje de programación más rentable y con mayor futuro en los próximos años?

Respecto de la primera parte de su pregunta, depende de lo que quiera decir por “rentable”.

Si por rentable quiere decir, el que normalmente genera programas “más optimizados” en términos de eficiencia energética, hay estudios que concluyen que ese lenguaje todavía sigue siendo C…

…seguido por C++ y Rust.

Si por rentable se refiere a qué lenguaje es “más productivo” para una software factory en términos de funcionalidad (FP) por línea de código (LoC) la firma QSM, experta en estimación, señala a Perl como el lenguaje con menor ratio de LoC por FP.

Sin embargo, como muchos ingenieros de software le dirán, las LoC estimadas es una métrica muuuuy engañosa. Para empezar, no cuesta lo mismo producir una línea de código en ensamblador que una línea de código en C, ni producir una línea de código en C que una línea de código en Haskell. Pero es que, además, las LoC tienden a producir sobreingeniería y costumbres muy poco higiénicas en los programadores a los que se mide su productividad en función de las LoC que generan semanalmente.

Una mejor métrica en términos de productividad (y que ayuda a mantener a los desarrolladores enfocados en el problema) es la de horas necesarias para entregar un punto de función (o un punto de historia de usuario). También se puede establecer ciertos valores típicos según el lenguaje elegido. Hace pocos años el conocido consultor e ingeniero de software Carpers Jones publicó su revisión del estado del arte en lo que se refiere a las métricas de medición de productividad en el desarrollo de software.

Para el tema que nos ocupa, la productividad según el lenguaje, véase la tabla 16 en la página 49.

Según esta tabla, el lenguaje de propósito general más productivo en términos de funcionalidad obtenida por hora de trabajo sería Smalltalk. Cuesta creer que Smalltalk, un lenguaje veterano, pero sin una gran popularidad al cabo de los años, sea tan productivo.

Pero así es. Probablemente tiene que ver con otras cuestiones como son el hecho de que los equipos que lo usan tienen gran experiencia en desarrollo ágil (fue el lenguaje que usaron los primeros que practicaron “metodologías” ágiles como XP), y que los entornos incluyen de serie una biblioteca enorme de componentes reusables y muy cercanos al lenguaje del problema. Y que admite técnicas de metaprogramación (programar programas que generan programas). Y que es un lenguaje extraordinariamente compacto con una sintaxis muy pequeña (con una biblioteca enorme, sí, pero el lenguaje en sí es ultracompacto).

No obstante, debe tenerse en cuenta que, en esa misma tabla 16, se puede observar como la forma más productiva de crear software son las herramientas que no requieren codificación o que requieren muy poca codificación (lo que se conoce como “no-code” y “low-code”). La más productiva resulta ser Integranova:

Esta tecnología es seguida por Excel, y por otras opciones del mundo 4GL normalmente asociadas a productos comerciales concretos como Forte, Telón y otros generadores de aplicaciones empresariales.

Si por rentable Vd. se refiere a “mejor pagado”… una reciente noticia publicada en Geeks4Geeks se publicó un ranking de los lenguajes mejor pagados (trabajando como autónomo).

El ganador (el que mejor se pagaba por hora) resultó ser Go.

Otra fuente de datos para una métrica similar la ofrece la encuesta anual de Stack Overflow que tiene un apartado dedicado a las tecnologías mejor remuneradas.

En este caso, el lenguaje mejor pagado resulta ser Clojure (un dialecto de Lisp para la JVM de uso minoritario, pero muy buscado en algunos entornos). Un detalle interesante: los cuatro lenguajes mejor pagados según esta última encuesta son todos ellos funcionales: Clojure, F#, Elixir y Erlang. Todos ellos son lenguajes que no aparecen en los primeros puestos del ranking de lenguajes más populares de Tiobe o de PYPL.

De hecho, casi podría concluirse que si Vd. se especializa en un lenguaje no muy popular, tendrá mejores perspectivas de ganar un mejor salario que si se decide por una carrera más “convencional”. Aunque supongo que tendrá que estar dispuesto a moverse ya que es muy probable que solo algunas pocas empresas demanden la tecnología.

Respecto su segunda pregunta: el futuro… mi predicción es que en el futuro (a más de 10 años vista) la programación de ordenadores no se parecerá en nada a lo que es hoy día. Para empezar, los lenguajes de programación en gran medida desaparecerán, se difuminarán y/o se harán más integrables unos con otros a través de las IA de codificación, y entornos interactivos multileguaje en los que el programador tendrá libertad para pasar de un lenguaje a otro con la misma facilidad que un cirujano cambia de un bisturí ultrasonico a uno eléctrico o a uno de diamante (o un mecánico cambia de una llave del 3 a una del 5). Los programadores usarán sistemas auxiliares que permitirán rebajar notablemente la curva de aprendizaje de cada formalismo (Github Copilot solo es la punta del Iceberg que está por llegar). Programar sin programar será una realidad, y el valor añadido del programador no será el conocimiento de un lenguaje concreto, sino el conocimiento del negocio, y de las técnicas y formalismos matemáticos (estadística, técnicas de optimización, algoritmos evolutivos, aprendizaje profundo, conocimientos financieros, técnicas de especificación formal, etc.). Mención aparte, la computación cuántica, que todavía no tengo ni idea de qué perfiles necesitará, pero requerirán seguro matemáticas. Las posiciones de desarrollador C o de desarrollador Java… y también las de desarrollador Clojure o desarrollador Go… e incluso las de desarrollador de Integranova (en el sentido que hoy las consideramos perfiles profesionales) habrán quedado tan obsoletas como la del antiguo aguador o la del sereno o la más reciente que ejerció mi abuelo: contable (de los de manguitos y libros en papel). Sinceramente, para entonces espero estar jubilado.