In che modo l'aumento della complessità dei sistemi ha influenzato generazioni successive di programmatori?

it just isn't necessary because of the increased amount of processing power and memory available.

Avere poca memoria, enormi dischi e processori veloci non è l'unica cosa che ha liberato le persone dal bisogno di ossessionare su ogni byte e ciclo. I compilatori sono ora molto, molto meglio degli umani nella produzione di codice altamente ottimizzato quando è importante.

Inoltre, non dimentichiamo per cosa stiamo effettivamente cercando di ottimizzare, che è il valore prodotto per un dato costo. I programmatori sono molto più costosi delle macchine. Tutto ciò che facciamo, fa sì che i programmatori producano programmi operativi, corretti, solidi e completi, più veloci e meno costosi, per creare più valore nel mondo.

My question though is how do people feel about this "hiding" of lower-level elements. Do you older programmers see it as a godsend or an unnecessary layer to get through?

È assolutamente necessario fare qualsiasi lavoro. Scrivo analizzatori di codici per vivere; se dovessi preoccuparmi dell'allocazione del registro o della programmazione del processore o di uno qualsiasi di quei milioni di altri dettagli, non spenderei il mio tempo per correggere bug, rivedere i rapporti sul rendimento, aggiungere funzionalità e così via.

Tutta la programmazione riguarda l'astrazione del livello sottostante, al fine di creare uno strato più prezioso su di esso. Se fai un "diagramma a strati" che mostra tutti i sottosistemi e come sono costruiti l'uno sull'altro, scoprirai che ci sono letteralmente dozzine di livelli tra l'hardware e l'esperienza dell'utente. Penso che nel diagramma a torta del livello Windows ci siano qualcosa come 60 livelli di sottosistemi necessari tra l'hardware grezzo e la possibilità di eseguire "Ciao mondo" in C #.

Do you think younger programmers would benefit more learning low-level programming BEFORE exploring the realms of expansive libraries?

Metti l'accento su PRIMA, quindi devo rispondere alla tua domanda in senso negativo. Sto aiutando un amico di 12 anni a imparare a programmare in questo momento e faresti meglio a credere che li sto iniziando in Elaborazione. js e non x86 assemblatore. Se inizi un giovane programmatore in qualcosa come Processing.js , scriveranno i loro giochi sparatutto in circa otto ore. Se li avvii in assembler moltiplicheranno tre numeri insieme in circa otto ore. Quale pensi sia più probabile che interessi l'interesse di un programmatore più giovane?

Ora se la domanda è "i programmatori che capiscono il livello n della torta traggono beneficio dalla comprensione del livello n-1?" la risposta è sì, ma è indipendente dall'età o dall'esperienza; è sempre il caso che puoi migliorare la tua programmazione di livello superiore comprendendo meglio le astrazioni sottostanti.

Avevo idee su questo argomento e ho li ho messi in un libro di 20 anni fa . È esaurito a lungo, ma puoi ottenere ancora copie su Amazon .

Una semplice risposta alla tua domanda è antica quanto Aristotele: La natura aborre il vuoto . Per quanto le macchine siano diventate sempre più veloci, il software è diventato sempre più lento.

Per essere più costruttivo, quello che ho proposto è che la teoria dell'informazione e la sua diretta rilevanza per il software facciano parte dell'educazione informatica. Viene insegnato solo ora, se non del tutto, in modo molto tangenziale.

Ad esempio, il comportamento big-O degli algoritmi può essere compreso in modo molto intuitivo e intuitivo se si pensa a un programma come un canale di informazioni di tipo Shannon, con simboli di input, simboli di output, rumore, ridondanza e larghezza di banda.

