Go-Design-Philosophie: Weniger ist mehr, woher kommt das?

Als ich zuvor Wissen und Erfahrungen in der Go-Community geteilt habe, hörte ich oft umgangssprachliche Wörter wie: weniger ist mehr, weniger ist mehr, der Weg zur Einfachheit, der Weg zur Einfachheit usw.

Sogar bei der Diskussion von Go-Themen und -Vorschlägen verwenden manche Leute „weniger ist mehr“, um Argumente zu widerlegen oder zu untermauern, was sehr interessant ist. Jeder wird sehr neugierig sein, woher kommt es und was bedeutet es?

Quelle des goldenen Satzes

So ein tief verwurzeltes Gemeinschaftskulturkonzept muss von einer Kernperson vorgeschlagen worden sein. Er ist der Autor, der diesen Satz gesagt hat:

Erkennt ihn jemand?

Er ist Rob Pike, der Vater der Go-Sprache.

Rob Pike hat mehrfach etwas in der Art von „Weniger ist mehr“ gesagt, und es ist weit verbreitet.

Teilen Sie bei Gelegenheiten wie:

• Im Jahr 2012 wurde auf der Go SF-Konferenz geteilt, was der erste Artikel war, der aus öffentlichen Meinungen zusammengestellt wurde . Im Jahr 2015 wurde auf der dotGo-Konferenz „
  Einfachheit ist kompliziert
• [2]
  “ geteilt, was weiterhin Kultur und Meinungsaustausch förderte. Verschiedene Variationen dieser Sichtweise sind in der Branche weit verbreitet und bilden eine einzigartige „Kultur“ der Go-Community.
Natürlich gibt es, der Resonanz aus der Community nach zu urteilen, sowohl Lob als auch Kritik.

Sprachinhalt

Hier ist ein Zitat aus Rob Pikes „Weniger ist exponentiell mehr

[3]

“, der Textteil@MIKESPOOK^[4] Übersetzung, ich werde neu anordnen, zuschneiden, zitieren , Mit Bildern werde ich das Rad nicht neu erfinden und es deutlich machen. Wie unten gezeigt:

Hintergrund

Dies ist der Inhalt meines (Rob Pike) Vortrags auf der Go-Konferenz in San Francisco im Juni 2012.

Dies ist eine private Rede. Ich spreche nicht im Namen von jemandem aus dem Go-Projektteam, möchte aber zunächst dem Team für alles danken, was es getan hat, um Go möglich zu machen.

Gleichzeitig möchte ich mich auch bei der San Francisco Go-Community dafür bedanken, dass sie mir diese Gelegenheit zum Reden gegeben hat.

Was mich an Go am meisten überrascht

Vor ein paar Wochen wurde ich gefragt: „Was hat Sie seit dem Start von Go am meisten überrascht?“

Ich hatte sofort eine Antwort: Ich hoffe zwar, dass C++-Programmierer Go verstehen werden als alternative Sprache, aber mehr Go-Programmierer kommen von Python und Ruby und nur wenige von C++.

Wir (Ken, Robert und ich) waren früher selbst C++-Programmierer und haben neue Sprachen entworfen, um Probleme in der von uns geschriebenen Software zu lösen.

Andere C++-Programmierer scheinen sich nicht besonders um diese Probleme zu kümmern, was ein wenig widersprüchlich erscheint.

Warum wir Go entwickelt haben

Heute möchte ich darüber sprechen, was uns dazu veranlasst hat, Go zu entwickeln, und warum wir überrascht waren, als es nicht hätte sein sollen.

Ich verspreche, Go mehr als C++ zu besprechen, und Sie können dem Thema auch dann vollständig folgen, wenn Sie C++ nicht kennen.

Die Antwort lässt sich wie folgt zusammenfassen: Glauben Sie, dass weniger mehr ist oder weniger weniger ist?

Die Bell Labs Story

Hier ist eine wahre Geschichte als Metapher. Wie folgt:

1. Bell Labs wurde ursprünglich durch drei Nummern identifiziert: 111 für physikalische Forschung, 127 für Informatikforschung und so weiter.
2. In den frühen 1980er-Jahren traf pünktlich ein Memo ein, in dem es hieß, dass aufgrund der wachsenden Forschung, wie wir sie kannten, eine weitere Ziffer hinzugefügt werden müsse, um unsere Arbeit leicht identifizieren zu können. Unser Zentrum wird also 1127.
3. Ron Hardin sagte scherzhaft und halb im Ernst, wenn wir die Welt wirklich besser verstehen würden, könnten wir sie um eine Ziffer reduzieren und aus 127 nur 27 machen.

Natürlich hat das Management den Witz nicht gehört, oder vielleicht wollte sie ihn nicht hören, aber ich denke, dass darin eine große Weisheit steckt. Weniger ist mehr. Je besser man es versteht, desto impliziter ist es.

Bitte denken Sie an diese Idee.

Hintergrund zur Entwicklung von Go

C++-Kompilierung wartet

Im September 2007 habe ich einige triviale, aber wichtige Arbeiten an der Kernarbeit eines riesigen Google C++-Programms (das, das Sie alle verwendet haben) erledigt.

Die Kompilierung auf diesem riesigen verteilten Cluster dauerte etwa 45 Minuten.

C++ neue Funktionsverbesserungen

Ich habe eine Benachrichtigung erhalten, dass mehrere bei Google beschäftigte Mitarbeiter des C++-Standardisierungsausschusses einen Bericht vorlegen werden.

Sie werden uns sagen, welche Verbesserungen es in dem gab, was damals C++0x hieß (heute bekannt als C++11).

Während der einstündigen Präsentation hörten wir Dinge, als seien bereits 35 Features geplant.

Eigentlich gibt es noch mehr, aber im Bericht werden nur 35 Features beschrieben. Natürlich sind einige Funktionen klein, aber wichtig genug, um im Bericht erwähnt zu werden.

Es gibt auch einige sehr subtile und schwer zu verstehende Informationen, wie zum Beispiel:

• Wertreferenzen.
• variable Vorlagen
• Zu diesem Zeitpunkt habe ich mir eine Frage gestellt:
  Das C++-Komitee ist wirklich der Meinung, dass das Problem mit C++ darin besteht, dass es nicht genügend Funktionen gibt
?

Definitiv, in einem weiteren Witz von Ron Hardin, die Vereinfachung der Sprache bringt mehr als das Hinzufügen von Funktionen Natürlich ist das ein bisschen lächerlich, aber behalte diese Idee im Hinterkopf

Sexuelles Sprachexperiment

Nur ein paar Monate vorher In diesem C++-Vortrag habe ich selbst einen Vortrag über eine Spielzeug-Parallelitätssprache gehalten, die ich in den 1980er Jahren entwickelt habe, und sie ist der Vorgänger von Go Einige Ideen, die in Newsqueak fehlten und über die ich noch einmal nachgedacht habe, als ich bei Google gearbeitet habe, werden einfacher, sodass Google davon profitieren kann Tatsächlich habe ich versucht, diese Ideen in C++ umzusetzen, bin aber gescheitert

Es war zu schwierig, C++-Kontrollstrukturen mit gleichzeitigen Operationen zu verbinden. Am Ende war es schwer, die wirklichen Vorteile zu erkennen

Obwohl ich zugeben muss, dass ich nie wirklich gut im Umgang mit C++ war, sah reines C++ trotzdem alles zu klobig aus

Aber dieser C++0x-Bericht hat mich noch einmal zum Nachdenken gebracht. Eine Sache, die mich wirklich stört (und sicherlich auch Ken und Robert), ist, dass das neue C++-Speichermodell über atomare Typen verfügt.

Es scheint ein absoluter Fehler zu sein, eine solch mikroskopische Sammlung beschreibender Details zu einem bereits überlasteten Typensystem hinzuzufügen. Auch das ist kurzsichtig. Es ist fast sicher, dass sich die Hardware in den nächsten zehn Jahren rasant weiterentwickeln wird. Es ist sehr dumm, die Sprache zu eng mit der heutigen Hardware zu verknüpfen.

Go Initial Team

Nach der Präsentation kehrten wir ins Büro zurück. Ich begann mit einer weiteren Zusammenstellung, drehte meinen Stuhl zu Robert und begann, die wichtigsten Themen zu kommunizieren.

Bevor die Zusammenstellung endete, hatten wir Ken hinzugezogen und entschieden, was zu tun war.

Wir werden nicht weiter C++ schreiben und wir – insbesondere ich – möchten beim Schreiben von Google-Code problemlos Parallelität schreiben können.

Gleichzeitig wollen wir auch bei der Kontrolle der „großen Programmierung“ vorankommen, worüber wir später sprechen werden.

Gehen Sie zur Feature-Diskussion

Wir haben eine Reihe von Dingen, die wir wollten, und ihre notwendigen Bedingungen auf das Whiteboard geschrieben. Syntaktische und semantische Details werden ignoriert und die Blaupause und das Gesamtbild im Auge behalten.

Ich habe noch immer eine faszinierende E-Mail aus dieser Zeit.

Hier ist ein Auszug:

• Robert: Der Ausgangspunkt ist C, einige offensichtliche Fehler beheben, Unordnung beseitigen und einige fehlende Funktionen hinzufügen.

• Rob: mit dem Namen „go“. Den Ursprung des Namens kann man sich ausdenken, er hat aber eine gute Grundlage. Es ist kurz und leicht zu buchstabieren. Werkzeuge: Goc, Gol, Goa. Wenn Sie einen interaktiven Debugger/Interpreter haben, nennen Sie ihn einfach „go“. Die Erweiterung ist .go.

• Robert: Die leere Schnittstelle ist interface{}. Sie implementieren alle Schnittstellen, sodass dies anstelle von void * verwendet werden kann.

Wir haben nicht alles richtig dargestellt. Beispielsweise dauerte die Zuordnung von Arrays und Slices fast ein Jahr. Aber die meisten wichtigen Merkmale der Sprache wurden in den ersten Tagen festgelegt.

Beachten Sie, dass Robert sagte, C sei der Ausgangspunkt, nicht C++. Ich bin mir nicht sicher, aber ich glaube, er meint C, besonders wenn Ken in der Nähe ist.

Tatsache ist aber, dass wir am Ende nicht bei C angefangen haben. Wir haben bei Null angefangen und uns nur Operatoren, Klammern, geschweifte Klammern und einige Schlüsselwörter ausgeliehen. (Natürlich nehmen wir auch das Beste aus anderen Sprachen, die wir kennen.)

Wie auch immer, wir machen jetzt das Gegenteil von C++, dekonstruieren alles, kehren zum Anfang zurück und fangen von vorne an. Wir versuchen nicht, ein besseres C++ oder sogar ein besseres C zu entwerfen. Einfach eine bessere Sprache für die Art von Software, die uns am Herzen liegt.

Irgendwann wurde daraus eine völlig andere Sprache als C und C++. Jede Veröffentlichung wird immer unterschiedlicher.

Go-Funktionsliste

Ich habe eine Liste wichtiger Vereinfachungen für C und C++ in Go erstellt:

• Kanonische Syntax (keine Symboltabelle zum Parsen erforderlich).
• Müllabfuhr (nur).
• Keine Header-Datei.
• Explizite Abhängigkeiten
• Keine zyklischen Abhängigkeiten.
• Konstanten können nur Zahlen sein.
• int und int32 sind unterschiedliche Typen.
• Sichtbarkeit der Einstellung der Groß-/Kleinschreibung.
• Jeder Typ kann Methoden haben (keine Klassen).
• Keine Untertypvererbung (keine Unterklassenbildung).
• Initialisierung auf Paketebene und definierte Initialisierungssequenz.
• Dateien zu einem Paket zusammengestellt.
• Globale Ausdrücke auf Paketebene sind reihenfolgeunabhängig.
• Keine arithmetische Konvertierung (Konstanten werden hilfsweise verarbeitet).
• Implizite Schnittstellenimplementierung (keine Definition „implementiert“ erforderlich).
• Eingebettet (kein Upgrade auf die übergeordnete Klasse).
• Methoden werden wie Funktionen definiert (keine besonderen Standortanforderungen).
• Methoden sind Funktionen.
• Interface enthält nur Methoden (keine Daten).
• Methoden stimmen nur nach Namen überein (nicht nach Typ).
• Es gibt keine Konstruktions- oder Zerstörungsmethode.
• Post-Inkrement und Post-Dekrement sind Anweisungen, keine Ausdrücke.
• Es gibt keine vordere Selbsterhöhung oder vordere Selbstabnahme.
• Aufgabe ist kein Ausdruck.
• In der Reihenfolge ausführen, in der Zuweisung und Funktionsaufruf definiert sind (es gibt keinen „Sequenzpunkt“).
• Keine Zeigerarithmetik.
• Speicher wird immer mit dem Wert Null initialisiert.
• Es ist legal, die Adresse lokaler Variablen zu übernehmen.
• Methoden haben kein „dieses“.
• Segmentierter Stapel.
• Keine statischen oder anderen Anmerkungen.
• Keine Vorlagen.
• Nichts Ungewöhnliches.
• Eingebauter String, Slice, Map.
• Überprüfung der Array-Grenzen.

Abgesehen von dieser vereinfachten Liste und einigen nicht erwähnten Kleinigkeiten glaube ich, dass Go ausdrucksvoller ist als C oder C++. Weniger ist mehr.

Aber trotzdem kann man nicht alles wegwerfen. Es besteht immer noch die Notwendigkeit, die Art und Weise zu strukturieren, wie Typen funktionieren, die richtige Syntax in der Praxis zu gewährleisten und die unbeschreiblichen Aspekte der Interaktion von Bibliotheken zu verbessern.

Wir haben auch einige Dinge hinzugefügt, die in C oder C++ nicht verfügbar sind, wie Slices und Maps, zusammengesetzte Deklarationen, Ausdrücke der obersten Ebene pro Datei (eine wichtige Sache, die fast vergessen wurde), Reflektion, Garbage Collection usw. Natürlich gibt es auch Parallelität.

Ich kann mir nicht vorstellen, keine Generika zu haben

Was natürlich offensichtlich fehlt, ist die Typenhierarchie. Erlauben Sie mir bitte, ein paar Schimpfworte dazu zu sagen.

In der Originalversion von Go sagte mir jemand, dass er sich nicht vorstellen könne, in einer Sprache ohne Generika zu arbeiten. Wie bereits irgendwo erwähnt, finde ich, dass dies eine absolut magische Rezension ist.

Um fair zu sein, hat er wahrscheinlich auf seine eigene Art ausgedrückt, wie sehr ihm gefällt, was STL in C++ für ihn getan hat. Lassen wir ihn im Interesse der Debatte im Zweifelsfall entscheiden.

Er sagte, dass das Schreiben von Containern wie Int-Listen oder Map-Strings eine unerträgliche Belastung sei. Ich denke, das ist ein erstaunlicher Punkt.

Selbst in Sprachen, die keine Generika haben, verbringe ich sehr wenig Zeit mit diesen Themen.

Objektorientierter Ansatz

Aber noch wichtiger ist, dass Typen die Lösung sind, um diese Belastungen loszulassen. Typ. Kein funktionaler Polymorphismus, keine Sprachgrundlage oder andere Unterstützung, nur Typen.

Das ist das Detail, das mich beeindruckt hat.

Programmierer, die von C++ und Java auf Go umsteigen, vermissen den Programmierstil der Arbeit mit Typen, insbesondere Vererbung und Unterklassenbildung, und alles, was damit zusammenhängt. Vielleicht bin ich ein Laie, was das Genre angeht, aber ich habe dieses Modell nie wirklich als sehr ausdrucksstark empfunden.

Mein verstorbener Freund Alain Fournier erzählte mir einmal, dass er der Meinung sei, dass die Einstufung die niedrigste Form des Stipendiums sei. Weißt du was? Typhierarchie ist Klassifizierung.

Sie müssen Entscheidungen darüber treffen, welches Teil in welche Box kommt, einschließlich des übergeordneten Elements jedes Typs, ob A von B erbt oder B von A erbt.

Ist ein sortierbares Array ein sortiertes Array oder ein durch ein Array ausgedrückter Sortierer? Wenn Sie glauben, dass alle Probleme typgesteuertes Design sind, müssen Sie Entscheidungen treffen.

Ich finde es lächerlich, auf diese Weise über das Programmieren nachzudenken. Der Kern liegt nicht in der angestammten Beziehung zwischen den Dingen, sondern darin, was sie für Sie tun können.

Natürlich kommen hier Schnittstellen ins Spiel. Aber sie sind bereits Teil der Blaupause, die die wahre Go-Philosophie ausmacht.

Wenn es bei C++ und Java um Typvererbung und Typklassifizierung geht, geht es bei Go um Komposition.

Doug McIlroy, der spätere Erfinder der Unix-Pipe, schrieb 1964 (!):

Wir sollten die Nachrichtendaten irgendwie Stück für Stück verbinden wie einen Gartenhahn und einen Schlauch. Dies ist auch die von IO verwendete Methode.

Dies ist auch die Methode, die Go verwendet. Go nimmt diese Idee auf und geht noch einen Schritt weiter. Dies ist eine Sprache über Kombination und Verbindung.

Ein offensichtliches Beispiel ist die Art und Weise, wie Schnittstellen uns die Kombination von Komponenten ermöglichen. Solange es Methode M implementiert, kann es an der entsprechenden Stelle platziert werden, ohne sich darum zu kümmern, was es ist.

Ein weiteres wichtiges Beispiel ist, wie Parallelität unabhängig laufende Berechnungen verbindet. Und es gibt auch ein ungewöhnliches (aber sehr einfaches) Typkompositionsmuster: das Einbetten.

Dies ist die einzigartige Kombinationstechnologie von Go, die sich völlig von C++- oder Java-Programmen unterscheidet.

Das große Programmiermuster von C++/Java

Es gibt ein unabhängiges Design von Go, das ich erwähnen möchte: Go wurde entwickelt, um beim Schreiben großer Programme zu helfen, die von großen Teams geschrieben und gepflegt werden.

Es gibt eine Sichtweise namens „Big Programming“, und irgendwie dominieren C++ und Java dieses Feld. Ich glaube, das ist nur ein historischer Fehler oder ein Industrieunfall. Es ist jedoch eine weithin akzeptierte Überzeugung, dass objektorientiertes Design etwas bewirken kann.

Das glaube ich überhaupt nicht. Große Software benötigt zwar den Schutz der Methodik, aber sie benötigt kein so starkes Abhängigkeitsmanagement und eine so klare Schnittstellenabstraktion oder gar solch großartige Dokumentationstools, aber es ist nicht wichtiger als ein leistungsstarkes Abhängigkeitsmanagement, eine klare Schnittstellenabstraktion und hervorragende Dokumentationstools. , und nichts davon kann C++ gut (obwohl Java es offensichtlich besser kann).

