Ci sono lingue di altissimo livello là fuori? [chiuso]


20

Storicamente un HLL è qualcosa come C, Fortran o Pascal e un VHLL è qualcosa come Ruby o Python. Conosco i termini 4GL, 5GL, DSL e LOP e coloro che non lo sono dovrebbero leggere Wikipedia per le definizioni. Sto cercando UHLL.

La mia domanda è: ci sono linguaggi informatici là fuori che sono un altro ordine di grandezza più produttivi e qualcuno ci sta lavorando?

Più produttivo significa meno codice creato e meno tempo per i programmatori per ottenere un risultato, meno bug e meno debug, collegamento concettuale più stretto tra codice e requisiti, meno sforzi per modificarli e mantenerli.

Il dominio principale che mi interessa sono le applicazioni business e consumer di uso generale, con una interfaccia grafica o un front-end del browser, la persistenza dei dati e le connessioni ad altri sistemi come la stampa e l'e-mail. Altre persone potrebbero benissimo concentrarsi altrove.

Riconosco che alcune di quelle lingue potrebbero essere specifiche del dominio e potrebbero essere poco più che la capacità di configurazione di un'applicazione ampia e capace. I fogli di calcolo di Excel rientrano in questa categoria.

Riconosco che alcune di quelle lingue potrebbero apparire generali, ma potrebbero essere di portata limitata e inadatte a molti problemi. Ad esempio, Matlab potrebbe non essere una buona scelta per un programma che si occupa principalmente di interazione dell'utente e dati testuali.

Conosco alcune delle funzionalità che potrebbero essere presenti in una UHLL, per analogia con VHLL. Mi aspetto di trovare uno o più dei seguenti (e sentiti libero di aggiungere alla lista):

  • Un disegno di un modulo GUI È il programma per un modulo GUI
  • Una tabella contenente righe, colonne e intestazioni È il programma per una tabella in un database
  • La logica dichiarativa dice cosa dovrebbe essere fatto e quando, senza istruzioni IF
  • Operazioni su set di dati, senza loop FOR
  • Esecuzione non sequenziale, ad es. Data driven, pattern matching, tree walking

La motivazione della domanda è che sono sempre più stufo del duro lavoro di tradurre requisiti aziendali relativamente semplici in grandi quantità di codice per soddisfare ciò che il computer vuole o ha bisogno. La domanda è davvero di trovare altri là fuori che condividono il mio dolore e stanno lavorando per aumentare il livello delle lingue e convincere il computer a fare di più del duro lavoro. Questa era una delle principali priorità negli anni '70 -'80, ma sta ancora accadendo?

Queste sono alcune risposte suggerite alla mia domanda, fornite qui per riassumere o enumerare le lingue che conosco e che a mio avviso non sono all'altezza.

Esistono molte lingue che sono HLL o VHLL e contengono caratteristiche individuali che appartengono a un livello superiore. Ho usato la maggior parte di loro (spesso male). Loro includono

  • Lisp, con le sue macro e la capacità di auto-modificarsi
  • Haskell, con dipendenza dei dati e pattern matching
  • SQL, che si occupa di righe e tabelle
  • Rebol, che sembra intelligente ma non capisco davvero
  • APL (e J), ​​con i suoi array multidimensionali e operatori ultracompatti
  • C # con LINQ
  • AWK / Perl / Python / Ruby con meravigliose collezioni e regex integrate

Queste lingue hanno troppe funzionalità di basso livello per essere UHLL. Il programmatore deve ancora scrivere molti costrutti di basso livello per qualsiasi programma utile.

Esistono pacchetti RAD / 4GL. Ne ho usati alcuni:

  • dBase / Foxpro
  • Dataflex / Powerflex (il mio prodotto)
  • Accesso
  • PowerBuilder

E molto altro che non ho usato. Principalmente la lingua è HLL nella migliore delle ipotesi, ma il pacchetto contiene un framework e connessioni privilegiate tra lingua e pacchetto in modo che le applicazioni possano essere costruite rapidamente. Non sono sicuro del motivo per cui questo approccio ha esaurito il vapore, ma in ogni caso UHLL non lo è.

Esistono framework / librerie non elaborati. Ne ho usati alcuni:

  • Rails
  • Java e swing
  • .NET Windows Forms, WPF e ASP.NET.

Questi sono attualmente lo stato dell'arte. Lasciano il programmatore saldamente intrappolato nel fango del linguaggio di implementazione, affrontando la complessità ad ogni angolo. Questo non è UHLL, ma è possibile concepire un UHLL sopra uno di questi.