D'altra parte, la produttività di un programmatore può essere compresa in termini simili usando la teoria dell'informazione di Kolmogorov. L'input è una struttura concettuale simbolica nella tua testa, e l'output è il testo del programma che viene fuori attraverso la punta delle dita. Il processo di programmazione è il canale tra i due. Quando il rumore entra nel processo, crea programmi (bug) incoerenti. Se il testo del programma di output ha una ridondanza sufficiente, può consentire che i bug vengano rilevati e corretti (rilevamento e correzione degli errori). Tuttavia, se è troppo ridondante è troppo grande e la sua stessa dimensione, combinata con il tasso di errore, causa l'introduzione di bug. Come risultato di questo ragionamento, ho passato una buona parte del libro che mostra come trattare la programmazione come un processo di design del linguaggio , con l'obiettivo di essere in grado di definire i linguaggi specifici del dominio appropriati per un bisogno. Facciamo un servizio a parole a lingue specifiche del dominio nell'educazione CS, ma, di nuovo, è tangenziale.

Costruire le lingue è facile. Ogni volta che definisci una funzione, una classe o una variabile, aggiungi del vocabolario alla lingua con cui hai iniziato, creando una nuova lingua con cui lavorare. Ciò che non è generalmente apprezzato è che l'obiettivo dovrebbe essere quello di avvicinare maggiormente la nuova lingua alla struttura concettuale del problema. Se questo è fatto, allora ha l'effetto di accorciare il codice e renderlo meno bacato semplicemente perché, idealmente, esiste una mappatura 1-1 tra concetti e codice. Se la mappatura è 1-1, potresti commettere un errore e codificare un concetto in modo errato come un concetto diverso, ma il programma non si arresta mai, cosa che accade quando codifica nessun requisito coerente .

Non stiamo ottenendo questo. Per tutti i nostri discorsi coraggiosi sulla progettazione del sistema software, il rapporto tra il codice e le esigenze sta diventando più grande, molto più grande.

È vero, abbiamo librerie molto utili. Tuttavia, penso che dovremmo essere molto cauti riguardo all'astrazione. Non dovremmo assumere se B si basa su A e questo è buono, che se C si basa su B è ancora meglio. Lo chiamo fenomeno "principessa e pisello". Accatastare gli strati sopra a qualcosa di problematico non lo risolve necessariamente.

Per terminare un post lungo, ho sviluppato uno stile di programmazione (che a volte mi mette nei guai) dove

• L'invenzione non è una brutta cosa. È una buona cosa, come lo è in altri rami dell'ingegneria. Certo, potrebbe essere la creazione di una curva di apprendimento per gli altri, ma se il risultato complessivo è una migliore produttività, vale la pena.
• Codice minimalista stile Haiku. Che in particolare valga per la progettazione della struttura dei dati. Nella mia esperienza, il problema più grande del software in questi giorni è la struttura dei dati gonfia.

L'astrazione di alto livello è essenziale per ottenere progressi continui nell'informatica.

Perché? Perché gli umani possono avere solo tanta conoscenza nelle loro teste in ogni dato momento. I moderni sistemi su larga scala sono possibili solo oggi perché puoi sfruttare tali astrazioni. Senza tali astrazioni, i sistemi software semplicemente collasserebbero sotto il loro stesso peso.

Ogni volta che scrivi un metodo, stai creando un'astrazione. Stai creando un po 'di funzionalità nascosta dietro una chiamata di metodo. Perché li scrivi? Perché puoi testare il metodo, dimostrare che funziona, e quindi invocare quella funzionalità ogni volta che vuoi semplicemente facendo la chiamata al metodo, e non devi più pensare al codice che si trova all'interno di quel metodo.

Nei primi giorni dell'informatica, abbiamo usato il linguaggio macchina. Abbiamo scritto programmi in metallo molto piccoli, con una conoscenza approfondita dell'hardware per il quale li stavamo scrivendo. È stato un processo meticoloso. Non c'erano debugger; il tuo programma di solito ha funzionato o è andato in crash. Non c'era GUI; tutto era a riga di comando o in batch. Il codice che hai scritto avrebbe funzionato solo su quella particolare macchina; non funzionerebbe su una macchina con un processore o sistema operativo diverso.

