Filosofía orientadora
1. Lenguajes de programación para personas
Los lenguajes de programación son cómo las personas hablan con las computadoras. La computadora estará encantada de hablar cualquier idioma que no sea ambiguo. La razón por la que tenemos lenguajes de alto nivel es porque las personas no pueden manejar el lenguaje de máquina. La esencia de los lenguajes de programación es evitar que nuestro pobre y frágil cerebro humano se sobrecargue con una gran cantidad de detalles.
Los arquitectos saben que algunos problemas de diseño son más mundanos que otros. Uno de los problemas de diseño más claros y abstractos es el diseño de puentes. En este caso, su trabajo es cubrir la distancia requerida con la menor cantidad de material posible. En el otro extremo del espectro está el diseño de sillas. Los diseñadores de sillas deben pasar su tiempo pensando en los culos humanos.
El desarrollo de software tiene una diferencia similar. El diseño de algoritmos para enrutar datos a través de una red es un buen problema abstracto, como el diseño de puentes. Mientras que diseñar lenguajes de programación es como diseñar sillas: necesita hacer frente a las debilidades humanas.
A la mayoría de nosotros nos cuesta mucho darnos cuenta de esto. Diseñar sistemas matemáticos elegantes suena mucho más atractivo para la mayoría de nosotros que caer en las debilidades humanas. El papel de la elegancia matemática es que cierto grado de elegancia hace que los programas sean más fáciles de entender. Pero todo no se limita a la elegancia.
Y cuando digo que los idiomas deben estar diseñados para tener en cuenta las debilidades humanas, no quiero decir que los idiomas deben estar diseñados para programadores malos. De hecho, debe diseñar software para los mejores programadores, pero incluso los mejores programadores tienen sus límites. No creo que al menos a alguien le guste programar en un lenguaje donde todas las variables se denoten con la letra "x" con índices enteros.
2. Diseña para ti y para tus amigos
Si observa la historia de los lenguajes de programación, la mayoría de los mejores lenguajes han sido diseñados para ser utilizados por sus propios autores, y la mayoría de los peores han sido diseñados para otras personas.
Cuando los idiomas están diseñados para otras personas, siempre es un grupo específico de personas: las personas no son tan inteligentes como los creadores del idioma. Entonces obtienes un idioma que te habla condescendientemente. Cobol es el ejemplo más claro, pero la mayoría de los idiomas están imbuidos de este espíritu.
Esto no tiene nada que ver con qué tan alto es el idioma. C es de nivel bastante bajo, pero fue creado para ser utilizado por sus autores, por lo que a los piratas informáticos les encanta.
El argumento para diseñar lenguajes para programadores malos es que hay más programadores malos que buenos. Quizás esto sea así. Pero este pequeño número de buenos programadores escribe desproporcionadamente más software.
Me interesa la cuestión de cómo crear un lenguaje que guste a los mejores hackers. Creo que esta pregunta es idéntica a la pregunta de cómo crear un buen lenguaje de programación, pero incluso si no lo es, al menos es una pregunta interesante.
3. Dele al programador el mayor control posible
Muchos idiomas (especialmente los creados para otras personas) se comportan como niñeras: intentan advertirte de cosas que, en su opinión, no te serán útiles. Tengo la opinión opuesta: dale al programador tanto control como puedas.
Cuando estudié por primera vez a Lisp, lo que más me gustó fue que hablamos en igualdad de condiciones. En otros idiomas que había estudiado en ese momento, había un idioma, y estaba mi programa en ese idioma, y existían por separado. Pero en Lisp, las funciones y macros que escribí fueron las mismas en las que se escribió el lenguaje. Podría reescribir el lenguaje en sí mismo si quisiera. Tenía el mismo atractivo que el software de código abierto.
4. Brevedad: la hermana del talento
La brevedad se subestima e incluso se desprecia. Pero si observa los corazones de los hackers, verá que les encanta la brevedad. ¿Cuántas veces has escuchado a los hackers decir amorosamente que, digamos, en la APL, pueden hacer cosas increíbles con solo un par de líneas de código? Creo que a las personas realmente inteligentes les gusta prestar atención a esto.
Creo que casi todo lo que acorta los programas es bueno. Debería haber muchas funciones de biblioteca, todo lo que puede ser implícito, debe ser así; la sintaxis debería ser más concisa; incluso los nombres de las entidades deben ser cortos.
Y no solo los programas deben ser cortos. Los manuales también deben ser cortos. Una buena parte de los manuales está llena de explicaciones, renuncias, advertencias y casos especiales. Si necesita acortar el manual, la mejor opción es arreglar un idioma que requiere tantas explicaciones.
5. Reconoce lo que es hackear.
A muchas personas les gustaría que la piratería sea matemática, o al menos algo similar a las ciencias naturales. Creo que piratear es más como arquitectura. La arquitectura está conectada con la física, en el sentido de que el arquitecto necesita diseñar un edificio que no se caiga, pero el objetivo real del arquitecto es crear un gran edificio y no hacer descubrimientos en el campo de la estática.
Lo que les encanta a los hackers es crear excelentes programas. Y creo que, al menos en nuestros propios pensamientos, debemos recordar que escribir programas maravillosos es maravilloso, incluso cuando este trabajo no se traduce fácilmente en la moneda intelectual ordinaria de los trabajos científicos. Desde un punto de vista intelectual, es igualmente importante cómo desarrollar un lenguaje que los programadores adoren, y crear un lenguaje terrible que incorpore la idea sobre la cual puedes publicar un artículo.
Problemas abiertos
1. ¿Cómo organizar grandes bibliotecas?
Las bibliotecas se están convirtiendo en una parte importante de los lenguajes de programación. Se vuelven tan grandes que puede ser peligroso. Si lleva más tiempo encontrar una función en la biblioteca que haga lo que necesita, que escribir esta función usted mismo, entonces todo el código no hace más que engrosar su manual. (Los manuales simbólicos fueron un ejemplo). Entonces tenemos que resolver el problema de organizar bibliotecas. Lo ideal es diseñarlos de manera que el programador pueda adivinar qué función de biblioteca es adecuada.
2. ¿La gente realmente teme por la sintaxis del prefijo?
Este es un problema abierto en el sentido de que lo he estado pensando durante varios años y todavía no sé la respuesta. La sintaxis del prefijo me parece completamente natural, posiblemente además de usarla en matemáticas. Pero puede ser que la mayor parte de la impopularidad de Lisp se deba simplemente a una sintaxis desconocida ... ¿Hay algo que ver con esto? Si es cierto, esta es otra pregunta.
3. ¿Qué necesitas para el software del servidor?
Creo que la mayoría de las aplicaciones que se escribirán en los próximos veinte años serán aplicaciones web, en el sentido de que los programas se ubicarán en el servidor y se comunicarán con usted a través de un navegador web. Y para escribir tales aplicaciones necesitamos cosas nuevas.
Una de estas cosas es admitir una nueva forma de liberar aplicaciones de servidor. En lugar de una o dos versiones principales por año, como el software de escritorio, el software del servidor se lanzará en una serie de pequeños cambios. Puede tener cinco o diez lanzamientos por día. Y todos siempre tendrán la última versión.
¿Sabes cómo diseñar programas para ser compatibles? El software del servidor debe estar diseñado para ser adaptable. Debería poder cambiarlo fácilmente, o al menos saber qué significa un cambio menor y qué es importante.
Otra cosa que puede ser útil en el software del servidor es, de repente, la continuidad de la entrega. En una aplicación web, puede usar algo como
CPS para obtener el efecto de las rutinas en el mundo sin estado de las sesiones web. Puede que la continuidad de la entrega valga la pena si esta oportunidad no es demasiado cara.
4. ¿Qué nuevas abstracciones quedan por abrir?
No estoy seguro de cuán razonable es esta esperanza, pero personalmente me gustaría descubrir una nueva abstracción, algo que podría ser tan importante como las funciones de primera clase o la recursión, o al menos los parámetros predeterminados. Tal vez este es un sueño imposible. Tales cosas a menudo no se abren. Pero no pierdo la esperanza.
Secretos poco conocidos
1. Puedes usar el idioma que quieras
Anteriormente, la creación de aplicaciones significaba la creación de software de escritorio. Y en el software de escritorio hay un gran sesgo hacia la escritura de aplicaciones en el mismo idioma que el sistema operativo. Entonces, hace diez años, escribir software en su conjunto significaba escribir software en C. Al final, la tradición ha evolucionado: las aplicaciones no deben escribirse en lenguajes inusuales. Y esta tradición se ha desarrollado durante tanto tiempo que personas no técnicas, como gerentes y capitalistas de riesgo, también han aprendido esto.
El software del servidor destruye este modelo por completo. Con el software del servidor, puede tomar el idioma que desee. Casi nadie más entiende esto (especialmente los gerentes y capitalistas de riesgo). Pero algunos hackers entienden esto, por lo que hemos escuchado sobre lenguajes independientes como Perl y Python. No escuchamos sobre Perl y Python porque la gente los usa para escribir aplicaciones de Windows.
¿Qué significa esto para nosotros, personas interesadas en diseñar lenguajes de programación, que hay una audiencia potencial para nuestro trabajo?
2. La velocidad proviene de los perfiladores
Los desarrolladores de lenguaje, o al menos sus implementadores, adoran escribir compiladores que generen código rápido. Pero creo que esto no es lo que hace que los idiomas sean rápidos para los usuarios. Knut ha notado durante mucho tiempo que la velocidad depende de unos pocos cuellos de botella. Y cualquiera que haya intentado acelerar el programa sabe que no puede adivinar dónde está el cuello de botella. El perfilador es la respuesta.
Los desarrolladores de idiomas están resolviendo el problema incorrecto. Los usuarios no necesitan puntos de referencia para trabajar rápidamente. Necesitan un lenguaje que pueda mostrar qué partes de su programa deben reescribirse. En este punto, se necesita velocidad en la práctica. Por lo tanto, podría ser mejor si los implementadores del lenguaje pasan la mitad del tiempo que dedican a optimizar el compilador y lo pasan escribiendo un buen perfilador.
3. Necesitas una aplicación que desarrolle tu lenguaje
Tal vez esta no sea la verdad definitiva, pero parece que los mejores lenguajes se han desarrollado junto con las aplicaciones en las que se utilizaron. C fue escrito por personas que necesitaban programación del sistema. Lisp fue diseñado en parte para la diferenciación simbólica; McCarthy estaba tan ansioso por comenzar que comenzó a escribir programas de diferenciación incluso en el primer documento de Lisp en 1960.
Esto es especialmente bueno si su aplicación resuelve algunos problemas nuevos. Esto alienta a su idioma a tener nuevas funciones que los programadores necesitan. Personalmente, estoy interesado en escribir un lenguaje que sea bueno para las aplicaciones de servidor.
[Durante la discusión, Guy Steele también expresó esta idea, y agregó que la aplicación no debe consistir en escribir un compilador para su idioma, a menos que su idioma esté destinado a escribir compiladores.]
4. El lenguaje debe ser adecuado para escribir programas únicos.Usted sabe lo que significa un programa único: esto es cuando necesita resolver rápidamente un problema limitado. Creo que si miras a tu alrededor, encontrarás muchos programas serios que comenzaron como programas únicos. No me sorprendería si la mayoría de los programas comenzaran como únicos. Por lo tanto, si desea crear un lenguaje que sea adecuado para escribir software en general, entonces debería ser adecuado para escribir programas únicos, porque esta es la etapa inicial de muchos programas.
5. Sintaxis relacionada con la semántica
Tradicionalmente se cree que la sintaxis y la semántica son cosas muy diferentes. Puede sonar impactante, pero no lo es. Creo que lo que quieres obtener en tu programa está relacionado con cómo lo expresas.
Recientemente hablé con Robert Morris, y se dio cuenta de que la sobrecarga del operador es una gran ventaja en los idiomas ganadores con sintaxis infija. En idiomas con sintaxis de prefijo, cualquier función que defina es en realidad un operador. Si desea sumar el nuevo tipo de número que creó, simplemente puede definir una nueva función para agregarlo. Si hace esto en un idioma con sintaxis infija, verá que hay una gran diferencia entre usar un operador sobrecargado y llamar a una función.
Ideas que vuelven con el tiempo
1. Nuevos lenguajes de programación
Mirando hacia atrás en la década de 1970, estaba de moda desarrollar nuevos lenguajes de programación. Ahora esto no es así. Pero creo que el software del servidor volverá a la moda para crear nuevos idiomas. Con el software de servidor, puede usar el idioma que desee, por lo que si alguien crea un idioma que parece mejor que el resto, habrá personas que decidan usarlo.
2. Tiempo compartido
Richard Kelsey propuso esta idea, ha llegado el momento de que vuelva, y la apoyo plenamente. Mi suposición (y Microsoft también) es que muchos cálculos se moverán desde el escritorio a los servidores remotos. En otras palabras, la división del tiempo ha regresado. Creo que necesitarás apoyo a nivel de idioma. Por ejemplo, Richard y Jonathan Reeves hicieron mucho trabajo para implementar la planificación de procesos en el Esquema 48.
3. Eficiencia
Recientemente parecía que las computadoras ya eran bastante rápidas. Cada vez más oímos sobre bytecode, lo que al menos para mí significa que tenemos el poder en stock. Pero creo que con el software del servidor, no lo tenemos. Alguien tendrá que pagar por los servidores que ejecutan el software, y el número de usuarios que el servidor puede soportar por máquina será un divisor de sus costos de capital.
Creo que la eficiencia importará, al menos en los cuellos de botella de la informática. Esto será especialmente importante para las operaciones de E / S, ya que las aplicaciones del servidor realizan muchas de esas operaciones.
Al final, podría resultar que el código de bytes no sea una opción. Sun y Microsoft actualmente parecen estar luchando cara a cara en el campo de código de bytes. Pero lo hacen porque el bytecode es un lugar conveniente para integrarse en el proceso, y no porque el bytecode solo sea una buena idea. Puede resultar que toda esta batalla pase desapercibida. Sería gracioso
Trampas y trampas
1. Clientes
Esto es solo una suposición, pero es que solo aquellas aplicaciones que estarán completamente del lado del servidor se beneficiarán. Diseñar un software que funcione asumiendo que todos tendrán a su cliente es como crear una sociedad basada en el supuesto de que todos serán honestos. Definitivamente sería conveniente, pero debes asumir que nunca sucederá.
Creo que habrá un rápido aumento en los dispositivos con acceso a la web, y podemos suponer que admitirán formularios y html básicos. ¿Tienes un navegador en tu teléfono? ¿Habrá un teléfono en su PalmPilot? ¿Tu blackberry tendrá una pantalla más grande? ¿Tendrás la oportunidad de conectarte en línea desde tu gameboy? De tu reloj? No lo se Y no tengo que averiguar si apuesto a que todo estará en el servidor. Simplemente es mucho más confiable tener todos los cerebros en el servidor. .
2. Programación orientada a objetos
Entiendo que esta es una declaración controvertida, pero no creo que OOP sea algo importante. Creo que este es un paradigma adecuado para aplicaciones específicas que necesitan estructuras de datos específicas, como sistemas de ventanas, simulaciones, sistemas CAD. Pero no entiendo por qué debería ser adecuado para todos los programas.
Creo que la gente en las grandes empresas adora la POO, en parte porque proporciona mucho de lo que parece trabajo. Lo que, por supuesto, se puede representar como, digamos, una lista de enteros, ahora se puede representar como una clase con todo tipo de andamios, con ruido y bullicio.
Otra característica atractiva de OOP es que los métodos le dan un cierto efecto de las funciones de primera clase. Pero esto no es noticia para los programadores de Lisp. Cuando tiene funciones reales de la primera clase, simplemente puede usarlas de cualquier manera que corresponda a la tarea, en lugar de insertar todo en una plantilla de clases y métodos.
Creo que esto significa para el diseño del lenguaje que no debes incrustar OOP demasiado profundamente en él. Quizás la respuesta sea ofrecer cosas más generales y fundamentales, y permitir a las personas diseñar cualquier sistema de objetos en forma de bibliotecas.
3. Diseño por comité
Si su idioma está siendo redactado por un comité, entonces está atrapado, y no solo por razones que todos conocen. Todos saben que los comités tienden a crear un diseño de lenguaje desigual e inconsistente. Pero creo que el gran peligro es que no corren riesgos. Cuando una persona está a la cabeza, toma riesgos que el comité nunca aceptará asumir.
¿Debo arriesgarme para crear un buen lenguaje? Muchas personas pueden sospechar que el diseño de un lenguaje es donde debes mantenerte bastante cerca de la sabiduría tradicional. Apuesto a que no lo es. En todo lo demás que hace la gente, la recompensa es proporcional al riesgo. Entonces, ¿por qué el diseño del lenguaje debe ser diferente?