Acabei de ler o capítulo Ruby do livro 7 Languages in 7 Weeks . Além de um pouco de açúcar sintático aqui e ali, eu realmente não consigo ver nada que não possa ser feito com C # com uma sintaxe semelhante. Entendo que as duas linguagens são inerentemente diferentes, mas minha pergunta está relacionada ao uso, e não ao design.
Perguntas relevantes me fazem acreditar que Ruby oferece pouco mais que C #:
- Por que os programadores de c # não são atraídos para ruby como os programadores de java?
- O bloco de código do Ruby é o mesmo da expressão lambda do C #?
Eu quase não trabalhei com Ruby e meu entendimento da linguagem ainda é muito limitado; talvez alguém que tenha experimentado o .NET 4.0 e o Ruby possa responder com exemplos concretos.
Quais tarefas requerem significativamente menos trabalho com Ruby que o C # 4.0?
Ps: Esta questão foi encerrada no StackOverflow por ser muito subjetiva e argumentativa, embora atraísse alguma atenção. Eu esperava que fosse mesclado aqui, mas, em vez disso, terei que repassá-lo.
fonte
Respostas:
Ruby possui literais para expressões regulares e vários atalhos sintáticos úteis para a criação / interpolação de strings. Portanto, quando suas tarefas estão relacionadas principalmente à mistura de bits e partes de strings correspondentes, o Ruby pode exigir menos trabalho (mas fora dos scripts auxiliares curtos, devo admitir que essa é uma situação muito rara).
Mais relevantes são as instalações de metaprogramação do Ruby. ou seja
#eval,#define_methode amigos, que combinados comopen classes,#includee#extendpermitem criar toneladas de código padrão em tempo de execução - você pode argumentar que os geradores / assistentes de código oferecem alguns dos mesmos benefícios, mas você tem que conviver com - quantidades possivelmente muito grandes - do código da placa da caldeira gerado, em comparação com uma quantidade relativamente pequena de código de metaprogramação que você teria que ler e entender.Um caso de uso típico para isso é ter que fazer interface com algum tipo de provedor de dados dinâmicos fora do seu aplicativo. O Rails ActiveRecord é um bom exemplo disso.
No futuro, isso pode ser muito benéfico para o desenvolvimento de GUIs, pois você pode gerar métodos manipulando eventos a partir de elementos da interface do usuário criando métodos durante o tempo de execução com base no ID, tipo, valores de entrada dos elementos da interface do usuário etc. (como Objective-C em esteróides, talvez veremos um pouco desse poder quando o MacRuby amadurecer).
A linha entre bom uso e abuso horrível desse recurso, porém, é muito fina e tende - pela minha experiência - a ser uma das principais causas de dores de cabeça em grandes projetos Ruby (on Rails). Portanto, tenha cuidado ao decidir liberar o Djinn da sua garrafa :)
fonte