Quindi abbiamo scritto linguaggi di alto livello per astrarre tutti quei dettagli. Abbiamo creato macchine virtuali in modo che i nostri programmi possano essere trasferiti su altre macchine. Abbiamo creato la garbage collection in modo che i programmatori non dovessero essere così diligenti nella gestione della memoria, eliminando un'intera classe di bug difficili. Abbiamo aggiunto i limiti di controllo alle nostre lingue in modo che gli hacker non potessero sfruttarle con sovraccarico del buffer. Abbiamo inventato la programmazione funzionale in modo da poter ragionare sui nostri programmi in un modo diverso, e riscoprirla di recente per sfruttare meglio la concorrenza.

Tutta questa astrazione ti isola dall'hardware? Certo che lo fa Vivere in una casa invece di piantare una tenda ti isola dalla natura? Assolutamente. Ma tutti sanno perché vivono in una casa invece che in una tenda, e costruire una casa è una partita di palla completamente diversa rispetto a una tenda.

Tuttavia, è ancora possibile montare una tenda quando è necessario farlo, e in fase di programmazione, è possibile (se si è così inclini) scendere ancora a un livello più vicino all'hardware per ottenere prestazioni o vantaggi di memoria che altrimenti non potresti raggiungere il tuo linguaggio di alto livello.

Puoi astrarre troppo? "Overtake the plumbing", come direbbe Scotty ? Certo che puoi. Scrivere buone API è difficile. Scrivere buone API che incarnino correttamente e in modo completo il dominio del problema, in modo intuitivo e rilevabile, è ancora più difficile. Accumulare nuovi livelli di software non è sempre la soluzione migliore. Modelli di progettazione software hanno, in certa misura, peggiorato questa situazione, perché gli sviluppatori inesperti a volte li raggiungono quando sono più nitidi, più snelli lo strumento è più appropriato.

Un allenamento davvero valido coinvolge entrambi gli estremi, oltre a un ponte tra.

Sul lato di basso livello: come un computer esegue il codice da zero *, inclusa la conoscenza del linguaggio assembly e cosa sta facendo un compilatore.

Sul lato di alto livello: concetti generali, ad es. utilizzando array associativi, chiusure, ecc. senza perdere tempo a preoccuparsi di come funziona sotto il cofano.

IMHO tutti dovrebbero avere esperienza con entrambi, compresi i loro inconvenienti, e un assaggio di come ottenere da concetti di basso livello a concetti di alto livello. Ami gli array associativi? Bene, ora prova a usarli su un processore embedded da 50 centesimi con 1kB di RAM. Ti piace scrivere codice veloce usando C? Bene, ora hai tre settimane per scrivere un'app web; puoi passare il tuo tempo ad occuparti di strutture dati e gestione della memoria usando C, oppure puoi passare il tuo tempo ad imparare un nuovo framework web e poi implementare l'app web in pochi giorni.

Per quanto riguarda l'aspetto della complessità, penso: in questi giorni è troppo facile realizzare sistemi complessi senza comprensione chiara del costo di ciò . Di conseguenza, come società, abbiamo accumulato una quantità enorme di debito tecnico che ci morde di volta in volta . È come terremoti (solo il costo della vita vicino a una faglia geologica, giusto?), Solo che sta gradualmente peggiorando. E non so cosa fare al riguardo. Idealmente impareremmo e miglioreremmo nella gestione della complessità, ma non penso che succederà. Un'educazione ingegneristica responsabile deve includere molte più discussioni sulle conseguenze della complessità rispetto a quanto la maggior parte delle nostre università sta attualmente fornendo.

* e, comunque, dov'è il "terreno" in cui un computer esegue il codice? È un linguaggio di assemblaggio? O architettura del computer? O logica digitale? O transistor? O fisica del dispositivo?

Ritengo che la programmazione di alto livello abbia molti vantaggi ed è una parte essenziale di un linguaggio di programmazione. Uno dei motivi per cui Java ha avuto successo è che ha una libreria completa. Ottieni di più con meno codice: chiama solo una funzione predefinita.

