As linguagens de programação estão se tornando mais semelhantes às linguagens naturais?

Podemos estudar linguagens de programação no contexto da linguística? As linguagens de programação evoluem naturalmente de maneira semelhante às linguagens naturais?

Embora a racionalidade total e a consistência matemática sejam essenciais para as linguagens de programação, ainda há a necessidade (especialmente as linguagens modernas) de torná-las legíveis e confortáveis ​​para os seres humanos.

As linguagens de programação estão evoluindo para se tornarem mais linguísticas e, portanto, mais naturais? Por exemplo, código de máquina, cartões perfurados e linguagens assembly deram lugar a linguagens mais legíveis como Ruby e Python etc.

Quando digo que as linguagens de computador estão se tornando mais naturais, não quero dizer que elas contenham mais 'palavras que temos em inglês', quero dizer que elas parecem se tornar mais como uma linguagem natural, em termos de complexidade da gramática e capacidade de expressar significado (por exemplo, ser capaz de descrever eloquentemente uma consulta de um banco de dados de maneira racional e humana compreensível).

O que vocês acham? As linguagens de programação estão se tornando mais parecidas com as línguas naturais e, assim, se tornando aplicáveis ​​às leis da Linguística?

Ou talvez as línguas vivam em um espectro, onde por um lado você tem as linguagens racionais extremas e, por outro, a mais criativa. Talvez a programação e as linguagens naturais sejam idênticas e ambas apenas se encontrem nesse espectro de linguagem (sua única diferença, talvez seja a 'coisa' à qual estão tentando dar sentido).

Existe uma conexão entre a separação (efeito Babel Tower) de linguagens humanas e de idiomas de computadores? Eles se tornam mais diversos pelas mesmas razões (isto é, para resolver problemas diferentes em sistemas de computadores / sistemas de cultura em constante evolução etc.)?

Não, realmente não. As linguagens de programação tornaram-se mais parecidas com as línguas naturais apenas no sentido de "palavras que temos em inglês" ( sic ).

Uma característica fundamental das linguagens de programação é que elas não são ambíguas. Quando você escreve um programa e o executa, ele tem um significado bem definido, que é o seu comportamento. Se você deseja escrever um programa que funcione conforme o esperado (um objetivo difícil), é importante que o comportamento¹ do programa seja o mais previsível possível. As linguagens de programação não fizeram muita diferença na grande diferença em relação às linguagens naturais.

Por outro lado, tem havido trabalho para colmatar a lacuna do outro lado: analisar linguagens naturais com as mesmas ferramentas que linguagens de programação. Este campo é chamado processamento de linguagem natural . Essas abordagens foram praticamente descartadas em favor do aprendizado de máquina . Vou citar uma passagem no artigo da Wikipedia que é diretamente relevante aqui:

Até a década de 1980, a maioria dos sistemas de PNL era baseada em conjuntos complexos de regras escritas à mão. A partir do final dos anos 80, no entanto, houve uma revolução na PNL com a introdução de algoritmos de aprendizado de máquina para processamento de linguagem. Isso ocorreu devido ao aumento constante do poder computacional resultante da Lei de Moore e à diminuição gradual do domínio das teorias da linguística chomskyana (por exemplo, gramática transformacional), cujos fundamentos teóricos desencorajaram o tipo de linguística corpus subjacente à abordagem de aprendizado de máquina para processamento de linguagem.

Uma maneira pela qual a programação está evoluindo é que, ao projetar sistemas cada vez maiores, o código fonte nem sempre é uma boa maneira de entendê-los. Por exemplo, uma CPU Intel é um dos objetos mais complexos já criados pelo Man, e seu "código-fonte" não é apenas uma coleção de arquivos de texto, longe disso. Mas o design completo também não está evoluindo para algo parecido com a linguagem humana. Não sei quais são as ferramentas ou metáforas cognitivas apropriadas aqui e acho que ninguém sabe ainda; pergunte novamente em alguns séculos.

¹ _{Ou melhor, o conjunto de comportamentos possíveis anotados com as circunstâncias nas quais eles surgem, mas isso inclui apenas uma etapa de indireção na modelagem, portanto, isso não é realmente relevante aqui.}

