¿Hay algún lenguaje de ultra alto nivel por ahí? [cerrado]

Históricamente, un HLL es algo así como C, Fortran o Pascal y un VHLL es algo como Ruby o Python. Estoy familiarizado con los términos 4GL, 5GL, DSL y LOP, y aquellos que no lo estén deberían leer Wikipedia para las definiciones. Estoy buscando UHLLs.

Mi pregunta es: ¿hay algún lenguaje de computadora que sea otro orden de magnitud más productivo, y hay alguien trabajando en ellos?

Más productivo significa menos código creado y menos tiempo del programador para lograr un resultado, menos errores y menos depuración, un vínculo conceptual más cercano entre el código y los requisitos, menos esfuerzo para modificar y mantener.

El dominio principal que me interesa son las aplicaciones comerciales y de consumo de uso general, con interfaz gráfica de usuario o interfaz de usuario, persistencia de datos y conexiones a otros sistemas, como impresión y correo electrónico. Otras personas podrían enfocarse en otro lado.

Reconozco que algunos de esos lenguajes pueden ser específicos de un dominio y que pueden ser poco más que la capacidad de configuración de una aplicación grande y capaz. Las hojas de cálculo de Excel entran en esta categoría.

Reconozco que algunos de esos lenguajes pueden parecer generales, pero aún así pueden ser de alcance limitado e inadecuados para muchos problemas. Por ejemplo, Matlab podría no ser una buena opción para un programa que se ocupa principalmente de la interacción del usuario y los datos textuales.

Conozco algunas de las características que podrían estar en un UHLL, por analogía con VHLL. Esperaría encontrar uno o más de los siguientes (y siéntase libre de agregar a la lista):

• Un dibujo de un formulario GUI ES el programa para un formulario GUI
• Una tabla que contiene filas, columnas y encabezados ES el programa para una tabla en una base de datos
• La lógica declarativa dice qué se debe hacer y cuándo, sin declaraciones IF
• Operaciones en conjuntos de datos, sin bucles FOR
• Ejecución no secuencial, por ejemplo, impulsada por datos, coincidencia de patrones, caminata de árbol

La motivación para la pregunta es que estoy cada vez más harto del arduo trabajo de traducir requisitos comerciales relativamente simples en grandes cantidades de código para satisfacer lo que la computadora quiere o necesita. La pregunta es realmente acerca de encontrar a otras personas que compartan mi dolor y estén trabajando para elevar el nivel de los idiomas y lograr que la computadora haga más trabajo duro. Este fue un enfoque importante en las décadas de 1970 y 1980, pero ¿sigue sucediendo?

Estas son algunas respuestas sugeridas a mi pregunta, proporcionadas aquí para resumir o enumerar los idiomas que conozco y que, en mi opinión, se quedan cortos.

Hay muchos idiomas que son HLL o VHLL y contienen características individuales que pertenecen a un nivel superior. He usado la mayoría de ellos (a menudo mal). Incluyen

• Lisp, con sus macros y su capacidad de auto modificarse
• Haskell, con dependencia de datos y coincidencia de patrones
• SQL, que trata en filas y tablas
• Rebol, que parece inteligente pero realmente no lo entiendo
• APL (y J), con sus matrices multidimensionales y operadores ultracompactos
• C # con LINQ
• AWK / Perl / Python / Ruby con maravillosas colecciones y expresiones regulares incorporadas

Estos idiomas tienen demasiadas características de bajo nivel para ser UHLL. El programador todavía tiene que escribir muchas construcciones de bajo nivel para cualquier programa útil.

Hay paquetes RAD / 4GL. He usado algunos:

• dBase / Foxpro
• Dataflex / Powerflex (mi producto)
• Acceso
• PowerBuilder

Y mucho más que no he usado. En su mayoría, el idioma es HLL en el mejor de los casos, pero el paquete contiene un marco y conexiones privilegiadas entre el idioma y el paquete para que las aplicaciones se puedan construir rápidamente. No estoy seguro de por qué este enfoque se acabó, pero en cualquier caso UHLL no lo es.

Hay frameworks / bibliotecas en bruto. He usado algunos:

• Rieles
• Java awt y swing
• .NET Windows Forms, WPF y ASP.NET.

