Wie wurde vor 20 Jahren programmiert? [geschlossen]

Heutzutage haben wir viele Programmierhilfen, die die Arbeit erleichtern, darunter:

• IDEs

• Debugger (Zeile für Zeile, Haltepunkte usw.)

• Ant-Skripte usw. zum Kompilieren

• Websites wie StackOverflow helfen bei Programmierproblemen

Vor 20 Jahren gab es keines dieser Dinge. Mit welchen Tools haben die Leute programmiert und wie kamen sie ohne diese neueren Tools aus? Ich bin daran interessiert, mehr darüber zu erfahren, wie damals programmiert wurde.

Vor 20 Jahren, das ist 1991. In diesem Jahr wurde die Borland C ++ 2.0 IDE veröffentlicht. Mit integriertem Debugger (mit zeilenweisen und Haltepunkten) automatisierte Erstellung mit make.

Es sah so aus: http://www.ee.oulu.fi/research/tklab/courses/521419A/tc201_compile.png

Sie hatten keine Websites wie Stackoverflow, aber mit der IDE erhielten Sie einige tausend Seiten Dokumentation in schön gedruckten Büchern.

Vor 20 Jahren ... 1991 ...

Wir werden sehen. Ich habe SunOS und VAX VMS verwendet.

Wir haben Code mit Texteditoren (vi oder edit) geschrieben.

Ich persönlich benutze keine Debugger und habe es nie getan. Einige Leute verwendeten den ADB-Debugger unter SunOS. Ich habe es tatsächlich ein paar Mal verwendet, um ein Stack-Traceback aus einer Core-Dump-Datei wiederherzustellen. Ich habe keine Ahnung, was auf VAX VMS verfügbar war. Ich habe print-Anweisungen im Code verwendet.

Wir haben make zum Kompilieren benutzt.

Wir lasen die Papierdokumentation, dachten nach und führten Experimente durch. Tatsächlich funktioniert das immer noch. Stack Overflow wird von einigen Leuten überbeansprucht, die sich aus unerklärlichen Gründen weigern, Experimente durchzuführen oder nachzudenken.

Vor 30 Jahren ... 1981 ...

Wir werden sehen. Ich habe Univac Exec 8 und IBM OS verwendet.

Wir haben Code mit Texteditoren geschrieben (ich kann mich nicht an den Univac erinnern, aber der IBM war der Editor der TSO-Umgebung)

Ich persönlich benutze keine Debugger und habe es nie getan. Diese Maschinen waren "Großrechner" und konnten nicht in einem Schritt durch irgendetwas laufen. Es gab keinen "Debugger". Sie mussten print-Anweisungen in Ihren Code einfügen.

Wir haben Skripte zum Kompilieren geschrieben.

Wir lasen die Papierdokumentation, dachten nach und führten Experimente durch.

Vor 40 Jahren ... 1971 ...

Wir werden sehen. Ich verwendete eine IBM 1620 ohne Betriebssystem.

Wir haben Code mit Lochkarten geschrieben.

Das Debuggen bedeutete, den Prozessor in einem Schritt zu betreiben. Es war selten hilfreich, daher habe ich gelernt, "print" -Anweisungen in meinen Code einzufügen.

Wir führen den Compiler von Hand aus, um ein Kartenspiel aus gelochtem Papier zu erstellen, das wir dann ausführten. "Von Hand" bedeutete buchstäblich das Laden von Karten in einen Kartenleser, um den Compiler oder Assembler zu installieren. Laden Sie dann den Quellcode in einen Kartenleser, um den Objektcode zu erstellen. Laden Sie dann den resultierenden Objektcode in den Kartenleser, um das Programm auszuführen.

Wir lasen die Papierdokumentation, dachten nach und führten Experimente durch.

"Verschwinde von meinem Rasen, du faule Kinder"