Ora possiamo distinguere gli utenti del linguaggio di programmazione dagli scrittori del linguaggio di programmazione (scrittori di compilatori). Lasciamo le ottimizzazioni agli scrittori di compilatori. Ci concentriamo maggiormente sulla manutenibilità, il riutilizzo, ecc.

L'aumento della complessità dei sistemi è implacabile, opprimente e in ultima analisi paralizzante. Per me, come programmatore di vecchia generazione, è anche amaramente deludente.

Ho programmato per oltre 40 anni, avendo scritto codice in 50-100 lingue o dialetti diversi, e sono diventato esperto in 5-10. Il motivo per cui posso rivendicare così tanti è che per lo più sono solo la stessa lingua, con modifiche. Le modifiche apportano complessità, rendendo ogni lingua solo leggermente diversa.

Ho implementato gli stessi algoritmi innumerevoli volte: collezioni, conversioni, ordinamento e ricerca, codifica / decodifica, formato / analisi, buffer e stringhe, aritmetica, memoria, I / O. Ogni nuova implementazione aggiunge complessità, perché ognuno è solo leggermente diverso.

Mi chiedo alla magia creata dagli alti trapezisti volanti dei framework web e delle app mobili, su come possano produrre qualcosa di così bello in così poco tempo. Poi mi rendo conto di quanto non sanno, quanto avranno bisogno di apprendere su dati o comunicazioni o test o discussioni o altro prima che ciò che fanno diventino utili.

Ho imparato il mio mestiere nell'era dei linguaggi di quarta generazione, in cui credevamo sinceramente che avremmo prodotto una serie di linguaggi di livello superiore e superiore per acquisire progressivamente sempre più parti ripetitive del software di scrittura. Quindi, come è andata a finire, esattamente?

Microsoft e IBM hanno ucciso quell'idea tornando a C per scrivere app per Windows e OS / 2, mentre dBase / Foxpro e persino Delphi languivano. Poi il web lo ha fatto di nuovo con il suo ultimo trio di linguaggi assembly: HTML, CSS e JavaScript / DOM. È stato tutto in discesa da lì. Sempre più lingue e più librerie e più framework e più complessità.

Sappiamo che dovremmo farlo in modo diverso. Sappiamo di CoffeeScript e Dart, su Less e Sass, sul modello per evitare di dover scrivere HTML. Lo sappiamo e lo facciamo lo stesso. Abbiamo le nostre strutture, piene di astrazioni che perdono, e vediamo quali meraviglie possono essere fatte da quei pochi eletti che imparano gli incantesimi arcani, ma noi ei nostri programmi siamo intrappolati dalle decisioni prese nel passato. È troppo complicato da modificare o ricominciare da capo.

Il risultato è che le cose che dovrebbero essere facili non sono facili, e le cose che dovrebbero essere possibili sono quasi impossibili, a causa della complessità. Posso stimare il costo di apportare modifiche per implementare una nuova funzionalità in una base di codice stabilita e confidare che avrò ragione. Posso stimare, ma non posso giustificarlo o spiegarlo. È troppo complicato.

In risposta alla tua domanda finale, consiglierei caldamente ai programmatori più giovani di iniziare il più in alto possibile sulla torta di strati, e si immergerebbero solo negli strati inferiori in quanto il bisogno e il desiderio forniscono l'impulso. La mia preferenza è per le lingue senza loop, poca o nessuna ramificazione e stato esplicito. Lisp e Haskell vengono in mente. In pratica finisco sempre con C # / Java, Ruby, Javascript, Python e SQL perché è lì che si trovano le comunità.

Parole finali: la complessità è l'ultimo nemico! Batti questo e la vita diventa semplice.

My question though is how do people feel about this "hiding" of lower-level elements. Do you older programmers see it as a godsend or an unnecessary layer to get through?

Neanche, davvero.

