¿Qué tan cerca hemos llegado a automatizar la escritura de código? [cerrado]

Y no me refiero a autocompletar o fragmentos de código automáticos insertados por editores modernos, o código polimórfico. Pero, ¿cuál es el estado de la técnica en los programas que pueden pasar por entradas y tipos dados e información de las salidas deseadas y generar un código válido en un idioma de elección? Soy consciente de la programación genética, la programación de expresión génica, pero no conozco ningún otro esfuerzo. También googlear no aparece mucho.

¿Alguien sabe de algún avance en este frente?

Editar: cuando digo "generar un código válido", me refiero a una IA o algo similar que resuelva la lógica y el flujo de control y lo implemente en un lenguaje imperativo. Solo lenguaje imperativo, ya que esa es la parte difícil. Sin embargo, si conoce algún nuevo lenguaje que se esté desarrollando para admitir este tipo de idea, por favor mencione, ya que quizás nuestro conjunto actual de idiomas no es adecuado para el tipo de IA temprana que podamos tener.

Los lenguajes específicos de dominio son casi tan cercanos como nunca.

Siempre tendrá que darle a la computadora algunas reglas para trabajar. Pero cuanto más se definan esas reglas de una manera específica para su dominio, menos entrada tendrá que haber.

Los lenguajes específicos de dominio que se dirigen al desarrollo web requieren menos codificación que los lenguajes que son más genéricos. Los lenguajes específicos de dominio que se dirigen a las pruebas requieren menos codificación que los idiomas que no lo hacen. Los lenguajes específicos de dominio que se dirigen a la genética requieren menos codificación que los idiomas que no lo hacen. Y así.

Ahora, aquí viene la gran pregunta: ¿cuándo un dominio se vuelve lo suficientemente grande como para justificar la escritura de un lenguaje específico de dominio para él? El desarrollo web y las pruebas son cosas en las que al menos la mitad del mundo del desarrollo está trabajando. Era inevitable que surgieran marcos, reduciendo la cantidad de código repetitivo para estas cosas (que es, esencialmente, un lenguaje específico de dominio).

Pero, ¿qué hay del dominio comercial de su empresa? ¿Vale la pena centrarse en las cosas que se mencionan comúnmente en su empresa y hacer que pueda hacer referencia a esas cosas fácilmente en el código? No creo que realmente hayamos encontrado ese equilibrio todavía, aunque el diseño basado en el dominio se trata de responder esa pregunta.

En los años 80 y 90 hubo mucho revuelo sobre los llamados lenguajes de cuarta generación . Del artículo de Wikipedia:

Todos los 4GL están diseñados para reducir el esfuerzo de programación, el tiempo que lleva desarrollar software y el costo del desarrollo del software. No siempre tienen éxito en esta tarea, a veces dan como resultado un código poco elegante e imposible de mantener. Sin embargo, dado el problema correcto, el uso de un 4GL apropiado puede ser espectacularmente exitoso

...

Existen varios tipos diferentes de 4GL:

• Programación basada en tablas (sin código), que generalmente se ejecuta con un marco de tiempo de ejecución y bibliotecas. En lugar de usar código, el desarrollador define su lógica seleccionando una operación en una lista predefinida de comandos de manipulación de memoria o tabla de datos. En otras palabras, en lugar de codificar, el desarrollador utiliza la programación de algoritmos basados ​​en tablas (consulte también las tablas de control que se pueden utilizar para este propósito). Un buen ejemplo de este tipo de lenguaje 4GL es PowerBuilder. Estos tipos de herramientas se pueden usar para el desarrollo de aplicaciones comerciales, que generalmente consisten en un paquete que permite la manipulación de datos comerciales y la presentación de informes, por lo tanto, vienen con pantallas GUI y editores de informes. Por lo general, ofrecen integración con archivos DLL de nivel inferior generados a partir de un 3GL típico para cuando surja la necesidad de más operaciones específicas de hardware / sistema operativo.
• Los lenguajes de programación del generador de informes toman una descripción del formato de datos y el informe para generar y de ahí generan el informe requerido directamente o generan un programa para generar el informe. Ver también RPG
• Del mismo modo, los generadores de formularios gestionan las interacciones en línea con los usuarios del sistema de aplicaciones o generan programas para hacerlo.
• Los 4GL más ambiciosos (a veces denominados entornos de cuarta generación) intentan generar automáticamente sistemas completos a partir de las salidas de herramientas CASE, especificaciones de pantallas e informes, y posiblemente también la especificación de alguna lógica de procesamiento adicional.
• Gestión de datos Los 4GL como SAS, SPSS y Stata proporcionan comandos de codificación sofisticados para la manipulación de datos, la remodelación de archivos, la selección de casos y la documentación de datos en la preparación de datos para el análisis estadístico y la presentación de informes.

