Come è stata fatta la programmazione 20 anni fa? [chiuso]

Al giorno d'oggi abbiamo molti ausili di programmazione che semplificano il lavoro, tra cui:

• IDE

• Debugger (riga per riga, punti di interruzione, ecc.)

• Script di formica, ecc. Per la compilazione

• Siti come StackOverflow possono aiutarti se sei bloccato su un problema di programmazione

20 anni fa, nessuna di queste cose esisteva. Quali strumenti hanno usato le persone per programmare e come hanno fatto a rinunciare a questi strumenti più recenti? Sono interessato a saperne di più su come era stata programmata allora.

20 anni fa, è il 1991. È l'anno in cui è stato rilasciato l'IDE Borland C ++ 2.0. Con debugger integrato (con riga per riga e punti di interruzione), costruzione automatizzata con make.

Sembrava questo http://www.ee.oulu.fi/research/tklab/courses/521419A/tc201_compile.png

Non avevi siti web come StackOverflow, ma con l'IDE ottenevi poche migliaia di pagine di documentazione in libri ben stampati.

20 anni fa ... 1991 ...

Vediamo. Stavo usando SunOS e VAX VMS.

Abbiamo scritto codice usando editor di testo (vi o edit).

Personalmente non uso debugger e non l'ho mai fatto. Alcune persone hanno usato il debugger adb su SunOS. L'ho usato alcune volte per recuperare un traceback dello stack da un file di dump principale. Non ho idea di cosa fosse disponibile su VAX VMS. Ho usato le dichiarazioni di stampa nel codice.

Abbiamo usato make per la compilazione.

Abbiamo letto la documentazione cartacea, pensato e condotto esperimenti. Anzi, funziona ancora. Stack Overflow è abusato da alcune persone che - per ragioni inspiegabili - si rifiutano di condurre esperimenti o pensare.

30 anni fa ... 1981 ...

Vediamo. Stavo usando Univac Exec 8 e IBM OS.

Abbiamo scritto codice usando editor di testo (non ricordo quello di Univac, ma quello di IBM era l'editor dell'ambiente TSO)

Personalmente non uso debugger e non l'ho mai fatto. Quelle macchine erano "mainframe" e non potevano essere attraversate da nulla. Non c'era "debugger". Devi inserire le dichiarazioni di stampa nel tuo codice.

Abbiamo scritto degli script per la compilazione.

Abbiamo letto la documentazione cartacea, pensato e condotto esperimenti.

40 anni fa ... 1971 ...

Vediamo. Stavo usando un IBM 1620 senza sistema operativo.

Abbiamo scritto codice usando carte di carta perforate.

Debug significava un singolo passo del processore. Raramente è stato utile, quindi ho imparato a inserire istruzioni "print" nel mio codice.

Eseguiamo il compilatore a mano per produrre un mazzo di carte di carta perforate che poi abbiamo eseguito. "a mano" significava letteralmente caricare le carte in un lettore di schede per installare il compilatore o l'assemblatore. Quindi caricare il codice sorgente in un lettore di schede per produrre il codice oggetto. Quindi caricare il codice oggetto risultante nel lettore di schede per eseguire il programma.

Abbiamo letto la documentazione cartacea, pensato e condotto esperimenti.

"Get Off My Lawn You Rotten Kids"

• IDE. Quasi inutile. Il completamento del codice può essere divertente, ma non utile come sostengono alcune persone. Ho avuto gente mi dice che VB è un linguaggio accettabile a causa di Visual Studio. La colorazione della sintassi è forse la funzione più utile mai inventata. Il resto dovrebbe essere un componente aggiuntivo opzionale, in modo da poter rinunciare a loro e liberare memoria e cicli del processore.

  Come vanno le stampelle, ci sono cose peggiori su cui contare.

• Debugger. Inutili. Tranne quando la definizione della lingua è così negativa che la semantica è così torbida che non puoi capire cosa dovrebbe accadere. Ad esempio, VB. Quando è necessario un debugger, è davvero il momento di ottenere una lingua migliore.

  Sulla base della mia esperienza nell'insegnamento della programmazione, i debugger possono essere inutili. Per alcune persone, portano al pensiero offuscato e ad uno strano stile empirico di programmazione in cui non c'è alcun significato semantico per il codice - nessun significato - solo puro hacker.

