Lesbarkeit vor Geschwindigkeit?
In wie fern ist schnellerer Programmcode signifikant komplexer/unlesbarer? Ich hätte dazu gerne ein paar Beispiele warum, da ich dem so nicht zustimmen kann.
Ich glaube es ist eher eine Frage wie man Programmcode gewohnt ist.
Das Ergebnis basiert auf 9 Abstimmungen
6 Antworten
Man sollte immer daran denken, dass irgendwann jemand den Code mal ändern/überarbeiten muss. Dazu ist es erforderlich, dass dieser Jemand sich möglichst schnell in dem Code zurechtfinden sollte.
Das bedeutet nur in seltenen Ausnahmefällen, dass der Code langsamer sein muss, nur weil er verständlich geschrieben ist. Im Zweifel liefert man Kommentarzeilen, die die Absicht des Programmierers erklären.
Und es gibt eine Reihe "good practices": Man nennt eine Variable nicht "v121ax" sondern "Steuer_Prozent". Und man nennt eine Subroutine nicht "wgstrg" sondern gibt ihr einen verständlichen Namen.
Und bei einigen (älteren) Sprachen gibt es Konstrukte, die man nicht benutzen sollte. So in COBOL:
perform varying Index depending on
Wer das tut, gibt ein Bierfass an die Kollegen!
"Alt" ist nicht schlecht! Ich habe vor gar nicht langer Zeit ein paar Programme "spaßeshalber" in Cobol geschrieben. Die Ausführungsgeschwindigkeit war sensationell. Aber die Kollegen waren entsetzt!
Und das ist das Problem: Die Kollegen, die noch Cobol können, sind Rentner oder auf dem Friedhof. Schade eigentlich.
Naja - die Lebensdauer von Menschen ist begrenzt.
Ich habe noch Cobol, Fortran und Algol60 gelernt. Die heutige Programmierer-Generation hat davon keine Ahnung mehr. Und ich werde nicht jünger.
Heute wird sehr viel Code in Java "abgesondert". Java ist eine extrem Hardware- und Speicherintensive Sprache (Gemessen an C und Assembler) Aber es ist eine Sprache, in der man sehr schnell Ergebnisse erzielt, deshalb ist sie sehr beliebt.
Natürlich ist ein Programmcode in einer Hardwarenahen Sprache schneller als in einer hochabstrahierten Sprache. Aber das interessiert heute niemanden mehr
Heutzutage ist die Leistung von Computern und Smartphones so gut, dass wirklich schneller Code nicht mehr benötigt wird. Man legt also mehr Wert auf sauberen Code, welcher einfach und verständlich ist. Es gibt aber Fälle, in denen ist Schnelligkeit wichtiger. Nehmen wir Rust und C# als Beispiel, wo dann unsafe Blöcke schnell mal hinzukommen und Rust, C#, C/C++, ... wenn man mit Pointern arbeitet. Man kann sehr schnell etwas kaputt machen, da die Standard-Checks nicht wirklich auf Pointer wirken. Dadurch muss man hier und da selbst Sicherheitsmaßnahmen implementieren, welche für den eigenen Code optimiert sind. Dies kann zu einen Code Overhead führen, welcher aber trotzdem schneller ist. Grundsätzlich ist mehr Code immer schwieriger zu lesen, weil es mehr ist. Besonders bei weniger erfahrenen Entwicklern kann sowas zu Fragezeichen führen. Ich könnte noch mehr Beispiele nennen, aber das sollte als Beispiel reichen. Kommentare sind natürlich immer wichtig. Der Compiler entfernt diese in der Regel, weshalb sie keine Leistung während der Laufzeit beanspruchen. Kommentare sind aber nicht allmächtig. Ein sehr komplexer Code mit Kommentaren bleibt komplex und muss verstanden werden. Besonders in Bereich der Wartbarkeit ist sauberer und einfach zu lesener Code wichtig und mit der heutigen hardware vereinbar.
Heutzutage ist die Leistung von Computern und Smartphones so gut, dass wirklich schneller Code nicht mehr benötigt wird.
Bist du sicher? Alles neue scheint sehe schlecht zu laufen.
Man legt also mehr Wert auf sauberen Code
Was wäre unsauberet aber achneller? Ich habe es schon oft gehört und gesehen aber es selbst ao nicht empfunden.
Naja, man muss unterscheiden zwischen: Ich Klatsche ein Produkt hin und gebe mir keine Mühe, wodurch Bugs in das Produkt kommen und ich gebe mir Mühe und Versuche vor dem Release alle Bugs zu beheben. Selbst der am sauberste geschriebene Code kann schlecht sein auf moderner Hardware, wenn man versehentlich bugs eingebaut hat oder andere Flaschenhälse.
Unsauber wären, nehmen wir Rust und C# als Beispiel, wenn du viel mit Pointern arbeitest, um Geschwindigkeit zu bekommen, da du direkt auf den Speicher zugreift. Der Nachteil des Codeoverheads sind hier dann unsafe Blöcke, pointer (also viel Referenz und dereferenz Symbole) und mehr. In diesen sprachen gibt es extra diese unsafe Blöcke, denn das direkte ungeschützte arbeiten mit dem Arbeitsspeicher ist zwar schnell, aber unsicher und unsauberen. Viele Compiler Optimierungen greifen nicht, wie sicherheitsmaßnahmen. Stell dir vor, während du einen Array erstellt und damit arbeitest, ist alles sauber lesbar. Jetzt allokierst du selbst einen Speicherbereich und verwendest ihn. Die Verantwortung liegt dann bei dir. Die nötigsten Checks und Validierungen musst du dann selbst einbauen wodurch der Code mehr wird und unlesbarer
Definiere Hochsprache. High Level Sprachen können alles sein. Sogar Rust und C++. Auch wenn man diese gerne als Low Level bezeichnet. Grundsätzlich sind High Level Sprachen die Sprachen, die höher sind als eine Low Level Sprache darunter. ASM wäre hier die Low Level Sprache und Rust/C++ die High Level Sprachen. Und ja, Sprachen, wie C#, Java, JS usw. gibt es schon ewig. Nehmen wir mal als Beispiel: Heutige Webanwendungen, gebaut mit Electron, Tauri, was auch immer, sind Recht ok. Sie sehen modern aus, können viel und laufen auf aktueller Hardware. Damals wurde dann doch eher C/C++ bevorzugt, da es auf der Hardware einfach besser lief
Ich habe nicht von Web gesprochen. C im Web ist erst mit WASM direkt möglich geworden. Aber ich rede von Desktop Anwendungen
Vieles. Noch nie von Electron, Tauri und co gehört? Siehe Discord, Teams und viele andere Programme. Das sind Websites, mehr nicht, auch wenn die aussehen, wie ein Programm.
Einfachheit, Geld Ersparnis. Viele können HTML und CSS, wie auch JS. Zudem braucht man nicht immer High Performance und die Hardware schafft das Recht gut heutzutage
Das nehme ich dir nicht ab. Selbst ein 2 GB Ram Raspberry Pi kann schon komplexe Anwendungen ausführen
Also ich persönlich stehe auch auf Maschinencode, deshalb arbeite ich in letzter Zeit sehr viel mit Rust 🙂
Ich mag dieses Browser Krams auch nicht
In wie fern ist schnellerer Programmcode signifikant komplexer/unlesbarer?
Auch gut lesbarer Code kann schnelle Ausführungsgeschwindigkeiten haben. Beides zusammen schließt sich nicht automatisch aus.
Wenn man aber nun vor der konkreten Entscheidung steht, ob man komplizierteren Code formuliert, der in einer besser lesbaren Form weniger schnell laufen würde, dann wäre zuerst einmal abzuwägen, inwiefern der gedachte Vorteil denn nun tatsächlich eine Gewichtung für das Endprodukt hat.
- Redet man hierbei von einer Zeitdifferenz in Minuten oder Nanosekunden?
- Inwiefern ist es in diesem Kontext überhaupt wichtig, dass der Code schneller ausgeführt werden kann? Bei einer Anwendung, die wöchentlich ein Backup eines Systems anlegt, ist die Gewichtung beispielsweise anders, als bei einer Rendering Engine, von der man erwartet, dass sie pro Sekunde eine bestimmte Anzahl an Bildern zeichnet.
- Erfüllt die komplizierte Version noch immer übliche Anforderungen (für gute Software) wie z.B. Testbarkeit oder Erweiterbarkeit?
Sofern es keine wirklich guten Gründe/Notwendigkeit für die kompliziertere Lösung gibt, sollte sie nicht verwendet werden.
Gut lesbarer Code hat immerhin den Vorteil, leichter und schneller verständlich zu sein. Andere Entwickler können sich daher unter geringerem Zeitaufwand einarbeiten und Anpassungen/Erweiterungen vornehmen. Umso komplizierter Code formuliert ist, umso größer ist hingegen die Wahrscheinlichkeit, dass sich Fehler einschleichen. Sei es bei der initialen Entwicklung oder später bei Wartungsarbeiten / Erweiterungen. Das kann der Grundstein für ein instabiles Endprodukt werden.
Ich hätte dazu gerne ein paar Beispiele (...)
Ein klassisches Beispiel ist Duff's Device zur Optimierung von Schleifenläufen. Dieser Kniff ist auf den ersten Blick nicht so einfach durchschaubar und könnte von einigen Entwicklern sogar als Syntaxfehler eingestuft werden. Für die meisten Anwendungsfälle mit Schleifen ist er unnötig, zumal aktuelle Compiler eh eigene Techniken zum Abrollen von Schleifen implementieren.
Als zweites (kleines) Beispiel könnte man die Iteration über ein Array via Iterator anführen. Tendentiell wäre eine eine klassische for-Schleife schneller. Der Unterschied ist aber zu gering, als dass er ins Gewicht fallen würde.
Allgemeiner kann man in diesem Zuge ebenso den Einsatz von Sprachen betrachten, denn wo möglich, verdrängen oft einfachere Sprachen solche, die schwerer zugänglich sind.
Ein gutes Beispiel ist das Anwendungsfeld der Entwicklung von Desktopanwendungen. C++ wurde hier im Laufe der Jahre von Sprachen wie C#, Delphi, Java, TypeScript oder Visual Basic immer weiter zurückgedrängt.
Noch ein Beispiel sind Python oder JavaScript, die sich in verschiedenen Anwendungsbereichen (z.B. ML, Web, IoT) stärker ausgebreitet haben. Nur die wirklich zeitkritischen Anforderungen werden noch in einer Sprache wie C implemetiert.
Übergreifend findet man immer wieder Aufteilungen in Softwareprojekten, bei denen man versucht, Komplexitäten zu entfernen:
- In Game Engines (CryEngine, Godot, Unreal, ...) kann die Spiellogik mit einfacheren Skriptsprachen oder einer visuellen Programmiersprache formuliert werden
- GUI-Toolkits setzen oft auf eigene Sprachen zur Beschreibung der grafischen Oberfläche (siehe FXML, HTML, JSX, kv, QML, XAML)
All diese Fälle sind Beispiele, bei denen man sich für Einfachheit / bessere Lesbarkeit entschieden hat, statt für eine bessere Ausführungsgeschwindigkeit.
Wenn Programmcode nicht lesbar geschrieben wird, wird es immer schlimmer, verbuggter und schwerer zu erweitern.
So das man am Ende möglicherweise es neu schreiben muss.
Es gibt kaum Anwendungsfälle wo Geschwindigkeit so wichtig ist, dass dafür Lesbarkeit (stark) reduziert werden sollte.
Weil du nicht denkst wie ein Computer, sondern in Abstraktionen.
Für den Computer ist „tu X 100 mal“ komplizierter als einfach hundert mal X hinzuschreiben, da er dann selbst zählen muss, springen muss und ausbrechen muss.
Wenn du aber eine Datei mit zehntausenden von Befehlen jeweils hundertemal wiederholt vor dir hast, liest du nix mehr.
da er dann selbst zählen muss, springen muss und ausbrechen muss.
Er muss den Code aber auch Laden oder nicht? Mehr Code bedeutet doch auch mehr Zeit zur Ausführung oder nicht.
Wenn du aber eine Datei mit zehntausenden von Befehlen jeweils hundertemal wiederholt vor dir hast, liest du nix mehr.
Wieso?
Er muss den Code aber auch Laden oder nicht? Mehr Code bedeutet doch auch mehr Zeit zur Ausführung oder nicht.
Nein, mehr Code bedeutet nicht automatisch mehr Ausführungsdauer, Befehle brauchen unterschiedlich lange.
Wieso?
Nimm ein Buch, und kopier jeden Satz tausende male. Versuch dann mal, es zu lesen.
Nein, mehr Code bedeutet nicht automatisch mehr Ausführungsdauer, Befehle brauchen unterschiedlich lange.
Die Befehle müssen jedoch auch erstmal gelesen und - je nach sprache - interpretiert/kompiliert werden. Man könnte aber vllt dem Kompiler sagen dss die Funktion kritisch ist und ihn die Schleife ausschreiben lassen im Endergebnis
Nimm ein Buch, und kopier jeden Satz tausende male. Versuch dann mal, es zu lesen.
Das ist doch nicht das gleiche
Doch, das ist das Gleiche. Ich soll doch den Programmcode lesen können.
Das ein schließt ja das andere nicht aus. Es kommt ja darauf an was der Compiler aus/mit der Eingabe macht.
Das sehe ich auch so, wo allerdings wäre es anders? Viele hassen scheinbar einen bestimmten Stil und sagen dann es sei unlesbar.
Warum ist alt schlecht?