Wie wurde vor 20 Jahren programmiert? [geschlossen]

37

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.

Klicken Sie auf "Upvote"
quelle
29
Wir hatten sicherlich vor 20 Jahren IDEs und Debugger. 1991 gab es sogar eine frühe Version von Visual Studio.
ChrisF
14
Hammer und Meißel
Matthew Whited
15
Bah! Als ich jung war, musste ich nur mit Steinen und Sand programmieren
FrustratedWithFormsDesigner
16
Bah, wir konnten nicht einmal Nullen haben, wir mussten den Buchstaben O verwenden.
Loïc Wolff
15
Vor 20 Jahren musste man eigentlich etwas wissen. Es gab kein Internet, das alles wusste.
Joel Etherton

Antworten:

31

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.

vartec
quelle
Ich habe in der Schule gelernt, TC- und TP-IDE (s) zu verwenden, obwohl ich dort gehört habe, dass ähnliche Tools die IDE in die Mainstream-Programmierung
einbrachten
Lust auf Schmancy Gizmos. Sie würden sie nicht brauchen, wenn Sie Butterfiles verwenden würden.
Mateen Ulhaq
Good old Borland ... wenn Ihre App zu groß war, mussten Sie die DLLs auswählen, die Sie mit Debug-Code kompiliert haben, oder Sie würden den gesamten Computer zum Absturz bringen.
MadMurf
Ich erinnere mich an diese Bücher mit dem kleinen, dreigeteilten Lochpapier in einem kleinen Ordner.
JohnFx
3
So funktioniert es heute auch in IDEs. Sie haben Haltepunkte festgelegt, die zu debuggende Anwendung wird ausgeführt, und an einem Haltepunkt befinden Sie sich wieder in der IDE. Der einzige Unterschied ist, dass Sie natürlich nicht in Echtzeit zwischen ihnen wechseln können.
Jwenting
57

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.

S.Lott
quelle
3
Um wie viele Codezeilen könnten Sie auf eine Lochkarte passen?
Klicken Sie auf "Upvote
38
+1 für "Stapelüberlauf wird von einigen Leuten überbeansprucht, die sich aus unerklärlichen Gründen weigern, Experimente durchzuführen oder nachzudenken"
Binary Worrier
3
@trufa Im Jahr 1931 hatten wir analoge Computer, bei denen die Form von Rädern und Zahnrädern Variablen modellierte. 1831 hatten wir Webstühle, die Lochkarten und die Differenzmaschine, mit der Tabellenkalkulationen erstellt und die Ergebnisse gedruckt wurden, gelesen hatten
Martin Beckett,
13
Alles nach "Runter von meinem Rasen, du faule Kinder" ist ein Witz, oder?
Alb
7
Ich denke nicht, dass es ein Witz ist. Es scheint "traurig, aber wahr"
Adam Arold
28

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.

Berin Loritsch
quelle
17
Wir hatten auch USENET, Sie können Archive von comp.lang.c und anderen in Google Groups sehen, die auf die frühen / mittleren 80er Jahre zurückgehen.
James Love
1
Schauen Sie sich diesen Link an: en.wikipedia.org/wiki/Integrated_development_environment
Berin Loritsch
3
Das Debuggen wurde in der EDSAC etwa 48 erfunden. Gill, Wilkes und ihre Crew haben es herausgefunden. Wilkes hatte einen Artikel in einem Computergeschichtsjournal um 1982 oder so darüber gesprochen. Wenn jemand interessiert ist, sollte ich das Zitat ausgraben können.
Paul Nathan
1
Vor etwas mehr als 20 Jahren benutzte ich den GeOS-Assembler: en.wikipedia.org/wiki/GEOS_%288-bit_operating_system%29, der den in ihrem Textverarbeitungsprogramm geschriebenen Quellcode kompilierte. Es war eine Neuheit, WYSIWYG-Formatierung für Ihre Kommentare zu haben, was ich seitdem nie gesehen habe.
Berin Loritsch
4
GDB: Ein Debugger, der in jeder Sprache gleichermaßen schlecht aussieht. Es ist eine grundsätzlich schlechte Architektur; Der Debugger muss eng an die Sprache gekoppelt sein, damit er sprachspezifische Konzepte verstehen und unterstützen kann.
Mason Wheeler
18

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.

