Quão perto chegamos da automação da escrita de código? [fechadas]

E não quero dizer trechos de código de preenchimento automático ou automático inseridos por editores modernos ou código polimórfico. Mas qual é o estado da arte nos programas que podem passar por determinadas entradas, tipos e informações das saídas desejadas e gerar um trecho de código válido no idioma de sua escolha. Conheço Programação Genética, Programação de Expressão Gênica, mas não conheço outros esforços. Também pesquisar no Google não aparece muito.

Alguém está ciente de algum avanço nessa frente?

Edit: Quando digo "enviar um trecho de código válido", refiro-me a uma IA ou algo semelhante elaborando a lógica e o fluxo de controle e implementando-o em uma linguagem imperativa. Somente linguagem imperativa, já que essa é a parte difícil. No entanto, se você conhece algum novo idioma sendo desenvolvido para dar suporte a esse tipo de idéia, mencione, pois talvez o nosso conjunto atual de idiomas não seja adequado ao tipo de IA inicial que podemos ter pela primeira vez.

Os idiomas específicos do domínio estão o mais perto possível.

Você sempre precisará fornecer ao computador algumas regras para trabalhar. Porém, quanto mais essas regras forem definidas de uma maneira específica para seu domínio, menor será a participação.

Os idiomas específicos do domínio direcionados ao desenvolvimento da Web exigem menos codificação do que os idiomas mais genéricos. Os idiomas específicos do domínio que têm como alvo o teste exigem menos codificação do que os idiomas que não. Os idiomas específicos do domínio que têm como alvo a genética exigem menos codificação do que os idiomas que não. E assim por diante.

Agora, aqui está a grande questão: quando um domínio se torna grande o suficiente para justificar a criação de uma linguagem específica de domínio para ele? Desenvolvimento e teste da Web são coisas nas quais pelo menos metade do mundo do desenvolvimento está trabalhando. Era inevitável que estruturas surgissem, reduzindo a quantidade de código padrão para essas coisas (que é, essencialmente, uma linguagem específica de domínio).

Mas e o domínio comercial da sua empresa? Vale a pena focar nas coisas que são comumente mencionadas na sua empresa e torná-las para que você possa referenciar essas coisas facilmente no código? Acho que ainda não encontramos esse equilíbrio, embora o design orientado a domínio seja sobre responder a essa pergunta.

Nos anos 80 e 90, houve muita discussão sobre as chamadas linguagens de quarta geração . Do artigo da Wikipedia:

Todos os 4GLs foram projetados para reduzir o esforço de programação, o tempo necessário para desenvolver o software e o custo do desenvolvimento de software. Eles nem sempre são bem-sucedidos nessa tarefa, algumas vezes resultando em código deselegante e impossível de manter. No entanto, dado o problema certo, o uso de um 4GL apropriado pode ser espetacularmente bem-sucedido

...

Existem vários tipos diferentes de 4GLs:

• Programação orientada por tabela (sem código), geralmente em execução com uma estrutura de tempo de execução e bibliotecas. Em vez de usar código, o desenvolvedor define sua lógica selecionando uma operação em uma lista predefinida de comandos de manipulação de memória ou tabela de dados. Em outras palavras, em vez de codificar, o desenvolvedor usa a programação de algoritmos orientada por tabela (consulte também tabelas de controle que podem ser usadas para essa finalidade). Um bom exemplo desse tipo de linguagem 4GL é o PowerBuilder. Esses tipos de ferramentas podem ser usados ​​para o desenvolvimento de aplicativos de negócios geralmente consistindo em um pacote que permite a manipulação de dados de negócios e relatórios, portanto, eles vêm com telas da GUI e editores de relatórios. Eles geralmente oferecem integração com DLLs de nível inferior geradas a partir de um 3GL típico para quando houver necessidade de mais operações específicas de hardware / SO.
• As linguagens de programação do gerador de relatórios levam uma descrição do formato dos dados e do relatório a serem gerados e, a partir disso, geram diretamente o relatório necessário ou geram um programa para gerar o relatório. Veja também RPG
• Da mesma forma, os geradores de formulários gerenciam interações online com os usuários do sistema de aplicativos ou geram programas para isso.
• 4GLs mais ambiciosos (às vezes denominados ambientes de quarta geração) tentam gerar automaticamente sistemas inteiros a partir das saídas das ferramentas CASE, especificações de telas e relatórios e, possivelmente, também a especificação de alguma lógica de processamento adicional.
• Os 4GLs de gerenciamento de dados como SAS, SPSS e Stata fornecem comandos sofisticados de codificação para manipulação de dados, remodelagem de arquivos, seleção de casos e documentação de dados na preparação de dados para análise e relatório estatísticos.

