Pergunta

Vejo muita conversa aqui sobre linguagens funcionais e outras coisas.Por que você usaria um em vez de uma linguagem "tradicional"?O que eles fazem melhor?Em que eles são piores?Qual é o aplicativo de programação funcional ideal?

Foi útil?

Solução

As linguagens funcionais usam um paradigma diferente das linguagens imperativas e orientadas a objetos.Eles usam funções livres de efeitos colaterais como um bloco de construção básico da linguagem.Isso permite muitas coisas e torna muitas coisas mais difíceis (ou, na maioria dos casos, diferentes daquilo a que as pessoas estão acostumadas).

Uma das maiores vantagens da programação funcional é que a ordem de execução das funções livres de efeitos colaterais não é importante.Por exemplo, em Erlang isto é usado para permitir a simultaneidade de uma forma muito transparente.E como as funções em linguagens funcionais se comportam de maneira muito semelhante às funções matemáticas, é fácil traduzi-las para linguagens funcionais.Em alguns casos, isso pode tornar o código mais legível.

Tradicionalmente, uma das grandes desvantagens da programação funcional era também a falta de efeitos colaterais.É muito difícil escrever software útil sem IO, mas é difícil implementar IO sem efeitos colaterais nas funções.Portanto, a maioria das pessoas nunca tirou mais proveito da programação funcional do que calcular uma única saída a partir de uma única entrada.Em linguagens modernas de paradigma misto, como F# ou Scala, isso é mais fácil.

Muitas linguagens modernas possuem elementos de linguagens de programação funcionais.C# 3.0 tem muitos recursos de programação funcional e você também pode fazer programação funcional em Python.Acho que as razões para a popularidade da programação funcional se devem principalmente a dois motivos:A simultaneidade está se tornando um problema real na programação normal porque estamos adquirindo cada vez mais computadores multiprocessadores;e as línguas estão cada vez mais acessíveis.

Outras dicas

Não creio que haja qualquer dúvida sobre a abordagem funcional da programação "pegando", porque ela está em uso (como um estilo de programação) há cerca de 40 anos.Sempre que um programador OO escreve código limpo que favorece objetos imutáveis, esse código está emprestando conceitos funcionais.

No entanto, as línguas que impor um estilo funcional está recebendo muita tinta virtual atualmente, e se essas linguagens se tornarão dominantes no futuro é uma questão em aberto.Minha própria suspeita é que linguagens híbridas e multiparadigmáticas, como escala ou OCamlprovavelmente dominará as linguagens funcionais "puristas" da mesma forma que a linguagem OO pura (Smalltalk, Beta, etc.) influenciou a programação convencional, mas não acabou como as notações mais amplamente utilizadas.

Por fim, não resisto em apontar que seus comentários sobre FP são altamente paralelos aos comentários que ouvi de programadores procedimentais há não muitos anos:

  • O (mítico, IMHO) programador "médio" não entende isso.
  • Não é amplamente ensinado.
  • Qualquer programa que você possa escrever com ele pode ser escrito de outra maneira com as técnicas atuais.

Assim como as interfaces gráficas de usuário e o "código como modelo de negócio" foram conceitos que ajudaram o OO a se tornar mais amplamente apreciado, acredito que o aumento do uso da imutabilidade e do paralelismo mais simples (massivo) ajudará mais programadores a ver os benefícios que a abordagem funcional oferece. .Mas por mais que tenhamos aprendido em nos últimos 50 anos ou mais que compõem toda a história da programação digital de computadores, acho que ainda temos muito que aprender.Daqui a vinte anos, os programadores olharão para trás, surpresos, com a natureza primitiva das ferramentas que usamos atualmente, Incluindo as agora populares linguagens OO e FP.

A principal vantagem para mim é o seu paralelismo inerente, especialmente porque agora estamos nos afastando de mais MHz e em direção a cada vez mais núcleos.

