“Object-oriented programming makes code understandable by encapsulating moving parts. Functional programming makes code understandable by minimizing moving parts”
“Michael Feathers, author of Working with Legacy Code”
Faria sentido se Java se tornasse uma linguagem de paradigma funcional?
J
40 Respostas
J
Não faz sentido embora elas assumam algumas características das linguagens funcionais. Por exemplo c++, c# e java todas terão funções lambda.
Essa questão de paradigma é relativa devido ao tipo de problema que você pretende resolver.
Não pense que irá programar seus device drivers usando uma linguagem funcional. Para isso é melhor que a linguagem seja estrurturada.
K
No cerne da linguagem está o paradigma (ou paradigmas) que ela adota.
Sendo assim, esta pergunta é sem sentido: se Java da noite pro dia adotasse o paradigma funcional como o seu principal ao invés da orientação a objetos (que é o seu foco), não teríamos um novo Java, mas sim uma nova linguagem completamente diferente.
Uma pergunta mais interessante é: quão árduo é a mudança de nossa mentalidade do paradigma estruturado/orientado a objetos para o funcional? Indo um pouco além, quão difícil é a nossa adequação de pensamento do modo imperativo para o declarativo?
Dado que o maior inimigo do desenvolvedor é o determinismo linguístico (tenho alguns textos publicados sobre o problema aqui http://www.itexto.net/devkico/?page_id=766), depende do caso: se o indivíduo passou anos trabalhando apenas com o paradigma estruturado/orientado a objetos, a curva de aprendizado é muito mais íngreme. A solução para o problema é sempre ficar com as orelhas em pé experimentando tudo (ou ao menos lendo o mínimo a respeito) o que sai, seja paradigma funcional, lógico (que ainda vai pegar), whatever pra evitar cair nesta cilada.
R
nobres GUJistas … é o Duran …
K
Eu sei! 
Mas não é por causa disto que, se ele vier com uma discussão interessante a gente não possa tirar proveito uai 
Ou então, melhor ainda, tentar transformar o que está ruim em algo um pouquinho melhor como este caso. A melhor maneira de acabar com este tipo de problema não é ficar banindo o cara sempre, mesmo porquê ele sempre pode criar uma conta com novo nome como esta, mas sim tentar transformar carvão em diamante. Se no caminho não funcionar, bem: a gente tenta de novo e por ai vai.
J
sim, mas não custa nada responder.
R
Eu sei!
Mas não é por causa disto que, se ele vier com uma discussão interessante a gente não possa tirar proveito uai
Ou então, melhor ainda, tentar transformar o que está ruim em algo um pouquinho melhor como este caso. A melhor maneira de acabar com este tipo de problema não é ficar banindo o cara sempre, mesmo porquê ele sempre pode criar uma conta com novo nome como esta, mas sim tentar transformar carvão em diamante. Se no caminho não funcionar, bem: a gente tenta de novo e por ai vai.
Pelo jeito eu é que sou discrente com as pessoas mesmo …
Mas enfim, o paradigma funcional é interessante ? Sem dúvida alguma.
Vale a pena tornar Java uma linguagem funcional ? Duvido muito. É mais fácil criar uma linguagem nova que execute na JVM. Enfim, seria algo muito parecido com o que já existe, como a Clojure:
J
“Acredito que soluções são gerenciáveis, a tecnologia é o emprego da situação”
R
Essa aí nem o Pasquale entende hein…
uma vírgula aí ajudaria a separar as idéias, mas ainda não faria muito sentido.
E
Ele deve ter pegado este site
e passado pelo Google Translator. Um exemplo:
If we reallocate our assets to capitalize on the activities of competitors, we can achieve synergy in all business units and benefit from economies of scope
->
Se realocar nossos ativos para capitalizar sobre as atividades dos concorrentes, podemos criar uma sinergia em todas as unidades de negócio e beneficiar de economias de escopo
J
Ele deve ter pegado este sitee passado pelo Google Translator. Um exemplo:
If we reallocate our assets to capitalize on the activities of competitors, we can achieve synergy in all business units and benefit from economies of scope
->
Se realocar nossos ativos para capitalizar sobre as atividades dos concorrentes, podemos criar uma sinergia em todas as unidades de negócio e beneficiar de economias de escopo
Não foi uma observação que um consultor escreveu no site da IBM DeveloperWorks , aliás vou colocar aqui pra elucidar o assunto:
http://www.ibm.com/developerworks/br/java/library/j-ft5/
E
Entschuldigen sie - mas o Neal Ford não escreveu isso (“Acredito que soluções são gerenciáveis a tecnologia é o emprego da situação”) explicitamente - ele simplesmente comparou o modo de pensar “funcional” e “estruturado”.
R
Não foi uma observação que um consultor escreveu no site da IBM DeveloperWorks , aliás vou colocar aqui pra elucidar o assunto…
Não to querendo ser chato, mas novamente a ausência da vírgula acabou mudando o sentido da frase.
J
Entschuldigen sie - mas o Neal Ford não escreveu isso (“Acredito que soluções são gerenciáveis a tecnologia é o emprego da situação”) explicitamente
Isso mesmo, e nessa visão procurei explorar o Tema , o que coloca em cheque quando temos tomar decisões ao desenvolvimento.
L
Boa tarde pessoal.
Não querendo fugir do foco, mas quem é esse tal Duran?
O que ele fez ou faz de errado?
J
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.
R
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.
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 ?
M
Boa tarde pessoal.
Não querendo fugir do foco, mas quem é esse tal Duran?
O que ele fez ou faz de errado?
era um individuo que ja a alguns anos atras (eu participo desse forum a uns 4, 5 anos e desde então ja via seus posts) postava perolas de deixar o enem com inveja…
Boa tarde pessoal.
Não querendo fugir do foco, mas quem é esse tal Duran?
O que ele fez ou faz de errado?
era um individuo que ja a alguns anos atras (eu participo desse forum
E
Enquanto há gente aqui em discussões bizantinas (se o Java deve ou não adotar também o paradigma funcional), o pessoal do .NET já tem algumas linguagens funcionais que rodam sob .NET (como o F#) e desde o .NET 3.5 você pode usar estilo funcional no C# ( http://www.c-sharpcorner.com/uploadfile/rmcochran/introduction-to-functional-programming-in-C-Sharp/ ) .
Que tal olhar para o outro lado da cerca, hein?
A grama do vizinho pode ser mais verde, e é bom saber por quê.
K
Enquanto há gente aqui em discussões bizantinas (se o Java deve ou não adotar também o paradigma funcional), o pessoal do .NET já tem algumas linguagens funcionais que rodam sob .NET (como o F#) e desde o .NET 3.5 você pode usar estilo funcional no C# ( http://www.c-sharpcorner.com/uploadfile/rmcochran/introduction-to-functional-programming-in-C-Sharp/ ) .
Que tal olhar para o outro lado da cerca, hein?
A grama do vizinho pode ser mais verde, e é bom saber por quê.
Boa!
Mas do lado Java da cerca também: Clojure, Scala e algumas outras.
E
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.
K
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.
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?
B
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.
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 ?
Pelo visto tem gente que gosta de atrocidades igual C++ e Scala.
J
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.
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 ?
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.
J
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.
Bom, Java 8 é bem o paradigma funcional
K
Só por ter closures será que podemos dizer isto? Na realidade eu vejo mais como uma mistureba mesmo, não?
J
Só por ter closures será que podemos dizer isto? Na realidade eu vejo mais como uma mistureba mesmo, não?
Já consultou o link http://datumedge.blogspot.co.uk/2012/06/java-8-lambdas.html
K
Só por ter closures será que podemos dizer isto? Na realidade eu vejo mais como uma mistureba mesmo, não?
Já consultou o link http://datumedge.blogspot.co.uk/2012/06/java-8-lambdas.html
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.
J
Só por ter closures será que podemos dizer isto? Na realidade eu vejo mais como uma mistureba mesmo, não?
Já consultou o link http://datumedge.blogspot.co.uk/2012/06/java-8-lambdas.html
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.
E agora você esta vendo em Java.
R
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.
J
Bom, Java 8 é bem o paradigma funcional
Não é assim “bem”. Vai possuir alguns recursos. Vai ser semelhante ao c# 4 e c++11.
K
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.
Segue o link: http://commons.apache.org/sandbox/functor/
J
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.
K
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.
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.
B
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.
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.
B
E agora você esta vendo em Java.
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?
J
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.
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.
J
“O assunto merece uma reflexão”
L
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.
Mas já facilita o desenvolvimento
V
Como se o TIOBE medisse alguma coisa…
J
Esse site tá bem sugestivo :shock:
http://functionaljava.org/
Criado 12 de julho de 2012
Ultima resposta 16 de jul. de 2012
Respostas 40
Participantes 12
Alura O que são algoritmos e lógica de programação e como aprender? Entenda o que são algoritmos e lógica de programação e qual é a importância desses conceitos para começar a programar
Fiap Graduacao em Tecnologia — FIAP Analise e Desenvolvimento de Sistemas, Engenharia de Software e mais
Casa do Codigo Casa do Codigo — Livros de tecnologia Livros de programacao, infraestrutura e inovacao