Ruby é realmente uma linguagem interpretada se todas as suas implementações forem compiladas em bytecode?

Question

Na resposta escolhida para esta pergunta sobre Blue Ruby, Chuck diz:

Todas as implementações atuais do Ruby são compiladas no ByteCode.Ao contrário das reivindicações da SAP, a partir do Ruby 1.9, a própria RM inclui um compilador de bytecode, embora a capacidade de salvar o bytecode compilado no disco desaparecesse em algum lugar no processo de mesclar a máquina virtual Yarv.Jruby é compilado em arquivos Java .class.Não tenho muitos detalhes sobre o Maglev, mas parece seguro dizer que levará essa estrada também.

Estou confuso sobre esse problema de compilação/interpretação em relação ao Ruby.

Aprendi que Ruby é uma linguagem interpretada e é por isso que quando salvo alterações em meus arquivos Ruby não preciso reconstruir o projeto.

Mas se todas as implementações Ruby forem compiladas agora, ainda é justo dizer que Ruby é uma linguagem interpretada?Ou estou entendendo mal alguma coisa?

Answer 1

Sim, o Ruby ainda é uma linguagem interpretada, ou mais precisamente, o intérprete de Ruby (RM) de Matz, que é sobre isso que as pessoas geralmente falam quando falam sobre Ruby, ainda é um intérprete. A etapa de compilação está simplesmente lá para reduzir o código para algo mais rápido para executar do que interpretar e reinterpretar o mesmo código, tempo após o tempo.

Answer 2

Atualmente, quase todo idioma é "compilado", se você contar o ByteCode como sendo compilado. Até o Emacs Lisp é compilado. Ruby era um caso especial porque até recentemente, ele não compilado no bytecode.

Eu acho que você está certo em questionar a utilidade de caracterizar idiomas como "compilados" vs. "interpretados". Uma distinção útil, no entanto, é se o idioma cria código da máquina (por exemplo, o assembler x86) diretamente do código do usuário. C, C ++, muitos Lisps e Java com Jit ativado, mas Ruby, Python e Perl não.

As pessoas que não sabem melhor chamarão qualquer idioma que tenha uma etapa de compilação manual separada "compilada" e aqueles que não "interpretaram".

Answer 3

Uma pergunta sutil, de fato...Antigamente, as linguagens "interpretadas" eram analisadas e transformadas em uma forma intermediária que era mais rápida de executar, mas a "máquina" que as executava era um belo programa específico de linguagem.As linguagens "compiladas" foram traduzidas em instruções de código de máquina suportadas pelo computador no qual foram executadas.Uma distinção inicial era muito básica – estática vs.escopo dinâmico.Em uma linguagem de tipo estaticamente, uma referência de variável poderia ser praticamente resolvida para um endereço de memória em algumas instruções de máquina - você sabia exatamente onde no quadro de chamada a variável se referia.Em linguagens de tipo dinâmico, você tinha que pesquisar (em uma lista A ou em um quadro de chamada) pela referência.Com o advento da programação orientada a objetos, a natureza não imediata de uma referência se expandiu para muitos outros conceitos - classes (tipos), métodos (funções) e até mesmo interpretação sintática (DSLs incorporadas como regex).

A distinção, na verdade, remontando talvez ao final dos anos 70, não era tanto entre compilado e interpretado línguas, mas se eles foram executados em um ambiente compilado ou interpretado.Por exemplo, Pascal (a primeira linguagem de alto nível que estudei) funcionou na UC Berkeley primeiro no curso de Bill Joy pxp intérprete, e mais tarde o compilador que ele escreveu PCC.Mesma linguagem, disponível em ambientes compilados e interpretados.

Algumas linguagens são mais dinâmicas que outras, o significado de algo – um tipo, um método, uma variável – depende do ambiente de tempo de execução.Isso significa que, compilado ou não, existe um mecanismo de tempo de execução substancial associado à execução de um programa.Forth, Smalltalk, NeWs, Lisp, todos foram exemplos disso.Inicialmente, essas linguagens exigiam tantos mecanismos para serem executadas (em comparação com C ou Fortran) que eram naturais para interpretação.

Mesmo antes do Java, houve tentativas de acelerar a execução de linguagens complexas e dinâmicas com truques, técnicas que se tornaram compilação encadeada, compilação just-in-time e assim por diante.

Eu acho que foi Java, que foi a primeira linguagem amplamente difundida que realmente confundiu a lacuna entre compilador e intérprete, ironicamente não para que ele rodasse mais rápido (embora isso também), mas para que ele rodasse em qualquer lugar.Ao definir sua própria linguagem de máquina e "máquina" o bytecode java e VM, Java tentou se tornar uma linguagem compilada em algo próximo a qualquer máquina básica, mas não realmente a qualquer máquina real.

As línguas modernas casam com todas essas inovações.Alguns têm a natureza dinâmica, aberta, você não sabe o que obtém até o tempo de execução das tradicionais "linguagens interpretadas (ruby, lisp, smalltalk, python, perl (!)), alguns tentam têm o rigor de especificação que permite a detecção profunda de erros estáticos baseados em tipos de linguagens compiladas tradicionais (java, scala).Todos são compilados em representações independentes de máquina (JVM) reais para obter a semântica de gravação e execução em qualquer lugar.

Então, compilado vs.interpretado?O melhor de ambos, eu diria.Todo o código está no código-fonte (com documentação), mude qualquer coisa e o efeito é imediato, operações simples são executadas quase tão rápido quanto o hardware pode fazê-las, operações complexas são suportadas e rápidas o suficiente, modelos de hardware e memória são consistentes em todas as plataformas.

A maior polêmica nas linguagens hoje é provavelmente se elas são digitadas estaticamente ou dinamicamente, ou seja, não quão rápido elas serão executadas, mas se os erros serão encontrados pelo compilador de antemão (ao custo do programador ter que especificar uma digitação bastante complexa informações) ou os erros surgirão nos testes e na produção.

Answer 4

Você pode executar programas de rubi usando interativamente usando IRB, a concha rubi interativa. Embora possa gerar bytecode intermediário, certamente não é um "compilador" no sentido tradicional.

Answer 5

Uma linguagem compilada é geralmente compilada no código da máquina, em oposição ao código apenas de bytes. Alguns geradores de código de bytes podem realmente compilar o código de byte no código da máquina.

O código de byte em si é apenas uma etapa intermediária entre o código literal escrito pelo usuário e pela máquina virtual, ele ainda precisa ser interpretado pela máquina virtual (como é feito com Java em uma JVM e PHP com um cache de código OPCode).

Answer 6

Isso é possivelmente um pouco fora de tópico, mas ...

Rubi de ferro é uma implementação baseada no .NET do Ruby e, portanto, é geralmente compilada ao código de bytes e, em seguida, JIT compilado à linguagem da máquina no tempo de execução (ou seja, não interpretado). Também (pelo menos com outras línguas .NET, então presumo com Ruby) ngen Pode ser usado para gerar um binário nativo compilado com antecedência, de modo que é efetivamente uma versão compilada do código do Ruby.

Answer 7

Quanto às informações que obtive da RubyConf 2011 em Xangai, Matz está desenvolvendo uma 'Mruby' (significa Ruby de Matz) para direcionar a corrida em dispositivos incorporados. E Matz disse que o MRUBY fornecerá a capacidade de compilar o código Ruby no código da máquina para aumentar a velocidade e diminuir o uso dos recursos (limitados) nos dispositivos incorporados. Portanto, existem vários tipos de implementação do Ruby e, definitivamente, nem todos são interpretados durante o tempo de execução.