Quanto siamo vicini all'automazione della scrittura del codice? [chiuso]

Le lingue specifiche del dominio sono più vicine che mai avremo.

Dovrai sempre dare al computer alcune regole con cui lavorare. Ma più quelle regole sono definite in un modo specifico per il loro dominio, minore sarà l'input che ci sarà.

I linguaggi specifici del dominio che hanno come target lo sviluppo web richiedono meno codice rispetto alle lingue più generiche. Le lingue specifiche del dominio che hanno come target i test richiedono meno codice rispetto alle lingue che non lo fanno. I linguaggi specifici del dominio che hanno come target la genetica richiedono meno codice rispetto alle lingue che non lo sono. E così via.

Ora, ecco la grande domanda: quando un dominio diventa abbastanza grande da giustificare la scrittura di un linguaggio specifico del dominio per esso? Lo sviluppo e il test del web sono cose su cui almeno la metà del mondo di sviluppo sta lavorando. Era inevitabile che i framework si innescassero, riducendo la quantità di codice boilerplate per queste cose (che è, in sostanza, un linguaggio specifico del dominio).

Ma che dire del dominio commerciale della tua azienda? Vale la pena concentrarsi sulle cose che sono comunemente menzionate nella tua azienda e fare in modo che tu possa fare facilmente riferimento a queste cose nel codice? Non penso che abbiamo ancora trovato questo equilibrio, sebbene design basato sul dominio riguardi la risposta a questa domanda.

Negli anni '80 e '90 c'era un sacco di buzz sulle cosiddette lingue di quarta generazione . Dall'articolo di Wikipedia:

All 4GLs are designed to reduce programming effort, the time it takes to develop software, and the cost of software development. They are not always successful in this task, sometimes resulting in inelegant and unmaintainable code. However, given the right problem, the use of an appropriate 4GL can be spectacularly successful

...

A number of different types of 4GLs exist:

• Table-driven (codeless) programming, usually running with a runtime framework and libraries. Instead of using code, the developer defines his logic by selecting an operation in a pre-defined list of memory or data table manipulation commands. In other words, instead of coding, the developer uses Table-driven algorithm programming (See also control tables that can be used for this purpose). A good example of this type of 4GL language is PowerBuilder. These types of tools can be used for business application development usually consisting in a package allowing for both business data manipulation and reporting, therefore they come with GUI screens and report editors. They usually offer integration with lower level DLLs generated from a typical 3GL for when the need arise for more hardware/OS specific operations.
• Report-generator programming languages take a description of the data format and the report to generate and from that they either generate the required report directly or they generate a program to generate the report. See also RPG
• Similarly, forms generators manage online interactions with the application system users or generate programs to do so.
• More ambitious 4GLs (sometimes termed fourth generation environments) attempt to automatically generate whole systems from the outputs of CASE tools, specifications of screens and reports, and possibly also the specification of some additional processing logic.
• Data management 4GLs such as SAS, SPSS and Stata provide sophisticated coding commands for data manipulation, file reshaping, case selection and data documentation in the preparation of data for statistical analysis and reporting.

È interessante confrontare 4GL con linguaggi di programmazione di quinta generazione :

A fifth-generation programming language (abbreviated 5GL) is a programming language based around solving problems using constraints given to the program, rather than using an algorithm written by a programmer. Most constraint-based and logic programming languages and some declarative languages are fifth-generation languages.

While fourth-generation programming languages are designed to build specific programs, fifth-generation languages are designed to make the computer solve a given problem without the programmer. This way, the programmer only needs to worry about what problems need to be solved and what conditions need to be met, without worrying about how to implement a routine or algorithm to solve them. Fifth-generation languages are used mainly in artificial intelligence research. Prolog, OPS5, and Mercury are examples of fifth-generation languages.

In definitiva, anche se non "programmi" il computer, qualcuno deve ancora spiegare i tuoi requisiti al computer.

Uno degli approcci più discussi alla generazione automatica di codice è "MDA" a.k.a Architettura guidata dal modello. Principalmente (ma non necessariamente) si mette UML attraverso l'editor GUI visivo da cui vengono generate le classi rilevanti.

Mentre, penso che l'espressione del codice pienamente funzionale potrebbe essere ancora lontana, ci sono sistemi abbastanza buoni che generano scheletri completi.

