Le lingue attuali di oggi sono al livello giusto dell'astrazione?

Come ricercatore e scienziato, ho imparato alcune semplici regole, e la più importante è non lasciare che la mia immaginazione stabilisca dei limiti. Quello che voglio dire è che il fatto che non riesca ad immaginare un modo migliore per astrarre i problemi di oggi non significa che non esisti. Ciò non significa che un altro approccio non altererebbe completamente il modo in cui pensiamo alla programmazione e di conseguenza la mia comprensione dell'astrazione.

Nel senso del mercato, si tratta davvero di competizione. Se nessun altro ha il überlang, allora le lingue correnti ovviamente sembrano risolvere i problemi a un livello appropriato del mercato. Aspettative di ragionevole evoluzione con la tecnologia.

Se leggi alcuni dei saggi di Paul Graham su Lisp, però, vedrai che credeva che il suo vantaggio competitivo fosse un überlang, Lisp. Vedrete anche alcune affermazioni piuttosto forti sul livello di astrazione fornito da Lisp e su come si differenzia, per esempio, da Python. Esito a dare credito a tali affermazioni ... ma ha fatto 48 milioni di dollari scrivendo codice Lisp, e non l'ho fatto. Ciò aggiunge al suo credo di strada, nella mia mente.

Se supponiamo che Graham sia corretto, possiamo solo concludere che l'albero genealogico delle lingue di Fortran sta lentamente raggiungendo il livello di astrazione disponibile nel 1957 per gli utenti dei linguaggi della famiglia Lisp. Questa è un'affermazione audace, ma se è vera rispetto alle lingue odierne (i discendenti di Fortran, intendo) non sono abbastanza adeguati per le sfide odierne.

Ma Graham non deve essere nel giusto per sbilanciare lo zio Bob. Lo zio Bob ha torto se lo zio Bob non ha una conoscenza perfetta di ciò che è possibile. Quello che dobbiamo fare è in gran parte una funzione dei linguaggi che stiamo usando e del paradigma in cui lavoriamo, non il contrario.

Non ho alcun problema con il "livello" delle lingue attuali, ed ero un discepolo completo di Lisp-ism, ma tutta questa conversazione mi infastidisce.

Mi dà fastidio perché la lingua che usiamo veramente è quella che noi e altri abbiamo costruito sopra qualunque sia il compilatore o l'interprete. I nomi, i verbi, la sintassi e la semantica consistono non solo in ciò che è venuto fuori dalla scatola ma quali librerie abbiamo incluso, quali classi e metodi abbiamo definito, quali macro abbiamo scritto, quali interpreti abbiamo codificato, quali parser e generatori di codice che abbiamo scritto.

Non esiste una linea divisoria ferma tra utilizzando una lingua e creazione di una lingua. È più come un razzo che decolla nello spazio. Ad ogni punto, sta facendo uso di ciò che ha costruito in precedenza. Proprio come il razzo accelera in una direzione specifica verso l'esclusione degli altri, il nostro programma / linguaggio si basa sempre di più sul problema specifico che stiamo risolvendo. Diventa sempre più un dominio specifico per lingua (DSL).

Quindi l'intera domanda "sono le nostre lingue al giusto livello" manca il punto. Il punto è che ogni volta che programmiamo, stiamo costruendo un nuovo linguaggio, e dovremmo tutti conoscere i buoni modi per farlo, e le lingue di base dovrebbero aiutarci. Dovremmo capire che lo scopo di una lingua non è "fare cose", "manipolare oggetti", "controllare il computer", ecc. Lo scopo di una lingua è di esprimere i nostri modelli mentali in un modo efficacemente computabile.

So che la gente dirà "Beh, non era quello che doveva fare UML?" La risposta è che non poteva, proprio perché era preordinata. Un linguaggio specifico del dominio è proprio questo - specifico. Un dominio-generale-linguaggio è utile solo se può essere efficacemente trasformato in un linguaggio specifico del dominio.

Penso che una delle cose che dice è giusta.

Programming languages today are at the right level of abstraction.

Ma penso che, sebbene, in futuro, potremmo usare le stesse lingue di oggi, perché i compilatori stanno migliorando ei processori sono più veloci (dato che possono fare più calcoli al secondo), potremmo essere in grado di gestisci un livello superiore, dove non è necessario preoccuparsi dei dettagli delle prestazioni.

Questo è già successo con la maggior parte dei compiti e l'ascesa e l'ascesa di linguaggi dinamici come python e ruby, ma con il miglioramento dei compilatori potremmo essere in grado di iniziare a scrivere cose come database e forse eventualmente moduli del kernel e sistemi operativi in questo stile.

Mi viene in mente un epigramma di Alan Perlis: "Un linguaggio di programmazione è di basso livello quando i suoi programmi richiedono attenzione per l'irrilevante."

Inoltre, penso piuttosto alla programmazione come gestione della complessità piuttosto che alla gestione dei dettagli.

