Existe design patterns para o paradigma funcional?

A gigantesca maioria dos padrões de projetos são voltados para o paradigma orientado ao objeto,
mas será que existem outros padrões voltados especificamente para o ambiente funcional ?

[quote=johnny quest]A gigantesca maioria dos padrões de projetos são voltados para o paradigma orientado ao objeto,
mas será que existem outros padrões voltados especificamente para o ambiente funcional ?[/quote]
Tem o Transacion Script Pattern:
http://www.informit.com/articles/article.aspx?p=1398617


http://www.mundoj.com.br/images/revvirtual/edicao44.jpg

Se você tem duas opções para se fazer a mesma coisa, uma delas será um pattern.

A única vantagem é que linguagens funcionais geralmente te dão mais abstração, o que permite que você escreva o pattern uma única vez no código todo.

Obrigado por todas as respostas.

Realmente não deve existir ainda nenhum catalogo de design patterns específicos para o paradigma funcional.

Design Patterns são gambiarras para se trabalhar ao redor de uma limitação, e isso depende da linguagem.

Por exemplo, em Javascript não é possível usar herança. Logo se você quiser criar uma hierarquia de componentes precisará usar um pattern ou uma biblioteca que empregue esse pattern. Isso para simular uma feature que em outras linguagens é “de graça”.

Isso parece ridículo, afinal de contas, se essa feature é necessária então porque não utilizar uma linguagem que a disponibilize?

Toda Design Pattern pode ser evitada simplesmente escolhendo-se a ferramenta correta para se trabalhar.

Existem catálogos de patterns sim:
http://web.cecs.pdx.edu/~antoy/flp/patterns/

Patern não tem a ver com limitações da linguagem, e sim, com as melhores maneiras de se resolver coisas. Qualquer limguagem que te duas opções para a mesma coisa terá um pattern.

E sim, existem patterns para se tratar de limitações, mas eles não são regra e essa condição não define um pattern.

[quote=ViniGodoy]
Patern não tem a ver com limitações da linguagem, e sim, com as melhores maneiras de se resolver coisas. Qualquer limguagem que te duas opções para a mesma coisa terá um pattern.[/quote]

Não, não terá.

Em algumas linguages você pode expressar o que é necessário direto na linguagem, ou extendê-la com novas construções sintáticas afim de desempenhar um determinado papel. Design Pattern é repetição de código. E isso só existe em linguagens mais limitadas.

Aqui está um texto interessando que se aplica a isso: http://paulgraham.com/avg.html

[quote]Programmers get very attached to their favorite languages, and I don’t want to hurt anyone’s feelings, so to explain this point I’m going to use a hypothetical language called Blub. Blub falls right in the middle of the abstractness continuum. It is not the most powerful language, but it is more powerful than Cobol or machine language.

And in fact, our hypothetical Blub programmer wouldn’t use either of them. Of course he wouldn’t program in machine language. That’s what compilers are for. And as for Cobol, he doesn’t know how anyone can get anything done with it. It doesn’t even have x (Blub feature of your choice).

As long as our hypothetical Blub programmer is looking down the power continuum, he knows he’s looking down. Languages less powerful than Blub are obviously less powerful, because they’re missing some feature he’s used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn’t realize he’s looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.

When we switch to the point of view of a programmer using any of the languages higher up the power continuum, however, we find that he in turn looks down upon Blub. How can you get anything done in Blub? It doesn’t even have y.

By induction, the only programmers in a position to see all the differences in power between the various languages are those who understand the most powerful one. (This is probably what Eric Raymond meant about Lisp making you a better programmer.) You can’t trust the opinions of the others, because of the Blub paradox: they’re satisfied with whatever language they happen to use, because it dictates the way they think about programs.[/quote]

Longino, nós já tivemos essa discussão. A definição de pattern é: “In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.” (GoF)

O conceito de design pattern ser repetição de código só existe na sua cabeça. Na verdade, o Paul Graham escreveu um texto onde ele ressaltava que alguns patterns eram ser indicativos de onde as linguagens poderiam ser melhoradas, mas claro, os amantes de linguagens funcionais e trollers como você deturparam a definição e a elevaram ao extremo.

Diferentes linguagens com diferentes recursos só terão diferentes patterns. Não adianta tentar usar o livro do GoF em LISP.
Há propostas de catálogos de patterns, como a que mostrei acima, ou a lista compilada pelo Peter Norvig, que te mostrei em outro post.

[quote]
Existem catálogos de patterns sim:
http://web.cecs.pdx.edu/~antoy/flp/patterns/

Patern não tem a ver com limitações da linguagem, e sim, com as melhores maneiras de se resolver coisas. Qualquer limguagem que te duas opções para a mesma coisa terá um pattern.[/quote]

