Es gibt einige Definitionen von Macht, die über die Vollständigkeit von Turing hinausgehen. Mark zitierte, was ich tendenziell als "die Paul Graham-Definition" betrachte. Es ist eine ziemlich gute Definition mit einem schwerwiegenden Fehler: Es ist falsch. Es ist theoretisch eine sehr gute Definition der Sprachkraft, aber Sie wissen, was sie über den Unterschied zwischen Theorie und Praxis sagen ...
Wenn jeder in der Lage wäre, perfekten Code zu schreiben, der nicht nur fehlerfrei, sondern auch absolut zukunftssicher ist, dann wäre die Definition von Paul Graham korrekt. Das ist aber offensichtlich nicht der Fall. In der Praxis wird der größte Teil der Zeit und des Aufwands für das Software-Engineering nicht durch die erstmalige Erstellung des Produkts, sondern durch die anschließende Wartung in Anspruch genommen. Abhängig davon, welche Statistiken Sie anhören (und dies ist wahrscheinlich von Projekt zu Projekt sehr unterschiedlich), kann die Wartung zwischen 60% und 90% des Gesamtaufwands eines Programms ausmachen.
Die Wartung wird häufig von anderen Personen als der Person durchgeführt, die den Code ursprünglich geschrieben hat, und häufig Monate oder sogar Jahre nach dem ersten Schreiben des Codes. Dies bedeutet, dass es sich auch für den ursprünglichen Codierer möglicherweise um den Code anderer Personen handelt Punkt. Wenn Sie während der Wartung produktiv sein möchten, müssen Sie in der Lage sein, die ursprüngliche Absicht des Codes durch Lesen schnell festzustellen.
Daher ist eine leistungsfähigere Sprache eine Sprache, die das schnelle Lesen von Code erleichtert, und keine, die das schnelle Schreiben von Code erleichtert . Es besteht tendenziell eine gewisse Überschneidung zwischen den beiden Konzepten, aber die Konzepte sind häufig auch widersprüchlich, da in der knappen Syntax häufig Details ausgelassen werden, auf die ein Compiler / Interpreter viel einfacher schließen kann als ein Wartungsprogrammierer.
BEARBEITEN: Es gibt einen weiteren wichtigen Punkt bei der Beschreibung der Kraft einer Sprache: die Bandbreite der Konzepte, die Sie ausdrücken können, und wie leicht Sie beide Enden erreichen können. Paul Graham bewertet diesen gerne danach, wie hoch das Abstraktionsniveau sein kann, aber das ist nur die Hälfte davon. Jede Sprache, die eine niedrigere Abstraktionsgrenze auferlegt, unter die Sie bei Bedarf nicht gehen können, ist verkrüppelt, weil die Details, die weg abstrahiert werden, aus einem bestimmten Grund vorhanden sind. Dies ist der Unterschied zwischen einer leicht lesbaren Spielzeugsprache wie COBOL und einer leicht lesbaren, leistungsstarken Sprache: COBOL verfügt über keine Zeiger und keinen Zugriff auf Inline-Assemblys, in denen Sie Berechnungen ausdrücken können, auch wenn diese für COBOL nicht gut geeignet sind.
COBOL ist auch nicht besonders gut darin, das obere Ende des Abstraktionsspektrums zu erreichen. Laut Wikipedia gibt es "keine benutzerdefinierten Typen und keine benutzerdefinierten Funktionen", was es sehr schwierig macht, Algorithmen und Datenstrukturen zu erstellen.