As linguagens de computador tendem a se dar bem com a concisão e a precisão, um pouco como a notação matemática, que não mostrou nenhuma inclinação particular a evoluir para a linguagem natural (que eu conheço) nos últimos milhares de anos.

Duvido também que, se você se comunicasse com seu bebê exclusivamente em Haskell nos primeiros anos de sua vida, ele desenvolveria fluência na linguagem natural. Então, acho que há um contraste bastante nítido entre as linguagens natural e a computador.

Talvez uma disseminação mais ampla de técnicas de construção de linguagem tenha melhorado a "naturalidade" um pouco ao longo do tempo, suponho, uma vez que os programadores "votam com firmeza", usando linguagens que lhes parecem mais fáceis e o número de pessoas capazes de criar idiomas aumentou mais. profissionais e ferramentas melhores, mas esse é um pequeno efeito em torno das bordas e não representa uma transformação fundamental das linguagens de programação em humanas.

Um estudo de caso interessante nessa área é Perl vs Ruby (e Python ). O Perl é uma linguagem de script desenvolvida no início dos anos 90, que adicionou muita capacidade em comparação com as linguagens de script anteriores baseadas em Unix (por exemplo, bash). o autor Larry Wall está registrado, dizendo que sua formação em linguística inspirou algumas das características da linguagem.

no entanto, Perl tem uma sintaxe incômoda e muitos casos especiais que tornam o idioma um pouco parecido com o inglês em todas as suas sutis idiossincrasias, inspirando vários níveis de crítica . linguagens de script posteriores como Ruby e Python, desenvolvidas por cientistas da computação, têm muito mais consistência em sua sintaxe. o principal problema é que a linguagem natural tem grandes quantidades de ambiguidade (isso é estudado no campo da lingüística). Portanto, a linguagem natural terá um lugar fundamental nas futuras interfaces homem-computador como a Siri, mas essas interfaces estarão inerentemente sujeitas a problemas de ambiguidade.

então, aqui está um caso em que a evolução das linguagens de computador se afastou de uma idéia de linguagem natural. além disso, a história geral das linguagens de programação de computadores é que elas foram desenvolvidas e alteradas para remover a ambiguidade (que é altamente inerente à linguagem natural). isso não foi entendido no início da história dos compiladores (por exemplo, possivelmente na década de 1970) e, por exemplo, versões anteriores da linguagem Fortran tinham declarações com significados ambíguos que dependiam da implementação do compilador. algumas das teorias da linguagem CS relacionadas à análise foram desenvolvidas parcialmente em resposta à descoberta de ambiguidade na análise de linguagem.

A linguagem de máquina é muito precisa, enquanto um texto escrito por humanos geralmente pode ser interpretado de várias maneiras diferentes (alguns textos poéticos, por exemplo).

O que é cada vez mais evoluído é a correspondência de padrões, por exemplo, quando você escreve algum código feio, um compilador pode ajudá-lo a propor várias soluções possíveis e depois lançar algum aviso ou erro que pode ajudá-lo a se exprimir. (com base em padrões de código comuns, por exemplo)

Há pesquisas específicas sobre padrões de interação / design, mesmo T9 e SWYPE são reconhecedores de padrões que ajudam muito você (programas que gravam sua voz e a convertem em texto também são reconhecedores de padrões).

É claro que um programa é baseado em mecanismos precisos, portanto você precisa de linguagens precisas (não naturais), enquanto uma simples pesquisa na web no google é muito natural, basta digitar poucas palavras e obter o que deseja.

Cada tarefa e objetivo diferentes tem seu próprio idioma, não é uma simples "evolução de idioma único"; há muito mais idiomas. Tarefas precisas precisam de idiomas precisos e tarefas relaxadas requerem idiomas relaxados

Você pode escrever a mesma parte do código C e compilá-la com vários compiladores diferentes e (a menos que algum compilador esteja com problemas), o resultado do código será o mesmo, mesmo que um conjunto diferente seja gerado, enquanto que para uma pesquisa na web for feita a mesma palavras-chave para diferentes mecanismos de pesquisa fornece resultados diferentes.

Alguns anos atrás, meu filho mais velho e eu desenvolvemos um sistema de programação e desenvolvimento em inglês comum, com o interesse de responder às seguintes perguntas:

1. Os programas de baixo nível (como compiladores) podem ser escritos de maneira conveniente e eficiente em idiomas de alto nível (como o inglês)?