• IDEs. Fast nutzlos. Code-Vervollständigung kann Spaß machen, ist aber nicht so hilfreich, wie manche behaupten. Ich habe von Leuten erfahren, dass VB aufgrund von Visual Studio eine akzeptable Sprache ist. Die Syntaxfärbung ist wahrscheinlich die nützlichste Funktion, die jemals erfunden wurde. Der Rest sollten optionale Add-Ons sein, damit wir auf sie verzichten und Speicher- und Prozessorzyklen freigeben können.

  Da Krücken gehen, gibt es schlimmere Dinge, auf die man sich verlassen kann.

• Debugger. Nutzlos. Außer wenn die Sprachdefinition so schlecht ist, dass die Semantik so trübe ist, dass Sie nicht verstehen können, was eigentlich passieren sollte. Zum Beispiel VB. Wenn ein Debugger erforderlich ist, ist es wirklich an der Zeit, eine bessere Sprache zu erhalten.

  Aufgrund meiner Erfahrung im Programmierunterricht können Debugger nicht hilfreich sein. Für manche Menschen führen sie zu trübem Denken und einem seltsamen empirischen Programmierstil, bei dem der Code keine semantische Bedeutung hat - keine Bedeutung - nur reines Hacken.

• Ant-Skripte usw. zum Kompilieren. Inkrementelles Zusammenstellen und Verknüpfen ist keine wirklich gute Idee. Bei hyperkomplexen Sprachen ist dies ein notwendiger Hack, der aber wirklich als Hack angesehen werden muss. Es ist nicht notwendig oder sogar wünschenswert.

  Eine bessere Sprache, die sich weniger auf inkrementelle Kompilierung verlässt, scheint weitaus besser zu sein als ausgefeilte Ant-Skripte.

• Websites wie Stackoverflow helfen Ihnen, wenn Sie einen Fehler nicht finden. Manchmal hilfreich

  Wie bei Debuggern besteht die Möglichkeit, dass einige Leute durch einfaches Patzerglück erfolgreich zu sein scheinen. Das ist eine schlechte Sache.

Hmm, deine Prämisse ist nicht ganz wahr. Die letzten beiden Punkte sind korrekt, aber vor 20 Jahren hatten wir IDEs und Debugger.

In der Tat hat es Debugger immer gegeben. Ihr Design und ihre Verwendung haben sich weiterentwickelt, seit Brooks 'Team die alten IBM-Mainframes gebaut hat, da wir alle über eigene dedizierte Maschinen verfügen. Jetzt können wir jedoch dieselbe Debugger-Arbeit für eine Reihe von verschiedenen Sprachen ausführen (Beispiele finden Sie im GCC-Projekt oder in MS Visual Studio).

Vor 20 Jahren hatten wir keine ANT, aber wir hatten definitiv Make. Es gab sogar einige inkompatible Versionen des Tools. Das ist es, was die Leute verwendet haben, um ihre Projekte zu erstellen.

Und obwohl das Internet nicht ohne Weiteres verfügbar war (es war immer noch ein Forschungsprojekt an Universitäten und beim Militär), hatten wir Bücher und Zeitschriften. Die Magazine lieferten die aktuellsten Informationen und die Bücher behandelten die Theorie.

Verdammte Kinder. 1991? "Ja wirklich?" Was denkst du war damals los? Ich meine, Turbo Pascal war immer noch ein bisschen sexy, Netware war immer noch ein gültiger Konkurrent von Windows, schnelle Computer wurden immer noch in MHz gemessen, aber ansonsten war es nicht viel anders. Gehen Sie noch 10 Jahre zurück, und Sie sprechen von Green-Screen-Dingen, aber es gab auch IDEs für diese Systeme.

Man muss bis Mitte der 70er Jahre zurückgehen, um Lochkarten und solchen Mist zu finden.

Vor 20 Jahren hatten wir Borland Turbo Pascal und Turbo C ++, ziemlich leistungsfähige IDEs mit integrierten Debuggern, Profilern usw.

Es gab viele großartige Werkzeuge. Wie wurde wohl der Unix-Kernel gebaut? und kompiliert? und all die anderen großen Apps wie Lotus 123, Corel Draw, Wordperfect, Xenix, MS Windows, X Windows, Gnu, Kings Quest, Flugsimulator usw