• Script di formica, ecc. Per la compilazione. La compilazione e il collegamento incrementali non sono proprio un'idea eccezionale. Con linguaggi iper-complessi, è un hack necessario, ma deve davvero essere visto come un hack. Non è necessario o addirittura desiderabile.

  Un linguaggio migliore con meno affidamento sulla compilazione incrementale sembra una cosa molto, molto migliore dei sofisticati script Ant.

• Siti come StackOverflow possono aiutarti se sei troppo bloccato su un bug. A volte utile.

  Come con i debugger, c'è la possibilità che alcune persone sembrino avere successo con una semplice fortuna da sballo. È una brutta cosa.

Hmm, la tua premessa non è del tutto vera. Gli ultimi due articoli sono corretti, ma 20 anni fa avevamo IDE e debugger.

In effetti, i debugger sono sempre esistiti. Il loro design e utilizzo si sono evoluti da quando il team di Brooks ha costruito i vecchi mainframe IBM poiché tutti noi abbiamo le nostre macchine dedicate. Tuttavia, ora possiamo avere lo stesso lavoro di debugger per un numero di lingue diverse (vedi il progetto GCC o MS Visual Studio per esempi).

20 anni fa, non avevamo ANT, ma sicuramente avevamo Make. C'erano anche un paio di versioni incompatibili dello strumento. Questo è ciò che le persone usavano per costruire i loro progetti.

E mentre il web non era prontamente disponibile (era ancora un progetto di ricerca nelle università e nell'esercito), avevamo libri e riviste. Le riviste fornirono le informazioni più aggiornate e i libri trattarono la teoria.

Dannati bambini. 1991? Veramente? Cosa pensi succedesse allora? Voglio dire, Turbo Pascal era ancora piuttosto sexy, Netware era ancora un valido concorrente di Windows, i computer veloci erano ancora misurati in mhz, ma a parte questo, non era troppo diverso. Torna indietro di altri 10 anni e stai parlando di cose sullo schermo verde, ma c'erano anche IDE per quei sistemi.

Devi tornare a metà degli anni '70 per trovare schede perforate e schifezze del genere.

20 anni fa avevamo Borland Turbo Pascal e Turbo C ++, IDE piuttosto potenti con debugger integrati, profiler, ecc.

C'erano molti ottimi strumenti. Come pensa che sia stato creato il kernel Unix? e compilato? e tutte le altre enormi app come Lotus 123, Corel Draw, Wordperfect, Xenix, MS Windows, X Windows, gnu, Kings Quest, Flight Simulator ecc.

Unix disponeva di numerosi strumenti di produttività per programmatori come lanugine per l'analisi del codice, compilazione e vi o emacs per l'editing. Con la shell Korn (e probabilmente altri) potresti sospendere un editor e passare a un altro editor in 0,5 secondi, e farlo su un modem dial-up lento con uno schermo verde ("guardare l'erba crescere"). È possibile eseguire il debug con dbx o leggere semplicemente il dump principale.

Se avessi i soldi per un terminale grafico, potresti usare X Windows e xdbx per un debugging davvero fantasioso.

Internet era lì ma non il WWW. Avevamo FTP anonimo, gopher e WAIS. E i gruppi di notizie della rete come comp.lang.c per pubblicare domande (ora è principalmente spam).

Quegli strumenti erano potenti. Hai mai visto una ricostruzione del kernel correre per un giorno o due? Costruirà makefile dopo makefile, costruendo tutte quelle dipendenze. E c'era persino pmake in grado di rilevare quali obiettivi potevano essere costruiti in parallelo. La formica può ancora farlo?

Sul PC c'erano gli incredibili prodotti Borland come Turbo Pascal (la v4 fu un grande cambiamento quando uscì a metà degli anni '80).