2. As linguagens naturais podem ser analisadas de maneira relativamente "superficial" e ainda fornecer um ambiente estável o suficiente para a programação produtiva?

3. É mais fácil programar quando você não precisa traduzir seus pensamentos no idioma natural em uma sintaxe alternativa?

Agora podemos responder a cada uma dessas três perguntas, por experiência direta, com um retumbante "Sim".

Nosso analisador opera, pensamos, algo como o cérebro humano. Considerar. Um pai diz ao filho bebê:

"Quer chupar essa garrafa, rapaz?"

E o garoto ouve,

"blá, blá, SUGA, blá, blá, GARRAFA, blá, blá."

Mas ele responde adequadamente porque tem uma "imagem" de uma garrafa no lado direito da cabeça conectada à palavra "garrafa" no lado esquerdo e uma "habilidade" preexistente próxima à parte de trás do pescoço conectada à termo "chupar". Em outras palavras, o garoto combina o que pode com as imagens (tipos) e habilidades (rotinas) que acumulou e simplesmente desconsidera o resto. Nosso compilador faz a mesma coisa, com novas imagens (tipos) e habilidades (rotinas) sendo definidas - não por nós, mas - pelo programador, enquanto ele escreve o novo código do aplicativo.

Uma definição de tipo típica se parece com isso:

Um polígono é uma coisa com alguns vértices.

Internamente, o nome "polígono" agora está associado a um tipo de estrutura alocada dinamicamente que contém uma lista de vértices duplamente vinculada. "Vértice" é definido em outro lugar (antes ou depois dessa definição) de maneira semelhante; o plural é automaticamente entendido.

Uma rotina típica é assim:

Para anexar uma coordenada x e coordenada ay a um polígono: Crie um vértice considerando x e y. Anexe o vértice aos vértices do polígono.

Observe que nomes formais (nomes próprios) não são necessários para parâmetros e variáveis. Acreditamos que este é um insight importante. Minha cadeira e mesa do mundo real nunca (em conversas normais) são chamadas de "c" ou "minhaTabela" - refiro-me a elas simplesmente como "a cadeira" e "a mesa". Da mesma forma aqui: "o vértice" e "o polígono" são os nomes naturais para essas coisas.

Observe também que os espaços são permitidos na rotina e nos "nomes" variáveis ​​(como "x coord"). Este é o século 21, sim? E que "apelidos" também são permitidos (como "x" para "x coord"). E que os possessivos ("vértices do polígono") são usados ​​de maneira muito natural para fazer referência a "campos" dentro de "registros".

Observe também que a palavra "dado" poderia estar "usando" ou "com" ou qualquer outro equivalente, já que nossa análise superficial se concentra nas figuras (tipos) e nas habilidades (rotinas) necessárias para a compreensão e ignora tanto quanto possível, o resto.

No nível mais baixo, as coisas são assim:

Para adicionar um número a outro número: Intel $ 8B85080000008B008B9D0C0000000103.

Observe que, neste caso, temos os idiomas mais alto e mais baixo - inglês e código de máquina (embora em hexadecimal) - em uma única rotina. A idéia aqui é que (como um livro típico de matemática) um programa deve ser escrito principalmente em uma linguagem natural, com trechos apropriados em sintaxes mais convenientes, conforme necessário (e somente como).

Você pode obter nosso sistema de desenvolvimento aqui: www.osmosian.com/cal-3040.zip. É um pequeno programa do Windows, com menos de um megabyte de tamanho. Se você começar com o PDF no diretório "documentation", antes de dez páginas, recompilará o shebang inteiro (em menos de três segundos em uma máquina de última geração do Walmart).

Perguntas e comentários devem ser enviados para gerry.rzeppa@pobox.com

A separação das línguas humanas vem da evolução (darwiniana?) Em comunidades isoladas. A separação de linguagens de programação vem de variações na necessidade técnica, ideologia técnica, de mudanças no entendimento técnico e teórico, de mudanças na nossa capacidade técnica de implementar. É um processo um pouco mais consciente, eu acho.

