Warum ist die 5. Computergeneration gescheitert?

Eigentlich hat es in den 1980’er so gut angefangen, man hatte LISP, VLSI-Chipfertigung und man hatte eine Idee. Sie lautete, dass man einen stackbasierenden Prozessor zu einem Transputer hochrüstet, darauf ein Lisp-Betriebssystem per Bootstrapping installiert und auf der Maschine dann Künstliche Intelligenz betreibt. Ein sehr schöner Plan nur wurde daraus nichts. Rein formal gab es sie, die Lisp-Maschinen der 5. Computergeneration mit leistungsfähiger Software wo 3D Animation und Vernetzung möglich war. Und sie verwendeten tatsächlich Transputer welche der Stackarchitektur von heutigen GA144 Chips zum verwechseln ähnlich sahen. Das entscheidene war nicht so sehr die 5. Computergeneration sondern das was danach kam. Wenn man bereits die besten Computer der Welt besitzt auf der die schnellste und schönste Software läuft, kann man von dort aus nur noch verlieren. Wer auf dem Berg ganz oben steht hat nichts mehr was er bezwingen kann, also heißt es den Abstieg wagen. Und genau das ist die eigentliche Herausforderung. Wie entwickelt man Computer die weniger leistungsfähig sind als die Generation davor? Wie programmiert man Software die nicht mehr sondern weniger leistet?

Was danach kam steht in den Geschichtsbüchern drin. Es ist die Zeit ab dem Jahr 1990, wo nicht Lisp-Maschinen sondern Wintel-Systeme ihren Siegeszug antraten. Sie wurden betrieben mit der x86 Architektur und verwendeten Microsoft Windows als Betriebssystem. Später wurde noch das Telefonkupferkabel mit einer Uralt-Technologie namens DSL in Hochgeschwindigkeitsbandbreite umgewandelt worüber die Erfinder Lisp Maschinen nur müde gelächelt haben. Der Unterschied ist, dass sich die Lisp Maschinen nicht durchsetzen konnten, aber die Windows98 PCs hingegen schon. Das ist merkwürdig wenn man unterstellt, dass es nur ein höher schneller weiter gibt. Aber offenbar kann man Technologie auch in unterschiedliche Richtungen entwickeln, hin zu kaputten dysfunktionalen Systemen. Unnötig zu erwähnen, dass als nächste Iterationsstufe dann Issue tracking bei der Softwareentwicklung berühmt wurde. Gab es in den 1980’er Jahren keinerlei Probleme bei der Softwareentwicklung und konnte man komplette Betriebssysteme in weniger als 1000 Zeilen Forth Code schreiben, hat man heute Bugtracker mit genervten Usern und überforderte Developern die sich durch Millionen Zeilen von Java Code wühlen. Die Software ist nicht leistungsfähiger geworden, sondern sie ist heute kaputter denn je.

In den 1980’er gab es noch Schönheit in der Informatik, also Maschinen die rein waren. Es waren elegante saubere Systeme auf denen funktionsfähige KI-Software lief, schön in sterilen Reinräumen in denen gesunde Menschen arbeiteten. Heute ist alles anders. Heute sitzen überfettete Nerds vor gammligen Gamer-PCs und müssen sich durch schlampig programmierte Software kämpfen, die teilweise von Viren heimgesucht wird. Zwischendurch macht der Router Probleme und die Programmierprojekte scheitern reihenweise. Was ist seit den 1980’er schiefgelaufen, sind die Menschen etwa dümmer und fauler geworden? Was ist aus den Idealen geworden nach denen früher einmal Hard- und Software entwickelt wurde, wo sind sie geblieben die schönen Metageneratoren, welche sauberen Code aus Spezifikationen generieren anstatt so wie in der verkommenen Gegenwart wo git und ähnlicher Unsinn Einzu gehalten hat und die Teams vergiftet?

Die Blütezeit der Informatik waren die 1980’er Jahre. Dort war die Technologie auf ihrem Scheitelpunkt angelangt, sie hatte sich diesen Sieg mühsam erkämpfen müssen. Aber man war stolz darauf. Die 1980’er waren gekennzeichnet durch eine gesellschaftliche Stabilität, wo also Programmierer in gut bezahlten Berufen arbeiteten und dort leistungsfähige Systeme entwickelten. Es gab damals Roboter, Computeranimation, Internet, Virtual Reality, eigentlich alles was man mit Computern machen kann. Leider sind die 1980’er Jahre vorbei. Sie kommen nie wieder zurück. Die Art wie damals Informatik betrieben wurde ist heute nicht mehr angesagt. Ich glaube es ist an der Zeit, die 1980’er dezidiert zu untersuchen. Es war nicht irgendeine Epoche in der Computergeschichte sondern es war die letzte Epoche.

