¿Alguien puede explicarme las decisiones de diseño detrás de Autpolisp/visual lisp?

Question

Me pregunto si alguien puede explicar el razonamiento del diseño detrás de las siguientes características de autpolisp/visual lisp? Para mí, parecen estar en contra de la práctica de software aceptada ... ¿me estoy perdiendo algo?

• Todas las variables son globales por defecto (es decir, a no ser que se coloca después de un / en los argumentos de la función)
• de datos de lectura/escritura de AutoCAD requiere poner cosas en una lista de asociación con una gran cantidad de números mágicos. 10 medios coordenadas x/y, 90 significa longitud de la lista de coordenadas, 63 significa color, etc. Ok podría almacenar estos en algunas constantes pero eso significaría aún más globales, y la documentación que anima a usar los números mágicos directamente.
• Lisp es un lenguaje de estilo funcional, lo que anima a la programación por recursión sobre iteración, pero la recursión de cola que yo sepa, no se ha optimizado en Visual LISP que conduce a las pilas de llamadas horrendos - a menos que, por supuesto iterar. Pero la sintaxis de bucle es muy restrictiva; p.ej. no puede salir o devolver un valor de un bucle a menos que coloque algún tipo de indicador en la condición de terminación. Resultado, código feo.
• Generalmente se ven obligados a declarar las variables de todo el lugar que va en contra de la programación funcional - ¿por qué utilizar un lenguaje funcional (ish)?

Answer 1

Lisp no es un lenguaje, es un group of sometimes surprisingly different languages. Scheme y Clojure son los miembros funcionales de la familia. Common Lisp, y las razas más especializadas como Elisp no es particularmente funcional y no fomenta inherentemente la programación funcional o la recursión. CL de hecho, incluye un very flexible object system, un extremely flexible iteration DSL, y no garantiza llamadas de cola optimizadas (los dialectos del esquema sí, pero no los Lisps en general; ese es el peligro de pensar en "Lisp" como un solo idioma).

Ahora que tenemos eso aclarado, AutoLisp es una implementación de 1986 basada en una versión anterior de XLISP (la primera de las cuales se publicó en 1983).

La razón por la que podría volar frente a la práctica de programación actualmente aceptada es que es anterior a la práctica de programación actualmente aceptada. Otra cosa a tener en cuenta es que la netbook más barata disponible actualmente es several hundred times más potente de lo que un programador podría esperar tener acceso a mediados de los 80. Lo que significa que incluso si se acepta que una característica dada es excelente, las limitaciones de la CPU o de la memoria pueden haber impedido su implementación en un lenguaje comercial.

Nunca he programado en Autolisp/Visual Lisp específicamente, y las cosas que cita suenan bastante molestas, pero puede haber tenido alguna ventaja de rendimiento/memoria que lo justificaron en ese momento.

Answer 2

Si no recuerdo mal, de AutoLisp es un tenedor de una primera versión de XLISP (algunas fuentes afirman que fue XLISP 1.0 (ver this C2 article).

XLISP 1.0 es un ceceo 1-celular (funciones y variables compartir el mismo espacio de nombres) con algunas rarezas bastante extraño a ella.

Answer 3

Puede agregar dynamic scoping en la mezcla por cierto, y si no sabe lo que es, considérese afortunado.Pero en realidad no todos sus cuatro puntos son tan grande de un acuerdo de la OMI:

• "vars no declarados se crean automáticamente como global". Igual que en CL ¿no es así (a través del setq)? La otra opción es fallar, y eso no es muy atractivo para el lenguaje que se supone debe usarse para scripting rápido y sucio.

• "números mágicos" son códigos DXF, lo que es correcto son un gran inconveniente ya que tienden a cambiar con las versiones cambiantes de ACAD a veces (afortunadamente, rara vez). Así es como es. Repararlo requeriría una revisión general, presentando algunos "esquemas" y lo que no, ¿y por qué "ellos" se molestarían? AutoLISP se dejó en su estado a partir de 1992 aproximadamente, y nunca se molestó desde entonces. Visual LISP en sí mismo es un sistema totalmente diferente y mucho más capaz, pero está bloqueado para el usuario normal y solo sirve para cumplir un objetivo: emular el AutoLISP antiguo tan fielmente como sea posible (excepto cuando agrega nuevas funciones relacionadas con VBA). en la segunda mitad de la década de 1990, y estuvo bloqueado desde entonces también).

• (while (not done) ...) no es que ugly. No hay garantía de optimización de cola, sí, del mismo modo que no hay ninguna en CL y Haskell (la última realmente me tropieza, no hay forma garantizada de codificar un ciclo en Haskell en espacio constante sin mónadas, ¿qué tal?).

• "estás obligado a declarar vars por todas partes" aquí no te sigo. Usted los declara si supuestamente los declara, en la lista de argumentos internos de la función. ¿A qué otros lugares te refieres? No sé de ninguno.

En realidad, el mayor obstáculo de AutoLISP es su dinámica de resolución de nombres de la OMI, pero eso es lo que era en XLISP, solamente unos pocos años después de Esquema salió por primera vez. Entonces también es su almacén de datos inmutable, pero eso se hizo principalmente por simplicidad de implementación, y para evitar demasiada confusión y, por lo tanto, preguntas, desde la base de usuarios, supongo.