¿Cómo se inspira Java en Lisp?

Question

"Estábamos buscando los programadores de C++. Nosotros pudimos arrastrar muchos de ellos aproximadamente hasta la mitad de Lisp".

• de Guy Steele, co-autor del Java specspec

Fuente: http://www.paulgraham.com/icad.html

Contexto: http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg04045.html

me encontré con la cita anterior otro día. Obtuve muchas características exclusivas de java (sobre C++), como la recolección de basura que inicialmente se encontraron en Lisp. Pero ¿cómo más java arrastró a los programadores de C++ a mitad de camino a lisp?

Answer 1

Algunos aspectos de Java que lo hacen más "Lisp" que C++ son:

• recolección de basura
• tipo fuerte de seguridad
• reflexión
• sin preprocesador (pero Common Lisp hace tienen macros!)

EDITAR

Por cierto, cita de Guy Steele proviene de esta lista de correo publicación en 2003:

http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg04045.html

(Google es mi amigo :-))

Answer 2

Tomemos lista de viñetas famosa de Paul Graham y compara:

• condicionales: Java tiene condicionales. Bueno, C++ también los tenía.

• A Tipo de función: Java no tiene funciones de primera clase. C++ tampoco los tenía.

• Recursión: Java admite recursion. C++ lo apoyó también.

• Escritura dinámica: Java está tipado estáticamente. También lo fue C++.

• Garbage Collection: Java tiene una recolección de basura. C++ no.

• Programas compuestos por expresiones: Tanto Java como C++ hacen una distinción entre enunciados y expresiones. Entonces ambos no logran satisfacer este punto.

• A Tipo de símbolo: Ni Java ni C++ admiten esto como parte del lenguaje. Sin embargo, es muy fácil de implementar.

• Homoiconicidad: De nuevo, ni Java ni C++ son homocónicos.

• Todo el idioma existe todo el tiempo: No, de nuevo.

Así que lo único que se puede decir de Java toma más cerca de Lisp en comparación con C++ es la recolección de basura, lo que, en mi opinión, no es un argumento lo suficientemente convincente como para justificar la cita de Steele.

Conclusión: (subjetiva) La cita arriba indicada de Guy Steele es idiota. Período.

---

Una cita muy reveladora de comp.lang.scheme:

usted está enviando a un grupo Esquema. Por aquí, argumentar que Java es mejor que C++ es como argumentar que los saltamontes saben mejor que la corteza de árbol.
  — Thant Tessman, comp.lang.scheme

:-)

Answer 3

Hay más de unos pocos idiomas que pueden decir que se están moviendo hacia Lisp. Rígido Java no es uno de ellos.

Tuvo que haber sido una respuesta irónica o quizás estaba bajando de un doblador de 3 días.

Answer 4

Guy L. Steele es muy conocido en el mundo Lisp (que co-diseñó uno de los dos principales dialectos de Lisp en uso hoy en día) y al parecer fue invitado al grupo de diseño de Java en Sun después de la lengua había sido diseñado para escribir la especificación ya que era conocido por escribir buenas especificaciones para los idiomas existentes.

El "medio camino a Lisp" en mi mente no es tanto en la sintaxis del lenguaje Java (que modela C intencionalmente) como en la mentalidad de la JVM. "NO debes preocuparte por la recolección de basura". "No debes preocuparte por los punteros, excepto para los objetos de referencia". Estas cosas parecen naturales hoy en día, pero fueron herejes para algunos cuando salió Java.

Esto especialmente desde que Java fue increíblemente lento hasta Java 1.3, pero eso se debió a que valoraron la corrección más alta que la velocidad de implementación. En la actualidad, la mayoría de las implementaciones de Java son muy rápidas, pero a costa de la memoria.

Answer 5

El punto principal en la evolución de distancia de C++ hacia Java - desde una perspectiva Lisp - es el uso de la llamada 'memoria administrada':

• datos etiquetados
• recolección de basura precisa
• operaciones de bajo nivel seguras
• el uso de una máquina virtual con instrucciones específicas del lenguaje
• carga de código

Este modelo no era inusual en el mundo de Lisp, donde había implementaciones de software y hardware de máquinas virtuales con instrucciones específicas del lenguaje.

Por ejemplo, Interlisp de BBN y Xerox tenían una máquina virtual (en la década de 1970). También hubo estaciones de trabajo Interlisp (1970s-1980s) donde se proporcionó el conjunto de instrucciones en el nivel del procesador (microcodificado). Las instrucciones se verifican en tiempo de ejecución (does + have the right arguments). Esto también es muy similar a lo que usaba un tiempo de ejecución en Smalltalk. Los sistemas Xerox Smalltalk e InterLisp se ejecutaban en el mismo hardware, pero con diferentes microcódigos.

Eso significa que uno puede buscar en un depurador en los datos JVM y el depurador siempre sabe qué tipos primitivos hay. La reflexión puede usarse para obtener información. Esto es similar a cómo se puede mirar en Lisp con un depurador en los objetos. En C++ esto solo es posible cuando hay información de depuración presente, que generalmente solo es el caso durante el desarrollo.

Por lo tanto, la JVM se parece en cierto modo a un 'tiempo de ejecución' típico de Lisp.

Eso es diferente con C++, donde los datos de C++ son bits de bajo nivel (generalmente) y no había 'memoria administrada'.

James Gosling (el "padre" de Java) sabía un poco sobre Lisp desde la implementación de Gosling Emacs en C en Unix a principios de la década de 1980. Su Emacs tenía un dialecto de Lisp extraño para extender el editor: Mocklisp.

Aparte de eso, Java y Lisp son muy diferentes, por lo que 'a mitad de camino' puede no ser el caso, pero ayudó, por ejemplo, a superar la hostilidad contra algo como 'recolección de basura'. Desafortunadamente, especialmente en los primeros tiempos de Java, Java y JVM también estaban sobre promocionados y después de un tiempo los problemas de rendimiento se volvieron obvios. Esa fue una razón para la muerte de las aplicaciones de escritorio que eran lentas (tiempo de inicio lento, tiempo de respuesta lento, ...).

Answer 6

No creo que Java sea muy Lisp-ish, pero C++ es incluso menos Lisp-ish. Como ejemplo, considere esta invocación a CollectionUtils.filter():

void foo(final int n) { 
    CollectionUtils.filter(collection, new Predicate() { 
     public boolean evaluate(Object input) { return input.equals(n); } 
    }); 
} 

Encuentro este estilo más Lisp-ish que la versión equivalente de C++:

void foo(int n) { 
    // C++ does not have anonymous classes in the Java sense, so 
    // we need a separate definition 
    struct Predicate { 
     // This class does not have access to variables defined 
     // in the enclosing scope, so we need to explicitly pass 
     // whatever we need 
     int n; 
     Predicate(int n) : n(n) { } 

     bool operator()(int x) { return x == n; }  
    }; 

    CollectionUtils::filter(collection, Predicate(n)); 
}