Es interesante contrastar 4GL con lenguajes de programación de quinta generación :

Un lenguaje de programación de quinta generación (abreviado 5GL) es un lenguaje de programación basado en la resolución de problemas usando restricciones dadas al programa, en lugar de usar un algoritmo escrito por un programador. La mayoría de los lenguajes de programación basados ​​en restricciones y lógicos y algunos lenguajes declarativos son lenguajes de quinta generación.

Mientras que los lenguajes de programación de cuarta generación están diseñados para crear programas específicos, los lenguajes de quinta generación están diseñados para hacer que la computadora resuelva un problema dado sin el programador. De esta forma, el programador solo necesita preocuparse por los problemas que deben resolverse y las condiciones que deben cumplirse, sin preocuparse por cómo implementar una rutina o un algoritmo para resolverlos. Los lenguajes de quinta generación se utilizan principalmente en la investigación de inteligencia artificial. Prolog, OPS5 y Mercury son ejemplos de lenguajes de quinta generación.

En última instancia, incluso si no 'programa' la computadora, alguien aún tiene que explicarle sus requisitos a la computadora.

Uno de los enfoques más discutidos para la generación automática de código es "MDA", también conocida como arquitectura dirigida por modelos. Principalmente (pero no necesariamente) uno coloca UML a través del editor visual GUI desde el cual se generan las clases relevantes.

Si bien, creo que la expresión de código completamente funcional podría estar aún lejos, existen sistemas bastante buenos que generan esqueletos completos.

Echa un vistazo: http://www.actifsource.com/actifsource/index.html

También: http://www.win.tue.nl/~mchaudro/cbse2007/programgenerators.pdf

http://proglang.informatik.uni-freiburg.de/teaching/mda/2006ss/09-code-gen.pdf

He escrito muchos generadores de código para Java y C # que producen código de trabajo para diversas tareas. Hay paquetes como JAXB, que analiza un documento XML y produce las clases Java correspondientes y el código de clasificación / descomposición para hacer la traducción, y Entity Framework que produce clases DTO para calcular datos hacia / desde una base de datos. También hay herramientas como Rational XDE (como se llame ahora) que generan código de ida y vuelta entre un diagrama de clase y Java.

Si está buscando algo que pueda tomar requisitos comerciales o una especificación funcional y convertirlo en código, no he visto mucho progreso en esa área. Sé que OMG está trabajando en algún tipo de "UML ejecutable", pero aparte de algunos prototipos de DoD, no conozco ninguna implementación práctica.

¿ Cuenta la programación declarativa , por ejemplo, Prolog o SQL?

Usted simplemente describe lo que el programa debe lograr o qué condiciones deben cumplir los resultados. Luego consulta el sistema y obtiene resultados (o "sin soluciones").

Por supuesto, bajo el capó, hay un programa en ejecución, pero nunca se ve el código.

Desafortunadamente, la programación declarativa no es una bala de plata: más allá de los casos elementales, describir el objetivo declarativo con suficiente precisión aún requiere un esfuerzo y habilidad considerables, sin mencionar que para obtener un rendimiento decente, debes tener en cuenta varias imperfecciones de lo real, bajo la implementación de la campana (por ejemplo, comprender el papel de los índices SQL o la llamada de cola en las definiciones recursivas ...)

Dependiendo del tipo de problema, en realidad podría ser más fácil resolver el "cómo" que describir con precisión el "qué". Para los humanos, o al menos la mayoría de los programadores promedio, pensar en "cómo" parece ser más natural y "qué exactamente" requiere más gimnasia mental.

No estoy de acuerdo con su afirmación de que "el lenguaje imperativo ... esa es la parte difícil". Esa es la parte fácil, aunque es considerablemente más fácil en algunos idiomas que en otros. Descubrir lo que los usuarios realmente quieren y organizar toda esa información es la parte difícil. La parte del "lenguaje imperativo" parece difícil porque es cuando se realiza todo el trabajo real. Es entonces cuando aparecen las preguntas detalladas sobre los requisitos, y cuando todas las respuestas deben organizarse en una definición de sistema ejecutable.

No hay programación sin programación. Alguien tiene que traducir los deseos humanos imprecisos en una especificación precisa de un cálculo. Esa especificación puede estar en lenguaje ensamblador, o Java, o LISP, algún sistema esquemático, o un lenguaje aún por inventar. Pero hasta que las computadoras sean capaces de una comunicación profunda con los humanos, alguien tendrá que hablar con los usuarios y definir con precisión el sistema.