Unix verfügte über zahlreiche Programmierer-Produktivitätswerkzeuge wie Lint zur Code-Analyse, zum Kompilieren und Vi oder Emacs zur Bearbeitung. Mit der Korn-Shell (und wahrscheinlich auch mit anderen) können Sie einen Editor anhalten und in 0,5 Sekunden zu einem anderen Editor springen und dies auf einem langsamen DFÜ-Modem mit einem grünen Bildschirm tun ("Gras wachsen sehen"). Sie könnten mit dbx debuggen oder einfach den Core-Dump lesen.

Wenn Sie das Geld für ein Grafikterminal hätten, könnten Sie X Windows und xdbx für ein wirklich ausgefallenes Debugging verwenden.

Das Internet war da aber nicht das WWW. Wir hatten anonymes FTP, Gopher und WAIS. Und die Netzwerk-Newsgroups wie comp.lang.c zum Posten von Fragen (jetzt handelt es sich hauptsächlich um Spam).

Diese Werkzeuge waren mächtig. Haben Sie jemals einen Kernel-Rebuild-Lauf für ein oder zwei Tage gesehen? Es würde ein Makefile nach dem anderen erstellen und all diese Abhängigkeiten aufbauen. Und es gab sogar einen Fehler, der erkennen konnte, welche Ziele parallel gebaut werden konnten. Kann Ameise das noch tun?

Auf dem PC gab es die erstaunlichen Borland-Produkte wie Turbo Pascal (v4 war eine große Veränderung, als es Mitte der 80er herauskam).

Interessante Zeiten waren sie. Und interessante Preise. Die Windows 3 SDK-Box hatte einen Tragegriff, benötigte aber zwei Hände zum Anheben, zu viele Festplatten und einen Meter hohen Stapel Handbücher. Relationale Datenbanken kosten Tausende von Dollar pro Benutzer, Unix-Kriege, Spreadsheet-Kriege über den Schrägstrich. Ich bin erstaunt über die Tools, die ich jetzt für so verrückt niedrige Preise / gratis bekommen kann.

Das Lustigste daran ist, dass einige der Visual Studio-Tastaturbefehle (STRG-K + STRG-C) alte Wordstar-Befehle sind. Jedes Mal, wenn ich es benutze, ein bisschen Nostalgie.

Vor 20 Jahren programmierte ich in GFA Basic auf einem Atari ST 1040 :

Mehr Tastatur, weniger Maus.

Danke, dass du jemanden alt machst :-)

Damals gab es Debugger und Makefiles. Compiler kamen entweder mit dicken Büchern oder für Unix mit einer großen Anzahl von Manpages. Die meisten Unix-Entwickler verwendeten vi oder emacs. Ich habe damals keine Desktop-Programmierung durchgeführt, aber ich bin mir ziemlich sicher, dass sie Editoren verwendeten, die mit dem Compiler geliefert wurden und im Wesentlichen IDEs mit weniger Funktionen waren. Sie erhielten Hilfe von Kollegen, Büchern oder Zeitschriften.

Vor 20 Jahren programmierte ich in BASIC. Ich hatte keine IDE, weil BASICA und GW BASIC keine IDEs sind. Als ich später Quick BASIC sah, war ich sehr glücklich. Ich war sehr aufgeregt, als ich zum ersten Mal die Funktion zum Kopieren und Einfügen in der Entwicklung verwendet habe. Später haben sie den QBASIC-Compiler nicht mehr so ​​interpretiert wie früher, und es war auch großartig, aber dann bin ich zu C gewechselt und habe Borlands Turbo-C-IDE verwendet. Beachten Sie, dass ich in Ägypten bin und es damals kein Internet gab und wir ungefähr ein Jahr hinter der Software zurückblieben. Ich meine, wenn heute eine Version veröffentlicht wird, wird sie ungefähr ein Jahr später in meine Hand kommen. Jetzt ist es viel einfacher, aber die Freude am Programmieren war damals unvergleichlich :)

Ich denke, das "Webjahr" -Phänomen hat Ihre Datumsberechnungen verzerrt.

