Blau Nein! Gelb! - oder - Erhöhen neue Programmiersprachen die Entwicklungsgeschwindigkeit?

Ursprünglicher Autor: Robert C. Martin (Onkel Bob)
  • Übersetzung
In welcher Sprache wurden die allerersten Programme für die allerersten Computer mit einem gespeicherten Programm geschrieben?

Natürlich binäre Maschinensprache.

Warum?

Offensichtlich, weil es keinen Character Assembler gab. Die ersten Programme mussten in Binärcode geschrieben werden.

Wie viel einfacher ist es, Programme in Assembler als in binärer Maschinensprache zu schreiben?

Viel einfacher.

Kann ich eine Nummer haben? Wie oft einfacher?

Verdammt, Assembler erledigt die schwierigste Routinearbeit für Sie. Das heißt Es berechnet alle physikalischen Adressen. Er stellt alle Anweisungen für die physische Maschine zusammen. Es stellt sicher, dass physikalisch nicht realisierbare Befehle nicht ausgegeben werden können, beispielsweise Adressen außerhalb des Adressraums. Und dann wird eine leicht herunterladbare Binärausgabe erstellt.

Das Einsparen von Arbeitslasten ist enorm .

Wie viel Kann ich eine Nummer haben?

OK Wenn ich ein einfaches Programm wie das Drucken der Quadrate der ersten 25 Ganzzahlen in Assembler auf einem alten Computer wie PDP-8 schreiben würde, würde ich ungefähr zwei Stunden brauchen. Wenn ich dasselbe Programm in binärer Maschinensprache schreiben würde, würde dies doppelt so viel Zeit in Anspruch nehmen.

Ich sage doppelt , weil ich das Programm zuerst in symbolischer Syntax auf Papier schreiben und dann die Maschinensprache manuell auf Papier zusammenstellen würde. Danach müsste ich diesen Binärcode auch manuell in den Computer eingeben. Und all diese zusätzliche Arbeit hat mich ungefähr genauso viel Zeit gekostet wie das Schreiben eines Programms im ersten Fall. Vielleicht mehr.

Gut genug So reduziert die Verwendung von Zeichen Assembler den Arbeitsaufwand um die Hälfte?

Tatsächlich denke ich viel mehr. Das Quadrieren von ganzen Zahlen ist ein ziemlich einfaches Programm. Je größer das Programm ist, desto schwieriger ist es, es manuell zusammenzustellen und zu laden. Ich glaube tatsächlich, dass der Gewinn an Mühe von der Größe des Programms abhängt. Bei großen Programmen ist die Zeitersparnis erheblich .

Bitte erklären Sie.

Angenommen, Sie müssen eine Zeile in einem Programm in Character Assembler ändern. Auf einem alten PDP-8 mit Lochstreifen brauche ich 20 Minuten. Aber bei der manuellen Montage muss ich dann alle Adressen neu aufzählen und alle Maschinenanweisungen manuell wieder zusammenbauen. Abhängig von der Größe des ursprünglichen Programms werden Stunden vergehen. Die anschließende manuelle Eingabe erfordert nicht weniger Zeit.

Ich könnte Zeit sparen, indem ich das Programm in Module aufteile, die auf feste Adressen geladen sind und zwischen denen ein freier Abstand besteht. Sie können etwas mehr Zeit sparen, indem Sie ein kleines Programm schreiben, mit dem Sie ein großes Programm herunterladen können. Eine solche "Routine" -Last wird jedoch sehr, sehr hoch sein.

Gut Aber kann es trotzdem eine Figur sein? Wie viel einfacher ist die Assemblierung im Durchschnitt, als ein Programm in Binärform zu schreiben?

Ok Ich nehme an, wir können ungefähr 10 mal sagen.

Mit anderen Worten: Mit dem Zeichenassembler kann ein Programmierer die Arbeit von zehn Programmierern erledigen, die im Binärcode arbeiten.

Ja, das ist wahrscheinlich der Wahrheit nahe.

Wenn der Symbol-Assembler den Arbeitsaufwand um das Zehnfache reduziert hat, wie viel hat Fortran dann getan?

Sehr anständig. Wenn wir über die 50er sprechen, dann war Fortran damals einfach. Mit anderen Worten, es war etwas größer als der Zeichenassembler für das Zeichenlayout - ich bin mir nicht sicher, ob Sie verstehen, was ich meine.