Não acho que isso se tornará o próximo paradigma de programação e substituirá completamente os métodos do tipo OO, mas acho que chegaremos ao ponto em que precisaremos escrever parte do nosso código em uma linguagem funcional ou nossas linguagens de uso geral irão crescer para incluir construções mais funcionais.

Mesmo que você nunca tenha trabalhado profissionalmente em uma linguagem funcional, compreender a programação funcional o tornará um desenvolvedor melhor.Isso lhe dará uma nova perspectiva sobre seu código e programação em geral.

Eu digo que não há razão para não aprender.

Acho que as linguagens que fazem um bom trabalho ao misturar estilo funcional e imperativo são as mais interessantes e têm maior probabilidade de sucesso.

Sempre sou cético em relação à próxima grande novidade.Muitas vezes a Próxima Grande Coisa é puro acidente da história, estando lá no lugar certo na hora certa, não importa se a tecnologia é boa ou não.Exemplos:C++, Tcl/Tk, Perl.Todas tecnologias imperfeitas, todas extremamente bem-sucedidas porque foram percebidas como resolvendo os problemas da época ou como quase idênticas aos padrões arraigados, ou ambos.A programação funcional pode realmente ser ótima, mas isso não significa que será adotada.

Mas eu pode dizer por que as pessoas estão excitado sobre programação funcional:muitos, muitos programadores tiveram uma espécie de "experiência de conversão" na qual descobriram que usar uma linguagem funcional os torna duas vezes mais produtivos (ou talvez dez vezes mais produtivos), ao mesmo tempo que produzem código mais resistente a mudanças e com menos bugs.Essas pessoas pensam na programação funcional como uma arma secreta;um bom exemplo dessa mentalidade é o de Paul Graham Superando as Médias.Ah, e sua aplicação?Aplicativos da web de comércio eletrônico.

Desde o início de 2006 também tem havido algum burburinho sobre programação funcional e paralelismo.Já que as pessoas gostam Simon Peyton Jones tenho me preocupado com o paralelismo desde pelo menos 1984, não vou prender a respiração até que as linguagens funcionais resolvam o problema multicore.Mas isso explica parte do burburinho adicional no momento.

Em geral, as universidades americanas estão fazendo um péssimo trabalho no ensino de programação funcional.Há um forte núcleo de apoio para ensinando introdução à programação usando Scheme, e Haskell também conta com algum suporte lá, mas há muito pouco no ensino de técnicas avançadas para programadores funcionais.Ministrei esse curso em Harvard e o farei novamente nesta primavera na Tufts.Benjamin Pierce ministrou esse curso na Penn.Não sei se Paul Hudak fez alguma coisa em Yale.As universidades europeias estão a fazer um trabalho muito melhor;por exemplo, a programação funcional é enfatizada em locais importantes na Dinamarca, nos Países Baixos, na Suécia e no Reino Unido.Tenho menos noção do que está acontecendo na Australásia.

Não vejo ninguém mencionando o elefante na sala aqui, então acho que depende de mim :)

JavaScript é uma linguagem funcional.À medida que mais e mais pessoas fazem coisas mais avançadas com JS, especialmente aproveitando os pontos mais delicados do jQuery, Dojo e outras estruturas, o FP será introduzido pela porta dos fundos do desenvolvedor web.

Em conjunto com os encerramentos, o FP torna o código JS realmente leve, mas ainda assim legível.

Saúde, PS

A maioria dos aplicativos são simples o suficiente para serem resolvidos de maneira OO normal

  1. As maneiras nem sempre foram "normais". O padrão desta década foi o conceito marginalizado da última década.

  2. Programação funcional é matemática. Paul Graham em Lisp (substitua a programação funcional por Lisp):

