Il existe quelques définitions du pouvoir au-delà de l'exhaustivité de Turing. Mark a cité ce que j'ai tendance à considérer comme «la définition de Paul Graham». C'est une assez bonne définition, avec un sérieux défaut: c'est faux. C'est théoriquement une très bonne définition du pouvoir du langage, mais vous savez ce qu'ils disent de la différence entre la théorie et la pratique ...
Si tout le monde était capable d'écrire du code parfait, non seulement parfaitement sans bogue mais également parfaitement à l'épreuve du temps, de manière cohérente, alors la définition de Paul Graham serait correcte. Mais ce n'est évidemment pas le cas. Dans le monde réel, la majorité du temps et des efforts consacrés à l'ingénierie logicielle n'est pas absorbée par la création initiale du produit, mais par la maintenance par la suite. Selon les statistiques que vous écoutez (et cela varie probablement beaucoup d'un projet à l'autre), la maintenance peut représenter entre 60% et 90% de l'effort total consacré à un programme.
La maintenance est souvent effectuée par des personnes autres que la personne qui a écrit le code au départ, et souvent des mois, voire des années après l'écriture initiale du code, ce qui signifie que même pour le codeur d'origine, il peut tout aussi bien être "le code d'autres personnes". point. Si vous voulez être productif pendant la maintenance, vous devez être en mesure de vérifier rapidement l'intention d'origine du code en le lisant.
Par conséquent, un langage plus puissant est celui qui facilite la lecture rapide du code , et non celui qui facilite l' écriture rapide du code . Il y a généralement une grande quantité de chevauchement entre les deux, mais les concepts sont souvent à contre-courant également, car la syntaxe laconique omettra souvent les détails qu'un compilateur / interprète est en mesure d'inférer beaucoup plus facilement qu'un programmeur de maintenance.
EDIT: Il y a un autre point important dans la description de la puissance d'une langue: la gamme de concepts que vous êtes en mesure d'exprimer et la facilité avec laquelle vous pouvez en toucher les deux extrémités. Paul Graham aime évaluer celui-ci sur le niveau d'abstraction que vous pouvez atteindre, mais ce n'est que la moitié. Toute langue qui impose une limite d'abstraction inférieure, en dessous de laquelle vous ne pouvez pas aller si nécessaire, est paralysée parce que les détails qui sont abstraits sont là pour une raison. C'est la différence entre un langage jouet facilement lisible comme COBOL et un langage puissant facilement lisible: COBOL n'a pas de pointeurs et n'a pas accès à l'assemblage en ligne, où vous pouvez exprimer n'importe quel calcul, même ceux auxquels COBOL n'est pas bien adapté.
COBOL n'est pas non plus particulièrement bon pour atteindre l'extrémité supérieure du spectre d'abstraction. Selon Wikipedia, il n'a «aucun type défini par l'utilisateur et aucune fonction définie par l'utilisateur», ce qui rend très difficile la création d'algorithmes et de structures de données.