Erano tempi interessanti. E prezzi interessanti. La scatola dell'SDK di Windows 3 aveva una maniglia per il trasporto ma ha bisogno di due mani per sollevare, troppi dischi e una pila di manuali alta 1 piede. I database relazionali costano migliaia di dollari per utente, guerre Unix, guerre di fogli di calcolo sul tasto barra. Sono stupito dagli strumenti che posso ottenere ora a prezzi così folli / gratuiti.

La parte più divertente di tutto ciò è che alcuni dei comandi di Visual Studio (CTRL-K + CTRL-C) sono vecchi comandi di Wordstar. Un po 'di nostalgia ogni volta che lo uso.

20 anni fa, stavo programmando in GFA Basic su un Atari ST 1040 :

Più tastiera, meno mouse.

Grazie per far sentire vecchio un ragazzo :-)

All'epoca c'erano debugger e makefile. I compilatori o venivano con libri spessi, o per Unix, una grande serie di pagine man. La maggior parte degli sviluppatori Unix utilizzava vi o emacs. All'epoca non avevo fatto alcuna programmazione desktop, ma sono abbastanza sicuro che usavano editor forniti con il compilatore che erano essenzialmente IDE con meno funzionalità. Hai ricevuto aiuto da colleghi, libri o riviste.

20 anni fa stavo programmando in BASIC. Non avevo IDE perché BASICA e GW BASIC non sono IDE. Quando ho visto Quick BASIC in seguito sono stato molto contento. Ero molto emozionato quando ho usato per la prima volta la funzione Copia e incolla nello sviluppo. Successivamente hanno reso il compilatore QBASIC non interprete come una volta ed è stato fantastico, ma poi sono passato a C e ho usato l'IDE Turbo C di Borland. Nota che sono in Egitto e allora non c'era internet ed eravamo indietro di circa un anno nel software. Voglio dire, se una versione viene rilasciata oggi, mi verrà in mano circa un anno dopo. Ora è molto più facile ma la gioia della programmazione di allora era incomparabile :)

Penso che il fenomeno dell '"anno web" abbia distorto i calcoli della data.

20 anni fa stavo programmando in Smalltalk - uno dei primi linguaggi orientati agli oggetti basati sulla GUI su un Mac IIe con uno schermo da 20 pollici, quindi penso che devi tornare indietro di qualche anno in più per ottenere le pelli dell'orso e la pietra -era l'era della programmazione dei coltelli.

Ora 40 anni fa stavo programmando in basic usando un terminale teletype che aveva un modem in stile accoppiatore acustico (110 Baud baby!) - conosci il tipo che hai composto il telefono, quindi hai infilato la mano nelle coppe di gomma sul modem .

Ecco un modulo standard per aiutarti a scrivere i tuoi programmi FORTRAN prima di rovinare un mucchio di schede perforate.