Controlla: link

Inoltre: link

link

Ho scritto molti generatori di codice per Java e C # che producono codice funzionante per varie attività. Esistono pacchetti come JAXB, che analizzano un documento XML e producono corrispondenti classi Java e codice di marshalling / unmarshalling per eseguire la traduzione, e Entity Framework che produce classi DTO per il marshalling dei dati da / verso un database. Ci sono anche strumenti come Rational XDE (di qualunque cosa si chiami ora) che generano codice di andata e ritorno tra un diagramma di classe e Java.

Se stai cercando qualcosa che possa soddisfare i requisiti aziendali o le specifiche funzionali e trasformarlo in codice, non ho visto molti progressi in quest'area. So che OMG sta lavorando su una sorta di "UML eseguibile", ma a parte alcuni prototipi DoD non conosco alcuna implementazione pratica.

Il conteggio programmazione dichiarativa , ad es. Prolog o SQL?

Descrivi solo che cosa dovrebbe realizzare il programma o quali condizioni dovrebbero soddisfare i risultati. Quindi chiedi al sistema e ottieni risultati (o "nessuna soluzione").

Ovviamente sotto il cofano, c'è un programma in esecuzione, ma non si vede mai il codice.

Sfortunatamente la programmazione dichiarativa non è una pallottola d'argento: al di là dei casi elementari, descrivere l'obiettivo dichiarativo con sufficiente precisione richiede ancora considerevoli sforzi e abilità, per non parlare del fatto che per ottenere prestazioni decenti, bisogna tenere conto delle varie imperfezioni di l'implementazione effettiva, sotto la cappa (ad esempio, la comprensione del ruolo degli indici SQL o della coda di chiamata nelle definizioni ricorsive ...)

A seconda del tipo di problema, in realtà potrebbe essere più semplice risolvere il "come" piuttosto che descrivere con precisione il "cosa". Per gli umani, o almeno per la maggior parte dei programmatori, pensare a "come" sembra venire più naturale, e "cosa esattamente" richiede più ginnastica mentale.

Non sono d'accordo con la tua affermazione che "linguaggio imperativo ... è la parte difficile". Questa è la parte facile, anche se è notevolmente più semplice in alcune lingue rispetto ad altre. Capire cosa vogliono veramente gli utenti e organizzare tutte queste informazioni è la parte difficile. La parte "linguaggio imperativo" sembra difficile perché è quando tutto il lavoro reale viene fatto. In questo modo vengono visualizzate le domande dettagliate sui requisiti e quando tutte le risposte devono essere organizzate in una definizione di sistema eseguibile.

Non c'è programmazione senza programmazione. Qualcuno deve tradurre imprecisi desideri umani in una specifica precisa di un calcolo. Quella specifica può essere in linguaggio assembly, o Java, o LISP, qualche sistema diagrammatico o una lingua ancora da inventare. Ma finché i computer non saranno in grado di comunicare in profondità con gli umani, qualcuno dovrà parlare con gli utenti e definire con precisione il sistema.

Siamo già lì! Tutto ciò di cui abbiamo bisogno è un linguaggio con l'odierno carattere homo-iconic e decenni prima "codice è dati". Definisci il tuo ambiente con la programmazione bottom-up, invece di progettare top-down. Ad esempio potresti creare i tuoi DSL all'interno di Lisp. Con l'approccio di Stacking potresti mettere tanto DSL (livelli) uno sopra l'altro come se fosse necessario per il tuo problema specifico. Questo approccio ti porta da una rappresentazione a livello molto basso delle S-espressioni fino alla più complessa astrazione di dati che puoi mai immaginare. Quindi, qual è la scrittura automatica del codice, se non si impila una lingua su un'altra?

Ho sentito mormorii di tentativi di derivare programmi da specifiche espresse usando tipi dipendenti in sistemi come Coq. Non ho idea di che tipo di progresso sia stato fatto, però.

How close have we gotten to automating code writing?

no dove vicino a qualcosa di cui vale la pena parlare.

Ho anche affermato con forza che non ci arriveremo mai.

