Pensi che l'esposizione al BASIC possa mutilarti la mente? [chiuso]

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

Dimenticate cicli, subroutine, variabili locali e tutto ciò che la Programmazione Strutturata (di cui Dijkstra e Knuth erano grandi sostenitori) enfatizzò. Avevi GOTO, e ti piaceva .

In questo contesto, i programmatori che conoscevano solo le variabili globali, hanno inventato le proprie subroutine (usando più variabili globali per parametri e valori restituiti!) e hanno scritto che gli spaghetti GOTO erano realmente mutilati.

Se hai 30 anni o meno oggi e Basic è stata la tua prima lingua, non era la stessa lingua di cui parlava Dijkstra. Anche se sei più vecchio e il tuo primo Basic ha alcune di queste funzionalità, come commenta Murph qui sotto, potrebbe comunque non essere la stessa lingua di cui parlava Dijkstra.

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

• La citazione di Dijkstra è del 1975.

• Non è stato fino alla versione 6 che hai ottenuto separatamente le procedure compilabili - il che, credo, mostra l'inizio dello spostamento di messa a fuoco away da GOTO.

• "Nel 1976, Steve Garland ha aggiunto le funzioni programmazione strutturata per creare Dartmouth SBASIC, un precompilatore che ha prodotto la versione 6 output ... " ^{[ Wikipedia ]} Il contesto della citazione è chiaramente precedente a quello che ora conosciamo come strutture di controllo e molti utenti del tempo avrebbero potuto avere maggiore familiarità con la versione più recente - cioè due prima di Garland, che è v5 e prima di procedure compilabili separatamente.

• GOSUB / RETURN gestiscono ancora "subroutine semplici".

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

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