(da: http://www.w3.org/2010/Talks/01-08-steven-ten-euro-computer/ )

Assicurati di usare una matita in modo da poter cancellare i tuoi errori e lasciare alcune righe vuote tra le dichiarazioni stampate nel caso in cui dimentichi alcuni passaggi.

(OK, forse è un po ' prima del 1991, ma non di molto ...)

Bene, tutto è iniziato con le schede perforate , ma sono sicuro che almeno avrai sentito parlare di quella lezione di storia. Ciò risale a più di 20 anni fa, tuttavia.

Per il debug? Un sacco di finestre di messaggio, file di registro e altri metodi di output per aiutare a controllare e vedere cosa è appena successo.

20 anni fa 4GL's erano moda.

Sorprendentemente, 20 anni fa le cose non erano affatto così diverse. Ora 30 anni fa ...

Ora, mentre scrivo questa risposta, tieni a mente che avevo solo 10 anni a quel tempo, ma che continuavo a scuotere dischi floppy da 5,25 "sul mio disco rigido da 1 MB abilitato IBM Headstart XT / AT PC. Perché rispondere a questa domanda?

Perché dove lavoro, manteniamo un sistema di 20 anni e una base di codice, quindi siamo ancora in una fase di distorsione quando lavoriamo con i sistemi legacy, gli ambienti di sviluppo e il codice.

20 anni fa stavo programmando, principalmente in C, Pascal. Per la piattaforma DOS c'erano Turbo C, Turbo Pascal che erano per lo più editor completi con debugger che permettevano il passaggio. Per una vera programmazione , sento che molti programmatori come me hanno usato il compilatore vi +, eseguito dai prompt dei comandi.

La programmazione era un po 'più difficile allora, specialmente per alcuni linguaggi di programmazione. Riesco ancora a vedere tracce di ciò nella mia programmazione: trovo che eseguire i miei test con printistruzioni sia più semplice che passare attraverso le istruzioni.

Posso parlare per la Bulgaria.

Contrariamente a quanto pensi, la Bulgaria è stata tra i principali paesi per le tecnologie informatiche. Facendo parte del blocco comunista, l'URSS ha investito ingenti somme di denaro nella nostra informatica, rendendola leader del settore nel blocco comunista. Tuttavia i comunisti non tolleravano le compagnie private e tutto in quest'area era gestito dal governo. Così il recente crollo del blocco comunista alcuni anni fa ha lasciato il Paese senza imprese stabili per mantenere il settore in buone condizioni. Tuttavia, è rimasta una buona eredità di conoscenza per la prossima generazione di specialisti. Quindi non abbiamo mai smesso di avere accesso alle ultime tecnologie e lo sviluppo del software non differiva dai paesi occidentali. Abbiamo utilizzato gli ultimi strumenti e concetti di programmazione all'avanguardia.

Quindi non ripeterò tutto ciò che dicono gli altri, ma sì, all'epoca c'erano IDE e debugger abbastanza buoni (corrispondenti alla natura del software in fase di sviluppo all'epoca).

Ricordo di aver usato personalmente Turbo Pascal e Turbo C (di Borland). Anche il software Autodesk per la grafica (come 3d Studio e Animator).

Tuttavia, la fonte di conoscenza era più limitata: principalmente libri, riviste, colleghi e raramente riviste elettroniche tramite BBS. Internet era principalmente una curiosità. Alcuni avevano accesso a Usenet, ma lo usano raramente per lavoro.

Solo 20 anni fa. Stai scherzando. Stavo usando i debugger nel 1972 quando stavo imparando la programmazione. Certo, quelli che sono stato in grado di usare non erano buoni come oggi. Sospetto che esistessero molto prima.
Gli strumenti sono cambiati nel corso degli anni e sono migliorati, ma non credo nemmeno che non avessimo strumenti in quel momento.
Sospetto che dovresti tornare agli anni '50 per arrivare al livello in cui non c'erano debugger.
Il primo debugger veramente buono che ho usato è stato su un VAX con VMS negli anni '80. Tutto è salito da lì.

Ormai dovresti vedere che nel 1991 erano presenti versioni semplici della maggior parte degli strumenti a cui sei affezionato, sebbene distribuite in modo non uniforme.

I confronti più interessanti sono con il 1981: l'inizio di processi sociali ampiamente disponibili che coinvolgono le reti USENET e UUCP e ARPANET. (La giornata della bandiera TCP di Internet era nel 1983.)

Confronti ancora più interessanti sono con il 1971: prime versioni dei sistemi operativi che ora conosci e ami, processi sociali basati sull'editoria (newsletter cartacee, conferenze frequentate di persona, condivisione di codice con contatti personali, gruppi di utenti, utilizzo di supporti come nastri magnetici ).

20 anni fa stavo codificando un 386 in Borland C ++ usando OWL per la programmazione di Windows.

La mia macchina aveva alcuni MB di RAM e un disco rigido da 200 MB. Potrei installare la maggior parte del software da floppy disk, ma sempre più software è arrivato su CD.

Quando ho premuto F8 per "Esegui" il mio progetto a Borland, il compilatore avrebbe funzionato abbastanza rapidamente e avrei potuto immediatamente giocare con i risultati.

Avevamo un PC in ufficio che ogni poche ore si collegava rumorosamente a Demon (usando Trumpet WinSock) e scaricava l'e-mail di tutti.

Quando non riuscivamo a capire come programmare qualcosa, spesso cercavamo la risposta in un libro: i libri dell'API Win32 erano particolarmente utili.

In realtà, eravamo abbastanza produttivi ... e l'IDE ha funzionato abbastanza rapidamente allora! Ma non avevano un buon refactoring e buoni strumenti di test integrati.

20 anni fa? Stavo usando un bel IDE con un fantastico generatore di UI drag-and-drop e project manager. C'era un linguaggio OO abbastanza buono, un insieme di oggetti GUI davvero buoni, un sacco di fantastiche app e una finestra terminale che mi ha dato una solida shell Unix. E un debugger, ma sono d'accordo che quelli sono per i deboli di mente (o hanno a che fare con il loro codice orribile).

Se sembra un po 'come il Mac, è perché sto parlando dell'ambiente di sviluppo NeXT, che è quello che si è trasformato nel moderno Mac OS. Per i whippersnapper, puoi leggere la storia qui:

• http://en.wikipedia.org/wiki/NeXT
• http://en.wikipedia.org/wiki/Interface_Builder
• http://en.wikipedia.org/wiki/Project_Builder

Come nota a margine, dirò che il fantastico edificio della GUI mi ha completamente rovinato. Quando ho iniziato a sviluppare app Swing in Java, era come se il cane di qualcuno avesse mangiato un vecchio documento API della GUI e lo avesse vomitato di nuovo e Sun l'avesse spedito. Per fortuna il web sta finalmente arrivando da qualche parte.

Ho iniziato a programmare nel 1981, arrivando 30 anni fa questo autunno.

Nel 1991, lavoravo ad Apple Computer (alias solo "Apple" in questi giorni), e lavoravo a stretto contatto con una piccola società canadese di nome Metrowerks.

Metrowerks stava costruendo un IDE eccezionale per C, C ++ e Pascal. Questo ambiente ha giocato un ruolo importante nella riuscita transizione di Apple al processore PowerPC dal 68K.

Anche se ero un dipendente Apple, per diversi anni sono stato effettivamente il Product Manager di Metrowerks, lavorando a stretto contatto con Greg Galanos e Jean Belanger sulla strategia di prodotto, ecc. È stata questa stretta collaborazione tra Apple e uno sviluppatore di terze parti che ha consentito Power Macintosh transizione, la prima grande transizione Mac di Apple (la seconda è la transizione a OS X).

Nel 1981, stavo entrando nel mio anno di matricola alla UCSC e ho avuto l'opportunità di iniziare a lavorare su una versione 7 di Unix (non versione 7) in esecuzione su un PDP-11/70.

Nessun IDE qui! Cavolo, non abbiamo avuto il controllo della versione fino a pochi anni dopo!

Era vi (e vim non era una scelta), cc, ln e make. Stava scrivendo C Shell Scripts e hackerando il sorgente su C Shell per aumentare la dimensione delle variabili d'ambiente da 512 caratteri a 1024 caratteri, al fine di accogliere i TERMCAPS sempre più complessi dei nostri "terminali intelligenti"

Stava ottenendo l'opportunità di leggere una copia bootleg del Lions Book sul pavimento del condominio fuori dal campus di uno studente della classe CIS, Ted Goldstein. Ted ha intrapreso una carriera molto completa, tra cui VP of Tools presso Apple.

Stava mettendo le mani su un Mac nel 1984 e una prima edizione di MDS (Macintosh Development System) e imparando a programmare questa nuova e meravigliosa bestia.

E 'stato molto divertente. È stato molto più facile alzarsi e correre. Ma il potere che abbiamo con lingue come Ruby è incredibile. Invece di scrivere una tabella hash per la tabella dei simboli dei miei compilatori, li sto usando a destra ea sinistra come tipo di dati di base!

Sì, è stato molto divertente, ma non ci tornerei ...

20 anni fa stavo scrivendo codice in AMOS , che aveva un IDE e un debugger abbastanza decente.

Nel 1991, ho usato un IDE / Framework chiamato UIMX su un terminale X, creando applicazioni basate su Motif che accedevano a un RDBMS Informatix. La lingua era C.

C'era SCCS per il versioning, make for building.

Guardando indietro, non molto diverso da come lavoro oggi.

28 anni fa stavo scrivendo il codice assembly in esadecimale, a mano, per il processore 6809 (nel Dragon 32 per quelli di voi che lo ricordano) - Alla fine ho scritto un assemblatore per lo più decente, che mi ha aiutato.

Non c'era debugger: se non avesse funzionato avresti aggiunto il codice di stampa per dare un'occhiata allo stack. Notti lunghe! Un codice efficiente ha aiutato, poiché c'erano meno righe per andare storto

E oggi devo imparare Clearcase, Maven, Ant e VS - tutto molto divertente (ma mi mancano i vecchi tempi)

20 anni, eh? Stavo operando in PC-land proprio in quel particolare momento dopo aver lasciato Apple-land poco prima. All'epoca ricordo che i bambini ricchi avevano IDE in piena regola con debug integrato (Borland e Microsoft). Il resto di noi stava raschiando insieme a marchi a basso prezzo che funzionavano bene, ma non erano così "integrati" (Mix Software, vari fornitori di compilatori di shareware). Il mouse era sulla scrivania, ma raramente si toccava. 90% del tempo trascorso in modalità testo. Le configurazioni a doppio monitor stavano iniziando a svanire (prima di allora, era comune avere un monitor di codifica monocromatico e un monitor "in esecuzione" a colori nello stesso sistema in cui le schede MDA e CGA utilizzavano posizioni I / O / memoria diverse e potevano entrambi essere eseguito contemporaneamente in DOS). Le prime versioni di Windows non erano soddisfatte di più monitor.

Le lingue popolari erano C, Pascal e Modula-2. La gente usava ancora Logo e BASIC. "Visual BASIC" stava finalmente iniziando a uccidere BASIC. COBOL e RPG venivano insegnati al college.

I bambini ricchi stavano usando USEnet su Internet, i bambini poveri continuavano a chiamare il BBS locale e usavano i gruppi FIDOnet (a 1200-2400 bps di solito, un modem a 9600 bps non era ancora conveniente per la maggior parte delle persone, costando quasi quanto il resto del computer).

Il primo computer che ho programmato negli anni Settanta era un Univac 1218 . Il 1218 aveva un dirigente minimalista e 16K di memoria core in ferrite orientata alle parole a 18 bit (da cui il termine "core dump"). L'archiviazione secondaria veniva gestita tramite nastro magnetico e schede perforate da 80 colonne con codifica Hollerith. La macchina utilizzava il complemento per l'aritmetica e il complemento per l'indirizzamento. Potrebbe essere programmato e il debug utilizzando il pannello frontale su cui sono stati visualizzati i contenuti di tutti i registri mediante interruttori a pulsante illuminati. Questa CPU può sembrare primitiva per gli standard moderni, ma all'epoca era molto interessante per me.

Di nuovo sull'argomento: usavo gli IDE venti anni fa per la maggior parte del mio sviluppo. Non sono uno di quei vecchietti che credono che gli IDE siano per le menti deboli. Un buon IDE è un amplificatore di produttività.

20 anni fa ero uno studente che programmava RMCOBOL-85.

Stavo usando un terminale verde collegato a un file server.

L'interfaccia era un editor di testo in stile blocco note. Nessun pezzo di fantasia. Abbiamo anche potuto scegliere di utilizzare VI. Non l'ho mai fatto.

Ah bei giorni. :)

Quasi 20 anni fa al giorno in cui stavo usando un PC IBM e un Amiga 1000 per compilare codice C e assembly per qualcosa chiamato Atari Lynx. Il programma in questione ha eseguito 5 giochi da casinò in 47K (ovvero i kilobyte) di spazio con 1K per alcune variabili di sistema. Un enorme 16K è stato riservato per i video a doppio buffer. Quando è arrivato il sistema di "sviluppo", c'erano delle routine di esempio del linguaggio assembly per trasformare lo schermo di un colore e fare clic sull'altoparlante. Questo è stato. Se volevi del testo, allora dovevi creare un font e le tue routine di testo. Networking? Vai avanti, basta scrivere i tuoi driver. Non so perché, ma la difficoltà era parte del divertimento. È incredibile che abbia funzionato.

Stai scherzando? Stavo scuotendo il mio 80286 nel Turbo Pascal a metà / fine degli anni '80.

20 anni fa facevo parte di un team che utilizza Interface Builder e Objective-C per creare un'app di desktop publishing per il sistema operativo NeXTstep. E sì, Internet era in circolazione, era solo un po 'più difficile da usare, ma sono riuscito a trovare e pubblicare risposte su comp.sys.next.

Stavo eseguendo il debug di debugger presso Sun nel 1989 come tecnico del supporto tecnico per sviluppatori.

Stavo usando IDE circa 30 anni fa: UCSD p-System / Apple Pascal. Ha scritto Sundog: Frozen Legacy for the Apple II con Apple Pascal e 6502 assembly (1982-84). Ho anche scritto il mio disassemblatore p-code / 6502. Del resto, stavo usando il sistema UCSD p su un microcomputer Northstar Horizon (Z-80) presso il Lunar & Planetary Institute nel 1981.

Nel 1963 stavo lavorando in un lavoro estivo nel campus. Era sul computer PDP-1, realizzato da Digital (DEC).

E sì, aveva un debugger interattivo, chiamato DDT. È possibile impostare un punto di interruzione, esaminare e modificare variabili, codice patch. L'editor di testo era piuttosto primitivo e spesso abbiamo usato una macchina per nastro di carta offline.

La lingua era assemblatore. La macchina aveva qualcosa come 4k di parole a 18 bit. Nessun sistema operativo.

Nel 1971, ero su un PDP-10 con 262.144 parole di 36 bit ciascuna. Un sistema di multiproprietà interattivo che supportava forse 10 utenti simultanei, un editor di testo chiamato TECO, un debugger ancora chiamato DDT e lingue come Lisp, Fortran, Basic e Algol. TECO era davvero potente. È possibile scrivere programmi di manipolazione del testo al suo interno.

Il PDP-10 era la base per una macchina simile prodotta presso la Palo Alto Research, dove nacque l'ufficio del futuro. Ethernet, mouse e interfaccia grafica, e-mail, stampante laser e programmazione orientata agli oggetti. Palo Alto aveva tutto questo. Dieci anni prima del PC.

Molte di queste cose sono state dimenticate e poi reinventate più volte negli anni da allora. E, naturalmente, ci sono anche molte novità.

Passando al 1991, stavo lavorando su un VAX. Il mio linguaggio principale era SQL, anche se ho scritto cose in PASCAL quando necessario. Ho anche usato DCL e Datatrieve come linguaggi di scripting, anche se non abbiamo usato quel termine.

Il VAX non aveva un IDE in quel momento, almeno non dove lavoravo. Ma l'editor di testo, i compilatori, il linker, il debugger e il linguaggio di comando sono stati tutti creati con l'idea che lo sviluppatore li avrebbe usati tutti. Hanno lavorato insieme bene. Ricordare una manciata di comandi non è stato più difficile che ricordare dove si trova un determinato strumento su una barra degli strumenti. La riscrittura dei comandi è stata semplificata dal richiamo dei comandi.

Il VAX aveva un eccellente debugger, ma non l'ho mai imparato. PASCAL ha reso abbastanza facile ottenere i programmi per cominciare, e la programmazione strutturata ha reso abbastanza facile localizzare un bug senza usare un debugger. Il debug di SQL è un gioco di ruolo completamente diverso.

Oltre a lavorare sul VAX, ho usato strumenti desktop per manipolare i dati localmente. Questi erano strumenti di MS Office o i loro precursori, non ricordo. La parte difficile era collegare gli strumenti desktop ai dati memorizzati in un database sul VAX.