In den 1980’er gab es HDTV Fernsehen auf superscharfen Monitoren. Und was gibt es heute? Verwackelte youtube Aufnahmen in 240p, die zwischendurch noch Verbindungsprobleme verursachen. Die Technologie hat sich seit damals beträchtlich zurückentwickelt. Ursache dafür ist, dass heute Leute an der Software herumprogrammieren die davon keine Ahnung haben. Linus Torvalds wurde schon genannt, aber auch die Firma ARM und Google zählen dazu. Alles keine reinen Technikprojekte mehr sondern die Unternehmen verstehen sich als Bildungseinrichtungen die ihren Angestellten Wissen vermitteln. Heute wird typischerweise Software nicht mehr von Programmierern sondern von Literaturwissenschaftlern oder sogar Musikern programmiert. Das kann nur schiefgehen.

Advertisements

Die ersten Schritte in der Robotik beginnen mit dem Fallen-Lernen

https://robotics.stackexchange.com/questions/14240/first-steps-in-robotics Es ist immer schön zu hören wenn sich jemand für die Robotik interessiert. Es ist ein sehr spannendes Gebiet, ja das interessanteste was es überhaupt gibt. Das der Einstieg etwas konfus verläuft verwundert wenig. Die Frage des OP ist fast schon typisch, sie kommt extrem häufig bei Stackoverflow vor und der Grund dafür lautet, dass Robotik weitestgehend unerforschtes Gebiet ist. Das beste was man für den Anfang lernen kann ist zu versagen. Egal welches Einzelthema man sich heraussucht, egal ob man mit Java oder C++ anfängt, ob man Mindstorms, Arduiono oder doch einen pneumatischen Muskel für die ersten Gehversuche verwendet, es wird garantiert scheitern. Das heißt, man wird mit der Technik wochenlang herumspielen nur um zu erfahren, dass es nichts bringt. Auf Youtube gibt es inzwischen eine schöne Kollektion an Clips mit failed robotics Projekten. Am besten Gefallen hat mir der extrem schwere Spinnenroboter eines Japaners, der schon sehr advanced aussieht aber dann doch das Gleichgewicht verliert und den Erfinder dumm zurücklässt. Ach so, bevor ichs vergesse, einen Lesetipp kann ich doch noch geben. Wenn man nur ein Paper lesen möchte, dann ist „Hasslacher, Brosl and Tilden, Mark W: Living Machines, 1995“, http://www.robot.cl/pics/viaje/living_machines.pdf ideal geeignet. Vom technischen Standpunkt betrachtet enthält es kompletten Unsinn, weil man so auf gar keinen Fall Roboter programmiert, aber es liest sich ziemlich gut.

Mergen ohne git

Das Mergen unter git ist gerade für Einsteiger ein Buch mit sieben Siegeln. Um die Dinge zu beleuchten zunächst ein Exkurs wie man ohne git mergen kann. Nehmen wir mal an, im Lokal Area Network befindet sich in einem Netzlaufwerk eine Excel-Tabelle auf die alle zugreifen können. Wie editiert man jetzt diese Datei? Am besten dadurch, dass man sich eine lokale Kopie erstellt „abrechnung-Kopie.xls“, und bei sich auf dem eigenen Computer daran Änderungen vornimmt. Anschließend kopiert man die Kopie zurück ins LAN-Laufwerk und dort gibt es folglich zwei Dateien „abrechnung.xls“ und „abrechnung-kopie.xls“. Die Konfusion die man dadurch verursacht hat und der Versuch es zu beseitigen wird als Merging verstanden. Genau genommen ist Merging als keine Teamarbeit wo man gemeinsam an Dateien arbeitet, sondern es bedeutet die oben beschriebene super-egoistische Arbeitsweise.

Magische Grenze von 10 Lines of Code im Linux Kernel