Portanto, a curta explicação de por que esse idioma da década de 1950 não é obsoleto é que não era tecnologia, mas matemática, e a matemática não fica obsoleta.A coisa certa para comparar o Lisp não é o hardware dos anos 50, mas, digamos, o algoritmo do Quicksort, que foi descoberto em 1960 e ainda é o tipo de uso geral mais rápido.

Aposto que você não sabia que era programação funcional quando usou:

  • Fórmulas Excel
  • Compositor de Quartzo
  • JavaScript
  • Logotipo (gráficos de tartaruga)
  • LINQ
  • SQL
  • Subscore.js (ou lodash), d3

O programador corporativo médio, por ex.A maioria das pessoas com quem trabalho não vai entender e a maioria dos ambientes de trabalho não permitirá que você se programe nele

Essa é apenas uma questão de tempo.O programador corporativo médio aprende qualquer que seja a grande novidade do momento.Há 15 anos, eles não entendiam OOP.SE O FP entende, seus “programadores corporativos médios” o seguirão.

Não é realmente ensinado nas universidades (ou é hoje em dia?)

Varia muito.Na minha universidade, o SML é o primeiro idioma ao qual os alunos são apresentados.Acredito que o MIT ensina LISP como um curso de primeiro ano.Estes dois exemplos podem não ser representativos, claro, mas acredito que a maioria das universidades oferece, pelo menos, alguns cursos opcionais sobre PF, mesmo que não os tornem uma parte obrigatória do currículo.

A maioria das aplicações é simples o suficiente para ser resolvida de maneira normal OO

Porém, não é realmente uma questão de "suficientemente simples".Seria uma solução mais simples (ou mais legível, robusto, elegante e de alto desempenho) em FP?Muitas coisas são "suficientemente simples para serem resolvidas em Java", mas ainda requerem uma quantidade enorme de código.

Em qualquer caso, tenha em mente que há já várias décadas que os proponentes do PF afirmam que este será o próximo grande sucesso.Talvez estejam certos, mas tenha em mente que não estavam quando fizeram a mesma afirmação há 5, 10 ou 15 anos.

Uma coisa que definitivamente conta a seu favor é que recentemente o C# deu uma guinada acentuada em direção ao FP, a ponto de praticamente transformar uma geração de programadores em programadores de FP, sem que eles nem percebam.Isso poderia apenas abrir caminho para a “revolução” do FP.Talvez.;)

O homem não pode compreender a perfeição e as imperfeições da arte que escolheu se não conseguir ver o valor em outras artes.Seguir regras só permite o desenvolvimento até certo ponto da técnica e então o aluno e o artista têm que aprender mais e buscar mais.Faz sentido estudar outras artes além das da estratégia.

Quem não aprendeu algo mais sobre si mesmo observando as atividades dos outros?Para aprender a espada estude violão.Para aprender o primeiro estudo de comércio.Apenas estudar a espada o tornará tacanho e não permitirá que você cresça externamente.

- Miyamoto Musashi, "Um Livro dos Cinco Anéis"

Uma característica fundamental em uma linguagem funcional é o conceito de funções de primeira classe.A ideia é que você possa passar funções como parâmetros para outras funções e retorná-las como valores.

A programação funcional envolve escrever código que não muda de estado.A principal razão para fazer isso é que chamadas sucessivas a uma função produzirão o mesmo resultado.Você pode escrever código funcional em qualquer linguagem que suporte funções de primeira classe, mas existem algumas linguagens, como Haskell, que não permitem alterar o estado.Na verdade, você não deve causar nenhum efeito colateral (como imprimir texto) - o que parece ser completamente inútil.

Em vez disso, Haskell emprega uma abordagem diferente para IO:mônadas.Estes são objetos que contêm a operação IO desejada a ser executada pelo nível superior do seu intérprete.Em qualquer outro nível são simplesmente objetos no sistema.

Que vantagens a programação funcional oferece?A programação funcional permite codificação com menos potencial para bugs porque cada componente é completamente isolado.Além disso, o uso de recursão e funções de primeira classe permite provas simples de correção que normalmente refletem a estrutura do código.