Bedeutet das, dass er die Komplexität um das Zehnfache reduziert hat?

Was bist du natürlich nicht! Die "Routinelast" des symbolischen Assemblers war nicht so hoch. Ich würde sagen, dass Fortran die Komplexität relativ wenig reduziert hat. Möglicherweise ungefähr 30%.

Mit anderen Worten, 10 Fortran-Programmierer können 13 Assembler-Programmierer ersetzen.

Wenn Sie den Prozess aus dieser Perspektive betrachten wollen, dann scheint es so.

Wir machen weiter - wie hilft eine Sprache wie C, im Vergleich zu Fortran Zeit zu sparen?

Nun, C verbringt etwas weniger Zeit mit „Routinearbeit“ als Fortran. Im alten Fortran musste man sich Dinge wie Zeilennummern und die Reihenfolge der gemeinsamen Operatoren merken. Es gab auch unglaublich viele Sprungoperatoren im gesamten Text. Die Programmiersprache C ist wesentlich komfortabler als Fortran 1. Ich würde sagen, dass sie die Komplexität um etwa 20% reduziert hat.

Gut Das heißt, 10 C-Programmierer können 12 Fortran-Programmierer ersetzen.

Nun, das ist natürlich nur eine Annahme, aber ich würde eine vernünftige Annahme sagen.

Gut Nun: Um wie viel hat C ++ die Komplexität in Bezug auf C reduziert?

Hör zu, lass uns aufhören. Wir erinnern uns jetzt nicht an viel mehr Auswirkungen.

Wirklich? Was genau?

Entwicklungsumgebung. Dies bedeutet, dass wir in den 50er Jahren Lochkarten und Papierbänder verwendeten. Das Kompilieren eines einfachen Programms dauerte mindestens eine halbe Stunde. Und dann, wenn Sie auf das Auto zugreifen könnten. In den späten 80ern, als C ++ populär wurde, speicherten Programmierer ihre Programme auf Datenträgern, und das Kompilieren eines einfachen Programms dauerte nur zwei bis drei Minuten.

Ist es eine Verringerung der Arbeitsintensität? Oder nur eine Verringerung der Latenz?

A. Also hier ist es. Die Frage ist klar. Ja, dann musste das Auto lange warten.

Anfrage: Wenn Sie Ihre geschätzten Arbeitseinsätze angeben, schließen Sie bitte die Wartezeit aus. Ich bin daran interessiert, Zeit zu sparen, die nur mit der Sprache selbst verbunden ist.

Ich verstehe. Sie haben also nach C ++ gefragt. Ehrlich gesagt glaube ich nicht, dass C ++ die Komplexität auf irgendeine Weise erheblich verringert hat. Natürlich gab es etwas , aber ich glaube, nicht mehr als 5%. Dies bedeutet, dass die Routinebelastung in C einfach gering war und daher die Zeitersparnis beim Arbeiten in C ++ nicht signifikant sein konnte.

Wenn Sie 5% verwenden, können 100 C ++ - Programmierer 105 C-Programmierer ersetzen.

Im Allgemeinen ja. Aber nur für kleine und mittlere Programme. Für große Programme bietet C ++ einige zusätzliche Vorteile.

Welche?

Das ist ziemlich schwer zu erklären. Das Fazit ist jedoch, dass die objektorientierten Eigenschaften von C ++, insbesondere der Polymorphismus, es ermöglichten, große Programme in unabhängig entwickelte und eingesetzte Module zu unterteilen. Und das reduziert - bei sehr großen Programmen - die Routinebelastung erheblich.

Kann ich eine Nummer haben?

Nun, Sie scheinen meine Hände weiter zu drehen ... Angesichts der Anzahl der wirklich großen Programme, die in den 80er und 90er Jahren erstellt wurden, werde ich sagen, dass C ++ den Arbeitsaufwand im Allgemeinen um möglicherweise 7% reduziert hat.

Das klang nicht besonders zuversichtlich.

Ja Aber verwenden wir diesen Wert. 7%.

Gut 100 C ++ - Programmierer können also 107 C-Programmierer ersetzen?

Es scheint, als hätte ich es gesagt. Verwenden wir diesen Wert.

Wie viel Zeit spart Java im Vergleich zu C ++?

Schwer zu sagen. Spart etwas Zeit. Java ist eine einfachere Sprache. Es verfügt über eine automatische dynamische Speicherfreigabesteuerung ("Garbage Collection"). Es gibt keine Header-Dateien. Es funktioniert in einer virtuellen Maschine. Er hat viele Tugenden. Und ein paar Mängel.

Was ist mit den Zahlen?

Ich habe das Gefühl, dass wir ins Schleudern geraten ... Aber da Sie mich so unter Druck setzen, würden Sie sagen, dass Sie bei der Arbeit mit Java (was nie passiert) eine Reduzierung der Arbeitskosten um 5% im Vergleich zu C ++ erzielen können.

100 Java-Programmierer können also 105 C ++ - Programmierer ersetzen?

Ja Nein. Es ist nicht so. Der Spread ist zu groß. Wenn wir zufällig 100 Java-Programmierer auswählen und sie mit den ebenfalls ausgewählten 105 C ++ - Programmierern vergleichen, würde ich es nicht wagen, das Ergebnis vorherzusagen. Um einen echten Gewinn zu erzielen, brauchen Sie viel mehr Programmierer.

Wie viel mehr

Mindestens zwei Größenordnungen.

Mit anderen Worten, 10.000 zufällig ausgewählte Java-Programmierer können 10.500 ähnlich ausgewählte C ++ - Programmierer ersetzen.

Vielleicht auch.

Sehr gut. Um wie viel reduziert eine Sprache wie Ruby die Komplexität im Vergleich zu Java?

Nun, mein Lieber! seufzt Worüber reden Sie? Schau, Ruby ist wirklich eine schöne Sprache. Es ist sowohl einfach als auch komplex, elegant und bizarr. Es ist viel langsamer als Java, aber Computer sind jetzt so billig, dass ...

Entschuldigung, aber ich frage nicht danach.

Sie haben Recht. Ich weiß. Die Hauptrichtung, in der die Komplexität von Ruby im Vergleich zu einer Sprache wie Java geringer ist, ist Types . In Java müssen Sie eine formale Typstruktur erstellen und deren Konsistenz beibehalten. Ruby kann ziemlich schnell und frei mit Typen gespielt werden.

Es klingt nach einer Steigerung der Arbeitsproduktivität.

Im Allgemeinen nicht. Es stellt sich heraus, dass die Fähigkeit, schnell und frei mit einer Typstruktur zu spielen, zum Auftreten einer Klasse von Laufzeitfehlern führt, die beim Programmieren in Java nicht verfügbar sind. Daher haben Ruby-Programmierer eine höhere Belastung beim Testen und Debuggen von Programmen.

Mit anderen Worten, sind diese Effekte ausgeglichen?

Es hängt davon ab, wen Sie fragen.

Ich frage dich.

Ok Ich würde sagen, dass sich die Effekte nicht ausgleichen. Die Komplexität der Arbeit mit Ruby ist geringer als mit Java.

Wie viel 20%?

Die Leute dachten so. In den 90er Jahren dachten viele, dass Smalltalk-Programmierer um ein Vielfaches produktiver arbeiteten als C ++.

Du verwirrst mich. Warum erinnere ich mich an diese Sprachen?

Ja, weil C ++ Java ziemlich nahe kommt und Smalltalk Ruby.

Ich verstehe Damit reduziert Ruby die Komplexität um ein Mehrfaches gegenüber Java?

Nein, höchstwahrscheinlich nicht. Wenn Sie auf die 90er Jahre zurückblicken, dann war das Problem mit der Wartezeit noch recht ausgeprägt. Die Kompilierungszeit für ein typisches C ++ - Programm betrug mehrere Minuten. Die Kompilierungszeit für das Smalltalk-Programm war praktisch Null .

Null?

Praktisch ja Das Problem ist, dass Sie bei der Verwendung von Sprachen wie Java und C ++ viele Aktionen ausführen müssen, um alle Typen zu koordinieren. Bei der Verwendung von Smaltalk und Ruby gibt es kein solches Problem. Daher benötigten sie in den 90er Jahren Zeit von Minuten bis Millisekunden.

Ich verstehe Aber da dies alles nur eine Wartezeit ist, können wir es nicht berücksichtigen.

Nicht wirklich so. Sie sehen, wenn die Kompilierungszeit fast Null ist , dann führt dies zu einem anderen Programmierstil und einer anderen Disziplin. Sie können mit einem sehr kurzen Zyklus arbeiten - Sekunden statt Minuten. Dies gibt extrem schnelles Feedback. Bei langen Übersetzungszeiten ist eine schnelle Rückmeldung nicht möglich.

