¿Están evolucionando los lenguajes de programación para parecerse más a Lisp?

No, realmente no.

No hay casi nada análogo a las expresiones s en nada que no sea un dialecto de Lisp; compare TCL, pero ese lenguaje no es reciente.

La metaprogramación de plantillas, a veces incluso con cuasiquotación, existe en otros lugares, pero es tan incómoda, en ausencia de algo análogo a la gramática de dos capas que proporcionarían las expresiones s, que se usa solo cuando es absolutamente necesario y, por lo general, no se puede mantener; en particular, observe la situación en Haskell.

La administración automática de memoria es un tema de interés continuo y renovado, pero la recolección de basura se ve con desconfianza; La inferencia automática de región, la propiedad y los calificadores de por vida en los tipos de puntero y el recuento de referencias son las áreas activas de desarrollo. Puede verlos en C ++ y Swift. Contrastar Go y Rust, pero en ambos, GC es opcional, con la gestión manual como una opción para, por ejemplo, el desarrollo del kernel, donde este es un requisito.

Las funciones de orden superior ciertamente se han puesto de moda, por lo que me inclino a dar crédito a JavaScript y darle una mención honorífica a Python. Tampoco es un idioma reciente, pero es agradable ver que finalmente se acepta. Claramente, por supuesto, Lisp fue el sitio de la invención original, por lo que este es un sí parcial.

En cuanto a los modelos de objetos, Smalltalk sigue reinando supremamente; muchos dialectos de Lisp tenían excelentes versiones, y Common Lisp merece una mención especial por el protocolo Meraobject innovador y completamente descartado por la historia. Pero los objetos, por supuesto, se originaron con Smalltalk.

La semántica limpia y las API de sistema bien diseñadas también se citan con frecuencia como virtudes de Lisp, pero también se afirman en cualquier otro lenguaje serio. Estas serían afirmaciones objetivamente definidas y comprobables si a alguien le importara; nadie lo hace.

Con todo lo dicho, espero que el mensaje de la gente sea que hay acontecimientos interesantes que suceden más allá de Lisp, y en direcciones que nunca fueron. Señalaría las clases de tipos como se usan en Haskell y ML, y los tipos dependientes para la programación práctica con verificación formal, como en Idris.

Lisp era un excelente lenguaje. Ha sido rechazado repetidamente por muchos programadores, a menudo por razones legítimas. Ya es hora de tomar las lecciones que hay en sus restos y seguir adelante.

No lo creo. En todo caso, se están volviendo más como Smalltalk, combinando objetos con lambdas. Python es una especie de excepción. Toma características de algunos idiomas diferentes, incluido Lisp, pero parece tomar la mayor parte de su influencia de Perl.

Lo que más caracteriza a Lisp es el procesamiento de listas. El código con el que trabaja está incrustado dentro de una estructura, y ofrece una forma consistente de acceder a cualquier cosa dentro de esa estructura. No son solo líneas de texto. La gente podría decir que esto no es diferente de cualquier otro idioma, ya que también operan dentro de las estructuras, pero lo que hace diferente a Lisp es que tienes acceso a esa estructura dentro del lenguaje. Ciertos lenguajes dan la capacidad de modificar la estructura del código que se está ejecutando, fuera de las “reglas normales”, llamadas metaprogramación, y Lisp es una de esas. Algunos lenguajes modernos han tenido capacidades de metaprogramación, pero por lo que he visto son torpes, como si fueran añadidos a posteriori. Tenemos mucho camino por recorrer antes de que coincidan con la elegancia de algunos idiomas antiguos como Lisp y Smalltalk.

No.

Los lenguajes de programación hace tiempo que tomaron prestadas todas las buenas ideas de Lisp (recolección de basura, tipeo fuerte, REPL, cierres …) y descartaron las malas ideas (sintaxis homoicónica, macros de estilo Lisp, tipeo dinámico).

Realmente no. No se puede “evolucionar” hacia una estructura similar a Lisp, tiene que estar allí desde el principio. Algunos trucos secundarios útiles, como lambdas y cierres, se pueden agregar a la mayoría de los idiomas sin mucho trabajo adicional, pero un cambio completo simplemente no es posible.