Vor 20 Jahren programmierte ich in Smalltalk - einer der ersten objektorientierten Sprachen auf GUI-Basis auf einem Mac IIe mit einem 20-Zoll-Bildschirm. Ich denke, Sie müssen noch ein paar Jahre zurückgehen, um die Bärenfelle und den Stein zu bekommen -Messer-Ära der Programmierung.

Vor 40 Jahren programmierte ich in Basic mit einem Teletyp-Terminal, das über ein Modem im Akustikkoppler-Stil verfügte (110 Baud Baby!). Sie kennen die Art, mit der Sie das Telefon gewählt haben, und steckten dann die Hand in die Gummischalen des Modems .

Hier ist ein Standardformular, mit dem Sie Ihre FORTRAN-Programme schreiben können, bevor Sie ein paar Lochkarten vermasseln.

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

Verwenden Sie unbedingt einen Bleistift, damit Sie Ihre Fehler löschen können, und lassen Sie zwischen den gedruckten Anweisungen ein paar leere Zeilen, falls Sie einige Schritte vergessen.

(OK, vielleicht ist das ein bisschen vor 1991, aber nicht viel ...)

Nun, alles begann mit Lochkarten , aber ich bin sicher, dass Sie zumindest von dieser Geschichtsstunde gehört haben. Das geht jedoch auf mehr als 20 Jahre zurück.

Zum Debuggen? Viele Nachrichtenboxen, Protokolldateien und andere Ausgabemethoden, mit denen Sie überprüfen können, was gerade passiert ist.

Vor 20 Jahren waren 4GLs der letzte Schrei.

Überraschenderweise war es vor 20 Jahren noch gar nicht so anders. Jetzt vor 30 Jahren ...

Denken Sie beim Schreiben dieser Antwort daran, dass ich zu diesem Zeitpunkt erst 10 Jahre alt war, aber immer noch 5,25-Zoll-Disketten in meinen mit 1 MB Festplatte ausgestatteten IBM Headstart XT / AT-PC schaukelte. Warum diese Frage beantworten?

Denn wo ich arbeite, unterhalten wir eine 20 Jahre alte System- und Codebasis, sodass wir uns bei der Arbeit mit den Legacy-Systemen, Entwicklungsumgebungen und Code immer noch in einer schwierigen Zeit befinden.

Vor 20 Jahren programmierte ich hauptsächlich in C, Pascal. Für die DOS-Plattform gab es Turbo C und Turbo Pascal, bei denen es sich zumeist um vollständige Editoren handelte, bei denen Debugger den Durchstieg ermöglichten. Für die echte Programmierung habe ich das Gefühl, dass die meisten Programmierer wie ich vi + Compiler verwendet haben, die über Eingabeaufforderungen ausgeführt werden.

Das Programmieren war damals etwas schwieriger, besonders für einige Programmiersprachen. Ich kann immer noch Spuren davon in meiner eigenen Programmierung erkennen: Ich finde es printeinfacher , meine Tests mit Anweisungen durchzuführen, als Anweisungen durchzugehen.

Ich kann für Bulgarien sprechen.

Im Gegensatz zu Ihrer Meinung war Bulgarien eines der Top-Länder für Computertechnologien. Als Teil des kommunistischen Blocks investierte die UdSSR viel Geld in unsere Informatik und machte sie zu einem Branchenführer im kommunistischen Block. Die Kommunisten duldeten jedoch keine privaten Unternehmen und alles in diesem Bereich wurde von der Regierung verwaltet. So hatte der jüngste Zusammenbruch des kommunistischen Blocks vor einigen Jahren keine stabilen Geschäfte mehr im Land, um die Industrie in einem guten Zustand zu halten. Ein schönes Erbe an Wissen blieb jedoch für die nächste Generation von Spezialisten. Wir haben also nie aufgehört, auf die neuesten Technologien zuzugreifen, und die Softwareentwicklung unterschied sich nicht von der in den westlichen Ländern. Wir haben die neuesten Werkzeuge und Programmierkonzepte verwendet.

Daher werde ich nicht alles wiederholen, was die anderen sagen, aber ja, es gab zu dieser Zeit ziemlich gute IDEs und Debugger (entsprechend der Art der Software, die damals entwickelt wurde).