Reduziert schnelles Feedback die Arbeitskosten?

Ja, bis zu einem gewissen Grad. Wenn Ihre Zyklen extrem kurz sind, ist die „Routinelast“ in jedem Zyklus sehr gering. Ihre durch die Notwendigkeit der Nachverfolgung verursachte Geschäftigkeit nimmt ab. Das Verlängern von Zyklen erhöht die "Routine" -Last und nichtlinear.

Nichtlinear?

Ja, die „Routinelast“ wächst überproportional zur Zykluszeit. Es kann zum Beispiel als O (N ^ 2) wachsen. Ich weiß nicht. Aber ich bin mir ziemlich sicher, dass die Abhängigkeit nichtlinear ist.

Großartig! Ruby ist also der Anführer!

Nein. Und genau darum geht es. Dank der Verbesserung unserer Hardware in den letzten zwanzig Jahren ist die Kompilierungszeit für Java nahezu Null geworden . Die Zykluszeit des Java-Programmierers ist nicht länger (oder sollte nicht länger sein) als die eines Ruby-Programmierers.

Bitte klären Sie.

Ich sage, dass Programmierer, die die Disziplin des kurzen Zyklus verwenden, nur einen geringen Unterschied im Arbeitseinsatz bemerken (oder im Allgemeinen nicht bemerken werden), wenn sie mit Java und Ruby arbeiten. Der Unterschied wird so gering sein, dass es schwierig sein wird, ihn zu messen.

Ein unermesslicher Unterschied?

Meiner Meinung nach müssen Experimente mit Tausenden von Programmierern durchgeführt werden, um ein statistisch zuverlässiges Ergebnis für diesen Unterschied zu erhalten.

Aber Sie haben bereits gesagt, dass Ruby die Komplexität im Vergleich zu Java reduziert.

Ich denke schon, aber nur, wenn die Zykluszeit lang ist. Wenn der Bearbeitungs- / Kompilierungs- / Testzyklus sehr kurz gehalten wird, ist der Effekt vernachlässigbar.

Null?

Natürlich nicht wahrscheinlicher etwa 5%. Aber die Streuung wird gigantisch sein.

Also arbeiten 10.500 Java-Kurzzyklus-Programmierer genauso wie 10.000 Ruby-Kurzzyklus-Programmierer?

Wenn Sie einen weiteren Auftrag für die Stichprobengröße hinzufügen, würde ich mich getraut haben, dem zuzustimmen.

Gibt es Sprachen, die Ruby überlegen sind?

Mit einer Sprache wie Clojure können Sie weitere 5% erzielen, da sie einerseits recht einfach und andererseits funktional ist.

Geben Sie einer funktionalen Sprache nur 5%?

Nein, ich sage, dass Disziplin im kurzen Zyklus Leistungsunterschiede in modernen Sprachen praktisch ausgleichen kann.

Wenn Sie mit kurzen Schleifen arbeiten, spielt es kaum eine Rolle, welche moderne Sprache Sie verwenden.

Das heißt: Swift? Dart? Gehen?

Spielt keine Rolle.

Scala? F #?

Spielt keine Rolle.

Mit anderen Worten, wir haben die Spitze erreicht. Keine zukünftige Sprache wird besser sein als das, was wir jetzt haben.

Nicht wirklich so. Ich sage nur, dass wir uns auf dem Weg einer sinkenden Effizienz befinden. Keine der zukünftigen Sprachen wird einen 10-fachen Gewinn bringen, wie dies beim Assembler in Bezug auf den Binärcode der Fall war. Keine zukünftige Sprache wird die Arbeitsintensität um 50%, 20% oder sogar 10% im Vergleich zu bestehenden Sprachen reduzieren. Die Disziplin des kurzen Zyklus hat die Unterschiede zur praktischen Unermesslichkeit verringert.

Warum erscheinen dann alle neuen Sprachen?

Dies ist die Suche nach dem Heiligen Gral .

Ah, also ist es nur eine Frage des Niveaus Ihrer Lieblingsfarbe.



Anmerkung des Übersetzers: Titel des Fastens und sein Thema ist ein Verweis auf ein Fragment des Films „Monty Pythons und den Heiligen Grals“, in dem der Ritter der Tafelrunde trifft auf fünf drei Fragen , die die Brücke des Todes zu überqueren

Jetzt auch beliebt: