Allez la philosophie du design : moins c'est plus, d'où ça vient ?

Lorsque je partageais mes connaissances et mon expérience dans la communauté Go auparavant, j'entendais souvent des mots d'argot tels que : moins c'est plus, moins c'est plus, la route vers la simplicité, la route vers la simplicité, etc.

Même lors des discussions sur les problèmes et les propositions du Go, certaines personnes utiliseront « moins c'est plus » pour réfuter ou soutenir des arguments, ce qui est très intéressant. Tout le monde sera très curieux, d’où vient-il et qu’est-ce que cela signifie ?

Source de la phrase d'or

Un concept culturel communautaire aussi profondément enraciné doit avoir été proposé par une personne clé. C'est l'auteur qui a prononcé cette phrase :

Est-ce que quelqu'un la reconnaît ?

Il s'agit de Rob Pike, le père du langage Go.

Rob Pike a mentionné quelque chose comme « moins c'est plus » à plusieurs reprises et cela est largement diffusé.

Partagez à des occasions telles que :

• En 2012, "Moins, c'est exponentiellement plus^[1]" a été partagé lors de la conférence Go SF, qui était le premier article compilé à partir d'opinions publiques. .
• En 2015, ce qui a été partagé lors de la conférence dotGo était "La simplicité est compliquée^[2]", qui a continué à inculquer la culture et à partager des opinions.

Diverses variantes de ce point de vue sont largement diffusées dans l'industrie, formant une « culture » unique dans la communauté Go.

Bien sûr, à en juger par la réponse de la communauté, il y a à la fois des éloges et des critiques.

Contenu du discours

Voici une citation de Rob Pike "Less is exponentiellement plus^[3]", la partie texte@MIKESPOOK^[4] Traduction, je vais réorganiser, couper, citer , Avec des images, je ne réinventerai pas la roue et je le préciserai.

Comme indiqué ci-dessous :

Contexte

C'est le contenu de ma conférence (Rob Pike) à la conférence Go à San Francisco en juin 2012.

Il s'agit d'un discours privé. Je ne parle au nom de personne dans l'équipe du projet Go, mais j'aimerais commencer par remercier l'équipe pour tout ce qu'elle a fait pour rendre Go possible.

En même temps, je voudrais également remercier la communauté San Francisco Go de m'avoir donné cette opportunité de prendre la parole.

Qu'est-ce qui me surprend le plus chez Go

Il y a quelques semaines, on m'a demandé : "Qu'est-ce qui vous a le plus surpris depuis le lancement de Go ?"

J'ai immédiatement eu une réponse : même si nous espérons que les programmeurs C++ comprendront Go comme langage alternatif, mais davantage de programmeurs Go viennent de Python et Ruby, et seuls quelques-uns viennent de C++.

Nous (Ken, Robert et moi) étions nous-mêmes des programmeurs C++ et nous avons conçu de nouveaux langages pour résoudre les problèmes des logiciels que nous avons écrits.

Et les autres programmeurs C++ ne semblent pas se soucier beaucoup de ces problèmes, ce qui semble un peu contradictoire.

Pourquoi nous avons développé Go

Aujourd'hui, je veux parler de ce qui nous a conduit à créer Go et pourquoi nous avons été surpris alors que cela n'aurait pas dû l'être.

Je promets de discuter de Go plus que de C++, et vous pouvez toujours suivre complètement le sujet même si vous ne connaissez pas le C++.

La réponse peut être résumée comme suit : Pensez-vous que moins c'est plus, ou moins c'est moins ?

L'histoire des Bell Labs

Voici une histoire vraie sous forme de métaphore. Comme suit :

1. Bell Labs était initialement identifié par trois numéros : 111 pour la recherche physique, 127 pour la recherche informatique, et ainsi de suite.
2. Au début des années 1980, une note est arrivée à temps indiquant que, comme la recherche telle que nous la connaissions se développait, un chiffre supplémentaire devait être ajouté afin d'identifier facilement notre travail. Notre centre devient donc 1127.
3. Ron Hardin a dit en plaisantant et à moitié sérieusement que si nous comprenions vraiment mieux le monde, nous pourrions le réduire d'un chiffre et faire de 127 seulement 27.