Ich erinnere mich, dass ich persönlich Turbo Pascal und Turbo C (von Borland) verwendet habe. Auch die Autodesk-Software für die Grafik (wie 3d Studio und Animator).

Die Wissensquelle war jedoch begrenzt - hauptsächlich Bücher, Magazine, Kollegen und selten elektronische Magazine über BBS. Internet war meistens eine Kuriosität. Einige hatten Zugang zum Usenet, nutzen es aber nur selten für die Arbeit.

Erst vor 20 Jahren. Du willst mich doch veräppeln. Ich habe 1972 Debugger benutzt, als ich Programmieren gelernt habe. Zugegeben, die, die ich benutzen konnte, waren nicht so gut wie heute. Ich vermute, dass sie schon lange vorher existierten.
Die Werkzeuge haben sich im Laufe der Jahre verändert und sind besser geworden, aber denken Sie nicht einmal, dass wir damals keine Werkzeuge hatten.
Ich vermute, dass Sie in die 50er Jahre zurückkehren müssen, um auf das Niveau zu gelangen, auf dem es keine Debugger gab.
Der erste wirklich gute Debugger, den ich verwendete, war in den 80er Jahren auf einer VAX mit VMS. Von dort ist alles hochgegangen.

Inzwischen sollten Sie feststellen, dass einfache Versionen der meisten von Ihnen bevorzugten Tools 1991 vorhanden waren, obwohl sie ungleich verteilt waren.

Interessanter ist der Vergleich mit 1981: der Beginn allgemein verfügbarer sozialer Prozesse, an denen USENET-, UUCP- und ARPANET-Netzwerke beteiligt sind. (Der Tag der TCP-Flagge im Internet war 1983.)

Noch interessanter sind Vergleiche mit 1971: Frühere Versionen der Betriebssysteme, die Sie heute kennen und lieben, soziale Prozesse, die auf Veröffentlichungen basieren (Newsletter in Papierform, persönlich besuchte Konferenzen, gemeinsame Nutzung von Code mit persönlichen Kontakten, Benutzergruppen, Verwendung von Medien wie Magnetbändern) ).

Vor 20 Jahren habe ich mit OWL für Windows-Programmierung auf einem 386 in Borland C ++ programmiert.

Mein Computer hatte ein paar MB RAM und eine 200 MB Festplatte. Ich konnte die meiste Software von Disketten installieren - aber immer mehr Software wurde auf CD geliefert.

Wenn ich F8 drückte, um mein Projekt in Borland "auszuführen", funktionierte der Compiler ziemlich schnell und ich konnte sofort mit den Ergebnissen spielen.

Wir hatten einen PC im Büro, auf dem alle paar Stunden eine geräuschvolle Verbindung zu Demon (mit Trumpet WinSock) hergestellt und die E-Mails aller heruntergeladen wurden.

Wenn wir nicht herausfinden konnten, wie etwas zu programmieren ist, haben wir die Antwort oft in einem Buch nachgeschlagen - die Win32-API-Bücher waren besonders nützlich.

Eigentlich waren wir ziemlich produktiv ... und die IDE hat damals ziemlich schnell funktioniert! Aber sie hatten kein nettes Refactoring und keine netten integrierten Testwerkzeuge.

vor 20 Jahren? Ich habe eine nette IDE mit einem fantastischen Drag-and-Drop-UI-Builder und Projektmanager verwendet. Es gab eine ziemlich gute OO-Sprache, eine Reihe wirklich guter GUI-Objekte, eine Reihe großartiger Apps und ein Terminalfenster, das mir eine solide Unix-Shell verlieh. Und ein Debugger, aber ich stimme zu, das sind für die Schwachen (oder den Umgang mit ihrem abscheulichen Code).

Wenn das nach dem Mac klingt, dann deshalb, weil ich von der Entwicklungsumgebung NeXT spreche, aus der das moderne Mac OS hervorgegangen ist. Für die Whippersnapper können Sie die Geschichte hier lesen:

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

