[quote=Leonardo3001][quote=Juk][quote=Leonardo3001]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.
[/quote]
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.[/quote]
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.
[/quote]
Ninguém comparou Spring com Ruby, não tem nada a ver uma coisa com a outra. Você perguntou “se alguma vez você conseguiu separar a lógica de manipulação da Connection da lógica de consulta ao banco” e isso o Spring faz e muito bem, além de tratar erros.
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.
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.
[quote=sergiotaborda]
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.[/quote]
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.
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.
[quote=mochuara][quote=juliocbq]
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).
[/quote]
Ok, esta desculpado… [/quote]
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:
[quote=sergiotaborda][quote=Leonardo3001]
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?
[/quote]
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.
[/quote]
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.
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.
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.
Um antigo patrão (dono da empresa) gostava de medir a produtividade dessa forma. É claro que não concordo.
[quote=sergiotaborda]
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.[/quote]
O 150 é fictício. Quando escrevi, sabia que deveria ter colocado um número maior. =)
[quote=sergiotaborda] … não é arquitetura web que é complicada. É a sua arquitetura que é complicada. [/quote]
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.
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…
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.[/quote]
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 é arquitetura web que é complicada. É a sua arquitetura que é complicada.