Ya estamos ahi! Todo lo que necesitamos es un lenguaje con hoy llamado carácter homo-icónico y décadas antes "el código es información". Defina su propio entorno mediante la programación de abajo hacia arriba en lugar de diseñar de arriba hacia abajo. Por ejemplo, podría construir sus propios DSL dentro de Lisp. Con el enfoque de Apilamiento , puede colocar tantos DSL (capas) uno encima del otro como necesite para su problema específico. Este enfoque lo lleva desde una representación de muy bajo nivel de expresiones S hasta la abstracción de datos más compleja que pueda imaginar. Entonces, ¿qué es la escritura automática de código, si no se apila un idioma en otro?

He escuchado murmullos de intentos de derivar programas a partir de especificaciones expresadas usando tipos dependientes en sistemas como Coq. Sin embargo, no tengo idea de qué tipo de progreso se ha hecho.

¿Qué tan cerca hemos llegado a automatizar la escritura de código?

ni cerca de nada de lo que valga la pena hablar.

También puse firmemente que nunca llegaremos allí tampoco.

¿Estado del arte en la automatización de la escritura de códigos? No hay "estado del arte". Pero hay un estado de fracaso perpetuo. No hay intentos exitosos hasta ahora. Lo más probable es que nunca haya una implementación exitosa de esto, excepto algunos ejemplos que tienen un alcance muy limitado.

Eso puede ser algo bueno, ya que nos dejaría sin trabajo.

Por cierto a las personas que leen ... No confunda la creación de algoritmos con generadores triviales de CRUD como Ruby on Rails. La generación de CRUD es la ejecución de un algoritmo predefinido, no la creación de un algoritmo para resolver un problema.

Hay varias herramientas donde puedes hacer cosas sin escribir ningún código (MS Access, Filemaker). Algunos generan código en segundo plano que puede modificarse. Esto funciona bien con aplicaciones empresariales y front-end de bases de datos. El usuario golpea una pared y eventualmente contrata a un programador. La lógica se vuelve demasiado compleja. He visto aplicaciones web que crean un formulario que llena una tabla. Esto es excelente hasta que necesite un formulario primario con un formulario secundario que maneje múltiples registros. Ninguno de ellos ofrece esto.

Tratando de imaginar cómo funciona esto si quiero automatizar / codificar la alteración de archivos de imagen, video o sonido. Al igual que una GUI de la base de datos, alguien podría hacerlos para estos que generan código en lugar de simplemente manipular el archivo.

Las hojas de cálculo manejan todo, desde matemática simple hasta estadísticas, bastante bien. Grabe una macro y se crea un guión.

La complejidad usualmente se pone al día. Eventualmente, quieres crear algo realmente nuevo. Es difícil construir un generador de código que cree código para algo en lo que nadie más pensó.

Con su pregunta, creo que está preguntando cuánto desarrollo futuro podrá minimizar la cantidad de trabajo que un desarrollador de software tendrá que hacer. Incluso si tiene una IA que puede escribir todo su programa, aún tiene que decirle qué hacer, al igual que para un fabricante de automóviles automático, todavía tiene que darle un plano, y ese plano requiere algo de trabajo.

Y si tiene una IA, aún tiene que enseñarla y tendrá que aprender a través de varios proyectos. Por lo tanto, no creo que una IA sea adecuada para este tipo de trabajo, sino un enfoque más determinista, utilizando generadores de código. Estos generadores de código pueden volverse muy complejos, pero no necesariamente tienen que emplear aprendizaje automático.

Dicho esto, ya existe investigación en las áreas llamadas Diseño de software orientado a funciones y Diseño de software orientado a aspectos. Estos tratan con el ensamblaje de aplicaciones de software seleccionando algunas características que debería tener, y luego se genera el código para eso. El objetivo es tener implementaciones para varias características que aparecen repetidamente en un dominio particular y ensamblarlas como bloques de construcción, según sea adecuado para su aplicación particular. Para el desarrollo web, por ejemplo, las características incluirían transacciones, estadísticas, escalabilidad, registro y cualquier cosa que pueda considerar como características recurrentes de diferentes aplicaciones web.

Las características y los aspectos son diferentes a los componentes, ya que generalmente son preocupaciones transversales. Tomemos, por ejemplo, el registro. No puede simplemente tomar una biblioteca e incluirla en su aplicación y decir que tiene un registro ahora. Debe distribuir sus llamadas de registro por todo su código, y ahí es donde los generadores de código son útiles. Recientemente escuché sobre todo esto en esta entrevista de dos partes en Software Engineering Radio .

Parece que este tipo de investigación está bastante de moda en Europa, y en Alemania en particular, incluso en la industria, como puedo decir por experiencia personal. La generación de código puede ser útil para generar el código de infraestructura necesario, de modo que el desarrollador pueda concentrarse exclusivamente en implementar el comportamiento específico de su aplicación y no molestarse con los mismos problemas secundarios en cada proyecto diferente.

Queda por ver cuánto se puede reducir ese código específico de la aplicación. Ciertamente no se puede eliminar por completo, solo se reduce a algún tipo de plan, como mencioné al principio.