Als Randnotiz sage ich, dass das großartige GUI-Gebäude mich total ruiniert hat. Als ich anfing, Swing-Apps in Java zu entwickeln, war es, als hätte jemandes Hund ein veraltetes GUI-API-Dokument gegessen und es erneut ausgegeben, und Sun hatte es ausgeliefert. Gott sei Dank kommt das Web endlich voran.

Ich habe 1981 mit dem Programmieren begonnen und bin vor 30 Jahren in diesem Herbst aufgetaucht.

1991 arbeitete ich bei Apple Computer (auch bekannt als "Apple") und arbeitete eng mit einer kleinen kanadischen Firma namens Metrowerks zusammen.

Metrowerks baute eine umwerfende IDE für C, C ++ und Pascal. Diese Umgebung spielte eine wichtige Rolle bei der erfolgreichen Umstellung von Apple auf den PowerPC-Prozessor von 68K.

Obwohl ich ein Apple-Mitarbeiter war, war ich mehrere Jahre lang effektiv der Produktmanager von Metrowerks und arbeitete eng mit Greg Galanos und Jean Belanger an der Produktstrategie usw. zusammen. Diese enge Partnerschaft zwischen Apple und einem Drittanbieter-Entwickler ermöglichte den Power Macintosh Übergang, Apple ersten großen Mac Übergang (der zweite ist der Übergang zu OS X).

1981 trat ich in mein Studienjahr an der UCSC ein und bekam die Gelegenheit, an einem Unix Release 7 (nicht Version 7) zu arbeiten, das auf einem PDP-11/70 lief.

Keine IDEs hier! Wir hatten die Versionskontrolle erst ein paar Jahre später!

Es war vi (und vim war keine Wahl), cc, ln und make. Es wurden C-Shell-Skripte geschrieben und der Quellcode in C-Shell gehackt, um die Größe der Umgebungsvariablen von 512 Zeichen auf 1024 Zeichen zu erhöhen, um den immer komplexeren TERMCAPS unserer "intelligenten Terminals" gerecht zu werden.

Es bot sich die Gelegenheit, eine Raubkopie des Lions-Buches auf dem Boden der Eigentumswohnung eines GUS-Studenten der Oberklasse, Ted Goldstein, zu lesen . Ted hat eine sehr lange Karriere hinter sich, unter anderem als Vice President of Tools bei Apple.

Ich bekam 1984 einen Mac und eine frühe Ausgabe von MDS (Macintosh Development System) und lernte, dieses neue und wundervolle Biest zu programmieren.

Es war viel Spaß. Es war viel einfacher, loszulegen. Aber die Macht, die wir mit Sprachen wie Ruby haben, ist unglaublich. Anstatt eine Hash-Tabelle für die Symboltabelle meines Compilers zu schreiben, verwende ich sie rechts und links als Basisdatentyp!

Ja, es hat sehr viel Spaß gemacht, aber ich würde nicht zurückkehren ...

Vor 20 Jahren schrieb ich Code in AMOS , das eine IDE und einen ziemlich anständigen Debugger hatte.

1991 habe ich auf einem X-Terminal eine IDE / ein Framework namens UIMX verwendet und Motif-basierte Anwendungen erstellt, die auf ein Informatix-RDBMS zugegriffen haben. Sprache war C.

Es gab SCCS für die Versionierung und zum Erstellen.

Rückblickend nicht viel anders als heute.

Vor 28 Jahren schrieb ich den Assembler-Code für den 6809-Prozessor von Hand in hexadezimaler Form (im Dragon 32 für diejenigen, die sich daran erinnern) - schließlich schrieb ich einen meist anständigen Assembler dafür, was half.

Es gab keinen Debugger - wenn es nicht funktioniert hätte, würden Sie Druckcode hinzufügen, um einen Blick auf den Stapel zu werfen. Lange Nächte! Effizienter Code half, da weniger Zeilen fehlschlugen

Und heutzutage muss ich Clearcase, Maven, Ant und VS lernen - alles sehr lustig (aber ich vermisse die alten Zeiten)

