PREGUNTAS FRECUENTES SOBRE ARC
¿Dónde lo consigo?
Arclanguage.org.
¿Por qué necesitas diseñar un nuevo lenguaje?
Sería sorprendente si no tuviéramos todavía necesidad de diseñar más lenguajes. Esto equivaldría a decir que el diseño de lenguajes de programación es ahora un problema resuelto, y que el lenguaje final, perfecto, ha sido diseñado. A mi no me parece asi— y por mucho. La cantidad de preguntas aún sin resolver hace que mi cabeza dé vueltas.
¿Por qué se llama Arc?
El nombre es una referencia a la programación de abajo-hacia arriba. Esto significa personalizar el lenguaje para adaptarse a tu aplicación, produciendo un programa con la forma de un arco, en lugar de un dintel. Dado que la brevedad es otro de los objetivos, nos deshicimos de la h.
¿Por qué conservaste car y cdr?
Debido a que no se nos ocurrio alguna alternativa mejor. Hubiera sido engañoso utilizar, first y rest o head y tail, porque las cons son básicamente pares; las listas son una cosa que puedes construir con ellas, pero no lo único.
En el Inglés no hay un nombre convencional para la primera y segunda mitad de un par. Si tienes que inventar nombres, car y cdr son opciones muy buenas, porque son cortas y de la misma longitud y naturalmente utiles para componer (por ejemplo: cadr).
¿Arc es orientado a objetos?
La frase "orientado a objetos" significa muchas cosas. La mitad son evidentes, y la otra mitad son errores.
Creemos que Lisp debe permitirte definir nuevos tipos que sean tratados igual que los tipos incorporados— en la misma forma que te permite definir nuevas funciones que son tratadas igual que las funciones incorporadas. No creemos que cada programa deba consistir en la definición de nuevos tipos.
¿Por qué no utilizar algún otro delimitador en lugar de paréntesis?
Probamos varias posibilidades. Corchetes y llaves pierden porque son menos direccionales que los paréntesis (izquierda y derecha se diferencian en menos píxeles); < y > pierden porque no se ajustan lo suficiente para incluir expresiones más largas que tokens.
¿No sera que permitir <new possibility> confunda a la gente que lee el codigo?
Ejemplo (a i) podría ser una llamada a función o una referencia a la matriz.
Si haces mas breve un lenguaje, tienes necesariamente más posibilidades de lo que podría significar una expresión. Por ejemplo, debido a que las funciones son un tipo de datos en Lisp, alguien nuevo en Lisp podría quejarse de que no puede saber si un parámetro x es una función o un entero. Esto es una consecuencia inevitable de hacer un lenguaje más potente. Es responsabilidad del programador (como siempre) evitar usar el lenguaje de una manera que confunda a los lectores.
¿Por qué no construir Arc sobre Java/Parrot /.NET?
Estamos tratando de hacer algo a largo plazo en Arc, algo que sea útil para la gente, en, digamos, 100 años. (Si esto suena loco, recuerda que ya estamos en el 50.) Así que (a) no tenemos prisa en ahorrar esfuerzos; cuando estás tratando de hacer algo que dure 100 años, hay mucho tiempo para trabajar en ello, y (b) no queremos adherirnos a cualquier cosa que no sea intemporal, para que todo el proyecto se enrosque como una tuerca.