Estos son actualmente el estado del arte. Dejan al programador firmemente atrapado en el lodo del lenguaje de implementación, lidiando con la complejidad en todo momento. Esto no es UHLL, pero posiblemente se pueda construir un UHLL sobre uno de estos.

Hay herramientas de diseño, como UML y el conjunto de herramientas de Rational, que no conozco bien. Hasta donde puedo ver, ayudan a articular los requisitos del negocio, pero nunca pueden reemplazar el paso de programación. No quiero eliminar a los programadores, solo hago más por unidad de tiempo y esfuerzo.

Entonces, habiendo eliminado a todos los contendientes que puedo pensar, espero que alguien más pueda proporcionar un mejor candidato.

Edición tardía: creo que tengo una respuesta: Wolfram Language. http://www.wolfram.com/wolfram-language/

Casi todos los criterios que enumera son cosas que ya se han probado en herramientas 4GL / RAD como MS Access, Sybase Power Builder, Oracle Forms, Ruby-on-Rails (como un espécimen más moderno para aplicaciones web) y muchos más (consulte Wikipedia para obtener más información). lista muy larga de vendedores). Y, de hecho, la traducción de requisitos empresariales relativamente simples en algún tipo de programa se puede lograr muy rápidamente con estas herramientas. Es por eso que la mayoría de los vendedores de herramientas RAD anuncian sus productos de una manera que todos deberían pensar que ya han inventado un UHLL en su sentido.

El problema es que, tan pronto como deje que los requisitos sean " relativamente simples ", y tan pronto como tenga que mantener y desarrollar programas escritos con estos entornos, notará que alcanza fácilmente los límites y observará los inconvenientes de ellos. , o que implementar requisitos con ellos no es más sencillo que con cualquier otro "VHLL" que tenga en mente. En mi humilde opinión, hay una buena posibilidad de que esto elimine cualquier mejora de eficiencia que haya tenido en la versión 1.0 al pasar a las versiones 1.1, 1.2 y 1.3 de su programa.

Si desea crear software para requisitos complejos, necesitará un entorno de programación complejo. Todavía no hay una bala de plata , solo tuvimos mejoras gradualmente a lo largo de los años y no "el orden de magnitud" en productividad con cualquier lenguaje de programación actual sobre sus predecesores (al menos, durante los últimos 30 años, que es aproximadamente el tiempo en el pasado cuando se publicó el artículo de Brook).

El lenguaje de programación de más alto nivel que conozco es APL . Requiere un teclado especial para representar todos los símbolos necesarios. Mira este video , en el que el autor escribe una implementación completa del Juego de la vida de Conway en aproximadamente siete minutos.

La verdadera pregunta, por supuesto, es "¿es esto práctico?" ¿Puedo encontrar suficientes programadores de APL en el mundo para sostener un negocio de esta manera? ¿APL se ejecutará en teléfonos y tabletas? ¿Realmente necesito comprar nuevos teclados para todos mis desarrolladores de software?

Si realmente desea un aumento de la productividad, su mejor opción es probablemente alguna variante de Lisp. Clojure se ejecuta en la JVM y tiene un puerto .NET. Digo esto porque la gente ya lo ha hecho; el motor de búsqueda de Orbitz funciona en Lisp, y Paul Graham dirigió un negocio completo usando Lisp, alegando que le dio una ventaja significativa sobre sus competidores (que todos estaban usando Java).

Tenga en cuenta que, cuanto más alto sea su lenguaje de programación, más se eliminará del hardware real y es más probable que tenga problemas de rendimiento. A menos que tenga compiladores realmente sofisticados, es posible que de vez en cuando se encuentre codificando porciones críticas de rendimiento de su aplicación en lenguajes de menor nivel y de mejor rendimiento.

Y todavía está la cuestión de tener una masa crítica de desarrolladores versados ​​en el lenguaje. A pesar de todas sus verrugas, nunca tendrá problemas para encontrar un programador de Java.

Tenga en cuenta que los idiomas principales todavía están evolucionando. Linq fue creado con el propósito específico de hacer que la programación basada en datos sea más declarativa. Se agregaron varias características nuevas al lenguaje C # para que Linq funcione; Todos ellos tienen que ver con mejorar la productividad del desarrollador.

Lecturas adicionales
Batir los promedios

