Filosofía guía
1. Lenguajes de programación para personas
Los lenguajes de programación son la forma en que la gente habla 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 la gente no puede manejar el lenguaje de máquina. El objetivo de los lenguajes de programación es evitar que nuestros pobres y frágiles cerebros humanos se vean abrumados por demasiados detalles.
Los arquitectos saben que algunos problemas de diseño son más mundanos que otros. Algunos de los problemas de diseño más claros y abstractos son el diseño de puentes. En este caso, tu trabajo consiste en cubrir la distancia requerida con el menor material posible. En el otro extremo del espectro está el diseño de sillas. Los diseñadores de sillas deberían dedicar su tiempo a pensar en los traseros de las personas.
El desarrollo de software tiene una diferencia similar. Diseñar algoritmos para enrutar datos a través de una red es un problema bonito y abstracto, como diseñar puentes. Mientras que diseñar lenguajes de programación es como diseñar sillas: hay que lidiar con las debilidades humanas.
A la mayoría de nosotros nos resulta difícil darnos cuenta de esto. Diseñar sistemas matemáticos elegantes suena mucho más atractivo para la mayoría de nosotros que complacer 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 no todo es elegancia.
Y cuando digo que los lenguajes deberían diseñarse para adaptarse a las debilidades humanas, no me refiero a que los lenguajes deban diseñarse para malos programadores. En realidad, deberías diseñar software para los mejores programadores, pero incluso los mejores programadores tienen sus límites. No creo que a nadie le guste programar en un lenguaje donde todas las variables se indican con la letra "x" con subíndices enteros.
2. Diseña para ti y tus amigos
Si nos fijamos en la historia de los lenguajes de programación, la mayoría de los mejores lenguajes fueron diseñados para ser utilizados por sus propios autores, y la mayoría de los peores fueron diseñados para que los usaran otras personas.
Cuando los idiomas están diseñados para otras personas, siempre se trata de un grupo específico de personas: las personas no son tan inteligentes como los creadores del idioma. Así es como obtienes una lengua que te habla con desdén. Cobol es el ejemplo más destacado, pero la mayoría de los lenguajes están imbuidos de este espíritu.
No tiene nada que ver con el nivel de nivel del idioma. C tiene un nivel bastante bajo, pero fue creado para que lo utilizaran sus autores, razón por la cual a los hackers les encanta.
El argumento para diseñar lenguajes para malos programadores es que hay más malos programadores que buenos. Quizás esto sea así. Pero este pequeño número de buenos programadores escribe desproporcionadamente más software.
Mi pregunta es, ¿cómo se crea un lenguaje que atraiga a los mejores hackers? Me parece que esta pregunta es idéntica a la pregunta de ¿cómo crear un buen lenguaje de programación?, pero aunque no lo sea, al menos es una pregunta interesante.
3. Dale al programador el mayor control posible.
Muchos idiomas (especialmente aquellos diseñados para otras personas) actúan como niñeras: intentan advertirte de cosas que creen que no te serán útiles. Yo adopto el punto de vista opuesto: dale al programador todo el control que puedas.
Cuando aprendí Lisp por primera vez, lo que más me gustó fue que hablábamos como iguales. En los otros idiomas que había aprendido en ese momento, había un idioma y estaba mi programa en ese idioma, y existían de manera bastante separada. Pero en Lisp, las funciones y macros que escribí fueron las mismas en las que fue escrito el lenguaje mismo. Podría reescribir el lenguaje mismo si quisiera. Tenía el mismo atractivo que el software de código abierto.
4. La brevedad es hermana del talento.
La brevedad se subestima e incluso se desprecia. Pero si observas los corazones de los hackers, verás que les gusta mucho la brevedad. ¿Cuántas veces has oído a los hackers hablar con cariño de cómo, por ejemplo, en APL, pueden hacer cosas increíbles con sólo un par de líneas de código? Supongo que a la gente realmente inteligente le gusta prestar atención a esto.
Creo que casi cualquier cosa que haga que los programas sean más cortos es algo bueno. Debería haber muchas funciones de biblioteca, todo lo que pueda estar implícito debería serlo; la sintaxis debería ser más concisa; Incluso los nombres de las entidades deben ser cortos.
Y no sólo los programas deberían ser breves. Los manuales también deben ser breves. Buena parte de los manuales están llenos de explicaciones, avisos legales, advertencias y casos especiales. Si necesitas acortar el manual, la mejor opción es corregir el lenguaje que requiere tanta explicación.
5. Reconoce qué es el hacking
A mucha gente le gustaría que la piratería fuera matemática, o al menos algo parecido a la ciencia. Creo que la piratería se parece más a la arquitectura. La arquitectura tiene que ver con la física en el sentido de que un arquitecto necesita diseñar un edificio que no se caiga, pero el verdadero objetivo de un arquitecto es crear un gran edificio, no hacer descubrimientos en el campo de la estática.
Lo que les encanta a los hackers es crear grandes programas. Y creo que, al menos en nuestra opinión, deberíamos recordar que escribir grandes programas es algo maravilloso, incluso cuando ese trabajo no se traduce fácilmente en la corriente intelectual habitual de los artículos científicos. Desde un punto de vista intelectual, es tan importante diseñar un lenguaje que a los programadores les encantará como diseñar uno terrible que encarne una idea sobre la que puedas publicar un artículo.
Problemas abiertos
1. ¿Cómo organizar bibliotecas grandes?
Las bibliotecas se están convirtiendo en una parte importante de los lenguajes de programación. Se vuelven tan grandes que pueden ser peligrosos. Si lleva más tiempo encontrar una función en una biblioteca que haga lo que necesita que escribirla usted mismo, entonces todo el código no hace más que hacer que su manual sea más grueso. (Los manuales de Simbólica fueron un ejemplo de esto.) Así que tendremos que resolver el problema de la organización de la biblioteca. Lo ideal es diseñarlos de manera que el programador pueda adivinar qué función de biblioteca es adecuada.
2. ¿La gente está realmente asustada por la sintaxis de los prefijos?
Este es un problema abierto en el sentido de que he estado pensando en ello durante varios años y todavía no sé la respuesta. La sintaxis del prefijo me parece completamente natural, excepto quizás por su uso en matemáticas. Pero puede ser que gran parte de la impopularidad de Lisp se deba simplemente a su sintaxis desconocida... Si debemos hacer algo al respecto, si es cierto, es otra cuestión.
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 residirán en un servidor y se comunicarán con usted a través de un navegador web. Y para escribir este tipo de aplicaciones necesitamos cosas nuevas.
Una de esas cosas es la compatibilidad con una nueva forma de lanzar aplicaciones de servidor. En lugar de uno o dos grandes lanzamientos por año, como el software de escritorio, el software de servidor se lanzará con una serie de pequeños cambios. Es posible que tenga cinco o diez lanzamientos por día. Y todos siempre tendrán la última versión.
¿Sabes cómo diseñar programas para que sean mantenibles? El software del servidor debe estar diseñado para ser modificable. Debería poder cambiarlo fácilmente, o al menos saber qué significa un cambio menor y qué es importante.
Otra cosa que puede resultar útil en el software de servidor es, de repente, la continuidad de la entrega. En una aplicación web puedes usar algo como para obtener el efecto de las rutinas en el mundo sin estado de las sesiones web. Tener continuidad en el suministro puede valer la pena si la función no es demasiado costosa.
4. ¿Qué nuevas abstracciones quedan por descubrir?
No estoy seguro de cuán razonable sea esa esperanza, pero personalmente me gustaría mucho descubrir una nueva abstracción, algo que pueda ser tan significativo como las funciones de primera clase o la recursividad o al menos los parámetros predeterminados. Quizás este sea un sueño imposible. Estas cosas muchas veces no se descubren. 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 existe una gran tendencia a escribir aplicaciones en el mismo idioma que el sistema operativo. Así que hace diez años, escribir software en general significaba escribir software en C. Con el tiempo, la tradición evolucionó: las aplicaciones no deberían escribirse en lenguajes inusuales. Y esta tradición ha evolucionado durante tanto tiempo que personas sin conocimientos técnicos, como gerentes y capitalistas de riesgo, también la han aprendido.
El software del servidor destruye este modelo por completo. Con el software de servidor puedes utilizar cualquier idioma que desees. Casi nadie lo entiende todavía (especialmente los directivos y los capitalistas de riesgo). Pero algunos hackers entienden esto, por eso oímos hablar de lenguajes independientes como Perl y Python. No oímos hablar de Perl y Python porque la gente los usa para escribir aplicaciones de Windows.
¿Qué significa esto para nosotros, personas interesadas en el diseño de lenguajes de programación, que existe una audiencia potencial para nuestro trabajo?
2. La velocidad proviene de los perfiladores
A los desarrolladores de lenguajes, o al menos a los implementadores de lenguajes, les gusta escribir compiladores que generen código rápido. Pero creo que eso no es lo que hace que los idiomas sean rápidos para los usuarios. Knuth señaló hace mucho tiempo que la velocidad depende de unos pocos cuellos de botella. Y cualquiera que haya intentado acelerar un programa sabe que no se puede adivinar dónde está el cuello de botella. Profiler es la respuesta.
Los desarrolladores de lenguajes están resolviendo el problema equivocado. Los usuarios no necesitan puntos de referencia para ejecutarse 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. Entonces, tal vez sería mejor si los implementadores del lenguaje dedicaran la mitad del tiempo que dedican a optimizar el compilador y lo dedicaran a escribir un buen generador de perfiles.
3. Necesitas una aplicación que haga evolucionar tu idioma
Puede que esta no sea la verdad última, pero parece que los mejores lenguajes evolucionaron junto con las aplicaciones en las que se utilizaban. C fue escrito por personas que necesitaban programación de sistemas. Lisp fue diseñado en parte para la diferenciación simbólica, y McCarthy estaba tan ansioso por comenzar que incluso comenzó a escribir programas de diferenciación en el primer artículo de Lisp en 1960.
Esto es especialmente bueno si su aplicación resuelve algunos problemas nuevos. Esto hace que su lenguaje tenga nuevas características que los programadores desean. Personalmente, estoy interesado en escribir un lenguaje que sea bueno para aplicaciones de servidor.
[Durante la discusión, Guy Steele también destacó este punto y agregó que la aplicación no debe consistir en escribir un compilador para su idioma, a menos que su idioma esté diseñado para escribir compiladores.]4. El lenguaje debe ser adecuado para escribir programas únicos.
Ya sabes lo que significa un programa de una sola vez: es cuando necesitas resolver rápidamente algún problema limitado. Creo que si miras a tu alrededor, encontrarás muchos programas serios que comenzaron como únicos. No me sorprendería que 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 también debería ser adecuado para escribir programas únicos, porque esta es la etapa inicial de muchos programas.
5. La sintaxis está relacionada con la semántica.
Tradicionalmente se cree que la sintaxis y la semántica son cosas muy diferentes. Esto puede parecer impactante, pero no lo es. Creo que lo que quieres lograr en tu programa tiene que ver con cómo lo expresas.
Recientemente hablé con Robert Morris y notó que la sobrecarga de operadores es una gran ventaja para la victoria de los lenguajes con sintaxis infija. En lenguajes con sintaxis de prefijo, cualquier función que defina es en realidad un operador. Si desea agregar un nuevo tipo de número que inventó, simplemente puede definir una nueva función para agregarlo. Si haces esto en un lenguaje con sintaxis infija, verás que hay una gran diferencia entre usar un operador sobrecargado y llamar a una función.
Ideas que regresan con el tiempo
1. Nuevos lenguajes de programación
Si nos remontamos a la década de 1970, estaba de moda desarrollar nuevos lenguajes de programación. Este no es el caso ahora. Pero creo que el software de servidor volverá a poner de moda la creación de nuevos lenguajes. Con el software de servidor puedes utilizar cualquier idioma que desees, por lo que si alguien crea un idioma que parece mejor que el resto, habrá gente que decidirá utilizarlo.
2. Tiempo compartido
A Richard Kelsey se le ocurrió esta idea cuyo momento ha llegado nuevamente y la apoyo plenamente. Mi conjetura (y la de Microsoft también) es que gran parte de la informática se trasladará del escritorio a servidores remotos. En otras palabras, el tiempo compartido ha vuelto. Creo que esto necesitará apoyo a nivel del idioma. Por ejemplo, Richard y Jonathan Reeves han trabajado mucho para implementar la programación de procesos en el Esquema 48.
3. Eficiencia
Recientemente parecía que los ordenadores ya eran lo suficientemente rápidos. Cada vez oímos más sobre el código de bytes, lo que al menos para mí significa que tenemos algo de energía en reserva. Pero creo que con el software de servidor no lo tenemos. Alguien tendrá que pagar por los servidores que ejecutan el software, y la cantidad de usuarios que el servidor puede admitir por máquina será un divisor de sus costos de capital.
Creo que la eficiencia será importante, al menos en los cuellos de botella informáticos. Esto será especialmente importante para las operaciones de E/S, porque las aplicaciones de servidor realizan muchas de estas operaciones.
Al final, puede resultar que el código de bytes no sea la respuesta. Sun y Microsoft parecen estar compitiendo cara a cara en el campo del código de bytes en este momento. Pero lo hacen porque el código de bytes es un lugar conveniente para integrarse en un proceso, no porque el código de bytes en sí sea una buena idea. Puede resultar que toda esta batalla pase desapercibida. Sería gracioso.
Trampas y trampas
1. Clientes
Esto es sólo una suposición, pero es que las únicas aplicaciones que se beneficiarán son aquellas que están completamente del lado del servidor. Diseñar software que funcione bajo el supuesto de que todos tendrán un cliente es como diseñar una sociedad basada en el supuesto de que todos serán honestos. Definitivamente sería conveniente, pero hay que asumir que nunca sucederá.
Creo que habrá un rápido aumento en los dispositivos habilitados para la web y podemos suponer que admitirán HTML y formularios básicos. ¿Tienes un navegador en tu teléfono? ¿Su PalmPilot tendrá un teléfono? ¿Tu blackberry tendrá una pantalla más grande? ¿Podrás acceder a Internet desde tu Gameboy? ¿De tu reloj? No sé. Y no tendré que averiguarlo si apuesto a que todo estará en el servidor. Es mucho más confiable tener todos los cerebros en el servidor. .
2. Programación orientada a objetos
Me doy cuenta de que esta es una declaración controvertida, pero no creo que la programación orientada a objetos sea tan importante. Creo que este es un paradigma adecuado para aplicaciones específicas que necesitan estructuras de datos específicas, como sistemas de ventanas, simulaciones y sistemas CAD. Pero no entiendo por qué debería ser adecuado para todos los programas.
Creo que a la gente de las grandes empresas le encanta la programación orientada a objetos, en parte porque hace que muchas cosas parezcan funcionar. Lo que naturalmente podría representarse como, digamos, una lista de números enteros, ahora puede representarse como un salón de clases con todo tipo de andamios, ajetreo y bullicio.
Otra característica atractiva de la programación orientada a objetos es que los métodos le brindan algunos de los efectos de las funciones de primera clase. Pero esto no es ninguna novedad para los programadores de Lisp. Cuando tiene verdaderas funciones de primera clase, puede simplemente usarlas de cualquier manera que se adapte a la tarea en cuestión, en lugar de meter todo en una plantilla repetitiva de clases y métodos.
Creo que lo que esto significa para el diseño del lenguaje es que no deberías incorporar la programación orientada a objetos demasiado profundamente en él. Quizás la respuesta sea ofrecer cosas más generales y fundamentales y permitir que las personas diseñen cualquier sistema de objetos como bibliotecas.
3. Diseño por comité
Si su lenguaje está diseñado por un comité, entonces está atrapado, y no sólo por razones que todos conocen. Todo el mundo sabe que los comités tienden a crear diseños de lenguaje confusos e inconsistentes. Pero creo que el gran peligro es que no se arriesguen. Cuando una persona está a cargo, asume riesgos que el comité nunca aceptaría asumir.
¿Necesitas correr riesgos para crear un buen lenguaje? Mucha gente podría sospechar que en el diseño del lenguaje es donde hay que permanecer bastante cerca de la sabiduría tradicional. Apuesto a que ese no es el caso. En todo lo demás que hace la gente, la recompensa es proporcional al riesgo. Entonces, ¿por qué el diseño del lenguaje debería ser diferente?
Fuente: habr.com