https://www.heise.de/ct/artikel/Die-Neuerungen-von-Linux-4-14-3831941.html
Das Buch „The Mythical Man-Month“ genießt unter Programmierern Kultstatus. Es enthält viel wares und zum ersten Mal wurde dort die Größe „Lines of Code“ diskutiert. Das Fazit lautete damals, dass ein durchschnittlicher Programmierer rund 10 Lines of Code am Tag schreibt. Bis heute wird diese Zahl von vielen als zu niedrig angesehen und behauptet, man könnte gut 500 Codezeilen am Tag schreiben, insbesondere wenn automatische Codegeneratoren verwendet werden. In einem früheren Blogpost habe ich schon die realen Werte von Microsoft Windows untersucht wo im Schnitt die Programmierer rund 6 Zeilen Code am Tag erstellt haben. Aber auch das als effizient geltende Linux Projekt schafft es nicht oberhalb von 10 Lines of Code pro Tag zu kommen. Die aktuellen Zahlen gibt es auf https://www.developer-tech.com/news/2017/jul/05/linux-kernel-412-developers-added-795-lines-code-hour/ Danach kommen pro Tag 19093 Codezeilen hinzu, die von 1821 Developern erstellt wurden. Macht nach Adam Riese einen erstaunlich niedrigen Wert von 10,48 Lines of Code pro Kopf und Tag. Ungeachtet dessen erklimmt der Linux Kernel in jeder Version neue Hürden und kaum jemand wird behaupten, dass dort nicht effizient gearbeitet wird, oder Greg Kroah-Hartman ein Anfänger wäre, der noch nicht richtig in C programmieren kann.

Ich glaube die Verwunderung über 10 LoC/Day kommt daher, dass über Softwareentwicklung meist Leute diskutieren die an den Universitäten arbeiten und selber noch nie Software entwickelt haben. Das eingangs zitierte Buch wurde nicht von einem Akademiker geschrieben sondern von einem IBM Angestellten. Die Vorstellung man könnte am Tag 500 Lines of Code erzeugen und womöglich noch Metaprogramming mit Haskel einsetzen ist wohl eine Vorstellung die so nur an den Universitäten gelehrt wird. Man teilt sie, wenn man sich einer Gruppe zugehörig fühlt welche für sich die Deutungshoheit reklamiert und eine sehr verzerrte Sicht auf die Wirklichkeit besitzt.

Meine Prognose lautet, dass man die 10 Lines of Code natürlich wird steigern können. Aber nur sehr mäßig. Vielleicht wird sie in 5 Jahren auf 11 Lines of Code pro Tag angestiegen sein, weil besser klar ist, was ein Kernel eigentlich ist und wie man richtigen C-Code schreibt. Der eigentliche Anstieg der Produktivität basiert jedoch auf einer anderen Größe: Zahl der Entwickler. Je mehr Coder man für den Linux Kernel abstellt und die in das Projekt integriert, desto schneller steigt die absolute Zahl an Codezeilen an. Noch vor ein paar Jahren waren es nur 1000 Developer die regelmäßig commits beigesteuert haben, heute weißt die Statistik einen Wert von 1800 aus.

Der Name Greg Kroah-Hartman wurde schon erwähnt. In einem Vortrag hat er einmal gezeigt wie genau sein täglicher Arbeitsablauf aussieht. Er hat damals auf der Commandline mal auf die Schnelle neue Commits in den Master-Tree übertragen und nebenbei noch am Sourcecode herumeditiert. Die Zuschauer waren beindruckt, weil das extrem Profi-mäßig daherkam. Was in dem Vortrag leider nicht erwähnt wurde ist, dass auch die Produktität von Kroah-Hartman nicht oberhalb von 10 Lines of Code am Tag liegt. Es macht eben einen Unterschied ob man Patches die jemand anderes geschrieben hat und die bereits jemand als korrekt bezeichnet hat, in das git repository einpflegt oder ob man richtige Software from scratch schreibt. Hätte Hartman damals in seinem Vortrag Kernel Programmierung unter Live-Bedingungen gezeigt, dann wäre über die Zeitdauer des gesammten Vortrags genau eine neue Zeile hinzugekommen. 10 Stunden Arbeit täglich geteilt durch 10 Codezeilen macht 1 Zeile pro Stunde. Rein statistisch gesehen bedeutet es, dass man pro Minute ein Byte anfügt. Also sehr gemächlich die Tastatur bedient. Was Hartman wohl eher demonstriert hat war, was passiert wenn man die Produktivität von 1800 Developern zu einem ganzen kombiniert. Es also mittels git schafft, dass man am Tag nicht 10 Zeilen Code neu dazufügt sondern 10×1800=18000 Zeilen. Dort kann man tatsächlich live Zuschauen wir das Projekt immer größer wird. Die Kernel Developer bilden einen virtuellen Superprogrammierer, der ziemlich schnell auf der Tastatur ist und perfekten C-Code schreibt. Jeden Tag erweitert er den Kernel massiv.