Esistono strumenti di progettazione, come UML e il set di strumenti di Rational, che non conosco bene. Per quanto posso vedere, aiutano a articolare i requisiti aziendali ma non possono mai sostituire la fase di programmazione. Non voglio eliminare i programmatori, ma solo fare di più per unità di tempo e impegno.

Quindi, avendo eliminato tutti i contendenti che posso pensare, spero che qualcun altro possa fornire un candidato migliore.

Modifica tardiva: penso di avere una risposta: Wolfram Language. http://www.wolfram.com/wolfram-language/


2
@Phoshi: anche gli ultimi tre punti sono coperti da SQL. Solo non in un modo DWIM (fare ciò che intendo).
kdgregory,

10
Un disegno di un modulo GUI È il programma per un modulo GUI Certo, ma dov'è il codice che gestisce i clic sui pulsanti, gli aggiornamenti dell'interfaccia utente, ecc ...? Hai mai lavorato con i progettisti di moduli di Visual Studio? Scrivono ancora codice sotto le copertine, ma di solito lo sviluppatore non ha mai bisogno di guardarlo. Sviluppano semplicemente la forma "visivamente". Fatta eccezione per il codice personalizzato come i corpi dei gestori di eventi ... Una tabella contenente righe, colonne e intestazioni È il programma per una tabella in un database Che dire di tutti i trigger, indici e vincoli sulla tabella del database?
FrustratedWithFormsDesigner,

3
@FrustratedWithFormsDesigner: Eppure sei ... frustrato.
Robert Harvey,

4
@RobertHarvey: Sì. Ma non frustrato come se dovessi scrivere tutto il codice da solo. ;)
FrustratedWithFormsDesigner il

7
Cosa può essere un linguaggio di livello superiore (come nel "più astratto") di un DSL su misura per un particolare dominio problematico? E, naturalmente, ci sono alcune lingue là fuori che sono state progettate appositamente per costruire in modo efficiente tali DSL.
SK-logic,

Risposte:


33

Quasi tutti i criteri che elenchi sono cose già provate negli strumenti 4GL / RAD come MS Access, Sybase Power Builder, Oracle Forms, Ruby-on-Rails (come un campione più moderno per le app Web) e molti altri (vedi Wikipedia per un elenco molto lungo di fornitori). E in effetti, con questi strumenti è possibile ottenere molto rapidamente la conversione di requisiti aziendali relativamente semplici in un qualche tipo di programma. Ecco perché la maggior parte dei fornitori di strumenti RAD pubblicizza i propri prodotti in modo tale che tutti dovrebbero pensare di aver già inventato una UHLL nel tuo senso.

Il problema è che non appena lasci il terreno per cui i requisiti sono " relativamente semplici ", e non appena devi mantenere ed evolvere i programmi scritti con questi ambienti, noterai che raggiungi facilmente i limiti e ne noti gli svantaggi o che implementare i requisiti con essi non è in alcun modo più semplice di qualsiasi altro "VHLL" che hai in mente. IMHO c'è una buona possibilità che questi uccidano qualsiasi miglioramento di efficienza che hai avuto nella versione 1.0 quando vai oltre alle versioni 1.1, 1.2 e 1.3 del tuo programma.