Creo que has insinuado un poco sobre un punto de cruce que limita la existencia de lenguajes de ultra alto nivel; en algún momento ya no los identificamos como lenguajes de programación.

El mejor ejemplo de este fenómeno específico que conozco, y que quizás sea de gran interés potencial aquí, es el lenguaje de modelado unificado . De hecho, hay paquetes de aplicaciones de software específicos que se han desarrollado para hacer específicamente lo que está pidiendo. Cumple con muchos de sus requisitos, pero no necesariamente en la forma en que está pensando. Aún así, es extremadamente educativo para esta situación, ya que me he sentido de manera similar y mi experiencia (que sigue) ha cambiado la forma en que pienso sobre este problema.

Personalmente, aquí hablaré del arquitecto de software Rational de IBM , que es un intento de permitir realmente el desarrollo de ultra alto nivel. El objetivo es que pueda crear el concepto comercial filosófico como un objeto, como un Actor o Clase, otorgar atributos a las entidades, definir conexiones, definir cómo podría fluir la información a través del sistema mientras se trabaja, y hacer esto Todo con una GUI.

Por ejemplo, puede arrastrar un objeto DataStore, un Actor, un formulario, algunas Clases relevantes (como Cliente, etc.), dibujar algunas líneas de conexión entre objetos usando gráficos y demás, y boom: cuando haya terminado, publique un programa de trabajo. (esto obviamente es extremadamente simplificado)

De hecho, lo que se ha hecho es la formación de una GUI compleja, una implementación / interpretación muy completa de UML, y luego se compila en código Java / C # / VB con documentos XML completos que contienen la información de gráficos UML, y también implementan / habilitan Ingeniería de ida y vuelta para que pueda ir y venir entre el Modelo y el Código para poder controlar las cosas a un nivel filosófico de sangrado nasal muy alto y un código específico de plataforma de muy bajo nivel.

¡Es todo lo que quieres y más, y no renuncias a nada en el intercambio! ¿Correcto?

¿Por qué no todos lo usan?!?!

... bueno, mira, esa es la cosa. Lo que realmente termina es una empresa monolítica, todo implica una gran cantidad de partes móviles y magia, todo se ve afectado, o a veces no, por un cambio en cualquiera de los muchos lugares diferentes (en la GUI, XML, nivel inferior código, modelos UML que se crean / definen / mantienen en muchos niveles de modelo diferentes).

Es realmente genial jugar con él, pero es ... cómo decir esto ... tiene una curva de aprendizaje extremadamente alta, está diseñado con múltiples disciplinas en mente, y realmente debes tratarlo como algo completamente nuevo que permite poca, muy poca, generalización para otras habilidades que ya tienes.

Y la conclusión es que, incluso entonces, con millones y millones vertidos en el proyecto por docenas de compañías y algunos nombres muy importantes detrás de él, todavía terminas con un código de estilo C en la capa ejecutable que debe editarse directamente a veces , porque algunas cosas simplemente no hacen que la traducción entre las descripciones de clases orientadas a objetos y UML baje a nivel de programación / máquina, y la automatización simplemente no puede completarse.

Mi experiencia fue que era una forma increíblemente complicada de generar andamios. Probablemente sea lo más cruel que diré sobre una empresa tecnológica tan inmensa, pero eso es lo que obtuve de ella.

De la gente de la industria con la que he hablado, lamentablemente dijeron lo mismo. Sintieron que hicieron mucho trabajo creando documentación, innumerables diagramas, modelos, reuniones, análisis, durante meses y meses, y luego lo tiraron todo y el equipo de desarrollo simplemente escribió el código y a menudo lo trató como Aún Otra carpeta de especificaciones (que ya nadie lee). Así que ahora solo usan Java y algunos programas de diagramas / visualización de propósitos especiales, y Agile, y ese es el final de esa historia.

Tal vez esto sea injusto y funcione cuando lo haces bien. Tal vez, pero de consultores y profesores con los que he hablado afirmaron haber pasado muchas horas en talleres especiales de desarrollo de varias semanas trabajando para aprender el sistema, y ​​volviendo para obtener más capacitación, y literalmente dedicando años para aprender cómo hacerlo. trabajo y lo que va a donde.

