Che cos'è una buona metafora della programmazione? [chiuso]

Mi riferisco a spiegare al non programmatore cos'è la programmazione. Mi sono assicurato di cercare domande simili prima di creare questo, ma i pochi che ho trovato sembravano eludere la domanda, e in particolare mi piacerebbe vedere alcune metafore o analogie. Personalmente trovo più semplice spiegare qualcosa di tecnico a qualcuno attraverso l'uso di metafore o analogie.

Il motivo per cui sono interessato a questo è perché molte persone incontrano il lavoro di un programmatore su base giornaliera, ma se chiedi alla persona media che cosa è o fa un programmatore, in realtà non lo sanno. Questo porta a certe situazioni di incomprensione (es. "[...] ma pensavo che fossi bravo con i computer!")

Mi piacerebbe davvero trovare il migliore là fuori. Vorrei poter spiegare facilmente a qualcuno la mia scelta di carriera. Certo, almeno l'idea generale.

Personalmente non ne ho uno solido, ma ci ho pensato a lungo e di solito mi sono concentrato sulla metafora del "linguaggio", dove ci capita di conoscere un linguaggio che i computer capiscono, e quindi siamo in grado di dire ai computer cosa o "insegnarli" a risolvere i nostri problemi.

Per esempio:

Immagina che in una realtà alternativa esistano robot umanoidi con intelligenza artificiale e che alcune persone siano in grado di comunicare con loro attraverso un linguaggio comune, che è una variante dell'inglese. Queste persone in grado di comunicare con i robot sono in grado di insegnare loro come risolvere determinati problemi o svolgere determinati compiti, come fare le nostre faccende.

Bene, sebbene non esistano ancora robot del genere, i programmatori dei nostri tempi sono come quelle persone, ma invece di comunicare con i robot, comunicano con i computer. I programmatori "insegnano" ai computer come eseguire determinate attività o risolvere determinati problemi mediante software che creano utilizzando questo "linguaggio comune".

I programmatori e questo "linguaggio comune" ci danno cose come e-mail, siti Web, videogiochi, elaboratori di testi, smartphone ( per dirla semplicemente ) e molte altre cose che usiamo quotidianamente.

Non intendo mettere la programmazione sul trono o altro, è solo la migliore metafora che potrei inventare.

Sono sicuro che qualcuno troverà qualche problema con questo, probabilmente è un po 'inventato, ma di nuovo è per questo che sto facendo questa domanda.

È come dover scrivere istruzioni dettagliate passo per passo su come guidare da qualche parte. Ma di solito devi aggiungere piani di emergenza per cose come "cosa succede se c'è un ingorgo" o "cosa succede se un camion si rompe nella corsia di svolta".

E a volte devi immergerti ancora di più e spiegare le regole della strada come il lato su cui guidare o cosa fare al semaforo rosso. E a volte devi anche spiegare con precisione come funziona il volante o il pedale del gas.

E di solito, una volta che hai tutto ciò descritto nei minimi dettagli, il cliente dice "è perfetto, tranne che deve lavorare per qualcuno alla guida di un hovercraft"

Scrivo istruzioni molto, molto dettagliate per una macchina molto, molto stupida.

Uso la metafora "Scriviamo ricette per maglieria " che è nonna amichevole.

Fondamento logico:

• Il lavoro a maglia è un processo meccanico piuttosto semplice in cui in pratica è necessario seguire esattamente le istruzioni dettagliate per ottenere qualcosa da esso.
• La maggior parte delle istruzioni per maglieria sono per taglie multiple. Questo ti dà ifdichiarazioni, matematica e loop.
• Puoi trovare l'errore nella ricetta quando l'esercito di nonne arrabbiate arriva con i suoi maglioni buggy!

Un'analogia non molto buona, ma quando le persone mi dicono di riparare la loro macchina, dico "Sono il ragazzo che progetta le macchine. Non sono il meccanico!"

