Por qué siempre necesitaremos nuevos lenguajes de programación

Estructura e interpretación de programas de computadora de Harold Abelson y Gerald Jay Sussman es uno de los mejores libros sobre programación jamás escritos. Se adelantó a su tiempo durante muchos años.

Las ventajas de la programación funcional que se destacaron todavía son una fuente constante de inspiración para ponentes, profesores y otros escritores. Mostró el poder y los defectos de la programación orientada a objetos cuando aún era joven. Los poderes se anuncian rápidamente gracias a los fanáticos de la programación orientada a objetos. Por otro lado, la comunidad tardó años en ver las fallas.

El último capítulo estuvo íntegramente dedicado a otro concepto que todavía no se discute mucho en el diálogo popular: la necesidad de nuevos lenguajes de programación. Aunque el libro simpatizaba con Lisp, claramente afirmó que no es el lenguaje de programación final. Ningún idioma lo será jamás.

Siempre necesitaremos nuevos lenguajes de programación para mejorar nuestra expresividad. Esta no es una afirmación trivial, y para comprender qué hay detrás, debemos bajar dos niveles.

¿Qué es un lenguaje de programación?

Ver la siguiente función:

fun square(a: Int) = a * a
// Usageprint(square(10) + square(20))

¿Qué significa que squareestá definido?

Desde un punto de vista técnico, es solo una simplificación y el cuerpo puede reemplazar todas las llamadas:

// Kotlinprint(10 * 10 + 20 * 20)

Desde el punto de vista del programador, squarees mucho más. El hecho de que podamos definir tal función no solo es una forma más sencilla de realizar una operación, sino que también nos permite expresar un concepto de cuadratura. Esta función es una abstracción.

Si fuera más complejo, nos permitiría ocultar toda esta complejidad detrás de una simple llamada a función. Esto es lo que es la programación: las diferentes características del lenguaje de programación nos permiten expresar las cosas de diferentes maneras.

Evolución de los lenguajes de programación

La industria de la programación evoluciona, y también lo hacen los lenguajes de programación. Piense en el ciclo for. Inicialmente, solo había un bucle cuando.

Pronto, los programadores notaron un patrón común:

// Cint i = 0;while(i < n) { i++; // ...} 

La whileexpresión se usó una y otra vez para iterar sobre algo, principalmente números, direcciones o iteradores.

Así que presentamos bucles for:

// C++for (int i = 0; i < n; i++) { // ...}

Pronto, la industria observó que el bucle for se usa principalmente para iterar sobre elementos de una lista.

Es por eso que los lenguajes introdujeron una nueva variante de bucle for que está diseñada para iterar sobre list:

// Kotlinfor(e in list) { // ...}

Entonces necesitamos nuevas funciones

Pero los idiomas evolucionan, ¿por qué no seguir con ellos?

Es cierto que los idiomas evolucionan. En algunos casos, es realmente impresionante cómo lenguajes antiguos como C ++, Java o JavaScript pueden tener un buen soporte para elementos de programación funcional para los que no fueron diseñados. Pero el problema es que las nuevas funciones no reemplazan a las antiguas, sino que se agregan.

En términos de características del lenguaje de programación, más no es necesariamente mejor. Es confuso cuando podemos expresar el mismo concepto de muchas formas diferentes.

Piense en Scala. La mayor objeción con Scala es que demasiadas características diferentes hacen que sea extremadamente difícil entender lo que está sucediendo en el código de un desarrollador con demasiada creatividad.

El lenguaje de programación Go construyó su popularidad sobre la base de la simplicidad. No se trata de cuántas funciones tienen algunos idiomas, sino de tener el conjunto perfecto de funciones.

En mi opinión, es por eso que todo el mundo ama tanto a Kotlin. Es el lenguaje de programación mejor diseñado que conozco.

Hay fuertes razones para ello:

  • Estuvo en beta durante 6 años y fue evolucionando iterativamente durante todo ese tiempo.
  • Está diseñado por JetBrains que ha estado dominando su comprensión de los lenguajes de programación y cómo la gente los usa durante años.