Bien sûr, la direction n’a pas entendu la blague, ou peut-être qu’elle ne voulait pas l’entendre, mais je pense qu’il y a une grande sagesse là-dedans. Moins c'est plus. Mieux vous comprenez, plus c’est implicite.

N'oubliez pas cette idée.

Contexte du développement de Go

Compilation C++ en attente

En septembre 2007, je faisais un travail trivial mais important sur un énorme programme Google C++ (celui que vous avez tous utilisé) de base.

Il m'a fallu environ 45 minutes pour compiler sur cet énorme cluster distribué.

Améliorations des nouvelles fonctionnalités C++

Reçu une notification indiquant que plusieurs personnes employées par Google travaillant pour le comité de normalisation C++ donneront un rapport.

Ils nous diront quelles améliorations seront apportées à ce qui s'appelait alors C++0x (maintenant connu sous le nom de C++11).

Pendant la présentation d'une heure, nous avons entendu des choses comme si 35 fonctionnalités étaient déjà prévues.

En fait, il y en a plus, mais seules 35 fonctionnalités sont décrites dans le rapport. Bien entendu, certaines fonctionnalités sont mineures mais suffisamment importantes pour mériter d’être mentionnées dans le rapport.

Il existe également des références très subtiles et difficiles à comprendre, telles que :

• rvalue références.
• modèles variadiques
• littéraux définis par l'utilisateur

À ce moment-là, je me suis posé une question : Le comité C++ croit vraiment que le problème avec C++ est qu'il n'y a pas assez de fonctionnalités  ?

Certainement, dans une autre blague de Ron Hardin,

simplifier le langage fait plus que ajouter des fonctionnalités Bien sûr, c'est un peu ridicule, mais gardez cette idée à l'esprit

Expérience de langage sexuel Quelques mois avant. lors de cette conférence C++, j'ai moi-même donné une conférence, que vous pouvez voir sur YouTube, sur un langage de concurrence jouet que j'ai développé dans les années 1980. Ce langage s'appelle Newsqueak, et c'est le prédécesseur de Go

J'ai fait ce rapport à cause de. quelques idées qui manquaient dans Newsqueak et auxquelles j'ai repensé lorsque je travaillais chez Google. L'écriture de code côté serveur devient plus facile, permettant à Google d'en bénéficier

En fait, j'ai

essayé d'implémenter ces idées en C++, mais j'ai échoué

Il était trop difficile de connecter des structures de contrôle C++ à des opérations simultanées. En fin de compte, il était difficile de voir les vrais avantages Même si j'avoue que je n'ai jamais été vraiment doué pour utiliser le C++, le C++ pur rendait quand même tout trop maladroit

Mais ce rapport C++0x m'a fait y repenser. Une chose qui me dérange vraiment (et je suis sûr que Ken et Robert aussi) est que le nouveau modèle de mémoire C++ a des types atomiques.

Cela semble être une erreur absolue d'ajouter une collection aussi microscopique de détails descriptifs à un système de caractères déjà surchargé. C'est également une vision à courte vue. Il est presque certain que le matériel progressera rapidement au cours des dix prochaines années. Il est très insensé de lier trop étroitement le langage au matériel actuel.

Go Initial Team

Après la présentation nous sommes retournés au bureau. J'ai commencé une autre compilation, j'ai tourné ma chaise vers Robert et j'ai commencé à communiquer les questions clés.

Avant la fin de la compilation, nous avions fait venir Ken et décidé quoi faire.

Nous n'allons pas continuer à écrire du C++, et nous - surtout moi, voulons pouvoir écrire facilement de la concurrence lors de l'écriture du code Google.

En même temps, nous souhaitons également avancer dans le contrôle de la « grande programmation », dont nous parlerons plus tard.

Go feature discussion

Nous avons écrit un tas de choses que nous voulions et leurs conditions nécessaires sur le tableau blanc. Les détails syntaxiques et sémantiques sont ignorés, et le plan et la vision d’ensemble sont envisagés.

