Pensi che l'esposizione a BASIC possa mutilare la tua mente? [chiuso]

È praticamente impossibile insegnare una buona programmazione agli studenti che hanno avuto una precedente esposizione a BASIC: come potenziali programmatori sono mentalmente mutilati oltre la speranza di rigenerazione

- Edsger W. Dijkstra

Ho un profondo rispetto per Dijkstra ma non sono d'accordo con tutto ciò che ha detto / scritto. Non sono particolarmente d'accordo con questa citazione su un documento collegato scritto 35 anni fa sull'implementazione BASIC di Dartmouth .

Molti dei miei colleghi o amici programmatori hanno iniziato con BASIC, le domande che seguono hanno risposte che indicano che molti programmatori hanno avuto la loro prima esperienza sulla programmazione in BASIC. AFAIK molti buoni programmatori hanno iniziato con la programmazione BASIC.

Non sto parlando di Visual Basic o di altri dialetti "moderni" di BASIC in esecuzione su macchine piene di risorse. Sto parlando di vecchi tempi BASIC in esecuzione su computer "giocattolo", che il programmatore doveva preoccuparsi di salvare piccoli numeri che non devono essere calcolati come una stringa per salvare un misero byte perché il computer ne aveva solo poche centinaia, oppure usare goto calcolato per mancanza di una funzionalità più potente e molte altre cose che richiedono al programmatore di pensare molto prima di fare qualcosa e costringere il programmatore ad essere creativo.