Durante el período beta, se implementaron completamente algunas características importantes y, sin embargo, se eliminaron antes de la versión 1.0. Entre ellos se encuentran las tuplas. ¡Kotlin los apoyó plenamente! Sin embargo, el equipo de Kotlin eliminó el soporte para tuplas antes de Kotlin 1.0 porque su análisis y experimentos mostraron que las tuplas hacen más daño que bien, y la gente debería usar clases de datos en su lugar. Esto demuestra que JetBrains comprende la importancia de un buen diseño.

Otro lenguaje que está bien diseñado es Swift. Se desarrolló mucho más rápido y los desarrolladores que lo estaban diseñando cometieron muchos errores. Sin embargo, Apple acaba de cambiar el diseño con casi todas las versiones principales. Realmente no les importa el legado.

Los desarrolladores se quejan, pero desde el punto de vista del diseño, es genial. Aunque no pueden seguir haciendo eso por mucho tiempo. Cuantas más cosas haya en Swift, mayor será el costo del cambio de diseño. Además, no creo que puedan cambiar funcionalidades importantes.

Entonces, si tenemos nuevos lenguajes bien diseñados, ¿son los lenguajes finales?

De ningún modo. Las industrias evolucionan. Nuestro pensamiento evoluciona. Y, por tanto, los lenguajes de programación también deben evolucionar.

Una cosa es que nacerán ideas para nuevas funciones y formas de pensar, por lo que los lenguajes perfectamente diseñados ya no serán perfectos.

Lo segundo es que aprendemos más sobre programación. Las clases y métodos están abiertos de forma predeterminada en Java. Kotlin hizo que ambos fueran finales de forma predeterminada porque los desarrolladores usaban en exceso la herencia cuando no deberían haberlo hecho.

Los miembros de la clase Java eran paquetes privados de forma predeterminada. Este modificador casi nunca se usó. Kotlin no lo permite en absoluto, pero los miembros de la clase son públicos de forma predeterminada porque este es el modificador más común para ellos. Cambiamos nuestros hábitos y aprendemos, por eso también los idiomas deberían cambiar con nosotros.

La tercera cosa es que los paradigmas cambian. Veo estancamiento en términos de paradigmas de programación, pero todavía tenemos algunos que introducir en la práctica diaria.

¿A dónde fue la programación lógica? Tenga en cuenta que puede usar este paradigma y solo proporcionar un conjunto de restricciones para un sitio web y esperar que el sitio web se cree automáticamente en función de ellas. Es posible implementar eso. Además, tarde o temprano nacerán nuevos paradigmas. No puede ser que lo hayamos explorado todo.

Finalmente, nacen nuevas tecnologías y la vieja forma de pensar representada por los lenguajes anteriores puede no ser adecuada.

Piense en blockchain. Cuando hablo con personas que consideran cambiarse, quieren usar sus lenguajes favoritos como Java o JavaScript. Aunque cuando hablo con los desarrolladores de blockchain, afirman que blockchain debe desarrollarse en lenguajes diseñados para ello.

Por ejemplo, un contrato es un concepto que no tiene equivalente en programación. Puede ser simulado por clase, pero esto es perjudicial para la forma en que la gente piensa sobre él. Es perjudicial cuando intentamos expresar cosas nuevas con palabras antiguas. Es como llamar a un coche "caballo de acero" y tratar de hacer mecánicos de los veterinarios.

Clausura

Piense en las matemáticas. El equilibrio se puede expresar de forma descriptiva:

Dos más tres es igual a cinco

Aunque es algo totalmente diferente a expresarlo usando la notación matemática:

2 + 3 = 5

No es la única optimización de legibilidad y espacio. Estas dos notaciones significan lo mismo, pero representan conceptos totalmente diferentes. Esto es algo que no es importante desde el punto de vista de una computadora, que puede traducir fácilmente la forma descriptiva en matemática, pero es lo más importante para nosotros como humanos.

Si no fuera importante, operaríamos en Assembler en lugar de Java, JavaScript, Python o Kotlin. Pero es importante. Es por eso que necesitamos una expresión cada vez mejor, y necesitamos nuevos lenguajes de programación.

Sobre el Autor

Marcin Moskała (@marcinmoskala) es formador y consultor y actualmente se concentra en impartir Kotlin en Android y talleres avanzados de Kotlin (para obtener más detalles, solicite aquí). También es ponente, autor de artículos y un libro sobre el desarrollo de Android en Kotlin.