Ho imparato il BASIC prima di ogni altra cosa (beh, ad eccezione dell'algebra, immagino). Se non si deformasse seriamente, allora 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 al BASIC, ma avrebbe avuto un più difficile tempo per insegnarmi qualcosa a causa della sua esposizione a lungo termine a una scatola di pino sotterraneo. E anche con questi fattori rimossi, non sono mai stato uno studente di CS serio, uno studente di matematica serio o uno studente serio in qualsiasi altra disciplina. L'abisso tra qualcuno come me e il tipo di programmatore Dijkstra che avrebbe voluto vedere è così bello da essere quasi insondabile ...

Eppure, programmiamo. Noi che siamo stuzzicati su BASIC, giocati con FORTRAN, sperimentato con COBOL e tutto il resto, abbiamo anche trovato una gioia e un fascino per queste piccole macchine che, sebbene forse completamente dissimili da quelle che hanno disegnato per la prima volta Mr. Edsger nel suo campo, non è meno una vocazione, il fondamento di una lunga vita di amore.

... o forse è proprio quello che una mente mutilata vorrebbe dire ...

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

BASIC, da un punto di vista strutturato, non era peggio di assembler o COBOL. Allora, non c'era la pletora di lingue discese dall'Algol che abbiamo ora, Pascal è stata la prima introduzione che molte persone hanno avuto su strutture di controllo ragionevoli (e non mi piace molto le strutture di controllo Pascal).

Se BASIC fosse stato abbastanza per danneggiare in modo permanente le persone, allora c'erano anche altre lingue antiche e quindi non avremmo avuto persone abbastanza incolume da sviluppare tutte le lingue che usiamo oggi.

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

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

1. Ho continuato a provare a imparare modi migliori per realizzare ciò che volevo con meno impegno, il che ha portato all'apprendimento di altre lingue e alle funzionalità di quei linguaggi che le rendono potenti e
2. Mi sono imbattuto in e ho riscontrato problemi con il BASIC come linguaggio, specialmente la mancanza di subroutine (anche se non avevo l'esperienza per descrivere in modo conciso i problemi che faccio ora).

Ammetto che l'apprendimento della programmazione orientata agli oggetti dopo la pura procedura del BASIC è stata una battaglia per un po ', ma non so se questo fosse veramente correlato al BASIC, poiché avevo imparato una buona dose di C da poi pure.

Anche io non sono d'accordo con Dijkstra. Io sono più difficile imparare una seconda lingua perché i paradigmi, non perché è BASIC.

BASIC è stata la mia prima lingua su un personal computer chiamato TK (simile a 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 ho imparato il linguaggio macchina a 8 bit dopo quello. BASIC mi ha aiutato molto con questo.

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

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

Ho iniziato con base su un clone di mela quando avevo otto anni.

Anche le versioni successive di base che avevano introdotto alcune idee OOP (qbasic, visual basic, ecc.) non avrebbero avuto senso ad Eight.

L'avvio precoce della programmazione è uno dei motivi per cui riesco a pensare al problema nel flusso del programma e questo è un modo in cui troppe persone non possono fare bene in questo settore.

Penso che un inizio precoce sia spesso vantaggioso e un linguaggio MOLTO SEMPLICE è richiesto quando si tratta di piccoli.

Il tuo chilometraggio può variare ...

Tutti hanno problemi se non riescono a identificare i problemi nella loro lingua corrente e non solo sono in grado di aggirarli, ma ne trovano un altro costruito per risolvere il problema.

E GOTO è male solo se non hai la numerazione delle righe;)

Penso che l'esposizione alla maggior parte degli esempi di BASIC nel mondo sia ciò che mutilano i cervelli dei programmatori, non il linguaggio stesso. È come il programmatore C # che esplora MSDN e non ritiene che la gestione delle eccezioni sia necessaria o che i tipi IDisposable non veramente debbano essere eliminati.

Attualmente sto usando il BASIC per insegnare a mio figlio a scrivere i suoi giochi semplici. Non l'ho mai usato, ho iniziato la mia carriera 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 fondamento di tutte le lingue è lo stesso, formule matematiche con segni, operatori e simboli diversi. Questo è anche quello che sto insegnando a mio figlio e per questo può già leggere e spiegare il codice C ++. Mio figlio ha 12 anni.

GOTO di BASIC è un ottimo modo per insegnare il modo di pensare in linguaggio assembly . Non mutila la mente, ma allontana la mente dalle sinapsi basate sul carbonio e più vicine ai transistor basati sul silicio.

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

Il basic è buono - è divertente e piuttosto semplice Può fare divertenti grafica 2d e cosa no ... Ho imparato (o cerco di imparare) che quando avevo circa 10 o 12 anni, era una lingua divertente questo mi ha fatto interessare a saperne di più sui computer ...

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

La citazione di Dijkstra deriva da un periodo di tempo in cui gli accademici stavano cercando di spingere una tendenza verso programmi ben strutturati correttamente provati e progettati da specifiche. Ma non è così che è andata l'industria delle grandi porzioni. Al contrario, molti programmatori dell'era del web 2.0 stanno provando a prototipare rapidamente qualcosa per cui la maggior parte delle specifiche matematicamente restrittive per provare il codice non esiste, perché le cose si stanno evolvendo troppo rapidamente per garantire che tali specifiche rimangano competitive.

Quindi i metodi di programmazione tentativi ed errori di hack-and-slash che la programmazione in Basic talvolta incoraggia, una volta ripuliti un po 'nella metodologia, sono un utile primer per il pensiero di RAD.

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

Penso, 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 per farti sapere per svilupparsi bene, quando è stato detto .

Il fatto di avere un linguaggio come BASIC ti insegna poco su come programmare a un livello basso, qualcosa di molto più necessario nel passato rispetto a adesso, e ti darebbe l'impressione errata che la programmazione sia più semplice di quanto sia in realtà.

Ricordo di aver imparato appropriatamente "codice macchina" all'età di 15 anni dopo oltre 3 anni di VZ200, C64 e Apple] [e BASIC, è stata una scortese sveglia.

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

per quelli di noi che stavano caricando il codice assembly nei computer Speer Micro-LINC un byte alla volta tramite un set di 8 switch sul pannello frontale e li memorizziamo su nastri PDP nel lontano 1972 affermerò inequivocabilmente che Dijkstra era un tonto pomposo. Tutto ciò che lui disprezzava di Basic era vero in giro per l'assemblatore con cui stavo lavorando e tuttavia io e migliaia di altre persone recuperate dalla nostra esposizione all'assemblatore e in seguito Basic e Fortran e Cobol e C ecc.

Ho iniziato a programmare con GW-BASIC nei primi anni '90. La mia mente non è stata 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 linea. Non è un problema.

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

Is good to learn a programming language running on a computer full of resources where the novice programmer can do all wrong and the program runs without big problems? Or is it better to learn where the programmer can't go wrong?

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