Satanicpuppy
quelle
1
"war nicht zu viel anders"? Es gab kein Internet, und ich bin sicher, dass auch Sie jeden Tag eine Menge Zeit damit verbringen, Informationen, die Sie für Ihre Arbeit benötigen, aus dem Netz zu holen.
4
@ Thorbjørn: Wir hatten die Kaffeekanne cam! Und Usenet! Was brauchst du sonst noch? Ehrlich gesagt war es nach meinen Erinnerungen kein so großes Problem. Der Bedarf an Webdokumentation ist mit der Komplexität des von Ihnen erstellten Materials gestiegen. Wenn Sie eine Buchhaltungsanwendung mit einer Text-GUI zusammenarbeiten, benötigen Sie nicht viel Dokumentation.
Satanicpuppy
1
@satanicpuppy, du hattest die Kaffeekanne nur 1991, wenn du in Cambridge warst. Warst du?
2
"Netware war immer noch ein gültiger Konkurrent von Windows" ... scheint, als ob Sie 1991 in einem alternativen Universum lebten.
ocodo
2
@ Thorbjørn Usenet, bevor die Horden darauf abstiegen, war eine bessere Ressource als StackOverflow heute. Natürlich ist Wikipedia und das Web im Allgemeinen großartig, aber das Programmieren ist nicht so anders.
Jim Balter
16

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

jwenting
quelle
Borland C ++ war zu der Zeit ziemlich süß.
Chris Cudmore
12

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.

2 Umdrehungen
quelle
Arrrrggghhhhhhh, Sie haben Wordstar erwähnt!
HLGEM
Unix wurde mit ed geschrieben - keines der von Ihnen erwähnten Tools war zu diesem Zeitpunkt vorhanden. Wir hatten die Mashey-Shell, die von der Bourne-Shell abgelöst wurde - die Korn-Shell war eine späte Ankunft.
Jim Balter
11

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

atari st 1040

fretje
quelle
2
Du Glückspilz. Ich hatte Atari ST 512 zu dieser Zeit
Nemanja Trifunovic
Hoppla. Ich meine Atari 520. Es hatte 512 Kb RAM :)
Nemanja Trifunovic
10

Mehr Tastatur, weniger Maus.

John Robertson
quelle
7

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.

Karl Bielefeldt
quelle
Ich möchte mich bei allen entschuldigen, die immer noch Makefiles und Emacs verwenden.
16.
@ Bev Sie sind nicht der einzige :)
NWS
6

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 :)

M.Sameer
quelle
6

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 .

Zeke Hansell
quelle
"110 Baud Baby" LOL
Edelwasser
6

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

Bildbeschreibung hier eingeben

(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 ...)

Oosterwal
quelle
5

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.

Mat Nadrofsky
quelle
Ich erinnere mich an Keypunch-Karten in den 1980er Jahren.
Crosenblum
Verdammte 4gls. Ich habe gestern einen (Speedware) benutzt . Warum irgendjemand jemals gedacht hat, dass dies eine gute Idee ist, ist mir ein Rätsel, aber alle meine Vorgänger haben unermessliche Arbeitsstunden in die Codierung von nicht unterstützbarem 4GL-Code gesteckt, und hin und wieder muss ich etwas im System optimieren. Sprechen Sie über eine nutzlose Fähigkeit.
Satanicpuppy
@Satanicpuppy: 4GLs waren die Web-Frameworks des Tages. Ich kann mir vorstellen, was Entwickler in 20 Jahren über Ruby on Rails / jQuery / Zend-Code sagen werden: "Wer hat das jemals für eine gute Idee gehalten? War jeder um die Jahrhundertwende ein Idiot ?" :)
TMN
@tmn: Heh. Ich weiß nicht , wie sie entweder, für so ziemlich dem gleichen Grund ... Natürlich, ich weiß nicht brauchen sie entweder zu verwenden, kein Web - Kerl zu sein. 4GLs waren jedoch schlechter, weil sie proprietär waren. Support kostet ein Vermögen, und wenn Sie keinen Support hätten, könnten Sie kein Upgrade durchführen. Ich habe vor ein paar Jahren eine neue Lizenz für uns in Betracht gezogen, damit ich alles auf eine neue Serverumgebung migrieren konnte, und die Lizenz lief über 150.000! Pro Seite! Das COBOL konnte ich kostenlos migrieren, und die Datenbanken benötigten nur einige 500 Dollar Schnittstelle. Das ganze Projekt wurde wegen dieser gottverdammten proprietären 4GL-Umgebung heruntergefahren.
Satanicpuppy
Jetzt 4GL gab es etwas, an das man sich erinnern musste.
Martin York
5

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.

