Arquivo Discussoes de Programacao e Tecnologia 
é impressão minha ou tanto java quanto c# estão em um caminho de se tornarem linguagens
funcionais por adicionarem Clousures, lambda calculus, (C# com linq) e várias outras features do mundo funcional ?
e será que essa mistura de paradigmas(OO e Funcional) no mesmo projeto não podem fazer os sistemas se tornarem mais díficeis de se fazer manutenção,
sendo mais complicado criar documentações, e facilitando a inserção de erros arquiteturais no projeto ?
é impressão minha ou tanto java quanto c# estão em um caminho de se tornarem linguagens
funcionais por adicionarem Clousures, lambda calculus, (C# com linq) e várias outras features do mundo funcional?
Tomara, mas acho pouco provável. Linguagens funcionais não são exatamente uma tecnologia nova.
Na verdade, surgiram até mesmo antes das linguagens estruturadas.
e será que essa mistura de paradigmas(OO e Funcional) no mesmo projeto não podem fazer os sistemas se tornarem mais díficeis de se fazer manutenção,
sendo mais complicado criar documentações, e facilitando a inserção de erros arquiteturais no projeto ?
Acho que sim. Misturas de paradigmas sempre causam algum tipo de estresse. Mas é um risco que geralmente vale a pena correr.
Sei lá. Acho que esses trecos de porgramação funcional dificultam até a legibilidade do código. Eu mesmo fiz um código em C# dia desses e coloquei uma expressão lambda no meio. Pensando na manuntenção eu estou considerando tirar isso e implementar a mesma solução de uma forma mais tradicional. Mas pode ser a minha falta de conhecimento em paradigmas funcionais.
Um dos problemas é que geralmente quem não conhece usa um lambda como uma espécie de “inner class anônima fácil de digitar”. Isso é tão verdade que parte da propaganda do lambda no Java (e no C++ também) é baseada exclusivamente nisso. E isso não é exatamente usar o paradigma funcional.
Já vi alguns códigos em LINQ que fazem um uso sério de lambda. Mas realmente, é muito legível para quem entende, mas pouco legível para quem não entende (a grande maioria dos programadores).
Um dos problemas é que geralmente quem não conhece usa um lambda como uma espécie de “inner class anônima fácil de digitar”. Isso é tão verdade que parte da propaganda do lambda no Java (e no C++ também) é baseada exclusivamente nisso. E isso não é exatamente usar o paradigma funcional.Já vi alguns códigos em LINQ que fazem um uso sério de lambda. Mas realmente, é muito legível para quem entende, mas pouco legível para quem não entende (a grande maioria dos programadores).
Engraçado, eu estava lendo sobre isso ontem a noite. Eu imagino que essas linguagens modernas serão um misto entre as duas, mas somente funcional creio que não.
A lâmbda simplifica por demais um bloco de código. A primeira vista pode parecer estranho mas é questão de costume.
Fiquei impressionado com o que dá para fazer com esse linq. Até comecei a estudar o Entity Framework.
Engraçado, eu estava lendo sobre isso ontem a noite. Eu imagino que essas linguagens modernas serão um misto entre as duas, mas somente funcional creio que não.
A lâmbda simplifica por demais um bloco de código. A primeira vista pode parecer estranho mas é questão de costume.Fiquei impressionado com o que dá para fazer com esse linq. Até comecei a estudar o Entity Framework.
Pelo grande avanço do conhecimento do paradigma OO, e por causa de muito código legado, pelo jeito as linguagens mais modernas serão hibridas mesmo.
Mas o que mais me impressinou no paradigma funcional, foi a forma elegante que foi resolvida o problema da execução de softwares em ambiente multithreads, sem precisar de Locks e jamais gerando dead locks ou race conditions. Com toda certeza essa seria uma feature que gostaria de ver no java.
Engraçado, eu estava lendo sobre isso ontem a noite. Eu imagino que essas linguagens modernas serão um misto entre as duas, mas somente funcional creio que não.
A lâmbda simplifica por demais um bloco de código. A primeira vista pode parecer estranho mas é questão de costume.Fiquei impressionado com o que dá para fazer com esse linq. Até comecei a estudar o Entity Framework.
Pelo grande avanço do conhecimento do paradigma OO, e por causa de muito código legado, pelo jeito as linguagens mais modernas serão hibridas mesmo.
Mas o que mais me impressinou no paradigma funcional, foi a forma elegante que foi resolvida o problema da execução de softwares em ambiente multithreads, sem precisar de Locks e jamais gerando dead locks ou race conditions. Com toda certeza essa seria uma feature que gostaria de ver no java.
Eles também precisam levar em questão a qualidade do compilador. Não creio que seja possível criar um bom compilador para assembly com uma linguagem inteiramente funcional. Seria talvez preciso uma gramatica muito extensa. Posso estar enganado.
Eles também precisam levar em questão a qualidade do compilador. Não creio que seja possível criar um bom compilador para assembly com uma linguagem inteiramente funcional. Seria talvez preciso uma gramatica muito extensa. Posso estar enganado.
Se não estou enganado Haskell pode ser chamado de puramente funcional e possui aparentemente um ótimo compilador.
Geralmente dizem que a performance é próxima a C++.
(Apesar da maioria das linguagens se dizerem próximas de C++).
Eles também precisam levar em questão a qualidade do compilador. Não creio que seja possível criar um bom compilador para assembly com uma linguagem inteiramente funcional. Seria talvez preciso uma gramatica muito extensa. Posso estar enganado.Se não estou enganado Haskell pode ser chamado de puramente funcional e possui aparentemente um ótimo compilador.
Geralmente dizem que a performance é próxima a C++.
(Apesar da maioria das linguagens se dizerem próximas de C++).
Comparando o ghc(gnu haskell) com o gcc(gnu c), o código gerado pelo primeiro ainda está atrás do segundo.
Imagino que o g++ ainda consiga bater esses dois.
http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=gcc&lang2=ghc
Em árvores o compilador de c chega ser 4x melhor que o de haskell
binary-trees
C GNU gcc 13.09 5.44 150,720 850 94% 46% 66% 34%
Haskell GHC 67.80 21.30 781,940 612 73% 90% 84% 74%
Esses compiladores são os do set da gnu. Podem haver outros compiladores de haskell mais otimizados.
acho que nao, acho que ha espaco para os 2 paradigmas.
Um dos problemas é que geralmente quem não conhece usa um lambda como uma espécie de “inner class anônima fácil de digitar”. Isso é tão verdade que parte da propaganda do lambda no Java (e no C++ também) é baseada exclusivamente nisso. E isso não é exatamente usar o paradigma funcional.Já vi alguns códigos em LINQ que fazem um uso sério de lambda. Mas realmente, é muito legível para quem entende, mas pouco legível para quem não entende (a grande maioria dos programadores).
Essa dificuldade de leitura é mais do que natural. É fácil para quem não conhece inglês ler um texto em inglês? Com linguagens de programação não é diferente.
Com o tempo, as pessoas acostumam.
e pra debugar um codigo desse?
Essa dificuldade de leitura é mais do que natural. É fácil para quem não conhece inglês ler um texto em inglês? Com linguagens de programação não é diferente.Com o tempo, as pessoas acostumam.
O problema é que temos poucas escolas ensinando o pessoal a falar inglês. 
Essa dificuldade de leitura é mais do que natural. É fácil para quem não conhece inglês ler um texto em inglês? Com linguagens de programação não é diferente.Com o tempo, as pessoas acostumam.
O problema é que temos poucas escolas ensinando o pessoal a falar inglês. ;)
Realmente… Estamos aprendendo inglês comprando livro e vendo o povo “falar” no Google. rs
Engraçado. Muito tem se falado à respeito de inserir elementos de programação funcional em linguagens OO. Mas e a programação orientada à aspectos? Por que não se tem tanto interesse nela? Pelo que eu andei vendo na internet sobre o assunto, me pareceu um paradigma legal.
Engraçado. Muito tem se falado à respeito de inserir elementos de programação funcional em linguagens OO. Mas e a programação orientada à aspectos? Por que não se tem tanto interesse nela? Pelo que eu andei vendo na internet sobre o assunto, me pareceu um paradigma legal.
O Microsoft MVC usa uma abordagem similar a de aspectos para tratamento de requisições. Você pode fazer algo como:
public class UsuarioController {
[MySecurityPolicy]
public void CadastrarUsuario(int id) {
//Código para cadastrar usuário
}
}
Onde MySecurityPolicy é uma classe, implementada por você, que contém a política de acesso do usuário ao sistema. Se a requisição não sobreviver a essa política, o método CadastrarUsuario do controller nem sequer roda.
Engraçado. Muito tem se falado à respeito de inserir elementos de programação funcional em linguagens OO. Mas e a programação orientada à aspectos? Por que não se tem tanto interesse nela? Pelo que eu andei vendo na internet sobre o assunto, me pareceu um paradigma legal.O Microsoft MVC usa uma abordagem similar a de aspectos para tratamento de requisições. Você pode fazer algo como:
public class UsuarioController { [MySecurityPolicy] public void CadastrarUsuario(int id) { //Código para cadastrar usuário } }Onde MySecurityPolicy é uma classe, implementada por você, que contém a política de acesso do usuário ao sistema. Se a requisição não sobreviver a essa política, o método CadastrarUsuario do controller nem sequer roda.
Hum, interessante. Mas bem que a POA poderia ser usada em mais linguagens.
Engraçado. Muito tem se falado à respeito de inserir elementos de programação funcional em linguagens OO. Mas e a programação orientada à aspectos? Por que não se tem tanto interesse nela? Pelo que eu andei vendo na internet sobre o assunto, me pareceu um paradigma legal.O Microsoft MVC usa uma abordagem similar a de aspectos para tratamento de requisições. Você pode fazer algo como:
public class UsuarioController { [MySecurityPolicy] public void CadastrarUsuario(int id) { //Código para cadastrar usuário } }Onde MySecurityPolicy é uma classe, implementada por você, que contém a política de acesso do usuário ao sistema. Se a requisição não sobreviver a essa política, o método CadastrarUsuario do controller nem sequer roda.
Hum, interessante. Mas bem que a POA poderia ser usada em mais linguagens.
Mas não será, enquanto a POE (Programação Orientada a Estagiário) e a POG (Precisa explicar?) dominarem o mercado.
…Hum, interessante. Mas bem que a POA poderia ser usada em mais linguagens.
Mas não será, enquanto a POE (Programação Orientada a Estagiário) e a POG (Precisa explicar?) dominarem o mercado.
Pois é, pensei no mesmo. Tem muita gente que mal sabe usar OO corretamente, imagine os códigos bizarros que esse pessoal faria em POA.