Ansichten eines Informatikers

Die Programmiersprache Python – und was nervt

Hadmut
14.2.2024 14:47

Einige Leser beschwerten sich, weil sie unter dem Blogartikel Python etwas über die Programmiersprache Python erwartet hatten und dann was über eine tote Schlange kam.

Einer schrieb, er habe das schon so verinnerlicht, dass er bei „Python“ nur noch an die Programmiersprache und nicht mehr an das Tier denkt, und sich erst gewundert habe, bis er gemerkt hat, dass es um ein totes Tier geht. Soll ja auch schon Kinder gegeben haben, die fragten, warum man ein Tier nach dem Computereingabegerät benennt.

Nun gut, sage ich was zur Programmiersprache Python: Ich mag sie nicht sonderlich.

Ich finde sie sogar recht primitiv und ungelenk, sperrig, dürftig. Quasi das BASIC des 21. Jahrhunderts. Man kommt an Python freilich nicht vorbei, weil

  • der Interpreter recht klein, kompakt und leicht zu integrieren ist, damit sogar solche Dinge wie MicroPython für ESP8266 und ESP32-Prozessoren ermöglicht. Was die Nischensprache lua eigentlich noch besser kann, aber sich als Nischensprache nicht durchgesetzt hat,
  • es ist bei vielen, sogar den monolothischen, immutable Linux-Distributionen bereits mitinstalliert, weil man darin oft besser und sicherer Skripten kann als in Shells,
  • man es für so wichtige Anwendungen wie Ansible braucht (mir ist Puppet zwar lieber, aber die kann man nicht vergleichen, die können sich gegenseitig nicht ersetzen)
  • weil es viele Bibliotheken nur für Python gibt, oder zumindest aktuelle, gepflegte Versionen nur (noch) für Python zu haben sind, etwa PyQt,
  • weil viele Programme dies als Interpreter eingebaut oder für die Datensprachen verwenden, etwa Scribus oder Blender,

Deshalb braucht man eigentlich gar keine Diskussion für oder gegen oder über Python. Python ist fast so unvermeidlich wie die Shell, und man kommt nicht dran vorbei, weil es inzwischen fester Bestandteil von Linux ist. Ob es einem gefällt oder nicht. Die Frage, was man von Python hält, stellt sich schlicht nicht, weil Python – leider – unvermeidbar, unumgänglich geworden ist. Man fragt auch nicht, was man von der Shell hält. Ist halt so. Mal muss man sie verwenden. Mal muss man nicht.

Mir gefällt Python allerdings nicht so. Die Syntax finde ich uäh, und damit meine ich nicht einmal die Struktur durch Einrückung, denn die verwende ich auch in anderen Sprachen, sondern schon die Auswahl an Sprachkonstrukten. Das ist irgendwie so wie gewollt und nicht gekonnt, und aus Rückwärtskompatibilität auch nie richtig gemacht. Python ist – wie so viele Programmiersprachen – irgendwie von Leuten gemacht, die das besser hätten bleiben lassen, weil sie kein Gefühl für Programmiersprachen haben, und vielleicht gerade deshalb ad hoc etwas zusammengebastelt haben. Python wirkt auf mich wie ein verfestigter Bastelversuch, wie ein Provisorium, das ewig hält.

Oh ja, es ist weit besser als Perl. Perl ist ja auch nur aus Versehen zur Programmiersprache geworden, das war ja ursprünglich nur das Ansinnen, sed und awk zu einer gemeinsamen Applikation zusammenzufassen und zu verbessern, und wurde darüber durch Erweiterungen versehentlich zur Programmiersprache gemacht, und so sah es dann auch aus. Python sollte das bessere Perl sein. Und so sieht es auch aus.

Ich persönlich programmiere sehr viel lieber in Ruby.