Pero tal vez sea culpa de todos los programadores, que simplemente se nieguen a aceptar que el sistema funciona tan bien y, sin embargo, no se parece en nada a la programación de computadoras. Tal vez los programadores de código puro simplemente se resisten a reemplazar sus trabajos, como los fabricantes de velas y los tejedores de antaño, y se niegan a hacer su tarea limitada de Implementación a Especificación y esto hace que todos los demás se sientan tan frustrados que lo tiran y dicen cosas malas, y casi fue perfecto.

Pero ... creo que puede haber algo de verdad en eso, sin embargo, creo que en su mayoría simplemente no funciona tan bien. Creo que resulta algo que no es realmente tan difícil la mayor parte del tiempo (programación de computadoras), y lo hace aún más difícil hasta el punto de que si funciona sería genial, pero santo cielo, tienes mucho tiempo sin nada para ¡muéstralo para llegar allí!

Tal vez funcionaría solo en una empresa con más de mil equipos de hombres, y tal vez todavía no estemos allí.

No se.

Sin embargo, un estudio de lo que está bien y lo que está mal con este enfoque de los lenguajes de ultra alto nivel, y creo que UML necesita ser incluido en tal consideración, realmente debe considerar cosas como Rational Software Architect, para evitar un posibles recados tontos.

O tal vez solo tenemos que darle otros 20-50 años de arduo trabajo. Ya no soy optimista de que un lenguaje de programación es la restricción, ya no.

Y si los lenguajes de programación eran la restricción antes, es por eso que las mejoras nos dieron una posible mejora de orden de magnitud. Si ya no son una limitación, entonces es mucho más probable que cualquier innovación sea incapaz de proporcionar ese orden de mejora. ¡Pero no puedo decir el futuro! Por lo tanto, supondré que el resto no está "en proceso", pero ciertamente "es demasiado pronto para contarlo".

Si lo piensa por un tiempo, la programación de nivel superior es básicamente poder componer partes más pequeñas que están fácilmente disponibles y probadas. Hasta el punto donde su programa es un código de pegamento muy simple de varias bibliotecas. Quizás el pegamento sea un DSL muy expresivo. Puede hacer esto en casi todos los lenguajes de programación.

Personalmente, empiezo a sentir cada vez más que la solución a la componibilidad es, al contrario de lo que puede sentir instintivamente, no se encuentra en la programación orientada a objetos. Este paradigma, al igual que la programación imperativa, brinda demasiada libertad a los programadores, lo que a su vez hace que sea demasiado difícil escribir código que sea fácil de reutilizar.

Más bien, creo que la programación funcional proporciona primitivas que son mucho más adecuadas para la componibilidad. Los lenguajes de programación funcionales puros tampoco le permiten definir funciones que tengan efectos secundarios, lo que no solo reduce los errores o facilita su detección, sino que también facilita su construcción (componerlos en un sistema más grande).

Si le interesa la programación funcional, puede echar un vistazo a los lenguajes funcionales modernos como Haskell . Creo que el módulo Parsec proporciona un buen DSL de alto nivel (se llama biblioteca combinada en jerga funcional) para analizar. También hay marcos de programación reactivos funcionales para Haskell que le permiten crear potentes GUI con unas pocas líneas de código.

Esperaría que Lua, como la usa el juego para guiar sus misiones e interfaces, cumpliría con este criterio. También se utilizan lenguajes específicos de dominio similares (y utilidades de creación de mapas) para permitir a los diseñadores de niveles decir rápida y fácilmente "cuando el jugador hable con Bob, comience la misión épica de Bob".

Sé de algunos lenguajes esotéricos más que se centran en mover el código para describir lo que está sucediendo, no cómo se supone que debe hacerse. Algunos se centran en un enfoque muy declarativo, basado en la lógica. Algunos se centran en la programación reactiva para hacer eso. Algunos se centran en los actores para hacer eso (especialmente para cosas que necesitan ser paralelizables). Algunos se centran simplemente en hacer que la sintaxis sea más natural, con la afirmación de que la sintaxis natural conduce a menos errores causados ​​por la traducción entre el lenguaje natural y el código.

Ninguno es realmente prometedor en cuanto a producir un orden de magnitud más productividad para el desarrollador de rango y archivo.

Creo que REBOL puede ajustarse a todos sus criterios. Puede crear aplicaciones GUI relativamente sofisticadas en varias líneas de código; sin embargo, su "especialidad" es la creación de DSL.