Stato dell'arte nell'automazione della scrittura del codice? Non esiste uno "stato dell'arte". Ma c'è uno stato di perenne fallimento. Non ci sono tentativi riusciti finora. Molto probabilmente non ci sarà mai un'implementazione di successo di questo diverso da alcuni esempi che hanno uno scopo molto limitato.

Potrebbe essere una buona cosa dal momento che ci metterebbe fuori dal lavoro.

BTW alle persone che leggono .... Non confondere la creazione dell'algoritmo con generatori CRUD banali come Ruby on Rails. La generazione CRUD è l'esecuzione di un algoritmo predefinito, non la creazione di un algoritmo per risolvere un problema.

Ci sono diversi strumenti in cui puoi fare cose senza scrivere alcun codice (MS Access, Filemaker). Alcuni generano codice sullo sfondo che può essere modificato. Funziona bene con le app aziendali e i front-end del database. L'utente colpisce un muro e alla fine assume un programmatore. La logica diventa troppo complessa. Ho visto app Web che creano un modulo che popola un tavolo. Ciò è eccezionale finché non è necessario un modulo padre con un modulo figlio che gestisca più record. Nessuno di loro offre questo.

Cercando di immaginare come funziona se voglio automatizzare / codificare l'alterazione di immagini, video o file audio. Come una GUI del database, qualcuno potrebbe crearli per questi che generano codice invece di manipolare il file.

I fogli di calcolo stanno gestendo tutto, dalla semplice matematica alla statistica abbastanza bene. Registra una macro e viene creato uno script.

La complessità raggiunge di solito. Alla fine, vuoi creare qualcosa di veramente nuovo. È difficile costruire un generatore di codice che crea codice per qualcosa a cui nessun altro pensava.

Con la tua domanda, credo che tu stia chiedendo in che misura lo sviluppo futuro sarà in grado di minimizzare la quantità di lavoro che uno sviluppatore di software dovrà fare. Anche se hai un'intelligenza artificiale in grado di scrivere tutto il tuo programma, devi ancora dirgli cosa fare, proprio come per un costruttore di macchine automatiche, devi comunque dargli un progetto e quel progetto richiede del lavoro.

E se hai un'intelligenza artificiale, devi ancora insegnarla e dovrà imparare attraverso diversi progetti. Pertanto, non credo che un'intelligenza artificiale sia adatta a questo tipo di lavoro, ma piuttosto un approccio più deterministico, utilizzando i generatori di codice. Questi generatori di codice possono diventare molto complessi, ma non devono necessariamente utilizzare l'apprendimento automatico.

Detto questo, esiste già una ricerca nelle aree denominate Design del software orientato alle funzionalità e Design del software orientato agli aspetti. Questi si occupano di assemblare applicazioni software selezionando alcune funzionalità che dovrebbero avere e quindi il codice viene generato per quello. L'obiettivo è disporre di implementazioni per diverse funzionalità che appaiono ripetutamente in un particolare dominio e assemblarle come blocchi predefiniti, come adatti per la tua particolare applicazione. Ad esempio, per lo sviluppo web, le funzionalità includono transazioni, statistiche, scalabilità, registrazione e qualsiasi altra cosa tu possa pensare come caratteristiche ricorrenti di diverse applicazioni Web.

Le caratteristiche e gli aspetti sono diversi dai componenti, poiché di solito sono preoccupazioni trasversali. Prendi ad esempio la registrazione. Non puoi semplicemente prendere una biblioteca e includerla nella tua applicazione e dire che ora hai la registrazione. Devi diffondere le tue chiamate di registrazione su tutto il tuo codice, ed è qui che i generatori di codice sono a portata di mano. Di recente ho sentito parlare di tutte queste cose da questo in due parti intervista su Radio di ingegneria del software .

Sembra che questo tipo di ricerca sia piuttosto alla moda in Europa, e in particolare in Germania, anche nel settore, come posso dire per esperienza personale. La generazione del codice può essere utile per generare il codice dell'infrastruttura necessario, in modo che lo sviluppatore possa concentrarsi esclusivamente sull'implementazione del comportamento specifico della sua applicazione e non preoccuparsi degli stessi problemi collaterali su ogni progetto diverso.

Resta da vedere quanto quel codice specifico per l'applicazione possa essere ristretto. Certamente non può essere eliminato completamente, ma ridotto a una sorta di progetto, come ho detto all'inizio.