Ruby ist eine überaus elegante und syntaktisch schöne Sprache, mit der man überaus effizient, kurz, prägnant, fehlerarm, schön selbst sehr erstaunliche, komplexe Dinge hinschreiben kann, weil Ruby ein konsequentes objektorientiertes Prinzip verfolgt, ganz hervorragend funktional und mit Lambda-Ausdrücken umgehen kann (und das weit besser und schöner als explizit als funktional gebaute Sprachen wie der akademische Unfall Scala, und mit einer pfiffigen, wohldurchdachten Syntax und Semantik erlaubt, sich auf das wesentliche zu konzentrieren und möglichst wenig Sprachballast und Boilerplate-Code zu schreiben. Mit seiner Syntax, seinem Scope und seinem Umgang mit Lambda-Aussdrücken erlaubt Ruby, Sachen zu bauen, die wie Spracherweiterungen und dedizierte deklarative Sprachen aussehen, obwohl es nach wie vor normale Ruby-Syntax und deren Prinzipen von Objektorientierung und Lambda-Ausdrücken sind.

Ruby ist schwerer zu lernen und zu verstehen als Python. Wenn man Ruby aber verstanden hat, dann ist es einfacher, ein Programm in Ruby zu schreiben und ein Problem zu lösen, als in Python. Ruby ist einfach der größere Werkzeugkasten.

Außerdem hat Ruby ein sehr schönes und leistungsfähiges System zur Verwaltung von Bibliotheken, die Gems und den Bundler. Auch das ist sehr elegant und erlaubt es, vielen Versionen derselben Bibliothek nebeneinander zu halten und jedem Programm die zu geben, die es haben will. Bei Python ist das auch wie so auf die Schnelle hingemurkst und nie repariert.

Ich kann aber nicht umhin, auch an Ruby schwere Kritik zu üben, obwohl diese eigentlich alle Interpreter-Sprachen, auch Python, trifft:

Das fehlende Konzept einer Typenbindung von Variablen und Parametern ist eine Katastrophe.

Und sie finden das in Ruby auch noch toll, und verherrlichen es als „Duck Typing“ – einfach alles an Datentypen zu nehmen und dann was draus zu machen. In Anlehnung an das Kurzgedicht

“When I see a bird that walks like a duck and swims like a duck and quacks like a duck, I call that bird a duck.”

mit dem Gedanken, jeden Datentyp hinzunehmen, oder einfach auch damit zufrieden zu sein, wenn der Parameter, was auch immer er sein mag, auf die Methoden regiert, mit denen man ihn verwendet. Dazu verwenden seriöse Programmiersprachen „Traits“ oder „Interfaces“.

Hört sich niedlich an, und erlaubt auch in der Tat ein paar überaus leistungsfähige Dinge, ist aber im Ergebnis – ich sage es mal deutlich – Scheiße. Weil man damit ab einer bestimmten Programmgröße keine fehlerfreien Programme mehr hinbekommt, und man die Fehler immer erst zur Laufzeit findet, und einem dann unerwartet das Programm abstürzt oder Blödsinn baut. Neulich habe ich eine große Programmbibliothek (von anderen, nicht von mir) debuggt, weil irgendwas manchmal schief ging. Ergebnis: Eine Prozedur, die unter sich wieder mit einer Tiefe von 5 jede Mange andere aufruft, gibt normalerweise einen Array von Strings zurück. Ist es aber nur einer, dann gibt sie unter bestimmten Umständen nur einen String und nicht einen Array mit einem Element, den String, zurück. Weil es keine Typbindung gibt, und das geht dann irgendwo ganz anders, viel später, in irgendeinem anderen Programmteil schief. Oder ähnlich, eine Prozedur, die lieber nil als einen leeren Array zurückzugeben um anzuzeigen, dass sie kein Ergebnis liefern kann. Und das wird dann auch nie dokumentiert.

So schön und elegant und leicht das alles ist, und man kann damit wunderbar und schnell mal irgendwas skripten und nett programmieren, ist das alles qualitativ so schrottig, dass man sich darauf einfach nicht verlassen kann.

Das Gegenteil davon ist Rust. In Rust prüft der Compiler so streng, dass eine unglaubliche Menge an möglichen Fehlern schon beim Übersetzen erkannt und damit verhindert werden. Dafür kann es sehr lange dauern, bis man sein Programm so geschrieben hat, dass der Compiler es überhaupt übersetzen will, statt einen einen Idioten zu heißen, der des Programmierens unfähig ist, und den Quelltext einer Compilation für unwürdig zu erachten. Die für Ruby und Python so charakteristischen Laufzeitfehler sind in Rust ausgeschlossen. Rust-Programme sind sehr schnell und gut, aber leider auch monströs groß und deren Erstellung doch mühselig, und das Bibliotheksangebot (noch) dürftig.

Langer Rede kurzer Sinn:

Es gibt gerade keine Programmiersprache, die mir vollends gefällt. Für den meisten kleinen Alltagskram verwende ich Ruby.

Dringende Bitte

Nach solchen Artikel werde ich regelmäßig überflutet mit Zuschriften der Art „Warum nimmst Du nicht X?“ oder „Kennst Du Y noch nicht?“ oder „Ich bin so zufrieden mit Z“. Bei Programmiersprachen gerne auch, warum Turbopascal immer noch die beste ist. (Analog bei Linux-Distributionen, Auto- und Kameramarken.)

Leute: Bitte lasst diesen Blödsinn bleiben!

Schon allein der bloße Umstand, jemandem einfach mal so einen Umstieg auf eine andere Programmiersprache zu empfehlen entlarvt Euch als Laien und Schwätzer. Denn wer von heute auf morgen seine Sprache wechselt – oder glaubt, dass andere das tun könnten – zeigt, dass er selbst keinen großen Bestand hat, und gar nicht abschätzen kann, wieviel Aufwand das ist, seinen Softwarebestand umzustricken.

Und so lieb es gemeint ist: Ich bin Informatiker. Das mag sich jetzt arrogant anhören, aber ich brauche keine 300 Zuschriften von Hobbyisten, Amateuren und Auch-Programmierern, mit welcher Sprache sie so zufrieden sind, dass ich die mal „ausprobieren“ müsste, als ob ich mal eine andere Marmeladensorte aufs Brot schmiere. Der schiere Vorgang an sich, jemand anderem, von dem man nicht weiß, was er macht und wie er programmiert, einfach so ins Blaue eine ander Programmiersprache zu empfehlen mit der Begründung, man finde die so gut, disqualifiziert sich sofort dazu, anderen Programmiersprachen zu empfehlen. Jemandem, der nicht Anfänger ist, ohne Kenntnis der Aufgabenstellung und Anforderungen eine Programmiersprache zu empfehlen, gehört zur Gattung jener seltsamen Paradoxien, für die man zu doof ist, wenn man sie tut, und zu denen nur der fähig ist, der sie unterlässt. Unter keinen Umständen würde ich mir eine Programmiersprache von jemandem empfehlen lassen, der sie mir empfiehlt, ohne zu wissen, was ich mache, brauche, will.

Immer, wenn ich etwas zu bestimmten Themen schreibe, kommt danach eine Flut von Zuschriften von Leuten, die aus ihrer kleinen Welt heraus meinen, die allerbeste aller Programmiersprachen zu kennen und empfehlen zu können. Und dann meist auch noch irgendwelche Orchideensprachen, die kaum Einsatz finden, irgendeinem abstrusen Paradigma folgen oder auf Gedeih und Verderb an eine einzelne Firma gebunden sind. Bitte hört auf damit. Ihr wirkt damit wie jemand, der einem das Provinzdorf X zum Leben empfiehlt, sein ganzes Leben lang aber selbst nie aus dem Dorf herausgekommen ist und nur dieses kennt. Ihr macht Euch nur zum Affen mit diesen „Ich bin so zufrieden mit der Sprache [BLUBBER], willst Du die nicht auch mal probieren?“

Nein, will ich nicht. Weil es mich auch überhaupt nicht interessiert, wie schön und toll und anfängergeeignet [BLUBBER] ist, solange nicht klar ist, worin die relativen Vor- und Nachteile gegenüber meinem jetzigen Zustand sind und wie hoch der Migrationsaufwand ist.

Und noch weniger – T’schuldigung, wenn ich es mal so direkt und offen sage – habe ich die Zeit für endlose Diskussionen auf Laienniveau mit Leuten, die mir unbedingt einreden wollen, dass die Sprache X, von der ich noch nie gehört habe, so toll sei, weil sie 1994 darin irgendeine Murksfinanzbuchhaltung oder den Stundenplan für die Kinder geschrieben haben, und die dann nicht mehr locker lassen, bis man die Sprache ihrer Wahl übernimmt, oder zutiefst beleidigt sind, wenn man ihnen nicht nachgibt.

Leute, ich bin Informatiker und habe im Laufe meines Lebens in mindestens 30, eher über 50 Programmiersprachen programmiert. Erstens bin ich selbst in der Lage, mir etwas auszusuchen, was meinen Anforderungen möglichst nahe kommt. Zweitens bewerte ich Programmiersprachen nach völlig anderen Kriterien als Autodidakten und Gelegenheitsprogrammierer, es ist für mich beispielsweise ziemlich irrelevant, ob eine Sprache leicht zu erlernen oder damit das Programmieren leicht zu lernen ist, und sowas. Und drittens ist es Informatikern innerhalb gewisser Kategorien gleichmächtiger Sprachen schlicht egal, in welcher Sprache sie programmieren, weil der Arbeitsablauf und die Verfügbarkeit von Bibliotheken viel, viel wichtiger sind. Viertens: Ich glaube Euch, dass Ihr mit eurem Porsche oder Cabrio viel Spaß habt, es ist aber für Klempner, Ladenketten, Spediteure trotzdem das falsche Auto. Denkt mal drüber nach.

Und noch nie, noch nicht ein einziges Mal, konnte irgendwer einen guten Rat für eine Programmiersprache abgeben, ohne zu wissen, was der Zweck und die Anforderungen sind. Der einzige Rat, den man bei vielen Programmiersprachen blind abgeben kann, ist von ihnen abzuraten.

(Manchmal kommt mir der Gedanke, dass es genau dieses Gehabe ist, das von Feministinnen dann für „Mansplaining“ gehalten wird.)

Sorry, das musste jetzt mal raus, weil mir diese ständigen „Warum nimmst Du nicht …“-Mails bei bestimmten Themen und Kategorien so auf die Nerven gehen.