Da bambino, ho letto un'ottima descrizione della programmazione: è come dire a un robot come svolgere un compito comune e quotidiano, come andare a scuola. Quindi puoi dirlo a "Vai a scuola!", Ma non sa come. Quindi gli dici di "uscire, svoltare a sinistra, continuare a camminare fino a quando non si viene a scuola, svoltare a sinistra, entrare e sedersi". Ma c'è una strada in mezzo! Quindi devi dirgli di "fermarti alla strada, controllare che non ci sia traffico, attraversare la strada e continuare a camminare" da qualche parte nel mezzo lì. E le porte? Quindi aggiungi "controlla se la porta della scuola è aperta. In caso contrario, aprila". lì dentro. Alla fine, hai un programma che può dire al tuo robot come andare a scuola da solo.

Questo si combina perfettamente con il logo, dove istruisci la tartaruga esattamente in questo modo per creare forme complesse.

La programmazione è come una scatola di cioccolatini . A volte trovi subito quello che stai cercando, ma il più delle volte ci vogliono un sacco di tentativi ed errori. A volte prendi il cocco.

Semafori . Le auto si muovono o si fermano. Un semaforo è facile da immaginare, ma cosa succede se ne aggiungi un altro? Che ne dici di un terzo? Che dire di un'intera città? Un sistema di transito è composto da migliaia di luci di arresto, ognuna semplice in sé e per sé, ma una volta considerata nel suo insieme, diventa un sistema complesso. Se uno di quei semafori si guasta o si spegne per pochi secondi, getta l'intero sistema nel caos. Se tutto è sincronizzato, ti piace solo il viaggio.

Un oratore motivazionale trova le chiavi per sbloccare il puzzle delle motivazioni, dei sogni e delle idee delle persone. Ogni situazione, ogni persona è diversa. Ciò che ha funzionato in passato potrebbe non essere appropriato ora. A volte una chiave può essere riutilizzata, ma deve essere adattata all'individuo. Altre volte, la chiave deve essere modificata di nuovo. Ciò che è più gratificante è quando la persona è stata sbloccata e la vedi uscire e conquistare il mondo. Il più devastante è quando ti senti vicino, ma non riesci a sbloccare il potenziale.

Una storia poliziesca , in cui il detective costruisce lentamente il suo caso cercando indizi e raccogliendo prove. Metodico, intelligente e preciso vincerà la giornata. Sciatta, ignorante e pigra condannerà il caso. Alla fine, il lavoro rimarrà o cadrà davanti a una giuria di colleghi.

Una slot machine . Inserisci tutte le tue monete e tira la leva. A volte vinci alla grande, a volte ti siedi per ore e non succede nulla. A volte qualcun altro passa casualmente, tira la leva una volta e vince il jackpot.

Musica . Una nota è abbastanza semplice, ma una misura è più complessa. Una canzone completa ha molte misure con molte note. Se una nota è disattivata, può rovinare l'intera performance. Se ogni nota viene consegnata perfettamente, l'esecuzione si attenua sullo sfondo ed esiste solo la musica.

La migliore metafora di qualsiasi cosa è essa stessa. Qualunque cosa diversa perderà una certa precisione. Come tale, scegliere la metafora migliore dipende da cosa, in particolare, vuoi catturare sulla programmazione. Dal momento che qui ci saranno molte risposte sulle metafore di programmazione, risponderò con la classica metafora del processo di sviluppo nel suo insieme:

Costruzione di edifici

L'aspetto più comune di questa metafora è che un architetto fisico è in qualche modo analogo a un architetto del software. Ecco alcuni altri parallelismi:

• Le modifiche sono più economiche e meno costose prima di apportarle. Cioè, puoi spostare una riga sulla carta ora o 10 tonnellate in cemento più tardi.
• Un edificio senza un piano adeguato tenderà a crollare
• I costruttori tentano di implementare ciò che il client desidera. Se il cliente non descrive in modo accurato l'aspetto che deve avere l'edificio (o c'è qualche altro errore nella comunicazione), sarà costoso cambiare.
• Ci sono alcune leggi della fisica che non possono essere piegate. Proprio come una seconda storia di trecento piedi di larghezza non può essere costruita su una prima storia di 100 piedi di larghezza, la caratteristica X non può essere costruita senza un robusto sottosistema Y.

Naturalmente, come ogni metafora, ha i suoi limiti. Alcuni difetti con esso:

• Gli edifici sono monouso; lo costruisci da qualche parte e lì rimane. Non è possibile copiarlo un milione di volte per un milione di utenti diversi con un milione di esigenze diverse a costo incrementale zero.
• Gli edifici sono considerevolmente più immutabili del software.
• Non esiste una chiara analogia con il costo del materiale da costruzione. Una riga di codice non costa nulla, solo il tempo necessario per produrlo costa denaro.
• L'architettura incrementale che è (a seconda di chi si chiede) possibile con il software non è possibile con la costruzione, dove la si progetta una volta, quindi la si costruisce.

Quindi, come ogni analogia, dipende da cosa stai cercando di spiegare. Fai attenzione a non fare troppo affidamento su una metafora o il tuo cliente inizierà a chiedersi quali saranno le tasse di proprietà sul suo nuovo sistema di gestione stipendi.

Adoro l' analogia di Chris McMahon con lo sviluppo del software come la creazione di musica, in particolare di musica jazz.

Sono Ella Fitzgerald e Count Basie che eseguono la canzone One O'Clock Jump. La canzone è un blues a dodici battute, che è l'equivalente jazz di un'app di database con un'interfaccia utente. Voglio dire: proprio come ogni programmatore ha creato un'app di database con un'interfaccia utente, ogni musicista americano ha suonato blues a dodici battute. È un framework su cui sono appese molte molte molte canzoni, dal conte Basie a Jimi Hendrix ai Ramones.

Questo particolare video è un ottimo esempio di pratica agile. Ascolta come la voce e il piano si influenzano a vicenda. È molto simile alla programmazione di coppia ed è molto simile a TDD: la voce fa qualcosa; il piano risponde; il piano fa qualcosa; la voce risponde. E nota il contatto visivo. Queste persone sono intensamente consapevoli di ciò che sta accadendo da un istante all'altro. Non hanno spartiti (BDUF). Sono coinvolti in un'attività che richiede intensa concentrazione e abilità, proprio come un buon sviluppo software. Sono anche chiaramente consapevoli che esiste un pubblico, così come un buon sviluppo software dovrebbe essere consapevole delle esigenze delle persone che pagano le bollette.

Ecco il link al post del blog in cui ne discute: http://chrismcmahonsblog.blogspot.com/2007/05/example-of-analogy-monks-vs-music.html

A volte mi riferisco alla programmazione come al controllo di zombi senza cervello . Riassumendo il mio post sul blog a riguardo:

• Come gli zombi, i computer con cui operiamo sono molto stupidi. È difficile istruirli a fare qualsiasi cosa a meno che le istruzioni non siano dettagliate
• Lo zombi è aggressivo e se perdiamo piccoli dettagli nelle istruzioni, lasciamo la creatura non gestita, può schiacciare tutto intorno a sé. Lo stesso con i computer: la mancanza di dettagli nelle istruzioni può causare l'arresto anomalo del programma e la distruzione dei dati.
• Devi conoscere la magia se vuoi controllare uno zombi. Lo stesso con la programmazione.
• Più persone con il cervello si riuniscono in un unico posto, più computer avranno probabilmente. Sembra che i cervelli attirino i computer, allo stesso modo in cui attraggono gli zombi.

La programmazione è come costruire cose con Lego :

• Stai attaccando un sacco di piccoli pezzi insieme per rendere le cose più grandi
• I pezzetti sono disponibili in un numero limitato di forme e dimensioni
• Le piccole cose possono stare insieme solo in certi modi
• Giocare con queste cose può essere molto divertente

Programmare un computer è come crescere un bambino ...

• Tutti non sono d'accordo sul modo giusto di farlo
• Ti tiene sveglio la notte
• Non fa mai quello che gli dici
• Non importa quanti libri leggi sull'argomento, quando vai a farlo, ti senti come se non avessi idea di cosa stai facendo
• Dopo un po 'tendi a diventare pigro
• Ti aspetti che abbia grandi ritorni in futuro, ma finisci per mantenerlo fino alla fine della sua vita
• Non è mai così pulito, intelligente o sicuro come volevi
• Quando ci ripensi più tardi, ti chiedi a cosa diavolo stavi pensando
• Nonostante tutto lo stress che ti ha causato, lo adori comunque.

La differenza principale è che ci arrabbiamo se qualcuno ruba il nostro codice sorgente, ma spesso siamo contenti di avere qualcuno che ci toglie i bambini di dosso.

La programmazione è come costruire una fabbrica o una catena di montaggio.

Pensa al software come a una macchina o catena di montaggio esistente all'interno del computer. Alcune materie prime e componenti vengono immessi nella macchina e segue una serie di procedure per trasformarli in alcuni prodotti finali. Le procedure sono impostate per eseguire un'operazione specifica su alcune materie prime o componenti su una serie specifica di parametri (ad es. Tempo, temperatura, distanza, ecc.) In un ordine particolare. Se i dettagli dell'operazione da eseguire non fossero corretti, o i sensori della macchina non fossero calibrati correttamente, o se alcune materie prime o componenti non rientrassero negli standard di qualità previsti, ciò potrebbe cambiare il risultato dell'operazione e il prodotto non verrebbe fuori come previsto.

Tale macchina è molto rigida nel suo funzionamento e input accettabili. Le macchine non mettono in discussione l'intelligenza dei progettisti né il suo attuale ambiente operativo. Continuerà a seguire le procedure finché sarà diretto. Anche se un cambiamento nelle materie prime o nei componenti potrebbe avere un effetto drastico su ciò che è accaduto nelle operazioni successive, la macchina eseguirà comunque le sue procedure. Il processo dovrebbe essere rivisto per vedere quali modifiche alle procedure erano necessarie per compensare e produrre il risultato desiderato. Una modifica al design o alla configurazione del prodotto potrebbe anche richiedere una modifica significativa delle operazioni eseguite o del loro ordine. Sebbene i responsabili della produzione abbiano rapidamente imparato l'importanza di isolare il più possibile le operazioni per ridurre gli effetti indesiderati tra loro, vengono fatte molte ipotesi sulla condizione in cui si trovano i componenti quando vengono sottoposti a elaborazione; ipotesi che potrebbero non essere rilevate fino a quando il prodotto finale non sarà nelle mani dell'utente in un ambiente operativo diverso.

Aiutare un idiota veloce a superare una lezione di matematica che richiede un saggio scritto.

La programmazione al computer è come giocare a scacchi in cui le dimensioni del tabellone, la quantità di pezzi in gioco e le regole che governano quei pezzi crescono in dimensioni e complessità man mano che il gioco procede.

Scrivere software è come ... scrivere! ^^

I nuovi studenti delle classi CS / di programmazione sono praticamente come utenti non programmatori. L'esempio del robot è buono.

Indietro, negli anni '80, usando Logo, Karel (o simili ambienti di programmazione), dove l'utente impara a programmare, guardando il computer come un robot, invece di un televisore con una macchina da scrivere, ha aiutato molto. Quegli strumenti erano comunemente usati nelle scuole medie e superiori.

Quella programmazione pratica ha aiutato gli studenti ad acquisire capacità di problem solving, anche se non erano collegati al computer !!!

Oppure, anche se gli studenti non sono diventati programmatori.

Alcuni college e università hanno anche applicato tali strumenti nei corsi del primo anno.

Mi chiedo perché molte scuole superiori abbandonino l'insegnamento di Logo e Karel ...

Mi piace l'analogia di Fred Brooks, di Mythical Man-Month, che programmare è come fare magie.

(Il) costrutto del programma, a differenza delle parole del poeta, è reale nel senso che si muove e funziona, producendo un output visibile separato dal costrutto stesso. Stampa i risultati, disegna immagini, produce suoni, muove le braccia. La magia del mito e della leggenda si è avverata nel nostro tempo. Si digita l'incantesimo corretto su una tastiera e uno schermo prende vita, mostrando cose che non sono mai state né potrebbero essere. ...

(Uno) deve funzionare correttamente. Anche a questo proposito il computer ricorda la magia del mito e della leggenda. Se un personaggio, una pausa dell'incantesimo non è rigorosamente nella forma corretta, la magia non funziona. Gli esseri umani non sono abituati a essere perfetti e pochi settori dell'attività umana lo richiedono. Adattarmi al requisito della perfezione è, penso, la parte più difficile dell'apprendimento da programmare.

"[...] ma pensavo fossi bravo con i computer!"

Questo di solito è un tentativo di ingannare un geek nel riparare un computer (senti il ​​bisogno di provare che si sbagliano?). La mia risposta standard:
sono un programmatore. È come un ingegnere automobilistico: probabilmente non saprà come riparare i freni della tua Trabant del '72, e certamente non lo farebbe se lo sapesse. Un meccanico lo farebbe!

Mi piace il concetto di ricetta per cucinare.

La programmazione è come esercitare enormi quantità di energia. Puoi fare in modo che il computer faccia tutto ciò che desideri. Sei limitato solo dalla tua immaginazione e dalla quantità di tempo che sei disposto a investire.

I programmatori sono come i creatori di una casa. Possiamo dirti tutto sulle case che abbiamo realizzato. Tuttavia, se ci chiedi di chiedere a una casa a caso che stiamo passando per strada, è probabile che probabilmente non ne sapremo molto. Ma se hai bisogno di qualcosa di aggiunto o modificato in quella casa, possiamo farlo accadere a condizione che il proprietario ci permetta.

In uno dei vecchi articoli di Chris Crawford sulla programmazione ha paragonato un programma complesso a una burocrazia, con più agenzie che comunicano passando memo avanti e indietro. Ho scoperto che si tratta di una metafora molto utile quando si spiega lo sviluppo del software.

Generalmente equiparare la programmazione a un puzzle.

Per creare un nuovo progetto - hai tonnellate di pezzi, un paio dei quali non appartengono a questa immagine, e non hai un'anteprima di come appare il puzzle quando è finito. Ma conosci le dimensioni e i colori generali, quindi le stime sono possibili, ma non necessariamente accurate.

Per modificare un progetto già esistente: un gatto è passato e ha buttato giù un pezzo del puzzle finito. Ci vorrà del tempo, ma il framework è già lì, quindi non dovrebbe essere troppo male (a seconda di quanto deve essere cambiato).

Aiuta anche a descrivere i progressi. Uno dei miei progetti recenti, ad un certo punto mi chiedevo come descriverlo in modo che una persona non tecnica potesse capire perché non so per quanto ancora, e mi è venuta in mente: pensa a un puzzle in cui tutti i i bordi sono fatti, così come poco più della metà se i pezzi interni. Quelli rimasti sono tutti separati l'uno dall'altro, quello che devo fare ora è colmare le lacune.

È triste ma la programmazione è un lavoro che può essere compreso solo imparando a farlo.

La programmazione ha diversi livelli di percezione e diversi da diversi lati.

A basso livello è "scrivere istruzioni molto, molto dettagliate per una macchina molto, molto stupida"

Al livello successivo si tratta di complessità. Costruire una nuova metafora per semplificare il lavoro. Come la matematica superiore.

Da un lato diverso il suo utilizzo di tecnologie ausiliarie come il controllo della versione, il codice autodocumentato, la costruzione del progetto e i test.

Dall'altro lato la sua interfaccia "user" di costruzione (non letteralmente, intendo anche API UI), prevedere possibili errori (fatti dall'utente, dati o persino se stesso) e reagire correttamente agli errori.

E infine.

Metafora per la programmazione è la letteratura. Per prima cosa devi imparare l'alfabeto. Ma scrivere un romanzo su questo non ha nemmeno inizio.