CMR
quelle
Ich benutze immer noch vi (gvim) zusammen mit Visual Studio (ich habe es heute benutzt). Ich verwende VS nur zur Code-Vervollständigung (es sucht nach Methoden für mich) und zum Starten von IncrediBuild. Ansonsten kann ich mit vim viel schneller bearbeiten.
Giorgio
5

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.

venimus
quelle
Zwanzig Jahre gab es definitiv weniger Wissensquellen, aber die Qualität eines durchschnittlichen Software-Anwenders war höher. Vor zwanzig Jahren haben nur die Entschlossensten in dieser Branche überlebt. Jetzt kann sich Inkompetenz hinter guten Fähigkeiten wie "Googeln" und "Ausschneiden und Einfügen" verstecken.
Bit-Twiddler
Welche Art von Software haben Sie damals in Bulgarien hergestellt, als es noch keine privaten Unternehmen gab?
Klicken Sie auf "Upvote
@Click Upvote Wissenschaft, Militär, Weltraum, Ingenieurwesen usw. - alles natürlich vom Staat selbst finanziert - oder zumindest war es damals in meinem Land (UdSSR) so.
mlvljr
4

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.

Dave
quelle
4

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) ).

Liudvikas Bukys
quelle
Das ARPANET war im Oktober 1969 in Betrieb - ich war dort für die erste Anmeldung. Wir schickten bald eine E-Mail, obwohl das "@" erst ein paar Jahre später "erfunden" wurde. Aber schon vorher hatten wir Interuser-Messaging auf Time-Sharing-Systemen - der eigentliche Anfang von Dingen wie Usenet.
Jim Balter
Ja, in den 1970er Jahren hatten die "in crowd" (relativ wenige) ARPANET-, Xerox Altos-, Ethernet-, Dover-Drucker, schrieben Programme in Smalltalk, Lisp, Simula67 oder C und hatten Tenex und Unix für Betriebssysteme. In den 1980er Jahren verfügten <i> alle </ i> über Weitverkehrsnetze und Remote-Kollegen, die sich immer mehr Code teilen.
Liudvikas Bukys
Diese Dinge waren an Universitäten üblich.
Jim Balter
1
Lieber Jim Balter, wir sind nicht wirklich anderer Meinung. Ich betone nur, dass der große Unterschied zwischen den 70ern und den 80ern nicht in der Existenz von Werkzeugen lag, sondern in ihrer wirklich weit verbreiteten Verfügbarkeit. Ein anderes Beispiel: Siehe RFC923 (Oktober 1984). Damals wurden nur 35 ASNs zugeteilt - nur ein kleiner Teil der Universitäten.
Liudvikas Bukys
4

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.

Stuart
quelle
4

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:

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.

William Pietri
quelle
4

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 ...

Jordan
quelle
Wow! Und keine RSI oder Karpaltraining oder andere gesundheitliche Rückschläge von all den Jahren der Programmierung? Nein, versteh mich nicht falsch, ich will nicht sagen, dass 20+ oder 30+ Jahre Codierung zu RSI führen, aber ich habe Fälle gesehen, in denen zu viel Gebrauch der Editoren wie vi dazu geführt hat.
Mamta D
3

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

Ameise
quelle
Ja, ich auch! Eine interessante Kombination aus schrecklicher und fantastischer Sprache, in der man programmieren lernen kann, die aber am Ende ganz gut geklappt hat. Davor habe ich STOS, seinen Atari ST-Vorgänger, verwendet.
Liedman
3

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.

user281377
quelle
3

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)

Rory Alsop
quelle
3

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).

Brian Knoblauch
quelle
3

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.

Bit-Twiddler
quelle
2

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. :)

TeaDrinkingGeek
quelle
2

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.

user20205
quelle
2

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

Bildbeschreibung hier eingeben

JohnFx
quelle
2

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.

user20254
quelle
Sehr cool, diesen Bruce zu hören! Ich erinnere mich, als Sie die Welt von Mac verlassen haben, um an NeXT zu arbeiten ...
Jordan
2

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.

Walter Mitty
quelle