Se si desidera creare software per requisiti complessi, è necessario un ambiente di programmazione complesso. Non c'è ancora nessun proiettile d'argento , abbiamo avuto solo gradualmente miglioramenti nel corso degli anni e non "l'ordine di grandezza" nella produttività con qualsiasi linguaggio di programmazione attuale rispetto ai suoi predecessori (almeno, negli ultimi 30 anni, che è circa il tempo in il passato quando è stato pubblicato l'articolo di Brook).


9
+1 per relatively simple. La logica aziendale reale tende a trasformare gli spaghetti molto rapidamente.
Bobson,

1
+1 per non appena lasci il terreno. Per me sono spesso molto simili a "costruire un blog in 5 minuti (senza scrivere codice)!" tipo di pubblicità. È fantastico, fino a quando non devi implementare qualcosa che assomigli a un vero programma, e poi improvvisamente ciò che pensavi fosse una cosa semplice non lo è. Forse sono fantastici e non li capisco, ma il marketing rende davvero difficile credere che non sia solo un pasticcio più grande quanto più vai avanti.
BrianH,

Si, lo so. Ho scritto codice nella maggior parte di quei 4GL e molti altri. Quelli che ho usato fanno il ridimensionamento, ma lo fanno perché contengono un HLL non molto buono incorporato, come VBA. E tutti hanno dei limiti e, essendo prodotti chiusi, non è possibile modificarli. Sì, Fred Brooks ha ragione, quindi un UHLL avrebbe bisogno di un intero arsenale di proiettili.
david.pfx,

Io chiamo questo "effetto Dreamweaver". Le UHLL sono solo astrazioni ultraperdibili
Charles Salvia,

14

Il linguaggio di programmazione di massimo livello che conosco è APL . Richiede una tastiera speciale per rappresentare tutti i simboli necessari. Guarda questo video , in cui l'autore scrive un'implementazione completa di Conway's Game of Life in circa sette minuti.

La vera domanda, ovviamente, è "è pratica?" Posso trovare abbastanza programmatori APL nel mondo per sostenere un business in questo modo? APL funzionerà su telefoni e tablet? Devo davvero acquistare nuove tastiere per tutti i miei sviluppatori software?

Se vuoi davvero un aumento della produttività, la tua scommessa migliore è probabilmente una variante di Lisp. Clojure viene eseguito su JVM e ha una porta .NET. Lo dico perché la gente lo ha già fatto; il motore di ricerca Orbitz gira su Lisp e Paul Graham gestiva un'intera azienda usando Lisp, sostenendo che gli dava un vantaggio significativo rispetto ai suoi concorrenti (che stavano usando tutti Java).

Tieni presente che, più è alto il tuo linguaggio di programmazione, più viene rimosso dall'hardware reale e più è probabile che tu abbia problemi di prestazioni. A meno che non abbiate compilatori davvero sofisticati, potreste comunque trovarvi a codificare porzioni critiche per le prestazioni della vostra applicazione in linguaggi più performanti e di livello inferiore di volta in volta.

E c'è ancora la questione di avere una massa critica di sviluppatori esperti nella lingua. Nonostante tutte le sue verruche, non avrai mai problemi a trovare un programmatore Java.


Nota che le lingue tradizionali sono ancora in evoluzione. Linq è stato creato allo scopo specifico di rendere più dichiarativa la programmazione basata sui dati . Diverse nuove funzionalità sono state aggiunte al linguaggio C # per far funzionare Linq; tutti hanno a che fare con il miglioramento della produttività degli sviluppatori.

Ulteriori letture
battendo le medie


Linq è un eccellente esempio del tipo di codice che intendo. Adoro scrivere if e loop come whens e select, il tutto in un'unica riga. Qualche altro esempio del genere?
david.pfx,

1
@ david.pfx: C # è piuttosto tardi per quella parte e trovo che la sua sintassi sia all'indietro (usa parole chiave SQL, ma l'ordine è diverso dove tutti gli altri usano l'ordine SQL e parole chiave / simboli più semplici). Il modo in cui possono compilarlo in SQL è comunque migliore di quello che la maggior parte delle lingue può fare.
Jan Hudec,

4
@ david.pfx: praticamente qualsiasi linguaggio funzionale con una comprensione delle liste può fare ciò che fa Linq.
Robert Harvey,

7

Penso che tu abbia accennato un po 'a un punto di incrocio che limita l'esistenza di linguaggi di altissimo livello - ad un certo punto non li identifichiamo più come linguaggi di programmazione.

Il miglior esempio di questi fenomeni specifici di cui sono a conoscenza, e che forse è di grande potenziale interesse qui, è Unified Modeling Language . In effetti, ci sono stack di applicazioni software specifici che sono stati sviluppati per fare specificamente quello che stai chiedendo. Soddisfa molte delle tue esigenze, ma non necessariamente nel modo in cui stai pensando. Tuttavia, è estremamente educativo per questa situazione, poiché mi sono sentito in modo simile e la mia esperienza (che segue) ha cambiato il modo in cui penso a questo problema.

Personalmente parlerò qui di IBM Rational Software Architect , che è un tentativo di consentire davvero lo sviluppo di altissimo livello. L'obiettivo è che tu sia in grado di creare il concetto di business filosofico come un oggetto, come un attore o una classe, dare attributi alle entità, definire connessioni, definire come le informazioni potrebbero fluire attraverso il sistema mentre vengono elaborate, e fare questo tutto con una GUI.

Ad esempio, è possibile trascinare un oggetto DataStore, un attore, un modulo, alcune classi pertinenti (come cliente, ecc.), Tracciare alcune linee di connessione tra oggetti utilizzando grafici e simili e boom: quando hai finito, pubblichi un programma di lavoro. (questo è ovviamente estremamente semplificato)

In effetti, ciò che è stato fatto è la formazione di una GUI complessa, un'implementazione / interpretazione molto approfondita di UML, quindi si compila in codice Java / C # / VB con documenti XML completi che contengono le informazioni grafiche UML e inoltre implementano / abilitano Ingegneria di andata e ritorno in modo da poter andare avanti e indietro tra Modello e Codice in modo da poter controllare le cose sia a un livello filosofico molto elevato che a un livello specifico di piattaforma molto basso.

È tutto ciò che vuoi, e di più, e non rinunci a nulla nello scambio! Giusto?

Perché non lo usano tutti?!?!

... beh, vedi, questa è la cosa. Ciò che effettivamente si ottiene è un'impresa monolitica, tutto coinvolge molte parti in movimento e magie, tutto è - o talvolta non è - influenzato da un cambiamento in uno dei tanti luoghi diversi (nella GUI, XML, livello inferiore codice, modelli UML che sono essi stessi creati / definiti / mantenuti in molti diversi livelli di modello).

È tutto davvero bello con cui giocare, ma è ... come dirlo ... ha una curva di apprendimento estremamente alta, è progettato pensando a più discipline e devi davvero trattarlo come una cosa completamente nuova che consente una generalizzabilità minima, molto limitata, per altre abilità che già possiedi.

E la linea di fondo è - anche allora, con milioni e milioni versati nel progetto da dozzine di aziende e alcuni nomi molto grandi dietro, finisci ancora con il codice in stile C sul livello eseguibile che deve essere modificato direttamente a volte , perché alcune cose semplicemente non rendono la traduzione tra descrizioni di classi orientate agli oggetti e UML fino al livello di programmazione / macchina e l'automazione non è del tutto completa.

La mia esperienza è stata che era un modo incredibilmente complicato per generare impalcature. Questa è probabilmente la cosa più crudele che dirò mai di un'impresa tecnologica così immensa, ma è quello che ne ho tratto.

Dalle persone del settore con cui ho parlato, hanno purtroppo detto la stessa cosa. La loro sensazione era che facessero molto lavoro per creare documentazione, innumerevoli diagrammi, modelli, riunioni, analisi, nel corso di mesi e mesi, quindi hanno buttato tutto fuori e il team di sviluppo ha appena scritto il codice per esso e spesso lo ha trattato ancora come Un altro raccoglitore di specifiche (che nessuno legge mai più). Quindi ora usano solo Java e alcuni software di diagrammi / visualizzazione per scopi speciali, e Agile, e questa è la fine di quella storia.

Forse questo è ingiusto e funziona quando lo fai bene. Forse, ma da consulenti e professori con cui ho parlato hanno affermato di aver trascorso molte ore in speciali seminari di sviluppo di più settimane lavorando per imparare il sistema e tornare indietro per una maggiore formazione e letteralmente passare anni per imparare come farlo lavoro e cosa va dove.

Ma forse è tutta colpa dei programmatori, che si rifiutano semplicemente di accettare che il sistema funzioni così bene e tuttavia non assomiglia affatto alla programmazione del computer. Forse i programmatori di codici puri resistono solo alla sostituzione dei loro lavori, come i produttori di candele e i vecchi tessitori, e quindi rifiutano di svolgere il loro limitato compito di Implementazione su specifica e questo rende tutti così frustrati da buttarli fuori e dire cose cattive, ed era quasi perfetto.

Ma ... penso che ci possa essere un po 'di verità, ma penso che per lo più non funzioni davvero bene. Penso che trasformi qualcosa che non è davvero così difficile per la maggior parte del tempo (programmazione per computer) e rende ancora più difficile al punto che se funziona sarebbe fantastico, ma merda santa hai molto tempo senza niente da mostra per arrivarci!

Forse funzionerebbe solo in un'azienda con oltre mille team di uomini, e forse non ci siamo ancora.

Non so.

Tuttavia, uno studio di ciò che è giusto e sbagliato, con questo approccio ai linguaggi di altissimo livello - e penso che il tipo di UML debba essere incluso in tale considerazione - deve davvero considerare cose come Rational Software Architect, in modo da evitare un potenziali sciocchi commissione.

O forse non ci resta che concedere altri 20-50 anni di duro lavoro. Non sono più ottimista sul fatto che un linguaggio di programmazione sia più il limite.

E se i linguaggi di programmazione erano il vincolo prima, ecco perché i miglioramenti ci davano un potenziale ordine di miglioramento della grandezza. Se non sono più un tale vincolo, allora è molto più probabile che qualsiasi innovazione non sia in grado di fornire un tale ordine di miglioramento. Ma non posso dire il futuro! Quindi suppongo che il resto non sia "in lavorazione", ma certamente "troppo presto per dirlo".


Pensi davvero di eliminare la codifica? Non vedo alcuna prospettiva che i requisiti aziendali vengano tradotti direttamente in codice fino a quando i computer non saranno intelligenti come noi.
david.pfx,

1
Ho avuto il dubbio piacere di lavorare con Rhapsody (mi chiedo perché IBM abbia acquistato un altro strumento simile e abbia due insiemi simili di applicazioni con il marchio IBM Rational) e la mia esperienza è che non si ridimensiona. Più persone che lavorano sullo stesso pezzo di codice sono un problema ben studiato e risolto, ma più persone che lavorano sullo stesso pezzo di UML semplicemente non funzionano.
Jan Hudec,

"Perché non lo usano tutti?!?!" - perché produce cattivi risultati. Questo è un cavallo che è stato frustato nel giro di un centimetro della sua vita. L'UML è un fallimento.
Duffymo,

1

Se ci pensate per un po ', la programmazione di livello superiore è sostanzialmente in grado di comporre parti più piccole che sono prontamente disponibili e comprovate. Fino al punto in cui il tuo programma è un codice colla molto semplice di varie librerie. Forse la colla è un DSL molto espressivo. Puoi farlo in ogni linguaggio di programmazione.

Personalmente, comincio sempre più a percepire che la soluzione alla componibilità è - contrariamente a ciò che potresti istintivamente sentire - non trovata nella programmazione orientata agli oggetti. Questo paradigma, oltre alla programmazione imperativa, offre troppa libertà ai programmatori, il che a sua volta rende troppo difficile scrivere codice facile da riutilizzare.

Piuttosto, penso che la programmazione funzionale fornisca le primitive che sono molto più adatte alla componibilità. I linguaggi di programmazione funzionale pura non consentono inoltre di definire funzioni con effetti collaterali, che non solo riducono i bug o facilitano la loro individuazione, ma rendono anche più semplice costruirli (componendoli in un sistema più grande).

Se la programmazione funzionale ti interessa, puoi dare un'occhiata ai linguaggi funzionali moderni come Haskell . Penso che il modulo Parsec fornisca un buon DSL di alto livello (si chiama libreria combinatrice in gergo funzionale) per l'analisi. Esistono anche framework di programmazione reattiva funzionale per Haskell che consentono di creare potenti GUI con poche righe di codice.


1
-1 per rispondere a una domanda "sì / no" senza dire sì o no. (E ignorando il vocabolario specifico nella domanda del PO.)
DougM,

In realtà, penso che sia giusto. L'UHLL non è per l'implementazione di funzionalità già esistenti, ma per combinarle in modi che sono troppo difficili da pensare a livello inferiore. Conosci qualche? Haskell non lo è.
david.pfx,

Grazie per la tua risposta positiva. In realtà stavo solo pensando di eliminare la risposta, dato che sono d'accordo con DougM. Non stavo suggerendo che lo stesso Haskell fosse, piuttosto penso che usare le librerie combinatrici in linguaggi di programmazione funzionale (come Haskell) sia il modo di combinare componenti già pronti.
Matthias P.

0

Mi aspetto che Lua, usato dal gioco per scrivere le proprie missioni e interfacce, soddisfi questi criteri. Esistono anche linguaggi simili (e utilità per la creazione di mappe) simili a domini utilizzati per consentire ai progettisti di livelli di dire rapidamente e facilmente "quando il giocatore parla con Bob, avvia Bob's Epic Quest".

Conosco alcuni linguaggi più esoterici che si concentrano sullo spostamento del codice per descrivere ciò che sta succedendo, non come dovrebbe essere fatto. Alcuni si concentrano su un approccio molto dichiarativo e basato sulla logica. Alcuni si concentrano sulla programmazione reattiva per farlo. Alcuni si concentrano sugli attori per farlo (specialmente per cose che devono essere parallelizzabili). Alcuni si concentrano semplicemente sul rendere la sintassi più naturale - con l'affermazione che la sintassi naturale porta a un minor numero di bug causati dalla traduzione tra linguaggio naturale e codice.

Nessuno è davvero promettente per quanto riguarda la produzione di un ordine di grandezza maggiore produttività per lo sviluppatore di rango e file.


1
Lua non sarebbe più adatta come linguaggio per la codifica di dettagli di basso livello, al di sotto della portata dell'UHLL?
david.pfx,

0

Penso che REBOL possa soddisfare tutti i tuoi criteri. Puoi creare app GUI relativamente sofisticate in diverse righe di codice, tuttavia la sua "specialità" è la creazione di DSL.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.