J'ai encore ici un email fascinant de cette époque.

Voici un extrait :

• Robert : Le point de départ est C, corrigez quelques défauts évidents, supprimez l'encombrement et ajoutez quelques fonctionnalités manquantes.

• Rob : nommé « go ». Vous pouvez inventer l’origine du nom, mais il repose sur une bonne base. C'est court et facile à épeler. Outils : goc, gol, goa. Si vous disposez d'un débogueur/interprète interactif, appelez-le simplement "go". L'extension est .go.

• Robert : L'interface vide est interface{}. Ils implémentent toutes les interfaces, cela peut donc être utilisé à la place de void *.

Nous n’avons pas tout décrit correctement. Par exemple, le mappage des tableaux et des tranches a pris près d’un an. Mais la plupart des caractéristiques importantes de la langue ont été définies dès les premiers jours.

Notez que Robert a dit que C est le point de départ, pas C++. Je ne suis pas sûr, mais je crois qu'il veut dire C, surtout si Ken est là.

Mais le fait est qu’au final nous ne sommes pas partis de C. Nous sommes partis de zéro, en empruntant uniquement des opérateurs, des parenthèses, des accolades et quelques mots-clés. (Bien sûr, en prenant aussi le meilleur des autres langages que nous connaissons.)

Quoi qu'il en soit, nous faisons désormais le contraire du C++, en déconstruisant tout, en revenant à la case départ et en recommençant. Nous n’essayons pas de concevoir un meilleur C++, ni même un meilleur C. Juste un meilleur langage pour le type de logiciel qui nous intéresse.

Finalement, c'est devenu un langage complètement différent du C et du C++. Chaque version devient de plus en plus différente.

Liste des fonctionnalités Go

J'ai dressé une liste de simplifications importantes pour le C et le C++ dans Go :

• Syntaxe canonique (aucune table de symboles requise pour l'analyse).
• Collecte des déchets (uniquement).
• Pas de fichier d'en-tête.
• Dépendances explicites
• Aucune dépendance cyclique.
• Les constantes ne peuvent être que des nombres.
• int et int32 sont des types différents.
• Visibilité des paramètres de casse des lettres.
• Tout type peut avoir des méthodes (pas de classes).
• Aucun héritage de sous-type (pas de sous-classement).
• Initialisation au niveau du package et séquence d'initialisation définie.
• fichiers compilés dans un package.
• Les expressions globales au niveau du package sont indépendantes de l'ordre.
• Pas de conversion arithmétique (les constantes sont traitées auxiliairement).
• Implémentation implicite de l'interface (aucune définition "impléments" requise).
• Embedded (pas de mise à niveau vers la classe parent).
• Les méthodes sont définies comme des fonctions (aucune exigence particulière en matière de localisation).
• Les méthodes sont des fonctions.
• L'interface ne contient que des méthodes (pas de données).
• Les méthodes ne correspondent que par nom (pas par type).
• Il n'y a aucune méthode de construction ou de destruction.
• Post-incrémentation et post-décrémentation sont des déclarations, pas des expressions.
• Il n'y a pas de pré-incrémentation ni de pré-décrémentation.
• La mission n'est pas une expression.
• Exécuter dans l'ordre dans lequel l'affectation et l'appel de fonction sont définis (il n'y a pas de "point de séquence").
• Pas d'arithmétique de pointeur.
• La mémoire est toujours initialisée avec une valeur nulle.
• Il est légal de prendre l'adresse de variables locales.
• Les méthodes n’ont pas « ceci ».
• Pile segmentée.
• Aucune annotation statique ou autre type.
• Aucun modèle.
• Rien d'inhabituel.
• Ficelle, tranche, carte intégrées.
• Vérification des limites du tableau.

Outre cette liste simplifiée et quelques anecdotes non mentionnées, je pense que Go est plus expressif que C ou C++. Moins c'est plus.

Mais même ainsi, on ne peut pas tout jeter. Il est toujours nécessaire de structurer la façon dont les types fonctionnent, d'avoir une syntaxe appropriée dans la pratique et de faire en sorte que les choses ineffables consistant à améliorer l'interaction des bibliothèques.

Nous avons également ajouté certaines choses qui ne sont pas disponibles en C ou C++, comme les tranches et les cartes, les déclarations composées, les expressions de niveau supérieur par fichier (une chose importante qui a presque été oubliée), la réflexion, le garbage collection, etc. Bien sûr, il y a aussi la concurrence.

Je ne peux pas imaginer ne pas avoir de génériques

Bien sûr, ce qui manque évidemment, c'est la hiérarchie des types. S'il vous plaît, permettez-moi de dire quelques gros mots à ce sujet.

Dans la version originale de Go, quelqu'un m'a dit qu'il ne s'imaginait pas travailler dans un langage sans génériques. Comme mentionné quelque part auparavant, je pense que c'est une critique absolument magique.

Pour être honnête, il utilisait probablement sa propre façon d'exprimer à quel point il aimait ce que STL faisait pour lui en C++. Par souci de débat, accordons-lui le bénéfice du doute.

Il a dit qu'écrire des conteneurs comme des listes int ou des chaînes de carte est un fardeau intolérable. Je pense que c'est un point étonnant.

Même dans les langues qui n'ont pas de génériques, je consacre très peu de temps à ces questions.

Approche orientée objet

Mais plus important encore, il a déclaré que les types sont la solution pour abandonner ces fardeaux. taper. Pas de polymorphisme fonctionnel, pas de fondement du langage ou autre assistance, juste des types.

C'est le détail qui m'a marqué.

Les programmeurs arrivant sur Go depuis C++ et Java manquent du style de programmation consistant à travailler avec les types, en particulier l'héritage et les sous-classes, et tout ce qui va avec. Je suis peut-être un profane en ce qui concerne le genre, mais je n'ai jamais vraiment trouvé ce modèle très expressif.

Mon défunt ami Alain Fournier m'a dit un jour qu'il croyait que la forme de bourse la plus basse était la classification. Alors tu sais quoi ? La hiérarchie des types est la classification.

Vous devez décider quelle pièce va dans quelle boîte, y compris le parent de chaque type, si A hérite de B ou B hérite de A.

Un tableau triable est-il un tableau trié ou un trieur exprimé par un tableau ? Si vous pensez que tous les problèmes sont dus à une conception axée sur le type, vous devez alors prendre des décisions.

Je pense qu'il est ridicule de penser à la programmation de cette façon. L’essentiel n’est pas la relation ancestrale entre les choses, mais ce qu’elles peuvent faire pour vous.

Bien sûr, c’est là que les interfaces entrent en jeu dans Go. Mais ils font déjà partie du plan, qui constitue la véritable philosophie du Go.

Si C++ et Java concernent l'héritage de types et la classification de types, Go concerne la composition.

Doug McIlroy, l'inventeur éventuel du tuyau Unix, écrivait en 1964 (!):

Nous devrions en quelque sorte relier les données des messages pièce par pièce comme un robinet de jardin et un tuyau. C'est également la méthode utilisée par IO.

C'est aussi la méthode utilisée par Go. Go reprend cette idée et va encore plus loin. C'est un langage sur la combinaison et la connexion.

Un exemple évident est la façon dont les interfaces nous permettent de combiner des composants. Tant qu'il implémente la méthode M, il peut être placé à l'endroit approprié sans se soucier de ce dont il s'agit.

Un autre exemple important est la manière dont la concurrence connecte des calculs exécutés indépendamment. Et il existe également un modèle de composition de caractères inhabituel (mais très simple) : l'intégration.

Il s'agit de la technologie de combinaison unique de Go, qui est complètement différente des programmes C++ ou Java.

Le grand modèle de programmation de C++/Java

Il existe une conception sans rapport avec Go que je tiens à mentionner : Go a été conçu pour aider à écrire de grands programmes, écrits et maintenus par de grandes équipes.

Il existe un point de vue appelé « Big Programming », et d'une manière ou d'une autre, C++ et Java dominent ce domaine. Je pense qu'il s'agit simplement d'une erreur historique ou d'un accident industriel. Mais il est largement admis que la conception orientée objet peut faire quelque chose.

Je n’y crois pas du tout. Les gros logiciels ont besoin de la protection de la méthodologie, mais ils n'ont pas besoin d'une gestion des dépendances aussi forte et d'une abstraction d'interface aussi claire, ni même d'outils de documentation aussi magnifiques, mais ce n'est pas plus important qu'une gestion des dépendances puissante, une abstraction d'interface claire et d'excellents outils de documentation. , et aucune de ces choses n'est une chose que C++ fait bien (même si Java le fait évidemment mieux).

Nous ne le savons pas encore car il n’y a pas assez de logiciels écrits en Go, mais je suis convaincu que Go se démarquera dans le grand monde de la programmation. Le temps nous le dira.

Pourquoi Go n'est pas apprécié des programmeurs C++

Maintenant, revenons à l'étonnante question que j'ai mentionnée au début de mon exposé :

Pourquoi Go, un langage conçu pour détruire le C++, et pourquoi vous l'avez fait. N'a-t-il pas conquis le cœur des programmeurs C++ ?

Blague à part, je pense que c'est parce que Go et C++ ont des philosophies complètement différentes.

C++ vous permet de résoudre tous les problèmes du bout des doigts.

J'ai cité ceci dans la FAQ C++11 :

C++ offre une gamme d'abstractions, d'élégance, de flexibilité et de capacités d'expression gratuites plus large que l'énorme croissance du code manuscrit spécialement écrit.

Cette direction de pensée est différente de celle de Go. Le coût zéro n’est pas l’objectif, du moins pas le coût CPU nul. La proposition de Go consiste davantage à minimiser la charge de travail du programmeur.

Go n'est pas exhaustif. Vous ne pouvez pas tout intégrer. Vous ne pouvez pas contrôler avec précision chaque petit détail de l'exécution. Par exemple, il n'y a pas de RAII. La collecte des déchets peut être utilisée à la place. Il n'y a pas non plus de fonction de libération de mémoire.

Ce que vous obtenez est puissant mais facile à comprendre et à utiliser pour créer des modules qui sont utilisés pour se connecter et se combiner pour résoudre des problèmes.

Cela ne sera peut-être pas aussi rapide, aussi raffiné, aussi clair sur le plan idéologique que vos solutions écrites dans d'autres langues, mais ce sera certainement plus facile à écrire, plus facile à lire, plus facile à comprendre, plus facile à maintenir et plus sécurisé.

En d'autres termes, bien sûr, un peu trop simplistes :

• Les programmeurs Python et Ruby : Move to Go car ils ne renoncent pas à beaucoup d'expressivité, mais gagnent en performance, et dansent avec la concurrence.
• Les programmeurs C++ : ne peuvent pas passer à Go car ils se sont battus dur pour obtenir un contrôle précis sur leur langage et ne veulent pas abandonner tout ce qu'ils ont gagné. Pour eux, le logiciel ne consiste pas seulement à accomplir un travail, mais à le faire d'une certaine manière.

La question est donc : le succès de Go réfute-t-il leur vision du monde ? Nous devrions réaliser quelque chose dès le début.

Ceux qui sont enthousiasmés par les nouvelles fonctionnalités de C++11 ne se soucieront pas d'un langage qui n'a pas autant de fonctionnalités. Même s’il s’avère que la langue a plus à offrir qu’ils ne l’imaginaient.

Merci à tous.

Résumé

J'ai toujours été très curieux de connaître la philosophie de Go selon laquelle « moins c'est plus ». D'où vient-elle et quelle est sa signification ?

Je l'ai lu et trié pendant la Fête du Printemps. Même si le discours contenait beaucoup de contenu, il était aussi plus familier. Mais essentiellement, ce que Rob Pike entendait par « moins c’est plus » est quelque chose d’intéressant.

Le point de vue principal est le suivant : "Les concepts de Go et C++ sont complètement différents. On espère que la charge de travail du programmeur sera minimisée. Un petit nombre de ses propres fonctionnalités devraient pouvoir être connectées et combinées pour résoudre des problèmes, et être plus expressif, plutôt que d'accumuler des fonctions."

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!