Você esta dizendo então que a impossibilidade de fazer o mesmo em Java (codigo de 1 linha) é uma funcionalidade da linguagem, ao invés de uma limitação???
[quote=mochuara]
Você esta dizendo então que a impossibilidade de fazer o mesmo em Java (codigo de 1 linha) é uma funcionalidade da linguagem, ao invés de uma limitação???[/quote]
Cara, na minha opinião, escrever código em uma linha não é vantagem, pois, no meu ponto de vista, se esta possibilidade for mal empregada, prejudica demais a legibilidade. Foi o que achei do código dos números aleatórios. Acho que o Kung tentou, em um evento Java, mostrar a força do Ruby. Mas, para mim, o efeito foi negativo, pois aquela lógica, em particular, achei muito confusa.
E, sim. Acho que se você quiser, pode encapsular tudo em APIs e resolver questões complicadas (em Java) de forma mais simples.
Esta API foi só um exemplo, tenho várias outras que facilitam a minha vida. Uma delas é a DateUtility, que facilita a vida no trabalho com datas.
Estou em processo de formação de amizade com o SourceForge para disponibilizar as minhas APIs. =)
Por enquanto, SourceForge 2, Celso 0. =D
Não, Ruby não tem melhor implementação de nada. Metaprogramação é muito útil, mas vai muito além de alterar classes em tempo de execução.
Usar o Extrair Método, ao meu ver, diminui o código dentro de um método, o deixando mais legível. Separa mais o teu código, fazendo que a pessoa leia menos coisas diferentes por bloco de código, e entenda mais rápido o que ele faz e onde ela pode mudar.
No geral pode ser que para cada método extraído você crie duas ou três linhas a mais, mas o importante é que essas linhas não atrapalhem a leitura. Eu digo que é melhor ter 20 métodos de 50 linhas(total 1000) que um super método de 900. Eu vou contar que normalmente dentro dessas god-classes você encontra muito código repetido, o que diminui o tamanho de tudo no final quando arrumado.
O mesmo digo para esse código livre de construções da linguagem que atrapalham o entendimento (chamem isso de condensado se quiser) . É melhor ser conciso e preciso, comunicar-se de maneira breve, que enrolar e delongar, escrever demais.
Um adendo: NÃO estou dizendo que o objetivo final é condensar tudo. Passar do ponto de breve para brevíssimo estraga tudo. Como tudo, devemos usar em moderação.
O Einstein tinha uma frase perfeita para o que quero dizer (e acabei me delongando também):
Make everything as simple as possible, but not simpler.
temos bastante coisa em rails aqui na Caelum tbm, varios projetos.
e estamos nos aventurando em scala tbm. um modulo de um dos sistemas principais aqui foi feito em scala.[/quote]
Esse dinamismo da Caelum é muito interessante. Parece a ThoughtWorks brasileira. =D
[quote=Bruno Laturner]Usar o Extrair Método, ao meu ver, diminui o código dentro de um método, o deixando mais legível. Separa mais o teu código, fazendo que a pessoa leia menos coisas diferentes por bloco de código, e entenda mais rápido o que ele faz e onde ela pode mudar.
No geral pode ser que para cada método extraído você crie duas ou três linhas a mais, mas o importante é que essas linhas não atrapalhem a leitura. Eu digo que é melhor ter 20 métodos de 50 linhas(total 1000) que um super método de 900. Eu vou contar que normalmente dentro dessas god-classes você encontra muito código repetido, o que diminui o tamanho de tudo no final quando arrumado.[/quote]
Desculpa alterar o seu quote, mas precisei destacar o parágrafo que considero muito importante.
Eu também acredito nisso. Acredito muito na modularização e nos níveis de encapsulamento propostos por Page-Jones em seu livro.
O que eu acho (posso estar errado) é que essa história de código em uma linha vai justamente na direção contrária a um código modularizado que proporciona melhor legibilidade, já que agrega muita lógica (condensa) em uma linha. A lógica que era dividida se une em prol de uma quantidade menor de linhas. Acho isso estranho.
EDIT: ENCAPSULAMENTOS para ENCAPSULAMENTO
Concordo também, uma linha pra muita coisa chega a esse ponto em que a pessoa exagerou.
Igual como colocar vários operadores ternários encadeados. Eu refiro usar vários ifs e elses no lugar deles.
[quote=Bruno Laturner]
Concordo também, uma linha pra muita coisa chega a esse ponto em que a pessoa exagerou.
Igual como colocar vários operadores ternários encadeados. Eu refiro usar vários ifs e elses no lugar deles.[/quote]
Exatamente.
A linguagem que quer se gabar em escrever menos código para uma determinada coisa, deveria dispor de um método assim (dentro do exemplo que venho dando):
GiveMeARandomNumberBetween(1,100);Não escrever 150.000 instruções em uma única linha.
E o melhor de tudo é, se eu quiser, posso escrever o método acima em Java e coloca-lo numa classe como MinhaMath, tranquilamente.
Eu também acho isso. Da minha experiencia sempre que alguem tenta condensar o codigo dá m#$@#$.
AS boas práticas mandam excatamente o contrário, como vc disse. Código bom é aquele que se lê fácil sem o auxilio de comentários.
Isso não significa que código bom é aquele que é curto. “ler facil” = “entender com facilidade” e não “ler em pouco tempo”
A metaprogramação do ruby não é nada de unico e portanto não argumento para preferir Ruby. A razão para alguem usar Ruby sem usar Rails é … ? Nenhuma. Nada tem peso suficiente para justificar o uso de ruby. A meta programção vc pode fazer com Groovy ,por exemplo. Sem sequer ter que usar uma sintaxe diferente da do java.
A justificativa do povo da JRuby para a criação é que : a VM original é lenta , muito lenta. A linguagem ruby é “bonita”. Ora, isso não são argumentos sérios. Os argumentos reais são : A VM original é uma m#$%#$% e o RoR correria muito melhor se fosse em cima de uma JVM usando toda a API de java e infraestrutura que ela oferece ( como concurrencia e threads). O problema é que a implementação é uma gambiarra só…
O ponto é : Como tecnologia ruby é inutil. Ele só é conhecido por causa do rails. Mas outras implementações “rails” existem sem usar ruby e mais proxima do universo java ( o Grails). Não ha justificativa tecnica ou economica para usar Ruby quando vc conhece Java. Se vc veio do PHP ou do C ou outra coisa, até que vai, mas se vc veio do Java a evolução natural é usar Groovy e não Ruby. Se quer framework faz-tudo tem o Grails. Além de que Groovy serve para bem mais coisas como mexer com xml, com o ant e até escrever scripts para o OS e substiuir os .bat da vida. Isso são razões tecnicas para não migrar para Ruby. Fora que em Groovy vc reaproveita todo o codigo “utilitário” que já tem implementado.
Além disso vc pode migrar para Scala ou qualquer coisa que venha por ai, mas o ponto da questão é que migrar para fora da JVM para quem desenvolve em Java é suicidio tecnico. É como passar a usar C++ de novo. No máximo migra para JRuby e olá lá… ah! pois é, o RoR - ainda - não corre em JRuby…
Já roda sim. Só se quebram de novo e não fiquei sabendo.
Interessante esta discussão!
Quando ouço falar de Ruby não consigo evitar de lembrar das linguagens XBase (DbFast, Clipper, Joiner - brasileiro, FoxPro, etc…) da decada de 80 :shock: .
Até uma coisa semelhante ao tal do clouser um deles possuia (clipper), o nome éra codeblock; éra muito bom, porem permitia muitas ciladas também.
O discurso era o mesmo “Escreva menos linhas!”, “Escreva linhas mais legiveis!”, “Tenha maior produtividade!” e etc…
Você pode / podia abrir uma arquivo com uma linha “use nome_do_arquivo”, mais simples e mais legível que isso quase impossível.
Eu não gostava e ainda não gosto destas linguagens, questão de perfil; gostava de Pascal e linguagem C. Aliás em linguagem C vc consegue montar expressões bem pequenas mas pra ler e entender depois fica bem difícil.
As linguagens XBase na minha opinião surgiram e até emplacaram com uma promessa semelhante mas morreram, e olha só quem ficou por aí. Cobol, Pascal, C justamente aquelas linguagens que “necessitavam” um pouco mais de linhas, muito estranho.
Será que as linguagens XBase, Scala, Ruby e etc… são frutos da dificuldade das pessoas em dominar a arte de programar e construir sistemas ? :shock:
flws
Olá
Lendo algumas opiniões neste tópico me lembrei do tempo em que escrevia programas em assembler ou mesmo em linguagem de máquina para antigas calculadoras de mesa.
Que mal tem uma linguagem permitir comandos mais poderosos? E para mim não importa se este comando é como no Scala onde praticamente tudo é resolvido por debaixo dos panos através de uma chamada de função ou se o comando é traduzido direto em linguagem de máquina, assembler, bytecode ou sei lá o que for.
Vou dar um exemplinho de comando limitado no Java:
Alguém aqui sente falta de um switch / case no Java que permita testar Strings? É óbvio que a gente pode sobreviver só testando char, int e outros poucos ou até mesmo nunca usar switch case. Mas para mim seria mais intuitivo testar Strings. E para criadores de algumas outras linguagens também.
Quando a gente aprende Ruby encontra centenas de casos assim de coisas que em Java necessita escrever mais código. Python também permite coisas interessantes. Quando aprendi Scala ainda encontrei algumas coisas que mesmo depois de mais de 10 anos que aprendi Java, não tenho a menor idéia sobre como fazer. E ao estudar Erlang quase só encontrei novidades (senti falta de muitas coisas do Java).
Se alguém ainda tem dúvidas quanto ao que escrevi sobre comandos poderosos de uma linguagem uso um exemplo do próprio Java. Criem na raça em C (não é C++) uma Linked List e vejam como é bom ter isto embutido na API do Java.
[]s
Luca
Não, Ruby não tem melhor implementação de nada. Metaprogramação é muito útil, mas vai muito além de alterar classes em tempo de execução.[/quote]
Você é novo no Java né?
Não pegou a época do XML hell, Struts, Spring, EJB, etc.
A questão não é ir além, mas consertar o problema em questão, ou pelo menos oferecer uma solução.
Faz parte da arte escolher a melhor linguagem pra cada problema. Tá parecendo uns programadores iniciantes que eu conheço que acham que usar framework é ‘roubar’, que o bonito é fazer tudo na mão.
De acordo com o que disse e não tenho dúvidas acredite!
Já construi Linked List em Pascal (Turbo Pascal vrs 3.0, 5.5 ) e C versão 5.0 da Microsoft em DOS, debugger só em Pascal e não havia GOOGLE (ainda bem que tudo isso já passou), pelas versões dá para perceber que faz bastante tempo isso rsrsrs. Obviamente ter isso de “mãos beijadas” em Java (e em XBase) é muito bom. O que me deixa curioso é o discurso…é o mesmo dos anos 80, e como já foi dito antes, talvez só isto não seja o bastante (ao menos para mim no momento) para migrar para uma desta linguagens.
Obviamente que estou de olho no mercado, atento a estas questões; programava em Basic Z80 para 8 bits e hoje trabalho com Java, não vai ser agora que vou “dormir de touca” né?
flws
Sério que tem gente que pensa assim?
Vai ver isto seja resultado do nível de ensino ruim nas universidades que não ensinam o real valor de se utilizar / construir componentes.
flws
Aproveitando o tópico, aqui vai uma apresentação do Martin Fowler contando sobre suas experiências depois de 3 anos usando Ruby na ThoughtWorks.
[quote=Luca]
Se alguém ainda tem dúvidas quanto ao que escrevi sobre comandos poderosos de uma linguagem uso um exemplo do próprio Java. Criem na raça em C (não é C++) uma Linked List e vejam como é bom ter isto embutido na API do Java.
[]s
Luca[/quote]
Luca, usando o exemplo que você deu, se, em Java, você não tivesse LinkedList e pudesse implementar a lógica na mão, nada impediria de criar uma classe e jogar essa lógica lá dentro e usar o resto da sua vida. Eu fazia isso em Clipper, criando bibliotecas de função, principalmente para desenho das telas e dos menus. =)
Cara, quase pegou o /370 hein. =D
Eu brinquei um pouco com o Basic do TK 2000 II de 85 a 90. Bons tempos…
Olá
Pois é, eu também fazia. É tão bom já ter tudo pronto e poder se concentrar mais no problema a resolver.
Eu peguei o /370. Mas isto foi quando já desenvolvia sistemas há um bom tempo. Comecei com um IBM 1130 da Escola de Engenharia UFRJ. Na época um programa com 1000 linhas era meio grande. E linhas de Fortran são muito menos poderosas do que linhas de Java. Mas um programa gastava pouca memória. A ponte Rio Niterói foi calculada com um programa de menos de 3000 linhas e que ocupava metade da memória do computador, isto é, ocupava 4 Kb
[]s
Luca
Sim, acho isso sensacional. Comandos poderosos são interessantes e não os descarto. O meu questionamento é justamente o contrário. Que vantagem eu levo em colocar 6, 7 comandos na mesma linha?