ViniGodoy. Obrigado por responder a minha pergunta.
Mesmo o guj começando a ficar lotado de trolls, ainda participo no guj porque aprendo bastante com diversos usuários em vários tópicos diferentes, principalmente com o ViniGodoy.

Obrigado. :smiley:

Concordo com o Longino, se você esta procurando por padrões para expressar sua solução é porque sua linguagem te deixou na mão.

Sempre existem formas mais fáceis do que usar patterns, basta procurar. :slight_smile:

[quote=ViniGodoy]
O conceito de design pattern ser repetição de código só existe na sua cabeça. Na verdade, o Paul Graham escreveu um texto onde ele ressaltava que alguns patterns eram ser indicativos de onde as linguagens poderiam ser melhoradas, mas claro, os amantes de linguagens funcionais e trollers como você deturparam a definição e a elevaram ao extremo.[/quote]

Só na sua cabeça isso é ciência. Opiniões de um grupo de fulanos valem tanto quanto a de qualquer um, pois afinal de contas são apenas opiniões.

O conceito de Design Pattern foi criado devido às limitações inerentes a linguagem C++ e mais tarde muitas outras foram criadas para o Java.

O que acontece aqui é exatamente o que Paul Graham descreveu no texto dele, você acha que Design Pattern é normal porque você só consegue pensar em “Java” ou alguma linguagem imperativa similar. Se buscasse entender outros paradigmas, veria que muitos dos problemas só existem porque a linguagem de implementação é limitada, e não por causa de algum problema intrínseco ao domínio.

Acontece que não estou me baseando nas opiniões de um grupo de fulanos, mas na definição clássica de patterns, dado pelos criadores da teoria, em sua tese de doutorado.
Na minha cabeça, isso é ciência.

A única pessoa que está dando opinião aqui é você.

Longino. Eu programo em LISP com relativa freqüência. Sei o quanto a linguagem é poderosa e capaz de abstrair conceitos, evitar repetições de código, etc.

Não existe ainda um conjunto de design patterns em LISP pelos seguintes motivos:
a) Ninguém se preocupou em fazer um levantamento tão grande e preciso quanto o GoF fez (até porque, o uso de LISP ainda é bastante restrito, se comparado ao das linguagens OO);
b) A comunidade ainda não formalizou um vocabulário, num catálogo bem aceito e descrito. Um pattern só é um pattern depois de formalizado;

Por exemplo, em boas parte dos programas lisp que já trabalhei, alguém cedo ou tarde cria uma macro ou uma função para fazer algo similar ao for each, ou mesmo ao comando for.
Ok, as macros tem nomes diferentes, ou são implementadas por mecanismos diferentes, mas são basicamente a mesma solução, para o mesmo problema.

Bastaria estudar as alternativas de macros desse tipo, pesar as vantagens e desvantagens de cada um, e formalizar uma solução que pareça ser a melhor de maneira geral. Então, você dá um nome (que poderia ser “for each pattern”) para se ter um design pattern. Isso não tem nada a ver com limitação da linguagem. É simplesmente uma formalização de uma solução padrão para um problema padrão.

Mas enfim, essa a última resposta que eu te dou, afinal, você já foi até banido do fórum por trolling, e sei lá o que veio fazer aqui novamente com seu novo usuário. Como você já começou a me atacar pessoalmente, ao dizer que eu “só consigo pensar em Java”, ao dar a entender que não sei o que é ciência, e que eu “não busco entender outros paradigmas”, dou o assunto por encerrado.

