Есть несколько определений силы за пределами полноты по Тьюрингу. Марк привел то, что я склонен считать «определением Пола Грэма». Это довольно хорошее определение с одним серьезным недостатком: это неправильно. Это теоретически очень хорошее определение языковой силы, но вы знаете, что они говорят о разнице между теорией и практикой ...
Если бы каждый был способен писать идеальный код, не только идеально безошибочный, но и идеально ориентированный на будущее, то определение Пола Грэма было бы правильным. Но это явно не тот случай. В реальном мире большая часть времени и усилий, затрачиваемых на разработку программного обеспечения, занимает не первоначальное создание продукта, а его последующее обслуживание. В зависимости от того, какую статистику вы слушаете (и она, вероятно, сильно отличается от проекта к проекту), обслуживание может составлять от 60% до 90% от общего объема усилий, затрачиваемых на программу.
Техническое обслуживание часто выполняется людьми, отличными от того, кто изначально написал код, и часто через месяцы или даже годы после первоначального написания кода, что означает, что даже для оригинального кодировщика это может быть также «чужой код» точка. Если вы хотите работать продуктивно во время обслуживания, вы должны быть в состоянии быстро определить первоначальное назначение кода, прочитав его.
Следовательно, более мощный язык - это язык, который облегчает быстрое чтение кода , а не тот, который облегчает быстрое написание кода . Как правило, между этими двумя понятиями существует значительное совпадение, но понятия также часто имеют перекрестные цели, поскольку в кратком синтаксисе часто пропускаются детали, которые компилятор / интерпретатор может вывести гораздо проще, чем программист по обслуживанию.
РЕДАКТИРОВАТЬ: есть еще один важный момент в описании силы языка: диапазон понятий, которые вы можете выразить, и как легко вы можете достичь обоих целей. Пол Грэхам любит оценивать этот уровень, насколько высоко вы можете достичь уровня абстракции, но это только половина. Любой язык, который устанавливает нижний предел абстракции, ниже которого вы не можете перейти, когда это необходимо, ограничен, потому что детали, которые абстрагируются, существуют по причине. В этом разница между легко читаемым игрушечным языком, таким как COBOL, и легко читаемым мощным языком: у COBOL нет указателей и нет доступа к встроенной сборке, где вы можете выражать любые вычисления, даже те, для которых COBOL плохо подходит.
COBOL также не особенно хорош в достижении высокого уровня спектра абстракции. Согласно Википедии, в ней нет «пользовательских типов и пользовательских функций», что сильно затрудняет создание алгоритмов и структур данных.