Aliás, há um monte de coisas que odeio aqui no GUJ. Por exemplo, muitas vezes se pergunta algo como:
a) Qual é a melhor coisa para fazer X?
(A pessoa que está pedindo isso às vezes não aceita uma série de sugestões, quer saber apenas qual é a MELHOR. E ainda reclama se você só faz um comentário mas não diz logo de cara qual é a MELHOR, dizendo que a gente não foi convidado nessa discussão.)
b) É possível fazer Y?
(Eu gostaria de responder apenas “SIM” ou “NÃO”, à maneira lógica e portuguesa de responder, mas eu sei que a pessoa quer, na verdade, dizer “Mê dê um programa prontinho que faça Y”).
Ou então se entra numa discussão religiosa sobre “Por que é que X é muito melhor que Y” ou “Por que é que a companhia Z vai destruir o mundo”.
Outra coisa é que o pessoal aqui normalmente não consegue levar nada na esportiva, dá a impressão que todo mundo pode fazer bullying mas se você retrucar, se sentem ofendidos.
[quote=entanglement]Aliás, há um monte de coisas que odeio aqui no GUJ. Por exemplo, muitas vezes se pergunta algo como:
a) Qual é a melhor coisa para fazer X?
(A pessoa que está pedindo isso às vezes não aceita uma série de sugestões, quer saber apenas qual é a MELHOR. E ainda reclama se você só faz um comentário mas não diz logo de cara qual é a MELHOR, dizendo que a gente não foi convidado nessa discussão.)
b) É possível fazer Y?
(Eu gostaria de responder apenas “SIM” ou “NÃO”, à maneira lógica e portuguesa de responder, mas eu sei que a pessoa quer, na verdade, dizer “Mê dê um programa prontinho que faça Y”).
Ou então se entra numa discussão religiosa sobre “Por que é que X é muito melhor que Y” ou “Por que é que a companhia Z vai destruir o mundo”.
Outra coisa é que o pessoal aqui normalmente não consegue levar nada na esportiva, dá a impressão que todo mundo pode fazer bullying mas se você retrucar, se sentem ofendidos. [/quote]
Interessante: ao contrário do seu post anterior, o que este tem a ver com a discussão? Alguém agiu com você assim aqui?
[quote=rmendes08][quote=johnny quest]Não, pois o paradigma imperativo resolve alguns problemas mais elegantemente e com melhor performance do que a forma funcional em alguns casos.
O ideal seria ter uma linguagem hibrida, com os dois paradigmas juntos, igual ao C++ e Scala.
Dessa forma, a partir do problema sendo resolvido, se poderia utilizar o melhor paradigma para resolver o problema.
[/quote]
Ora, para que ter 2 paradigmas em uma linguagem se sobre a mesma plataforma podemos ter 2 linguagens interoperáveis, cada uma no seu quadrado ?[/quote]
Pelo visto tem gente que gosta de atrocidades igual C++ e Scala.
Não, pois o paradigma imperativo resolve alguns problemas mais elegantemente e com melhor performance do que a forma funcional em alguns casos.
O ideal seria ter uma linguagem hibrida, com os dois paradigmas juntos, igual ao C++ e Scala.
Dessa forma, a partir do problema sendo resolvido, se poderia utilizar o melhor paradigma para resolver o problema.
[/quote]
Ora, para que ter 2 paradigmas em uma linguagem se sobre a mesma plataforma podemos ter 2 linguagens interoperáveis, cada uma no seu quadrado ?[/quote]
Eu também sou da opinião da linguagem possuir alguns recursos funcionais mas não toda funcional, apesar de não ter nada contra uma usar completamente este paradigma. O fato é que o compilador de linguagem funcional não é tão eficiente como o das imperativas.
Existe um bom artigo sobre isso.
Assim sendo são ferramentas para diferentes propósitos.
[quote=entanglement]Aliás, há um monte de coisas que odeio aqui no GUJ. Por exemplo, muitas vezes se pergunta algo como:
a) Qual é a melhor coisa para fazer X?
(A pessoa que está pedindo isso às vezes não aceita uma série de sugestões, quer saber apenas qual é a MELHOR. E ainda reclama se você só faz um comentário mas não diz logo de cara qual é a MELHOR, dizendo que a gente não foi convidado nessa discussão.)
b) É possível fazer Y?
(Eu gostaria de responder apenas “SIM” ou “NÃO”, à maneira lógica e portuguesa de responder, mas eu sei que a pessoa quer, na verdade, dizer “Mê dê um programa prontinho que faça Y”).
Ou então se entra numa discussão religiosa sobre “Por que é que X é muito melhor que Y” ou “Por que é que a companhia Z vai destruir o mundo”.
Outra coisa é que o pessoal aqui normalmente não consegue levar nada na esportiva, dá a impressão que todo mundo pode fazer bullying mas se você retrucar, se sentem ofendidos. [/quote]
Bacana, valeu pelo link. Outra alternativa para usar lambdas hoje é Groovy, que possui uma sintaxe muito próxima do Java e já oferece este recurso desde a primeira versão.
Bacana, valeu pelo link. Outra alternativa para usar lambdas hoje é Groovy, que possui uma sintaxe muito próxima do Java e já oferece este recurso desde a primeira versão.[/quote]
O fato de possuir closures não torna Java uma linguagem funcional. É apenas um atalho para fazer coisas que ficam verbosas apenas com orientação a objetos. Um exemplo são os listeners de eventos. Dificilmente o “cacuete” da programaçao em linguagem Java mudará.
Por outro lado, se alguém precisa/gosta de escrever código no paradigma funcional e quer ver esse código rodando numa JVM, bem, essa pessoa tem toda a liberdade de implementar a própria linguagem (isso se nenhuma das linguagens existentes servir). É bem melhor do que brigar no JCP por mudanças em uma linguagem que já tem milhões de linhas de código escritas pelo mundo.
A título de curiosidade, existe um projeto bem antigo da Apache chamado Commons Functor, cujo objetivo era trazer (mesmo que de uma forma bem precária) as closures para o Java.
Basicamente você encapsulava uma função em um objeto e ia o passando como referência.
O paradigma funcional é legal e tal, simplifica muito o código comparado ao imperativo, mas uma das suas deficiências é a imutabilidade.
Vou citar meu exemplo: Ao reescrever minha chess engine para Scala, queria somente usar a parte funcional, que é a melhor parte, mas quando comecei a parte da criação da árvore de jogo, tive que parar com a imutabilidade, pois estavam sendo criados muitos objetos em memória para cada tabuleiro criado, e isso começou a pesar no processamento/memória. Por isso, nessa região do código, voltei a utilizar variáveis mutáveis.
Se estivesse utilizando uma linguagem funcional pura, já teria dor de cabeça em como resolver esse problema da imutabilidade na linguagem, pois não teria a possibilidade de escolher variáveis mutáveis.
[quote=johnny quest]O paradigma funcional é legal e tal, simplifica muito o código comparado ao imperativo, mas uma das suas deficiências é a imutabilidade.
Vou citar meu exemplo: Ao reescrever minha chess engine para Scala, queria somente usar a parte funcional, que é a melhor parte, mas quando comecei a parte da criação da árvore de jogo, tive que parar com a imutabilidade, pois estavam sendo criados muitos objetos em memória para cada tabuleiro criado, e isso começou a pesar no processamento/memória. Por isso, nessa região do código, voltei a utilizar variáveis mutáveis.
Se estivesse utilizando uma linguagem funcional pura, já teria dor de cabeça em como resolver esse problema da imutabilidade na linguagem, pois não teria a possibilidade de escolher variáveis mutáveis.[/quote]
Mas ai que tá: imutabilidade é a grande vantagem do negócio. Em aplicações de alta concorrência, por exemplo, elimina a necessidade da maior parte dos locks. O maior problema na minha opinião é a nossa adaptação a ele, ter de pensar em um mundo imutável em termos de programação é muito difícil.
Por outro lado, você tem com a questão da imutabilidade posssibilidades interessantes, como por exemplo a noção de “estados” em um objeto. Em Clojure, por exemplo, você pode voltar seu objeto para um estado anterior (como em uma transação de banco de dados) de forma muito simples.
[quote=johnny quest]O paradigma funcional é legal e tal, simplifica muito o código comparado ao imperativo, mas uma das suas deficiências é a imutabilidade.
Vou citar meu exemplo: Ao reescrever minha chess engine para Scala, queria somente usar a parte funcional, que é a melhor parte, mas quando comecei a parte da criação da árvore de jogo, tive que parar com a imutabilidade, pois estavam sendo criados muitos objetos em memória para cada tabuleiro criado, e isso começou a pesar no processamento/memória. Por isso, nessa região do código, voltei a utilizar variáveis mutáveis.
Se estivesse utilizando uma linguagem funcional pura, já teria dor de cabeça em como resolver esse problema da imutabilidade na linguagem, pois não teria a possibilidade de escolher variáveis mutáveis.[/quote]
Me parece um daqueles casos de escolha da ferramenta errada para o problema.
Eu não usaria uma linguagem funcional num jogo, ou para criação de GUIs, a não ser se estivesse buscando problemas.
Como disse o kicolobo, backend e aplicações de alta concorriencia é onde o paradigma funcional se destaca.
[quote=Jonas backer]
E agora você esta vendo em Java.[/quote]
Duran, acho que vc esta tendo visões, Java 8 ainda nem foi lançado.
E com o Java caindo no TIOBE que nem chuva, ficaria surpreso se alguém acabar vendo Java 8 num projeto real algum dia.
Entendo que esteja empolgado pra usar sua lambda (diga-se de passagem, coisa que qualquer linguagem fajuta por ai já tem ha anos), mas não esqueça que 95% das empresas ainda usam Java 6, e sem nenhum perspectiva de mudança. Principalmente depois da Oracle, e o medo da JVM começar a ser cobrada?
[quote]Mas ai que tá: imutabilidade é a grande vantagem do negócio. Em aplicações de alta concorrência, por exemplo, elimina a necessidade da maior parte dos locks. O maior problema na minha opinião é a nossa adaptação a ele, ter de pensar em um mundo imutável em termos de programação é muito difícil.
Por outro lado, você tem com a questão da imutabilidade posssibilidades interessantes, como por exemplo a noção de “estados” em um objeto. Em Clojure, por exemplo, você pode voltar seu objeto para um estado anterior (como em uma transação de banco de dados) de forma muito simples.[/quote]
Concordo plenamente. Para propósitos de concorrência nada se compara à facilidade de desenvolvimento que a imutabilidade pode trazer,
mas para falar a verdade ainda não consegui pensar\criar um software concorrente de criação exponencial de objetos(Tabuleiros) que tenha o mesmo desempenho de um único processador executando. Por essa razão estou utilizando dados mutáveis, mas se descobrisse uma forma de utilizar a imutabilidade sem perder desempenho(nesse caso específico) utilizaria sem pensar 2x.
Paradigma, pode até ser, mas não vamos esquecer que no Java 8 ainda não existe o conceito de função como uma “first-class”. O lambda ainda é um açúcar sintático para classes anônimas.