Não creio que as pessoas mais realistas pensem que a programação funcional vai pegar (torna-se o principal paradigma como OO).Afinal, a maioria dos problemas de negócios não são problemas matemáticos bonitos, mas regras imperativas complicadas para mover dados e exibi-los de várias maneiras, o que significa que não é uma boa opção para o paradigma de programação funcional puro (a curva de aprendizado da mônada excede em muito OO).

OTOH, programação funcional é o que torna a programação divertida.Faz você apreciar a beleza inerente e atemporal das expressões sucintas da matemática subjacente do universo.As pessoas dizem que aprender programação funcional fará de você um programador melhor.É claro que isso é altamente subjetivo.Pessoalmente, também não acho que isso seja totalmente verdade.

Isso faz de você um ser senciente melhor.

Devo ser estúpido, mas ainda não entendi.Existem exemplos reais de pequenos aplicativos escritos em uma linguagem funcional como F #, onde você pode examinar o código-fonte e ver como e por que era melhor usar essa abordagem do que, digamos, C #?

Eu gostaria de salientar que tudo o que você disse sobre linguagens funcionais, a maioria das pessoas dizia sobre linguagens orientadas a objetos há cerca de 20 anos.Naquela época era muito comum ouvir falar de OO:

* The average corporate programmer, e.g. most of the people I work with, will not understand it and most work environments will not let you program in it
* It's not really taught at universities (or is it nowadays?)
* Most applications are simple enough to be solved in normal IMPERATIVE ways

A mudança tem que vir de algum lugar.Uma mudança significativa e importante acontecerá independentemente de as pessoas treinadas em tecnologias anteriores considerarem que a mudança não é necessária.Você acha que a mudança para OO foi boa apesar de todas as pessoas que eram contra na época?

O F# pode pegar porque a Microsoft está promovendo isso.

Pró:

  • F# fará parte da próxima versão do Visual Studio
  • A Microsoft está construindo uma comunidade já há algum tempo - evangelistas, livros, consultores que trabalham com clientes de alto perfil, exposição significativa em conferências de MS.
  • F# é uma linguagem .Net de primeira classe e é a primeira linguagem funcional que vem com uma base realmente grande (não que eu diga que Lisp, Haskell, Erlang, Scala, OCaml não tenham muitas bibliotecas, elas apenas não são tão completas quanto .Net é)
  • Forte apoio ao paralelismo

Contra:

  • F# é muito difícil de começar, mesmo se você for bom com C# e .Net - pelo menos para mim :(
  • provavelmente será difícil encontrar bons desenvolvedores de F#

Então, dou 50:50 de chance para o F# se tornar importante.Outras linguagens funcionais não funcionarão em um futuro próximo.

Acho que uma razão é que algumas pessoas acham que a parte mais importante para saber se um idioma será aceito é quão bom ele é.Infelizmente, as coisas raramente são tão simples.Por exemplo, eu diria que o maior fator por trás da aceitação do Python não é a linguagem em si (embora isso é muito importante).A maior razão pela qual o Python é tão popular é sua enorme biblioteca padrão e a comunidade ainda maior de bibliotecas de terceiros.

Linguagens como Clojure ou F# podem ser a exceção à regra, considerando que são construídas sobre JVM/CLR.Como resultado, não tenho uma resposta para eles.

A maioria dos aplicativos pode ser resolvida em [insira sua linguagem favorita, paradigma, etc.aqui].

Embora isso seja verdade, diferentes ferramentas podem ser usadas para resolver diferentes problemas.Funcional apenas permite outra abstração de alto (superior?) Nível que permite realizar nosso trabalho de maneira mais eficaz quando usado corretamente.

Parece-me que aquelas pessoas que nunca aprenderam Lisp ou Scheme na graduação agora estão descobrindo.Tal como acontece com muitas coisas neste campo, há uma tendência para exagerar e criar grandes expectativas...