ForthOS ausprobiert

Das ForthOS Iso Image liegt auf http://www.forthos.org/install.html zum Download bereit. Um es zu starten muss man in CentOS vorher noch qemu plus kvm installieren. Dann noch schnell eine virtuelle Festplatte erzeugen und ForthOS hochfahren:

yum install qemu qemu-kvm
qemu-img create -f qcow2 hda.img 10G
qemu-system-x86_64 -hda hda.img -cdrom forthos.iso -boot d -m 1024 -enable-kvm -smp 2

Nach dem booten erhält man einen Forth Prompt auf dem man Forth Code eintippen kann, also „1 1 + .“ um eine Aufgabe zu rechnen. Leider geht im Hintergrund die CPU Belastung auf 100% hoch. Es ist unklar ob es sich dabei um einen Fehler handelt oder das ForthOS in Wirklichkeit ein böser Virus ist, der die CPU Zeit klauen will. Weitere Funktionen wie eine GUI habe ich in der Software nicht entdecken können.

OSKit
Nachdem das ForthOS nicht so funktioniert hat wie erhofft, bleibt Zeit noch etwas über das OSKit zu sagen. Zugegeben, ich habe das Projekt erst heute entdeckt, das Paper aus dem Jahr 2002 trägt den Titel „The oskit the flux operating system toolkit 0.97“ und wurde auf https://www.cs.utah.edu/flux/oskit/doc/oskit.ps.gz veröffentlicht. Wenn ich das Dokument richtig verstehe ist es ein Meta-Betriebssystem. Es basiert auf dem objektorientierten COM Modell aus dem Hardwaretreiber für Linux, FreeBSD und NetBSD abgeleitet werden. Ferner ist noch eine Virtual Memory Funktion und etwas Security mit dabei. Auch an eine X11 Grafikschnittstelle wurde gedacht. Zumindest nach dem Paper sieht es so aus, als könne man aus OSKit heraus Sourcecode erzeugen der dann für sehr unterschiedliche Betriebssysteme verwendet wird. Am besten sollte man gleichmal Linus Torvalds das Paper zuschicken, weil er sich dann viel Arbeit spart und nicht immer from scratch soviel selber Programmieren muss. Aber vielleicht gefällt ihm ja auch nicht der objektorientierte Ansatz über COM? COM ist ein Standard, der von Microsoft entwickelt wurde. Und dabei war Linux und Windows doch immer getrennt … Sehr merkwürdig das ganze.

Forth ist nicht fett

Manche Verschwörungstheoretiker behaupten, dass Forth eine verfettete Sprache wäre, die viel zu viel Möglichkeiten bereitstellt anstatt zwei drei wichtige Paradigmen anzubieten. Häufig wird das Bild einer vollgefressenen Tonne bemüht die alles in sich reinschaufelt was nicht bei drei auf dem Baum ist um so den Frust zu bekämpfen. Doch das ist nicht war. Forth ist eine extrem schlanke Sprache. Das dort Metaprogramming unterstützt wird ist kein Zeichen von zuviel, sondern sowas ist absolut nötig in der täglichen Programmierpraxis. Auch die Möglichkeit eigene Words anzulegen um den Sprachumfang beträchtlich zu erweitern ist Ausdruck eines minimalistischen Ansatzes. Das sich damit die Komplexität beträchtlich erhöht weil jeder seine eigene Word Datei erzeugt ist nur dummes Gerede. Wenn man „Create does“ richtig einsetzt ist es eine sinnvolle Erweiterung zu einem Forth System. Apropos System. Manche Leute sagen, dass man auch ohne Stack auskommt und sogar ohne lokale Variablen. Aber wie bitteschön will man denn ohne Stack sinnvolle Aufgaben ausführen. Nein, nein der Stack gehört zum absoluten Minimum, der muss einfach sein, sonst fehlt etwas. Ich meine, man kann ja den Stack, die umgekehrte polnische Notation und die fähigkeit als virtuelle Maschine nicht einfach streichen. Dann würde ja nicht mehr viel übrig bleiben, oder? Um halbwegs ansehnliche Programme zu schreiben braucht man einfach eine mächtige Hochsprache wie Forth die nicht nur compilerdirektiven, Präprozessoren und einen Interpreter mitbringt sondern ein eigenes Dateisystem, Plugins für selbstgeschriebene Erweiterungen sowie kleinere Spiele für zwischendurch. Das ist alles sehr schlank gehalten.

