Existem algumas definições de poder além da abrangência de Turing. Mark citou o que costumo pensar como "a definição de Paul Graham". É uma definição muito boa, com uma falha séria: está errada. Teoricamente, é uma definição muito boa do poder da linguagem, mas você sabe o que eles dizem sobre a diferença entre teoria e prática ...
Se todo mundo fosse capaz de escrever um código perfeito, não apenas perfeitamente livre de erros, mas também perfeitamente à prova de futuro, de forma consistente, a definição de Paul Graham estaria correta. Mas obviamente não é esse o caso. No mundo real, a maior parte do tempo e esforço dedicados à engenharia de software não é ocupada pela criação inicial do produto, mas pela manutenção posterior. Dependendo de quais estatísticas você escuta, (e provavelmente varia um pouco de projeto para projeto), a manutenção pode representar de 60% a 90% do esforço total que entra em um programa.
A manutenção geralmente é executada por outras pessoas que não a pessoa que escreveu o código inicialmente, e freqüentemente meses ou mesmo anos após a escrita inicial do código, o que significa que, mesmo para o codificador original, ele também pode ser o "código de outras pessoas". ponto. Se você deseja ser produtivo durante a manutenção, precisa verificar rapidamente a intenção original do código lendo-o.
Portanto, uma linguagem mais poderosa é aquela que facilita a leitura rápida do código , e não uma linguagem que facilita a gravação rápida do código . Tende a haver uma justa quantidade de sobreposições entre os dois, mas os conceitos também costumam ter objetivos diferentes, pois a sintaxe concisa geralmente omite os detalhes que um compilador / intérprete é capaz de deduzir com muito mais facilidade do que um programador de manutenção.
EDIT: Há outro ponto importante na descrição do poder de uma linguagem: a variedade de conceitos que você é capaz de expressar e a facilidade com que consegue atingir as duas extremidades. Paul Graham gosta de avaliar este em qual nível de abstração você pode alcançar, mas isso é apenas metade. Qualquer linguagem que imponha um limite inferior de abstração, abaixo do qual você não pode ir quando necessário, é prejudicada porque os detalhes que estão sendo abstraídos estão lá por uma razão. Essa é a diferença entre uma linguagem de brinquedo de fácil leitura, como COBOL, e uma linguagem poderosa de fácil leitura: COBOL não tem ponteiros nem acesso a montagem em linha, onde é possível expressar qualquer cálculo, mesmo aqueles aos quais o COBOL não é adequado.
O COBOL também não é particularmente bom em atingir o limite máximo do espectro de abstração. Segundo a Wikipedia, "não possui tipos definidos pelo usuário nem funções definidas pelo usuário", o que dificulta a criação de algoritmos e estruturas de dados.