Se hai avuto esperienza con BASIC ai vecchi tempi su una macchina con risorse limitate (tieni presente che un semplice microcontrollore oggi ha molte più risorse di un computer nel 1975, pensi che BASIC aiuti la tua mente a trovare soluzioni migliori, a pensare come un ingegnere o BASIC ti trascina al lato oscuro della programmazione e ti ha mutilato mentalmente?

È utile imparare un linguaggio di programmazione in esecuzione su un computer pieno di risorse in cui il programmatore principiante può fare tutto di sbagliato e il programma funziona senza grossi problemi? O è meglio sapere dove il programmatore non può sbagliare?

Cosa puoi dire di BASIC ti ha aiutato ad essere un programmatore migliore / peggiore?

Insegneresti al vecchio programmatore BASIC in esecuzione su una macchina (virtuale) da 2KB?

Certo, solo l'esposizione a BASIC è negativa. Forse condividi la mia opinione secondo cui il BASIC moderno non aiuta molto perché il BASIC moderno, così come altri linguaggi di programmazione, offre servizi che consentono al programmatore di non pensare più a fondo.

Ulteriori informazioni: Perché BASIC?

Le basi popolari al momento della citazione erano molto diverse da quelle che avevamo anche 20 anni fa. (Li conti tra i tuoi dialetti "moderni"?;)

Dimentica loop, subroutine, variabili locali e tutto ciò che la Programmazione strutturata (di cui Dijkstra e Knuth erano grandi sostenitori) ha sottolineato. Avevi GOTO e ti è piaciuto .

In questo contesto, i programmatori che conoscevano solo variabili globali, inventarono le loro subroutine (usando più variabili globali per parametri e valori di ritorno!) E scrissero spaghetti GOTO erano davvero mutilati.

Se oggi hai 30 anni o meno e Basic era la tua prima lingua, non era la stessa lingua di cui parlava Dijkstra. Anche se sei più vecchio e il tuo primo Basic aveva alcune di queste caratteristiche, come commenta Murph di seguito, potrebbe non essere stata la stessa lingua di cui parlava Dijkstra.

Hai aggiornato la domanda con un contesto che non avevo mai conosciuto prima:

• La citazione di Dijkstra è del 1975.

• Non è stato fino alla versione 6 che hai ottenuto procedure compilabili separatamente - che, credo, mostrano l'inizio del passaggio a fuoco lontano da GOTO.

• "Nel 1976, Steve Garland ha aggiunto funzionalità di programmazione strutturate per creare Dartmouth SBASIC, un precompilatore che ha prodotto l'output della versione 6 ..." ^{[ Wikipedia ]} Il contesto della citazione è chiaramente davanti a ciò che ora conosciamo come strutture di controllo, e molti utenti del il tempo avrebbe potuto essere più familiare con la seconda alla versione più recente, ovvero due versioni precedenti a Garland, che è la v5 e prima delle procedure compilabili separatamente.

• GOSUB / RETURN gestisce ancora solo "semplici subroutine".

• "I nomi delle variabili erano limitati da A a Z, da A0 a A9, da B0 a B9, ..., da Z0 a Z9, dando un massimo di 286 possibili variabili distinte." ... e sono tutti globali.

_{Un uomo non può fare di meglio che mangiare e bere e trovare soddisfazione nel suo lavoro.}

Ho imparato BASIC prima di ogni altra cosa (beh, tranne per l'algebra immagino). Se non mi ha seriamente distorto, non sono sicuro di come spiegare i 18 anni che sono seguiti ...

Detto questo, e allora? Dijkstra potrebbe avere difficoltà a insegnarmi qualcosa a causa della mia esposizione a lungo termine a BASIC, ma avrebbe avuto più difficoltà a insegnarmi qualcosa a causa della sua esposizione a lungo termine a una scatola di pini sotterranea. E anche dopo aver rimosso quei fattori, non sono mai stato uno studente serio di CS, uno studente di matematica serio o uno studente serio in qualsiasi altra disciplina. L'abisso tra qualcuno come me e il tipo di programmatore che Dijkstra avrebbe voluto vedere è così grande da essere quasi insondabile ...

Eppure, programmiamo. Noi che abbiamo dentellato BASIC, giocato con FORTRAN, sperimentato con COBOL e tutto il resto, abbiamo anche trovato una gioia e un fascino con queste piccole macchine che, sebbene forse del tutto diverse da quelle che hanno portato il signor Edsger nel suo campo, non siamo meno una vocazione, la base per un lungo lavoro d'amore.

... o forse è proprio quello che direbbe una mente mutilata ...

Non è BASIC che ti fa male, è l'incapacità di esporsi ad altre lingue. I "programmatori" di Monoglot non lo sono.

BASIC, da un punto di vista strutturato, non era peggio dell'assemblatore o COBOL. All'epoca non esisteva la pletora di lingue discendenti dell'Algol che abbiamo ora, Pascal è la prima introduzione che la maggior parte delle persone ha dovuto ragionevole strutture di controllo (e non mi piace molto le strutture di controllo Pascal).

Se BASIC fosse abbastanza per danneggiare permanentemente le persone, lo sarebbero state anche altre lingue primitive, e quindi non avremmo avuto persone abbastanza illesi da sviluppare tutte le lingue che usiamo oggi.

È possibile che Dijkstra abbia avuto a che fare con persone che non erano buoni programmatori e che non lo sarebbero mai state, che hanno imparato a fare alcune cose in BASIC. Questa è l'interpretazione più caritatevole che posso mettere sulla dichiarazione.

Ho imparato con BASIC su un TRS-80 e Apple II c / e, e mi considero un buon programmatore. I due tratti che penso personalmente hanno portato a non essere distrutti imparando prima BASIC

1. Ho continuato a cercare di imparare modi migliori per realizzare ciò che volevo con meno sforzo, il che ha portato all'apprendimento di altre lingue e alle caratteristiche di quelle lingue che le rendono potenti, e
2. Ho incontrato e riconosciuto problemi con BASIC come lingua, soprattutto la mancanza di subroutine (anche se non avevo l'esperienza per descrivere in modo conciso i problemi che faccio ora).

Devo ammettere che l'apprendimento della programmazione orientata agli oggetti dopo la pura procedurale di BASIC è stata una lotta per un po ', ma non so se fosse veramente correlato a BASIC, dato che a quel tempo avevo imparato anche una buona dose di C .

Non sono d'accordo con Dijkstra. Penso che sia più difficile imparare una seconda lingua perché i paradigmi, non perché è BASE.

BASIC è stata la mia prima lingua su un personal computer chiamato TK (tipo Sinclair) nel 1985. Era una macchina con risorse molto limitate. A quel tempo, ho scritto un compilatore BASIC da un libro usando un editor esadecimale per divertimento. Ho comprato un libro Z80 e successivamente ho imparato il linguaggio macchina a 8 bit. BASIC mi ha aiutato molto in questo.

Dopo aver imparato C e Pascal e suonare con Assembly per 8080/6. MSX-BASIC, Quick Basic in tempi MS-DOS ... VB, Delphi, alcuni Java in tempi Windows ...

Oggi un lavoro con progress (4gl), .net (C # / VB), php e non mi sento un ciclope. : O)

Ho iniziato con un semplice clone di mele a otto anni.

Persino le versioni successive di base che presentavano alcune idee OOP (qbasic, visual basic, ecc.) Non avrebbero avuto senso su Otto.

Iniziare a programmare così presto è uno dei motivi per cui riesco a riflettere sul problema nel flusso del programma e questo è un modo in cui troppe persone non riescono a fare bene in questo settore.

Penso che un inizio precoce sia spesso utile e sia necessario un linguaggio MOLTO SEMPLICE quando si ha a che fare con i più piccoli.

Il tuo chilometraggio può variare ...

Penso che l'esposizione alla maggior parte degli esempi BASIC nel mondo siano ciò che mutilano il cervello dei programmatori, non il linguaggio stesso. È come il programmatore C # che naviga su MSDN e non pensa che sia necessaria la gestione delle eccezioni o che i IDisposabletipi non debbano davvero essere eliminati.

Chiunque avrà un problema se non riesce a identificare i problemi nella loro lingua corrente e non solo sarà in grado di aggirarli, ma ne troverà un altro creato per risolvere il problema.

E GOTO è male solo se non si dispone della numerazione delle righe;)

Attualmente sto usando BASIC per insegnare a mio figlio a scrivere i suoi giochi semplici. Non l'ho mai usato, ho avviato il mio operatore con PowerBuilder e PowerScript e sono passato a C / C ++ e poi a Delphi. Oggi uso quasi tutte le lingue disponibili e mi adeguo molto velocemente perché il terreno di tutte le lingue sono le stesse, formule matematiche con segni, operatori e simboli diversi. Questo è anche ciò che sto insegnando a mio figlio e per questo può già leggere e spiegare il codice C ++. Mio figlio ha 12 anni.

BASIC GOTOè un ottimo modo per insegnare il modo di pensare nel linguaggio assembly . Non mutila la mente, porta solo la mente più lontano dalle sinapsi a base di carbonio e più vicina ai transistor a base di silicio.

Tuttavia, confrontiamo BASIC con LOGO. BASIC può allontanare i ragazzi dalla programmazione, perché per scrivere un semplice programma divertente, tutto ciò che puoi fare è continuare a scrivere a macchina un programma molto, molto lungo stampato su una rivista, mentre con LOGO un one-liner può disegnare una grafica molto impressionante, che è essenziale per attirare i bambini.

Di base è buono - è divertente e piuttosto semplice Può fare divertente grafica 2d e cosa no ... Ho imparato (o provo a imparare) che quando avevo circa 10 o 12 anni, era una lingua divertente che mi ha interessato a saperne di più sui computer ...

Alcuni dei migliori programmatori che conosco sono stati presto esposti alla programmazione in Basic. È un po 'più "concreto" e quindi offre una migliore percezione di come la macchina di basso livello potrebbe effettivamente funzionare rispetto a molti linguaggi più recenti (ad esempio è un'introduzione HLL più vicina all'assemblatore).

La citazione di Dijkstra risale a un periodo in cui gli accademici stavano cercando di spingere una tendenza verso programmi ben strutturati e perfettamente dimostrabili progettati dalle specifiche. Ma non è così che è andata una grande industria. Invece, molti programmatori dell'era del web 2.0 stanno provando a prototipare rapidamente qualcosa per cui non esiste la maggior parte delle specifiche matematicamente rigorose per dimostrare il codice, perché le cose si stanno evolvendo troppo rapidamente perché quelle specifiche rimangano competitive.

Pertanto, i metodi di programmazione di tentativi ed errori hack-and-slash che la programmazione in Basic a volte incoraggia, se ripuliti un po 'nella metodologia, è un utile spunto per il pensiero RAD.

Concluderò notando che ci sono almeno 5 interpreti di base disponibili su iPad, mantenendo così la lingua disponibile anche sui dispositivi più recenti.

Penso che, dato che questa citazione ha 35 anni, ha molto a che fare con la mancanza di astrazione che era disponibile nei linguaggi di programmazione, e ciò che era necessario che tu sapessi per sviluppare bene, quando è stato detto.

Avere una lingua come BASIC ti insegna poco su come programmare a basso livello, qualcosa di molto più necessario in passato di adesso, e ti darebbe l'impressione errata che la programmazione fosse più semplice di quanto non sia in realtà.

Ricordo discretamente di aver provato a imparare il "codice macchina" all'età di 15 anni dopo oltre 3 anni di VZ200, C64 e Apple] [e BASIC, era una scortese sveglia.

In questi giorni, tuttavia, anche se sono un snob completo su queste cose, e non mi troverai a lavorare felicemente in nessuna lingua con BASIC nel nome (tendo a iniziare a urlare al monitor frasi come 'stupido Fisher Price Language' in quanto , ancora una volta, rifiuta le mie incurvate parentesi graffe), ammetto che è più facile fare cose produttive con linguaggi che astraggono la meccanica della CPU rispetto a 35 anni fa (o 25 anni fa, nella mia esperienza personale ed esempio)

per quelli di noi che caricavano il codice assembly nei computer Speer Micro-LINC un byte alla volta tramite un set di 8 interruttori sul pannello frontale e li memorizzavano su nastri PDP nel 1972, affermerò inequivocabilmente che Dijkstra era un pomposo idiota. Tutto ciò che disprezzava di Basic era vero per quanto riguarda l'assemblatore con cui lavoravo, eppure io e migliaia di altre persone abbiamo recuperato dalla nostra esposizione all'assemblatore e in seguito Basic, Fortran, Cobol e C ecc.

Ho iniziato a programmare con GW-BASIC all'inizio degli anni '90. La mia mente non si è mutilata. Sono passato a linguaggi migliori come Pascal, C, C ++, Java, C # e Python.

Non sarei in grado di scrivere un programma BASIC oggi; Ho dimenticato come pensare in termini di numeri di riga. Non è un problema.

Ma la mia esperienza BASIC mi ha aiutato molto nel corso di Computer Architecture del college dove ho dovuto imparare il linguaggio assembly (MIPS). Assemblea flusso di controllo lingua è molto simile a BASIC di: Salti = GOTO, rami = IF... GOTO, jal(chiamata) ... jr(ret) = GOSUB... RETURN. Questo è tutto il flusso di controllo di cui hai bisogno!

È utile imparare un linguaggio di programmazione in esecuzione su un computer pieno di risorse in cui il programmatore principiante può fare tutto di sbagliato e il programma funziona senza grossi problemi? O è meglio sapere dove il programmatore non può sbagliare?

Direi che è meglio imparare su un computer con risorse limitate. Non perché "il programmatore non può sbagliare" ma perché la soglia "coolness" è molto più bassa. Un programmatore principiante potrebbe non sapere come realizzare un ottimo sparatutto in prima persona per il proprio PC. Ma potevano scrivere un ottimo gioco Pac Man per la loro TI-89 e usare l'hardware al massimo delle sue potenzialità. E questa è una sensazione di potere.