Forth ist eine kleine zierliche Sprache und keineswegs eine riesiger Truck der beide Fahrspuren benötigt und der über bestimmte Brücken schon gar nicht mehr drüberfahren darf weil er hoffnungslos überladen ist. Nein, Forth sieht sich dem Minimalismus verpflichtet es enthält daher keine überflüssigen Features wie sie in andernen Sprachen eingebaut sind. Bei C beispielsweise gibt es riesige Bibliotheken mit unmengen an Words, auf sowas kann Forth gut verzichten. Auch gibt es keine komplizierten Anleitungen wie bei Java sondern alles ist sehr spartanisch aufgebaut. Es gibt nur die eine Anleitung und wenn man die gelesen hat kann man sofort anfangen mit dem Programmieren. Es ist also keineswegs so, dass man erst beim Systemadminstrator einen Laufzettel ausfüllen muss nur weil man ein Hello World eintippen möchte. Nein, das geht alles sehr unbürokratisch, Forth ist ein sehr benutzerfreundliches System, insbesondere Bigforth steht im Ruf besonders leicht zu bedienen zu sein. Da ist alles auf einen schlanken Minimalismus hingetrimmt. Das Wort big ist nur eine Anspielung auf Small, was voll und ganz zutrifft.

Update Robot Control System

Das Robot Control System kommt gut voran. Ich habe inzwischen etwas entdeckt was das Projektziel ernsthaft gefährden kann: Forth. Das hört sich zunächst wie eine schlechte Nachricht an, aber wenn man wissen will was best-practices sind muss man auch dessen Gegenteil die Anti-Patterns kennen und lieben. Und davon bringt Forth eine ganze Menge mit. Die Sprache gilt als sehr teuer. Damit ist gemeint, dass es aufwendig ist, dorthin Sourcecode zu portieren. Wenn also das Softwareprojekt zu gut läuft und man vorhat ein wenig zu bremsen reicht es aus, wenn man Teile des Projektes auf Forth portiert. Mangels C-Compiler ist das nahezu unmöglich und bindet wertvolle Ressourcen, die woanders dringend benötigt werden. Als ersten Anfang habe ich einen Prototypen in Forth entwickelt der mal eine Roboterbibliothek werden soll:

\ Robotics Library in Forth
\ running with: gforth library.fs
: version ( no parameter )
  ." 1.0"
;
: quotient ( n1 n2 -- n )
  \ quotient of division
  \ returns: n1 % n2
  /mod  \ reminder and quotient to stack
  drop  \ leaves quotient on stack
;
: anglediff ( source target -- n )
  \ return difference between two angles
  \  temp = target - source
  \  temp = (temp + 180) % 360 - 180
  swap -   \ target - source
  180 +    \ +180
  360 quotient \ % 360
  180 -    \ -180
;
: calcdistance { p1x p1y p2x p2y }
  \ Euclidean ordinary distance
  \ return math.sqrt((p1[0] - p2[0]) ** 2 + (p1[1] - p2[1]) ** 2)
  \ { a b c d } store stack to local variables
  ." calcdistance"
  p1x p2x - \ px2-p1x

;
: polarpoint ( p1 angle radius -- n)
  \ polar coordinates for a point on circle
  ." polarpoint"
;

Irgendwas sinnvolles anfangen kann man damit nicht. Um das bisschen Code zu schreiben ging viel Zeit verloren. Aber dafür ist er in Forth geschrieben. Es ist als Huldigung an eine Sprache zu verstehen die hochgradig umstritten ist und von einigen als Hölle beschrieben wird. Ich würde Forth eher mit einem Fixed Gear Fahrrad vergleichen, bei dem man während der Fahrt mittreten muss. Es ist eine unglaublich coole Sprache, ich kenne keine andere, die faszinierender ist. Zugegeben, Forth ist nicht gerade geeignet wenn man die Dinge voranbringen möchte und neue Ideen ausprobieren will. Dafür ist C und darauf aufbauende Sprache die bessere Wahl. Sondern Forth ist kalkuliertes Chaos was man hinzufügt, damit alles schiefgeht was auch schiefgehen kann.

Zur Entspannung noch ein schönes Video was viel über das Lebensgefühl hinter Forth vermittelt: