Wie man an der rechten Seite schon lesen kann bin ich Jahrgang 1968. Außerdem habe ich schon recht früh mit der Softwareentwicklung angefangen, obwohl man bei den ersten Versuchen doch eher von Spaghetti-Code reden muss. Wir wussten es damals halt nicht besser, und in Zeiten als es weder Internet noch Modem gab (ich habe tatsächlich noch die Zeiten der Akustikkoppler erlebt) waren die einzigen Informationsquellen einige rar gesäte Bücher und die eigenen Erkenntnisse. Gegebenenfalls noch die Erkenntnisse des Freunds aus der Nachbarschaft, was sich aber qualitativ die Waage hielt.
Professionelle Programmiererfahrung habe ich dann mit Turbo Pascal, später mit Borland Pascal sammeln dürfen. Auch wenn Borland sich da wirklich sehr anstrengte und eine für die damalige Zeit sehr gute Entwicklungsumgebung zur Verfügung stellte, mit einer heutigen IDE hatte das nichts zu tun. Heutzutage erwarten wir praktisch, dass die IDE uns beim Programmieren unter die Arme greift, sei es mittels IntelliSense, Code-Analyse, der Möglichkeit, den Stil des Codes über eine .editorConfig vorzugeben, Templates für die Erstellung neuer Applikationen vorzugeben und noch vieles mehr. Das Ganze natürlich "so nebenbei", während wir auf einem zweiten (oder dritten oder vierten) Bildschirm den Webbrowser mit gefühlt 100 Tabs offen haben, von denen jeder Tab eine andere Seite der Dokumentation zeigt.
Die Softwareentwicklung hat sich in den letzten 30 Jahren extrem verändert. Vieles ist besser geworden - beispielsweise die Masse an Dingen die mittlerweile möglich ist, durch Internet, Cloud, etc. - aber auch die Komplexität wurde größer. Früher reichte es mir, wenn ich Pascal konnte (oder die Programmiersprache meiner Wahl), denn wo kein Internet, da keine Website, und wo kein Windows, da nur DOS - kein Multitasking, immer nur ein Programm offen (wollte man ein anderes starten musste man das aktuell offene halt schließen), keine Computermaus (!), nur ein Bildschirm, wobei meiner mit seiner 15" Trinitron-Röhre schon das höchste der Gefühle war. Damals gab's halt nur CRT.
Die Trinitron-Röhre war übrigens genial. Während der Bildschirm herkömmlicher Monitore (und auch Fernseher) vom Grundprinzip her der Ausschnitt einer Kugel war (also sowohl horizontal als auch vertikal leicht gekrümmt), war das bei Trinitron-Röhren anders. Diese basierten auf einem Zylinder, d.h. nach oben und unten gab es keine Krümmung, was ein viel schöneres Bild ergab (und generell den Bildschirminhalt "gerader" aussehen lies). Heute haben wir Flachbildschirme, und die sind definitiv eine Verbesserung - mein 15-Zöller von damals ragte nämlich gefühlt einen Meter nach hinten über den Schreibtisch hinweg, und mehrere davon ersetzen mühelos eine Zentralheizung.
Was haben wir uns damals gequält (im Vergleich zu heute). Man könnte aber auch sagen, wir haben damals noch programmiert und wurden nicht für jeden Firlefanz an die Hand genommen. Ja, ich weiß, das ist bewusst überzogen formuliert.
Was die Komplexität angeht ... wie angesprochen reichte früher eine Programmiersprache aus, sei es Pascal, C, oder später C++. Einige haben sich auch an Assembler rangetraut, was mit 8- oder 16-Bit noch in Ordnung war, aber spätestens mit 32-Bit-Rechner eine Qual wurde. Trotzdem - Pascal bot auch die Möglichkeit, direkt Assembler-Code einzufügen, für einige Routinen die man besonders schnell haben wollte. Aber auch der Compiler von Borland war schon sehr gut und produzierte performanten Code. Performance war ein wichtiger Punkt, da die Rechner jener Zeit noch nicht mit Geschwindigkeiten im GigaHertz-Bereich prahlten, sondern mit 16, 25 oder 33 MegaHertz auskommen mussten.
Heute reicht eine Programmiersprache nicht mehr aus, nicht mal die Kenntnis einer einzigen Programmierplattform. Zu den Programmier- und Beschreibungssprachen, die heutzutage auf dem Menü stehen, gehören (unter anderem): HTML, CSS, SCSS (Sass), Less, Javascript, Typescript, Angular, React, NextJs (auf Basis von React), jQuery, .NET, .NET Core, C# (natürlich), ggf. in Zukunft Blazor, Architekturen wie MVC oder MVVM, WPF (Windows Presentation Foundation), Toolings wie Grunt oder Gulp, und noch viele andere Dinge mehr. Es gibt also sehr viel mehr zu lernen.
Das Killerfeature seinerzeit bei Borland Pascal war, wenn ich mich recht erinnere, die Syntaxhervorhebung innerhalb der IDE, weiß bzw. gelb auf blau. Der blaue Hintergrund war das Markenzeichen von Borland, das änderte sich erst als Delphi auf den Markt kam (das aber auch noch eine Anzeigeoption für die "traditionelle" Variante beinhaltete, wenn ich mich recht erinnere). Allerdings hatte Deplhi, so hervorragend es auch war, den Kampf bereits verloren als es erschien - Microsoft war schneller gewesen und hatte 1991 die erste Version von Visual Basic veröffentlicht, mit der man Anwendungen gewissermaßen "zusammenklicken" konnte. Zum Zeitpunkt als Deplhi erschien (1995) war VB bereits in der Version 3 verfügbar (wenn ich mich recht erinnere), und das Rennen damit gelaufen. Und das, obwohl Delphi (subjektiv für mich, aber ich denke auch objektiv im direkten Vergleich) die klar bessere Software war.
Wer das Ganze bis hierher gelesen hat und diese Zeiten miterlebt hat, könnte ein wenig nostalgisch zurückdenken ... die jüngeren unter uns werden vermutlich eher etwas in der Richtung "Oh mein Gott, wie konnte man so arbeiten" denken. Aber ernsthaft - es gab durchaus Dinge, die damals wirklich besser waren.
Was ich subjektiv als besser empfand war, dass ich nicht "gegängelt" wurde von meiner Entwicklungsumgebung. Beispiel Visual Studio Code: "Wir haben festgestellt dass du Feature XYZ aktiviert hast, willst du nicht dafür Addon ABC oder DEF installieren?" - Nein, will ich nicht, und wenn ich es will suche ich mir die Addons die ich brauche gerne selbst raus. Oder das Visual Studio, das mich heute (wenngleich wirklich dezent) "fragte" ob ich nicht an einer Umfrage teilnehmen möchte. Nein, will ich nicht, ich hätte gerne einen Knopf, der derartigen Anfragen komplett und für alle Zeit abschaltet. Ich hätte auch gerne einen Knopf, der jegliche Rechtschreibprüfung in allen Tools abschaltet - die müssen auch nicht die Sprache erkennen, in der ich gerade schreibe. Zugegeben, das mag für den einen oder anderen sinnvoll sein, für mich nicht, also möchte ich da entweder die Wahl haben, oder es sollte von Anfang an ein Opt-In sein, kein Opt-out.
Microsoft macht da leider auch bei .NET nicht halt. Im .NET Framework gibt es für ASP.NET MVC eine Funktionalität, mit der ich eine Methode in einem Controller aufrufen kann (@Html.Action()). In .NET Core fehlt diese, als Ersatz werden ViewComponents genannt. Das ist aber leider nicht das gleiche, ViewComponents kann ich nämlich nicht mal einfach so nachladen, ggf. noch mit Übergabe von Parametern etc. ... aber die "alte" Funktionalität wurde gestrichen. Ich würde mich wirklich sehr freuen, wenn die Entwickler bei Microsoft aufhören würden, mir zu sagen, was für mich das Beste ist - das kann ich schon selbst entscheiden.
Das artet jetzt schon in einen "Rant" aus ... ich habe die @Html.Action()-Funktionalität übrigens bereits als TagHelper für ASP.NET Core nachgebaut, mehr darüber in einem späteren Post.
Zurück zu dem, was besser war. Dazu muss man sich zunächst folgendes vorstellen: Programmiert wurde damals unter DOS, d.h. Dateinamen konnten exakt 8 Zeichen haben (plus Erweiterung), und wenn ich mich recht erinnere waren auch die Namen von Variablen und Parametern limitiert, wenngleich nicht auf 8 Zeichen. Die Programme, an denen ich damals arbeitete, hatten ca. 2 Mio Zeilen Code - und nichts davon war generiert. Um sich dort zurechtzufinden waren einige Dinge wichtig:
- Ein Benamungsschema, an das sich jeder halten musste, für Methoden und Dateien (vor allem für Dateien)
- Möglichst kleine Methoden, damit die Komplexität innerhalb der Applikation nicht zu hoch wurde
- Gleichzeitig mussten die Programmbestandteile wiederverwendbar sein (beispielsweise musste eine Kundenliste aus den verschiedensten Situationen heraus aufgerufen werden können, das wollte man nicht immer neu programmieren). Das bedeutete, dass man erst mal nachdenken musste, bevor man die erste Zeile Code schreibt.
- Code musste verständlich sein (Dokumentationskommentare gab's in der Form nicht, wenngleich wir mit normalen Kommentaren arbeiteten. Aber ohne Intellisense hilft das auch nur wenn man in den Code schaut, nicht wenn man eine Methode aufruft)
Die ganzen kleinen Helfer, die wir heutzutage zur Verfügung haben, sind durchaus nützlich, keine Frage. Aber wir sollten uns nicht zu sehr auf sie verlassen. Kleine Änderungen an der Art der Programmierung (beispielsweise keine riesigen Methoden mehr schreiben, oder auch keine "Blackboxen" einführen, bei denen niemand mehr versteht wie das Feature überhaupt funktioniert) können eine große Wirkung haben - nämlich weniger Zeitverlust durch Fehlersuche, Einarbeitung eines neuen Kollegen, etc.
So, das soll mal genug gewesen sein. Wer bis hierher gelesen hat - Chapeau. Die nächsten Posts werden sicherlich kürzer und interessanter.