As linguagens de computador poderiam ser mais parecidas com as línguas naturais? Provavelmente um pouco, até certo ponto. Eu acho que uma grande parte da complexidade da linguagem natural resulta de uma variedade de fenômenos de evolução simultâneos que não têm motivos para produzir um resultado consistente a qualquer momento, mesmo que seja provável que inconsistências antigas sejam eliminadas progressivamente enquanto uma nova aparece . Não sou especialista em linguística diacrônica. Mas queremos esse tipo de complexidade nas linguagens de programação.

A questão da ambiguidade é importante, mas não como afirma a maioria das pessoas. Uma linguagem é um meio de comunicação, e deve ser analisada no contexto dessa comunicação (homem-homem, homem-máquina, ambos, entre lugares ou entre tempos, ... para dizer um pouco simplista). O que importa não é se você pode fazer apenas declarações não ambíguas no idioma, mas se você sempre pode garantir que a comunicação seja inequívoca no contexto pretendido. Existe uma linguagem de programação bem conhecida e amplamente usada, que permite escrever programas ambíguos (bem, sim, mas eu não vejo as últimas versões há algum tempo). Nesse caso, o compilador é inteligente o suficiente para detectar a ambiguidade e solicitar esclarecimentos, que podem ser incorporados no programa para eliminar a ambiguidade. Observe que a detecção de ambiguidade não significa que apenas uma das opções possíveis tenha significado, todas elas têm. A questão é se uma das entidades comunicantes pode detectar a ambiguidade para que o remetente possa esclarecê-la. Os seres humanos são ruins nisso, mas os computadores podem ser muito bons.

Formalismos e linguagens de programação podem ter sintaxe mais rica e flexível. Eu acredito que a principal razão pela qual eles não fazem isso é o simples conservadorismo. As ferramentas sintáticas usadas ainda são muitas vezes ferramentas projetadas há trinta anos ou mais, para atender às limitações dos computadores da época. A eficiência da análise não é mais uma questão tão crítica na compilação, e existem técnicas mais poderosas de forma tratável.

Curiosamente, a base mais amplamente usada para sintaxe de linguagens de programação vem da pesquisa em linguagem natural: a gramática livre de contexto. Grande parte da pesquisa técnica mudou-se para a ciência da computação teórica / técnica nos anos sessenta, para ser redescoberta de alguma maneira no início dos anos 80 por pessoas de linguagem natural (estou simplificando). Desde então, muito progresso foi feito para a sintaxe em linguagens naturais, enquanto a ciência da computação parece em grande parte presa às antigas ferramentas sintáticas. O pêndulo da linguagem natural está agora voltando para as técnicas estatísticas, mas as abordagens algébricas da sintaxe não são esquecidas. Provavelmente, boas abordagens virão de uma combinação de técnicas algébricas e estatísticas.

Meu sentimento é que a área crítica é a semântica e a transição entre sintaxe e semântica. Ainda é muito difícil formalizar a linguagem natural, enquanto temos muitas técnicas precisas no caso de linguagens de programação e sistemas formais. Como o jogo está longe de ser jogado para linguagens naturais, é difícil dizer qual o impacto que poderia ter sobre linguagens de programação no futuro.

Outro ponto é que muitos designers de linguagem de programação estão tentando provar alguma coisa ou reforçar uma ideologia técnica. Assim, eles são extremamente prescritivos em seu design para impedir que os usuários se afastem dos paradigmas pretendidos. Infelizmente, isso é extremamente contraproducente para a criatividade. A linguagem mais criativa já projetada foi uma das primeiras: Lisp (1958). A liberdade e a flexibilidade permitidas foram a fonte de considerável criatividade. O preço era que exigia autodisciplina e compreensão. Mas Lisp era realmente uma metalinguagem, uma linguagem para a criação de linguagens.

Agora, para outra perspectiva, os programas são na verdade provas de suas especificações vistas como uma declaração matemática (bem, estou simplificando novamente). Algumas pessoas (não me lembro de referências, desculpe) estão brincando com provadores de teoremas para produzir provas que pareceriam ter sido escritas por um matemático em linguagem natural. Então, acho que a ideia de ter programas que parecem que foram escritos em linguagem natural pode não ser totalmente absurda.

