📩 🍷 🕜 Paul Graham: concision = force 📏 🤚🏼 😳

À HackerNews aujourd'hui, nous avons soulevé une discussion sur l' article de 2002 de Paul Graham et nous avons décidé de ressusciter sa traduction de l'inexistence.

"La quantité de sens compressée dans un petit espace
par des signes algébriques, est une autre circonstance qui facilite
les raisonnements que nous sommes habitués à poursuivre par leur aide."
- Charles Babbage (1791-1871)

Dans la discussion autour de l'article LL1 Revenge sur la liste de diffusion LL1, Paul Prescod a fait une remarque qui ne me venait pas à l'esprit.

L'objectif de Python est la régularité et la lisibilité, mais pas la brièveté.

À première vue, un langage de programmation ne devrait probablement pas prétendre l'être. Si je comprends bien, brièveté (concision, concision, compacité) = force. Et si oui, alors en faisant une substitution, on obtient:

L'objectif de Python est la régularité et la lisibilité, mais pas la puissance.

ce qui, à son tour, n'est pas un très bon compromis (si c'est vraiment un compromis), qui vaut la peine d'être fait. Il semble que si vous dites: le but du langage Python n'est pas d'être un langage de programmation efficace.

Est-ce que brièveté = force? Cela semble être une question importante, peut-être la question la plus importante pour ceux qui sont impliqués dans le développement des langues. Je ne suis pas encore sûr que la réponse soit simplement «oui», mais pour commencer, c'est une bonne hypothèse.

Hypothèse

Mon hypothèse est que la brièveté est le pouvoir, ou ils sont si proches que, à l'exception des cas pathologiques, vous pouvez les prendre pour quelque chose d'identique.

La concision, me semble-t-il, est à quoi servent les langages de programmation. Les ordinateurs seraient tout aussi heureux s'ils recevaient des instructions directement en langage machine. Je pense que la principale raison pour laquelle nous allons développer des langages de haut niveau est d'avoir l'avantage d'exprimer (et surtout, de penser) dix lignes dans un langage de haut niveau, ce qui nécessiterait 1000 lignes de code machine. En d'autres termes, l'objectif principal des langages de haut niveau est de raccourcir le code source.

Si le code source plus court est le but des langages de haut niveau, et la force de quelque chose est une mesure de la façon dont l'objectif est atteint, alors la force du langage de programmation est de savoir combien il réduit vos programmes.

Inversement, un langage qui ne rend pas vos programmes plus petits fait un mauvais travail d'un langage de programmation, tout comme un couteau qui coupe mal ou une impression illisible.

Métrique

Et dans quel sens est moins? La mesure la plus courante de la taille du code source est le nombre de lignes. Mais cette mesure n'est courante qu'à cause de la simplicité de la mesure, et je ne pense pas que quiconque pense que c'est un bon test de la taille du programme. Les langues ont des conventions différentes sur ce qui peut être placé sur une seule ligne; pas mal de lignes en C peuvent n'avoir qu'un ou deux séparateurs.

Un autre test simple est le nombre de caractères dans le programme, mais celui-ci n'est pas trop bon; certaines langues (comme Perl) ont des identifiants plus courts que d'autres.

Je pense que la meilleure mesure de la taille d'un programme peut être le nombre d'éléments, où l'élément est quelque chose qui pourrait devenir un sommet séparé dans l'arbre source. Le nom d'une variable ou d'une fonction est un élément; un entier ou un nombre réel est un élément; un segment littéral de texte est un élément; un élément d'une directive de modèle ou de format est un élément. Il y a des cas limites ("-5" est-il un élément ou deux?), Mais je pense que la plupart d'entre eux sont les mêmes dans toutes les langues, donc ils n'affecteront pas trop la comparaison.

Cette mesure doit être concrétisée, et elle peut nécessiter une interprétation supplémentaire dans le cas de certaines langues spécifiques, mais il me semble qu'elle essaie de mesurer la bonne chose: le nombre de parties du programme. L'arbre source est ce que vous dessinez dans votre esprit pour représenter le programme, et donc la taille de cet arbre est proportionnelle à la quantité de travail nécessaire pour l'écrire ou le lire.

Conception

Cette mesure nous permettrait de comparer différentes langues, mais ce n'est pas, du moins pour moi, sa valeur de base. Et la valeur du test de brièveté est un guide pour concevoir des langues. La comparaison de langue la plus utile consiste à comparer deux variantes possibles de la même langue. Que puis-je faire dans la langue pour raccourcir les programmes?

Si la charge conceptuelle d'un programme est proportionnelle à sa complexité et qu'un programmeur donné peut supporter une certaine charge conceptuelle, cela revient à demander: comment aider les programmeurs à faire plus? Et cela, me semble-t-il, revient à demander: comment concevoir un bon langage?

(Soit dit en passant, la fausseté de ce dicton déjà barbu «toutes les langues sont équivalentes» est plus clairement visible lors de la conception des langues. Lorsque vous créez une nouvelle langue, vous comparez constamment deux langues - une dans laquelle je ferais X, et l'autre dans laquelle je ne ferais pas - de sorte que décider si c'est mieux. S'il s'agissait d'une question inutile, vous pourriez tout aussi bien lancer une pièce.)

Avoir un objectif de brièveté semble être un bon moyen de trouver de nouvelles idées. Si vous trouvez un moyen de raccourcir les programmes, ce n'est pas un hasard: vous avez probablement trouvé une nouvelle abstraction utile. Vous pourriez même écrire un programme qui récupérerait des morceaux répétés dans le code source. De nouvelles idées peuvent être trouvées parmi les langues qui ont la réputation d'être concises: Forth, Joy, Icon.

Comparaison

Le premier qui a écrit sur ces choses était, pour autant que je sache, Fred Brooks avec son livre Mythical Man-Month. Il a écrit que les programmeurs génèrent la même quantité de code indépendamment de la langue. Quand je l'ai lu pour la première fois dans la vingtaine, ce fut une grosse surprise, et il me semblait que cela avait d'énormes conséquences. Cela signifiait que (a) la seule façon d'écrire des programmes plus rapidement était d'utiliser un langage plus court, et (b) celui qui avait pris la peine de le faire demanderait aux concurrents qui ne le font pas.

La conjecture de Brooks, si elle est vraie, peut être l'essence même du piratage. Depuis lors, au fil des ans, j'ai prêté attention à tout ce qui pouvait être pertinent pour la question: des études théoriques aux histoires sur des projets individuels. Je n'ai rien vu qui contredirait cette hypothèse.

Mais je n'ai vu aucune preuve claire et je ne m'attends pas à les voir. Des études telles que la comparaison des langages de programmation Lutz Prekelt, bien qu'elles produisent les résultats escomptés, elles ont tendance à utiliser des tâches trop petites pour un test significatif. Le meilleur test pour une langue est ce qui se passe dans les programmes écrits en un mois. Et si vous êtes convaincu, comme moi, que le but principal des langues est d'être une bonne langue dans laquelle ils pensent (plutôt qu'une langue dans laquelle ils donnent des instructions à l'ordinateur après y avoir réfléchi), alors le véritable test pour la langue est quelle nouveauté pouvez-vous y écrire. Ainsi, la comparaison de langues basées sur une spécification prédéfinie est quelque peu erronée.

Le vrai test pour la langue est de savoir dans quelle mesure vous pouvez y trouver et résoudre de nouveaux problèmes, mais pas les tâches formulées par quelqu'un d'autre. Ce sont des critères différents. Dans l'art, des outils tels que la broderie et la mosaïque fonctionnent bien si vous savez à l'avance ce que vous voulez obtenir, mais absolument indécents si vous ne le savez pas. Si vous souhaitez révéler une image en train d'écrire une image (ce que vous devez faire pour révéler des choses complexes comme, par exemple, l'image d'une personne), vous devez utiliser un outil plus flexible comme un crayon, de l'encre ou des peintures à l'huile. Bien sûr, les tapisseries et les mosaïques sont faites comme ça: d'abord une image est créée, puis seulement elle est copiée.

Cela signifie qu'il est peu probable que nous ayons une comparaison correcte de la force relative des langages de programmation. Nous aurons des comparaisons exactes, mais pas correctes. En particulier, les études visant explicitement à comparer les langues utiliseront probablement de petites tâches et utiliseront nécessairement un ensemble de tâches prédéfinies, et auront donc tendance à sous-estimer les langues les plus puissantes.

Les rapports dans ce domaine, bien qu'ils soient moins précis que les études «scientifiques», seront probablement plus significatifs. Par exemple, Ulf Wieger d'Ericsson a mené une étude et est arrivé à la conclusion qu'Erlang est 4 à 10 fois plus court que C ++, et que la vitesse de développement du logiciel est proportionnellement plus élevée:

La comparaison des projets internes dans Ericsson révèle une productivité similaire en lignes de code par heure, y compris toutes les phases de développement, quel que soit le langage utilisé (Erlang, PLEX, C, C ++ ou Java). Différences de langues - uniquement dans la quantité totale de code source.

Cette étude indique également clairement qu'elle n'apparaît pas dans le livre de Brooks (car elle ne mesurait que les lignes de code débogué): les programmes écrits dans des langages plus puissants ont tendance à contenir moins d'erreurs. C'est déjà assez, et probablement dans des tâches telles que les commutateurs réseau, c'est plus important que les performances du programmeur.

Goûts

En fin de compte, vous pouvez faire confiance à votre instinct. Qu'est-ce que la programmation dans ce langage? Je pense que pour créer une meilleure langue, vous devez devenir hypersensible à la façon dont la langue vous permet d'y penser, puis choisir ou développer une langue qui vous semble la plus appropriée. Si une propriété de la langue est gênante ou restrictive - ne vous inquiétez pas, vous le saurez.

Mais une telle hypersensibilité se traduira par des langues maladroites devenant insupportables pour vous. Je trouve la programmation dans des langages qui n'ont pas de macros insupportablement restrictive, tout comme si quelqu'un habitué à la frappe dynamique considérait insupportablement restrictif le retour aux langues, où les types devraient être décrits pour chaque variable déclarée et il est impossible de déclarer une liste composée d'éléments différents types.

Et je ne suis pas seul. Je connais de nombreux hackers Lisp avec lesquels quelque chose de similaire s'est produit. En fait, la mesure la plus précise de la force relative d'un langage de programmation pourrait être la proportion de programmeurs qui connaissent un langage donné qui entreprendront tout travail dans lequel ce langage devrait être utilisé, quel que soit le domaine.

Limites

Beaucoup de pirates savent probablement à quoi cela ressemble lorsque le langage semble restrictif. C'est probablement le même sentiment que lorsque vous êtes coincé dans un embouteillage dans la rue que vous souhaitez emprunter et que vous devez faire un long détour. Vous voulez dire quelque chose et la langue ne vous permet pas de le faire.

En fait, un langage limitatif n'est pas un langage succinct. Le problème n'est pas que vous ne pouvez pas exprimer quelque chose, mais que le détour que cette langue vous oblige à faire est trop long. Faites cette expérience de pensée: vous voulez écrire une sorte de programme, et le langage ne vous permet pas de le faire comme vous l'aviez prévu, mais au lieu de cela, vous le raccourcissez. Au moins pour moi, ce ne serait pas trop restrictif. Comme si un policier vous dirigeait d'un embouteillage sur une route plus courte au lieu d'un long détour. Hou la la!

Il me semble que le sentiment de limitation essentiellement (de 90 pour cent?) Découle du fait que vous êtes obligé de prolonger le programme dans la langue dans laquelle vous écrivez, par rapport à la langue dans laquelle vous pensez. La limite est fondamentalement une brièveté insuffisante, donc quand une langue semble être limitative, cela signifie qu'elle n'est pas assez courte.

Lisibilité

La citation que j'ai commencée mentionne également deux autres qualités: la régularité et la lisibilité. Je ne comprends pas vraiment ce qu'est la régularité et quels sont les avantages d'un code régulier et lisible par rapport à un code simplement lisible. Mais je pense que je sais ce que l'on entend par lisibilité, et il me semble également que cela a à voir avec la brièveté.

Ici, nous devons être prudents avec les concepts de lisibilité d'une seule ligne de code et la lisibilité du programme dans son ensemble. Seul le dernier est important. Je suis d'accord qu'une ligne sur BASIC est probablement plus lisible qu'une ligne sur Lisp, mais un programme écrit en BASIC aura plus de lignes que le même programme écrit en Lisp. La lecture du programme BASIC demandera plus d'efforts.

effort total = effort pour lire une ligne * nombre de lignes

Je ne suis pas sûr que la lisibilité soit proportionnelle à la brièveté, mais la brièveté est certainement un facteur de lisibilité (voir la formule ci-dessus). Il n'est donc guère logique de dire que le but du langage est la lisibilité, mais pas la brièveté.

Pour un utilisateur qui voit cette langue pour la première fois, la lisibilité ligne par ligne signifie que cette langue lui semblera inoffensive. Ainsi, la lisibilité ligne par ligne peut être une bonne décision marketing, bien que ce soit une mauvaise décision de conception. Il est isomorphe quant au mode de paiement échelonné: au lieu d'être intimidé par un gros acompte, vous offrez à l'acheteur un petit versement mensuel. Le paiement partiel n'est finalement pas rentable pour lui, ainsi que la lisibilité ligne par ligne - pour le programmeur. L'acheteur doit effectuer de nombreux petits paiements, tout comme le programmeur doit lire plusieurs lignes lisibles séparément.

Ce ratio existait même avant l'avènement des langages de programmation. Si vous lisez des romans et des articles de journaux, votre première expérience de lecture d'un article en mathématiques peut être effrayante: lire une page prend une demi-heure. Néanmoins, je suis sûr que le problème n'est pas dans la notation, comme cela peut sembler à première vue. Un article en mathématiques est difficile à lire car les idées elles-mêmes sont complexes. Si vous exprimez les mêmes idées en prose (comme le faisaient les mathématiciens avant de penser à une brève notation), leur lecture ne serait pas plus facile, car cette seule page se transformerait en un livre entier.

Dans quelle mesure?

Certains étaient en désaccord avec l'idée de concision = force. Je pense que, au lieu de se demander si c'est le cas, il serait plus utile de se demander dans quelle mesure la brièveté est le pouvoir? Parce qu'il est clair que la brièveté est l'un des principaux objectifs des langages de programmation. Sinon, quel est leur objectif et quelle est l'importance de ces autres fonctions?

Je propose cela pour ne pas rendre la discussion plus civile. Je veux vraiment connaître la réponse. Quand, si cela se produit, la langue devient-elle suffisamment concise?

L'hypothèse avec laquelle j'ai commencé était que, à l'exception de certains cas pathologiques, la brièveté est identique à la force. Je voulais dire qu'ils seront identiques dans n'importe quel langage développé par quelqu'un, mais si quelqu'un veut créer un langage spécifiquement pour réfuter cette hypothèse, alors cela fonctionnera probablement. Mais je n'en suis pas vraiment sûr non plus.

Langues mais pas programmes

Il convient de préciser que nous parlons de la brièveté des langues et non des programmes individuels. Bien sûr, certains programmes peuvent être écrits très étroitement.

J'ai écrit à ce sujet dans le livre «About Lisp». Pour que la macro se justifie, elle doit économiser beaucoup plus d'espace par rapport à sa propre longueur. Si une macro volumineuse enregistre dix lignes de code chaque fois que vous l'utilisez et que la macro elle-même se compose de dix lignes, vous obtiendrez des économies de lignes si vous l'utilisez plus de deux fois. Mais c'est toujours une mauvaise décision, car les définitions de macro sont plus difficiles à lire que le code normal. Vous devrez peut-être utiliser la macro 10 ou 20 fois avant que la lisibilité ne s'améliore.

Je suis sûr que dans n'importe quelle langue de tels compromis sont possibles (même si je soupçonne que les enjeux sont soulevés dans des langues fortes). Chaque programmeur a déjà vu du code extrêmement raccourci en raison de techniques de programmation douteuses.

Ainsi, il est incontestable - du moins pour moi - que les programmes peuvent être suffisamment concis. La question est: les langues elles-mêmes peuvent-elles être courtes? Les langages peuvent-ils obliger les programmeurs à écrire brièvement (en éléments) au détriment de la lisibilité?

L'une des raisons pour lesquelles il est difficile d'imaginer un langage trop concis est que s'il existe une manière trop compacte d'exprimer quelque chose, alors il y aura probablement une manière plus longue. Par exemple, s'il vous semble que l'utilisation de macros ou de fonctions de haut niveau en Lisp est trop dense, vous pouvez écrire du code isomorphe à Pascal. Si vous ne voulez pas exprimer la factorielle dans la langue d'Arc comme un appel à une fonction de haut niveau,

(rec zero 1 * 1-)

vous pouvez également écrire une définition récursive: bien

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

que je ne puisse pas donner d'exemples aussi immédiatement, je suis intéressé par la question: la langue peut-elle être trop courte? Y a-t-il des langues qui vous obligent à écrire du code illisible? Si quelqu'un a des exemples, je serais heureux de les voir.

(Rappelez-vous: je suis intéressé par les programmes qui ont une densité élevée selon la mesure des «éléments» décrits ci-dessus, mais pas les programmes qui sont courts juste parce que les séparateurs peuvent être omis en eux et tout a des noms qui sont un caractère long.)

Il a d'abord été publié ici .

Apprenez en détail comment obtenir une profession recherchée à partir de zéro ou passer au niveau supérieur en compétences et en salaire en suivant les cours en ligne de SkillFactory:

Paul Graham: concision = force