(Vorbemerkung: Meine persönlichen Erfahrungen mit Node.js beschränken sich außer der testweisen Installation von Etherpad Lite auf den zumindest erfolgreichen Versuch, eine Desktopanwendung mit Electron zu schreiben. Diese Anwendung wird allerdings zunächst in einer anständigen Sprache neu implementiert, bevor ich sie für hier veröffentlichungstauglich halte; auch, weil Node.js eine schlicht unbrauchbare Programmierumgebung ist.)
Dieser Tage geht das NPM-Debakel durch deutsche Technikmedien, das sich etwa folgendermaßen zusammenfassen lässt: Der Entwickler einer bekannten und viel genutzten JavaScript-Bibliothek, die aus einem Zufall heraus genau so heißt wie einer der zahlreichen ICQ-Klone, wird von den Machern dieses ICQ-Klons darum gebeten, den Namen zur eigenen Verwendung freizugeben; er bietet ihnen kulant an, dass sie ihm den Namen abkaufen können, sie lehnen ab und drohen stattdessen den Machern von “npm”, einem großen Verzeichnis von JavaScript-Bibliotheken, mit rechtlichen Schritten, wenn sie den Namen für ihre geplante Bibliothek nicht freigegeben bekommen. Der Entwickler der eingangs erwähnten Bibliothek bekommt also “seinen” Namen von Dritten entzogen und zieht daraufhin verständlicherweise erbost all seine Projekte aus dem Verzeichnis zurück, woraufhin offensichtlich ein bedeutsamer Teil der dort aufgeführten Projekte, darunter große Frameworks wie React.js, plötzlich nicht mehr funktionierte, weil sie ihrerseits für triviale Aufgaben (dazu komme ich gleich) auf seinen Code zurückgegriffen haben.
Nun könnte man darüber spekulieren, wer hier eigentlich “die Schuld” trägt und ob der Kapitalismus nicht dringend abgeschafft werden sollte, um solche Streitigkeiten um Markenrechte künftig nicht mehr zu lukrativen Nebeneinnahmen machen zu können. Dabei liegt das Problem viel näher — das Problem heißt Node.js.
Dass man JavaScript besser nicht für ernsthafte Programmierung nutzen sollte, ist längst kalter Kaffee (macht also, wie der Volksmund behauptet, fast so schön wie ein Döner), und das nicht nur, weil JavaScript im Jahr 2016 das Haupteinfallstor für Schadsoftware im Browser ist. Nun ist es bedauerlicherweise immer noch Konsens, dass dynamische Inhalte im Browser in JavaScript geschrieben sein sollten, sieht man von Parenscript, Emscripten und vielen weiteren Projekten ab, die das Schreiben von JavaScript in einer richtigen Programmiersprache ermöglichen und dem Entwickler bis zur Fertigstellung wenigstens die Syntax vom Hals halten. Daran lässt sich nichts so einfach ändern, das ist eine Entscheidung derer, die irgendwelche wüsten “Standards” festlegen.
Node.js verfolgt einen anderen Ansatz: Im Kern aus V8, der JavaScript-Komponente von ausgerechnet Googles Chrome-Browser, bestehend zielt es auf die Verwendung in Netzwerkanwendungen, sozusagen als Ersatz für Perl, PHP, Python und dergleichen, völlig losgelöst vom Browser. Nicht, dass das besser wäre, denn die wesentlichen Schwierigkeiten der Sprache JavaScript hat Node.js natürlich auch, dort üblich ist es aber, sie zu kaschieren, indem man die vorhandene Sprachstruktur bis zur Unkenntlichkeit mit Code fremder Leute aufbläht: Hier noch ein Framework, da noch eine Bibliothek, zusammengeklebt mit allerlei Hokuspokus mit Funktionen, die niemals dafür gedacht waren. Dabei sind die Aufgaben oft trivial: Welches Framework soll ich nutzen, um zwei Zahlen zu addieren? — Nein, das ist natürlich nur ein Scherz, diese Frage hat niemand tatsächlich gestellt. Anscheinend wäre aber in der Welt von Node.js keine Frage zu blöd, um sie mit einem neuen “Paket” zu beantworten; nennen wir hier zum Beispiel doch nur einmal diejenigen, die sich Pakete wie noop4 (“no operation 4”) ausdenken, das nach der Installation dafür genutzt werden kann, überhaupt nichts zu tun. Weil’s der Neugier dient: Natürlich gibt es auch “noop” 1 bis 3.
Fefe hat derweil herausgefunden, dass es sogar ein Paket (in Version 3.1.0, ich wiederhole: 3.1.0) gibt, das prüft, ob eine Zahl positiv ist, was ja in anderen Sprachen (oder heißt das heute alles “Ökosystem”?) ein verdammtes Sprachfeature ist, was einiges erklärt: Eine typische Node.js-Anwendung besteht überwiegend aus dem Code fremder Leute. Wenn da irgendwo ein tiefgreifender Fehler passiert, stelle ich mir die Fehlersuche zumindest als angemessene Strafe vor. Die in seinem Blogartikel erwähnten PHP-Entwickler — zu denen ich vor einer Weile auch beruflich noch zählte — als ähnlich niedrigstufig anzusehen halte ich übrigens für etwas zu kurz gedacht, weil es anders als in Python, Perl und so weiter in PHP schlicht nicht nötig ist, die Standardbibliotheken um ein Vielfaches zu “erweitern”. Während ich übrigens diesen Text hier konzipierte, kam ich mit einem typischen Node.js-Entwickler ins Gespräch, dessen Ergebnis zusammengefasst lautete, dass ich zweifelsfrei ein “PEGIDA” unterstützender Neonazi sei, weil ich wahrheitsgemäß behauptete, in meinen bisher fünfzehn Jahren mit PHP kein einziges “PHP-Framework” wie das “Zend Framework” oder “Symfony” benutzt haben zu müssen, weil ich dort zumindest serverseitig mein Zeug gern mal selbst schreibe, damit ich weiß, wo alles steht. So weit ist es schon gekommen, dass man sich von Hipstern anpöbeln lassen muss, weil man sich nicht grundsätzlich auf fremden Code verlassen möchte.
Ich schweife (schon wieder) ab. Was ich eigentlich festgestellt haben wollte: Node.js richtet sich wie Java offensichtlich an Leute, die nicht programmieren, sondern nur fremden Code zusammenkleben wollen. Egal, wie einfach eine Methode selbst zu implementieren ist, es hat schon wer gemacht und deswegen hängt man lieber eine zusätzliche Abhängigkeit in sein Programm. Ein Paket, das mit einem Einzeiler (!) überprüft, ob eine Variable ein Array ist, hat 880.000 Downloads pro Tag.
Und dann stellen sich die gleichen BWL-Schlipsträger, die schon mit dem sturzfreien Adressieren einer E‑Mail überfordert sind, aber von Firmen viel zu hoch dafür bezahlt werden, dass sie ihnen raten, gefälligst immer auf das neueste Framework zu setzen, egal, wie gering der Mehrwert auch sein mag, was unvermeidlich dazu führt, dass solche Techniken, die immerhin wertvolle Minuten beim allsemestrigen Umstieg sparen, zusätzlichen Auftrieb erhalten, vor das erstbeste Mikrofon und beklagen sich, dass heute keiner mehr anständig programmieren kann.
So viele Mittelfinger kann ich mir gar nicht wachsen lassen.
Ich als jemand, der JavaScript so weit wie möglich meidet, habe das hier ja eher für eine Satire gehalten…
Gut, dass man Common Lisp in JavaScript übersetzt kriegt – falls ich doch mal wieder muss.
Naja, im Vergleich zu Lisp Code ist das Beispiel doch lesbar.
Ich habe mal n x‑beliebigen Lisp Code gesucht und das gefunden https://github.com/vydd/sketch/blob/master/src/color.lisp — der Javascript Code ist egal wie komplex er eigentlich ist, relativ (also auch für Nicht JS Programmierer) lesbar. Was man von Lispcode nicht unbedingt behaupten kann.
Auweia, der Vergleich ist ja schon schlimm. Javascript-Code, der Zahlen vergleicht, und eine Grafikbibliothek. Die würde in JS auch nicht besser verständlich sein.
Und stell dir das erst mal in Perl vor.
Lesbarkeit hat ja erstmal nichts mit der Sprache zu tun, das ist sicher auch so umsetzbar das es für Aussenstehende lesbar ist — auch in und gerade in Perl.
Ist das z.b. lesbarer?
https://github.com/fukamachi/woo/blob/master/src/woo.lisp
Für mich nicht. Da ist jedes Perlmodul einfacher.
Aber der Code den Elias (auf Twitter) gezeigt hat vergleicht keine Zahlen, sondern ist vermutlich eine komplette Anwendung, für die in anderen Sprachen vermutlich 200KB Code notwendig wären, aber das kann man dann auch nicht vergleichen?
Ja, das ist sogar sehr lesbar. Selbst, wenn man den Code zum ersten Mal sähe, wüsste man sofort, was jede Zeile tut.
Ich habe unlängst einem Arbeitskollegen, der noch nie eine Zeile Lisp programmiert hat, eine Methode aus meinem neuen Programm (dazu schreibe ich demnächst was, wenn es fertig ist) gezeigt. Das Einzige, was er nicht sofort verstanden hat, war, was “numberp” macht. Versuch das mal mit einem beliebigen Perlmodul. Die sind ja oft recht, äh, schlecht formatiert.
Da siehste mal wie unterschiedlich der Blicklinkel ist, für mich ist das unlesbares Kauderwelsch. Mir fehlen Hinweise darauf was Variabeln, Schlüsselwörter sind oder welche Strukturen zusammen gehören. Das ist in meinen Augen eine Buchstabensuppe.
Da ich überwiegend mit Perl und Javascript arbeite sind für mich die hier “bemeckerten” Codes verständlich und nachvollziehbar. Und ja, wenn ich versuche ein Perl Modul zu verstehen ist das für mich einfacher, da diese i.d.R. gut dokumentiert sind oder der Code eindeutiger. Jeder kann halt das was er kann.
Was mich bei Node.js mehr nervt ist (wobei ich es nicht nutze) ist die “Javasierung”, die leider auch bei Perl immer mehr Einzug hält und vermutlich auch die Ursache für solche Codeauswüchse sind. Alles muss bis in jede Ebene auf’s Detail geprüft werden, anstatt einfach mal eine Ausnahme zu werfen.
Wobei ich aber davon ausgehe, dass es auch kleinste Standardmodule in C,Lisp oder in der Sprache XYZ gibt, die, wenn sie jemand löschen würde, viele tausend Programme betreffen würde.
Was aber z.b. auch ein Problem von PHP ist, da es kaum Standardmodule gibt, muss alles über Jahrzehnte mitgeschleppt werden und wenn die mysql erweiterung irgendwann mal entfernt wird, werden wohl auch einige dumm aus der Röhre schauen, derweil hat man dann drei mySQL Abstraktionsschichten gleichzeitig. Und was die Vielzahl der Methoden und die Inkonsistenzen der Aufrufe angeht ist PHP ja legendär.
Letztlich ist das was Node.js da macht der Versuch das zu vermeiden. Ob es gelungen ist, darüber läßt sich wohl streiten. Aber das ganze hat nun wenig mit dem eigentlichen Urheberstreit an sich zu tun.
In (Common) Lisp gibt es keine “syntaktisch getrennten” Variablen und Schlüsselwörter im eigentlichen Sinne. Alles ist eine Liste, wobei es zwei Arten von Listen gibt; entweder so was wie “1 2 3 4 5” oder so was wie “funktion param1 param2 param3”, was auch für das Setzen einer Variable (setze-variable name wert) gilt. So was wie “Schlüsselwörter” findest du da primär, wenn du mit Schleifen arbeiten möchtest. Das lässt dir aber auch gewisse Freiheiten: Du kannst deine Variable “list” nennen, ohne dass der Compiler sich (wie etwa in Scheme) beschwert, weil die “Funktion” list schon definiert ist. — Was Strukturen betrifft: Klammer auf = Strukturbeginn, Klammer zu = Strukturende. Hast du in Perl auch, sind nur mehr Klammerarten.
Versteh’ mich nicht falsch: Ich mag Perl auch deshalb, weil es so lustig aussieht. Ich nutze es nur nicht für alles, was ich schreiben möchte. Die Dokumentation von Perlmodulen ist aber oft schlichtweg grauenhaft. Eine “nackte” Parameterliste ist keine brauchbare Dokumentation.
ad PHP:
PHP 7 hat nach einigen Jahren, in denen die mysql_-Erweiterung “deprecated” (und auch als solche gekennzeichnet) war, die Unterstützung dafür ganz entfernt. Es gibt immer noch zwei verschiedene Datenbankanbindungen für MySQL im “Kern”, nämlich PDO und mysqli_, aber zumindest nicht mehr drei.
Zu deinem Kommentar paßt aber auch die erste Antwort auf diesen Tweet
Wo wir gerade bei Sprache sind: Dein letzter Satz hat vier Zeilen bei rund 140 Zeichen pro Zeile. Und das, um einen Sachverhalt zu beschreiben. Das geht aber auch besser.
Guten Morgen.
Korrektur: Dein vorletzter Satz. Der letzte ist perfekt.
Ich halte meine Leser für überwiegend undoof genug, um von Relativsätzen nicht überfordert zu werden.
Doof oder undoof spielt ja nicht die Rolle.