Wir wissen es noch nicht, da nicht genügend Software in Go geschrieben ist, aber ich bin zuversichtlich, dass Go in der großen Programmierwelt herausragen wird. Die Zeit wird es zeigen.

Warum Go bei C++-Programmierern nicht beliebt ist? Hat es nicht die Herzen der C++-Programmierer erobert? Spaß beiseite, ich denke, das liegt daran, dass Go und C++ völlig unterschiedliche Philosophien haben.

C++ ermöglicht es Ihnen, alle Probleme auf Knopfdruck zu lösen

.

Ich habe dies aus den C++11-FAQ zitiert:

C++ verfügt über ein breiteres Spektrum an Abstraktionen, Eleganz, Flexibilität und kostenlosen Ausdrucksmöglichkeiten als die enorme Zunahme an speziell geschriebenem handcodiertem Code.

Diese Denkrichtung unterscheidet sich von der von Go. Nullkosten sind nicht das Ziel, zumindest nicht null CPU-Kosten. Gos Vorschlag besteht eher darin, die Arbeitsbelastung des Programmierers zu minimieren.

Go ist nicht allumfassend. Man kann nicht alles eingebaut bekommen. Sie können nicht jedes kleine Detail der Ausführung genau kontrollieren. Beispielsweise gibt es kein RAII. Stattdessen kann die Garbage Collection verwendet werden. Es gibt auch keine Speicherfreigabefunktion.

Was Sie erhalten, ist leistungsstark, aber leicht zu verstehen und einfach zu verwenden, um einige Module zu erstellen, die zum Verbinden und Kombinieren zur Lösung von Problemen verwendet werden.

Dies ist am Ende vielleicht nicht so schnell, so ausgefeilt und ideologisch klar wie Ihre in anderen Sprachen verfassten Lösungen, aber es wird sicherlich einfacher zu schreiben, einfacher zu lesen, einfacher zu verstehen, einfacher zu warten und sicherer sein.

Mit anderen Worten, natürlich etwas zu einfach:

• Python- und Ruby-Programmierer: Move to Go, weil sie nicht viel Ausdruckskraft aufgeben, aber an Leistung gewinnen und mit Parallelität tanzen.
• C++-Programmierer: Sie können nicht zu Go wechseln, weil sie hart darum gekämpft haben, eine präzise Kontrolle über ihre Sprache zu erlangen, und nichts aufgeben wollen, was sie gewonnen haben. Für sie geht es bei Software nicht nur darum, Arbeit zu erledigen, sondern sie auf eine bestimmte Art und Weise zu erledigen.

Die Frage ist also: Widerlegt Gos Erfolg ihre Weltanschauung? Wir sollten von Anfang an etwas erkennen.

Wer von den neuen Features von C++11 begeistert ist, wird sich nicht um eine Sprache kümmern, die nicht über so viele Features verfügt. Auch wenn sich herausstellt, dass die Sprache mehr zu bieten hat, als sie sich vorgestellt haben.

Vielen Dank an alle.

Zusammenfassung

Ich war schon immer sehr neugierig auf Gos Philosophie „Weniger ist mehr“. Woher kommt das und was bedeutet es?

Ich habe es während des Frühlingsfestes gelesen und sortiert. Obwohl die Rede viel Inhalt hatte, war sie auch umgangssprachlicher. Aber im Grunde ist das, was Rob Pike mit „weniger ist mehr“ meinte, etwas Interessantes.

Der Kernpunkt ist: „Die Konzepte von Go und C++ sind völlig unterschiedlich. Es besteht die Hoffnung, dass die Arbeitsbelastung des Programmierers minimiert wird. Eine kleine Anzahl eigener Funktionen sollte verbunden und kombiniert werden können, um Probleme zu lösen. und ausdrucksvoller sein als Heap-Funktionen.

Das obige ist der detaillierte Inhalt vonGo-Design-Philosophie: Weniger ist mehr, woher kommt das?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!