Há algum tempo, o criador da linguagem de programação Lua, Roberto Ierusalimschy, visitou nosso escritório em Moscou. Fizemos a ele algumas perguntas que também preparamos com a participação dos usuários do Habr.com. E, finalmente, gostaríamos de compartilhar a versão em texto completo desta entrevista.
- Vamos começar com alguns assuntos filosóficos. Imagine, se você recriasse Lua do zero, quais três coisas você mudaria em Lua?Uau! Essa é uma pergunta difícil. Há muita história embutida na criação e desenvolvimento da linguagem. Não foi uma grande decisão de uma só vez. Há alguns arrependimentos, vários dos quais tive a chance de corrigir ao longo dos anos. As pessoas reclamam disso o tempo todo por causa da compatibilidade. Fizemos isso várias vezes. Eu só estou pensando em coisas pequenas.
- Global por padrão? Você acha que esse é o caminho?Talvez. Mas é muito difícil para linguagens dinâmicas. Talvez a solução seja não ter nenhum padrão, mas seria difícil usar variáveis então.
Por exemplo, você teria que declarar de alguma forma todas as bibliotecas padrão. Você deseja uma linha única,
print(sin(x)) e, em seguida, terá que declarar 'print' e também declarar 'sin'. Portanto, é meio estranho ter declarações para esse tipo de scripts muito curtos.
Qualquer coisa maior não deve ter padrões, eu acho. Local por padrão não é a solução, não existe. É apenas para tarefas, não para uso. Algo que atribuímos, depois usamos e depois atribuímos, e há algum erro - completamente confuso.
Talvez global por padrão não seja perfeito, mas com certeza local por padrão não é uma solução. Eu acho que algum tipo de declaração, talvez declaração opcional ... Tivemos essa proposta muitas vezes - algum tipo de declaração global. Mas, no final, acho que o problema é que as pessoas começam a pedir cada vez mais e desistimos.
(sarcasticamente) Sim, colocaremos alguma declaração global - adicione isso e aquilo e aquilo, divulgue isso e, no final, entendemos que a conclusão final não satisfará a maioria das pessoas e não colocaremos todas as opções que todos desejarem, então não colocamos nada. No final, o modo estrito é um compromisso razoável.
Existe este problema: na maioria das vezes estamos usando campos dentro dos módulos, por exemplo, então você tem os mesmos problemas novamente. É apenas um caso muito específico de erro que a solução geral provavelmente deve incluir. Então eu acho que se você realmente quer isso, deve usar uma linguagem de tipo estaticamente.
- Global por padrão também é bom para pequenos arquivos de configuração.- Sim, exatamente, para pequenos scripts e assim por diante.
- Não há trocas aqui?- Não, sempre existem trocas. Há uma troca entre pequenos scripts e programas reais ou algo assim.
- Então, estamos voltando à primeira grande questão: três coisas que você mudaria se tivesse a chance. Na minha opinião, você está muito feliz com o que temos agora, está certo?- Bem, não é uma grande mudança, mas ainda assim ... Nossa inadimplência que se transformou em uma grande mudança é nula nas tabelas. É algo que realmente me arrependo. Eu fiz esse tipo de implementação, uma espécie de hack ... Você viu o que eu fiz? Enviei uma versão de Lua há cerca de seis meses ou um ano que não tinha tabelas.
- Valores nulos?Exatamente. Eu acho que foi chamado nil nas tabelas - o que é chamado nulo. Fizemos algumas invasões na gramática para torná-la um pouco compatível.
- Por que é necessário?- Estou realmente convencido de que esse é um problema inteiro de buracos ... Acho que a maioria dos problemas de nil em matrizes desapareceria, se pudéssemos ter [nil em tabelas] ... Porque o problema exato não é nil em matrizes. As pessoas dizem que não podemos ter nada em matrizes, portanto, devemos ter matrizes separadas das tabelas. Mas o verdadeiro problema é que não podemos ter nada nas tabelas! Portanto, o problema está nas tabelas, não na maneira como representamos matrizes. Se pudéssemos ter nada em tabelas, teríamos nada em matrizes sem mais nada. Então isso é algo que realmente me arrependo, e muitas pessoas não entendem como as coisas mudariam se Lua permitisse nada em tabelas.
- Posso contar uma história sobre Tarantool? Na verdade, temos nossa própria implementação de null, que é um CDATA para um ponteiro nulo. Usamo-lo onde são necessárias lacunas na memória. Para preencher argumentos posicionais quando fazemos chamadas remotas e assim por diante. Mas geralmente sofremos com isso porque o CDATA é sempre convertido em 'verdadeiro'. Portanto, nada em matrizes resolveria muitos dos nossos problemas.Sim, eu sei. Esse é exatamente o meu ponto - isso resolveria muitos problemas para muitas pessoas, mas há um grande problema de compatibilidade. Não temos energia para lançar uma versão tão incompatível e depois quebrar a comunidade e ter uma documentação diferente para Lua 5 e Lua 6 etc. Mas talvez um dia a liberemos. Mas é realmente uma grande mudança. Eu acho que deveria ter sido assim desde o início - se fosse, seria uma mudança trivial no idioma, exceto pela compatibilidade. Ele quebra muitos programas, de maneiras muito sutis.
- Quais são as desvantagens, exceto a compatibilidade?- Além da compatibilidade, a desvantagem é que precisaríamos de duas novas operações, duas novas funções. Como 'delete key', porque atribuir nil não excluiria a chave; portanto, teríamos um tipo de operação primitiva para excluir a chave e realmente removê-la da tabela. E 'teste' para verificar onde exatamente distinguir entre zero e ausente. Então, precisamos de duas funções primitivas.
- Você analisou o impacto disso em implementações reais?- Sim, lançamos uma versão do Lua com isso. E como eu disse, ele quebra o código de várias maneiras sutis. Existem pessoas que fazem table.insert (f (x)) - uma chamada para uma função. E é proposital, é por design que quando uma função não deseja inserir nada, ela retorna nulo. Então, em vez de uma verificação separada "eu quero inserir?", Chamo table.insert e sabendo que se for nulo, ele não será inserido. Como tudo em todos os idiomas, um bug se torna um recurso e as pessoas o usam - mas se você o alterar, você quebra o código.
- Que tal um novo tipo de vazio? Como nada, mas vazio?- Oh não, isso é um pesadelo. Você apenas adia o problema, se colocar outro, precisará de outro e outro e outro. Essa não é a solução. O principal problema - bem, não principal, mas um dos problemas - é que nada já está enraizado em muitos lugares do idioma. Por exemplo, um exemplo muito típico. Dizemos: você deve evitar nada em matrizes, buracos. Mas então temos funções que retornam nulo e algo depois de nulo, então obtemos um código de erro. Portanto, a própria construção assume o que nada representa ... Por exemplo, se eu quiser fazer uma lista de retornos dessa função, apenas para capturar todos esses retornos.
- É por isso que você tem um truque para isso. :)- Exatamente, mas você não precisa usar hacks para um problema tão primitivo e óbvio. Mas a maneira como as bibliotecas são construídas ... Uma vez pensei nisso - talvez as bibliotecas retornem falsas em vez de nulas - mas é uma solução meio cozida, resolve apenas uma pequena parte do problema. O verdadeiro problema, como eu disse, é que deveríamos ter nada nas tabelas. Caso contrário, talvez não devamos usar nils com a mesma frequência que usamos agora. É tudo meio bagunçado. Portanto, se você criar um nulo, essas funções ainda retornarão um valor nulo, e ainda teríamos esse problema a menos que criassemos um novo tipo e as funções retornariam um nulo em vez de nulo.
+ Vazio pode ser usado para dizer explicitamente que a chave deve ser mantida em uma chave de tabela com um valor vazio. E nada pode agir como antes.- Sim, é isso que eu quero dizer. Todas as funções nas bibliotecas devem retornar nulas ou nulas.
- Eles ainda podem retornar nulo, por que não?- Porque ainda temos o problema de que você não pode capturar algumas funções.
- Mas não haverá uma primeira chave, apenas uma segunda chave.- Não, não haverá uma segunda chave, porque a contagem estará errada e você terá um buraco na matriz.
- Sim, você está dizendo que precisa de um falso metamétodo?Sim. Meu sonho é algo assim:
{f(x)}Você deve capturar todos os retornos da função
f(x) . E então eu posso fazer
%x ou #
%x , e isso me dará o número de retornos da função. É isso que uma linguagem razoável deve fazer. Portanto, criar um vazio não resolverá isso, a menos que tenhamos uma regra muito forte de que as funções nunca devem retornar nulas, mas por que precisamos nulas? Talvez devêssemos evitar.
- Roberto, haverá um suporte de análise estática muito mais forte para Lua? Como "Lua Verifique os esteróides". Eu sei que não vai resolver todos os problemas, é claro. Você está dizendo que esse é um recurso para 6.0, se é que alguma vez, certo? Portanto, se no 5.x houver uma forte ferramenta de análise estática - se horas-homem e homens-ano forem investidos - isso realmente ajudaria?- Não, acho que uma ferramenta de análise estática realmente forte se chama ... sistema de tipos! Se você quer uma ferramenta realmente forte, deve usar uma linguagem de tipo estaticamente, algo como Haskell ou mesmo algo com tipos dependentes. Então você terá ferramentas de análise realmente fortes.
- Mas então você não tem Lua.- Exatamente, Lua é para ...
- Impreciso? Gostei muito da sua foto de girafa em tipos estáticos e dinâmicos.- Sim, meu último slide.
O slide final da palestra de Roberto Ierusalimschy “Por que (e por que não) Lua?”
na lua em Moscow 2019 conference- Para a nossa próxima pergunta preparada, vamos voltar a essa imagem. Se eu entendi direito, sua posição é que Lua é uma pequena ferramenta útil para resolver tarefas não muito grandes.- Não, acho que você pode realizar algumas tarefas grandes, mas não com análise estática. Eu acredito fortemente em testes. A propósito, eu discordo de você na cobertura, sua opinião é que não devemos perseguir a cobertura ... Quero dizer, concordo plenamente que a cobertura não implica teste completo, mas a não cobertura implica um teste de zero por cento. Então eu falei sobre uma sala de testes - você estava lá em Estocolmo. Então comecei meu teste com [alguns] bugs - isso é a coisa mais estranha - um deles era famoso, o outro não era famoso. É algo completamente quebrado em um arquivo de cabeçalho da Microsoft, C e C ++. Então, eu pesquiso na web e ninguém se importa com isso ou até percebe.
Por exemplo, há uma função matemática,
modf () , na qual você deve passar um ponteiro para um duplo, pois ele retorna dois duplos. Traduzimos a parte inteira do número ou a parte fracionária. Portanto, isso faz parte de uma biblioteca padrão há muito tempo. Então veio o C 99, e você precisa dessa função para carros alegóricos. E o arquivo de cabeçalho da Microsoft simplesmente manteve essa função e declarou outra como macro. Então ele colocou este tipo de conversão. Então, lançou o dobro para flutuar, ok, e depois lançou o ponteiro para dobrar para o ponteiro flutuar!
- Algo está errado nesta foto.- Este é um arquivo de cabeçalho do Visual C ++ e Visual C 2007. Quero dizer, se você chamasse essa função uma vez, com quaisquer parâmetros e verificasse os resultados - estaria errado a menos que seja zero. Caso contrário, qualquer outro valor estará errado. Você nunca usaria essa função. Zero cobertura. E há muitas discussões sobre testes ... quero dizer, basta chamar uma função uma vez, verificar os resultados! Então está lá, está lá há muito tempo, há muitos anos que ninguém se importa. Um muito famoso foi na Apple.
Algo como "
if… what… goto… ok ", era algo assim. Alguém colocou outra declaração aqui. E então tudo estava indo bem. E houve muitas discussões em que você deve ter as regras, os colchetes devem ser obrigatórios no seu estilo, etc., etc. Ninguém mencionou que existem muitos outros ifs aqui. Isso nunca foi executado ...
- Há também um problema de segurança, pelo que me lembro.Sim, exatamente. Porque eles estavam apenas testando casos aprovados. Eles não estavam testando nada, porque tudo seria aprovado. Isso significa que não há um único caso de teste no aplicativo de segurança que verifique se ele recusa alguma conexão ou seja o que for que ele deveria recusar. Então todos discutem e dizem que devem ter colchetes ... Eles devem ter testes, testes mínimos! Porque ninguém nunca testou isso, é o que quero dizer com cobertura. É inacreditável como as pessoas não fazem testes básicos. Porque se eles estavam fazendo todos os testes básicos, é claro, é um pesadelo fazer toda a cobertura e executar todas as linhas, etc. As pessoas negligenciam até os testes básicos, portanto a cobertura é pelo menos sobre o mínimo. É uma maneira de chamar a atenção para algumas partes do programa que você esqueceu. É um tipo de guia sobre como melhorar um pouco seus testes.
- Qual é a cobertura dos testes no Tarantool? 83%! Roberto, qual é a cobertura do teste de Lua?- Cerca de 99,6. Quantas linhas de código você possui? Um milhão, centenas de milhares? Estes são grandes números. Um por cento dos cem mil são mil linhas de código que nunca foram testadas. Você não o executou. Seus usuários não testam nada.
- Então, existem 17% dos recursos do Tarantool que não são usados atualmente?- Não tenho certeza se você deseja desempilhar tudo de volta para onde estávamos ... Acho que um dos problemas com linguagens dinâmicas (e estáticas) é que as pessoas não testam coisas. Mesmo se você tiver uma linguagem estática, a menos que tenha algo - nem mesmo como Haskell, mas Coq -, algum sistema de prova, você muda isso para isso ou aquilo. Nenhuma ferramenta de análise estática pode detectar esses erros, então você precisa de testes. E se você tiver os testes, detecta problemas globais, renomeia erros de ortografia etc. Todos esses tipos de erros. Você deve fazer esses testes de qualquer maneira, talvez às vezes seja um pouco mais difícil de depurar, às vezes não - depende da linguagem e do tipo de bug. Mas o problema é que nenhuma ferramenta de análise estática pode permitir que você evite testes. Os testes, por outro lado ... bem, eles nunca provam a ausência de erro, mas eu me sinto muito mais seguro depois de todos os testes.
- Temos uma pergunta sobre o teste de módulos Lua. Como desenvolvedor, quero testar algumas funções locais que podem ser usadas posteriormente. A questão é: queremos ter uma cobertura de cerca de 99%, mas para a API que este módulo produz, o número de casos funcionais que ele deve produzir é muito menor do que a funcionalidade que ele suporta internamente.- Por que isso, desculpe?
- Há algumas funcionalidades que não são acessíveis pela interface pública.- Se houver uma funcionalidade que não seja alcançável pela interface pública, ela não deverá estar lá, apenas apague-a. Apague esse código.
- Apenas mate?- Sim, às vezes faço isso em Lua. Havia alguma cobertura de código, eu não conseguia chegar lá ou ali ou lá, então pensei que era impossível e apenas removi o código. Não é tão comum, mas aconteceu mais de uma vez. Esses casos eram impossíveis de acontecer, basta colocar uma afirmação para comentar por que isso não pode acontecer. Se você não conseguir acessar suas funções a partir da API pública, ela não deverá estar lá. Devemos codificar a API pública com entrada incorreta, essencial para os testes.
- Remova o código, a remoção é boa, reduz a complexidade. A complexidade reduzida aumenta a manutenção e a estabilidade. Mantenha isso simples.- Sim, programação extrema tinha essa regra. Se não estiver em um teste, não existe.
- Quais idiomas o inspiraram quando você criou Lua? Quais paradigmas, especialidades funcionais ou partes dessas línguas você gostou?- Eu projetei Lua para um propósito muito específico, não era um projeto acadêmico. É por isso que quando você me pergunta se eu o criaria novamente, digo que há muitas coisas históricas na linguagem. Eu não comecei com 'Deixe-me criar o idioma que eu quero ou quero usar ou todo mundo precisa etc. Meu problema era 'Este programa aqui precisa de uma linguagem de configuração para geólogos e engenheiros, e preciso criar uma pequena linguagem que eles possam usar com uma interface fácil. É por isso que a API sempre foi parte integrante da linguagem, porque é mais fácil ser integrado. Esse era o objetivo. O que eu tinha na minha formação, eram muitas línguas diferentes na época ... umas dez. Se você quiser todo o plano de fundo ...
- Eu estava interessado nos idiomas que você queria incluir no Lua.- Eu estava conseguindo coisas de várias línguas diferentes, qualquer que fosse o problema que eu tinha. A maior inspiração foi a linguagem Modula para sintaxe, mas por outro lado, é difícil dizer porque existem muitas línguas. Algumas coisas vieram do AWK, foi outra pequena inspiração. Claro, Scheme e Lisp ... Eu sempre fui fascinado com Lisp desde que comecei a programar.
- E ainda não há macros em Lua!- Sim, há muita diferença na sintaxe. Fortran, eu acho, foi o primeiro idioma ... não, o primeiro idioma que aprendi foi Assembléia, depois veio o Fortran. Estudei, mas nunca usei CLU. Fiz muita programação com Smalltalk, SNOBOL. Eu também estudei, mas nunca usei o Icon, também é muito interessante. Muita coisa veio de Pascal e C. Na época em que criei Lua, o C ++ já era muito complexo para mim - e isso foi antes dos modelos, etc. Era 1991, e em 1993 Lua foi iniciada.
- A União Soviética caiu e você começou a criar Lua. :) Você estava entediado com ponto e vírgula e objetos quando começou a trabalhar em Lua? Eu esperaria que Lua tivesse uma sintaxe semelhante a C, porque está integrada a C. Mas ...- Sim, acho que é uma boa razão para não ter sintaxe semelhante - para que você não os misture, esses são dois idiomas diferentes.
É algo realmente engraçado e está ligado à resposta que você não me permitiu [na conferência] fornecer matrizes a partir de 1. Minha resposta foi muito longa.
Quando começamos a Lua, o mundo era diferente, nem tudo era do tipo C. Java e JavaScript não existiam, o Python estava na infância e tinha uma versão menor que 1.0. Portanto, não havia essa coisa quando todas as línguas deveriam ser do tipo C. C era apenas uma das muitas sintaxes existentes.
E as matrizes eram exatamente as mesmas. É muito engraçado que a maioria das pessoas não perceba isso. Há coisas boas sobre matrizes baseadas em zero e matrizes baseadas em uma.
O fato é que a maioria dos idiomas populares hoje é baseada em zero por causa de C. Eles foram inspirados por C. E o engraçado é que C não tem indexação. Portanto, você não pode dizer que C indexa matrizes de zero, porque não há operação de indexação. C tem aritmética de ponteiro, portanto zero em C não é um índice, é um deslocamento. E como um deslocamento, deve ser zero - não porque tenha melhores propriedades matemáticas ou porque seja mais natural, seja qual for.
E todos os idiomas que copiaram C, eles têm índices e não têm aritmética de ponteiro. Java, JavaScript, etc., etc. - nenhum deles tem aritmética de ponteiro. Então eles apenas copiaram o zero, mas é uma operação completamente diferente. Eles colocam zero sem nenhum motivo - é como um culto à carga.
- Você está dizendo que é lógico se você tiver um idioma incorporado em C para fazê-lo com sintaxe semelhante a C. Mas se você tem uma linguagem incorporada em C, presumo que você tenha programadores em C que desejam que o código esteja em C e não em outra linguagem, que se pareça com C, mas não seja C. Portanto, os usuários de Lua nunca deveriam usar C diariamente? Porque- Quem usa C todos os dias?
- programadores de sistema.Exatamente. Esse é o problema, muitas pessoas usam C, mas não devem poder usá-lo. Os programadores devem ser certificados para usar o C. Por que o software está tão danificado? Todos esses hacks invadindo o mundo, todos esses problemas de segurança. Pelo menos metade deles é por causa de C. É realmente difícil programar em C.
- Mas Lua está em C.- Sim, e foi assim que aprendemos o quão difícil é programar em C. Você tem estouros de buffer, números inteiros que causam estouros de buffer ... Basta obter um único programa C que você pode ter certeza de que nenhuma aritmética dará errado se as pessoas colocarem qualquer número em qualquer lugar e tudo está marcado. Por outro lado, problemas reais de portabilidade - talvez algumas vezes em uma CPU funcione, mas depois cheguem à outra CPU ... É uma loucura.
Por exemplo, muito recentemente, tivemos um problema. Como você sabe que o seu programa C não sobrecarrega a pilha? Quero dizer profundidade da pilha, não estouro de pilha porque você invadiu ... Quantas chamadas você tem o direito de fazer em um programa C?
- Depende do tamanho da pilha.Exatamente. O que o padrão diz sobre isso? Se você codifica em C e executa essa função que chama essa função que chama essa função ... quantas chamadas você pode fazer?
16 mil?- Posso estar errado, mas acho que o padrão não diz nada sobre isso.
- Acho que não há nada no padrão porque é muito dependente do tamanho.- Claro, isso depende do tamanho de cada função. Pode ser uma matriz enorme e automática no quadro de funções ... Portanto, o padrão não diz nada e não há como verificar se uma chamada será válida. Portanto, você pode ter um único problema se tiver três chamadas de etapa, ele pode falhar e ainda ser um programa C válido. Corrija de acordo com o padrão - embora não esteja correto porque falha. Portanto, é muito difícil programar em C, porque existem muitos ... Outro bom exemplo: qual é o resultado quando você subtrai dois ponteiros? Ninguém aqui trabalha com C?
- Não, então não grelhe eles. Mas o C ++ suporta tipos diferentes.- Não, C ++ tem o mesmo problema.
- Qual é o tipo de declaração? ptrdiff_t ?- Exatamente,
ptrdiff_t é um tipo assinado. Portanto, normalmente, se você tiver uma memória padrão do tamanho da sua palavra e subtrair dois ponteiros nesse espaço, não poderá representar todos os tamanhos no tipo assinado. Então, o que o padrão diz sobre isso?
Quando você subtrai dois ponteiros, se a resposta se encaixa em um diff de ponteiro, essa é a resposta. Caso contrário, você terá um comportamento indefinido. E como você sabe se encaixa? Você não Portanto, sempre que você subtrair dois ponteiros, normalmente você sabe que isso está fora do padrão, que, se você estiver apontando para algo maior que pelo menos 2 bytes, o tamanho maior será metade do tamanho da memória, então está tudo bem.
Então você só está tendo um problema se estiver apontando para bytes ou caracteres. Mas quando você faz isso, tem um problema real, não pode fazer aritmética de ponteiros sem se preocupar com o fato de ter uma string maior que a metade da memória. E então não posso simplesmente calcular o tamanho e armazenar em um tipo de ponteiro porque está errado.
É o que quero dizer sobre ter um programa C ou C ++ seguro que é realmente seguro.
- Você já pensou em implementar Lua em um idioma diferente? Mudar de C para outra coisa?- Quando começamos, considerei C ++, mas como disse, desisti de usá-lo por causa da complexidade - não consigo aprender toda a linguagem. Deve ser útil ter algumas coisas do C ++, mas ... ainda hoje não vejo nenhuma linguagem que funcionaria.
- Você pode explicar o porquê?- Porque não tenho alternativas. Só posso explicar o porquê contra outros idiomas. Não estou dizendo que C é perfeito ou até bom, mas é o melhor. Para explicar o porquê, preciso compará-lo com outros idiomas.
- E a JVM?JVM. Vamos lá, ele não cabe na metade do hardware ... Portabilidade é o principal motivo, mas também o desempenho. Na JVM, é um pouco melhor que o .NET, mas não é tão diferente. Muitas coisas que Lua faz, não podemos fazer com a JVM. Você não pode controlar o coletor de lixo, por exemplo. É necessário usar o coletor de lixo da JVM porque não é possível ter um coletor de lixo diferente implementado na parte superior da JVM. A JVM também é um grande consumidor de memória. Quando qualquer programa Java começa a dizer olá, é mais ou menos 10 MB. A portabilidade é um problema não porque não foi portado, mas porque não pode ser portado.
- E as modificações da JVM como a Mobile JVM?- Isso não é JVM, é uma piada. É como uma micro edição de Java, não Java.
- E outras linguagens estáticas, como Go ou Oberon? Eles poderiam ser a base para Lua se você o criou hoje?- Oberon ... pode ser, depende ... Go, novamente, tem um coletor de lixo e um tempo de execução muito grande para Lua. Oberon seria uma opção, mas Oberon tem algumas coisas muito estranhas, como você quase não tem constantes, se bem me lembro. Sim, acho que eles removeram o const de Pascal para Oberon. Eu tinha um livro sobre Oberon e amava Oberon. Seu
sistema era inacreditável, é realmente algo.
Lembro-me de que em 1994 vi uma demonstração de Oberon e Self. Você se conhece? É uma linguagem dinâmica muito interessante com os compiladores jit, etc ... Vi essas demos com uma semana de diferença, e o Self era muito inteligente, eles usaram algumas técnicas de desenhos animados para disfarçar a lentidão das operações. Porque quando você abriu algo, era como 'woop!' - primeiro reduz um pouco e depois se expande com alguns efeitos. Foi muito bem implementada, essas técnicas que eles usavam para simular movimento ...
Então, uma semana depois, vimos uma demonstração do Oberon, que estava funcionando com 1/10 de hardware para o Self - havia uma máquina pequena e muito antiga. No Oberon, você clica e depois apenas lança, tudo funciona imediatamente, todo o sistema é tão leve.
Mas para mim é muito minimalista, eles removeram constantes e tipos de variantes.
Haskell?- Não conheço Haskell ou como implementar Lua em Haskell.
- E qual sua atitude em relação a linguagens como Python ou R ou Julia como base para futuras implementações de Lua?- Eu acho que cada um desses tem seus usos.
R parece ser bom para estatísticas. É muito específico do domínio, feito por pessoas da área, então isso é uma força.
Python é legal, mas eu tive problemas pessoais com ele. Pensei ter mencionado isso na minha palestra ou na entrevista. Essa coisa de não conhecer o idioma inteiro ou não usá-lo, a falácia do subconjunto.
Usamos Python em nossos cursos, ensinando programação básica - apenas uma pequena parte, loops e números inteiros. Todos estavam felizes e disseram que seria bom ter algumas aplicações gráficas, por isso precisávamos de uma biblioteca gráfica. E quase todas as bibliotecas gráficas, você obtém a API ... Mas eu não conheço Python o suficiente, isso é algo muito avançado. Ele tem a ilusão de que é fácil e eu tenho todas essas bibliotecas para tudo, mas é fácil ou você tem tudo.
Então, quando você começa a usar a linguagem, começa: oh, eu tenho que aprender OOP, herança, qualquer outra coisa. Cada biblioteca. Parece que os autores se orgulham de usar recursos de linguagem mais avançados em sua API para mostrar que não sei o quê. Chamadas de função, tipos padrão, etc. Você tem esse objeto e, se quiser outra coisa, precisará criar outro objeto ...
Até a correspondência de padrões, você pode fazer algumas coisas simples, mas geralmente a correspondência de padrões padrão não é algo que você faz. Você faz uma correspondência, um objeto retorna um resultado e, em seguida, chama métodos no resultado desse objeto para obter o resultado real da correspondência. Às vezes, existe uma maneira mais simples de usar, mas não é óbvio, não é o que a maioria das pessoas usa.
Outro exemplo: eu estava ministrando um curso sobre correspondência de padrões e queria usar a sintaxe semelhante ao Perl, e não podia usar Lua por causa de uma sintaxe completamente diferente. Então, pensei que o Python seria o exemplo perfeito. Mas no Python existem algumas funções diretas para algumas coisas básicas, mas para algo mais complexo você precisa conhecer objetos e métodos etc. Eu só queria fazer alguma coisa e ter o resultado.
- O que você acabou usando?- Eu usei Python e expliquei a eles. Mas mesmo o Perl é muito mais simples, você faz a partida e os resultados são $ 1, $ 2, $ 3, é muito mais fácil, mas eu não tenho coragem de usar o Perl, então ...
- Eu estava usando Python por dois anos antes de perceber que havia decoradores. (pergunta por Yaroslav Dynnikov da equipe Tarantool)- Sim, e quando você deseja usar uma biblioteca, precisa aprender essas coisas e não entende a API etc. Python dá a ilusão de que é fácil, mas é bastante complexo.
... E Julia, eu não sei muito sobre Julia, mas isso me lembrou LuaJIT no sentido de que às vezes parece o orgulho do usuário. Você pode ter resultados muito bons, mas precisa realmente entender o que está acontecendo. Não é como se você escrevesse código e obtivesse bons resultados. Não, você escreve código e às vezes os resultados são bons, às vezes são horríveis. E quando os resultados são terríveis, você tem muitas boas ferramentas que mostram a linguagem intermediária que foi gerada, você verifica e depois passa por todo esse código quase de montagem. Então você percebe: oh, não está otimizando isso por causa disso. Esse é o problema dos programadores, eles gostam de jogos e às vezes gostam de coisas porque é difícil, não porque é fácil.
Não sei muito sobre Julia, mas uma vez vi uma conversa sobre isso. E o cara falando, foi ele quem teve esse ponto de vista: veja como é legal, escrevemos este programa e é perfeito. Não me lembro de muita coisa, acho que sobre multiplicação de matrizes. E então os carros alegóricos são perfeitos, então os duplos são perfeitos, e então eles colocam [números] complexos ... e foi uma tragédia. Como cem vezes mais devagar.
(sarcasticamente) 'Veja como é bom, nós temos essa ferramenta, podemos ver toda a montagem [lista], e então você muda isso e aquilo e aquilo. Veja como isso é eficiente '. Sim, eu vejo, eu posso programar em montagem diretamente.
Mas isso foi apenas uma conversa. Estudei um pouco de R e tenho alguma experiência de usuário com Python para coisas pequenas.
- O que você acha de Erlang?- Erlang é uma linguagem engraçada. Tem alguns usos realmente bons, a tolerância a falhas é realmente interessante. Mas eles afirmam que é uma linguagem funcional e toda a idéia da linguagem funcional é que você não tem um estado.
E Erlang tem um enorme estado oculto nas mensagens enviadas e ainda não recebidas. Portanto, cada pequeno processo é completamente funcional, mas o próprio programa não é funcional.
É uma bagunça de dados ocultos muito pior que as variáveis globais, porque se fossem variáveis globais, você as imprimiria. Mensagens que são o estado real do seu sistema. A cada momento, qual é o estado do sistema? Há todas essas mensagens enviadas aqui e ali. É completamente não funcional, de todo.
- Então Erlang mente sobre ser funcional e Python sobre ser simples. Sobre o que Lua mente?- Lua mente um pouco sobre ser pequeno. Ainda é menor do que a maioria dos outros idiomas, mas se você quer um idioma realmente pequeno, Lua é maior do que você deseja.
- O que é uma linguagem pequena então?- Adiante, eu adoro Forth.
- Existe espaço para uma versão menor do Lua?Talvez, mas é difícil. Adoro mesas, mas as mesas não são muito pequenas. Se você quer representar coisas pequenas, toda a idéia por trás das mesas não combina com você. Seria a sintaxe de Lua, chamaríamos de Lua, mas não é Lua.
Seria como uma micro edição Java. Você o chama de Java, mas possui multi-threading? Não, não faz. Tem uma reflexão? Não, não faz. Então, por que usá-lo? Ele tem uma sintaxe de Java, o mesmo sistema de tipos, mas não é Java. É uma linguagem diferente e mais fácil de aprender se você conhece Java, mas não é Java.
Se você deseja criar uma linguagem pequena que se pareça com Lua, mas Lua sem tabelas não é ... Provavelmente você deve declarar tabelas, algo como FFI para poder ser pequeno.
- Existem pequenas adaptações de Lua?Talvez eu não saiba.
- Lua está pronta para pura programação funcional? Você pode fazer isso com Lua?- Claro que você pode. Não é particularmente eficiente, mas apenas Haskell é realmente eficiente para isso. Se você começar a usar mônadas e coisas assim, criar novas funções, compor funções etc ... Você pode fazer isso com Lua, ele é executado razoavelmente, mas você precisa de técnicas de implementação diferentes das linguagens imperativas normais para fazer algo realmente eficiente.
— Actually, there is a library for functional programming in Lua.— Yes, it's reasonable and usable, if you do really need performance; you can do a lot of stuff with it. I love functional stuff and I do it all the time.
— My question is more about the garbage collector, because we only have only mutable objects and we have to use them efficiently. Will Lua be good for that?— I think a new incarnation of garbage collector will help a lot, but again…
— Young die young? The one that seems to work with young objects?— Exactly, yes. But as I said even with the standard garbage collector we don't have optimal performance but it can be reasonable. More often you don't even need that performance for most actions unless you are writing servers and having big operations.
— What functional programming tasks do you perform in Lua?— A simple example. My book, I'm writing my own format and I have a formatter that transforms that in LaTex or DocBook. It's completely functional, it has a big pattern matching… It's slightly inspired by LaTex but much more uniformed. There's @ symbol instead of backslash, a name of a macro and one single argument in curly brackets. So I have gsub that recognizes this kind of stuff and then it calls a function, the function does something and returns something. It's all functional, just functions on top of functions on top of functions, and the final function gives a big result.
— Why don't you program with LaTeX?— Plain LaTeX? First, it's too tricky for a lot of stuff and so difficult. I have several things that I don't know how to do in LaTex. For example, I want to put a piece of inline code inside a text. Then there is a slash verb, standard stuff. But slash verb gives fixed space. And the space between stuff is never right. All real spaces are variable, it depends on how the line is adjusted, so it expands in some spaces and compacts in others depending on a lot of stuff. And those spaces are fixed, so sometimes they look too large, sometimes too small. It also depends on what you put in code.
— But you still render your own format to LaTeX?— Yes, but with a lot of preprocessing. I write my own verb but then it changes and becomes not a verb but a lot of stuff. For example, when I write 3+1 I write a very small space here. In verb, if I don't put any space here, it shrinks, and if I do, it's too large. So I do the preprocessing, inserting a variable space. It's very small but can be a little larger if it needs to adjust. But if I put 'and' after 1 then I put a larger space. This function here does all that. This is a small example but there are other things…
— Do you have a source?— I do have the source, it is in the
git . The program's called
2html . The current version only generates HTML… Sorry, that's a kind of a mess. I created it for a book but also another one for the manual. The one in the git is for the manual. But the other one is more complicated and not public, I can't make it public. But the main problem is that TeX is not there. It's almost impossible to process TeX files without TeX itself.
— Is it not machine-readable?— Yes, it's not machine-readable. I mean, it is readable because TeX reads it. It's so hard to test, so many strange rules etc. So this is much more uniformed and as I said I generate DocBook format, sometimes I need it. That started when I had this contract for a book.
— So you use 2html to generate DocBook?— Yes, it generates DocBook directly.
- Ok, muito obrigado pela entrevista!
Se você tiver mais alguma dúvida, poderá solicitá-las na lista de discussão Lua . Até breve!