Olá
Antes de chamá-lo de idiota, lembrem-se que o autor Elliotte Rusty Harold é professor do Computer Science Department da Polytechnic University em Brooklyn. É autor de 18 livros de Java e de XML (tem gente que acha escrever livros fácil e sem valor), palestrante em muitos eventos e também dono do Cafe au Lait que é um dos sites mais antigos sobre a tecnologia Java.
[]s
Luca
Legal, concordo plenamente.
O ponto de vista que ele adotou, de um implementador de bibliotecas/frameworks/serviços, ele está certo. No entanto, um contra-argumento análogo poderia ser aplicado para justificar o que um desenvolvedor Ruby não gosta em Java: “Como um implementador de interfaces gráficas/sistemas dinâmicos com o usuário …”.
Não vejo isso como um problema em clareza de código. Acho que fica até mais intuitivo.
…
Pointless, Java também está cheio de métodos com nomes duvidosos.
Acho que isso é mais uma questão de compatibilidade com linguagens aparentadas do C e considero isso uma vantagem, além de um argumento vazio.
Gaaahhh!! PL/SQL? Ponto para o tio Elliotte.
Caracteres estranhos, como $, _, @ ou @@, suck! Podem dizer que é questão estética, mas acho muito improdutivo ter que usar estes caracteres malucos em Ruby. E, sinceramente, preferiria usar uma palavra-reservada (como static ou global) ao invés de usar $. Sim, eu já ouvi falar em convenções de código, mas acho que tudo isso tem limite.
O que ele propõe dá para se implementar usando modules, não apenas classes. Além disso, se nós ficarmos restritos apenas à OO clássica, mixins poderiam ser consideradas aberrações/heresias, uma vez que você altera a interface da instância de uma classe em tempo de execução conforme a sua vontade. Então, talvez seja preciso rever conceitos…
Hmmm… O argumento anterior se aplica a este. Sinceramente, não vejo isso como um problema. Além disso, em Ruby, todo método “private” se comporta como se fosse um método “protected” em Java. Ruby não tem métodos private de verdade (e não vejo isso como problema).
Achei interessante o artigo, mas todo artigo deste tipo comete sempre o mesmo erro: analisar uma tecnologia usando os olhos de outra. No caso, alguém está analisando Ruby com os olhos de um desenvolvedor Java e isso é uma falha (a recíproca é verdadeira - entendeu, Thiagosc?). Ruby introduz outro tipo de filosofia de desenvolvimento bem diferente do Java. Nem melhor, nem pior, talvez complementar, mas diferente. E isso é preciso ser levado em conta.
Olá
Só para lembrar, ele fez este mesmo tipo de critica ao Java em 2002. Vejam:
10 Reasons We Need Java 3.0
[]s
Luca que não concorda nem discorda porque não manja de Ruby
[quote=Luca]Olá
Só para lembrar, ele fez este mesmo tipo de critica ao Java em 2002. Vejam:
10 Reasons We Need Java 3.0
[]s
Luca que não concorda nem discorda porque não manja de Ruby
[/quote]
O carinha gosta de top-10 lists. Desta outra listinhas, acho apenas que o quinto item não faz muito sentido nem muita diferença.
Não é lá uma lista de 10 tragédias…
aprendi um pouco de ruby, mas tem tanto troll usando ruby que eu acabei dando uma parada. Eu acho interessante aprender, mas assim, acho que para quem ja sabe java etc, eh bem rapido aprender
[quote=Daniel Quirino Oliveira]Achei interessante o artigo, mas todo artigo deste tipo comete sempre o mesmo erro: analisar uma tecnologia usando os olhos de outra. No caso, alguém está analisando Ruby com os olhos de um desenvolvedor Java e isso é uma falha (a recíproca é verdadeira - entendeu, Thiagosc?). Ruby introduz outro tipo de filosofia de desenvolvimento bem diferente do Java. Nem melhor, nem pior, talvez complementar, mas diferente. E isso é preciso ser levado em conta.
[/quote]
Pelo menos é bem mais razoável do que afirmações esdrúxulas como “Java is dead”, ou FUD sobre “complexidade” do Java, ou contagem de keystrokes como sinal de “bom”, ou desdém por IDEs e ferramentas que auxiliam no desenvolvimento, ou coisas do gênero.
Foi um artigo mais adulto do que tudo que eu já li de um programador Ruby comentando sobre Java. Todas as coisas “ruins” de Java, segundo esses, ou são exageros absurdos (como fazer EJB para simples webapps usando o notepad) ou argumentos não-técnicos (como “tudo muda… a mudança é boa… mude você também”).
Só um comentário, não me agradam linguagens que não fornecem proteção adequada. Eu, como desenvolvedor, quero ocultar funcionalidades e dados em classes, isso é básico de OO e fornece segurança. Pensar que o “a documentação diz o que pode ser feito” e confiar somente nisso é no mínino “o cúmulo do fanboy”. Não querer admitir que um método reescrito pode afetar sua aplicação de maneiras catastróficas e achar que “bons desenvolvedores não erram” parece mais infantil, vindo diretamente da escola técnica com 15 anos de idade e zero de experiência profissional, do que adulto.
Não é isso o que tem se visto não. Ao contrário do que você diz, tem havido muito FUD pra cima do Ruby/Rails, querendo caracterizar como ferramenta insuficiente para o que as pessoas precisar. Vide declaração recente do James Gosling, que falou que Ruby só servia pra fazer sites.
[quote=ZehOliveira]
Não é isso o que tem se visto não. Ao contrário do que você diz, tem havido muito FUD pra cima do Ruby/Rails, querendo caracterizar como ferramenta insuficiente para o que as pessoas precisar. Vide declaração recente do James Gosling, que falou que Ruby só servia pra fazer sites.[/quote]
1 - Ele não disse nada demais, afinal de contas a maioria das pessoas que usam Ruby usam-no para fazer websites, e em várias outras funções ele não seria o mais adequado;
2 - Você precisa prestar mais atenção nos artigos estilo “Java is dead” (e tem um tópico sobre um deles aqui nesse fórum mesmo) e ver o tamanho das asnices lá descritas. Eu uso apenas o que preciso do Java, mas tem gente que faz questão de citar o EJB e outros absurdos descomunais (sobre “como foi difícil configurar o Tomcat… logo RoR RuLeZ!!!111” ou “deprecate? Que ridículo. Homens de verdade reescrevem suas aplicações sempre que sai uma versão nova”). Sempre com a lenda urbana de que só idiota usa Java, e todos desenvolvedores Ruby são gênios (acho que eles nunca pararam para pensar que existem pessoas que escolheram Java de livre e espontânea vontade, pelas qualidades da plataforma).
Meus 2 cents…
Eu acho que a tipagem poderia ser escolhida pelo programador, como acontece em Groovy, acho que existe lugar pra ambos.
Algumas bizarrices do Ruby, como a famigerada variável global $_ são realmente terríveis, mas a própria comunidade afirma que usar essas coisas não é bom e isso pode ser retirado de versões futuras da linguagem
“elsif” é sofrível.
Returns automáticos também não são lá muito úteis na minha opinião, só com muito costume você “pega” o que está contecendo no código e isso vai de encontro a “expressividade” do código Ruby.
E se eu pegar uma linguagem de programação onde o array começa com 1, eu não programo nunca mais nela 
Olá
[quote=Maurício Linhares]E se eu pegar uma linguagem de programação onde o array começa com 1, eu não programo nunca mais nela
[/quote]
Praticamente tudo que ganhei na vida foi com Fortran que usei pelo menos de 1969 até 1985 (ou mais um pouquinho). Atualmente estou mexendo em uma antiga aplicação de cálculo não linear de estruturas suportadas por cabos totalmente escrita em Fortran.
O Elliot é engenheiro como eu. Deve ter programado muito aplicações científicas onde o uso de arrays é fundamental. Na natureza a contagem começa por 1, assim é mais direto mapear entidades físicas com arrays começando por 1.
Na verdade Arrays em Java são diferentes de arrays em Fortran. Em Fortran um array de 2 dimensões é uma matriz. Lá na escolinha da Dona Peteca a gente aprendeu que o primeiro termo de uma matriz é 1,1. Matrizes são elementos básicos em cálculos de engenharia.
Em Java um Array de 2 dimensões na verdade é um array de 2 arrays. Não obrigatoriamente são matrizes.
[]s
Luca
Acho que isso é questão de costume, já devem fazer uns 2 anos que eu não “vejo” matrizes, mas programei muito em linguagens “C like”, então pra mim é muito mais natural “aceitar” que arrays começam no 0 da mesma forma que eu acho os returns automáticos do Ruby esquisitos 
Pergunta de ignorante curioso: Matrizes em Fortran são sempre “quadradas”, por exemplo, 3x3, 4x4, etc?
Quanto ao artigo, eu estou enrolando para aprender Ruby de vez, mas eu me enganei em algum ponto ou não dá pra fazer override de métodos?
Olá
Não, podem ser também retangulares. E ter mais dimensões também, se bem que depois da 3a fica sem sentido físico e com pouca performance.
O sistema que estou trabalhando era otimizado para máquinas limitadas. Ele demorava somente 2 horas para resolver cerca de 1000 equações em um 286 de 16MHz. Mas este é exatamente o motivo do meu atual sofrimento. O que era ótimo antigamente hoje é péssimo.
Toda a memória disponível é mapeada para um arrayzão. O programa o tempo todo faz endereçamento indireto colocando as variáveis nas áreas que estão livres. Quando as variáveis não são necessárias na memória elas vão para o disco abrindo espaço para outras. Eu agora estou apanhando porque nem sei mais onde guardei a documentação e por falta de prática levo surras do Fortran. Não sei onde estava com a cabeça quando não segui os conselhos da minha mãe e não fiz concurso para um emprego público daqueles com aposentadoria integral. :oops:
[]s
Luca
Você embassa demais os defeitos de Java e super expõe os de Ruby. Quando Gosling dá uma declaração infeliz pra influência que tem dizendo que Ruby só serve pra fazer site, você fala que ele não disse nada demais. Mas se alguém de Ruby faz cara feia pra Java, você só não chama de bonito. Deixa pra lá, tou alimentando troll assim.
[quote=Maurício Linhares]Meus 2 cents…
Eu acho que a tipagem poderia ser escolhida pelo programador, como acontece em Groovy, acho que existe lugar pra ambos.
[/quote]
A tipagem do Groovy é estática, porém implícita (i.e., não requer uma declaração explícita de tipo).
[quote=Luca]Olá
10 Things I Hate About Ruby
Antes de chamá-lo de idiota, lembrem-se que o autor Elliotte Rusty Harold é professor do Computer Science Department da Polytechnic University em Brooklyn. É autor de 18 livros de Java e de XML (tem gente que acha escrever livros fácil e sem valor), palestrante em muitos eventos e também dono do Cafe au Lait que é um dos sites mais antigos sobre a tecnologia Java.[/quote]
Bom, respeito a opinião do cara, mas discordo em muitos pontos.
Não faria sentido em ruby o método se chamar new. Quando o initialize foi chamado, o new já executou. A lógica é que o new, chama o initialize. E em ruby, o new na verdade executa todo o blobo da classe, então se eu tiver uma classe assim:
class Teste
puts "Ola Mundo"
end
Quando eu chama Teste.new vai aparecer “Ola Mundo” na tela. Então, a lógica é o new executa o bloco de código da classe e depois chama o initialize, que pasmem inicializa um objeto JA criado, e não cria um objeto. Então, na minha opinião, a semantica está correta.
“Weak typing” é o que dá um poder tremendo ao Ruby, e sim, têm as suas desvantagens e as suas vantagens também.
Me sorry, mas se ele quer um linguagem fortemente tipada essa não é o Ruby. Simplemente não é. Procure outra ou utilize java. E viva as diferenças.
No inicio eu achava estranho também, mas confesso que hoje eu gosto. Mas não ficaria triste se fosse diferente.
Por ser de fraca tipagem, vc nunca define qual, e se o metodo têm retorno, por isso você é obrigado a sempre retornar alguma coisa, mesmo que seja nil.
Variaveis globais em ruby são pertecentes a modulos que você importa. Seria mais ou menos como static imports do Java 5.
:? Na boa? Nada a ver. Se for para começar a discutir nome de métodos… Só uso o Calendar para isso.
Novamente questão de gosto. Sugar sugar sugar.
É isso é estranho mesmo.
Lembre-se sempre que Ruby é um linguagem de script, muuuito utilizado em shell. E quando se trata de fazer scripts shell essas variaveis globais são uma mão na roda. Se voce for usar rails, apenas ignoreas.
Qual o problema disso? Em ruby, que é um linguagem de script. Em 99% do tempo você tá fazendo metodos publicos. Por não ser default se vai facilitar? E é tão simples sair do normal. Segue abaixo um exemplo de classe só com publicos e outro com publicos e privados
[code]class SoPublico
def methodo1
end
def methodo2
end
def methodo3
end
end[/code]
[code]class PublicoEPrivado
public
def methodo1
end
def methodo2
end
private
def methodo3
end
def methodo4
end
end[/code]
Complicado?
Como assim? Em ruby metodos podem ser private, public e protected…
[quote=juzepeleteiro]
Como assim? Em ruby metodos podem ser private, public e protected…[/quote]
Não é bem assim. Ruby não tem membros “private” como em Java. “private”, em Ruby, é análogo ao “protected” do Java.
[quote=Daniel Quirino Oliveira][quote=juzepeleteiro]
Como assim? Em ruby metodos podem ser private, public e protected…[/quote]
Não é bem assim. Ruby não tem membros “private” como em Java. “private”, em Ruby, é análogo ao “protected” do Java. [/quote]
Aew? Preciso dar mais um estudada nisso…
São boas observações, mas achei muito superficial.
Reclamar do puts? Tsc…