É interessante contrastar o 4GL com as linguagens de programação de quinta geração :

Uma linguagem de programação de quinta geração (5GL abreviada) é uma linguagem de programação baseada na solução de problemas usando restrições dadas ao programa, em vez de usar um algoritmo escrito por um programador. A maioria das linguagens de programação lógica e baseada em restrições e algumas linguagens declarativas são linguagens de quinta geração.

Enquanto as linguagens de programação de quarta geração são projetadas para criar programas específicos, as linguagens de quinta geração são projetadas para fazer o computador resolver um determinado problema sem o programador. Dessa forma, o programador precisa se preocupar apenas com quais problemas precisam ser resolvidos e com quais condições precisam ser atendidas, sem se preocupar em como implementar uma rotina ou algoritmo para resolvê-los. As linguagens de quinta geração são usadas principalmente em pesquisas de inteligência artificial. Prolog, OPS5 e Mercury são exemplos de idiomas de quinta geração.

Por fim, mesmo que você não 'programe' o computador, alguém ainda precisará explicar seus requisitos ao computador.

Uma das abordagens mais discutidas para a geração automatizada de código é o "MDA", também conhecido como arquitetura orientada a modelos. Principalmente (mas não necessariamente), é apresentado o UML através do editor visual da GUI a partir do qual as classes relevantes são geradas.

Embora eu ache que a expressão de código totalmente funcional ainda esteja longe, existem sistemas suficientemente bons que geram esqueletos completos.

Confira: http://www.actifsource.com/actifsource/index.html

Também: http://www.win.tue.nl/~mchaudro/cbse2007/programgenerators.pdf

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

Eu escrevi muitos geradores de código para Java e C # que produzem código de trabalho para várias tarefas. Existem pacotes como o JAXB, que analisa um documento XML e produz as classes Java correspondentes e o código de marshalling / unmarshalling para fazer a tradução, e o Entity Framework que produz classes de DTO para organizar os dados de / para um banco de dados. Também existem ferramentas como o Rational XDE (como é chamado agora) que geram códigos de ida e volta entre um diagrama de classes e Java.

Se você está procurando algo que possa pegar requisitos de negócios ou especificações funcionais e transformá-lo em código, não vi muito progresso nessa área. Eu sei que o OMG está trabalhando em algum tipo de "UML executável", mas, além de alguns protótipos do DoD, não conheço nenhuma implementação prática.

A programação declarativa conta, por exemplo, Prolog ou SQL?

Você acabou de descrever o que o programa deve realizar ou quais condições os resultados devem satisfazer. Então você consulta o sistema e obtém resultados (ou "sem soluções").

Obviamente, existe um programa em execução, mas você nunca vê o código.

Infelizmente, a programação declarativa não é uma bala de prata: além de casos elementares, descrever a meta declarativa com precisão suficiente ainda exige esforço e habilidade consideráveis, sem mencionar que, para obter um desempenho decente, é necessário levar em consideração várias imperfeições do real, implementação sob o capô (por exemplo, entendendo o papel dos índices SQL ou da chamada final em definições recursivas ...)

Dependendo do tipo do problema, seria realmente mais fácil resolver o "como" do que descrever com precisão o "o quê". Para os seres humanos, ou pelo menos para a maioria dos programadores comuns, pensar em "como" parece vir mais naturalmente e "o que exatamente" requer mais ginástica mental.

Discordo da sua afirmação de que "linguagem imperativa ... essa é a parte mais difícil". Essa é a parte mais fácil, embora seja consideravelmente mais fácil em alguns idiomas do que em outros. Descobrir o que os usuários realmente querem e organizar todas essas informações é a parte mais difícil. A parte "Linguagem imperativa" parece difícil porque é quando todo o trabalho real é feito. É quando as perguntas detalhadas sobre os requisitos aparecem e quando todas as respostas precisam ser organizadas em uma definição de sistema executável.

Não há programação sem programação. Alguém precisa traduzir desejos humanos imprecisos em uma especificação precisa de um cálculo. Essa especificação pode estar na linguagem assembly, ou Java ou LISP, em algum sistema diagramático ou em uma linguagem ainda a ser inventada. Mas até que os computadores sejam capazes de se comunicar profundamente com os seres humanos, alguém terá que conversar com os usuários e definir com precisão o sistema.

Nós já estamos lá! Tudo o que precisamos é de uma linguagem hoje chamada de caráter homo-icônico e décadas antes "código é dados". Defina seu próprio ambiente programando de baixo para cima em vez de projetar de cima para baixo. Você poderia, por exemplo, criar suas próprias DSLs dentro do Lisp. Com a abordagem de empilhamento, você pode colocar o máximo de DSLs (camadas) um sobre o outro, conforme necessário para o seu problema específico. Essa abordagem leva você de uma representação em nível muito baixo de expressões S até a abstração de dados mais complexa que você pode imaginar. Então, o que é a escrita automática de código, se não estiver empilhando um idioma em outro?