Vai passar.

A programação funcional é ótima.No entanto, não dominará o mundo.C, C++, Java, C#, etc ainda estarão por aí.

O que resultará disso, eu acho, é mais habilidade em vários idiomas - por exemplo, implementar coisas em uma linguagem funcional e depois dar acesso a essas coisas em outras linguagens.

Ao ler "A próxima linguagem de programação convencional:A Game Developer’s Perspective" de Tim Sweeney, Epic Games, meu primeiro pensamento foi: eu aprendi Haskell.

PPT

Versão HTML do Google

As coisas estão caminhando em uma direção funcional há algum tempo.Os dois novos garotos legais dos últimos anos, Ruby e Python, estão radicalmente mais próximos das linguagens funcionais do que o que veio antes deles - tanto que alguns Lispers começaram a apoiar um ou outro como "próximo o suficiente".

E com o hardware massivamente paralelo colocando pressão evolutiva sobre todos — e as linguagens funcionais no melhor lugar para lidar com as mudanças — não é um salto tão grande quanto antes pensar que Haskell ou F# serão o próximo grande sucesso.

Você tem acompanhado a evolução das linguagens de programação ultimamente?Cada nova versão de todas as principais linguagens de programação parece emprestar cada vez mais recursos da programação funcional.

  • Fechamentos, funções anônimas, funções de passagem e retorno como valores costumavam ser recursos exóticos conhecidos apenas por hackers de Lisp e ML.Mas gradualmente, C#, Delphi, Python, Perl, Javascript adicionaram suporte para encerramentos.Não é possível que qualquer linguagem emergente seja levada a sério sem encerramentos.

  • Várias linguagens, principalmente Python, C# e Ruby, têm suporte nativo para compreensão de listas e geradores de listas.

  • O ML foi pioneiro na programação genérica em 1973, mas o suporte a genéricos ("polimorfismo paramétrico") só se tornou um padrão da indústria nos últimos 5 anos ou mais.Se bem me lembro, Fortran apoiou genéricos em 2003, seguido por Java 2004, C# em 2005, Delphi em 2008.(Eu sei que o C++ oferece suporte a modelos desde 1979, mas 90% das discussões sobre o STL do C++ começam com "aqui há demônios".)

O que torna esses recursos atraentes para os programadores?Deveria ser claramente óbvio: ajuda os programadores a escrever códigos mais curtos.Todas as línguas no futuro apoiarão – no mínimo – encerramentos se quiserem permanecer competitivas.A este respeito, a programação funcional já está em voga.

A maioria das aplicações é simples o suficiente para ser resolvida de maneira normal OO

Quem disse que não se pode usar programação funcional também para coisas simples?Nem todo programa funcional precisa ser um compilador, um provador de teoremas ou um switch de telecomunicações massivamente paralelo.Eu uso F# regularmente para scripts descartáveis ​​ad hoc, além de meus projetos mais complicados.

Está em alta porque é a melhor ferramenta disponível para controlar a complexidade.Ver:
- slides 109-116 da palestra de Simon Peyton-Jones "A Taste of Haskell"
- "A próxima linguagem de programação convencional:A perspectiva de um desenvolvedor de jogos" por Tim Sweeney

Concordo com o primeiro ponto, mas os tempos mudam.As empresas responderão, mesmo que sejam adoptantes tardios, se perceberem que há uma vantagem a obter.A vida é dinâmica.

Eles ensinavam Haskell e ML em Stanford no final dos anos 90.Tenho certeza de que lugares como Carnegie Mellon, MIT, Stanford e outras boas escolas estão apresentando isso aos alunos.

Concordo que a maioria dos aplicativos de “exposição de bancos de dados relacionais na web” continuarão nessa linha por muito tempo.Java EE, .NET, RoR e PHP desenvolveram algumas soluções muito boas para esse problema.

