Interpretando o Ruby!
Acho que é um assunto interessante e por isso vou falar um pouco sobre os Interpretadores Ruby!
Bem antes de falar dos interpretadores de Ruby, vamos falar um pouco sobre interpretadores. Na verdade era interessante deixar bem claro a diferença entre anbiente de execução e instruções executadas.
O que é Ruby, na verdade Ruby é o nome que se dá ao conjuto de Interpretador e Linguagem que o interpretador reconhece, ou seja, o Linguagem Ruby é reconhecida pelo Interpretador Ruby.
Bem nem sempre foi assim, a muitos e muito tempo (hehe to brincando), os programas eram compilados, ou seja escrevia-se o código fonte e depois o código era convertido para linguagem de máquina (binarios) e executado diretamente pelo processador, nunca mais necessitando ser lido o código fonte. É assim que a linguagem C faz usando o Compilador GCC. Ou seja Tem a Linguagem C e o Compilador que entende a Linguagem C.
Voltemos a Ruby, no mundo Ruby é um pouco diferente. A diferença logo de cara é que o Codigo Ruby não é Compilado para Binários e sim Interpretado durante a Execução. Fica mais ou menos assim, quando executamos um programa Ruby, primeiramente chamamos um programa que reconhece as instruçoes Ruby (o interpretador ruby), este programa lê as instruções e executa durante a solicitação. O legal é que o Interpretador sempre precisa de ler o código fonte para executar a instrução. O legal disso é:
Primeiro! Seu código pode ser rodado em qualquer ambiente. Basta que haja um interpretador Ruby no ambiente, tails como Linux, Windows, Unix, BSD, etc.
Segundo! Ao Interpretar o codigo pode ser otimizado excessivamente para ser mais rápido e mais eficiente.
Bem mais não acaba ai, linguagens orientadas a objetos tem um grande desafio em uso de memória. Notem que quando se instancia um Objeto ele e repleto de Atributos e isso consome muita memória, porem, também torna as variaveis bem mais regenciaveis, pois elas sempre dependem de um objeto. Bem para resolver este problemas existe um outro programa que auxilia o Sistema Operacional a gerenciar a memória, ele tem por objetivo remover objetos não usados da memória e liberar espaço para outros objetos. Este programa tem o nome de Coletor de Lixo.
Ja notamos que a coisa ta ficando cada vez mais interessante. Então vamos falar dos interpretadores de Ruby.
MRI - Matz Ruby Interpreter
Como o Próprio nome ja diz é o interpretador que o Matz fez, ele é o primeiro Interpretador Ruby, é lindo em sua forma, porém não é o mais otimizado, talvez porque o Matz não buscasse o que o java buscava, em ser o melhor, mais seguro e mais rápido de todos. O que significa isso, um programa ruby executado pelo interpretador MRI, é bem mais lento que um programa Java ou um programa Smalltalk, quem, porém isso não é necessariamente um grande problema, pois com a facilidade de programação que a linguagem proporciona, é possivel otimizar código tornando a aplicação em si mais rápida idependente do interpretador.
YARV - MRI1.9
Este é o grande esforço da comunidade Ruby para melhorar o MRI, ele tem por objetivo resolver alguns problemas conseituais do MRI e aumentar sua performance, porém isso nao está sendo tão simples assim, por mais interessantes que venham se mostrando os testes a velocidade em si não tem melhorado muito, isto é normal, em alguns casos a otimização de um interpretador leva vários anos para encontrar algo performático e seguro.
Rubinius
Este com certeza é o mais elegante e promissor de todos. A idéia do Rubinius é fazer um interpretador de Ruby escrito em Ruby. Como? O jeito é fazer os elementos essenciais em C, e depois o restante todo em ruby puro. É como construir uma ferrovia, os primeiros trilhos usaśe um caminhão pra llevar, quando cabe a locomotiva, ja usa-se a prórpia ferrovia apra levar os proximos trilhos. Qual é a grande vantagem de se escrever um interpretador de Ruby em Ruby, a grande sacada é que escrever em Ruby é muito fácil e rápido, em quanto um interpretador de Ruby em C precisa de 10 mil linha um Escrito em Ruby precisa de 1 mil, e enquanto em um Interpretador escrito em C voce precisa mudar 1000 linhas pra melhorar algo em Ruby voce precisa mudar apesa 10, isso tornaria a evolução do Rubinius algo vertiginoso e inesperado. Porém o inicio ainda é muito lento e singular, talvez ainda demore um pouco para chegar ao estado perfeito da arte.
Bem além disso a idéia do Rubinius é ser um Maquina Virtual, a diferença entre ser uma VM ou somente um Interpretador é que é necessário implementar no interpretador todas as rotinas que o sistema Operacional disponibiliza diretamente ao sistema, ou seja, ao inves de vc pedir ao SO para ler um arquivo, pedesse a MV que por sua vez pede a Sistema Operacional, isso torna a Sua Aplicação bem mais portavel, pois dependendo do Sistema Operacional ele disponibiliza diferentes recusos, e é possivel vc estar usando algum recusrso que nao esteja disponível em todos SO, um exemplo classico é a gerador de imagens MAGIC, que é escrito em C e é possivel usar no MRI, porém nem todos os SO tem o MAGIC instalado e disponível. Voltando uma VM é muito mais capaz de resolver tudo que seu programa pede sem depender o Sistema Operacional, isso torna seu Programa mais portavel.
Além disso tem algo muito legal que aconteceu durante o desenvolvimento do Rubinius. A idéia de compatibilidade, o Rubinius priorizou testes automatizados em seu desenvolvimento, com isso usando os mesmos testes que o Rubinius fez é possivel avaliar a compatibilidade de vários interpretadores, ous eja, é dizer que um MRI 1.8 é compativel com MRI1.9 e compativel com RUbinius, etc. Isso da mais tranquilidade pois é possivel saber se um codigo escrito em Ruby sera bem interpretado por qualquer Interpretador Ruby.
JRUBY
Talvez essa seja a melhor opção hoje para interpretar código Ruby. O que é JRuby? JRuby é um esforço da comunidade e da propria SUM em possibilitar que o interpretador java reconheça código Ruby. A pergunta que nao quer calar! Porque a SUM deseja que o código ruby seja interpretador pela JVM? É porque a Linguagem Ruby é muito melhor que a linguagem Java, eheh, bem não é so por isso, a linguagem Ruby implementa muito bem outros paradigmas que a linguagem Java não é capaz, tais como meta programação, desenvolviemnto ágil, etc..
E o que Ruby ganha com isso? Toda a maturidade, velocidade, segurança da JVM. Sem falar que para a JVM chegasse a ser o que é hoje, formam investidos milhares de milhares dolares e tempo, e quando se executa seu programa Ruby sobre essa estrutura voce automaticamente se beneficia disso.
Outra vantagem é ser Enterprise, bem esse conseito inútil é muito respeitado belas grandes empresas, onde ter uma aplicação em uma linguagem conhecida é muito mais aceitavel que ter uma aplicação melhor em uma linguagem pouco conhecida, quando voce tem um programa Ruby sendo executado sobre a JVM, o programa normalmente é mais aceito. Sem falar que a maioria das empresas que exigem coisas Enterprise não sabem nada sobre tecnologia e seguem o fluxo de todas as outras, e ter a SUM dizendo que acredita em Ruby ja as deixa mais calmas e conformadas, eu sei que isso não é nenhum parametro tecnico mais é muito usado no mundo doente dos Enterprise.
O bom efeito colateral em usar JRuby é a possibilidade de usar toda as Bibliotecas, APIs, escritas em Java em seus programas Ruby, isso é legal até certo ponto, porém em alguns casos reduz a curva de resistencia em se usar uma nova linguagem, onde os programadores Java podem continuar usando sua bibliotecas Java em vez de ter que reescreve-las em Ruby, bem só o futuro dirá se isso é realmente uma boa idéias, eu escrevi um outro artigo falando sobre isso deem uma lida. Da Vinci Machine Project!
IronRuby
A idéia do IronRuby é fazer que o interpretador .NET da Microsoft reconheça código Ruby, este projeto também é mantido pela comunidade e própria Microsoft. Bem por mais estranho que pareça este projeto deveria ser bem melhor que o projeto JRuby, levando em conta que a VM .NET da Microsoft é bem mais preparada para executar linguagem dinamicas como Ruby. Porém é um projeto apagado e sem muitas grandes novidades, talvez pela antipatica que a comunidade retem pela Microsoft. Existem outras coisas, o projeto .NET é proprietário, fechado bem ao estilo Micro$oft, porém existe um outro projeto que é o Mono que nada mais é que a implementação da VM .NET em software livre, e o IronRuby é capaz de rodar também sobre Mono, mais mesmo assim a projeto IronRUby não decolou ainda, mais eu acredito bastante que seja viavél talvez não seja a melhor opção hoje mais no futuro pode se tornar algo interessante
MagLev
Uma estrela cadente! Talves essa seja a melhor imagem para descrever o Maglev. A idéia do Maglev e fazer o Interpretador GemsStone de Smalltalk reconhecer código Ruby. Essa idéia veio de Avi Bryant, o cara é muito bom. Tudo começou em um tempo em que a comunidade Ruby vinha sofrendo com a frase “Rails não escala”, e Avi Bryant disse, “Eu vim do futuro e sei como isso acaba”. Após isso ele me aparece na RubyConf com nada mais nada menos que a Maglev, puxou o Datashow e rodou alguns códigos Ruby sobre a GemStone, o que mais assuntou é que a Maglev chegou a ser 60 vezes mais rápida que o MRI, e algumas grandezas mais rápida que o JRuby. Isso criou um clima estranho, pois centenas de programadores estavam se dedicando em fazer o Jruby que é 2 ou 3 vezes mais rápido que MRI, ou Rubinus que é algumas vezes mais lento que o MRI.
Bem o mais legal é que Smalltalk e uma linguagem dinamica como Ruby, entao um interpretador de Smalltalk e quase a mesma coisa que um interpretador de Ruby, isso torna as coisas muito mais simples de serem feitas, diferente de Jruby que tem que fazer uma JVM interpretar código dinamico, que é muito dificil, a GemStone foi facilmente adaptada para rodar código Ruby com a mesma eficiencia que roda código SmallTalk.
O ruim de tudo isso é que a GemStone é um VM proprietária e tem custo para usa-la, e nao tem o código fonte aberto, tal como o MRI, JVM, Rubinus. Isso me preocupa, mais voltando ao pensamento Interprise pode ser uma solução viável apra alguma empresas.
Bem mais nem tudo são flores, o Avi Bryant, foi mostro o Maglev na RubyConf e depois sumiu, eu venho buscando mais coisas sobre Maglev e nao veja nada na comunidade, talvez seja esse o plano deles ser bombático sempre, mais isso deixa a gente sem rumo, ou pode ser que o projeto ta meio parado mesmo, bem vamos vem.
Este são os projetos mais conhecidos de Interpretadores e VM Ruby. Como o Ruby é OpenSource quanquer pessoa pode pegar o MRI e fazer algumas modificações, sendo assim pode existir vários outros projetos ai que eu não conheço, mais acredito que esses sejam os mais relevantes. Depois a gente fala mais sobre VM, para deixar mais claro as diferenças e caracteristicas de cada VM Ruby tais como Rubinius, Jruby, IronRuby, Maglev.
Valeu!!!
Comments
1 Resposta para “Interpretando o Ruby!”
Deixe um comentário
[...] claro a diferença entre anbiente de execução e instruções executadas. … fique por dentro clique aqui. Fonte: [...]