In così tante parole, se riusciamo a farla franca conoscendo i microcodici e qualcos'altro quando scriviamo molti software (anche se andiamo via anche con le specificità dell'hardware), cos'altro possiamo farcela? Una possibile risposta: qualunque sia il fenomeno di calcolo per cui possiamo creare un modello (pensiamo ai sistemi operativi, alle grammatiche corrispondenti, alla gestione della memoria, al flusso di dati, alla transazione della memoria del software, ecc.) E rendiamolo abbastanza generale e abbastanza flessibile da farci sentire a nostro agio nel fare la magia mentale chiama "astrarre" l'insieme di dettagli indesiderati dei complessi fenomeni di cui ci stiamo occupando.

Quindi, non penso che i linguaggi di programmazione generale di oggi siano in alcun modo vicini alle mie aspettative personali.

Ho visto un esempio di vita reale di Blub Paradox di Paul Graham su usenet. I programmatori di Lisp stavano provando a spiegare ai programmatori di Python quali erano le macro per cui erano buoni. La folla di Python ha risposto ad ogni esempio con: "Puoi fare la stessa cosa in Python". Il punto che la folla di Lisp stava cercando di fare - che il Lisp consenta ai programmatori di aggiungere le proprie strutture di controllo - è stato perso nel gruppo Python. Coloro che hanno capito le strutture di controllo hanno preso la posizione che aggiungere il proprio è stato malvagio e ha portato a un codice non gestibile.

Ciò che questo esempio dimostra è che il livello di astrazione di un linguaggio di programmazione non è la cosa più importante. Riusciamo a scrivere codice funzionante, e non perdiamo le funzionalità avanzate di Lisp perché non le abbiamo mai conosciute (e sono comunque malvagie, portano a codice illeggibile).

Che cosa sono le "lingue di oggi per tutti gli usi"? Quali sono "i nostri problemi in questo momento"? Realizzare programmi embedded in tempo reale è molto diverso dal realizzare un sistema di data mining di grandi dimensioni, che è molto diverso dal fare applicazioni web, e tutti questi ovviamente devono funzionare a diversi livelli di astrazione. Anche il software desktop generico è stato realizzato con successo con vari linguaggi come C ++, Python e Lisp, che funzionano tutti a diversi livelli - o dovremmo dire dimensioni - di astrazione.

Sembra infatti che il livello di astrazione non sia così critico; in qualche modo alcuni linguaggi sembrano funzionare meglio con determinati problemi (a volte per ovvi motivi, non è possibile scrivere codice di basso livello con linguaggi che non consentono l'accesso ai registri fisici del computer e scrivere app Web con C non elaborata è ovviamente impraticabile).

Bob Martin è un esperto OO da dentro e fuori. Mentre può scrivere cose eccellenti su questo, la sua idea del campo chiamato "programmazione" sembra essere piuttosto superficiale.

Bob Martin sees us as detail managers and our problems are at the detail level.

I nostri problemi sono al livello dei dettagli perché siamo gestori di dettaglio. Se lavorassimo ad un livello più alto di astrazione, i dettagli si prenderebbero cura di se stessi e non dovremmo più gestirli.

Sono d'accordo con lo zio Bob che non abbiamo bisogno di una MDA sulla parte superiore di un linguaggio di programmazione. Sono uno sviluppatore Java e il motivo per cui il mio codice viene generato automaticamente se il modello non è in grado di gestire le informazioni di gestione dei dettagli. Dicendo che non sono d'accordo sul fatto che UML non sia il livello appropriato di astrazione di cui abbiamo bisogno per il nostro progetto finché non ci aspettiamo che UML guidi la nostra generazione di codice. Intendo dire che per me UML è un linguaggio fantastico che dovrebbe essere usato in tutti i progetti ma MDA, MDD ecc non dovrebbe ...

Molti progetti usano solo lavagne mentre un UML leggero sarebbe stato molto più appropriato. Non hai bisogno di essere un esperto ma solo di usare il tuo cervello ed essere in grado di parlare di oggetti a livello di java e di modello. Se non conosci UML, crea solo diagrammi di classe per creare lo scheletro della tua applicazione.

Quello che uso è un UML avanzato che genera il mio codice solo quando ne ho bisogno e quale modello viene aggiornato quando eseguo il codice. Una tecnologia meravigliosa che mi consente di creare la mia architettura e quindi di iniziare a scrivere codice, tornare al mio modello e tornare di nuovo al codice senza mai perdere alcuna informazione e avere un codice ben scritto. Il meccanismo che utilizzo è la fusione di modelli incrementali sviluppata da Omondo. Nessun MDD o MDA con Omondo ma un'unione tra Java e ID UML.

Hai mai notato che UML 2.3 ha la stessa architettura di C # e Java? Ha pacchetti, classi, attributi, metodi e può anche gestire i vincoli sui metodi che sono i dettagli di gestione Zio Bob sta parlando. Il problema è che il lavoro di specifica OMG che è assolutamente fantastico riguarda il metamodello mentre vengono discussi solo i diagrammi UML. Intendo dire che UML non dovrebbe essere solo grafico o MDA, MDD. UML dovrebbe essere l'intero modello di progetto con diagrammi UML solo il visualizzatore del modello e non il modello stesso !! Il problema è che gli strumenti usano i livelli di trasformazione per creare codice e modelli e non la specifica ufficiale che è il metamodello UML 2.3 !!