No entanto, você pode notar que, mesmo quando escrito informalmente por um matemático, o discurso matemático parece bem diferente da conversa comum ou de um livro de história. Isso se deve a uma diferença significativa no universo do discurso em questão, os domínios semânticos que estão sendo discutidos. Assim, embora você possa imaginar linguagens de programação que se parecem mais com linguagens naturais, há uma limitação natural que é o domínio do discurso e suas próprias propriedades desejáveis. Muito provavelmente permanecerá essencialmente superficial, isto é, principalmente sintático. O matemático pode falar sobre sistemas formais e sobre política. Espero que os dois discursos não sejam parecidos. Os computadores não podem (ainda?) Falar de política ou entendê-la. O dia em que eles fizerem isso não será mais a programação.

Olhando para trás na história, as linguagens de alto nível foram, desde o início (FORTRAN), uma tentativa de se aproximar de uma forma mais natural para expressar tarefas computacionais, mas essas tarefas foram entendidas como matemáticas ou lógicas (Fortran 1957, Algol 1958, Lisp 1958 ) ou mais orientada para os negócios (Cobol 1959). Dentro de dez anos, as pessoas estavam preocupadas com idiomas que seriam mais próximos, mais bem adaptados ao problema em questão, e houve uma pesquisa significativa nos chamados extensible languages, cobrindo sintaxe e semântica. Um caminho importante para expressar problemas de maneira mais natural foi o surgimento de object orientation(às vezes sob outros nomes). Embora seja sempre difícil atribuir paternidade, provavelmente surgiu do trabalho sobre inteligência artificial, principalmente em Lisp, e da linguagemSimula 67(Família Algol), que pretendia expressar mais naturalmente problemas do mundo real que devem ser simulados em um computador. Tudo parece historicamente consistente.

Embora sejam semelhantes, pois as perguntas feitas são semelhantes, elas são bastante distintas em termos de complexidade. A principal diferença é que a linguagem natural é inerentemente ambígua (mesmo no nível das palavras). Ainda não está claro o que se entende por uma palavra? No mundo das linguagens de programação, no entanto, uma variedade de dispositivos de definição está à disposição. Observe as gramáticas para analisar a linguagem natural e as para analisar as linguagens de programação. A diferença de tamanho é impressionante. O fato é que gramáticas para linguagens de programação são sistemas formais; então eles são passíveis de análise matemática. Lidar com ambiguidades apresenta muitos problemas para os quais uma solução na contraparte da linguagem de programação seria trivial ou simples.

Talvez a diferença entre linguagens naturais e linguagens de programação diminua se a diferença entre cientistas da computação e pessoas "naturais" diminuir.

Nos últimos anos, o interesse em (E) DSLs e interfaces fluentes tem aumentado constantemente, em uma grande variedade de linguagens: Haskell, as várias linguagens de script, C #, Java e até C ++ (pense na sobrecarga de operator<<para fazer saída).

Até certo ponto, eles permitem que o código seja lido mais naturalmente. Ilustrarei com um exemplo de EDSL no groovy. O pacote groovy.time permite escrever

use ( TimeCategory ) {
    // application on numbers:
    println 1.minute.from.now
    println 10.days.ago

    // application on dates
    def someDate = new Date()
    println someDate - 3.months 
}

Se você fizesse isso através da classe java.util.Calendar , teria que escrever algo parecido com isto para o primeiro exemplo:

void demo() {
    Calendar date = new GregorianCalendar();
    date.add(Calendar.MINUTE, 1);
    System.out.println(date);
}

As linguagens de computador (mesmo as linguagens de máquina rudimentares dos dias anteriores) são linguagens humanas, pois são principalmente para comunicação com outros seres humanos, são definidas por seres humanos e são usadas apenas secundariamente para transmitir instruções a uma máquina. Portanto, eles evoluem da mesma maneira que as línguas "naturais" (apenas procure "expressões idiomáticas") para o seu idioma favorito; verifique como, por exemplo, o C evoluiu do K&R C para a atual ISO-C 2011. Mas eles existem em um ambiente diferente. deve transmitir um significado preciso (os computadores ainda são burros demais para fazer sentido e corrigir o que é pedido a eles), e há um prêmio pela facilidade de processamento (portanto, a gramática e o vocabulário mesmo de C ++, PL / 1 ou APL são muito mais simples do que, por exemplo, o inglês, que como idiomas naturais é bastante simples).

Pode-se dizer o mesmo do formalismo da matemática ou das ciências em geral, ou mesmo de projetos (inerentemente 2D, não 1D como os outros).