Il layering è necessario perché senza di esso si raggiunge un punto in cui il sistema diventa spaghetti non mantenibile. È anche uno dei principi della riusabilità: se lo sviluppatore di una biblioteca ha fatto un buon lavoro, le persone che lo utilizzano non dovrebbero preoccuparsi dei dettagli dell'implementazione. La quantità di codice in scatola che usiamo nei nostri sistemi è cresciuta di ordini di mana da quello che era quando ho scritto il mio primo programma 35 anni fa. Questa crescita significa che siamo in grado di fare cose più potenti col passare del tempo. Questo è buono.

Il luogo in cui è stato un problema per me è del tutto culturale. La mia parte pragmatica comprende che non è più possibile avvolgere la mia mente in ogni dettaglio e riuscire a finire le cose che voglio fare. (Invecchiando non aiuta neanche). La mia irascibile metà di Barbanera ha avuto difficoltà a lasciar andare molti anni di avere una comprensione così raffinata di tutto ciò su cui ho lavorato.

Do you think younger programmers would benefit more learning low-level programming BEFORE exploring the realms of expansive libraries?

Come è stato sottolineato in altre risposte, c'è un equilibrio tra l'attrarre e il mantenere l'attenzione dei neofiti e il dare loro un'ideale educazione dal basso verso l'alto. Se non puoi fare il primo, quest'ultimo non può accadere.

Vedo le cose nel nostro settore che sono parallele al resto della società. In passato, quasi tutti coltivavano il proprio cibo e passavano molto tempo a farlo. Da allora, abbiamo creato specialisti chiamati agricoltori che fanno quel lavoro, liberando altri per fare altre cose che contribuiscono alla società. Compro il mio cibo in un negozio di alimentari e non sarei assolutamente in grado di produrne la maggior parte da solo se dovessi farlo. Abbiamo una cosa simile in corso, anche se su una scala temporale molto più compressa. I programmatori sono specializzati in alcuni set di livelli e non in altri. Il ragazzo medio che scrive GUI può sapere che esiste una cosa come lo spazio di swap ma probabilmente non sa o si preoccupa molto di come il sistema operativo lo sta gestendo.

Il risultato di tutto ciò è che non si tratta più solo di sviluppo. La specializzazione continua significa che gli sviluppatori dovranno continuare a migliorare le loro capacità di comunicazione e integrazione.

Come ogni cosa, un po 'ti fa bene, ma fa troppo male. Il problema è che troppi sistemi non sanno quando fermarsi - solo 1 astrazione in più, per aiutarti a programmare più velocemente ... ma poi finisci per programmare nel mondo reale dove le cose non sono mai così semplici come vuoi, e tu dedica più tempo a lavorare intorno ai bordi di quanto avresti speso con un'astrazione meno dettagliata.

È abilmente descritto qui

o qui - "con una singola riga di codice puoi aggiungere 500 utenti al dominio" .. .

Le tue astrazioni cercano di nascondere la complessità da te, ma in realtà tutto ciò che fanno è nascondere quella complessità. La complessità è ancora lì, è solo che hai molto meno controllo su di esso - ed è per questo che si finisce con questo tipo di situazione.

"se i programmatori più anziani vedono innovazioni come queste come una manna dal cielo o un ulteriore livello da estrapolare, e perché potrebbero pensarlo così?"

Ho programmato da quando ero al liceo, circa 34 anni, iniziando con Basic e Z80 Assembler, passando a C, vari linguaggi 4GL, Scheme, SQL e ora vari linguaggi web. La portata, la portata e la profondità dei problemi affrontati dalla professione hanno vissuto un periodo inflazionistico nel tempo, in particolare negli anni '90. Costrutti come librerie, framework e servizi OS sono tutti mezzi per affrontare la complessità che accompagna lo spazio esteso dei problemi. Non sono una manna dal cielo né un peso in sé e per sé - solo una continua esplorazione di un vasto spazio di soluzione.

