🤒 👰🏽 ⏺️ Paul Graham: Kürze = Stärke 🚘 😶 🙎🏾

Bei HackerNews haben wir heute eine Diskussion über den Artikel von Paul Graham aus dem Jahr 2002 geführt und beschlossen, seine Übersetzung aus der Nichtexistenz wiederzubeleben.

"Die Menge an Bedeutung, die
durch algebraische Zeichen auf einen kleinen Raum komprimiert wird , ist ein weiterer Umstand, der
die Überlegungen erleichtert, die wir gewohnt sind, mit ihrer Hilfe fortzusetzen."
- Charles Babbage (1791-1871)

In einer Diskussion um den Artikel LL1 Revenge auf der LL1-Mailingliste brachte Paul Prescod eine Idee zum Ausdruck, die mich nicht aus den Augen lässt.

Pythons Ziel ist Regelmäßigkeit und Lesbarkeit, aber nicht Kürze.

Auf den ersten Blick sollte eine Programmiersprache wahrscheinlich nicht behaupten, es zu sein. Nach meinem Verständnis ist Kürze (Prägnanz, Prägnanz, Kompaktheit) = Stärke. Und wenn ja, dann erhalten wir eine Substitution, wir bekommen:

Pythons Ziel ist Regelmäßigkeit und Lesbarkeit, aber keine Leistung.

Dies ist wiederum kein sehr guter Kompromiss (wenn es sich wirklich um einen Kompromiss handelt), der es wert ist, gemacht zu werden. Es scheint, als ob Sie sagen: Das Ziel der Python-Sprache ist es nicht, eine effektive Programmiersprache zu sein.

Ist Kürze = Stärke? Dies scheint eine wichtige Frage zu sein, vielleicht die wichtigste für diejenigen, die an der Entwicklung von Sprachen beteiligt sind. Ich bin mir noch nicht sicher, ob die Antwort einfach "Ja" lautet, aber für den Anfang ist dies eine gute Hypothese.

Hypothese

Meine Hypothese ist, dass Kürze Macht ist oder dass sie so nahe beieinander liegen, dass man sie mit Ausnahme von pathologischen Fällen für etwas Identisches halten kann.

Kürze, so scheint es mir, ist das, wofür Programmiersprachen geschaffen wurden. Computer würden sich genauso freuen, wenn sie Anweisungen direkt in Maschinensprache erhalten würden. Ich denke, der Hauptgrund, warum wir Hochsprachen entwickeln werden, ist der Vorteil, zehn Zeilen in einer Hochsprache auszudrücken (und vor allem zu denken), was 1000 Zeilen Maschinencode erfordern würde. Mit anderen Worten, das Hauptziel von Hochsprachen ist es, den Quellcode kürzer zu machen.

Wenn der kürzere Quellcode der Zweck von Hochsprachen ist und die Stärke von etwas ein Maß dafür ist, wie gut das Ziel erreicht wird, dann ist die Stärke der Programmiersprache, wie stark sie Ihre Programme reduziert.

Umgekehrt macht eine Sprache, die Ihre Programme nicht kleiner macht, eine schlechte Arbeit in einer Programmiersprache, genau wie ein Messer, das schlecht schneidet oder unleserlich druckt.

Metriken

Und in welchem Sinne ist weniger? Das häufigste Maß für die Größe des Quellcodes ist die Anzahl der Zeilen. Aber diese Maßnahme ist nur wegen der Einfachheit der Messung üblich, und ich glaube nicht, dass irgendjemand glaubt, dass es ein guter Test für die Programmgröße ist. Sprachen haben unterschiedliche Konventionen, was in einer Zeile platziert werden kann. Einige Zeilen in C haben möglicherweise nur ein oder zwei Trennzeichen.

Ein weiterer einfacher Test ist die Anzahl der Zeichen im Programm, aber dieser ist nicht zu gut. Einige Sprachen (wie Perl) haben kürzere Bezeichner als andere.

Ich denke, das beste Maß für die Größe eines Programms kann die Anzahl der Elemente sein, wobei das Element etwas ist, das zu einem separaten Scheitelpunkt im Quellbaum werden kann. Der Name einer Variablen oder Funktion ist ein Element. eine ganze Zahl oder eine reelle Zahl ist ein Element; Ein Textliteral-Segment ist ein Element. Ein Element einer Muster- oder Formatanweisung ist ein Element. Es gibt Grenzfälle (ist "-5" ein oder zwei Elemente?), Aber ich denke, die meisten sind in allen Sprachen gleich, sodass sie den Vergleich nicht zu sehr beeinflussen.

Diese Maßnahme sollte konkretisiert werden und erfordert bei einigen bestimmten Sprachen möglicherweise eine zusätzliche Interpretation, aber es scheint mir, dass versucht wird, das Richtige zu messen: die Anzahl der Programmteile. Der Quellbaum ist das, was Sie in Ihrem Kopf zeichnen, um das Programm darzustellen, und daher ist die Größe dieses Baums proportional zum Arbeitsaufwand, der zum Schreiben oder Lesen erforderlich ist.

Design

Diese Maßnahme würde es uns ermöglichen, verschiedene Sprachen zu vergleichen, aber dies ist zumindest für mich nicht der Grundwert. Der Wert des Kürze-Tests ist ein Leitfaden für das Entwerfen von Sprachen. Der nützlichste Sprachvergleich besteht darin, zwei mögliche Variationen derselben Sprache zu vergleichen. Was kann ich in der Sprache tun, um Programme zu verkürzen?

Wenn die konzeptionelle Belastung eines Programms proportional zu seiner Komplexität ist und ein bestimmter Programmierer einer bestimmten konzeptionellen Belastung standhalten kann, entspricht dies der Frage: Wie kann er Programmierern helfen, mehr zu tun? Und das scheint mir dasselbe zu sein wie zu fragen: Wie gestaltet man eine gute Sprache?

(Übrigens wird die Falschheit dieses bereits bärtigen Sprichworts „Alle Sprachen sind gleich“ am deutlichsten beim Entwerfen von Sprachen deutlich. Wenn Sie eine neue Sprache erstellen, vergleichen Sie ständig zwei Sprachen - eine, in der ich X machen würde, und die andere, in der ich nicht machen würde - damit Entscheide, was besser ist. Wenn es eine sinnlose Frage wäre, könntest du genauso gut eine Münze werfen.)

Ein Ziel der Kürze zu haben, scheint ein guter Weg zu sein, um neue Ideen zu finden. Wenn Sie einen Weg finden, Programme zu verkürzen, ist dies kein Zufall: Sie haben wahrscheinlich eine nützliche neue Abstraktion gefunden. Sie könnten sogar ein Programm schreiben, das sich wiederholende Blöcke im Quellcode abruft. Neue Ideen finden sich in Sprachen, die den Ruf haben, prägnant zu sein: Forth, Joy, Icon.

Vergleich

Der erste, der über diese Dinge schrieb, war, soweit ich weiß, Fred Brooks mit seinem Buch Mythical Man-Month. Er schrieb, dass Programmierer unabhängig von der Sprache dieselbe Menge an Code generieren. Als ich es in meinen 20ern zum ersten Mal las, war es eine große Überraschung, und es schien mir, dass dies enorme Konsequenzen hatte. Dies bedeutete, dass (a) die einzige Möglichkeit, Programme schneller zu schreiben, darin besteht, eine kürzere Sprache zu verwenden, und (b) derjenige, der sich die Mühe gemacht hat, die Wettbewerber zu fragen, die dies nicht tun.

Brooks Vermutung, wenn sie wahr ist, kann die Essenz des Hackens sein. Seitdem habe ich im Laufe der Jahre auf alles geachtet, was für das Thema relevant wäre: von theoretischen Studien bis zu Geschichten über einzelne Projekte. Ich habe nichts gesehen, was dieser Hypothese widersprechen würde.

Aber ich habe keine klaren Beweise gesehen, und ich erwarte nicht, sie zu sehen. Studien wie der Vergleich der Programmiersprachen von Lutz Prekelt liefern zwar die erwarteten Ergebnisse, verwenden jedoch tendenziell Aufgaben, die für einen aussagekräftigen Test zu klein sind. Der beste Test für eine Sprache ist, was in Programmen passiert, die in einem Monat geschrieben wurden. Und wenn Sie wie ich davon überzeugt sind, dass der Hauptzweck von Sprachen darin besteht, eine gute Sprache zu sein, in der sie denken (und nicht eine Sprache, in der sie dem Computer Anweisungen geben, nachdem Sie darüber nachgedacht haben), dann ist der eigentliche Test für die Sprache Was Neues kannst du darauf schreiben? Daher ist der Vergleich von Sprachen, die auf einer vordefinierten Spezifikation basieren, etwas falsch.

Der eigentliche Test für die Sprache ist, wie gut Sie neue Probleme finden und lösen können, aber nicht die Aufgaben, die von jemand anderem formuliert wurden. Dies sind verschiedene Kriterien. In der Kunst funktionieren Werkzeuge wie Stickerei und Mosaik gut, wenn Sie im Voraus wissen, was Sie erhalten möchten, aber absolut unanständig, wenn Sie es nicht wissen. Wenn Sie beim Schreiben eines Bildes ein Bild anzeigen möchten (was Sie tun sollten, wenn Sie so komplexe Dinge wie beispielsweise das Bild einer Person anzeigen), sollten Sie ein flexibleres Werkzeug wie Bleistift, Tinte oder Ölfarben verwenden. Natürlich werden Wandteppiche und Mosaike einfach so hergestellt: Zuerst wird ein Bild erstellt und dann nur noch kopiert.

Dies bedeutet, dass es unwahrscheinlich ist, dass wir die relative Stärke der Programmiersprachen richtig vergleichen können. Wir werden genaue Vergleiche haben, aber keine korrekten. Insbesondere Studien, die explizit auf Sprachvergleiche abzielen, verwenden wahrscheinlich kleine Aufgaben und verwenden notwendigerweise einen vordefinierten Satz von Aufgaben. Daher werden die mächtigsten Sprachen tendenziell unterschätzt.

Berichte in diesem Bereich sind wahrscheinlich weniger aussagekräftig als „wissenschaftliche“ Studien, aber wahrscheinlich aussagekräftiger. Zum Beispiel führte Ulf Wieger von Ericsson eine Studie durch und kam zu dem Schluss, dass Erlang 4-10 mal kürzer als C ++ ist und die Geschwindigkeit der Softwareentwicklung proportional höher ist:

Ein Vergleich der internen Projekte in Ericsson zeigt eine ähnliche Produktivität in Codezeilen pro Stunde, einschließlich aller Entwicklungsphasen, unabhängig von der verwendeten Sprache (Erlang, PLEX, C, C ++ oder Java). Unterschiede in den Sprachen - nur in der Gesamtmenge des Quellcodes.

Diese Studie zeigt auch deutlich, dass sie nicht in Brooks 'Buch erscheint (da nur Zeilen mit debuggtem Code gemessen wurden): Programme, die in leistungsfähigeren Sprachen geschrieben wurden, enthalten tendenziell weniger Fehler. Dies ist bereits völlig ausreichend, und wahrscheinlich ist dies bei Aufgaben wie Netzwerk-Switches wichtiger als die Leistung des Programmierers.

Schmeckt

Am Ende können Sie Ihrem Instinkt vertrauen. Was ist Programmieren in dieser Sprache? Ich denke, um eine bessere Sprache zu schaffen, sollten Sie überempfindlich werden, wie gut die Sprache es Ihnen ermöglicht, darin zu denken, und dann eine Sprache auswählen oder entwickeln, die Ihnen am besten geeignet erscheint. Wenn eine Eigenschaft der Sprache unpraktisch oder einschränkend ist - keine Sorge, Sie werden davon erfahren.

Eine solche Überempfindlichkeit führt jedoch dazu, dass ungeschickte Sprachen für Sie unerträglich werden. Ich finde das Programmieren in Sprachen, die keine unerträglich einschränkenden Makros haben, so als würde jemand, der an dynamisches Tippen gewöhnt ist, die Rückkehr zu Sprachen als unerträglich einschränkend betrachten, wobei Typen für jede deklarierte Variable beschrieben werden sollten und es unmöglich ist, eine Liste mit Elementen zu deklarieren verschiedene Typen.

Und ich bin nicht allein. Ich kenne viele Lisp-Hacker, mit denen etwas Ähnliches passiert ist. Tatsächlich könnte das genaueste Maß für die relative Stärke einer Programmiersprache der Anteil der Programmierer sein, die eine bestimmte Sprache kennen und unabhängig vom Fachgebiet Arbeiten ausführen, in denen diese Sprache verwendet werden sollte.

Einschränkungen

Wahrscheinlich wissen viele Hacker, wie es sich anfühlt, wenn die Sprache restriktiv erscheint. Dies ist wahrscheinlich das gleiche Gefühl wie wenn Sie auf der Straße, auf der Sie fahren möchten, im Stau stecken bleiben und einen langen Umweg machen müssen. Sie möchten etwas sagen und die Sprache erlaubt Ihnen dies nicht.

Tatsächlich ist eine einschränkende Sprache keine prägnante Sprache. Das Problem ist nicht, dass Sie etwas nicht ausdrücken können, sondern dass der Umweg, zu dem diese Sprache Sie zwingt, zu lang ist. Machen Sie dieses Gedankenexperiment: Sie möchten eine Art Programm schreiben, und die Sprache erlaubt es Ihnen nicht, es so zu machen, wie Sie es geplant haben, sondern macht es kürzer. Zumindest für mich wäre das nicht zu restriktiv. Als würde ein Polizist Sie von einem Stau auf eine kürzere Straße anstatt auf einen langen Umweg leiten. Beeindruckend!

Es scheint mir, dass das Gefühl der Begrenztheit im Grunde (um 90 Prozent?) Darauf zurückzuführen ist, dass Sie gezwungen sind, das Programm in der Sprache, in der Sie schreiben, länger zu machen als in der Sprache, in der Sie denken. Begrenztheit ist im Grunde eine unzureichende Kürze. Wenn eine Sprache also einschränkend zu sein scheint, bedeutet dies, dass sie nicht kurz genug ist.

Lesbarkeit

Das Zitat, mit dem ich begonnen habe, erwähnt auch zwei andere Eigenschaften: Regelmäßigkeit und Lesbarkeit. Ich verstehe nicht wirklich, was Regelmäßigkeit ist und welche Vorteile regulärer und lesbarer Code im Vergleich zu nur lesbarem Code bietet. Aber ich glaube zu wissen, was unter Lesbarkeit zu verstehen ist, und es scheint mir auch, dass dies mit Kürze zu tun hat.

Hier müssen wir mit den Konzepten der Lesbarkeit einer einzelnen Codezeile und der Lesbarkeit des gesamten Programms vorsichtig sein. Nur das Letzte ist wichtig. Ich bin damit einverstanden, dass eine Zeile in BASIC höchstwahrscheinlich besser lesbar ist als eine Zeile in Lisp, aber ein in BASIC geschriebenes Programm enthält mehr Zeilen als dasselbe in Lisp geschriebene Programm. Das Lesen des BASIC-Programms erfordert mehr Aufwand.

Gesamtaufwand = Aufwand zum Lesen einer Zeile * Anzahl der Zeilen

Ich bin mir nicht so sicher, ob die Lesbarkeit proportional zur Kürze ist, aber definitiv ist die Kürze ein Faktor für die Lesbarkeit (siehe die obige Formel). Es macht also kaum Sinn zu sagen, dass der Zweck der Sprache die Lesbarkeit ist, aber nicht die Kürze.

Für einen Benutzer, der eine bestimmte Sprache zum ersten Mal sieht, bedeutet die zeilenweise Lesbarkeit, dass diese Sprache für ihn harmlos erscheint. Daher kann die zeilenweise Lesbarkeit eine gute Marketingentscheidung sein, obwohl es sich um eine schlechte Entwurfsentscheidung handelt. Es ist isomorph in Bezug auf die Zahlungsweise in Raten: Anstatt sich von einer großen Anzahlung einschüchtern zu lassen, bieten Sie dem Käufer eine kleine monatliche Zahlung an. Die Zahlung in Teilen ist für ihn letztendlich unrentabel, ebenso wie die zeilenweise Lesbarkeit - für den Programmierer. Der Käufer muss viele kleine Zahlungen leisten, genauso wie der Programmierer viele lesbare Zeilen separat lesen muss.

Dieses Verhältnis bestand bereits vor dem Aufkommen der Programmiersprachen. Wenn Sie Romane und Zeitungsartikel lesen, kann Ihre erste Erfahrung beim Lesen eines Artikels in Mathematik beängstigend sein: Das Lesen einer Seite dauert eine halbe Stunde. Trotzdem bin ich mir sicher, dass das Problem nicht in der Notation liegt, wie es auf den ersten Blick scheinen mag. Ein Artikel in Mathematik ist schwer zu lesen, da die Ideen selbst komplex sind. Wenn Sie dieselben Ideen in Prosa ausdrücken (wie es Mathematiker getan haben, bevor sie an eine kurze Notation gedacht haben), wäre das Lesen nicht einfacher, da diese einzelne Seite zu einem ganzen Buch werden würde.

In welchem Maße?

Einige waren mit der Idee der Kürze = Stärke nicht einverstanden. Ich denke, anstatt zu streiten, ob dies so ist, wäre es sinnvoller zu fragen, inwieweit Kürze Macht ist. Weil es klar ist, dass Kürze eines der Hauptziele von Programmiersprachen ist. Und wenn nicht, was ist ihr Zweck und wie wichtig sind diese anderen Funktionen?

Ich schlage dies vor, um die Diskussion nicht ziviler zu gestalten. Ich möchte wirklich die Antwort wissen. Wann, wenn überhaupt, wird die Sprache prägnant genug?

Die Hypothese, mit der ich begann, war, dass bis auf einige pathologische Fälle die Kürze mit der Stärke identisch ist. Ich meinte, dass sie in jeder von jemandem entwickelten Sprache identisch sein werden, aber wenn jemand eine Sprache speziell erstellen möchte, um diese Hypothese zu widerlegen, wird es wahrscheinlich funktionieren. Aber da bin ich mir auch nicht sicher.

Sprachen, aber keine Programme

Es sollte klargestellt werden, dass es sich um die Kürze der Sprachen handelt, nicht um einzelne Programme. Natürlich können einige Programme sehr eng geschrieben werden.

Ich habe darüber in dem Buch „About Lisp“ geschrieben. Damit sich das Makro rechtfertigen kann, muss es im Verhältnis zu seiner eigenen Länge um ein Vielfaches mehr Platz sparen. Wenn ein umfangreiches Makro bei jeder Verwendung zehn Codezeilen speichert und das Makro selbst aus zehn Zeilen besteht, sparen Sie Zeilen, wenn Sie es mehr als zweimal verwenden. Dies ist jedoch immer noch ein schlechter Schritt, da Makrodefinitionen schwieriger zu lesen sind als normaler Code. Möglicherweise müssen Sie das Makro 10 oder 20 Mal verwenden, bevor sich die Lesbarkeit verbessert.

Ich bin sicher, dass in jeder Sprache solche Kompromisse möglich sind (obwohl ich vermute, dass der Einsatz in starken Sprachen erhöht wird). Jeder Programmierer hat jemals Code gesehen, der aufgrund zweifelhafter Programmiertechniken extrem verkürzt ist.

Daher ist es - zumindest für mich - unbestreitbar, dass Programme präzise genug sein können. Die Frage ist, können die Sprachen selbst kurz sein? Können Sprachen Programmierer zwingen, auf Kosten der Lesbarkeit kurz (in Elementen) zu schreiben?

Ein Grund, warum man sich eine zu prägnante Sprache kaum vorstellen kann, ist, dass es wahrscheinlich einen längeren Weg geben wird, wenn es eine zu kompakte Art gibt, etwas auszudrücken. Wenn Ihnen beispielsweise die Verwendung von Makros oder Funktionen auf hoher Ebene in Lisp zu dicht erscheint, können Sie Code schreiben, der für Pascal isomorph ist. Wenn Sie die Fakultät in der Sprache von Arc nicht als Aufruf einer übergeordneten Funktion ausdrücken möchten,

(rec zero 1 * 1-)

können Sie auch eine rekursive Definition schreiben:

(rfn fact (x) (if (zero x) 1 (* x (fact (1- x)))))

Obwohl ich nicht sofort Beispiele nennen kann, interessiert mich die Frage: Kann die Sprache zu kurz sein? Gibt es Sprachen, die Sie zwingen, unleserlichen Code zu schreiben? Wenn jemand Beispiele hat, würde ich mich freuen, sie zu sehen.

(Denken Sie daran: Ich interessiere mich für Programme mit einer hohen Dichte gemäß dem oben beschriebenen Maß an "Elementen", aber nicht für Programme, die kurz sind, nur weil Trennzeichen weggelassen werden können und alles Namen hat, die ein Zeichen lang sind.)

Es wurde zuerst hier veröffentlicht .

Erfahren Sie in SkillFactory-Onlinekursen, wie Sie einen begehrten Beruf von Grund auf neu erlernen oder Ihre Fähigkeiten und Ihr Gehalt verbessern können:

Paul Graham: Kürze = Stärke