Por que Erlang é a única verdadeira linguagem de computador?

Oleksandr Kaleniuk 2 de setembro de 2017

Há uma versão atualizada deste post em wordsandbuttons.online : https://wordsandbuttons.online/why_erlang_is_among_the_few_true_computer_languages.html

Imagine que há algo errado com a pressão da água em sua casa. Você tem que ligar para o serviço de encanador. Dizem que há um cara, que é honesto e capaz, e tem um Ph. D. em encanamento, mas … Ele não fala bem inglês. Ele veio do Tajiquistão e só fala fluentemente tadjique. Mas acontece que você estudou tadjique na faculdade, então você diz que eles mandam o cara imediatamente.

Quando ele chega, você descreve o problema (em tadjique) e ele começa a trabalhar. Logo ele encontra o problema e tenta denunciá-lo para você, aparentemente esperando por uma reação. Mas por alguma razão ele não usa tajik para denunciá-lo, ele usa o inglês. Que … Ele realmente não sabe. Se você responder (em tadjique) que você não entende, ele não irá mudar para tadjique; ele só repetirá a mesma frase mais alto.

O que não ajuda a construir um diálogo.

Ninguém sabe por que ele constantemente escolhe responder na língua em que ele não fala bem, em vez do seu. Que você faz. É absurdamente irritante, mas é assim que as coisas funcionam. É como eles sempre foram. O que ele fala é basicamente um mau inglês misturado com jargões profissionais e obscenidades tadjiques. Parece algo como isto:

Na função 'int main ()': 19:16: erro: não pode ligar 'std :: ostream {aka std :: basic_ostream <char>}' lvalue para 'std :: basic_ostream <char> &&' Em arquivo incluído de / usr / include / c ++ / 4.9 / iostream: 39: 0, de 2: /usr/include/c++/4.9/ostream:602:5: note: inicializando o argumento 1 de 'std :: basic_ostream <_CharT, _Traits> & std :: operador << (std :: basic_ostream <_CharT, _Traits> &&, const _Tp &) [com _CharT = char; _Traits = std :: char_traits <char>; _Tp = Element] 'operator << (basic_ostream <_CharT, _Traits> && __os, const _Tp & __x)

[CC BY-SA 2.5 ( http://creativecommons.org/licenses/by-sa/2.5 )], via Wikimedia Commons

Ok, não é mais sobre encanamento. Na verdade, nunca foi sobre encanamento. É sobre como nos comunicamos com a máquina. Uma linguagem de programação é algo que usamos para dizer o que fazer, mas a máquina tenta falar em inglês quando algo está errado. Os computadores não falam inglês bem, embora sejam bons em processar idiomas formais. E presumivelmente, aquele que escreve em linguagem formal deve ser capaz de ler de volta sem nenhum problema. Não seria melhor se o compilador ou o intérprete respondesse na mesma linguagem que recebe seus comandos?

De alguma forma, a idéia parece não ser tão agradável sem um encanador tadjique.

Até agora, a única linguagem que conheço que reporta erros na mesma linguagem em que você escreve código é Erlang. Se você sabe mais, por favor me avise na seção de comentários abaixo.

Aqui está um exemplo simples de " Programação Erlang ":

 1> Ponto = {ponto, 10, 45}. 
2> {ponto, C, C} = ponto.
= ERROR REPORT ==== 28-Out-2006 :: 17: 17: 00 ===
Erro no processo <0.32.0> com valor de saída:
{{badmatch, {point, 10,45}}, [{erl_eval, expr, 3}]}

A string em negrito é a mensagem de erro, o resto é apenas um preâmbulo do interpretador. De fato, não é totalmente conveniente para o leitor casual. Você tem que saber Erlang para ler seus erros. Mas como você ainda precisa saber o Erlang para escrever o código que os causa, tudo bem.

As alternativas são muito piores. Com mensagens de erro informais e não padronizadas, você teria que conhecer não apenas a linguagem de programação em si, mas também seu sistema de mensagens de erro Pidgin. Todo praticante de C ++ pode confirmar que a leitura de mensagens STL é uma arte por si só. É preciso conhecimento, paciência, determinação e, ocasionalmente, uma bola de cristal para construir uma compreensão firme de um problema relatado.

Por exemplo, a mensagem de erro acima lê como "desculpe, não consigo imprimir um element para você, porque seu tipo não tem um operador << ".

Normalmente, a linguagem é algo em que você pode construir um diálogo. Linguagens de programação são uma isenção infeliz. Historicamente, era mais importante dizer a um computador o que fazer do que o contrário. Quando você escreve um pequeno programa single-threaded, você pode esperar que não haja erros, então você não precisa realmente de um relatório. O relatório de erros sempre foi visto como um recurso auxiliar.

Erlang, no entanto, visa construir sistemas distribuídos altamente complexos. Erros não só são mais prováveis de acontecer, como também são inerentes à natureza do domínio. Tudo o que poderia dar errado acabará. E é melhor você ter uma linguagem de reportagem decente para isso.

O simples fato de você poder ter um diálogo, ou seja, escrever código e receber erros na mesma linguagem, faz do Erlang não apenas programação, mas uma verdadeira linguagem de computador.