Ma, IMHO, "innovazione" è meglio intesa in termini di nuove forme e non viene scambiata per movimenti laterali, reintroducendo forme che abbiamo già visto introdotte. In un certo senso, la fecondità di un ecosistema soffre quando le forme primitive non compongono, quando fissano decisioni prese all'inizio dell'evoluzione, o non riescono a rielaborare i propri detriti. Alcuni, se non la maggior parte, dei costrutti su cui ci concentriamo non danno la priorità al sostentamento a lungo termine del valore. Ciò ha iniziato a cambiare: approcci come Service Orientation e Domain Driven Design, per non parlare dell'ipertesto e dei modelli basati su grafici, ad esempio stanno alterando il paesaggio. Come ogni ecosistema, alla fine le forme dominanti lasceranno il posto a nuove forme; noi siamo meglio serviti consentendo la diversità, a grandi linee e in piccoli incrementi, piuttosto che una standardizzazione dall'alto verso il basso su larga scala seguita da un collasso tutto in una volta.

"E i programmatori più giovani traggono vantaggio dalla programmazione a basso livello dell'apprendimento PRIMA di esplorare i regni di librerie espansive? Se sì, allora perché?"

Direi che la maggior parte del linguaggio umano si basa su metafore dimenticate da molto tempo, quindi mentre io sostengo l'apprendimento della programmazione a basso livello da un punto di vista di alfabetizzazione scientifica / numerica, è più importante cercare le primitive che supporteranno la scala e portata dei problemi che stiamo affrontando in un modo che possiamo tranquillamente ignorare il livello più basso di dettaglio. Un framework non è un primitivo, né un sistema operativo o una libreria - sono piuttosto poveri nel fare il tipo di astrazione di cui abbiamo veramente bisogno. Un vero progresso porterà persone che (a) sanno cosa è successo prima e (b) possono pensare in un romanzo abbastanza da trovare qualcosa di abbastanza diverso da esplorare uno spazio di soluzione che non è stato esplorato prima o che è stato esplorato e dimenticato.

OTOH, anche se il tuo obiettivo è quello di lavorare come tecnico / meccanico, un certo livello di esposizione alla programmazione di basso livello sarà comunque utile per sviluppare le tue capacità di problem solving.

Il mio primo programma (da adolescente di 15 anni) era nel 1974 in PL / 1 su schede perforate per un mainframe IBM 370/168. Mio padre lavorava in IBM e ho avuto la fortuna di poter andare al data center la domenica.

All'epoca, un programma di diverse migliaia di affermazioni (cioè schede pasticciate) era un grande programma (e anche un programma pesante, dal momento che molte migliaia di schede perforate ponderavano molti chilogrammi). Le interfacce visive non esistevano (un tipico programma letto dal suo "input standard" usando un comando a schede perforate che inizia con //GO.SYSIN DD * IIRC, ma non ho imparato JCL ). Algoritmica era importante, e IIRC la libreria standard era piuttosto piccola per lo standard odierno.

Oggi, i programmi di diverse migliaia di linee sono generalmente considerati piccoli. Ad esempio, il compilatore GCC ha più di dieci milioni di righe di codice sorgente e nessuno le sta capendo completamente .

La mia sensazione è che la programmazione odierna sia molto diversa dagli anni '70, perché è necessario utilizzare molte più risorse (in particolare, le librerie esistenti e le strutture software). Tuttavia, suppongo che le persone che sviluppano software per data center (ad esempio motori di ricerca su Google) o software incorporato si preoccupino tanto di algoritmi e di efficienza rispetto al programmatore medio degli anni '70.

Continuo a pensare che la comprensione della programmazione a basso livello sia importante anche oggi (anche se la maggior parte dei programmatori non codificherà autonomamente algoritmi di base come alberi bilanciati, array ordinate in ordine dicotomico, ecc ...) perché la comprensione dell'intera immagine è ancora importante.

Una delle principali differenze tra gli anni '70 e oggi è il rapporto tra costo degli sforzi (umani) degli sviluppatori e potenza del computer.