Pourquoi la verbosité est-elle mauvaise pour un langage de programmation? [fermé]

J'ai vu beaucoup de gens se plaindre de la verbosité dans les langages de programmation. Je trouve que, dans certaines limites, plus un langage de programmation est bavard, mieux il le comprend. Je pense que cette verbosité renforce également l’écriture APIpour une langue plus claire .

Le seul inconvénient auquel je puisse penser est que cela vous oblige à taper plus, mais je veux dire, la plupart des gens utilisent des IDE qui font tout le travail à votre place.

Alors, quels sont les inconvénients possibles d'un langage de programmation prolixe?

Le but est une compréhension rapide

"Verbose" signifie "utilise trop de mots". La question est de savoir ce qu'est "trop".

Un bon code doit être facile à comprendre d'un coup d'œil. Cela est plus facile si la plupart des caractères servent directement l’objet du code .

Signal vs bruit

Si une langue est commentée, votre code est principalement constitué de bruit. Comparez le "Hello World" de Java :

class HelloWorldApp {
    public static void main(String[] args) {
        System.out.println("Hello World!");
    }
}

... avec Ruby:

print "Hello World!"

Le bruit gaspille l'énergie mentale.

Cryptic vs Clear

D'un autre côté, la rareté excessive d'une langue coûte aussi de l'énergie mentale. Comparez ces deux exemples de Common Lisp :

(car '(1 2 3))   # 3 characters whose meaning must be memorized
# vs
(first '(1 2 3)) # 5 characters whose meaning is obvious

Cela affecte la quantité de code que vous pouvez voir et analyser en un seul coup d'œil

x++ plutôt que set(x,Integeradd(get(x),1))

ps. Ce n'est pas juste une question de lecture de code. A l'époque des écrans 40x25, les langages de type APL, ou Perl, étaient utiles sur Cobol ou Fortran pour la quantité de code que vous pouviez lire / page. Mais maintenant, il s’agit plus de votre propre cache interne: si une requête a un seul opérateur, il est plus facile pour mon cerveau vieillissant d’analyser celle-ci que celle contenant 3 symboles et 4 appels de fonction.

Si le langage utilisé nuit à la lisibilité du code, il est mauvais.

Certaines langues ont une telle syntaxe verbeuse que saisir le sens du code prend plus de temps (je pense à VB.NET versus C #):

If something Then
End If

if(something)
{}

Cela revient vraiment à ce qu'un codeur est familier et à l'aise.

Allez jeter un coup d'œil à AppleScript , l'un des langages les plus prolixes que je puisse penser qui puisse être considéré comme courant , essayez d' écrire quelque chose de trivaliste et revenez en arrière et essayez de faire valoir que la verbosité est un bon trait dans une langue.

Essayer de se rappeler toute la sémantique de la destination et de la nature des mots-clés n’est pas trivial si vous ne le faites pas tous les jours.

Il suffit de regarder tout le bruit des mots - clés dans cet exemple trivial:

tell application "Finder"
    if folder "Applications" of startup disk exists then
        return count files in folder "Applications" of startup disk
    else
        return 0
    end if
end tell

Accorder la même chose bashaux outils Unix traditionnels serait concis, mais crypté pour la plupart des utilisateurs d’OSX, il faut donc trouver un équilibre.

Je pense que vous devez inverser la question et demander: pourquoi certaines personnes pensent-elles que le code laconique est bon?

Ma réponse serait qu'il y a deux raisons fondamentales:

Raisons pour lesquelles laconique peut être mieux

Ceux-ci incluent être plus lisibles, de la même manière qu'une phrase courte peut être plus compréhensible qu'une phrase fleurie et verbeuse. Souvent, les langages de programmation qui imitent la grammaire anglaise finissent par être terriblement longs, nécessitant d’énormes volumes de code pour effectuer les actions les plus simples. Vous constaterez souvent que plus une langue imite une langue écrite, plus il est difficile de la persuader de réaliser des opérations logiquement complexes.

Les raisons pour lesquelles Terse peut être pire

Certaines langues (et je pense à Perl) utilisent un tableau de symboles étranges, qui semblent avoir été sélectionnés de manière presque arbitraire, dans le cadre de leur syntaxe. Pour ceux qui ne sont pas familiers avec ces hiéroglyphes, le langage devient impénétrable. Il devient également facile de faire des erreurs de frappe qui ne sont pas faciles à voir. Les expressions régulières incarnent peut-être ce genre de concision.

En outre, certaines personnes aiment se montrer en écrivant un code laconique parce que, franchement, elles pensent que cela les rend malignes. Vous le voyez parfois sur StackOverflow, où les gens soumettent souvent des réponses extrêmement compactes aux dépens de la lisibilité. C'est une sorte de "impressionner vos pairs" avec à quel point vous connaissez la philosophie, mais les bons programmeurs se rendent compte que le " code golf " n'est pas le moyen de créer un logiciel maintenable.

@frowing, je suggérerais que l’un des moyens d’examiner la question de la verbosité consiste à réaliser que la programmation consiste toujours en un mélange de deux styles plutôt différents de recherche et d’expression d’une solution.

Le premier style, plus détaillé, est la programmation (linguistique) orientée vers la langue. Ce style combine des mots ressemblant à des noms et des mots ressemblant à des verbes dans des structures ressemblant à des phrases. Il est conçu pour être lu et compris de la même manière qu’un paragraphe bien écrit. La programmation linguistique est le style de programmation le plus universel puisque le langage lui-même est universel. Pour cette même raison, le support de programme à long terme nécessite toujours une composante linguistique puissante, car la première chose qu'un nouveau programmeur recherchera est une compréhension conceptuelle de ce qui se fait. En règle générale, plus vous vous éloignez du contexte dans lequel vous avez créé un programme, plus un style de programmation linguistique sera important pour garantir que vos hypothèses et vos concepts ne seront pas mal compris par la prochaine personne qui tentera de comprendre votre code. .

Le deuxième style, plus concis, est la programmation orientée vers les mathématiques. Ce style de raisonnement repose également sur le langage, puisque, par exemple, les variables sont analogues aux noms et les opérateurs aux verbes. Cependant, le raisonnement mathématique exploite la capacité étonnante et hautement parallèle de notre cerveau à effectuer des transformations spatiales complexes sur des objets situés dans notre champ de vision. En représentant les noms et les verbes sous forme de symboles compacts et distinctifs pouvant être organisés en objets imaginaires bien structurés (équations), nous pouvons ensuite utiliser nos capacités visuelles hautement parallèles pour effectuer des rotations, remplacements, mouvements, inversions et autres transformations de ces images imaginaires. objets. Le résultat est une énorme amplification du nombre de cas que nous pouvons traiter en même temps, chaque symbole pouvant représenter des classes entières d'objets étroitement liés.

Notez que pour appliquer efficacement le traitement visuel, vous devez garder votre objet imaginaire aussi semblable que possible en taille et en fonctionnalités à un objet réel. Si le champ de vision requis devient trop large ou si les symboles ne peuvent pas être utilisés comme des marques mobiles sur un objet, ou si vous devez «lire des lettres» et les convertir en mots, la capacité à effectuer des transformations complexes de manière fiable tombera. rapidement même pour un très bon mathématicien.

C'est pourquoi les gens plongés profondément dans le style de programmation mathématique peuvent devenir sérieusement malheureux si une équation est étalée et exprimée dans ce qu'ils appellent un style linguistique «verbeux». Ce n'est pas parce que l'équation a été modifiée de manière significative, mais parce que la diffuser de cette façon peut rendre presque impossible l'application d'un style visuel de compréhension. Cependant, dans le même temps, un nouveau programmeur qui n'est pas du tout familiarisé avec les symboles courts préférera probablement une version plus détaillée qui fournira plus d'informations linguistiques pour comprendre initialement le fonctionnement du code.

Alors, que recommanderais-je?

Utilisez les deux styles, mais faites bien attention à la raison pour laquelle vous utilisez chaque style.

Par exemple, tout ce qui a une chance d'interagir avec le monde extérieur devrait être intensément détaillé à un certain niveau, ne serait-ce que sous la forme de commentaires en ligne mélangés avec le code, et devrait également inclure des contrôles automatisés pour un usage correct. Les notations cryptiques et en particulier incomplètement définies n'ont aucune activité dans de telles interfaces, car il est presque certain qu'elles seront mal comprises à un moment donné. La perte de l’Obiter climatique Mars en 1999, due à une impossibilité de déterminer si les unités d’interface logicielles étaient exprimées en livres ou en newtons, est un exemple particulièrement frappant du danger de s’appuyer trop simplement sur des nombres bruts aux interfaces logicielles ou matérielles.

Inversement, toute forme de programmation profondément algorithmique et mathématique est un bon candidat, une programmation succincte qui prend en charge le style de raisonnement mathématique. Si une personne nouvelle doit conserver un tel code, il serait généralement préférable qu'elle apprenne les notations mathématiques au lieu d'essayer de transformer le code en des formes plus verbeuses. Il devrait bien sûr y avoir à tout moment une documentation facilement disponible pour expliquer les parties mathématiques du code disponible pour ces développeurs, mais il s’agit d’une question distincte.

Entre ces extrêmes, il existe de nombreux cas où le programmeur dispose d'une discrétion considérable. Je suggérerais de regarder comment le code sera maintenu à long terme et d'essayer de répondre aux besoins des personnes les plus susceptibles de maintenir le code à long terme.

Un certain nombre de personnes ont fait allusion à quelque chose qui, à mon avis, devrait probablement être déclaré explicitement.

La verbosité a tendance à favoriser la compréhension au niveau microscopique - elle conduit généralement à une déclaration individuelle facile à lire et à comprendre. La verbosité tend également à réduire le degré de familiarité avec le langage nécessaire pour la comprendre (au moins dans une certaine mesure). Les langages les plus verbeux (par exemple, COBOL) peuvent être au moins quelque peu lisibles, même par des non-programmeurs complets.

La concision tend au contraire: elle aide à la compréhension au niveau macroscopique, en particulier pour les programmeurs ayant une connaissance intime de cette langue. Dans le même temps, le manque de familiarité avec ce langage spécifique peut empêcher une compréhension même rudimentaire, même de la part de programmeurs ayant une expérience assez considérable.

En tant que telle, la lisibilité varie considérablement en fonction du public cible. D'une part, considérons qu'un projet volumineux et complexe est écrit et entretenu par des personnes travaillant presque exclusivement sur ce projet, dont la plupart ont une expérience et une formation considérables en matière de programmation (par exemple, de nombreux doctorats). Cela aura tendance à favoriser un langage plus concis.

À plus ou moins l'extrême opposé, considérons un projet considérablement plus simple (bien que probablement encore assez volumineux) et maintenu principalement par des personnes vraiment spécialisées dans les activités associées au logiciel, plutôt que dans le logiciel lui-même. Cela favorisera presque certainement un langage beaucoup plus bavard.

Plutôt que d’aller dans un livre technique, je reviens aux éléments de style * de Strunk et White. Le concept sous-jacent est "Soyez précis" et "Ne dites pas plus que nécessaire." Tout le reste est un commentaire.

Appliqué à la programmation, il s’agit d’être très précis mais de ne pas avoir de peluches inutiles. Le fluff supplémentaire peut être de la syntaxe, mais il peut également s'agir de plus de mots que nécessaire pour transmettre le sens. (Bien sûr, pas trop peu pour permettre l'ambiguïté non plus)

• Je cite la version originale car c'est la plus concise. :-)

En fin de compte, tout ce qui est "différent" fera hurler les gens. Je suis à l'aise avec la syntaxe de style C et donc d'accord avec d'autres langages qui partagent une syntaxe similaire (C ++, Java, C #). J'ai donc tendance à privilégier ce style particulier.

Les langues ont tendance à trouver un équilibre entre suffisamment descriptif et non verbeux.

Perl est un exemple où vous pouvez écrire du code très concis. Pour les non-initiés, le code écrit par un ninja Perl n’est rien de moins que de la magie.

COBOL est un exemple de trop prolixe.

J'ai lu quelque part quelque part qu'une grande partie du débat prolixe venait des nouveaux programmeurs par rapport aux anciens. L'analogie utilisée est que lorsque nous apprenons quelque chose de nouveau, nous nous racontons une "histoire" pour la traverser (pensez à quand vous avez appris l'algèbre en HS). Au fur et à mesure que nous acquérons de l'expérience, nous allons au-delà du besoin d'une histoire expliquant les composants individuels et nous en comprenons davantage. Notre code devient plus dense et plus concis, avec des commentaires expliquant uniquement les éléments nécessaires, au lieu de répéter ce que le code dit.

J'ai trouvé que c'était vrai entre moi et un collègue. Elle écrit du code avec beaucoup de commentaires expliquant ce que sont les lignes de code et beaucoup d'espace. Si je le lis, je constate que je ne peux insérer que quelques lignes de code sur un écran à cause de cela. Cela facilite beaucoup la compréhension de chaque ligne, mais il est beaucoup plus difficile d’exécuter toute la fonction.

J'ai tendance à écrire du code sans espaces ni commentaires supplémentaires. Cela facilite la visualisation de l'ensemble, mais vous devez pouvoir simplement "obtenir" les "mots" de code individuels. Si vous essayez de lire cette réponse avec chaque mot sur sa propre ligne, avec beaucoup d'espaces / commentaires / extra verbiage, il sera beaucoup plus facile de comprendre chaque mot, mais beaucoup plus difficile de comprendre le tout.

Einstein a eu raison: "Rendez les choses aussi simples que possible, mais pas plus simples."

Ceci s’applique également au code. Si vous pouvez simplifier le code en supprimant les éléments répétitifs et inutilement verbeux, c'est une bonne chose.

De plus, certaines études de cas suggèrent que la productivité du programmeur mesurée en lignes de code est plus ou moins une constante. Il en va de même du nombre de bugs par LOC. Ainsi, le passage à un langage qui vous permet d’en faire plus par ligne de code peut être considéré comme une amélioration de la productivité, si toutes choses égales par ailleurs.

Cela étant dit, cette industrie a tendance à trop concevoir et à compliquer des choses qui devraient être simples. Des choses simples, telles que le remplissage des informations de contact dans une base de données relationnelle. J'ai vu des solutions ridiculement compliquées et peu judicieuses ( MDA contre la toux ) pour résoudre ce problème particulier. Des langages tels que Scala et Ruby sont de bons exemples d'outils puissants qui, entre les mains de certaines personnes, génèrent un code inintelligible, trop compliqué et peu gérable. Ce n’est pas parce que vous pouvez utiliser plusieurs niveaux d’indirection en quelques touches seulement que vous devez casser tous les clous en vue avec ce marteau.

Lorsqu'il est utilisé correctement, vous obtenez un code propre, court, facile à comprendre. Lorsqu'il est mal utilisé, il est préférable de limiter l'individu en question à l'utilisation de Visual Basic ou d'un langage similaire limité pour éviter des dommages supplémentaires.

La vraie compétence consiste à faire des choses complexes de manière simple, pas à faire des choses simples de manière compliquée.

Quelque chose n'a été touché par la quantité de code que vous pouvez insérer dans un seul écran. Cela aide pour plusieurs raisons:

• Moins de défilement dans les deux sens lorsque vous travaillez (ou lisez) plusieurs fonctions dans un seul fichier.
• Moins de défilement horizontal (arrêter la lecture, cliquer et faire glisser la barre de défilement, arrêter la lecture, cliquer et faire glisser la barre de défilement ...).
• Analyse plus rapide, car la syntaxe est moins inutile pour vous permettre de trouver ce que vous voulez.

Parce que plus de code signifie plus de temps de développement et plus de bugs.

Si vous écrivez 100 lignes de codes plutôt que 300 lignes de codes. Cela signifie que vous aurez besoin d’un tiers de temps de développement et d’un tiers de bugs potentiels que vous pourriez rencontrer.

Dans la plupart des cas, vous devez concilier efficacité et concision, car écrire moins de codes signifie que la machine doit faire plus de choses et que l'efficacité en sera diminuée.

Habituellement, les gens préfèrent les langues lisibles / verbeuses aux langues cryptiques / laconiques. Cependant, je pense que la plupart des gens ont assimilé "verbosité" avec "fouillis", qui ne sont pas la même chose.

Par exemple: while(<>){print if($.==2 || $& && !$x++); $.=0 if (/^--+$/)}

est une déclaration très laconique. Il contient tout ce que vous voulez savoir. Cependant, en raison de sa rareté, il est difficile à comprendre. Par ailleurs, une version légèrement plus détaillée du même programme serait assez simple à comprendre car plus lisible. Ce n'est bien sûr pas une propriété de la langue en soi, mais certaines langues ont tendance à être plus verbeuses tandis que d'autres ont tendance à être plus concises dans leur manière de programmer.

A l'autre extrême de verbosité, est http://en.wikipedia.org/wiki/Literate_programming , que je considère comme un concept assez intéressant.

Un autre aspect est la "verbosité indésirable", également appelée "fouillis". Ce que vous devez ajouter pour des raisons techniques, le manque de sucre syntaxique, des API gonflées, etc.

Je pense qu'une syntaxe claire et intuitive est très importante. Il doit également être suffisamment détaillé pour faciliter la lecture. Des déclarations trop courtes contenant trop de logique peuvent souvent laisser plus de temps pour le déchiffrement que leurs homologues légèrement plus longues. D’un autre côté, un code gonflé inutile rempli de lignes standard pour faire quelque chose de tout simple est également une nuisance.

La verbosité étant une tendance à utiliser de grandes quantités de texte, et la concision à utiliser très peu de texte ...

La verbosité est mauvaise parce que:

1. il introduit plus de possibilité d'erreur typographique
2. cela rend plus difficile la lecture du code à l'écran ou sur papier, et / ou la saisie sur une carte perforée
   1. cela augmente les temps de débogage
   2. cela complique la compréhension du code pour la mise à niveau / la maintenance
   3. cela peut conduire à une duplication involontaire de code
3. cela augmente quelque peu la probabilité d'erreur de syntaxe
4. cela diminue la flexibilité de codage, en ce sens que la plupart des langages verbeux sont très structurés et n'ont pas plusieurs façons de dire la même chose.
5. il augmente les temps de codage et de compilation
6. cela peut prendre plus d'espace de stockage.

Un certain niveau de verbosité est essentiel pour la clarté, cependant ...

un niveau minimal de verbosité est bon pour les raisons suivantes:

1. il est plus facile pour l'homme de lire et d'attacher une valeur sémantique à un code purement symbolique
2. En nommant les variables et les fonctions, cela facilite le débogage, le portage et la maintenance du code
3. dans les opérations de langage de niveau de base et les mots-clés de langages complexes, il en résulte moins d'attributions d'opérations / mots-clés incorrects.

Parmi les merveilleux exemples de commandes trop laconiques pour de nombreuses personnes, on peut citer les anciennes bases BASIC de val(x$), str$(x)et chr$(x)... renvoyer un nombre à partir de sa représentation sous forme de chaîne, renvoyer une chaîne pour un nombre et renvoyer un seul caractère ayant la valeur ascii x en tant que chaîne.

Ou le pointeur C / C ++ et par les opérateurs de référence &et *par rapport au byrefmot clé BASIC . En C / C ++, je peux avoir une variable X et passer un pointeur sur cette variable, mais je dois me rappeler quel est le pointeur et quel est le "pointeur d'utilisation comme variable à laquelle il pointe"; en basic, je passe simplement la référence avec un mot clé byref dans l'appel de fonction, ce qui est plus clair, mais moins flexible:

def fn Foo(x byref as float) foo= (x += x+1)
...
Foo(x)

Dans ce code, le contenu de x est modifié en raison de l'indicateur byref. Certaines saveurs autorisent les appels externes à l'appel, d'autres dans leur définition, d'autres dans l'un ou l'autre.

La verbosité est importante pour que les programmeurs occasionnels puissent utiliser le symbolisme plus facilement. BASIC ou python sont plus lisibles par l'homme et plus verbeux que le C / C ++, et sont donc beaucoup plus utiles pour les programmeurs occasionnels; la rareté de C / C ++ le rend bien meilleur pour les programmeurs plus expérimentés, qui ont besoin de voir plus de code et de code plus complexe en même temps, mais qui ont dû apprendre les différentes conventions de structure symbolique. À l'autre extrémité se trouve APL, qui est presque illisible pour l'homme.

La clarté est un problème intimement lié: le code abrégé manque souvent de clarté et le code trop détaillé (comme dans AppleScript) peut l'être également. La familiarité avec un langage donné augmente la clarté du code laconique au sein de ce langage - un débutant, confronté au code C ++, ne sera probablement capable d’analyser que les formules, et même une grande partie du code fonctionnel BASIC ou Python est trop concise pour la compréhension, mais l’apple être perplexe, généralement, sans avoir recours aux dictionnaires de langue. Le moins clair que j'ai rencontré sans obscurcissement intentionnel est Inform 7 ...

Dans les temps anciens

Une autre considération importante dans le passé, mais qui n’est plus aussi importante pour le codeur amateur, est l’utilisation et l’espace de stockage. (Il est toujours essentiel au haut de gamme.) Gardant à l’esprit que de nombreuses langues ont été interprétées, en particulier les versions BASIC, et beaucoup d’autres compilées au moment de l’exécution, l’espace codé était important, en particulier lorsque les disques ne contenaient que 128 Ko, et les cartes perforées individuelles, 80B.

Plusieurs solutions existaient - la tokenization était extrêmement courante dans BASIC; les mots-clés de chaque langue ont été réduits à un mot de 1 ou 2 octets dans les 128 caractères supérieurs ou dans l'espace des caractères de contrôle. La tokénisation conduit également à la compilation de codes temporels (comme dans Inform et Z-Machine).

La compilation et la liaison de plusieurs objets ont également été utilisées pour contourner les limitations d’espace. Une section de code Pascal de 100 Ko pourrait être compilée avec seulement 5 Ko; en liant plusieurs fichiers compilés, il est possible de créer des applications volumineuses sans avoir accès à des disques de grand format (en se rappelant que 10 Mo est incroyablement volumineux et acheter une nouvelle voiture chère).

Cependant, des langages plus complexes ont introduit plus de code dans un bloc donné de disque et de bélier, et ont ainsi compilé de plus gros morceaux à la fois. Il ne faut pas oublier que les "mini-ordinateurs" du début des années 1970 n’avaient que 64 Ko de mémoire vive (le Honeywell 800 disposait d’une installation de base de 4 banques de 2048 mots de 8B chacune). APL et les langages symboliques similaires ont approché 1B par instruction plus ses opérandes, par rapport au beaucoup plus grand 3B-10B par instruction plus des opérandes. (C'était un cauchemar de taper sur des cartes perforées, d'autant plus que les symboles étaient essentiellement une police de caractères sur une boule de frappe, et que beaucoup de cardpunches n'avaient pas les symboles sur les touches ...)

De plus, n'oubliez pas que les cartes ne peuvent pas être effacées ... et de nombreux programmes ont été entrés sur des cartes. Bien que cela ne coûte pas cher individuellement, plus votre code peut être compressé sur la carte, moins vous en avez besoin, plus les programmes sont volumineux ou moins coûteux. Cela explique en partie le fait que BASIC concatène plusieurs instructions par ligne dans la plupart des versions - il a été introduit pour économiser sur les cartes perforées. (Ou bien, dit mon texte de programmation Vax Basic.) Bien que je n’ai pas programmé de lecteur de carte, j’ai perforé une carte pour un Honeywell 800 en FORTRAN, BASIC, APL et quelques autres langages hautement symboliques.

Comme pour tant d'autres choses, la réponse dépend de la définition concrète de "verbosité". Si la définition est telle que la verbosité implique la redondance, alors je dirais que c'est toujours mauvais. Notez qu'avec une telle définition, le programme Java hello world, souvent cité, ne serait pas qualifié de "verbeux", car il ne contient aucun élément redondant.

Les programmeurs ont tendance à aimer les langues avec un pouvoir expressif, car cela leur permet de coder des choses simples, qui doivent souvent être faites fréquemment, dans de petits morceaux de code. Les langages verbeux tendent à signifier que beaucoup, beaucoup de lignes de code doivent être utilisées pour faire la même chose encore et encore. Cependant, il peut y avoir quelque chose d'un prix à payer avec des langages expressifs car ils peuvent ne pas être aussi rapides à exécuter que des langages de haut niveau plus simples. Si je peux donner un exemple dans le contraste entre C et C ++. C ++ donne plus de pouvoir expressif aux auteurs de code - ils peuvent encapsuler l'idée d'objets réels dans des classes. Les programmeurs C peuvent réaliser les mêmes choses, mais ils ont le pouvoir expressif de la construction de classe pour les aider - ils doivent donc écrire du code plus long et plus compliqué (pour comprendre). Mais ce code pourrait bien être exécuté plus rapidement (bien que cela dépende fortement de la qualité du compilateur, etc.) car il n'utilise pas la "liaison tardive" de C ++ (c'est-à-dire le refactoring à l'exécution) pour exécuter le code. C n’exécute que le code compilé et lié, C ++ doit prendre une décision (dans certaines circonstances) sur les éléments de code à exécuter au moment de l’exécution.

Je pense qu’il existe une réponse à la question qui s’appuie sur une question plus fondamentale et théorique que la lisibilité et elle est liée à la théorie de l’information algorithmique fondée par Gregory Chaitin: http://en.wikipedia.org/wiki/Algorithmic_information_theory . En quelques mots, "le contenu informationnel d’une chaîne de caractères équivaut à la longueur de la représentation autonome la plus courte possible de cette chaîne", ce qui implique que le programme le plus court (notamment en termes de longueur lexicographique) résolve un problème de près correspond à la complexité intrinsèque du problème auquel il donne une solution et dépend donc plus de la nature du problème que de sa représentation.