20 Jahre, was? Ich war gerade erst im PC-Land tätig, nachdem ich kurz zuvor Apple-Land verlassen hatte. Damals erinnere ich mich, dass die reichen Kinder ausgewachsene IDEs mit integriertem Debugging hatten (Borland & Microsoft). Der Rest von uns kratzte mit Billigmarken, die gut funktionierten, aber nicht so "integriert" waren (Mix Software, verschiedene Shareware-Compiler-Anbieter). Maus lag auf dem Schreibtisch, wurde aber selten berührt. 90% der Zeit im Textmodus verbracht. Dual-Monitor-Konfigurationen begannen zu verblassen (früher war es üblich, dass ein Monochrom-Codierungsmonitor und ein Farbmonitor im selben System liefen, in dem die MDA- und CGA-Karten unterschiedliche E / A / Speicherpositionen verwendeten, und dies konnte beides sein gleichzeitig unter DOS ausgeführt werden). Frühere Versionen von Windows waren mit mehreren Monitoren nicht zufrieden.

Beliebte Sprachen waren C, Pascal und Modula-2. Die Leute benutzten immer noch Logo und BASIC. "Visual BASIC" begann jedoch endlich, BASIC abzutöten. COBOL und RPG wurden am College unterrichtet.

Reiche Kinder nutzten USEnet im Internet, arme Kinder wählten sich immer noch in lokale BBS ein und nutzten die FIDOnet - Gruppen (mit 1200-2400 Bit / s war ein 9600 Bit / s - Modem für die meisten Menschen immer noch nicht erschwinglich und kostete fast so viel wie der Rest der Welt) Computer).

Der erste Computer, den ich in den siebziger Jahren programmierte, war ein Univac 1218 . Der 1218 hatte eine minimalistische Exekutive und einen wortorientierten Ferritkernspeicher mit 16 Kbit (daher der Begriff "Core Dump"). Die Sekundärspeicherung erfolgte über Magnetband und Hollerith-codierte Lochkarten mit 80 Spalten. Die Maschine verwendete das eigene Komplement für die Arithmetik und das zweite Komplement für die Adressierung. Die Programmierung und Fehlerbehebung konnte über das Bedienfeld erfolgen, auf dem der Inhalt aller Register mit beleuchteten Drucktastenschaltern angezeigt wurde. Diese CPU mag nach modernen Maßstäben primitiv erscheinen, war aber zu dieser Zeit für mich sehr cool.

Zurück zum Thema: Ich habe vor 20 Jahren den größten Teil meiner Entwicklung mit IDEs durchgeführt. Ich gehöre nicht zu den verkrusteten alten Leuten, die glauben, dass IDEs für schwache Köpfe sind. Eine gute IDE ist ein Produktivitätsverstärker.

Vor 20 Jahren war ich Student beim Programmieren von RMCOBOL-85.

Ich habe ein grünes Terminal verwendet, das mit einem Dateiserver verbunden ist.

Die Benutzeroberfläche war ein Texteditor im Editor-Stil. Keine ausgefallenen Stücke. Wir hatten auch die Wahl, VI zu verwenden. Hab ich aber nie gemacht.

Ah gute Tage. :)

Bis vor fast 20 Jahren verwendete ich einen IBM-PC und einen Amiga 1000, um C-Code und Assembly für den Atari Lynx zu kompilieren. Das fragliche Programm hat 5 Casinospiele in 47K (das sind Kilobyte) Speicherplatz mit 1K für einige Systemvariablen ausgeführt. Für Doppelpuffer-Video wurden satte 16 KB reserviert. Als das "Entwicklungs" -System eintraf, gab es Assembler-Beispielroutinen, um den Bildschirm einfarbig zu machen und den Lautsprecher anzuklicken. Das war's. Wenn Sie Text wollten, mussten Sie eine Schriftart und Ihre eigenen Textroutinen erstellen. Vernetzung? Schreiben Sie einfach Ihre eigenen Treiber. Keine Ahnung warum, aber die Schwierigkeit war Teil des Spaßes. Es ist erstaunlich, dass irgendetwas davon überhaupt funktioniert hat.

Machst du Witze? Ich habe meine 80286 in Turbo Pascal Mitte / Ende der 80er gerockt.