Você encontrou algo importante:Pode ser o problema que não pode ser resolvido facilmente por outros meios que irão impulsionar a programação funcional.O que seria aquilo?

Será que o enorme hardware multicore e a computação em nuvem os impulsionarão?

Porque o FP traz benefícios significativos em termos de produtividade, confiabilidade e facilidade de manutenção.Many-core pode ser um aplicativo matador que finalmente faz com que grandes corporações mudem, apesar dos grandes volumes de código legado. Além disso, mesmo grandes linguagens comerciais como C# estão assumindo um sabor funcional distinto como resultado de preocupações de muitos núcleos - efeitos colaterais simplesmente não se ajustam bem com simultaneidade e paralelismo.

Não concordo que programadores "normais" não entendam isso.Eles irão, assim como eventualmente entenderam OOP (que é tão misterioso e estranho, se não mais).

Além disso, a maioria das universidades ensina FP, muitas até o ensinam como o primeiro curso de programação.

Uau - esta é uma discussão interessante.Meus próprios pensamentos sobre isso:

FP torna algumas tarefas relativamente simples (em comparação com linguagens sem FP).As línguas sem FP já estão a começar a tirar ideias do FP, por isso suspeito que esta tendência continuará e veremos mais uma fusão que deverá ajudar as pessoas a dar o salto para o FP mais facilmente.

Não sei se vai pegar ou não, mas pelas minhas investigações, é quase certo que vale a pena aprender uma linguagem funcional e fará de você um programador melhor.Apenas entender a transparência referencial torna muitas decisões de design muito mais fáceis - e os programas resultantes são muito mais fáceis de raciocinar.Basicamente, se você se deparar com um problema, então ele tende a ser apenas um problema com a saída de uma única função, em vez de um problema com um estado inconsistente, que poderia ter sido causado por qualquer uma das centenas de classes/métodos/funções em uma linguagem imparativa com efeitos colaterais.

A natureza sem estado do FP mapeia mais naturalmente a natureza sem estado da web e, portanto, as linguagens funcionais se prestam mais facilmente a aplicativos da web RESTFUL mais elegantes.Compare com as estruturas JAVA e .NET que precisam recorrer a HACKS terrivelmente feios, como chaves VIEWSTATE e SESSION, para manter o estado do aplicativo e manter a abstração (ocasionalmente bastante vazada) de uma linguagem imperativa com estado, em uma plataforma funcional essencialmente sem estado como a web.

E também, quanto mais sem estado for seu aplicativo, mais facilmente ele poderá se prestar ao processamento paralelo.Extremamente importante para a web, se o seu site se tornar popular.Nem sempre é simples adicionar mais hardware a um site para obter melhor desempenho.

Minha opinião é que isso vai pegar agora que a Microsoft o empurrou ainda mais para o mainstream.Para mim é atraente pelo que pode fazer por nós, porque é um novo desafio e pelas oportunidades de trabalho que oferece para o futuro.

Uma vez dominado, será outra ferramenta que nos ajudará ainda mais a nos tornar mais produtivos como programadores.

Um ponto esquecido na discussão é que os melhores sistemas de tipos são encontrados nas linguagens FP contemporâneas.Além do mais, os compiladores podem inferir todos (ou pelo menos a maioria) dos tipos automaticamente.

É interessante que se gaste metade do tempo escrevendo nomes de tipos ao programar Java, mas Java de longe não é seguro para tipos.Embora você nunca possa escrever tipos em um programa Haskell (exceto como um tipo de documentação verificada pelo compilador) e o código seja 100% seguro para tipos.

Além das outras respostas, lançar a solução em termos funcionais puros obriga a compreender melhor o problema.Por outro lado, pensar em um estilo funcional desenvolverá melhores* habilidades de resolução de problemas.

*Ou porque o paradigma funcional é melhor ou porque permitirá um ângulo de ataque adicional.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top