Eu ouvi murmúrios de tentativas de derivar programas de especificações expressas usando tipos dependentes em sistemas como o Coq. Não tenho idéia de que tipo de progresso foi feito.

Quão perto chegamos da automação da escrita de código?

nenhum lugar perto de algo que valha a pena falar.

Também afirmo fortemente que também nunca chegaremos lá.

Estado da arte na automação da escrita de código? Não existe um "estado da arte". Mas há um estado de fracasso perpétuo. Até o momento, não há tentativas bem-sucedidas. Provavelmente, nunca haverá uma implementação bem-sucedida disso além de alguns exemplos com escopo muito limitado.

Isso pode ser uma coisa boa, uma vez que nos tiraria do emprego.

Aliás, para as pessoas que leem ... Não confunda a criação de algoritmos com geradores triviais de CRUD como Ruby on Rails. A geração de CRUD é a execução de um algoritmo predefinido, não a criação de um algoritmo para resolver um problema.

Existem várias ferramentas nas quais você pode fazer as coisas sem escrever nenhum código (MS Access, Filemaker). Alguns geram código em segundo plano que pode ser alterado. Isso funciona bem com aplicativos de negócios e front-ends de bancos de dados. O usuário atinge uma parede e, eventualmente, contrata um programador. A lógica fica muito complexa. Vi aplicativos da web que criam um formulário que preenche uma tabela. Isso é ótimo até que você precise de um formulário pai com um formulário filho que lide com vários registros. Nenhum deles oferece isso.

Tentando imaginar como isso funciona, se eu quiser automatizar / codificar a alteração de arquivos de imagem, vídeo ou som. Como uma GUI de banco de dados, alguém poderia criá-los para esses que geram código, em vez de apenas manipular o arquivo.

As planilhas estão lidando com tudo, desde matemática simples até estatísticas. Grave uma macro e um script é criado.

A complexidade geralmente alcança. Eventualmente, você deseja criar algo realmente novo. Difícil criar um gerador de código que crie código para algo em que ninguém mais pensou.

Com sua pergunta, acredito que você está perguntando quanto desenvolvimento futuro será capaz de minimizar a quantidade de trabalho que um desenvolvedor de software terá que fazer. Mesmo se você tiver uma IA capaz de escrever todo o seu programa, ainda precisará dizer o que fazer, assim como para um fabricante de automóveis automático, ainda precisará fornecer um plano, e esse plano exige algum trabalho.

E se você tem uma IA, ainda precisa ensiná-la e ela terá que aprender através de vários projetos. Portanto, não acho que uma IA seja adequada para esse tipo de trabalho, mas uma abordagem mais determinística, usando geradores de código. Esses geradores de código podem se tornar muito complexos, mas não precisam necessariamente empregar aprendizado de máquina.

Dito isto, já existem pesquisas nas áreas denominadas Design de Software Orientado a Recursos e Design de Software Orientado a Aspectos. Eles lidam com a montagem de aplicativos de software, selecionando alguns recursos que deveriam ter e, em seguida, o código é gerado para isso. O objetivo é ter implementações para vários recursos que aparecem repetidamente em um domínio específico e montá-las como blocos de construção, conforme adequado para seu aplicativo específico. Para o desenvolvimento da Web, por exemplo, os recursos incluiriam transações, estatísticas, escalabilidade, criação de log e tudo o que você considere características características de diferentes aplicativos da Web.

Recursos e aspectos são diferentes dos componentes, pois geralmente são preocupações transversais. Tomemos, por exemplo, log. Você não pode simplesmente pegar uma biblioteca, incluí-la no seu aplicativo e dizer que possui o log agora. Você precisa espalhar suas chamadas de registro em todo o seu código, e é aí que os geradores de código são úteis. Eu ouvi recentemente sobre tudo isso nesta entrevista em duas partes na Rádio de Engenharia de Software .

Parece que esse tipo de pesquisa está na moda na Europa, e na Alemanha em particular, mesmo na indústria, como posso dizer por experiência própria. A geração de código pode ser útil para gerar o código de infraestrutura necessário, para que o desenvolvedor possa se concentrar exclusivamente na implementação do comportamento específico de seu aplicativo e não se preocupar com os mesmos problemas secundários em cada projeto diferente.

Resta ver quanto esse código específico do aplicativo pode ser reduzido. Certamente não pode ser eliminado completamente, apenas reduzido a algum tipo de projeto, como mencionei no começo.