Vor 20 Jahren war ich Teil eines Teams, das Interface Builder und Objective-C verwendete, um eine Desktop Publishing-App für das Betriebssystem NeXTstep zu erstellen. Und ja, das Internet gab es , es war nur ein bisschen schwieriger zu benutzen - aber ich konnte Antworten auf comp.sys.next finden und posten.

Ich war das Debuggen Debugger bei Sun 1989 als Auftragsentwickler Tech - Support - Mitarbeiter.

Ich habe vor fast 30 Jahren IDEs verwendet - das UCSD p-System / Apple Pascal. Schrieb Sundog: Frozen Legacy für den Apple II mit Apple Pascal und 6502 Assembly (1982-84). Schrieb auch meinen eigenen p-Code / 6502-Disassembler. Im Übrigen habe ich das UCSD-p-System 1981 am Lunar & Planetary Institute auf einem Northstar Horizon (Z-80) -Mikrocomputer eingesetzt.

1963 arbeitete ich bei einem Sommerjob auf dem Campus. Es befand sich auf dem PDP-1-Computer von Digital (DEC).

Und ja, es gab einen interaktiven Debugger namens DDT. Sie können einen Haltepunkt setzen, Variablen untersuchen und ändern sowie den Code ändern. Der Texteditor war ziemlich primitiv, und wir verwendeten stattdessen häufig eine Offline-Papierbandmaschine.

Die Sprache war Assembler. Die Maschine hatte ungefähr 4k 18-Bit-Wörter. Kein Betriebssystem

1971 war ich auf einem PDP-10 mit 262.144 Wörtern zu je 36 Bits. Ein interaktives Timesharing-System, das 10 gleichzeitige Benutzer unterstützt, ein Texteditor namens TECO, ein Debugger namens DDT und Sprachen wie Lisp, Fortran, Basic und Algol. TECO war wirklich mächtig. Sie könnten Textbearbeitungsprogramme darin schreiben.

Der PDP-10 war die Basis für eine ähnliche Maschine von Palo Alto Research, in der das Büro der Zukunft geboren wurde. Ethernet, Maus und GUI, E-Mail, Laserdrucker und objektorientierte Programmierung. Palo Alto hatte das alles. Zehn Jahre vor dem PC.

Vieles davon wurde vergessen und in den letzten Jahren mehrmals neu erfunden. Und natürlich gibt es auch eine Menge neuer Sachen.

1991 arbeitete ich an einem VAX. Meine Hauptsprache war SQL, obwohl ich bei Bedarf Dinge in PASCAL geschrieben habe. Ich habe auch DCL und Datatrieve als Skriptsprachen verwendet, obwohl wir diesen Begriff nicht verwendet haben.

Die VAX hatte zu diesem Zeitpunkt noch keine IDE, zumindest nicht dort, wo ich gearbeitet habe. Der Texteditor, die Compiler, der Linker, der Debugger und die Befehlssprache wurden jedoch alle mit der Idee erstellt, dass der Entwickler sie alle verwenden würde. Sie haben gut zusammengearbeitet. Es war nicht schwieriger, sich eine Handvoll Befehle zu merken, als sich zu merken, wo sich ein bestimmtes Werkzeug in einer Werkzeugleiste befindet. Das erneute Eingeben der Befehle wurde durch den Befehlsrückruf erleichtert.

Der VAX hatte einen ausgezeichneten Debugger, aber ich habe es nie gelernt. Mit PASCAL war es ziemlich einfach, die richtigen Programme für den Anfang zu finden, und mit strukturierter Programmierung war es ziemlich einfach, einen Fehler zu lokalisieren, ohne einen Debugger zu verwenden. Das Debuggen von SQL ist ein ganz anderes Ballspiel.

Zusätzlich zur Arbeit an VAX verwendete ich Desktop-Tools, um Daten lokal zu bearbeiten. Dies waren entweder MS Office-Tools oder deren Vorläufer, ich erinnere mich nicht. Der schwierige Teil bestand darin, Desktop-Tools mit Daten zu verknüpfen, die in einer VAX-Datenbank gespeichert sind.