Não sei se existe essa coisa de padrões visando atender todo um PARADIGMA, OO ou funcional (GoF não é um catálogo de padrões OO em geral, mas de OO segundo linguagens baseadas em C++/Java/C#).

Apesar de não concordar com o Longino, ele tem um bom argumento quando diz que patterns podem ser um sinal de limitação da linguagem, afinal como explica o fato de que grande parte do GoF se tornar irrelevante em linguagens OO mais modernas como Ruby, Scala por exemplo?

Eu por exemplo nunca ouvi ninguém reclamar de falta de formalização de padrões nessas linguagens que por sua vez são consideradas muito mais produtivas que Java.

Mas respondendo sua pergunta sobre paradigma funcional, da uma procurada por OTP (Open Telecom Platform) que, entre outras coisas, define um conjunto de design patterns para programação concorrente, tolerante a falhas, em Erlang.

Concordo com você. Java pode ser complexo demais, mas limitado?

Uma linguagem que pode ser usada para criar programas mobile, server, desktop, TV Digital, embarcados, etc…

…não é limitado para programadores de “mercado”.

Eu nunca disse que patterns não podem ser um sinal de falha da linguagem. Um problema comum pode surgir de uma deficiência da linguagem, como é o caso do padrão Singleton. Eu só critiquei o fato dele definir padrão como uma falha da linguagem. Muitos padrões, de fato, são justamente o oposto: a linguagem dá muitos meios de resolver o problemas, e há vários trade-offs envolvidos em cada um (muitos nem sempre óbvios). Fábricas, listeners, são justamente esse caso. As linguagens dão diversas formas de fazer essas coisas, e uma delas acaba se provando a melhor com o tempo e a experiência.

E, claro, creio que será possível implementar mecanismos nas linguagens para automatizar, ou facilitar alguns padrões.

[quote=vargas]Eu por exemplo nunca ouvi ninguém reclamar de falta de formalização de padrões nessas linguagens que por sua vez são consideradas muito mais produtivas que Java.

Mas respondendo sua pergunta sobre paradigma funcional, da uma procurada por OTP (Open Telecom Platform) que, entre outras coisas, define um conjunto de design patterns para programação concorrente, tolerante a falhas, em Erlang.[/quote]

Isso porque a cultura OO é muito rica, se comparado a das linguagens funcionais. Por mais legal que o LISP e o paradigma funcional sejam (e eu acho ele muito legal) ele ainda está muito aquém da popularidade da OO. Com isso, há menos literatura e menos demanda. É difícil ver aplicações grandes integralmente desenvolvidas na linguagem. Muitas são aplicações para rodar sob funções específicas, ou scripts integrados à outra linguagem.

[quote=ViniGodoy]
Eu nunca disse que patterns não podem ser um sinal de falha da linguagem. Um problema comum pode surgir de uma deficiência da linguagem, como é o caso do padrão Singleton. Eu só critiquei o fato dele definir padrão como uma falha da linguagem. Muitos padrões, de fato, são justamente o oposto: a linguagem dá muitos meios de resolver o problemas, e há vários trade-offs envolvidos em cada um (muitos nem sempre óbvios). Fábricas, listeners, são justamente esse caso. As linguagens dão diversas formas de fazer essas coisas, e uma delas acaba se provando a melhor com o tempo e a experiência.[/quote]

Isso não explica porque essa cultura de padrões não existe em linguagens OO mais moderna.

[quote=ViniGodoy]
Isso porque a cultura OO é muito rica, se comparado a das linguagens funcionais. Por mais legal que o LISP e o paradigma funcional sejam (e eu acho ele muito legal) ele ainda está muito aquém da popularidade da OO. Com isso, há menos literatura e menos demanda. É difícil ver aplicações grandes integralmente desenvolvidas na linguagem. Muitas são aplicações para rodar sob funções específicas, ou scripts integrados à outra linguagem.[/quote]

Desculpa, mas você está trolando? Assim fica difícil te levar a sério… linguagens funcionais estão em todo lugar. Amazon usa linguagens funcionais em praticamente todos seus serviços, projetos opensource como CouchDB, RIAK, RabbitMQ, isso sem falar no Facebook, WhatsApp, moreladores 3D (Wings3D).

Você quis dizer linguagens OO ou linguagens funcionais?

Não, não estou trolando. Não falei que não existem projetos com linguagens funcionais, nem que não existem projetos grandes, ou que essas linguagens são ruins.

Eu escrevi que comparado ao número de projetos OO, o uso de linguagens funcionais ainda é muito restrito. E, como reflexo, há menos faculdades ensinando programação funcional (e, quando ensinam, geralmente é em uma matéria só), e há menos engenheiros de software preocupados em desenvolver métodos e técnicas de desenvolvimento que considerem linguagem funcional como seu mainstream.

Creio que haja boas chances de um catálogo de padrões não existir simplesmente porque ninguém ainda teve iniciativa de procurar empresas que desenvolvam fortemente com linguagens funcionais, estudar os códigos que eles desenvolvem e compilar o catálogo. Além disso, creio que mesmo que alguém fizesse isso, esse catálogo não teria a importância que teve o GoF, pois o uso de linguagens funcionais não é regra, mas sim exceção. Acho que é a mesma razão pelo qual não ouvimos falar de “análise de sistemas funcionais”, ou não temos algo como uma UML para linguagens funcionais.

Eu sinceramente gostaria que isso se invertesse no futuro. Gosto muito de programar em linguagens funcionais, e não ficaria nem um pouco triste se elas tomassem o lugar das tecnologias OO de hoje em dia.

Você quis dizer linguagens OO ou linguagens funcionais?[/quote]

Eu disse OO mesmo. Java e C++ são as únicas que divulgam padrões de software como solução. Python, Ruby e Scala são mais diretas.

[quote=ViniGodoy]
Eu escrevi que comparado ao número de projetos OO, o uso de linguagens funcionais ainda é muito restrito.[/quote]

Não é restrito. Citei vários exemplos de projetos reais e de alto nível que usam linguagens funcionais.

No que diz respeito a Lisp eu concordo com você, é uma linguagem arcaica e pouco usada.