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.
[quote=Luca]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?
[/quote]
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á
[quote=celso.martins]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.[/quote]
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
[quote=Luca]
Luca (acho que fui meio confuso…)[/quote]
Eu não achei. Acho que entendi bem o que você quis passar.
[quote=Luca]
Faltou dizer… parabéns pelo tópico. Gostei de discutir este assunto.
Luca[/quote]
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.
[quote=victorcosta]
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)[/quote]
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"
endRepare 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.
[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=Leonardo3001]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.
[/quote]
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.
[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.
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
[quote=Luca]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? [/quote]
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.
[quote=celso.martins][quote=Leonardo3001]
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.
[/quote]
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.[/quote]
Lógica de algoritmo seria assim:
- Abre o arquivo, informando o modo de operação, obtém-se o descritor de arquivo;
- Com o descritor de arquivo, escreve-se (ou lê-se) a mensagem (possíveis erros são lançados);
- Fecha o descritor de arquivo.
Logica de negócio seria assim:
- Escreva no arquivo “FATURA.DAT”, a contabilidade do mês.
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.
[quote=celso.martins][quote=Luca]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?
[/quote]
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.
[/quote]
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.