Arquivo Discussoes de Programacao e Tecnologia Acabei de escrever um texto no meu blog, comentando o post de James Strachan sobre a possível substituição do Java pelo(a) Scala. Comentei, também, sobre a “alta produtividade” do Ruby que vi pelas mãos do Fábio Kung, no último Falando em Java.
Enfim, a jugular está pronta, mas venham devagar, sou pai de um menino lindo. =)
http://celsoavmartins.blogspot.com/2009/07/scala-vai-substituir-o-java.html
Abraços
bem, pelo pouco que codifiquei em ruby, realmente achei mais produtivo que java. Mas vale ressaltar que nem sempre produtividade está no topo, principalmente quando afeta qualidade. Mas, sei muito pouco de ruby pra falar, só sei que a linguagem é bem cômoda.
Mas é verdade também que muitas pessoas tendem a usar uma linguagem para os mais diferentes tipos de projetos. Isso realmente é uma coisa descabida. Todos nós sabemos que cada uma tem seu uso específico.
Sineramente?
Fiquei com medo da “única linha” que o Kung fez para - somente - gerar números aleatórios. :lol:
huahuahua…realmente, isso em c ou php, o que quer que seja, a gente pode fazer tmb uai:
#include int main(){ for(std::cout << rand() % 100 <<endl; return 0; } //números entre 0 e 99int i=0;i<100;i++)
Você tem razão.
Cara Scala não vi substituir o java, o Foco de Scala é outro completamente diferente.
Quanto ao Ruby, ele é bacana mesmo, mas nem sempre é a melhor escolha.
Só dei uma olhada no Scala, não me apeguei muito pois gostaria de aprender outra linguagem que não seja Java-style de programação hehehe.
[]'s
Sineramente?
Fiquei com medo da “única linha” que o Kung fez para - somente - gerar números aleatórios. :lol:
Aquela que não saia números acima de 300 nem a pau? :twisted:
Acho que atende as mesmas necessidades, e de uma maneira mais adequada com seu modelo de atores. Cai como uma luva para o mundo empresarial, ou pelo menos força e mente do desenvolvedor a trabalhar menos acoplado.
Olha um dos parágrafos do post do James:
Aquela que não saia números acima de 300 nem a pau? :twisted:
huahauhauhauhauhauhuah
A própria. No próximo evento, chegarei apenas a alguns minutos do início.
A performance do Scala é realmente tão boa assim como ele cita?
não mechi muito no scala então não sei dizer, so fiz alguns hello worlds, e um programação estruturada uhaahuuhauhahuahu
Sinceramente, eu nem sabia que existia isso(Scala). Vou dar uma pesquisada, e ver como funciona.
huahuahua…realmente, isso em c ou php, o que quer que seja, a gente pode fazer tmb uai:#include int main(){
for(std::cout << rand() % 100 <<endl; return 0; } //números entre 0 e 99int i=0;i<100;i++)Você tem razão.
Em C++ é preciso mais do que isso para gerar números aleatórios… o segredo para gerar números aleatórios é a semente. Gerado por algo que tenta simular algo aleatório e não repetitível.
Se vc rodar esse código várias vezes o resultado sempre será o mesmo.
Nessa de números aleatórios, poderiam tentar o http://www.random.org/
Mas como a gente faz programa, fazer o que… 
huahuahua…realmente, isso em c ou php, o que quer que seja, a gente pode fazer tmb uai:#include int main(){
for(std::cout << rand() % 100 <<endl; return 0; } //números entre 0 e 99int i=0;i<100;i++)Você tem razão.
Em C++ é preciso mais do que isso para gerar números aleatórios… o segredo para gerar números aleatórios é a semente. Gerado por algo que tenta simular algo aleatório e não repetitível.
Se vc rodar esse código várias vezes o resultado sempre será o mesmo.
claro que sim, mas, somente quando essa semente sair da memória. Enquanto o código rodar, gerará diferentes números. O objetivo do código é gerar números entre 0 e 99. Se vc rodar, vai ver que ele faz exatamente isso.
correção:
#include int main(){ for({srand(i);std::cout << rand() % 100 <<std::endl;} return 0; }int i=0;i<100;i++)
Nossa, quanta diferença. rs
huahuahua…realmente, isso em c ou php, o que quer que seja, a gente pode fazer tmb uai:#include int main(){
for(std::cout << rand() % 100 <<endl; return 0; } //números entre 0 e 99int i=0;i<100;i++)Você tem razão.
Em C++ é preciso mais do que isso para gerar números aleatórios… o segredo para gerar números aleatórios é a semente. Gerado por algo que tenta simular algo aleatório e não repetitível.
Se vc rodar esse código várias vezes o resultado sempre será o mesmo.
claro que sim, mas, somente quando essa semente sair da memória. Enquanto o código rodar, gerará diferentes números. O objetivo do código é gerar números entre 0 e 99. Se vc rodar, vai ver que ele faz exatamente isso.
correção:
#include int main(){
for({srand(i);std::cout << rand() % 100 <<std::endl;} return 0; }int i=0;i<100;i++)Nossa, quanta diferença. rs
Continua gerando números iguais… rs…
Nessa de números aleatórios, poderiam tentar o http://www.random.org/Mas como a gente faz programa, fazer o que… ;)
Realmente… se for para aplicações sérias o melhor é usar bibliotecas específicas… esse é o problema/solução do C++… muitas alternativas… muitas escolhas…
Nessa de números aleatórios, poderiam tentar o http://www.random.org/Mas como a gente faz programa, fazer o que… ;)
Realmente… se for para aplicações sérias o melhor é usar bibliotecas específicas… esse é o problema/solução do C++… muitas alternativas… muitas escolhas…
Rs… “The randomness comes from atmospheric noise”… pensei que era uma biblioteca…
Prq vc reinicia o programa em vez de aumentar a quantidade de números:
Mas assim:
srand(time(NULL)+i);
ou
srand(Time.msec());
Ae vai do seu framework. Eu uso qt aqui.
Prq vc reinicia o programa em vez de aumentar a quantidade de números:
Mas assim: srand(time(NULL)+i); ou srand(Time.msec()); Ae vai do seu framework. Eu uso qt aqui.</blockquote>Essas funções são ansi, então são independentes… só espero que você não esteja usando a semente(tempo) para para algo que precise ser realmente aleatório… tal como criptografia/sorteios/etc.
Precisei ir na Wikipedia pra descobrir o que era jugular. 
Eu estou iniciando meus estudos em Scala e, pelo pouco que eu vi, não tem essa de Java e Scala atenderem propósitos diferentes, Scala é realmente a linguagem para ser usada no lugar de Java, pois aquela é muito superior e muito mais moderna.
Sabia que, com Scala, uma classe com “getters” e “setters”* seria assim?
import java.util._
class Pessoa(var nome: String, var cpf: String, var dataNascimento: Date)
Nada das zilhões de linhas que é em Java.
Seria o que o C++ foi para o C, quando Scala introduz programação funcional à plataforma.
Também acredito que no futuro, a tendência é Scala virar uma forte candidata à projetos Enterprise, como construção de frameworks, containers e por aí vai. Para a implementação de negócio, ficaria com algo mais leve como Ruby, que é uma delícia de programar e vicia !!
Prq vc reinicia o programa em vez de aumentar a quantidade de números:
Mas assim: srand(time(NULL)+i); ou srand(Time.msec()); Ae vai do seu framework. Eu uso qt aqui.</blockquote>Essas funções são ansi, então são independentes… só espero que você não esteja usando a semente(tempo) para para algo que precise ser realmente aleatório… tal como criptografia/sorteios/etc.
Acho que voces estao confundindo aleatorio com unico. Aleatorio nao quer dizer que nao repete, aleatorio é aleatorio mesmo. Tipo um numero aleatorio entre 1 e 10 = 6; Outro numero aleatorio entre 1 e 10 = 6; Isto é aleatorio. Voce nao sabe qual vai ser e pode ser qualquer um entre 1 e 10.Acho que a discussao de voces seria “Aleatorio que nao se repete”. ou aleatorio unico.
Olá
Gosto muito de Ruby que é MUITO mais produtiva do que Java para escrever código novo. Gosto também bastante de Scala que permite fazer as mesmas coisas (ou um pouco mais) que o Java faz porém escrevendo muito menos linhas. Não é só a redução de linhas que me seduz. É que o código fica mais condensado nas questões relativas ao problema a resolver.
Ruby é bem mais fácil de aprender do que Scala (e tem muito mais fontes de estudo). Em compensação Scala, com sua tipagem estática não exige tantas linhas de testes quanto Ruby (que exige testar tudo e mais um pouco).
Ambas as linguagens permitem escrever código que roda na JVM. Nenhuma das duas atende 100% ao JIT que é otimizado para a semântica do Java. Mas Scala é mais próxima do Java e parece ser mais fácil de ser domesticada pela JVM. Dificilmente JRuby redundará em bytecodes tão bons quanto os oriundos de código Java.
Pelo parágrafo anterior alguém poderia concluir que recomendo Scala ao invés de JRuby. A conclusão não estaria de todo errada se não fosse pelo fato de que o uso de Ruby é muito mais difundido e muito mais gente sabe trabalhar com ele e com os gems disponíveis para ele.
Pode ser que esta situação mude daqui a alguns meses e eu acho mesmo que vai mudar com mais gente estudando Scala. Mas não acredito que Scala um dia chegue a ter a mesma popularidade do que o Ruby.
O melhor dos mundos já existe. Muito dos experts em integração de sistemas já concluiram que usar RPC atualmente é uma idiotice e que sistemas diferentes podem se integrar e escalar sem repetir erros dos tempos do CORBA. Hoje é fácil e possível usar a ferramenta adequada a cada problema e integrar de maneira simples sem manter estado e sem precisar de consultor SOA ou de WSDL, SOAP, UDDI, repositório, etc. O exemplo que me fez escrever este parágrafo é o SOLR que disponibiliza o LUCENE para código escrito em qualquer linguagem.
[]s
Luca
Prq vc reinicia o programa em vez de aumentar a quantidade de números:
Mas assim: srand(time(NULL)+i); ou srand(Time.msec()); Ae vai do seu framework. Eu uso qt aqui.</blockquote>Essas funções são ansi, então são independentes… só espero que você não esteja usando a semente(tempo) para para algo que precise ser realmente aleatório… tal como criptografia/sorteios/etc.
srand(
Time.msec()); Onde essa aqui é ANSI?
<blockquote><div class="quote-author">fredferrao:</div>Acho que voces estao confundindo aleatorio com unico.
Aleatorio nao quer dizer que nao repete, aleatorio é aleatorio mesmo.
Tipo um numero aleatorio entre 1 e 10 = 6;
Outro numero aleatorio entre 1 e 10 = 6;
Isto é aleatorio. Voce nao sabe qual vai ser e pode ser qualquer um entre 1 e 10.
Acho que a discussao de voces seria “Aleatorio que nao se repete”. ou aleatorio unico.
Eu sei. Ele não tem noção do que está dizendo. A diferença entre pseudo e um número realmente aleatório. O nº realmente aleatório não se consegue por representação matemática, apenas por hardware.
Criptografia não usa números aleatórios. Somente pseudo aleatórios.
Mas se tiver que usar ruby, não seria preferível usar o proprio, ao jruby?
Ruby é a linguagem de programação, Ruby MRI é a implementação oficial, e também há o JRuby, Rubinius, IronRuby, YARV é muitas outras implementações.
Da mesma forma que o JRuby é feito em bytecodes Java, o MRI é feito em outra linguagem também, C.
Com C se consegue ter o controle da matéria bruta dos recursos, enquanto na JVM eles são abstraídos, protegidos, e qualquer controle maior depende do quanto a JVM libera pra vc. É fato que a JVM foi feita para rodar somente Java, então ela se adapta 100% às necessidades dela. Agora que há mais linguagens usando os mesmos bytecode, mais instruções próprias à linguagens dinâmicas tem que ser adicionadas à JVM para que essas linguagens rodem melhor. Faça uma procura pelo invokeDynamic para saber mais.
Plataforma J2EE /JEE virou legado para o que hoje já se tem em termos de web 2.0 essa devem simplesmente fazer interoperabilidade mas trabalhando com um conceito novo de se produzir aplicações.
As linguagem que tem um efeito indepentente de plataforma também possuem engine que se comunicam com a JVM e de outrs JVMs fornecedores que precisam manter o seu negocio funcional também, projetos que estão indo para Frameworks Grails, Rails, entre outros vão sofrer redesenhos não tem como manter especificações que não atendem a propria arquitetura, nesse caso não existe a migração do negócio entretanto a curva de aprendizagem e implementação é consideralmente muito melhor e rápido de se fazer, pois não se perde-se tempo com uma infinidade de configuração em arvores de arquivos e deployments de tudo que é tipo, que são essas entranhas de frameworks que estão dentro da plataforma J2EE.
Me corrijam se estiver errado, mas a subtituicão do core do Twitter esta sendo feito para Scala né? tanto que um dos “donos” lá esta até vendendo um livro sobre Scala rs… o front-end vai continuar com Rails, por enquanto pelo menos.
Acho que se sair em alguns meses um Rails-like forte e eficiente como o próprio Rails é para Rubu, só que apra Scala, é bem possível que a linguagem ganhe muitos adeptos, muita gente preferiria algo mais java-like(Scala) do que script-like (Ruby) na hora de ter alternativa ao Java.
@Luca que bom vc por aqui de novo amigo
Olá
Tem o Lift cuja versão 1.0 saiu há poucos dias mas. É o único e com poucos desenvolvedores. Já faz Comet com facilidade. Leia http://steve.vinoski.net/pdf/IC-Scala_and_Lift.pdf
Obrigado. Estou tentando voltar para a área. Meus interesses atuias são Lucene/Solr/Inteligência Coletiva e em paralelo voltei a estudar Scala.
PS: Outros links:
http://liftweb.net/docs/StartingWithLift.pdf
http://www.ibm.com/developerworks/views/java/libraryview.jsp?search_by=scala+neward
http://www.ibm.com/developerworks/ajax/tutorials/wa-aj-comet/downloads.html
[]s
Luca
Alguém posta aí um Ator em ação.
Do blog do James Strachan citado no começo:
Ele se refere a James Gosling, Charles Nutter e a si mesmo, que designaram respectivamente o Java, o JRuby e o Groovy.
É aquela coisa Java é uma linguagem que realmente é bem sincronizadas com ferramentas UML pois tem o codigo especificado nesses instrumentos geradores de Codigo , fato que você pode usufluir do AndroMDA para até produzir metodologia baseado em Orientação a Aspecto.
Ator em ação é mais para requisito em cenário use case, isso não quer dizer que você precise tambem de qualquer software para fazer isso, tambem pode rascunhar a mão.
Márcio, o “Actor” ao qual o Mochuara está-se referindo não é o ator de um caso de uso do UML, mas um objeto usado para escrever programas concorrentes.
Em vez de você ter de tratar com threads ou pools de threads, que são coisas pesadas e demasiadamente concretas, o uso de Actors abstrai esse processamento concorrente.
Embora Actors sejam normalmente implementados com pools de threads, isso não é obrigatoriamente necessário; você nem precisaria de threads se você tivesse um suporte equivalente ao runtime do Erlang.
Marcio, estava me referindo a um recurso da linguagem Scala chamado Atores. Não estava me referindo a atores que existe nos diagramas de UML.
Márcio, o “Actor” ao qual o Mochuara está-se referindo não é o ator de um caso de uso do UML, mas um objeto usado para escrever programas concorrentes.
Em vez de você ter de tratar com threads ou pools de threads, que são coisas pesadas e demasiadamente concretas, o uso de Actors abstrai esse processamento concorrente.
Embora Actors sejam normalmente implementados com pools de threads, isso não é obrigatoriamente necessário; você nem precisaria de threads se você tivesse um suporte equivalente ao runtime do Erlang.
Bom, me desculpa a ignorância
Marcio, estava me referindo a um recurso da linguagem Scala chamado Atores. Não estava me referindo a atores que existe nos diagramas de UML.
Bom, melhor explicado como iria também saber, foi mau !!!
Me corrijam se estiver errado, mas a subtituicão do core do Twitter esta sendo feito para Scala né? tanto que um dos “donos” lá esta até vendendo um livro sobre Scala rs… o front-end vai continuar com Rails, por enquanto pelo menos.Acho que se sair em alguns meses um Rails-like forte e eficiente como o próprio Rails é para Rubu, só que apra Scala, é bem possível que a linguagem ganhe muitos adeptos, muita gente preferiria algo mais java-like(Scala) do que script-like (Ruby) na hora de ter alternativa ao Java.
@Luca que bom vc por aqui de novo amigo :)
Muitos desenvolvedores da comunidade Ruby/Rails reclamaran dessa mudança, acusando os desenvolvedores do Twitter de serem ruins, principalmente por emularem um sistema de tipagem estática no Ruby através do uso compulsivo do método kind_of?, ou por não considerarem outras hipóteses, como utilizar o RabbitMQ, que é um message queue escrito em Ruby, e, aparentemente, bem melhor que o Starling, que foi o desenvolvido por eles.
P.S.: O Alex Payne, autor do livro sobre Scala, não chega a ser um dos donos do Twitter, é “só” um dos principais desenvolvedores.
Coincidencia ou não o twitter parece que ficou mais estavel depois da mudança, apesar de ter aumentado a quantidade usuários.
editado: ops! parece que o twitter esta fora do ar neste momento…
…Gosto também bastante de Scala que permite fazer as mesmas coisas (ou um pouco mais) que o Java faz porém escrevendo muito menos linhas. Não é só a redução de linhas que me seduz. É que o código fica mais condensado nas questões relativas ao problema a resolver.
Pois é, também considero isso uma vantagem. Mas uma desvantagem não seria que você fica com muita responsabilidade em menos linhas? Por isso citei o código do números aleatórios no Falando em Java. Aquela linha fazia umas cinco ou seis coisas diferentes. Acho isso confuso.
Posso estar errado, mas não é justamente isso que a Da Vinci Virtual Machine vai resolver?
…
Acho que se sair em alguns meses um Rails-like forte e eficiente como o próprio Rails é para Rubu, só que apra Scala, é bem possível que a linguagem ganhe muitos adeptos, muita gente preferiria algo mais java-like(Scala) do que script-like (Ruby) na hora de ter alternativa ao Java.
A semelhança com Java é realmente um ótimo atrativo. Segue um trecho de hello world retirado da wikipedia:
object HelloWorld extends Application {
println("Hello, world!")
}
Abraços
Me corrijam se estiver errado, mas a subtituicão do core do Twitter esta sendo feito para Scala né? tanto que um dos “donos” lá esta até vendendo um livro sobre Scala rs… o front-end vai continuar com Rails, por enquanto pelo menos.Acho que se sair em alguns meses um Rails-like forte e eficiente como o próprio Rails é para Rubu, só que apra Scala, é bem possível que a linguagem ganhe muitos adeptos, muita gente preferiria algo mais java-like(Scala) do que script-like (Ruby) na hora de ter alternativa ao Java.
@Luca que bom vc por aqui de novo amigo :)
Se não me engano, não foi todo o código Ruby no backend que foi substituído pelo código equivalente em Scala. Foi “só” o Starling, que é o message queue escrito em Ruby por eles, que foi substituído pelo Kestrel, um message queue escrito em Scala e também desenvolvido pela equipe do Twitter.Muitos desenvolvedores da comunidade Ruby/Rails reclamaran dessa mudança, acusando os desenvolvedores do Twitter de serem ruins, principalmente por emularem um sistema de tipagem estática no Ruby através do uso compulsivo do método kind_of?, ou por não considerarem outras hipóteses, como utilizar o RabbitMQ, que é um message queue escrito em Ruby, e, aparentemente, bem melhor que o Starling, que foi o desenvolvido por eles.
P.S.: O Alex Payne, autor do livro sobre Scala, não chega a ser um dos donos do Twitter, é “só” um dos principais desenvolvedores.
[]s
Acho que o Starling foi o principal motivo devido a ruindade imensa que conseguiram fazer, mas pelo que lembro dos blogs/sites ai no começo do ano se não me engano, quando começou pipocar esse assunto, com a saída do Starling, outras coisas que eram em Ruby foram consumidas pela nova implementação que fizeram em Scala.[]s
…Gosto também bastante de Scala que permite fazer as mesmas coisas (ou um pouco mais) que o Java faz porém escrevendo muito menos linhas. Não é só a redução de linhas que me seduz. É que o código fica mais condensado nas questões relativas ao problema a resolver.
Pois é, também considero isso uma vantagem. Mas uma desvantagem não seria que você fica com muita responsabilidade em menos linhas? Por isso citei o código do números aleatórios no Falando em Java. Aquela linha fazia umas cinco ou seis coisas diferentes. Acho isso confuso.
Eu também acho que código legível é melhor do que codigo condensado em 1 linha. Mas acho que o Luca quis dizer isso mesmo, escrever apenas o código necessário para descrever o problema (ainda que eu ache que programa feito em Scala ou Ruby não é assim tão idiomático.)
Olá
...acho que o Luca quis dizer isso mesmo, escrever apenas o código necessário para descrever o problema ...
Certo. Quer um exemplo?
Javaclass MyClass {
private int index;
private String name;
public MyClass(int index, String name) {
this.index = index;
this.name = name;
}
}
class MyClass(index: Int, name: String)
Nada de chaves, ponto e vírgula, declaração de variável em2 linhas e nada de construtor. O Scala já faz tudo isto por nós.
Poderia dar um monte de exemplos. Seria até covardia escolher uma classe em Java com um monte de getters e setters. E isto sem falar nas características funcionais da linguagem que quando bem usadas são bem poderosas. Só não podemos esquecer que tudo isto depois vai para a JVM convertido em bytecode e usando os tipos do Java.
[]s
Luca
Ae laguiar,
Não sei se vc já tinha lido esse post do akita http://akitaonrails.com/2009/04/07/a-controversia-do-twitter-e-scala
Pois é, também considero isso uma vantagem. Mas uma desvantagem não seria que você fica com muita responsabilidade em menos linhas? Por isso citei o código do números aleatórios no Falando em Java. Aquela linha fazia umas cinco ou seis coisas diferentes. Acho isso confuso.
Eu também acho que código legível é melhor do que codigo condensado em 1 linha. Mas acho que o Luca quis dizer isso mesmo, escrever apenas o código necessário para descrever o problema (ainda que eu ache que programa feito em Scala ou Ruby não é assim tão idiomático.)
Jogar Perl Golf em sistema em produção nunca foi bom.
Linguagens como o Ruby tem o que eu chamo de um alto grau de expressividade. Expressividade é a medida do quanto uma linguagem pode fazer o mesmo que outras linguagens fazem, escrevendo menos código e ainda se mantendo bastante legível.
Código pequeno é importante por que nós entendemos melhor coisas pequenas que coisas grandes, o que em programação se traduz em escrever códigos simples em favor de escrever códigos complexos. Por isso que desde as primeiras linguagens temos o conceito de modularidade, escrevemos funções, métodos, subprogramas em geral para resolver parte dos problemas sem misturar com as outras partes. A modularidade então evoluiu para encapsulamento, responsabilidade, e termos relacionados como a delegação. Daí então criamos os design patterns para catalogar e reaplicar as responsabilidades, a modularidade do código, a ajudar a manter o código simples e pequeno.
Código expressivo e pequeno também é rápido de codificar, o upload da mente para o teclado é rápido, e o download da tela para a mente também é rápido.
Bacana o post mencionando a jugular
a maior preocupação de pessoas que interagem com as entranhas do computador é reduzir o gap entre o que você tenta expressar e o que você expressa de fato para o computador processar o que você precisa.
com viabilidade de hardware cada vez mais transparante, a tendência clara é termos linguagens de programação cada vez mais empáticas com as nossas necessidades, moldadas de maneira mais natural ao que precisamos. É o gap entre uma linguagem de programação interpretada por computador e uma linguagem natural interpretada, são computadores mais ricos em interpretar simbolos e signos, mais abstraídos de características físicas de hardware, mais proximos de serem resolvedores de problemas responsivamente, aceitar que existe uma pilha de lições aprendidas que mostram os pontos de overhead na interação programador/computador, nos levando para um patamar mais convencionado, natural e humano de interagir com o computador de um modo mais flexível.
T+
Olá...acho que o Luca quis dizer isso mesmo, escrever apenas o código necessário para descrever o problema ...Certo. Quer um exemplo?
JavaScala (com a ressalva de que as 2 variáveis de instância são finais neste exemplo)class MyClass { private int index; private String name; public MyClass(int index, String name) { this.index = index; this.name = name; } }class MyClass(index: Int, name: String)Nada de chaves, ponto e vírgula, declaração de variável em2 linhas e nada de construtor. O Scala já faz tudo isto por nós.
Poderia dar um monte de exemplos. Seria até covardia escolher uma classe em Java com um monte de getters e setters. E isto sem falar nas características funcionais da linguagem que quando bem usadas são bem poderosas. Só não podemos esquecer que tudo isto depois vai para a JVM convertido em bytecode e usando os tipos do Java.
[]s
Luca
E como fica o encapsulamento em Scala? Estes atributos sao privados ou publicos? Ou nao há encapsulamento em Scala.
Tava dando uma pesquisada e achei esta apresendação: Uma introdução à linguagem Scala: mais uma linguagem JVM ou o futuro de JAVA?
La o cara sita assim:
TDA e casamento de padrões
# Geralmente criticado por desenvolvedores que gostam de orientação a objetos
=> TDA's não são extensíveis
=> TDA's violam a pureza do modelo de dados de OO
=> Casamento de padrões quebra encapsulamento
Mas e se eu nao quiser que a classe faça tudo pra mim? e se eu nao quiser que ela tenha tal contrutor que o "Scala faz por voce", tem como?
E outra esse negocio de tudo em uma linha é muito subjetivo de ser melhor ou nao, é como ja citaram acima, onde vai parar a legibilidade do codigo, imagina uma classe com 20, 30 ou 40 atritutos, ja imaginou que nojeira que nao fica, parecendo aquelas procedure/function do Delphi que aceita 3 milhoes de parametros.
Eu poderia fazer os atributos em uma linha no java.
public class MyClass{
private int id; String nome;
}
Voce diz nada de chaves, nada de ponto e virgula, porem voce nao tem chave mas tem parentese, nao tem ponto e virgula mas tem virgula eae?? Fica apenas a questao do contrutor que eu nao precisaria fazer, se é que eu realmente quero tal contrutor.
E por fim eu concordo com o post do Celso Martins, esse negocio de replace e bala de prata como ele diz.
Fico doido quando chega um e fala: "Java morreu negocio agora é Ruby, e parece que era :lol: porque agora java morreu e o negocio não é Ruby, é Scala. Pra mim por enquanto ta igual Ruby só Fogo de Palha.
E antes que venha algum falar, sim sempre é bom aprender novas linguagens pra nao ficar bitolado, ter outras maneiras de resolver a mesma coisa e tals, eu mesmo tava querendo comprar um livro de Ruby, mas pelo visto é melhor eu comprar um de Scala que ta na moda agora(alguem indica um?).
Resumindo, eu nao vou vender minha cama por causa disso, nao pelos proximos hummm 5~10 :? anos?? Se nao eu ja tinha vendido quando a dois anos atraz um amigo chegou dos EUA e disse, java morreu negocio agora é Ruby.
Olá
Fica igual ou melhor do que Java. Scala tem praticamanente tudo que o Java tem (não tem Static por exemplo e algumas sintaxes diferem como os índices dos arrays também como exemplo) e mais algumas outras coisas bem interessantes.
Li rápido. Em Scala tudo é objeto, inclusive inteiros. Mas na hora em que vai para a JVM, se possível, objetos são convertidos para os tipos primitivos para não perder desempenho. E Scala tem coisas que o Java não tem como por exemplo Pattern Matching.
Ora, é só você definir do jeito que quer. Aliás, há casos em que os livros de Scala recomendam fortemente o uso das chaves e também não há problema se você quiser ponto e vírgula ou fizer copy & paste de código Java com ponto e vírgula.
Isto é código ruim em qualquer linguagem. Scala desestimula isto mas tanto quanto Java e Ruby, não proíbe. Como sempre, ser mau programador é uma opção livre do programador.
Não é só isto. As classes ficam menos poluídas sem getters e setters. Mas repito, quem quiser pode usar.
Não é bala de prata… muito pelo contrário… a idéia é usar a coisa certa no momento certo. Fazer como o Jean-Francois Arcand mostra hoje no Java.net que rapidamente fez uma aplicação em Scala usando Comet
Quanto a questão da cama posso dizer que sei que muita gente aqui ganha a vida fazendo CRUD usando Java. Só digo uma coisinha: se esta turma usasse Ruby ao invés de Java para fazer CRUD, o trabalho exigiria menos horas e a turma ganharia menos. Um dia os patrões perceberão isto.
[]s
Luca
Olá
…
…
[]s
Luca
Legal, se tem como fazer tudo e a opção de usar ou nao como no java.
Agora como citei, ja temos ae o Phyton, Ruby, agora o Scala é o fogo de palha da vez, digo fogo de palha porque quando acende parece que vai ser o maior fogo do mundo, mas logo apaga, e ano que vem o que vai ser? Porque ate agora nao vi essas linguagens se firmarem de vez. RoR ja esta ae a um bom tempo, tem la sua comunidade tem os que fazem seus projetinho com ele, mas a nivel de mercado ta muito longe ainda. Essas lingagens por enquanto tao mais como “Mais uma linguagem da VM” do que como um substituto ao java.
E como fica o encapsulamento em Scala? Estes atributos sao privados ou publicos? Ou nao há encapsulamento em Scala.
Tava dando uma pesquisada e achei esta apresendação: Uma introdução à linguagem Scala: mais uma linguagem JVM ou o futuro de JAVA?La o cara sita assim:
Mas e se eu nao quiser que a classe faça tudo pra mim? e se eu nao quiser que ela tenha tal contrutor que o "Scala faz por voce", tem como?
O seu conceito de encapsulamento é confuso.
Vamos lá, encapsulamento deve ser visto mais como uma convenção adotada pelos programadores do que uma característica da linguagem. Por que? Porque é muito fácil quebrar as convenções de encapsulamento de uma linguagem OO, inclusive Java!. Um exemplo são os famosos getters e setters criados para todos os atributos privados. Isso quebra o encapsulamento, porque quando acontece uma alteração em uma propriedade privada, ocorre na sequencia a alteração de seu getter e setter.
Scala tem private, protected e public e mais um monte de permissões finas que só ela tem. A diferença é que, se você não colocar o modificador, o default é public. Mas isso deveria ser até irrelevante, porque um programador mané quebra os modificadores facilmente; enquanto que um programador bom mantém o encapsulamento mesmo em linguagens que não a oferecem, como Python.
E outra esse negocio de tudo em uma linha é muito subjetivo de ser melhor ou nao, é como ja citaram acima, onde vai parar a legibilidade do codigo, imagina uma classe com 20, 30 ou 40 atritutos, ja imaginou que nojeira que nao fica, parecendo aquelas procedure/function do Delphi que aceita 3 milhoes de parametros.Eu poderia fazer os atributos em uma linha no java.
public class MyClass{ private int id; String nome; }Voce diz nada de chaves, nada de ponto e virgula, porem voce nao tem chave mas tem parentese, nao tem ponto e virgula mas tem virgula eae?? Fica apenas a questao do contrutor que eu nao precisaria fazer, se é que eu realmente quero tal contrutor.
É possível sim ter construtores vazios e ter propriedades que não inicializam na construção. Mas qual a vantagem disso numa linguagem que é também funcional e que suporta concorrência via atores? Porque, nesses paradigmas, objetos imutáveis são essenciais e toda a inicialização precisa ser feita via construtor.
Não existe encapsulamento quando uma classe tem 20 ou 40 propriedades. Uma classe bem coesa tem no máximo, sei lá, uns sete atributos, ou nove estourando. 20 ou 40 atributos é “cheiro” de design ruim, pra qualquer linguagem utilizada. Então, não vejo problema ter as propriedades todas numa linha só. Se ficar muito comprida, faça a identação, ué.
Uma coisa que não foi falada é que, quando é colocado os atributos no construtor, é gerado, automaticamente, o “setter” e o “getter” pra ele. Por isso, o seu código Java em uma linha só não faz o que o código Scala faz.
E por fim eu concordo com o post do Celso Martins, esse negocio de replace e bala de prata como ele diz.
Fico doido quando chega um e fala: "Java morreu negocio agora é Ruby, e parece que era :lol: porque agora java morreu e o negocio não é Ruby, é Scala. Pra mim por enquanto ta igual Ruby só Fogo de Palha.
E antes que venha algum falar, sim sempre é bom aprender novas linguagens pra nao ficar bitolado, ter outras maneiras de resolver a mesma coisa e tals, eu mesmo tava querendo comprar um livro de Ruby, mas pelo visto é melhor eu comprar um de Scala que ta na moda agora(alguem indica um?).
Resumindo, eu nao vou vender minha cama por causa disso, nao pelos proximos hummm 5~10 :? anos?? Se nao eu ja tinha vendido quando a dois anos atraz um amigo chegou dos EUA e disse, java morreu negocio agora é Ruby.
Aí cada um faz o que achar melhor. Mas é por sua conta e risco.
Também acredito que no futuro, a tendência é Scala virar uma forte candidata à projetos Enterprise, como construção de frameworks, containers e por aí vai. Para a implementação de negócio, ficaria com algo mais leve como Ruby, que é uma delícia de programar e vicia !!
humm, pelo q eu estava lendo do scala, a idéia é justamente ter uma linguagem mais escalável. Segundo o autor, quando vc muda de uma linguagem pra outra vc sempre acaba perdendo muita informação sobre os tipos. Um exemplo que ele deu é quando um tipo java se torna uma consulta sql e vice versa.
Não tem jeito, sempre que vc tiver linguagens diferentes na conversão de tipos vai perder informação sobre o objeto, e quanto menos isso acontecer melhor.
Prefiro ruby à java, e acho legal pensarmos com muito cuidado sobre todas as novidades meteóricas, pois no final é pior pra gente e injusto o cliente ter que pagar por isso.
Aqui há uma introdução da arquitetura do twitter, explicando o que usam: http://www.infoq.com/news/2009/06/Twitter-Architecture
Legal, se tem como fazer tudo e a opção de usar ou nao como no java.
Agora como citei, ja temos ae o Phyton, Ruby, agora o Scala é o fogo de palha da vez, digo fogo de palha porque quando acende parece que vai ser o maior fogo do mundo, mas logo apaga, e ano que vem o que vai ser? Porque ate agora nao vi essas linguagens se firmarem de vez. RoR ja esta ae a um bom tempo, tem la sua comunidade tem os que fazem seus projetinho com ele, mas a nivel de mercado ta muito longe ainda. Essas lingagens por enquanto tao mais como “Mais uma linguagem da VM” do que como um substituto ao java.
Olha, sinceramente, não sei se no teu mercado de trabalho é assim, mas aqui em São Paulo (que acredito ser o maior do Brasil) já existe algumas empresas adotando Ruby On Rails. Além do mais, grandes empresas já estão utilizando, houve migrações “insanas” de muitas “blue chips” (papo de investir bitolado rsrsrs) da internet aqui e continuará havendo na minha opinião.
Lembro que quando cheguei em 2006 aqui em SP já tinham alguns projetos, pessoal trocando JSF por Rails e assim por diante. Hoje em dia a coisa tá mais punk, por exemplo, no lugar onde eu trabalho eu entrei como desenvolvedor Java Sr., depois de 4 meses trabalhando resolveram usar só Rails e tem sido assim desde então, já fazem mais de 6 meses que as coisas estão assim e pelo visto só continuará crescendo. Se em 2006 já tinha utilizações, imagina agora.
Não quero tirar o mérito de Java, tanto é que continuo sendo muito entusiasta, mas certas linguagens e frameworks acabam se adaptando melhor a certos cenários e, Java não é bala de prata como muitos aqui no guj continuam pensando, inclusive já fui uma dessas pessoas.
Legal, se tem como fazer tudo e a opção de usar ou nao como no java.
Agora como citei, ja temos ae o Phyton, Ruby, agora o Scala é o fogo de palha da vez, digo fogo de palha porque quando acende parece que vai ser o maior fogo do mundo, mas logo apaga, e ano que vem o que vai ser? Porque ate agora nao vi essas linguagens se firmarem de vez. RoR ja esta ae a um bom tempo, tem la sua comunidade tem os que fazem seus projetinho com ele, mas a nivel de mercado ta muito longe ainda. Essas lingagens por enquanto tao mais como “Mais uma linguagem da VM” do que como um substituto ao java.
Olha, sinceramente, não sei se no teu mercado de trabalho é assim, mas aqui em São Paulo (que acredito ser o maior do Brasil) já existe algumas empresas adotando Ruby On Rails. Além do mais, grandes empresas já estão utilizando, houve migrações “insanas” de muitas “blue chips” (papo de investir bitolado rsrsrs) da internet aqui e continuará havendo na minha opinião.
Lembro que quando cheguei em 2006 aqui em SP já tinham alguns projetos, pessoal trocando JSF por Rails e assim por diante. Hoje em dia a coisa tá mais punk, por exemplo, no lugar onde eu trabalho eu entrei como desenvolvedor Java Sr., depois de 4 meses trabalhando resolveram usar só Rails e tem sido assim desde então, já fazem mais de 6 meses que as coisas estão assim e pelo visto só continuará crescendo. Se em 2006 já tinha utilizações, imagina agora.
Não quero tirar o mérito de Java, tanto é que continuo sendo muito entusiasta, mas certas linguagens e frameworks acabam se adaptando melhor a certos cenários e, Java não é bala de prata como muitos aqui no guj continuam pensando, inclusive já fui uma dessas pessoas.
Pra mim o mercado em SP ainda é bem “atrasado” em relação a tecnologias. A maioria das empresas ainda quer o Java básico de 5~10 anos atrás (Struts, EJB, etc) e o resto está se atualizando (Spring, JSF, etc). RoR ao meu ver ainda não chegou com força.
Olá
Quanto a questão de linguagem bala de prata acho que todos concordam que não existe porque qualquer projetinho bobo usa no mínimo umas 3 ou 4 (Java, HTML, SQL, Javascript, xml, etc.)
Mas vejam somente o slide 13 desta apresentação sobre um projeto da BBC (Feeds Hub) mostrando um monte de linguagens e frameworks: Introducing BBC Feeds Hub (BBC Radiolabs)
Será que uma só pessoa domina tudo isto? É claro que não. Mas alguém tem que ter uma razoável noção para enxergar o sistema como um todo e este alguém não é um programador monoglota.
[]s
Luca
Seria legal você postar exemplos de empresas, até pra gente interessada em ter a oportunidade de trabalhar com Ruby poder procurar nos lugares certos.
Em SP que eu conheço a Abril e se não me engano a Toyota.
Com a falta de programadores Ruby no mercado, sabe se essas empresas tendem a contratar desenvolvedores experientes em outras linguagens e treiná-los internamente, ou preferem tentar a sorte pedindo currículos com experiência na linguagem?
Sim é uma convenção, porem a linguagem poderia/deveria te dar uma maneira de forçar essa convenção, pois podem haver programadores bons e manés trabalhando no mesmo lugar/sistema/framework, e acho que a ideia do javabean com getter e setter foi essa, voce esconde o atributo e força o usuario a passar por um “filtro”.
Porem da maneira como a maioria faz hoje, getters e setters vazios, sem codigos, que nao fazem nada alem de setar ou retornar o valor, um pra cada propriedade, voce esta certo, mudou-se a propriedade tem que mudar o getter/setter. Eu penso que se é pra nao ter nenhum codigo dentro deles entao ponto pro Scala, pois nao ha sentido eles existirem, pois é como se eles fossem os proprios atributos.
O que deveria ser mostrado para o usuario é apenas o que ele precisa, por exemplo eu poderia ter uma classe com 10 atributos e apenas 5 getter/setter tratando tudo e abastecendo os 10 atributos, entao neste caso eu poderia sim manter a interface do usuario caso eu necessite alterar/adicionar/remover um atributo. Não para casos extremos é claro.
Seria legal você postar exemplos de empresas, até pra gente interessada em ter a oportunidade de trabalhar com Ruby poder procurar nos lugares certos.
Em SP que eu conheço a Abril …
fred.
O ideal seria vcs so ter getters e setters para as propriedades que devem ser acessadas ou sobreescritas, não a todas as propriedades.
Eu nunca crio setters que nunca preciso, mas algumas vezes eles contem somente a definição para o novo campo.
[]'s
fred.O ideal seria vcs so ter getters e setters para as propriedades que devem ser acessadas ou sobreescritas, não a todas as propriedades.
Eu nunca crio setters que nunca preciso, mas algumas vezes eles contem somente a definição para o novo campo.
[]'s
Sim foi essa a ideia que eu quis passar no ultimo post. Mostrar pro usuario apenas o necessario e nao tudo. E tambem claro, nem sempre eles tem fazer algo mais alem de definir o valor.
De uns amigos e ex-alunos que tenho na Abril, sei que a migração foi feita da galera que desenvolvia em Java, botaram todo mundo para estudar Ruby. Se bem que procurar alguém com experiência ia ser perca de tempo, talvez achassem um ou outro.
Olha, a Abril, WebCO, Locaweb, UOL e a Agência Click são exemplos que me surgiram agora.
Uma vez dessa história que falei de cara trocando jsf/struts pra rails eu sinceramente não lembro o nome, foi alguém que eu conheci uma vez num onibus que eu ví e troquei uma idéia e aí sim que ele tinha falado que tinha alguns projetos com Rails.
Tem um user aqui do fórum que trabalha com home-office, em Rails, pra Alemanha
Se alguém tiver mais outras é só ir postando também
A propósito, o pessoal da Caelum tem usado em alguns projetos também?
Isso é muito bom, dá um dinamismo.
Esta conversa de que Java é pouco produtivo e temos que mudar para Ruby já está enchendo o saco.
Afinal o que “Produtivo” significa ? Sem a definição disso dizer que X é mais produtivo que Y é uma falácia à priori.
Vamos supor que “produtivo” significa :" consigo executar mais instruções com menos linhas de codigo".
Ora java tb consgue isso. Basta que vc tenha bibliotecas/api/classes que encapsulem os comandos malucos.
No MiddleHeaven - que é Java - tb faço uma selecção aleatoria como uma linha de codigo
Integer resultado = Range.over ( 1 , 6 ) .random () ;
Isso não é diferença entre as linguagens. É diferença entre as API. Acontece apenas que API de X tem funções mais “rápidas” que a de Y.
Blz, vc consegue escrever random generator em uma linha. E dai ?
Agora vamos supor que “mais produtivo” significa “consigo fazer mais com menos esforço”
Java é fortemente tipada. Só isso garante menos esforço em debuging. É clara que script não só pela tipagem forte mas pelo pouco uso de simbolos.
Sendo que não ha invocação dinamica é possivel saber e seguir o codigo de qualquer classe sem ter que saber que o método xyz é mágico e declaro dinamicamente. As coisas são o que são e não deixam de ser o que são.
Ok, você consegue colocar uma aplicação no ar com RoR em 1 dia. Em Grails tb. Mas isso são frameworks ! Não são linguagens.
Qualquer programação pode ser tão produtiva em uma linguagem quanto outra. Quando a linguagem não oferce o que queremos a API oferece. Se aPI não oferece alguma outra API de terceiro o faz, e sempre podemos implementar a nossa.
Agora, você tem um monte de coisa pronta em Java , vc vai mudar isso para outra coisa ? Isso é “produtivo” não. Vc vai criar uma aplicação nova.
Vc já conhece o framework ZZ e tem um monte de Utils da vida que vc domina e escreve aplicações em uma semana. Vai mudar para ruby ou outra coisa onde você tem que fazer tudo de novo ? Não me parece que isso é produtivo.
Cada linguagem tem o seu propósito. Scala veio com a ideia de programação funcional. Grovy com script derrotanto o ruby. Outras virão. Pode ser mais facil escrever uma classe nessas linguagens, mas é mais facil escrever um sistema inteiro ? É real a competição entre Java e essas outras linguagens para uma aplicação de proposito genérico ? Java é uma linguagem de proposito genérico ela não foi desenhada para escrever pouco ou dar comandos mirabulantes em um linha , se ela fosse assim não precisamos de linguagens de script.
Java foi criado para ser simples e seguro em comparação com C e C++ .
Finalmente, esse negocio de migrar está ultrapasado. todas essas linguagens novas correm ou irão correr na JVM. Sendo assim, existirão pontos mais faceis de criar com scala ou FX e outros com groovy. Ai faz todo o sentido pq vc tem acesso a todas as API java e java passa a ser para essas linguagens o que o C++ é hoje ( uma comunicação mais nativa com os recursos mais baixos) para impletar plugins e coisas do tipo.
Sair do ambiente da JVM é suicidio tecnico.
Quanto para mim, sem a definição de “produtivo” esta conversa é fútil e só serve para alimentar o hype das linguagens. ( ainda outro dia alguem falava do Ioke… ora… não vou perdeu o meu tempo aprendendo toda a linguagem-want-to-be que aparece… ) Essas linguagems precisam amadurecer. Depois a gente conversa de novo sobre qual realmente fez a diferença.
Acho que essa é a tendencia. Eu por exemplo sempre quis trabalhar com Ruby, estudei um pouco informalmente mas nunca tive a oportunidade de usar trabalhando. Ficaria bem feliz em usá-la (longe de querer largar o Java, mas gosto de aprender linguagens novas e me interesso muito por DSLs).
Olha, não conheço bem o Ruby, embora já tenha dado minhas estudadas. Mas ao que percebi, tem alguns que acham que DSL e coisa do Ruby ou que faz em linguagens como ele. Eu faço em Java sem problemas. Dá mais trabalho sim, mas no final, o resultado de usar é o mesmo, então, acho válido pela Orientação de Objetos.
Estou me interessando em Scala e acredito que vai se tornar muito mais popular que Ruby atualmente.
Não tenho nada contra estudar novas linguagens e aplicá-las onde faz sentido. Mas a simples idéia de que alguns fazem de que Ruby é a última bolacha do pacote é meio irritante.
Existem conceitos básicos que são aplicáveis a várias linguagens. O que determinará se uma linguagem é boa ou ruim são os conceitos em que se baseia mais a qualidade da implementação e bibliotecas.
Portanto quem é fã de Ruby não está “evoluindo” em nenhum aspecto, pois não sabe que determinadas features são mais velhas do que andar para frente. Se analisassem de fato veriam que Ruby nem é tão flexível assim como outras. Admitam, vocês apenas estão seguindo a modinha. Não existe nenhuma outra razão além dessa.
O fascínio de alguns com o Ruby se dá mais por causa do fato de que muitos não conheciam nada além de Java, do que com a qualidade da linguagem em si.
Olha, não conheço bem o Ruby, embora já tenha dado minhas estudadas. Mas ao que percebi, tem alguns que acham que DSL e coisa do Ruby ou que faz em linguagens como ele. Eu faço em Java sem problemas. Dá mais trabalho sim, mas no final, o resultado de usar é o mesmo, então, acho válido pela Orientação de Objetos.
Estou me interessando em Scala e acredito que vai se tornar muito mais popular que Ruby atualmente.
Sim, DSL é uma nova sigla da sopa de letrinhas que muitos gostam de repetir. Em algumas linguagens o que chamam de DSL não passa de “business as usual”, porque se estará desenvolvendo dessa forma naturalmente.
Ninguém evolui por ser fã de uma linguagem, mas aprender Ruby pode sim ensinar bastante coisa pra alguém que só programou nas linguagens que viu na faculdade ou no trabalho. Apesar das features serem mais velhas que andar pra frente, Ruby tem o mérito de tê-las trazido pro mainstream. Quantas pessoas você conhece que trabalham com Lisp, Smalltalk ou Haskel? E com Ruby?
Não tenho nada contra estudar novas linguagens e aplicá-las onde faz sentido. Mas a simples idéia de que alguns fazem de que Ruby é a última bolacha do pacote é meio irritante.
Com certeza. Pra falar a verdade, qualquer um que passa a idéia de que qualquer linguagem é a última bolacha, se engana amargamente. Essa coisa de produtividade é relativa. Conheço um cara que escreve em pascal, melhor que muita gente calejada a anos em rails ou java. Isso vai de pessoa pra pessoa.
Sobre aprender novas linguagens.
Imagino que seja essencial não depender de uma única para desenvolver projetos.
Vocé poderia citar uma dessas features que, graças ao Ruby, foi introduzida no mainstream?
Closures, metaprogramação, mixins. É muito mais fácil mexer com reflexão no Ruby, também, E tudo é objeto,
Só mais um exemplo de empresa, aqui na Gonow já trabalhamos com alguns projetos em Rails, tem alguns meses que montamos uma equipe especializada e temos previsão de mais que triplicar isso, alias a empresa será uma das grandes patrocinadoras do Rails Submit esse ano.
Quem não gosta de Ruby ou Rails, favor dar argumentos técnicos e não pessoais, para que o tópico não vire outro flame de eu gosto, vc não gosta.
As vezes aparecem umas vagas de emprego na rails-br, também.
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.
Ruby se apresentou como um melhor implementação de objetos para a época. Mas dizer que closures, mixins e monkeypatching virou mainstream é ir longe demais IMO.
Até porque acredito que o mainstream, que é formado por desenvolvedores de aplicações, não precisa de metaprogramação, mas posso estar errado quanto a isso!
Só mais um exemplo de empresa, aqui na Gonow já trabalhamos com alguns projetos em Rails, tem alguns meses que montamos uma equipe especializada e temos previsão de mais que triplicar isso, alias a empresa será uma das grandes patrocinadoras do Rails Submit esse ano.Quem não gosta de Ruby ou Rails, favor dar argumentos técnicos e não pessoais, para que o tópico não vire outro flame de eu gosto, vc não gosta.
Um argumento que pode não ser técnico, mas que embasa a minha opinião com relação ao que vi de Ruby até hoje é a confusão que aparece com a condensação de muita lógica em poucas linhas. Não estou falando da declaração de classe do Scala, que pelo que andei vendo desde a semana passada, parece realmente melhor que em Java. Estou falando da lógica no corpo de um método, por exemplo. Mais uma vez, por isso dei o exemplo dos números aleatórios do Falando em Java. Me parece muita lógica (responsabilidade) para pouca linha, o que, na minha visão, torna a sintaxe da linguagem confusa.
E como o que li em um post do Sérgio, se não me engano. Se quisermos realmente este tipo de coisa, podemos criar dentro do próprio Java. Trabalhar com arquivos em Java é chatinho pra dedéu, não é? Pois é, eu criei uma API em que você passa o nome do arquivo e um List do conteúdo do arquivo no construtor de uma das classes e pronto. Fica algo como isso:
List<String> linhas = new ArrayList<String>();
FileOut out = new FileOut("testeGuj.txt", linhas);
out.write();
write é sobrecarregado sem argumentos; ou com uma List ou uma String como argumentos. Nunca foi tão fácil escrever um arquivo. BufferedWriter, FileWriter e todas as outras pragas estão encapsuladas na classe FileOut. Tenho uma classe FileIn que, obviamente, serve para ler um arquivo.
Nem sempre a melhor forma de expressar uma idéia é de forma resumida ou sintética, como eu vi um post nessa thread dizer. Existem situações em que escrever mais favorece o entendimento. No Java por exemplo, quando extraimos um método (Refactoring) estamos, no mínimo, criando mais duas linhas de código (assinatura e a chave de fechamento “}”), sem por isso estar comprometendo a legibilidade. Normalmente o que acontece é justamente o contrário.
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???
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???
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.
Esse dinamismo da Caelum é muito interessante. Parece a ThoughtWorks brasileira. =D
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.
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.
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.
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.
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.
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
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?
Olá
Não entendi bem o que tem a ver isto com o tema deste tópico. Você costuma colocar comandos na mesma linha em Java? Ou em outra linguagem qualquer? Ou está se referindo ao uso de fluent interfaces?
[]s
Luca
Desculpa Luca, eu pensei que tinha feito o comentário sobre os comandos poderosos na outra mensagem. Quotei em outra resposta. Como eu disse, meu problema não é esse. E se fosse “até” em Java daria para resolver. Mas entendi onde você quis chegar.
O meu problema é o argumento que encher uma linha de comandos proporciona uma melhor produtividade e melhor legibilidade.
Não sabe brincar não desce pro play. =D
Em 85 eu programava de “brincadeirinha”.
Abraços.
Olá
Não entendi bem o que tem a ver isto com o tema deste tópico. Você costuma fazer isto em Java? Ou em outra linguagem qualquer? Ou está se referindo ao uso de fluent interfaces?
Ué… mas foi justamente por isso que abri o tópico. =D
Você esteve no Falando em Java?
Lá o Kung fez um sistema para gerar números aleatórios usando uma linha (duas porque não coube na tela), mas com 150 comandos nesta linha.
Quando alguém da platéia gritou pedindo para fazer em Java, pois a bagaça não funcionava, ele falou algo assim: Nem morto, em Java eu precisaria de dezenas de linhas.
Eu olhava aquelas duas linhas (uma na verdade) e ficava imaginando: e para debugar uma app com, sei lá, 300 linhas dessas. Vai levar uma eternidade. Prefiro escrever mais linhas, e deixar o código legível, que escrever tudo em uma e ficar meia hora só para entender o que essa linha faz. Esse é o ponto central do meu questionamento.
Abraços.
Olá
Ué… mas foi justamente por isso que abri o tópico. =DVocê esteve no Falando em Java?
Lá o Kung fez um sistema para gerar números aleatórios usando uma linha (duas porque não coube na tela), mas com 150 comandos nesta linha.
Agora entendi sobre o que está reclamando. Não fui ao Falando em Java mas acredito que o Fabio tenha tentado fazer um pequeno script. Se ele tivesse usado bash ao invés de ruby também ficaria menor do que Java que não roda como script e precisa fazer uma classe, salvar e compilar antes de rodar.
Comparar uma linguagem que exige criar um arquivo, salvar e compilar antes de executar com um script não vale. Não é este poder que me refiro. Aliás, quando falo em comandos poderosos também deveria falar onde pretendo usar a linguagem. Exemplo: Os comandos de Erlang são poderosos para concorrência, comandos Fortran são poderosos para resolver sistemas de equações e por aí vai.
Nem sempre a gente pode usar a melhor solução para cada problema. Muitas vezes basta conhecer a solução mais abrangente mesmo que em alguns casos não seja a ideal. Só que hoje posso dizer sem medo de errar que Java é complicado demais para a maioria dos sistemas web que conheço.
[]s
Luca (acho que fui meio confuso…)
Olá
Faltou dizer… parabéns pelo tópico. Gostei de discutir este assunto.
[]s
Luca
Voce ta certo, eh melhor varias linhas legiveis do que uma linha condensada dificil de entender
Mas no geral, quanto menos codigo mais facil de entender
Acontece que em Ruby da pra fazer muita coisa com poucas linhas e nao fica dificil de entender (pra quem conhece a linguagem)
Em Java muitas vezes voce eh obrigado a escrever varias linhas de codigo feio, repetitivo, dificil de ser testado. Codigo que seria muito mais facil de se escrever em Ruby por causa de metaprogramacao, closures, mixins, da natureza dinamica da linguagem. Eh impossivel na pratica criar algo igual ao Rails em Java, senao alguem ja teria feito
Cada linguagem tem suas qualidades, nao eh pq se eu prefiro hoje fazer aplicacao web com Rails que eu vou deixar de usar Java quando achar mais adequado (ou C, Scala, Erlang)
Tem um projeto pessoal que quando comecei eu nao tinha ideia de como implementar, soh tinha uma vaga ideia do resultado que eu queria. Comecei a implementar em Rails e depois de 2 meses acho que consegui terminar as partes criticas, que eu nem imaginava como ia fazer. Tenho certeza de que eu nao teria chegado ateh aqui se tivesse feito em Java (mesmo tendo bem mais tempo de experiencia em Java)
Concordo.
Sim, cada uma tem o seu espaço. Por isso tenho aversão a palavra substituir, trocar, migrar para linguagens. Mexo com Delphi profissionalmente até hoje. E pro propósito dele, não tem swing/awt que me conveça que o Delphi não é mais necessário. Essa palavra (migrar/substituir) usada constantemente no post do James, foi outra motivação para eu postar um comentário no meu blog e abrir esse tópico.
Como assim? Eu acho a arquitetura web complicada por si só. Client-side, server-side, joga na sessão, tira da sessão, manda pro JavaScript, chama submit(), manda pro servlet. Quando estou programando o background, sou a pessoa mais feliz do mundo. Quando chega nessa parte, quero virar padeiro e largar a programação. =D
Luca (acho que fui meio confuso…)
Eu não achei. Acho que entendi bem o que você quis passar.
Faltou dizer… parabéns pelo tópico. Gostei de discutir este assunto.
Luca
Tks! =D
Cara, isso, na minha visão, não é problema da linguagem e sim do desenvolvedor.
Esse é o ponto. Agregar, não substituir, migrar.
Tem um projeto pessoal que quando comecei eu nao tinha ideia de como implementar, soh tinha uma vaga ideia do resultado que eu queria. Comecei a implementar em Rails e depois de 2 meses acho que consegui terminar as partes criticas, que eu nem imaginava como ia fazer. Tenho certeza de que eu nao teria chegado ateh aqui se tivesse feito em Java (mesmo tendo bem mais tempo de experiencia em Java)
Não conheço o Rails a fundo, a ponto de comentar esse seu parágrafo. Só me vem a cabeça duas coisas: 1) Será que é necessário? 2) Será que realmente seria impossível fazer em Java?
Abraços.
HEhehehhhehehe… Linguagens novas não-java sempre gerarão flames…
Não sei porque a galera veste camisa de tal linguagem e acham que ela é melhor que outra ou algo do tipo. A questão é que toda linguagem tem seu motivo para existir e também tem sua característica principal.
É lógico que o java dará espaço para outras linguagens no futuro, uma linguagem nunca foi e nunca será de forma cabal a melhor solução dos problemas atuais e futuros. Os problemas mudam e com isso as linguagens mudam.
É da natureza do ser humano ir abstraindo problemas parecidos/iguais, mas isso não quer dizer necessarimente que uma linguagem que faça isso ganhará o mainstream.
Agora sinceramente esse lance de “vai substituir tal linguagem” é rídiculo. É como se eu vivesse na época do C e falasse: “O C será substituido pelo java”.
O C ta até hoje ai sendo utilizado pra várias coisas e continuará assim como o java continuará. O fato de existir linguagens que abstraem mais coisas do desenvolvedor não quer dizer que a linguagem vingará! Há muita coisa em jogo na área de desenvolvimento de software e sinceramente não é só este fator (abstração maior de código) que fará que uma linguagem suba ao mainstream.
Acho que pra uma linguagem chegar ao mainstream precisa muito mais do que somente abstração/diminuição de código. Talvez com uma nova revolução na computação, tipo (Cloud Computing, computação quântica, etc), a linguagem que estiver preparada ganhará o mainstream. Enquanto isso acho que ainda falta algum tempo pra java sair do cenário principal.
Olá
É por isto que disse que é possível usar a linguagem mais adequada em cada circunstância. Nas aplicações web do tipo busca no banco, põe no banco, tira do banco (95% das aplicações web que já participei), usar Java é complicado demais. Na maioria das aplicações web que participei, com Ruby/Rails o trabalho poderia ficar bem mais fácil.
Sim, é possível. Com possibilidade de prazo maior e de custo maior para desenvolver.
Um observação importante: lembrem-se que Ruby não tem tipagem estática e exige muito mais linhas de testes unitários do que Java. E como os Eclipses da vida criam linhas de código para nós, no fim das contas a diferença em número de linhas não é o que aparenta para quem aprende Ruby (até porque ninguém se preocupa hoje em dia com o número de linhas do projeto)
[]s
Luca
Celso,
entendo o seu ponto de que escrever muita informação em apenas uma linha é prejudicial. Se não me engano, existe um princípio em OO de que não se deve chamar um método de um objeto usando vários pontos (esqueci o nome e quem foi o autor desse princípio, se alguém lembrar, avisa!). Exemplo ruim:
anObject.principal().item().compress()
Exemplo bom:
anObject.compressPrincipalItem()
Mas esse tipo de encadeamento é possível em qualquer linguagem, e em qualquer linguagem isso é prejudicial. O ponto de que eu discordo é dizer que Ruby não é bom por ser possível condensar tudo em uma linha. Ora! Isso é a mesma coisa que dizer que Java não é bom porque é possível ter métodos estáticos! Ambas as “features” são dispensáveis, mas ninguém é obrigado a usá-las. E com disciplina, é possível escrever milhares de linhas de códigos sem recorrer a elas.
Eu vou dizer uma coisa que faz com que Ruby seja bom (e que muita gente não percebe, mas sente): esta linguagem permite que você separe lógica do algoritmo da lógica de negócio. Exemplo é como se escreve num arquivo em Ruby:
File.open("test.txt", "w") do |aFile|
aFile << "Is this it?\n"
end
Repare que eu simplesmente “abro” o arquivo e escrevo. Não preciso escrever tratamento para fechar o arquivo, preparar um handler e tudo o mais. Tudo está dentro do método “open”. Isso é bem diferente de Java, onde é necessário seguir uma certa ordem de abertura e fechamento de arquivos.
Pense em como lidávamos com JDBC, onde sempre tínhamos que abrir a Connection, obter Statements e ResultSet, fechar esses três objetos e ainda tratar erros. Alguma vez você conseguiu separar a lógica de manipulação da Connection da lógica de consulta ao banco? E que fosse ainda por cima bonito? Que eu me lembre, no máximo o pessoal fazia um ConnectionUtils para fechar Connection, Statement e ResultSet; e só! Por Ruby ter closures, essa lógica seria facilmente encapsulada em um método, bastaria passar um bloco dizendo o que eu queria que fizesse, sem esse ruído.
Veja que esse negócio de encapsular o algoritmo permeia praticamente todas as APIs do Ruby e do Rails, e o ganho final disso é considerável.
Não acho a parte “Model” do MVC (o que chamei de background) difícil de desenvolver. Essa parte até que flui bem, e os maiores problemas dizem respeito a melhor forma de desenvolver. Aplicar corretamente os princípios da OO. Esse tipo de reflexão acontece em qualquer linguagem OO.
Acho programar as Views e o Controller muito chato.
Um dono de uma empresa que eu trabalhei media a produtividade diária em número de linhas escritas. =)
Abraços.
Celso,Pense em como lidávamos com JDBC, onde sempre tínhamos que abrir a Connection, obter Statements e ResultSet, fechar esses três objetos e ainda tratar erros. Alguma vez você conseguiu separar a lógica de manipulação da Connection da lógica de consulta ao banco? E que fosse ainda por cima bonito? Que eu me lembre, no máximo o pessoal fazia um ConnectionUtils para fechar Connection, Statement e ResultSet; e só! Por Ruby ter closures, essa lógica seria facilmente encapsulada em um método, bastaria passar um bloco dizendo o que eu queria que fizesse, sem esse ruído.Veja que esse negócio de encapsular o algoritmo permeia praticamente todas as APIs do Ruby e do Rails, e o ganho final disso é considerável.
Celso,entendo o seu ponto de que escrever muita informação em apenas uma linha é prejudicial. Se não me engano, existe um princípio em OO de que não se deve chamar um método de um objeto usando vários pontos (esqueci o nome e quem foi o autor desse princípio, se alguém lembrar, avisa!). Exemplo ruim:
anObject.principal().item().compress()Exemplo bom:
anObject.compressPrincipalItem()Mas esse tipo de encadeamento é possível em qualquer linguagem, e em qualquer linguagem isso é prejudicial.
Esse princípio é a Lei de Demeter.
O problema é que não me sinto confortável com várias instruções na mesma linha,.
Não entendi a parte grifada.
Há alguns posts atrás postei uma classe em Java que faz algo bem parecido com isso que você mostrou, com duas linhas.
Também não entendo isso. Não é preciso escrever esse código? Qual a diferença de ser numa closure ou “em outro lugar qualquer”. Inclusive, acho as closures confusas de se ler.
Abraços.
Celso,Pense em como lidávamos com JDBC, onde sempre tínhamos que abrir a Connection, obter Statements e ResultSet, fechar esses três objetos e ainda tratar erros. Alguma vez você conseguiu separar a lógica de manipulação da Connection da lógica de consulta ao banco? E que fosse ainda por cima bonito? Que eu me lembre, no máximo o pessoal fazia um ConnectionUtils para fechar Connection, Statement e ResultSet; e só! Por Ruby ter closures, essa lógica seria facilmente encapsulada em um método, bastaria passar um bloco dizendo o que eu queria que fizesse, sem esse ruído.Veja que esse negócio de encapsular o algoritmo permeia praticamente todas as APIs do Ruby e do Rails, e o ganho final disso é considerável.
Usando Spring podemos encapsular toda essa “parafernália” de acesso ao JDBC. Acho inclusive que o Spring tem simplificado demais (por meio dos seus 312123 wrappers) o desenvolvimento de aplicações corporativas em Java. Se não fosse o Spring e as facilidades que ofereceu nos últimos anos, não tenho dúvida que boa parte das empresas iria acabar migrando de linguagem depois do desastre do EJB 2.
Hum… acho que não é mesma coisa. Há uma diferença quando se compara uma abstração fornecida através de uma API de uma abstração fornecida pela própria linguagem. A primeira opção não é padronizada (cada equipe tem seu jeito de abstrair), não é consistente com todo o sistema e tende a ser complexa. A segunda opção tem mais chance de ser homogêneo com as demais soluções de outras bilbiotecas e tende a ser simples.
Enfim, não vejo muito sentido comparar Spring com closures do Ruby. Até porque nunca houve necessidade de um container de DI em Ruby.
Não é falta de costume?
Eu por exemplo acho um saco fazer operações super simples em collections, como filtrá-las por critérios, usando Java. Dá pra fazer via interfaces e classes anônimas, isso quase vira um método inteiro. Numa linguagem que permitisse um tipo de construção mas breve, eu faria algo como:
lista_nova = lista filter {each.nome ~= /^B.*/}
Nisso te pergunto como profissional experiente, o que acha que o código em pseudo-linguagem acima faz, sem eu te dizer?
É o que digo que poderia fazer algo menor e não prejudicar a legibilidade para quem sabe ler a linguagem. Não é a mesma coisa ler spaguetti
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?
Eu tb programei em assembler e C e C++ e especialmente em VB onde o switch pode ser feito sobre strings. Eu fazia isso o temp todo.
Em java eu não faço isso nunca. Eu também pensei que o switch do java seria uma limitação, mas não é. Quando vc pensa em switch se strings isso significa que você está fazendo POS (Porgramação Orientada a Strings). Isso era comum em VB, Delphi, Clipper, etc… Mas em java isso é sinal que o seu mecanismo não é OO. Ao incorporar OO no modelo o switch desaparece porque simplesmente não é necessário. Coisas mais poderosas e simples como polimorfismo resolvem o problema.
Incluir um switch para String ou para qualquer objecto já agora , como faz o Groovy é ir na mão contrária. É trazer de volta a POS.
Para scripts, POS é normal e talvez por isso essa funcionalidade seja util, mas em Java isso é irrelevante. Pior que isso, em Java, em OO em geral, isso é uma má prática. A feature da linguagem permite a má prática e não o obriga a pensar OO como o Java. Isso, do ponto de vista de OO é um problema.
Eu vou dizer uma coisa que faz com que Ruby seja bom (e que muita gente não percebe, mas sente): esta linguagem permite que você separe lógica do algoritmo da lógica de negócio.
Não entendi a parte grifada.
Há alguns posts atrás postei uma classe em Java que faz algo bem parecido com isso que você mostrou, com duas linhas.
Também não entendo isso. Não é preciso escrever esse código? Qual a diferença de ser numa closure ou “em outro lugar qualquer”. Inclusive, acho as closures confusas de se ler.
Abraços.
Lógica de algoritmo seria assim:
Logica de negócio seria assim:
Inevitavelmente, em Java, a lógica do algoritmo e a lógica do negócio estarão num mesmo método. Em linguagens como Ruby, é possível ter a lógica desse algoritmo separado num método que recebe uma closure, e o usuário só se preocupa com a lógica de negócio.
A vantagem das closures é que o desenvolvedor não precisa se lembrar dos passos necessários que uma API num Java exigiria. Isso liberta o desenvolvedor de detalhes de implementação. Closures são complicadas, mas quando você aprende bem, você consegue dar real valor a elas.
Olá
Não entendi bem o que tem a ver isto com o tema deste tópico. Você costuma fazer isto em Java? Ou em outra linguagem qualquer? Ou está se referindo ao uso de fluent interfaces?
Ué… mas foi justamente por isso que abri o tópico. =D
Você esteve no Falando em Java?
Lá o Kung fez um sistema para gerar números aleatórios usando uma linha (duas porque não coube na tela), mas com 150 comandos nesta linha.
Quando alguém da platéia gritou pedindo para fazer em Java, pois a bagaça não funcionava, ele falou algo assim: Nem morto, em Java eu precisaria de dezenas de linhas.
Eu olhava aquelas duas linhas (uma na verdade) e ficava imaginando: e para debugar uma app com, sei lá, 300 linhas dessas. Vai levar uma eternidade. Prefiro escrever mais linhas, e deixar o código legível, que escrever tudo em uma e ficar meia hora só para entender o que essa linha faz. Esse é o ponto central do meu questionamento.
O ponto é muito simples: Desde quando os programas se medem por linha ?
Em COBOL talvez, mas em Java dificilmente.
Essas métricas do tempo nos nossos avós estão ultrapassadas e não significam nada em linguagens OO.
Em java tb pode escrever tudo em uma linha. Ninguem o obriga a dar enter !
O ponto não é quantes linhas e sim quantas invocações. Se o cara usa 300 métodos encadeados isso é correspondente a 300 invocações.
As mesmas que em java.
E já agora 150 são 15 dezenas. ( Não foi no evento e nao sei se esse 150 tem singificado, mas só para constar.)
Agora, se em X vc H faz N comandos e em Y vc faz H com M comandos então X é mais "produtivo" que Y se N < M ?
Não.
No máximo teria que ser N < M para qualquer H escolhido.
Escolha H = thread, e agora ?
Basta um H onde M > =N para que X não seja mais "produtivo"
Essas métricas são simplesmente absurdas.
Comparar as funcionalidades das APIs é simplesmente ridiculo.
… não é arquitetura web que é complicada. É a sua arquitetura que é complicada.
Celso,Pense em como lidávamos com JDBC, onde sempre tínhamos que abrir a Connection, obter Statements e ResultSet, fechar esses três objetos e ainda tratar erros. Alguma vez você conseguiu separar a lógica de manipulação da Connection da lógica de consulta ao banco? E que fosse ainda por cima bonito? Que eu me lembre, no máximo o pessoal fazia um ConnectionUtils para fechar Connection, Statement e ResultSet; e só! Por Ruby ter closures, essa lógica seria facilmente encapsulada em um método, bastaria passar um bloco dizendo o que eu queria que fizesse, sem esse ruído.Veja que esse negócio de encapsular o algoritmo permeia praticamente todas as APIs do Ruby e do Rails, e o ganho final disso é considerável.
Usando Spring podemos encapsular toda essa “parafernália” de acesso ao JDBC. Acho inclusive que o Spring tem simplificado demais (por meio dos seus 312123 wrappers) o desenvolvimento de aplicações corporativas em Java. Se não fosse o Spring e as facilidades que ofereceu nos últimos anos, não tenho dúvida que boa parte das empresas iria acabar migrando de linguagem depois do desastre do EJB 2.Hum… acho que não é mesma coisa. Há uma diferença quando se compara uma abstração fornecida através de uma API de uma abstração fornecida pela própria linguagem. A primeira opção não é padronizada (cada equipe tem seu jeito de abstrair), não é consistente com todo o sistema e tende a ser complexa. A segunda opção tem mais chance de ser homogêneo com as demais soluções de outras bilbiotecas e tende a ser simples.
Enfim, não vejo muito sentido comparar Spring com closures do Ruby. Até porque nunca houve necessidade de um container de DI em Ruby.
Outra coisa, você diz que usar o Spring (ou outra API) pra conexão com o banco não é consistente com todo o sistema e tende a ser complexo. Não entendi esta afirmação, porque não seria consistente com todo o sistema? Só se cada pessoa da equipe fazer de um jeito, mas aí não é problema de usar a API e sim falha da equipe. E não é nada complexo, muito pelo contrário.
Enfim, estamos saindo do tema do tópico e é melhor pararmos por aqui. Mas sugiro conhecer mais o Spring, se ainda trabalha com Java. Ele faz estas coisas que você citou ja a muito tempo.
Sim. Sempre. É trivial.
Você não pode usar um exemplo de péssimo design e arquitetura para dizer que uma linguagem é ruim. Além de que java.sql não é uma linguagem e sim uma API.
O exemplo que vc deu com file é interessante mais inutil. Em uma arquitetura bem desenhada vc prefere sempre manipular streams e não os arquivos em si. Isso dá origem ao conceito de arquivo virtual. Depois é preciso entender que Java usa do padrão Decorator para trabalar com streams. O conceito de Stream é mais do que canónico e o uso de Decorador com ele, mais do correto.
Se for muito necessário utilizar um codigo igual ao seu (em funcionaldiade) é possivel com java também. Mas tratar arquivos por linha, embora comum, é restrito de mais. Lê um XML com esse mecanismo e depois falamos… Ruby é linguagem de script . Isso por si só ja significa: “não serve para tudo mas é muito bom em casos particulares” Ruby tem que ser comparado com JavaScript e Groovy que tb são linguagens de script e não com Java ou C ou C++ que são linguagem de proposito geral.
Essa conversa de que cada linguagem serve para um coisa é conversa para boi dormir. Linguagens de proposito geral como Java, C e C++ servem para tudo. O foco é outro. E comparar linguagens como escopo difernete é ridiculo.
Qualquer linguagem com high-order functions é capaz de resolver o problema que o Spring se propoe a resolver. Não estou nem falando de meta programação, mas usar o basico de conceitos funcionais disponíveis hoje na JVM.
Sem querer ser chato, mas java não se enquadra nesse propósito geral tmb não. Não se pode programar um pic 18 com java, nem nenhum microcontrolador.(Salvo o do lego mindstorms, mas esse hardware é só pra lego. Eu nunca vi, se alguém conhece, gostaria que me desculpasse a ignorância).
Olhando o site da sun, li um tópico que diz que a jvm vai suportar linguagens dinâmicas no java7. Então tanto faz rodar jruby ou qualquer outra linguagem nela.
http://java.sun.com/developer/technicalArticles/DynTypeLang/index.html
Se for muito necessário utilizar um codigo igual ao seu (em funcionaldiade) é possivel com java também. Mas tratar arquivos por linha, embora comum, é restrito de mais. Lê um XML com esse mecanismo e depois falamos… Ruby é linguagem de script . Isso por si só ja significa: “não serve para tudo mas é muito bom em casos particulares” Ruby tem que ser comparado com JavaScript e Groovy que tb são linguagens de script e não com Java ou C ou C++ que são linguagem de proposito geral.Essa conversa de que cada linguagem serve para um coisa é conversa para boi dormir. Linguagens de proposito geral como Java, C e C++ servem para tudo. O foco é outro. E comparar linguagens como escopo difernete é ridiculo.
Não concordo em que não possamos compará-las, muito menos dizer que linguagens de scripts/interpretadas não são de propósito geral. Elas são. Mais e mais estamos usando Ruby, Python e até mesmo JavaScript(server-side JS, e aplicações do WebOS e do KDE) para produzir programas que eram feitas somente com as não-interpretadas.
Por fim, comparamos elas principalmente quando elas podem fazer a mesma coisa: Aplicações para a Web.
É muito válido.
Ok, esta desculpado… 
Celso,
outra vantagem das closures é que elas te oferecem uma outra forma de abstração que você só encontra em linguagens funcionais, que é a abstração de procedimento.
Nas linguagens OO o principal tipo de abstração que temos é a abstração de dados. Por exemplo, quando usamos composição de objetos pra abstrair uma funcionalidade maior. Nesse tipo de abstração, estamos preocupados em ‘esconder’ como é a estrutura interna do objeto.
Vou dar um exemplo de abstração de procedimento usando JavaScript, que apesar da sintaxe (e o nome :)) ser parecida com a do Java, não parece nem um pouco com o Java semanticamente e tem closures.
Os arrays em JavaScript tem um método sort que pode ser chamado sem parâmetros ou com uma função que fará a ordenação. Por exempĺo:
array.sort() ;
array.sort(function(a, b) {return a - b});
A abstração de procedimento está no segundo método, que ordena o array de acordo com uma função que foi passada como paramêtro. Se quiséssemos ordenar o array inversamente bastaria passar a função function(a, b) {return b - a} como parâmetro. Aqui queremos abstratir como algum procedimento funciona.
Além disso, as clojures permitem algumas técnicas de programação interessantes como currying e memoization.
Sem querer ser chato, mas java não se enquadra nesse propósito geral tmb não. Não se pode programar um pic 18 com java, nem nenhum microcontrolador.(Salvo o do lego mindstorms, mas esse hardware é só pra lego. Eu nunca vi, se alguém conhece, gostaria que me desculpasse a ignorância).
Ok, esta desculpado…
Pode suprir minha ignorância me mostrando um microcontrolador que pode ser programado em java?
Java é o Cobol da primeira (e talvez da segunda década) do século 21. É tão verboso quanto o Cobol, e bem mais complicado. O exemplo do dlt seria mais ou menos assim em Java:
XXX[] array = ...;
Arrays.sort (array, new Comparator<XXX>() {
public int compare (XXX o1, XXX o2) {
return o1.bla.compareTo (o2.bla);
}
}
Mesmo as "closures" que estavam previstas (e foram canceladas) do Java 7 não aliviariam muito a situação. O número de linhas seria equivalente ao do Javascript, mas a notação é mais abstrusa. Seria algo como:
XXX[] array = ...;
Arrays.sort (array, { XXX o1, XXX o2 => o1.bla.compareTo (o2.bla) } );
Pode suprir minha ignorância me mostrando um microcontrolador que pode ser programado em java?
Supra sua ignorância construindo um.
Pode suprir minha ignorância me mostrando um microcontrolador que pode ser programado em java?Supra sua ignorância construindo um.
Pode pedir para a sun construir um para você. Eu estou satisfeito com ansi c.
Tem este projeto aqui ó: http://research.sun.com/projects/dashboard.php?id=145
Tem mais este link de outro forum de cara que fala de outras coisas que parecem interessantes também: http://markmail.org/message/rr7oanygb6grphyq
flws
Pense em como lidávamos com JDBC, onde sempre tínhamos que abrir a Connection, obter Statements e ResultSet, fechar esses três objetos e ainda tratar erros. Alguma vez você conseguiu separar a lógica de manipulação da Connection da lógica de consulta ao banco?
Sim. Sempre. É trivial.
Você não pode usar um exemplo de péssimo design e arquitetura para dizer que uma linguagem é ruim. Além de que java.sql não é uma linguagem e sim uma API.
O exemplo que vc deu com file é interessante mais inutil. Em uma arquitetura bem desenhada vc prefere sempre manipular streams e não os arquivos em si. Isso dá origem ao conceito de arquivo virtual. Depois é preciso entender que Java usa do padrão Decorator para trabalar com streams. O conceito de Stream é mais do que canónico e o uso de Decorador com ele, mais do correto.
Se for muito necessário utilizar um codigo igual ao seu (em funcionaldiade) é possivel com java também. Mas tratar arquivos por linha, embora comum, é restrito de mais. Lê um XML com esse mecanismo e depois falamos… Ruby é linguagem de script . Isso por si só ja significa: “não serve para tudo mas é muito bom em casos particulares” Ruby tem que ser comparado com JavaScript e Groovy que tb são linguagens de script e não com Java ou C ou C++ que são linguagem de proposito geral.Essa conversa de que cada linguagem serve para um coisa é conversa para boi dormir. Linguagens de proposito geral como Java, C e C++ servem para tudo. O foco é outro. E comparar linguagens como escopo difernete é ridiculo.
Pode até ser que a arquitetura do java.sql seja ruim, mas existe uma forma de fazer isso melhor? E de uma maneira tão simples quanto a closures no Ruby? Acredito que não.
O fato é que o algoritmo de busca no banco, apesar de trivial, é repetitivo, e pode muito bem haver deslizes que geram erros a longo prazo (como esquecer de fechar um ResultSet numa conexão sempre aberta). Essa lógica só poderia ser encapsulada com Closures, ou algo que o simule, como as classes anônimas (porém, este é bem feio).
E outra, é possível sim usar Ruby com XML, dê uma olhada em HPricot. Segundo um exemplo da documentação, ler um trecho de XML seria assim:
(doc/:item).each do |item|
title = (item/:title).inner_html
link = (item/:link).inner_html
date = (item/'dc:date').inner_html
# ...
end
Onde a estrutura do código simula bem a estrutura do XML.
Tem este projeto aqui ó: http://research.sun.com/projects/dashboard.php?id=145
Tem mais este link de outro forum de cara que fala de outras coisas que parecem interessantes também: http://markmail.org/message/rr7oanygb6grphyq
flws
O sun spot é um dispositivo embarcado com um processador ARM modelo 920T de 32 bits. Ele tem a Squawk dentro do processador, implementada em hardware. Não é um microcontrolador.
Eu não conhecia, show de bola mesmo. Permite muitas possibilidades em termos de dispositivos embarcados.
Problema que é grande e caro.
Bom, quem se interessou por Scala pode ver o que ele pode fazer com XML.
Veja em:
http://burak.emir.googlepages.com/scalaxbook.docbk.html
Um documento XML:
<html>
<head>
<title>Hello XHTML world</title>
</head>
<body>
<h1>Hello world</h1>
<p><a href="http://scala-lang.org/">Scala</a> talks XHTML</p>
</body>
</html>
Uma aplicação Scala que carrega esse XML em um objeto XML:
object XMLTest1 extends Application {
val page =
<html>
<head>
<title>Hello XHTML world</title>
</head>
<body>
<h1>Hello world</h1>
<p><a >Scala</a> talks XHTML</p>
</body>
</html>;
println(page.toString())
}
E uma forma de atualizar um XML preexistente:
/* examples/xml/phonebook/phonebook2.scala */
package phonebook;
object phonebook2 {
import scala.xml.Node
/** adds an entry to a phonebook */
def add( p: Node, newEntry: Node ): Node = p match {
case <phonebook>{ ch @ _* }</phonebook> =>
<phonebook>{ ch }{ newEntry }</phonebook>
}
val pb2 =
add( phonebook1.labPhoneBook,
<entry>
<name>Kim</name>
<phone where="work">+41 21 111 11 11</phone>
</entry> );
def main( args: Array[String] ) =
Console.println( pb2 )
}
Não é falta de costume?
Claro que não descarto essa possibilidade.
Eu por exemplo acho um saco fazer operações super simples em collections, como filtrá-las por critérios, usando Java. Dá pra fazer via interfaces e classes anônimas, isso quase vira um método inteiro. Numa linguagem que permitisse um tipo de construção mas breve, eu faria algo como:Nisso te pergunto como profissional experiente, o que acha que o código em pseudo-linguagem acima faz, sem eu te dizer?lista_nova = lista filter {each.nome ~= /^B.*/}É o que digo que poderia fazer algo menor e não prejudicar a legibilidade para quem sabe ler a linguagem. Não é a mesma coisa ler spaguetti
Pode fazer como fiz abaixo. Podemos fazer considerações de perfomance e de design, mas funciona. Não sei se algum algoritmo mais eficiente que um "for" possa fazer esse trabalho de filtragem. É óbvio que o "for" para listas de 1.000.000 de elementos será muito ineficiente.
Também precisei escrever algumas linhas, mas apenas uma fez. Levei 10 minutos para escrever a classe e agora posso coloca-la em uma collections-util.jar e usar sempre que precisar.
Concordo que a coisa está ficando um pouco parecida com o Clipper. Depois de um tempo desenvolvendo em Java, você fica com uma grande quantidade de jars que muito se assemelham aos prg's do Clipper. Eu acredito que isso seja inevitável. No início, Ruby cubrirá a maioria das necessidades, mas com o passar do tempo as necessidades mudam e as releases da ferramenta nunca acompanham. Chegará um momento em que o desenvolvedor Ruby ou Scala estará também com uma vasta biblioteca. Espero que a componentização nestas linguagens seja tão simple como em Java. :wink:
Segue o filtro
import java.util.List;
import java.util.ArrayList;
import java.util.regex.Matcher;
import java.util.regex.Pattern;
public class Filter {
private List<String> source;
private String regex = "";
public Filter(List<String> source, String regex) {
if ((source == null) || (regex == null)){
throw new IllegalArgumentException("null argument");
}
this.source = source;
this.regex = regex;
}
public List<String> make(){
if (regex.isEmpty()){
return source;
}
Pattern pattern = Pattern.compile(regex);
List<String> result = new ArrayList<String>();
for (String element: source){
Matcher finder = pattern.matcher(element);
if (finder.find()){
result.add(element);
}
}
return result;
}
}
Usa assim:
List<String> source = new ArrayList<String>();
source.add("aaabbbasdzx");
source.add("aaacccdsas");
source.add("123bbbqwwas");
source.add("aaazzzxzas");
source.add("qqqbbbnnkk");
source.add("zzzyyyczxxcz");
source.add("bbbtttxxzc");
source.add("bbaa33zc23asx");
Filter filter = new Filter(source, "q{1,}");
List<String> filtrado = filter.make();
Um antigo patrão (dono da empresa) gostava de medir a produtividade dessa forma. É claro que não concordo.
Em COBOL talvez, mas em Java dificilmente.
Essas métricas do tempo nos nossos avós estão ultrapassadas e não significam nada em linguagens OO.Em java tb pode escrever tudo em uma linha. Ninguem o obriga a dar enter !
O ponto não é quantes linhas e sim quantas invocações. Se o cara usa 300 métodos encadeados isso é correspondente a 300 invocações.
As mesmas que em java.E já agora 150 são 15 dezenas. ( Não foi no evento e nao sei se esse 150 tem singificado, mas só para constar.)
Agora, se em X vc H faz N comandos e em Y vc faz H com M comandos então X é mais "produtivo" que Y se N < M ?
Não.No máximo teria que ser N < M para qualquer H escolhido.
Escolha H = thread, e agora ?
Basta um H onde M > =N para que X não seja mais "produtivo"Essas métricas são simplesmente absurdas.
Comparar as funcionalidades das APIs é simplesmente ridiculo.
O 150 é fictício. Quando escrevi, sabia que deveria ter colocado um número maior. =)
Creio que você esteja falando da parte javascript.
Eu uso Ajax com o DWR. Olha um exemplo dessa arquitetura que te passei. É de uma ferramenta interna e não tem muita preocupação com design. =D
Estou estudando soluções como o VRaptor. Gostei muito do que vi no evento. Hoje em dia tenho focado muito nas boas práticas de design OO e o estudo de frameworks tem ficado para trás.
var cellFuncs = [
function(data) {return count++},
function(data) {
return "<a + data.numero + ")\">" +
data.numero + "</a>"; },
function(data) { return data.descricao; },
function(data) { return data.horasEstimadas; },
function(data) { return data.qtdConcluida + "%"; }
];
function submeter(numero){
document.frm.numeroDemanda.value = numero;
document.frm.submit();
}
Bom, várias coisas:
Java no chip : procure Sun SPOT. Isso é um exemplo concreto de um chip java. Não ha necessidade real / tecnica para utilizar C a JVM pode correr directamente no chip. Lembre-se que bytecode é um tipo de linguagem de máquina como o assembler. Ok, o SPTO corre JavaME, mas é Java non the less.
Fala sério… vc não está usando ruby, vc deve estar usando Rails que por acaso é em Ruby. Vc não está utilizando as funcioanlidades da linguagem para criar aplicações e sim as do framework. neste aspecto a compara com Spring é válida. JavaScript Server Side não é JavaScript é algo que corre com JS. É como o rails.
Mas suponhamos que vc está mesmo usand ruby/js/ etc… “puro”. Qual é o método/função em JS para acessar arquivos ? Você consegue utilizar dentro do Browser ? Porquê não consegue ? Porque JS corre sempre dentro de outro algo pq é uma linguagem de script. Ou seja, a maioria das funcionalidades que vc usa em ruby ou js-ss não são da linguagem, são de algum sistema ou framework. Em ruby, por exemplo, tem coisa que é realmente feita em C e o ruby apenas mascara a chamada ( hummm… JNI ?)
Realmente linguagem de script é para produzir programas. Agora, para produzir aplicações e sistemas é preciso algum mais. Isso é fato. E a realidade é que as linguagems de script ou evoluem para linguagems gerais ou implementam sub-bibliotecas para coisas nativas com cara de artefato da linguagem (Já o Fortran usava essa tecnica de ter extensões em C)
Com js ou ruby vc faz um programa que corre em um certo ambiente. Com java vc faz o ambiente. São duas coisas diferentes.
Esse é sem comentário. Não estamos falando de ambiente e sim de linguagens.
Linguagem = sintaxe + semantica. Estamos falado de coisas como invocação dinamica , closures, inferencia de tipos, sobrecarga de operadores , etc… e não de escrever páginas html…
Quer discutir qual a melhor linguagem para criar sites ? Abra outro tópico.
Neste está em causa a diferença das linguagens. No máximo das plataformas.
Mas vamos supor que Ruby é o mais excelente para aplicações web. Ok. E para aplicações embarcadas em equipamentos ? aplicações desktop ? aplicações clould ? aplicações educativas ? jogos 3D ? simuladores de tempo real ? aplicações para TV ? celular ? hum… 1 em N não é pouco ?
Agora vc fala que isso não e´java. é a plataforma java. E que nela pode correr groovy ou jruby ou scala ou fortress ou qq outra coisa que rode em JVM. Sim. Exctamente. Então isso deixa claro que migrar para fora da JVM é uma asneira e migrar de linguagem é questão de gosto/experiencia.
Com closures vc reduz a escrita. ok. Mas isso tb é possivel com bibliotecas. Acho que isso está mais do que demonstrado.
O mérito de closures não é reduzir a escrita ou ser mais simples de escrever ( de certa forma até a complica) , o mérito é poder passar blocos de codigo como argumento de métodos e manter a tipagem forte e o controle de execção . Essa sim é uma grande diferença.
Ok, mas isso ja é possivel. Usando Method ou usando uma tecnica como esta :
ArraysUtils.sort(collection, new Object (){
compare (T a , T b ){
return a.x.compareTo(b.x);
}
});
Isto funciona no java atual. Isso é uma “closure”. O ponto é que não é fortemente tipado, não trata exceções de forma adquada e não “fecha sobre o escopo”. Ou seja, não é um closure. Mas o codigo é possivel.
Agora, por outro lado, se eu precisar usar esse codigo 1 vez, a diferença para closures nem é muita. Se eu precisar usar mais que 1 vez eu crio uma lib assim
ArraysUtils.sortXPTOByH(collection)
onde XPTO é a entidade e H a forma de ordenação. Nada é mais explicito que isto. E isto é boa prática em qualquer linguagem. Então, mesmo com closures vc acabaria fazendo isto para N > 1 , logo , a diferença não é assim tanta.
Parece que sempre caimos na mesma falácia : usar exemplo que pecam por um design mal feito ou que não são integrados no contexto de uma aplilação real. Como diz o Joshua Block: “não é porque vc pode fazer que vc usar” é necessária uma “code inteligence” que é mais abstrata que a linguagem que vc usa.
Eu não disse que a api de SQL é ruim. Aliás eu acho que ela é otima. É um excelente exemplo do padrão Bridge que poucas pessoas apreciam ( o usequer conhecem). A JDBC é tvl a API mais bem sucedida de sempre.
Clores dificilemente em alguma coisa haver com SQL, mas vamos lá …
Imagine que o hibernate era uma API do Java … e se chama JPA. Agora vc comprar o JPA com ActiveRecord do rails. (repare que é o JPA do JAVA com o o ActiveRecord do RAILS e não do ruby… mas ok ). Ai vc diz que um é melhor que o outro. Sei la´, tipo “AR é melhor que JPA” e vamos supor que isso é verdade. A falácia é vc imferir que " Se AR é melor que JPA então Ruby é melhor que Java". Isto é totalmente descabido. É como dizer que uma laranja é melhor que um space-shuttle.
O exemplo que vc deu é semelhante ao LINQ do .NET. Ok, é uma feature como qq outra. Uma feature de API à qual o compilador dá suporte nativo. Ok. O compilador do Java tb dá suporte nativo a um monte de API. O ponto não é esse.
Ai vc entra em outra discussão que não tem nada a hver com java ou ruby ou c#. É melhor vc usar esse tipo de suporte “linguistico” ou é mlhor vc usar objetos como sempre ?
A API de criteria é muito melhor que esse negocio que vc deu exemplo. Primeiro porque é OO. A montagem do critério pode ser distribuida e delegada a outros objectos. Segundo porqu segue padrões de OO já reconhecidos (QueryObject). Terceiro porque sendo OO pode ser implementada de diferentes formar por vc mesmo , e não ter que depender de API especiais como no LINQ (que ha 1 LINQ ha uma monte de LINQ to X )
Quarto, mesmo assim vc pode ter o apoio do compilador. Isto é o que pode ser feito em Groovy. A API é puramente OO e são as magias do groovy que simplificam a escrita. Simplificam a escrita, não o modelo, ou o poder da API.
O mesmo pode ser feito para XML , etc…
Alguns queriam algo LINQ-like para o Java. Isso é suicidio. O LINQ coisas como o seu exemplo são um atestado de 'somos muito estupidos para conseguir um modelo OO para isto, então temos que forçar a ajuda do compilador"… triste.
O linguagem Java tem a diretiva de ser simples e concisa. É por isso que tem tão poucas palavras chave e vc precisa escrever tao menos. Compare com C# e verá.
Por fim, coisas com acesso a dados SQL é coisa para API e não para a linguagem. esse era o meu ponto. Comparar o suporte em X para SQL com o suporte em Y é irrelevante para saber se X é melhor/pior que Y.
É legal Java ter closures ? É.
É necessário ? Não.
Tanto não é necessário que não vai ter por mais uma versão (2-3 anos). Se houvesse assim tanto interesse nessa feature da linguagem, ela seria implementada. Algo muito mais banal como suporte nativo ao uso de bigdecimal não passou…
Celso,outra vantagem das closures é que elas te oferecem uma outra forma de abstração que você só encontra em linguagens funcionais, que é a abstração de procedimento.
Nas linguagens OO o principal tipo de abstração que temos é a abstração de dados. Por exemplo, quando usamos composição de objetos pra abstrair uma funcionalidade maior. Nesse tipo de abstração, estamos preocupados em ‘esconder’ como é a estrutura interna do objeto.
Vou dar um exemplo de abstração de procedimento usando JavaScript, que apesar da sintaxe (e o nome :)) ser parecida com a do Java, não parece nem um pouco com o Java semanticamente e tem closures.
Os arrays em JavaScript tem um método sort que pode ser chamado sem parâmetros ou com uma função que fará a ordenação. Por exempĺo:
array.sort() ; array.sort(function(a, b) {return a - b});A abstração de procedimento está no segundo método, que ordena o array de acordo com uma função que foi passada como paramêtro. Se quiséssemos ordenar o array inversamente bastaria passar a função function(a, b) {return b - a} como parâmetro. Aqui queremos abstratir como algum procedimento funciona.
Além disso, as clojures permitem algumas técnicas de programação interessantes como currying e memoization.
Qual seria(m) a(s) diferença(s) de substituir a closure por uma funcionalidade de uma classe? Quais principios de projeto seriam degradados?
Acho que seria algo como:
List<String> listaFiltrada = new FilteredArrayList<String>(new Filter("foo");
Não me referia à JS. Me referi à arquitetura ela mesma. Po exemplo, eu não uso DWR. Pelo simples motivo que eu não uso EJB remoto. Não uso remote method invocation ( e pronto). Ok, tem outras coisas no DWR … no dia que justificar usar o DWR eu usaria, mas não à priori. O mesmo para Spring , VRaptor etc…
Alguem falou que os “inexperientes” acham que o bom é programar tudo do zero. Isso não é uma questão de inexperiencia ( aliás os inexperientes que eu conheço adoram usar frameworks ) é uma questão de arquitetura. Existem trade-offs que têm que ser equacionados.
O bom de fazer à mão, é que vc ganha muito mais experiencia com a linguagem e plataforma e se fizer direito - seguindo OO e boas práticas - vc tem uma biblioteca/API/framework próprio e não precisa mais dos outros. Não estou dizendo que tem que reinventar a roda ( embora eu não veja mal nisso) estou dizendo que a roda da carroça não serve para todos veiculos.
Não me referia à JS. Me referi à arquitetura ela mesma. Po exemplo, eu não uso DWR. Pelo simples motivo que eu não uso EJB remoto. Não uso remote method invocation ( e pronto). Ok, tem outras coisas no DWR … no dia que justificar usar o DWR eu usaria, mas não à priori. O mesmo para Spring , VRaptor etc…Alguem falou que os “inexperientes” acham que o bom é programar tudo do zero. Isso não é uma questão de inexperiencia ( aliás os inexperientes que eu conheço adoram usar frameworks ) é uma questão de arquitetura. Existem trade-offs que têm que ser equacionados.
O bom de fazer à mão, é que vc ganha muito mais experiencia com a linguagem e plataforma e se fizer direito - seguindo OO e boas práticas - vc tem uma biblioteca/API/framework próprio e não precisa mais dos outros. Não estou dizendo que tem que reinventar a roda ( embora eu não veja mal nisso) estou dizendo que a roda da carroça não serve para todos veiculos.
Nesse ponto discordo de você. Se for para melhorar a roda, blz. Mas pelo simples fato de reinventar, acho desnecessário e perigoso. O DWR encapsula muito da complexidade de usar Ajax com Java. Pensa em reinventar o Spring, maravilha. Interessante idéia se for no sentido de evolução.
Muitos poderiam dizer que o VRaptor estaria reinventando a roda, mas acredito que caminha no sentido da evolução. E com isso, só a plataforma tem a ganhar.
Não sou “framework-based”. Normalmente, nos meus projetos, uso apenas o Hibernate e o DWR. Spring muito raramente. Como eu disse estou muito focado no design OO, vou começar a estudar o livro do Meyer. Mas não por isso deixo de acreditar no lugar e do poder dos frameworks.
Fala sério… vc não está usando ruby, vc deve estar usando Rails que por acaso é em Ruby. Vc não está utilizando as funcioanlidades da linguagem para criar aplicações e sim as do framework. neste aspecto a compara com Spring é válida. JavaScript Server Side não é JavaScript é algo que corre com JS. É como o rails.
Alguém que está usando Rails não está usando Ruby? Não está usando as funcionalidades da linguagem e sim as do framework? COMO É QUE É? De onde você tirou isso?
Mas suponhamos que vc está mesmo usand ruby/js/ etc… “puro”. Qual é o método/função em JS para acessar arquivos ? Você consegue utilizar dentro do Browser ? Porquê não consegue ? Porque JS corre sempre dentro de outro algo pq é uma linguagem de script. Ou seja, a maioria das funcionalidades que vc usa em ruby ou js-ss não são da linguagem, são de algum sistema ou framework. Em ruby, por exemplo, tem coisa que é realmente feita em C e o ruby apenas mascara a chamada ( hummm… JNI ?)
Você consegue abrir arquivos com JS sim. É claro que você não vai tentar fazer isso de dentro de um browser, você vai usar Rhino que roda em cima da JVM. Quer dizer então que Java uma “linguagem de script”, porque “roda em cima de outro algo” (JVM)?
Realmente linguagem de script é para produzir programas. Agora, para produzir aplicações e sistemas é preciso algum mais. Isso é fato.
Qual a diferença entre programas, aplicações e sistemas? Até antes desse seu post eu achava que eram sinônimos.
Ruby é usado em todos cenários citados, exceto TV e simuladores de tempo real.
Bom, várias coisas:Java no chip : procure Sun SPOT. Isso é um exemplo concreto de um chip java. Não ha necessidade real / tecnica para utilizar C a JVM pode correr directamente no chip. Lembre-se que bytecode é um tipo de linguagem de máquina como o assembler. Ok, o SPTO corre JavaME, mas é Java non the less.
Eu olhei, e achei muito interessante. Mas não é um microcontrolador, é um sistema embarcado pra sensores e telecomunicações.
Digo um microcontrolador como um pic16, que eu pudesse desenvolver a placa e programar o firmware em java. Isso seria uma revolução.
O sun spot tem a squawk implementado no processador dela, um ARM.
É mesmo muito interessante.
Olá
Pois é… a discussão estava gostosa. Um bate papo sem compromisso. Porém… tinha que acontecer…
Pena… arroubos e arrotos de arrogância… só um detem o conhecimento… o que os outros escrevem são exemplos inúteis, ridículos e por aí vai o modo gentil de conversar do mau dialogador.
O pior é que nem sabe tanto assim. Escreve demais e como todo falastrão acaba dizendo bobagens. Aquela do “Fortran usava essa técnica de ter extensões em C” … é sem comentários.
Gente, parei por aqui neste tópico. Venho para me divertir e não para me aborrecer. Se alguém vem aqui só para menosprezar os outros, é melhor destilar seu mau humor no seu próprio blog.
[]s
Luca
. Não sei se algum algoritmo mais eficiente que um “for” possa fazer esse trabalho de filtragem. É óbvio que o “for” para listas de 1.000.000 de elementos será muito ineficiente.
Será? Nessas linguagens novas (Scala etc.) o “for” não é exatamente um laço de repetição estúpido e sim uma outra coisa, que só avalia e gera os elementos de uma lista à medida que é necessário. Assim as coisas não são tão ineficientes assim, e podem ser encadeadas sem problemas. E esse conceito também foi absorvido pelo C#, que tem até uma construção especial para isso (“yield”). É o Java que tem de carregar um monte de legado e compatibilidade retroativa que absorve mal as mudanças.
. Não sei se algum algoritmo mais eficiente que um “for” possa fazer esse trabalho de filtragem. É óbvio que o “for” para listas de 1.000.000 de elementos será muito ineficiente.
Será? Nessas linguagens novas (Scala etc.) o “for” não é exatamente um laço de repetição estúpido e sim uma outra coisa, que só avalia e gera os elementos de uma lista à medida que é necessário. Assim as coisas não são tão ineficientes assim, e podem ser encadeadas sem problemas. E esse conceito também foi absorvido pelo C#, que tem até uma construção especial para isso (“yield”). É o Java que tem de carregar um monte de legado e compatibilidade retroativa que absorve mal as mudanças.
Esse é um aspecto interessante que até então eu desconhecia. Com certeza, ter laços mais eficientes é uma vantagem. Mas não entendi como esse mecanismo (avaliação e geração por demanda) pode ser mais eficiente. Normalmente em um filtro eu demando todos elementos para comparação. Não no mesmo momento, mas preciso de todos. Existe algum benchmark que dê números reais a esse aumento de eficiência. Como esse mecanismo por demanda funciona?
encontrei um microcontrolador da família pic que pode rodar java.
http://www.oopic.com/
Seu compilador suporta sintaxe java, mas o resultado é código nativo do pic. Vantagem codificar em java pelo conforto da linguagem.
Esse é um aspecto interessante que até então eu desconhecia. Com certeza, ter laços mais eficientes é uma vantagem. Mas não entendi como esse mecanismo (avaliação e geração por demanda) pode ser mais eficiente.
Não é eficiente no quesito “rapidez” (já que uma “lazy list” tem um overhead significativo), mas no quesito “tempo de resposta”.
É em outro sentido (você pode obter o resultado mais rapidamente e usando menos memória, já que em vez de gerar uma lista completa toda em memória, filtrá-la de uma vez para gerar outra lista, você simplesmente indica que o resultado é uma “lazy list”, que será consumida por demanda por outro método, que pode gerar ou não uma outra “lazy list”. ).
Você pode até definir “listas infinitas” (onde você tem um método que gera as tais listas), que podem ser consumidos por outros métodos.
No C# o LINQ tem um conceito semelhante (você pode pegar um resultado aos poucos - lazy - ou então pegar o resultado todo de uma vez. Por exemplo, se você precisa de um resultado ordenado, é necessário, em algum momento, pegar o resultado todo de uma vez, e então ordená-lo. Mas se você quer apenas um resultado filtrado, você não precisa pegar tudo, só percorrer um iterador referente ao tal resultado.
Esse é um conceito interessante, muito usado em acesso a dados em SGDB. Mas continuo sem ver como isso ajudaria a filtragem de uma lista.
Ela não está completa em memória, mas está completa em algum lugar. Em um SGDB, é lógico onde está o todo, mas e na lazy list? Provavelmente no disco. E acho que é a esse overhead que você se referiu. Concordo que a iteração em uma lista menor por vez pode gerar ganhos significativos de perfomance, mas se colocar esse overhead na balança, talvez esse ganho não seja tão significativo.
Mas se você quer apenas um resultado filtrado, você não precisa pegar tudo, só percorrer um iterador referente ao tal resultado.
Blz… mas não é justamente essa iteração que é o gargalo do algoritmo? Isso precisa ser feito em algum lugar. Pode estar encapsulado em uma funcionalidade da linguagem, mas tem que existir. Não conheço algoritmos mais eficientes de filtragem como existe para ordenação, como o Bubble Sort. Pode ser que exista, mas não conheço.
Fala sério… vc não está usando ruby, vc deve estar usando Rails que por acaso é em Ruby. Vc não está utilizando as funcioanlidades da linguagem para criar aplicações e sim as do framework. neste aspecto a compara com Spring é válida. JavaScript Server Side não é JavaScript é algo que corre com JS. É como o rails.
Mas suponhamos que vc está mesmo usand ruby/js/ etc… “puro”. Qual é o método/função em JS para acessar arquivos ? Você consegue utilizar dentro do Browser ? Porquê não consegue ? Porque JS corre sempre dentro de outro algo pq é uma linguagem de script. Ou seja, a maioria das funcionalidades que vc usa em ruby ou js-ss não são da linguagem, são de algum sistema ou framework. Em ruby, por exemplo, tem coisa que é realmente feita em C e o ruby apenas mascara a chamada ( hummm… JNI ?)Realmente linguagem de script é para produzir programas. Agora, para produzir aplicações e sistemas é preciso algum mais. Isso é fato. E a realidade é que as linguagems de script ou evoluem para linguagems gerais ou implementam sub-bibliotecas para coisas nativas com cara de artefato da linguagem (Já o Fortran usava essa tecnica de ter extensões em C)
Com js ou ruby vc faz um programa que corre em um certo ambiente. Com java vc faz o ambiente. São duas coisas diferentes.
Olha, eu posso fazer um compilador que Ruby que compile para um código que a máquina entenda da mesma forma que posso fazer com Java. Aliás é isso que fazem com o JRuby, o compilam para a máquina virtual, da mesma forma que Java é compilado para a mesma máquina virtual.
Se você faz programas em JS e Ruby que são interpretados em certos ambientes, eu faço programas em Java que também são interpretados nestes mesmos ambientes. Se você faz ambientes com Java, também o faço com qualquer linguagem normal.
Todas produzem zeros e uns no final, então todas podem fazer a mesma coisa. A diferença é o quanto elas facilitam para fazer essas tarefas.
Agora se você diz que não dá para comparar as APIs que vem com a linguagem, eu concordo. A do Java é um monstro mesmo.
Fala sério… vc não está usando ruby, vc deve estar usando Rails que por acaso é em Ruby. Vc não está utilizando as funcioanlidades da linguagem para criar aplicações e sim as do framework. neste aspecto a compara com Spring é válida. JavaScript Server Side não é JavaScript é algo que corre com JS. É como o rails.
Alguém que está usando Rails não está usando Ruby? Não está usando as funcionalidades da linguagem e sim as do framework? COMO É QUE É? De onde você tirou isso?
Se um simples fato. quando vc faz “rails minhaapp” é uma coisa nativa ao ruby ou ao rails ? Se acha que é do ruby, remova o rails e tente executar o mesmo comando.
Um exemplo mais altonivel é ActiveRecord. Tudo bem que não é o Rails e apenas um componente do Rails, mas é nativo do ruby ? Não. É construido com Ruby, da mesma forma que JPA é construido com Java.
O Rails é um framework e está no nivel de abstraçção acima de um Mentaway , VRapor ou Spring. No mesmo nivel que um Grails.
O Ruby é uma linguagem. Experimente o Grails. vai ver que consegue o mesmo que em Ruby on Rails. Portanto fazer sites com essa facilidade não é uma coisa que depende da linguagem e sim do frameowrk utilizando que tem um certo poder. Um projeto “antigo” chamado JSpider ( se não me falha a memoria) era algo no nivel do rails mas diferente. Todos esses são application generators, que é um tipo de framework que mistura features de ferramenta.
O Grails é escrito usando o Hibernate e não o ActiveRecord. Mas uma implementação de ActiveRecord é possivel em Groovy já que ele tem as mesmas features de linguagem que ruby. Então, em tese, tudo o que existe em RoR poderia ser migrado para groovy sem problemas. É que o pessoa do Groovy optou por usar frameworks já consagrados. O ponto é este : Rails é um tipo de webapplication generator que mistura features de ferramenta com features de framwork. Nada disto tem a haver com a linguagem em si.
Então não é o JS que abre o arquivo, é a API Java que o JS manipula via Java Scripting. Isto é obvio.
Embora a linguagem seja o JS a API é do Java. O ponto era ilustrar a diferença entre uma linguagem e uma API.
O ambiente do JS é uma API . O JS roda dentro de uma API, uma biblioteca ( A Java Scripting). Java corre em cima de uma máquina.
É diferente.
Legal. Então vc pode listar exemplos de uso de ruby em cada uma das categorias ? ( estou especialmente curioso para saber como ruby acessa openGL ou que não seja através da biblioteca nativa escrita em C como a SDL… É que o Java tb use esse truque via API. Então não é justo dizer que isso é uma feature da linguagem… )
Não é eficiente no quesito “rapidez” (já que uma “lazy list” tem um overhead significativo), mas no quesito “tempo de resposta”.
Esse é um conceito interessante, muito usado em acesso a dados em SGDB. Mas continuo sem ver como isso ajudaria a filtragem de uma lista.
Ela não está completa em memória, mas está completa em algum lugar. Em um SGDB, é lógico onde está o todo, mas e na lazy list? Provavelmente no disco. E acho que é a esse overhead que você se referiu. Concordo que a iteração em uma lista menor por vez pode gerar ganhos significativos de perfomance, mas se colocar esse overhead na balança, talvez esse ganho não seja tão significativo.
Mas se você quer apenas um resultado filtrado, você não precisa pegar tudo, só percorrer um iterador referente ao tal resultado.Blz… mas não é justamente essa iteração que é o gargalo do algoritmo? Isso precisa ser feito em algum lugar. Pode estar encapsulado em uma funcionalidade da linguagem, mas tem que existir. Não conheço algoritmos mais eficientes de filtragem como existe para ordenação, como o Bubble Sort. Pode ser que exista, mas não conheço.
Bubble Sort é um dos piores para ordenação ;). E um algoritmo de filtragem que pode considerar é por exemplo que use várias CPUs de uma vez, como o divisão e conquista.
O que tem que pensar mesmo é quando coleções inteiras são uma vantagem, e quando um ter só iterador para elas é melhor.
Para este último já existe até um paradigma de programação próprio, o Stream Processing. Normalmente é usado em aplicações em tempo real, ou aquelas que você precise ter o resultado na tela o mais rápido possível, e não dá pra ficar esperando a aplicação carregar tudo e processar.
Paginação de resultados é outro uso que tenho em mente.
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.
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.
E o que isso tem a ver com a implementação OO do Ruby? Já trabalho com Java faz 6 anos, e antes disso já o usava bastante.
Desenvolver em Rails não é só usar esses geradores de código. Isso é só uma parte do desenvolvimento, a menor delas. É preciso escrever muitas linhas de código em Ruby pra uma aplicação web. Não faz o menor sentido dizer que alguém que usa o framework não está programando em Ruby.
Não interessa em cima de que a linguagem foi construída. Interessa é que é possível sim abrir arquivos usando JavaScript.
Uma hora você fala que linguagem é só sintaxe e semântica, outra hora faz considerações sobre o ambiente em que a linguagem foi desenvolvida. Se a linguagem roda em cima da JVM ou usa a API do Java não vale… Seja mais coerente.
Legal. Então vc pode listar exemplos de uso de ruby em cada uma das categorias ? ( estou especialmente curioso para saber como ruby acessa openGL ou que não seja através da biblioteca nativa escrita em C como a SDL… É que o Java tb use esse truque via API. Então não é justo dizer que isso é uma feature da linguagem… )Ruby é usado em todos cenários citados, exceto TV e simuladores de tempo real.
Releia minha frase: “Ruby é usado em todos cenários citados, exceto TV e simuladores de tempo real.”
Por acaso eu disse que acesso a OpenGL é uma feature da linguagem? Não.
Eu disse que Ruby é usado nos cenários que você citou, apenas pra desbancar seu argumento falacioso de que Ruby só serve pra web. Como isso é feito são outros quinhentos.
Desktop: Shoes, bindings pra Gtk, ruby/tk, FXRuby, JRuby + Swing, entre outros.
Embebbed: Apresentação sobre Ruby embarcado.
Apps cloud: JRuby no Google Application Engine
Aplicações educativas: o que impede alguém de desenvolver uma aplicação educativa em Ruby?
Games 3D: Wolfstein. Tem vários bindings pra bibliotecas 3D.
Celular: Aplicações pro Iphone
Eu fui muito ingênuo ao cair na tentação de responder um troll. Respondi só pra desmitificar alguns argumentos infundados.
Desenvolver em Rails não é só usar esses geradores de código. Isso é só uma parte do desenvolvimento, a menor delas. É preciso escrever muitas linhas de código em Ruby pra uma aplicação web. Não faz o menor sentido dizer que alguém que usa o framework não está programando em Ruby.
Pois é. Mas quando vc usa Spring vc fala “estou usando SPring” e não “Estou usando Java”. É obvio que vc vai programar com a linguagem. O ponto da conversa - que vc esqueceu - é saber se o Ruby é assim tão melhor que o Java ( não é comparável, é coisa de gosto) e se migrar do ambiente java para o do ruby (que não o JRuby) é uma boa escolha.
O argumento usual é que Ruby:
A conclusão é simples: quer mudar de linguagem ? escolha outra que não ruby. Quer mudar de plataforma ? Grande asneira.
Eu sou coerente. É você que afirmou que " sim abrir arquivos usando JavaScript" e “É claro que você não vai tentar fazer isso de dentro de um browser, você vai usar Rhino que roda em cima da JVM.”
Admita, vc não sabe a diferença entre uma linguagem de script e uma linguagem de proposito geral.
Esse é o ponto. Não é uma feature da linguagem, tal como em Java não é. Mas em Java é uma feature de um API tal como em Ruby é uma feature de uma API. Não podemos comparar linguagens com base nas suas API padrão ou extensões. Apenas de features da linguagem si mesma. ( a sua sintaxe, a sua semantica, etc…). Se falamos de API, performance, facilidade de criar aplicações do tipo X usando frameworks ( que são APIs). estamos falando da plataforma. E vc acha -seja honesto - que a plataforma ruby é melhor ( mais robusta,mais confiável, mais abrangente) que a plataforma Java ?
Eu , sendo honesto, acho que ainda não. E portanto, mudar agora é suicidio. Scala, por exemplo (que não é uma linguagem de script), ou Groovy (que compete com ruby) são muito melhor candidatos. E como o inventour do Groovy já falou que se conhecesse scala não teria inventado o groovy, ora ai tem quem está sendo escolhido como a alternativa à linguagem Java. Mas a plataforma ? essa é a Palaforma Java. A razão é simples. É a mais evoluida que existe no mercado (univeersidades e prototipos não valem).
Você foi ingênuo ao pensar que pode convencer alguem que Ruby ( linguagem ou plataforma) é melhor que a concorrencia.
O argumento usual é que Ruby:
- é melhor porque se fazem aplicações web mais depressa. Ok. O meu contra-argumento é “mais depressa não significa melhor” e “é mais depressa por causa do Rails, retire o rails e vai demorar tanto ou mais” e “o mesmo é possivel com groovy - que é java based - logo migrar para ruby não tem vantagem tecnica”
É mais depressa porque o Ruby é mais alto-nível e mais expressivo que Java, embora estas sejam características muito subjetivas. A própria natureza dinâmica da linguagem te permite automatizar coisas repetitivas na hora de escrever código com facilidade. Rails permite desenvolver tão depressa por causa das features do Ruby, não o contrário. Existem outros frameworks altamente produtivos (Ramaze, Merb, etc…) que foram construídos em cima dessas features.
Ok, mas esse argumento não é sobre o número de linhas, é sobre o quanto você precisa se focar nas regras de negócio da sua aplicação ao invés de detalhes de baixo nível como abrir arquivos, etc…
4) O projeto JRuby quer correr ruby sobre um JVM porque existem problemas de performance, gc, threads, etc… na vm padrão.
Temos noticias de sites que foram construidos em ruby e estão sendo obrigados a mudar para outra coisa porque ruby ( não jruby) não escala a contento e/ou é dificil manter a longo prazo. Coisas como scala estão substituindo o rubi e até o JRuby acaba sendo uma machadada no ambiente ruby não baseado em JVM. Portanto, sair para a “plataforma” ruby fora da JVM é asneira neste momento.
Apesar dos seus defeitos a MRI ainda é insubstituível em alguns cenários, até porque o JRuby não é 100% compatível com muitas gems.
Esse assunto de escalabilidade é tão polêmico quanto este que estamos discutindo e existem controvérsias a respeito da substituição de partes do Twitter originalmente escritas em Ruby por Scala. Tem gente que argumenta que os problemas de escalabilidade do Twitter não foram culpa do Ruby.
Manutenibilidade de código é responsabilidade do programador, não da linguagem.
Escolha Ruby pros casos certos. Não deixa nada a desejar em relação a Java em vários aspectos.
Não existe um consenso sobre o que é uma “linguagem de script”. Ruby, Python, Perl e outras “linguagens de script” são também linguagens de propósito geral.
Podemos e devemos. Muitas vezes Python ou Java são escolhidas pra uma situação justamente por causa das bibliotecas.
Não. Entretanto, Ruby roda em cima da plataforma Java. Irônico, não?
Não acho que Ruby é melhor linguagem/plataforma que a concorrência. Python, JavaScript, Lua, Scheme, Scala, e pasme, até Java são melhores do que Ruby dependendo do contexto. Ingenuidade é acreditar em balas de prata.
Dalto, sério, desiste, é pura perda de tempo
Desisti já. Foi a última msg.
Você foi ingênuo ao pensar que pode convencer alguem que Ruby ( linguagem ou plataforma) é melhor que a concorrencia.
Pra mim concorrência é ignorância.
Por mim que se matem os evangelistas, defender com unhas e dentes uma plataforma, num fórum de internet, é massagear o ego pra depois ver o tempo perdido que tiveram.
Eu já trabalhei com .NET, com Java e agora com RoR e não fico defendendo nem um nem outro, acho que cada um tem suas qualidades e defeitos, mas acho que abrir a cabeça foi a melhor coisa pra mim, vou repetir, PRA MIM!
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.
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.
E o que isso tem a ver com a implementação OO do Ruby? Já trabalho com Java faz 6 anos, e antes disso já o usava bastante.
Ruby usa metaprogramacao baseado na manipulacao de objetos em tempo de execucao.
Você acha que o Rails usa API de reflection do Java por baixo dos panos?
ficar discutindo linguagens é uma idiotice que, pelo visto, a maioria dos usuários desse fórum adoram fazer.
No final o compilador vai transformar tudo em assembler de um tipo de microprocessador, então nem sei porque discutem.
Ruby usa metaprogramacao baseado na manipulacao de objetos em tempo de execucao.Você acha que o Rails usa API de reflection do Java por baixo dos panos?
O que é extremamente limitado. O Ruby está longe de ser algo bom, e alguns apenas insistem porque não conhecem nada além disso.
Sabe, eu concordo que Java tenha algumas desvantagens em termos de linguagem, mas as bibliotecas e a VM meio que compensam. O que me deixa indignado é como alguém pode reclamar de abrir um FileInputStream.
Qual é a dificuldade disso? A flexibilidade de uma linguagem não se conta em quantidade de teclas por classe. Se você quiser extenda FileInputStream e dê um nome tipo “A”. Simples, rápido e você só precisou digitar uma letra. :roll:
Você poderia dizer o que é menos limitado do que open classes?
Você poderia dizer o que é menos limitado do que open classes?
Macros. Common Lisp faz o que o Ruby faz e muito mais.
Ruby usa metaprogramacao baseado na manipulacao de objetos em tempo de execucao.Você acha que o Rails usa API de reflection do Java por baixo dos panos?
O que é extremamente limitado. O Ruby está longe de ser algo bom, e alguns apenas insistem porque não conhecem nada além disso.
O que é uma coisa boa, e o que é uma coisa ruim?
Sei que o próprio http://mediacast.sun.com/, da própria sun roda rails.
Não sou o dono da verdade, mas o pouco que usei de rails, percebi que realmente é muito produtivo.
Olá
Maurício, sério, desiste, é pura perda de tempo - o retorno
[]s
Luca
E você programa profissionalmente em common lisp né?
OláMaurício, sério, desiste, é pura perda de tempo - o retorno
[]s
Luca
Pois é, não sei o que me deu. Crise pós almoço provavelmente, parei
Mas veja, isso é escolher uma plataforma. Existem plataformas que forçam uma certa linguagem e outras que não.
.NET e Java não forçam uma certa linguagem. Python sim. Ruby (vm original) sim.
Então não estamos falando de escolher entre a linguagem x e y e sim entre a plataforma A e B.
Escolher plataformas conforme a arquitura é natural. E ai sim, cada uma para o seu proposito. Mas a linguagem em si, nao é ligada ao proposito. Ela advém da escolha da plataforma.
A questão é que não ha vantagem em escolher a plataforma rubi sobre a java.
A linguagem ruby roda sobre a plataforma Java. Assim como outras.
Qual linguagem roda sobre a plataforma ruby além de ruby ? nenhuma.
Então se eu quiser aprender uma nova linguagem, ruby é tão boa escolha como grovvy ou scala. Mas se eu quiser mudar plataforma tem que haver uma muito boa razão tecnica/economica para isso. Razão tecnica não ha. Economica ? Se ha razões economicas ok. Serão do mesmo tipo que entre Java e .NET , o ponto é que ai estaremos foram do ambito da tecnologia e não mais dicutindo as linguagens ou as plataformas mas outras coisas como o preço por hora de um programador ruby e um java.
Mas tem mais. A linguagem ruby não roda sobre a plataforma java. ela roda sobre uma VM escrita sobre a plataforma Java. É um nivel de indireção a mais que o groovy ou o scala não têm. Então , até mesmo o port para JRuby é complexo e falho em comparação com as alternativas na plataforma java.
O que eu estou dizendo é o seguinte: assumindo que a linguagem ruby é melhor que a linguagem java, a plataforma Java é melhor que plataforma rubi. Assim é obvio que ficarei com a plataforma Java e posso migrar para a linguagem ruby sobre a jvm. Ok. Mas ao pensar que vou trocar a linguagem java por outra da plataforma Java, existem outras opções : scala e groovy , por exemplo.
Neste cenário a escolha é entre a linguagem ruby e estas. E nesse ambito ruby perde.
Em termos de featuras da linguagem groovy tem as todas e com a vantagem de ter a sintaxe de java. Isto, economicamente e´um vantagem porque não precisa haver um pesado retreino dos programadores. E scala tem features diferentes mas de poder igual.
quando existir um ScalaOnRails o mundo via esquecer ruby ( a plataforma e a linguagem)
Além de Java e Scala que partilham a mesma plataforma é dicifil aceitar que as outras sejam plataformas. Plataforma é algo maior que um linguagem um jvm e um API.
O ponto é que eu não vou gastar meu dinheiro na reinvenção da roda. A plataforma java já atende e é mais poderosa que qualquer das concorrentes.
A questão da linguagem é coisa de gosto e necessidade. E portanto, não se pode discutir qual é a melhor. Agora, plataforma é obvio que a Java é a melhor neste momento.
Quanto à API ter problemas e etc… é para isso que serve a JCP. Não está satisfeito, crie uma não API e mande para examinação. Afinal a Data Time veio do JodaTime o EJB3/JPA do Spring e Hibernate, e assim vai… Nada isso influencia a linguagem. Em Scala ou Groovy vc usa o mesmo FileInputStream que no Java.
ficar discutindo linguagens é uma idiotice que, pelo visto, a maioria dos usuários desse fórum adoram fazer.
No final o compilador vai transformar tudo em assembler de um tipo de microprocessador, então nem sei porque discutem.
Meu objetivo aqui não foi discutir linguagem A e B. A idéia central é discutir a tendência de mercado proposta pelo James no blog dele. É óbvio que isso leva a discussões de aspectos das ferramentas. Mas, sob meu ponto de vista, é muito mais interessante que um Java x c#, por exemplo.
Mas existe.
Isso não seria sistema distribuido e não um algoritmo?
Desculpa a ignorância, mas qual processo, em baixo nível, acontece aqui?
Não é eficiente no quesito “rapidez” (já que uma “lazy list” tem um overhead significativo), mas no quesito “tempo de resposta”.
Esse é um conceito interessante, muito usado em acesso a dados em SGDB. Mas continuo sem ver como isso ajudaria a filtragem de uma lista.
Ela não está completa em memória, mas está completa em algum lugar. Em um SGDB, é lógico onde está o todo, mas e na lazy list? Provavelmente no disco. E acho que é a esse overhead que você se referiu. Concordo que a iteração em uma lista menor por vez pode gerar ganhos significativos de perfomance, mas se colocar esse overhead na balança, talvez esse ganho não seja tão significativo.
Mas se você quer apenas um resultado filtrado, você não precisa pegar tudo, só percorrer um iterador referente ao tal resultado.Blz… mas não é justamente essa iteração que é o gargalo do algoritmo? Isso precisa ser feito em algum lugar. Pode estar encapsulado em uma funcionalidade da linguagem, mas tem que existir. Não conheço algoritmos mais eficientes de filtragem como existe para ordenação, como o Bubble Sort. Pode ser que exista, mas não conheço.
Thingol, gostaria de ler a sua opinião sobre isso, seria possível? Se não for, tudo bem também.
Será que escrevi tanta caca que não merece ser consertado?
Vejamos eu tenho Grails para groove, assim como eu tenho X para Scala ?
Eu tenho Rails para Ruby , assim como tenho JRuby para J2EE, assim como tenho JPython para J2EE
Vejamos eu tenho Grails para groove, assim como eu tenho X para Scala ?Eu tenho Rails para Ruby , assim como tenho JRuby para J2EE, assim como tenho JPython para J2EE
X = Lift
Vejamos eu tenho Grails para groove, assim como eu tenho X para Scala ?Eu tenho Rails para Ruby , assim como tenho JRuby para J2EE, assim como tenho JPython para J2EE
X = Lift
Boa não conhecia essa tecnologia para Scala, uma coisa é certa a velocidade de transformação dessas linguagens chega a ser absurdo o dominio para tantas soluções, brecar nao pode e evoluir exigi que a tecnologia avance tambem nos padrões que ela oferece não é o caso do mercado brasileiro mesmo !!!
Você poderia dizer o que é menos limitado do que open classes?
Macros. Common Lisp faz o que o Ruby faz e muito mais.
Porrra, qualquer lisp deixa Ruby no chinelo.
Fazia tempo que eu não lia um tópico com tanta gente falando besteira ao mesmo tempo. Estamos num forum inicialmente criado para Java mas hoje em dia temos várias alternativas para desenvolvimento (Java inclusive). Como já disseram uma vez, para quem só tem martelo todo problema é um prego.
O Maurício e o Luca já disseram, não vale nem a pena tentar ensinar um cego a enxergar simplesmente porque ele por natureza não tem condições para isso.
[]s
Fazia tempo que eu não lia um tópico com tanta gente falando besteira ao mesmo tempo. Estamos num forum inicialmente criado para Java mas hoje em dia temos várias alternativas para desenvolvimento (Java inclusive). Como já disseram uma vez, para quem só tem martelo todo problema é um prego.O Maurício e o Luca já disseram, não vale nem a pena tentar ensinar um cego a enxergar simplesmente porque ele por natureza não tem condições para isso.
[]s
Em se tratando de um martelo de proposito geral, como é o caso das linguagens que estamos discutindo aqui, o prego pode ser de todo tipo, tão diferentes ao ponto de interessarem pessoas completamente diferentes. Eu quero uma linguagem sim que possa resolver todo problema que vier, como java foi no passado. Até mesmo o google usa basicamente python para a maioria dos seus projetos.
Em se tratando de um martelo de proposito geral, como é o caso das linguagens que estamos discutindo aqui, o prego pode ser de todo tipo, tão diferentes ao ponto de interessarem pessoas completamente diferentes. Eu quero uma linguagem sim que possa resolver todo problema que vier, como java foi no passado. Até mesmo o google usa basicamente python para a maioria dos seus projetos.
“Cada fornecedor um produto, para cada produto uma solução, para cada solução a melhor escolha tecnologica”
Em se tratando de um martelo de proposito geral, como é o caso das linguagens que estamos discutindo aqui, o prego pode ser de todo tipo, tão diferentes ao ponto de interessarem pessoas completamente diferentes. Eu quero uma linguagem sim que possa resolver todo problema que vier, como java foi no passado. Até mesmo o google usa basicamente python para a maioria dos seus projetos.
Java foi no passado !? Amigo, java foi criado para pequenos dispositivos e para resolver problemas de TI.
Nenhum engenheiro vai usar java em eletrônica digital ou pesquisas científicas. Para cálculo, fortran ainda é mais indicado, e hardware, não serve nem mesmo c++. Tem que ser ansi c ou assembler.
O fato de java não servir para eletrônica digital não ter nada haver com sintaxe de linguagem, e sim arquiterura. A máquina virtual.
O único hardware que suporta byte code, que é o sun spot, custa $ 769,00. Não tem engenheiro que lançaria um produto com isso no mercado. Um pic custa menos de R$ 5,00
Fazia tempo que eu não lia um tópico com tanta gente falando besteira ao mesmo tempo. Estamos num forum inicialmente criado para Java mas hoje em dia temos várias alternativas para desenvolvimento (Java inclusive). Como já disseram uma vez, para quem só tem martelo todo problema é um prego.O Maurício e o Luca já disseram, não vale nem a pena tentar ensinar um cego a enxergar simplesmente porque ele por natureza não tem condições para isso.
[]s
Mas e aí?
Brinde-nos com a sua grande sabedoria, pois até agora só criticou. Mas sem babar ovo de moderador. Fala o que você acha. E não tenha medo… todos podemos nos enganar sobre algum conceito ou, simplesmente, errar.
O que você pode agregar a discussão, já que por aqui “tanta gente está falando besteira ao mesmo tempo”? Inclusive, num fórum, nem sei como isso é possível. Mas, whatever…
Scala é o futuro? O tempo de transição será grande? Ruby foi uma moda que não pegou?
Vejam bem, nada das perguntas acima representa a minha opinião, só estou convidando nosso amigo a participar mais ativamente da discussão e o desmotivando a ficar apenas criticando.
Sou todo olhos e ouvidos. Nos ilumine, por favor.
Abraços.
Não exageremos… a nasa tinha/tem uma sonda controlada com java e o matlab usa java por baixo dos panos.
Existe muita coisas possivel com Java que não é possivel com outros, por exemplo o realtime (usado pela sonda).
Dê uma olhada na API JScience.
Java não tem ainda uma nicho em ciencias porque os cientistas (ironia do destino) são muito conservadores ( i.e. são uns atrazados que só usam a tecnologia que aprenderam na faculdade - no seculo passado).
Contudo, a tecnologia java não deixa nada a desejar. E se procurar pela internet existem até bibliotecas em java para calculo numérico (algunas usando bigdecimal, que é “impossivel” em fortran e afins).
Quanto ao hardware que corre java directamente é uma questão de tempo e custo. o Spot é apenas a ponta do iceberg.
Nenhum engenheiro vai usar java em eletrônica digital ou pesquisas científicas. Para cálculo, fortran ainda é mais indicado, e hardware, não serve nem mesmo c++. Tem que ser ansi c ou assembler.
Não exageremos… a nasa tinha/tem uma sonda controlada com java e o matlab usa java por baixo dos panos.
Existe muita coisas possivel com Java que não é possivel com outros, por exemplo o realtime (usado pela sonda).
Dê uma olhada na API JScience.Java não tem ainda uma nicho em ciencias porque os cientistas (ironia do destino) são muito conservadores ( i.e. são uns atrazados que só usam a tecnologia que aprenderam na faculdade - no seculo passado).
Contudo, a tecnologia java não deixa nada a desejar. E se procurar pela internet existem até bibliotecas em java para calculo numérico (algunas usando bigdecimal, que é “impossivel” em fortran e afins).Quanto ao hardware que corre java directamente é uma questão de tempo e custo. o Spot é apenas a ponta do iceberg.
Conheço essas apis, mas se tratando de fortran, java nem chega perto. A sintaxe dela foi feita pra isso.
Sobre eletrônica digital, já vi o software que controla o spirit(robo que está em marte), o maestro. Mas quis dizer sobre o software que faz o hardware funcionar, e esse é c, e não java.
O uso de java é somente para criar uma api fácil de se trabalhar. O grosso do hardware é c e assembly.
Humm… tem algum problema com os conceitos ai… hardware é eletricidade e electrónica. No máximo vc tem firmware que e´um tipo de hibrido de software que conhece o hardware… mas qualquer linguagem pode ser compilada para o codigo do processador. Algumas mais facilmente que outras.
dizer que o 'software que faz o hardware funcionar" é C não faz sentido, já que todo o software é bits e bytes que dão instruções ao CPU… essas instruções podem ser escritas em milhentas linguagens… (e até sem linguagem nenhuma : apenas via circuito electrico, mas é muiiiitooo mais dificil)
Não se esqueça que bytecode é um tipo de assembler para a Java Machine e o fato dela ser implementada virtualmente ( em cima de uma máquina real) é uma das possibilidades. A outra é implementar directamente sobre uma máquina que entenda bytecode nativamente. Isso não é impossivel.
Neste cenário o C e qq outra lingugem é dispensável e superflua. Não existe obrigação tecnica em passar pelo C.
Humm… tem algum problema com os conceitos ai… hardware é eletricidade e electrónica. No máximo vc tem firmware que e´um tipo de hibrido de software que conhece o hardware… mas qualquer linguagem pode ser compilada para o codigo do processador. Algumas mais facilmente que outras.
dizer que o 'software que faz o hardware funcionar" é C não faz sentido, já que todo o software é bits e bytes que dão instruções ao CPU… essas instruções podem ser escritas em milhentas linguagens… (e até sem linguagem nenhuma : apenas via circuito electrico, mas é muiiiitooo mais dificil)Não se esqueça que bytecode é um tipo de assembler para a Java Machine e o fato dela ser implementada virtualmente ( em cima de uma máquina real) é uma das possibilidades. A outra é implementar directamente sobre uma máquina que entenda bytecode nativamente. Isso não é impossivel.
Neste cenário o C e qq outra lingugem é dispensável e superflua. Não existe obrigação tecnica em passar pelo C.
É justamente o que eu quero te dizer. Não tem compilador java para microcontroladores. Existem compiladores de pascal, basic e c.
Como java gera bytecode, precisaria de uma JRM(Java real machine). A sun chegou a desenvolver um(PicoJava), em 2002 mas não emplacou, agora existe o sun spot, mas mesmo assim é caro e não vai emplacar.
A nasa usa java somente para aplicações de alto nível.
E essa de tipo hibrido de software que conhece hardware não existe. Um firmware é um software que roda em um dispositivo embarcado. Pode tanto rodar num micro família pic, um ARM, ou PowerPc, que é com o que eu trabalho.
Se esse fórum fosse ao vivo, eu imagino que estaria vendo pancadaria de tudo que é lado, cadeira voando, pedrada… :lol:
Não sei vocês perceberam mas estão tentado comparar um monte de coisas nada a ver, tipo querer comparar “qual é melhor: volei ou futebol? Afinal ambos são esportes e são jogados com uma bola”.
Fulano: “Eu gosto de futebol, porque prefiro jogar com o pé do que com a mão. Ambos tem pontos, só que no futebol eles são mais raros de acontecer e tem outro nome: GOL. A propósito: um gol é mais legal do que um ponto de volei”
Beltrano: “Ah, mas volei é melhor, as partidas sempre terminam com mais pontos…”
Piada, né? aheuheauheauh
Vou dar a minha opinião. Não vi NECESSIDADE (vejam bem, necessidade) de aprender algo fora de Java / C# / PHP. App pro tio da padaria? C#. Site pro tio da padaria? PHP. Projetinhos pessoais? Java. Ninguém disse que isso ta certo ou não, isso é questão de GOSTO. Mesmo papo do Windows VS Linux. Claro que, como eu classifiquei anteriormente, as linguagens (ou plataformas, whatever) tem afinidades com certos tipos de propósitos, mas nada impede de eu fazer um sistema operacional com Java (apesar de ter mais recursos com C), ou manipular ant com C (apesar de ser mais facil com Groovy).
Ainda assim vou estudar bem Groovy/Ruby/Scala por causa de alguns conceitos que não existem nessas linguagens que estou acostumado, até porque canja de galinha, cuidado e conhecimento não fazem mal a ninguém.
Desculpe se te ofendi. Não foi a minha intenção. A mensagem não foi um ataque a você, se é que percebeu.
Como eu disse, não vou participar da discussão.
[]s
Humm fiquei interessado nesta edição, deve responder alguns porques deste tópico.
*Dinamismo e Elegância na parceria Java & Ruby
*Aplicações Desktop a jato com JRuby e Netbeans
*Ruby + Web: Porque usar Java com JRuby on Rails: Entenda as vantagens de se usar Java para rodar código Ruby, inclusive aplicações JRuby on Rails.
Mundo Java nº 36
A linguagem Java continua fazendo o que sempre fez, so que é mais devagar pras er feito hj. Mas tudo bem, espero que a concorrência continue usando.
Humm fiquei interessado nesta edição, deve responder alguns porques deste tópico.*Dinamismo e Elegância na parceria Java & Ruby
*Aplicações Desktop a jato com JRuby e Netbeans
*Ruby + Web: Porque usar Java com JRuby on Rails: Entenda as vantagens de se usar Java para rodar código Ruby, inclusive aplicações JRuby on Rails.
Mundo Java nº 36
[color=red]JRuby + Web: Porque usar Java com JRuby on Rails?[/color][color=green] (assunto novo)[/color]
Entenda as vantagens de se usar Java para rodar código Ruby, inclusive aplicações JRuby on Rails.
Autor: Fabio Kung
[color=darkred]Aplicações Desktop a jato com JRuby e Netbeans[/color] [color=green](assunto novo)[/color]
Construindo aplicações Swing combinando as melhores técnicas e ferramentas de Java e Ruby.
Autor: Demetrius Nunes
[color=blue]Made in Brazil: Padronização e Reuso de Aplicações Web com Demoiselle Framework[/color] [color=green] (assunto novo)[/color]
Conheça essa plataforma de desenvolvimento
criada para aplicações do governo e para toda a sociedade.
Autor: Flávio Gomes da Silva Lisboa
Comentário:
Concerteza já estou adquirindo a minha revista Mundo Java dessa Edição Inovadora, parabens pela iniciativa e assuntos relacionados.
Se esse fórum fosse ao vivo, eu imagino que estaria vendo pancadaria de tudo que é lado, cadeira voando, pedrada… :lol:Não sei vocês perceberam mas estão tentado comparar um monte de coisas nada a ver, tipo querer comparar “qual é melhor: volei ou futebol? Afinal ambos são esportes e são jogados com uma bola”.
Fulano: “Eu gosto de futebol, porque prefiro jogar com o pé do que com a mão. Ambos tem pontos, só que no futebol eles são mais raros de acontecer e tem outro nome: GOL. A propósito: um gol é mais legal do que um ponto de volei”
Beltrano: “Ah, mas volei é melhor, as partidas sempre terminam com mais pontos…”
Piada, né? aheuheauheauh
Vou dar a minha opinião. Não vi NECESSIDADE (vejam bem, necessidade) de aprender algo fora de Java / C# / PHP. App pro tio da padaria? C#. Site pro tio da padaria? PHP. Projetinhos pessoais? Java. Ninguém disse que isso ta certo ou não, isso é questão de GOSTO. Mesmo papo do Windows VS Linux. Claro que, como eu classifiquei anteriormente, as linguagens (ou plataformas, whatever) tem afinidades com certos tipos de propósitos, mas nada impede de eu fazer um sistema operacional com Java (apesar de ter mais recursos com C), ou manipular ant com C (apesar de ser mais facil com Groovy).
Ainda assim vou estudar bem Groovy/Ruby/Scala por causa de alguns conceitos que não existem nessas linguagens que estou acostumado, até porque canja de galinha, cuidado e conhecimento não fazem mal a ninguém.
eu não penso desta forma… acho que esse tipo de discussão, quando não envolve apenas ignorantes, trolls e xiitas, tende a enriquecer com boas informações todos os que acompanham…
Estamos em uma nova realidade na plataforma Java, com boas linguagens dinâmicas e bons frameworks para as mesmas e para empresas que buscam ao maximo a produtividade com qualidade, não tem como deixar de lado a discussão.
Se fosse pensar desta forma, não seria ético que Robert Sebesta ficasse comparando linguagens item por item em seu livro “Conceitos de Linguagens de Programação”… só que a diferença é que o autor citado conhece os conceitos por detrás de todas e sabe avaliar seus respectivos recursos imparcialmente…
Existe alguma opção aqui no GUJ onde posso bloquear o usuário Marcio Duran?
Existe alguma opção aqui no GUJ onde posso bloquear o usuário Marcio Duran?
:roll:
Assim o guj perderia metade da graça :lol:
Sim, claro. Quando há bom senso, qualquer discussão é válida. Até mesmo sobre características de esportes diferentes (volei e futebol). O problema é que muitas opiniões emitidas aqui foram baseadas em gostos pessoais, sem se basear em nenhum argumento técnico. Isso é chato… e dá sono. Lembro de um amigo que depois que foi para os EUA e começou a trabalhar com RoR. Era engraçado ele dizer que Java era ruim e Ruby era bom. Tudo deles era melhor, até o café. Que raiva de xiitismo.
Sim, claro. Quando há bom senso, qualquer discussão é válida. Até mesmo sobre características de esportes diferentes (volei e futebol). O problema é que muitas opiniões emitidas aqui foram baseadas em gostos pessoais, sem se basear em nenhum argumento técnico. Isso é chato… e dá sono. Lembro de um amigo que depois que foi para os EUA e começou a trabalhar com RoR. Era engraçado ele dizer que Java era ruim e Ruby era bom. Tudo deles era melhor, até o café. Que raiva de xiitismo.
concordo…
Eu concordo com você. Poderia ser uma discução sadia. O problema é que, não sei porque, se alguém falar que java não serve para algum tipo de coisa, as pessoas tendem a levar para o lado pessoal, em vez de tentar assimilar uma nova experiência.
Estamos num forum de java, mas realmente algumas pessoas só conhecem java, e não trabalharam em projetos que exigem outra visão.
Você esteve no Falando em Java?Lá o Kung fez um sistema para gerar números aleatórios usando uma linha (duas porque não coube na tela), mas com 150 comandos nesta linha.
Quando alguém da platéia gritou pedindo para fazer em Java, pois a bagaça não funcionava, ele falou algo assim: Nem morto, em Java eu precisaria de dezenas de linhas.
Eu olhava aquelas duas linhas (uma na verdade) e ficava imaginando: e para debugar uma app com, sei lá, 300 linhas dessas. Vai levar uma eternidade. Prefiro escrever mais linhas, e deixar o código legível, que escrever tudo em uma e ficar meia hora só para entender o que essa linha faz. Esse é o ponto central do meu questionamento.
Desculpem ter chegado atrasado na discussão, mas (ainda em tempo)…
O que eu fiz lá no Falando em Java, foi uma solução rápida para resolver o problema do sorteio. De forma alguma eu acho que o poder e vantagem de Ruby está em permitir fazer esse tipo de coisa. Eu sou um dos que mais critico os “Perl one-liners” que resolvem problemas imensos mas são totalmente ilegiveis.
Eu gosto muito de Ruby (e não acho que seja bala de prata, tem sim os seus problemas), justamente pela expressividade, já muito bem comentada por aqui pelo Dalto (dlt). E expressividade não é fazer o programa em uma linha, na minha opinião tem muito mais a ver com dimiuir o ruído, na hora de resolver o problema. Ruby é uma linguagem MUITO adequada para construção de DSLs internas e para deixar o código próximo do problema que ele resolve.
Outro ponto importante é a diversão. Como o Kenobi já comentou, é uma delícia programar em Ruby. É claro que isso é opinião pessoal, mas que com certeza deve ser levada em conta na hora de escolher uma tecnologia para uma equipe.
ps.: aquela “1-linha” de código que eu fiz em Ruby é legível sim, para quem tem um pouco de fluencia na linguagem. Mas ser legivel para todos não era mesmo o objetivo daquele código. Era só uma solução rápida e simples que eu pude fazer para o problema.
Outro ponto importante é a diversão. Como o Kenobi já comentou, é uma delícia programar em Ruby. É claro que isso é opinião pessoal, mas que com certeza deve ser levada em conta na hora de escolher uma tecnologia para uma equipe.
É por causa de comentários assim que eu não levo Ruby a sério.
Então tu quer dizer que Java deve ser levado a sério porque tu programa fazendo careta?
Não leve. Faz bem.
O problema é que os proponentes de Ruby não sabem explicar o porque ele é “melhor” em suas opiniões. Por isso citam “felicidade” e outros conceitos subjetivos.
Qualquer entusiasta de qualquer tecnologia se sentirá bem usando-a. Isso não quer dizer nada.
Realmente nesse ponto eu tenho que concordar… se não houver argumento técnico, a discussão fica parecendo de criancinhas falando: “o meu é melhor porque é mais legal que o seu…”
Voltando ao assunto: Scala, pelo que vi é uma linguagem que suporta o paradigma funcional. Alguém poderia me dar uma breve explicação sobre o paradigma e alguns exemplos de cenários que esse paradigma é o mais indicado (fora cálculos matemáticos)?
E dizer que Java é melhor que Ruby não adianta
O problema é que os proponentes de Ruby não sabem explicar o porque ele é “melhor” em suas opiniões. Por isso citam “felicidade” e outros conceitos subjetivos.
Qualquer entusiasta de qualquer tecnologia se sentirá bem usando-a. Isso não quer dizer nada.
produtividade não é subjetivo! o prazer de programar e a legibilidade do código se traduz em lucro para a empresa.
Pensei que não chegaria nunca. Antes tarde que nunca. =)
Agora você despertou meu interesse. Entendi o “muito” grifado (creio que tenha sido para não confundir com mais adequada).
Já li, muito superficialmente, textos sobre DSLs e me convenci do seu poder. Você poderia indicar algum texto (ou você mesmo dar uma breve explicação) de como o Ruby é muito adequada para criação de DSLs?
Desde quando li o texto do James, o Scala me chamou a atenção. Tenho lido alguns textos introdutórios sobre a linguagem, e ainda não li nada sobre DSLs. Se a criação de DSLs em Ruby for realmente simples, isso é claramente uma grande vantagem.
ps.: aquela “1-linha” de código que eu fiz em Ruby é legível sim, para quem tem um pouco de fluencia na linguagem. Mas ser legivel para todos não era mesmo o objetivo daquele código. Era só uma solução rápida e simples que eu pude fazer para o problema.
O meu comentário com relação aquela linha é porque a achei “superpopulada” com comandos. Não lembro quantos eram exatamente, mas creio que era algo em torno de 5. Mesmo para um desenvolvedor Ruby experiente, é lógico - pelo menos para mim -, que haverá uma dificuldade maior de entendimento em uma linha com 5 comandos que em uma linha com apenas um. Essa dificuldade demanda mais tempo. Em uma aplicação pequena (como foi o caso do Falando em Java) isso seria desprezível. Mas em uma aplicação com milhares de linhas, na minha visão, essa perda seria considerável. Foi neste sentido que lenvantei este ponto.
Não leve. Faz bem.
+1.
Eu acho melhor usar uma linguagem que me ajude a resolver um problema do que usar uma que eu tenha que resolver os problemas dela para funcionar o_O
T+
Não leve. Faz bem.
+1.
Eu acho melhor usar uma linguagem que me ajude a resolver um problema do que usar uma que eu tenha que resolver os problemas dela para funcionar o_O
T+
Apesar de concordar com o que disse, eu ainda prefiro uma linguagem que seja mantida por cientistas do que por rockstars.
Apesar de concordar com o que disse, eu ainda prefiro uma linguagem que seja mantida por cientistas do que por rockstars.
Ou seja, Scala e (principalmente na JVM) Java. Mas não acho que o Matz (o pai do Ruby) seja exatamente um rockstar; nem para Hiro (do seriado Heroes) ele está.
Uma vez quando vi uma palestra do Fábio Akita, e ele mostrou como escrever XML em Ruby, eu também fiquei encantado, e começei a estudar Ruby.
Mas nem por isso ruby é a solução para tudo.
De duas uma, ou o celso ta fazendo propaganda dos posts do blog dele, ou ele também ficou encantado e resolver abrir para discução.
Cobol ainda está por ai, e prova que nem tudo é substituido pelas novas linguagens
De acordo.
O interessante é que, se não me falha a memória Java foi criada em 1991 e Ruby em 1993; ou seja + ou - quatro anos de diferença. Em uma comparação entre Java e Ruby não dá para dizer que Ruby é tão jovem assim. Na minha opinião a diferença se deve ao momento e o propósito para o qual as linguagens foram criadas, além do investimento é claro. Dá para imaginar o quanto de $ e conhecimento foram injetados (direta e indiretamente) na plataforma Java? Sem falar nas empresas gigantes que deram de ainda dão apoio.
flws
Falando em empresas mantendo linguagens, muita coisa que se vê por aí é linguagem nem tão boa assim que é mantida viva por interesses comerciais. Não que não seja um bom motivo, problema é fanboy solta fogos de artifício pela linguagem, e está comendo na mão delas. A maioria dessas é também por motivos comerciais, para tentar manter emprego, ou preguiça/medo de sair da zona de conforto. Não que tentar manter o emprego também não seja um bom motivo para manter a coisa ruim 8)
Ééé, cada um na sua…
PS: linguagem aqui é uma variável que pode receber também tecnologias, produtos, enterprise service bus…
Desculpem ter chegado atrasado na discussão, mas (ainda em tempo)…
Pensei que não chegaria nunca. Antes tarde que nunca. =)
Agora você despertou meu interesse. Entendi o “muito” grifado (creio que tenha sido para não confundir com mais adequada).
Já li, muito superficialmente, textos sobre DSLs e me convenci do seu poder. Você poderia indicar algum texto (ou você mesmo dar uma breve explicação) de como o Ruby é muito adequada para criação de DSLs?Desde quando li o texto do James, o Scala me chamou a atenção. Tenho lido alguns textos introdutórios sobre a linguagem, e ainda não li nada sobre DSLs. Se a criação de DSLs em Ruby for realmente simples, isso é claramente uma grande vantagem.
ps.: aquela “1-linha” de código que eu fiz em Ruby é legível sim, para quem tem um pouco de fluencia na linguagem. Mas ser legivel para todos não era mesmo o objetivo daquele código. Era só uma solução rápida e simples que eu pude fazer para o problema.O meu comentário com relação aquela linha é porque a achei “superpopulada” com comandos. Não lembro quantos eram exatamente, mas creio que era algo em torno de 5. Mesmo para um desenvolvedor Ruby experiente, é lógico - pelo menos para mim -, que haverá uma dificuldade maior de entendimento em uma linha com 5 comandos que em uma linha com apenas um. Essa dificuldade demanda mais tempo. Em uma aplicação pequena (como foi o caso do Falando em Java) isso seria desprezível. Mas em uma aplicação com milhares de linhas, na minha visão, essa perda seria considerável. Foi neste sentido que lenvantei este ponto.
o post acima é a mais pura verdade. Existe um marketing enorme nisso. Vendem a imagem que se vc programa em tal linguagem, você é um ótimo profissional. E isso não é verdade. Como sabemos o codificador é medido pelo domínio de algoritmos, e não de linguagem.
Se for para citar, existem duas linguagens, que podemos dizer mais novas que java, ou c#(Novas, dizendo-se, por reunir novos atributos que nenhuma até agora implementou)
D e Objective C
O compilador D implementa coleta de lixo automático no próprio programa gerado, e o resultado é instrução nativa do processador. D também é completamente orientada a objetos.
Objective C, Poder de um compilador c e linguagem totalmente OO.
Linguagens são meramente questão de pesquisa. Tem de sobra pra escolher.
Apesar de concordar com o que disse, eu ainda prefiro uma linguagem que seja mantida por cientistas do que por rockstars.Ou seja, Scala e (principalmente na JVM) Java. Mas não acho que o Matz (o pai do Ruby) seja exatamente um rockstar; nem para Hiro (do seriado Heroes) ele está.
Nao posso falar de individuais, mas de comunidade e atitudes sim.
Rockstars, ninjas, etc. são os desenvolvedores do Rails. A atitude do pessoal que mantem o Ruby é bem diferente pelo que eu ouvi falar
Embora dificilmente programas “reais” sejam feitos em uma linha, linguagens como Ruby fornecem essa alternativa quando vc quer fazer algo rápido sem abrir mão da qualidade. Quando vc se acostuma com os métodos da classe Array, Hash, String, etc do Ruby vc faz coisas fantásticas de forma “one-liner” e pode, se quiser, introduzir mais linhas se precisar de mais expressividade.
Entretanto um programa real necessita de mais do que um monte de linhas de código para realizar as suas tarefas. Se vc opta por ter uma suite de testes automatizados para verificar o seu programa (coisa natural se vc trabalha com BDD ou TDD) é provavel que vc chegue ao equilíbrio do numero de linhas da linguagem que vc escolheu.
Pra mim esses são os programadores python
de ruby/rails não ví nada demais, geralmente é galera que veio do java
Pra mim esses são os programadores python
de ruby/rails não ví nada demais, geralmente é galera que veio do java
Programadores de Ruby são geralmente fanáticos e precisam “converter” os infiéis. O maior problema é que a linguagem Ruby em si é desnecessariamente verbosa (assim como todas as outras que não usam S expressions), não possui certas features essenciais, não promove vários paradigmas e foca mais em OO.
Se é para usar algo horrível, que seja Java pois pelo menos há uma imensa variedade de bibliotecas e ferramentas. Se é para usar algo bom, use Common Lisp. Para que se preocupar com uma cópia capada de Scheme com uma sintaxe “bonita” de Perl?
Se um lixo desse fosse o futuro eu mudaria de profissão.
Pra mim esses são os programadores python
de ruby/rails não ví nada demais, geralmente é galera que veio do java
Programadores de Ruby são geralmente fanáticos e precisam “converter” os infiéis. O maior problema é que a linguagem Ruby em si é desnecessariamente verbosa (assim como todas as outras que não usam S expressions), não possui certas features essenciais, não promove vários paradigmas e foca mais em OO.
Cite-as por favor
Pra mim esses são os programadores python
de ruby/rails não ví nada demais, geralmente é galera que veio do java
Programadores de Ruby são geralmente fanáticos e precisam “converter” os infiéis. O maior problema é que a linguagem Ruby em si é desnecessariamente verbosa (assim como todas as outras que não usam S expressions), não possui certas features essenciais, não promove vários paradigmas e foca mais em OO.
Cite-as por favor ;-)
Macros é uma. Um condition system decente é outra. Uma implementação OO decente é uma terceira.
Não estou falando que promove bem, mas o marketing é um importante componente do estilo Rockstar e a linguagem Ruby é vendida como sendo multi-paradigma, até mesmo como sendo um tipo de lisp. Na verdade esta foi minha principal frustação com Ruby. A linguagem é até divertida mas como não trazia nada de novo à mesa à época (eu já sabia Python) e pelo fato de ter me sentido enganado me fez pegar uma certa rejeição a tudo ligado a Ruby.
Pra mim esses são os programadores python
de ruby/rails não ví nada demais, geralmente é galera que veio do java
Programadores de Ruby são geralmente fanáticos e precisam “converter” os infiéis. O maior problema é que a linguagem Ruby em si é desnecessariamente verbosa (assim como todas as outras que não usam S expressions), não possui certas features essenciais, não promove vários paradigmas e foca mais em OO.
Cite-as por favor ;-)
Macros é uma. Um condition system decente é outra. Uma implementação OO decente é uma terceira.
Risos.
Aonde ruby é verbosa?
x = 2**100 versus
BigInteger x = new BigInteger("2").pow(100);
expired_timestamp = 24.hours versus
Long expiredTimestamp = 24 * 3600 * 1000;
Isso sem lembrar que as linhas de ruby são validas. Os pedaços em java voce tem que incluir isso dentro de um escopo de classe, obrigatoriamente.
Só lembrando que eu trabalho com java, e como a realidade pra mim não inclui liberdade de escolhas, prefiro me abster de criticar o que eu não uso ou não sei usar
Risos =)
T+
Verbosas em comparação a linguagens assim como Lisp, que possuem uma sintaxe melhor e features essenciais que não estão presentes em Ruby. Ruby é tosco demais.
Em Lisp for exemplo, os inteiros tem tamanho ilimitado e se dividem entre fixnum (tamanho do word da máquina) e bignum (limitado apenas pelo tamanho da memória). Todas as operações são transparentes para o desenvolvedor, a implementação usará o que for necessário para representar o número que você deseja automaticamente.
Do ponto de vista do desenvolvedor em Lisp não há diferença entre fixnum e bignum e você não precisará se preocupar com essa distinção.
Risos.Aonde ruby é verbosa?
x = 2**100 versus BigInteger x = new BigInteger("2").pow(100); expired_timestamp = 24.hours versus Long expiredTimestamp = 24 * 3600 * 1000;Isso sem lembrar que as linhas de ruby são validas. Os pedaços em java voce tem que incluir isso dentro de um escopo de classe, obrigatoriamente.
Só lembrando que eu trabalho com java, e como a realidade pra mim não inclui liberdade de escolhas, prefiro me abster de criticar o que eu não uso ou não sei usar
Risos =)
Verbosas em comparação a linguagens assim como Lisp, que possuem uma sintaxe melhor e features essenciais que não estão presentes em Ruby. Ruby é tosco demais.
Em Lisp for exemplo, os inteiros tem tamanho ilimitado e se dividem entre fixnum (tamanho do word da máquina) e bignum (limitado apenas pelo tamanho da memória). Todas as operações são transparentes para o desenvolvedor, a implementação usará o que for necessário para representar o número que você deseja automaticamente.
Do ponto de vista do desenvolvedor em Lisp não há diferença entre fixnum e bignum e você não precisará se preocupar com essa distinção.
E em ruby?