Por que linguagens funcionais? [fechadas]


332

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


John Hughes escreveu um artigo sobre isso: Por que a Programação Funcional é Importante .
Hjulle

Respostas:


214

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

Uma das maiores vantagens da programação funcional é que a ordem de execução das funções sem efeitos colaterais não é importante. Por exemplo, em Erlang, isso é usado para habilitar a simultaneidade de uma maneira 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 também era a falta de efeitos colaterais. É muito difícil escrever software útil sem E / S, mas é difícil implementá-lo 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. Nas linguagens modernas de paradigma misto, como F # ou Scala, isso é mais fácil.

Muitas linguagens modernas possuem elementos de linguagens de programação funcionais. O C # 3.0 possui muitos recursos de programação funcional e você também pode fazer programação funcional em Python. Penso que os motivos da 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 os idiomas estão ficando mais acessíveis.


14
Você PODE fazer programação funcional em python, mas é realmente terrível. stackoverflow.com/questions/1017621/…
Gordon Gustafson

28
É não difícil escrever código IO em linguagens funcionais puras. Todos eles fornecem um mecanismo simples para escrever código de E / S que funciona exatamente como em linguagens imperativas. Tudo o que eles fazem é impor que você não possa chamar código de E / S dentro de outro código cuja interface seja declarada como não executando E / S. Uma analogia seria um programador de linguagem dinâmica queixando-se de que uma linguagem de tipo estaticamente como Java dificultava o retorno do tipo que ela desejava de um método, porque ela precisava retornar o que a declaração de tipo dizia que retornaria.
Ben

9
Haskell é um exemplo de linguagem funcional pura, que não tem a desvantagem que você disse. Na verdade, torna muito mais fácil lidar com efeitos colaterais, porque os efeitos colaterais são encapsulados e permite que o programador alcance um nível de abstração muito mais poderoso do que as linguagens imperativas ... Realmente, todo mundo deveria tentar Haskell, realmente entender e perceber por que é tão poderoso.
FtheBuilder 9/03/16

202

Eu não acho que exista alguma dúvida sobre a abordagem funcional da programação "porque está em uso", porque ela está em uso (como um estilo de programação) há cerca de 40 anos. Sempre que um programador de OO escreve código limpo que favorece objetos imutáveis, esse código empresta conceitos funcionais.

No entanto, os idiomas que impõem um estilo funcional estão recebendo muita tinta virtual hoje em dia, e se esses idiomas se tornarão dominantes no futuro é uma questão em aberto. Minha própria suspeita é que linguagens híbridas de múltiplos paradigmas, como Scala ou OCaml , provavelmente dominem sobre linguagens funcionais "puristas" da mesma maneira que a linguagem OO pura (Smalltalk, Beta etc.) influenciou a programação convencional, mas ainda não terminou como as notações mais usadas.

Por fim, não consigo resistir ao apontar que seus comentários sobre FP são altamente paralelos às observações que ouvi de programadores de procedimentos há não muitos anos atrás:

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

Assim como interfaces gráficas de usuário e "código como modelo de negócios" foram conceitos que ajudaram o OO a ser mais amplamente apreciado, acredito que o aumento do uso da imutabilidade e o paralelismo mais simples (maciço) ajudarão mais programadores a ver os benefícios que a abordagem funcional oferece . Mas, tanto quanto aprendemos nos últimos 50 anos que compõem toda a história da programação de computadores digitais, acho que ainda temos muito a aprender. Daqui a 20 anos, os programadores olharão surpresos para a natureza primitiva das ferramentas que estamos usando atualmente, incluindo as agora populares OO e FP.


55
Basta olhar 20 anos atrás. Eu não acho que a programação tenha evoluído muito. Bem, temos ferramentas melhores, talvez um novo idioma ou 2, mas fundamentalmente pouco mudará. Isso levará mais de 20 anos. Nós todos pensavam que iria ver carros voadores em 2000. :)
bibac

32
O'Caml é irlandês.
defmeta

7
@alex strange: "Favor imutabilidade" e "evitar efeitos colaterais" são boas regras há bastante tempo nas escolas de programação imperativa e orientada a objetos. (Então, o que há para não gostar ;-)?
joel.neely

101
@bibac: há 20 anos, estávamos escrevendo código C e discutindo os méritos do Clipper ou do Turbo Pascal. A Orientação a Objetos era o domínio exclusivo dos acadêmicos. Propor que pouco mudou é absolutamente absurdo.
227 Daniel C. Sobral

24
@ Daniel: Por favor, forneça uma lista dessas pessoas que defenderam os "méritos" do Clipper. Eles precisam ser caçados e levados à justiça.
David David

125

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

Eu não acho que ele 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 precisamos escrever parte do nosso código em uma linguagem funcional ou nossas linguagens de uso geral crescer para incluir construções mais funcionais.


4
Já estamos vendo isso acontecendo. E isso vai acontecer mais no futuro. Então, eu concordo 100% sobre este ponto.
Jason Baker

O mais complicado é que são os aspectos de nada / nenhum efeito colateral do FP que o tornam tão adequado para o paralelismo. E esses são os aspectos que não se encaixam bem nas soluções OO - tornar os híbridos eficazes é extremamente difícil. Talvez cola FP entre nós OO?
James Brady

Para um híbrido eficaz, dê uma olhada no ramo 2.0 da linguagem de programação D. É um alfa / trabalho em andamento, mas está chegando lá.
dsimcha

2
Achei esta resposta interessante, não conheço nenhuma linguagem funcional, por que são consideradas mais adequadas ao paralelismo?
andandandand 27/01/09

26
Como não há dados compartilhados, as funções não têm efeitos colaterais. Tudo o que importa é o valor de retorno. (Essa é uma ideia bastante difícil para um programador de OO / procedimental.
Tom Smith

79

Mesmo que você nunca trabalhe profissionalmente em uma linguagem funcional, entender a programação funcional fará de você 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.

Eu acho que as linguagens que fazem um bom trabalho ao misturar estilo funcional e imperativo são as mais interessantes e com maior probabilidade de sucesso.


Bom ponto, mas eu gostaria de ver uma explicação de "de que maneira ele vai fazer você um programador melhor"
MT3

20
Diferentes paradigmas de programação abordam problemas de diferentes ângulos e geralmente exigem uma "maneira diferente de pensar" ou mentalidade. E treinar-se de várias maneiras diferentes de pensar (implicando aprender qual usar em que situação ...) nunca é uma coisa ruim.
peSHIr

56

Eu sou sempre cético sobre a próxima grande coisa. Muitas vezes o Next Big Thing é puro acidente da história, estando lá no lugar certo, no momento certo, independentemente de a tecnologia ser boa ou não. Exemplos: C ++, Tcl / Tk, Perl. Todas as tecnologias defeituosas, todas muito bem-sucedidas, porque foram percebidas como para resolver os problemas do dia ou para serem quase idênticas aos padrões estabelecidos, ou a ambos. A programação funcional pode realmente ser ótima, mas isso não significa que será adotada.

Mas posso dizer por que as pessoas estão empolgadas com a programação funcional: muitos programadores tiveram uma espécie de "experiência de conversão" na qual descobrem que usar uma linguagem funcional as torna duas vezes mais produtivas (ou talvez dez vezes mais produtivas) enquanto produzem código mais resistente a alterações e com menos bugs. Essas pessoas pensam na programação funcional como uma arma secreta; Um bom exemplo dessa mentalidade é Beating the Averages, de Paul Graham . Ah, e sua aplicação? Aplicativos da web de comércio eletrônico.

Desde o início de 2006, também houve alguns rumores sobre programação funcional e paralelismo. Como pessoas como Simon Peyton Jones preocupam-se com o paralelismo desde 1984, pelo menos, não prendo a respiração até que as linguagens funcionais resolvam o problema multicore. Mas isso explica alguns dos burburinhos adicionais agora.

Em geral, as universidades americanas estão fazendo um mau trabalho no ensino de programação funcional. Há um forte núcleo de suporte para o ensino de programação de introdução usando o Scheme , e Haskell também conta com algum suporte, mas há muito pouco no ensino de técnicas avançadas para programadores funcionais. Eu 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 fazendo um trabalho muito melhor; por exemplo, a programação funcional é enfatizada em locais importantes na Dinamarca, Holanda, Suécia e Reino Unido. Eu tenho menos noção do que está acontecendo na Australásia.


Eu não sei sobre as universidades do Reino Unido. É provável que você descubra que muitas universidades aqui ensinam muito poucas linguagens de programação (Java, C, talvez Perl, se tiver sorte). O problema aqui é a diferença de qualidade, pois as melhores (poucas) universidades têm os melhores programas de CS.
Mike B

Discordo que os exemplos que você deu são falhos, talvez de nicho ou adequados para determinadas áreas, mas com objetivos gerais suficientes para serem aceitos universalmente sem uma curva de aprendizado maciça. essa é provavelmente a maior razão pela qual eles são tão bem-sucedidos.
gbjbaanb 5/01/09

Eu fiz Forth e Lisp em uni no Reino Unido (assim como Pascal, C, Modula-2 e Cobol), mas isso foi há 20 anos ..
kpollock

29
Fui ensinado Java / C ++ na uni (na Austrália), mas alguns de meus colegas de trabalho foram para universidades diferentes, onde fizeram várias unidades em Haskell. Foi usado tanto para introdução à programação quanto em uma de suas unidades finais do ano. Eu ri quando ouvi o que meu colega de trabalho disse a um professor de Java depois que ele foi apresentado à seleção de elenco pela primeira vez (neste momento ele só conhecia Haskell) - "O quê ?! Você quer dizer que você tem algo e não sabe" t KNOW que tipo é ?!"
23339 Jacob Stanley

1
Olhe o que aconteceu com C # com todos os europeus na equipe :)
Benjol

32

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 o JS, especialmente aproveitando os pontos mais refinados do jQuery, Dojo e outras estruturas, o FP será introduzido pela porta traseira do desenvolvedor da web.

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

Saúde, PS


2
Foi assim que eu realmente comecei a cavar programação funcional. Nada é melhor que a lista de Prototype.js. Cada método (function (item) {}) ou todo o método de operação do jQuery.
Cory R. King

20
Javascript permite programar de forma funcional. É, no entanto, uma linguagem entre paradigmas, permitindo programar de várias maneiras diferentes (o que eu prefiro, mas isso não é relevante) ... OO, funcional, processual etc.
RHSeeger


Os métodos do objeto jQuery são apenas operações na mônada da lista. Tomar um objeto que representa um contêiner (ou sequência) como entrada e retornar um contêiner de objeto como saída é um bom exemplo de uma reinvenção prática do fmap.
Jared Updike

25

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

  1. As maneiras de OO 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 no Lisp (substitua a programação funcional pelo Lisp):

Portanto, a breve explicação de por que essa linguagem dos anos 50 não é obsoleta é que não era tecnologia, mas matemática, e a matemática não fica obsoleta. O certo para comparar o Lisp não é o hardware da década de 1950, mas, digamos, o algoritmo Quicksort, que foi descoberto em 1960 e ainda é o tipo mais rápido de uso geral.


25

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

  • Fórmulas do Excel
  • Compositor de quartzo
  • Javascript
  • Logotipo (gráficos da tartaruga)
  • LINQ
  • SQL
  • Underscore.js (ou Lodash), D3

10
Como o Javascript é considerado programação funcional?
Pacerier

8
Possui funções de primeira classe, funções de ordem superior, fechamentos, funções anônimas, aplicação parcial, currying e composição.
daniel1426

2
Haha Uma vez escreveu uma fórmula do Excel de reembolso de carga que era mais larga que a tela com funções aninhadas. Eu meio que sabia que estava programando funcionalmente, mas ainda não conhecia o termo.
ProfK

7
Por favor, adicione C a essa lista
Mandeep Janjua

2
@MandeepJanjua: Hein? Por quê? Ou por que não qualquer idioma então?
Sz.

18

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

Essa é apenas uma questão de tempo. Seu programador corporativo médio aprende qualquer que seja a grande coisa atual. Há 15 anos, eles não entendiam POO. Se o FP persistir, seus "programadores corporativos médios" seguirão.

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

Varia muito. Na minha universidade, o SML é a primeira língua para a qual os alunos são apresentados. Eu acredito que o MIT ensina o LISP como um curso do primeiro ano. Esses dois exemplos podem não ser representativos, é claro, mas acredito que a maioria das universidades, no mínimo, oferece alguns cursos opcionais sobre FP, mesmo que não o tornem uma parte obrigatória do currículo.

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

Não é realmente uma questão de "simples o suficiente". Uma solução seria mais simples (ou mais legível, robusta, elegante, com desempenho) no FP? Muitas coisas são "simples o suficiente para serem resolvidas em Java", mas ainda exigem uma quantidade enorme de código.

De qualquer forma, lembre-se de que os defensores da PF alegaram que era a Próxima Grande Coisa há várias décadas. Talvez eles estejam certos, mas lembre-se de que não estavam quando fizeram a mesma reivindicação há 5, 10 ou 15 anos.

Uma coisa que definitivamente conta a seu favor, porém, é que, recentemente, o C # deu uma guinada acentuada em relação ao FP, na medida em que praticamente transforma uma geração de programadores em programadores de FP, sem que eles percebam . Isso pode apenas abrir o caminho para a "revolução" do FP. Talvez. ;)


O MIT costumava ensinar Scheme em seu curso de introdução à CS, mas agora usa Python.
Mipadi

1
"15 anos atrás, eles não entendiam OOP" - O problema é que há 15 anos eles também não entendiam FP. E eles ainda não o fazem hoje.
Jason Baker

15

O homem não pode entender a perfeição e as imperfeições de sua arte escolhida se não puder ver o valor em outras artes. Seguir as regras apenas permite o desenvolvimento até um ponto na técnica e, em seguida, o aluno e o artista precisam aprender mais e procurar mais. Faz sentido estudar outras artes, bem como as de estratégia.

Quem não aprendeu algo mais sobre si mesmo observando as atividades dos outros? Para aprender a espada, estude o violão. Para aprender o primeiro estudo sobre comércio. Apenas estudar a espada fará com que você tenha uma mente estreita e não permita que você cresça para fora.

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


12

Um recurso importante em uma linguagem funcional é o conceito de funções de primeira classe. A idéia é que você pode 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 para uma função produzam o mesmo resultado. Você pode escrever código funcional em qualquer idioma que suporte funções de primeira classe, mas existem alguns idiomas, 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.

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

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


12

Eu não acho que a maioria das pessoas realistas ache que a programação funcional vai pegar (se torna o principal paradigma como o OO). Afinal, a maioria dos problemas de negócios não são problemas matemáticos, mas regras imperativas e peludas 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 pura (a curva de aprendizado da mônada excede em muito o OO).

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

Faz de você um ser mais consciente.


6
Não acho que o OO seja inerentemente mais fácil que o FP. Realmente depende do seu passado (sou um cara de matemática, adivinhe o que acho mais fácil? :) Maldito seja o pessoal do OO e suas regras insanas.
Temp2290 03/11/2009

14
Mônadas não são difíceis de entender. Não compre essa merda.
Rayne

-1 OOP é mais difícil que FP
apenas alguém

-1 Não escreveríamos otimizadores de compilação usando OCaml ou Haskell se o FP fosse apropriado apenas para problemas de matemática.
Graco

8

Eu devo ser densa, mas ainda não entendo. Existem exemplos reais de aplicativos pequenos escritos em uma linguagem funcional como F #, na qual você pode ver o código-fonte e ver como e por que era melhor usar essa abordagem do que, digamos, C #?


Boa observação +1. @ Mendelt: "mais acessível"? Você quer dizer que a dor de cabeça é mais rápida quando você assiste o código?
Patrick Honorez

2
Consulte esta biblioteca do F #: quanttec.com/fparsec/tutorial.html . Eu adoraria ver código de exemplo em C # com analisadores que pareciam metade da elegância e legibilidade que o código F #, mesmo que sejam compilados com as mesmas instruções. E tente portar o FParsec de F # para C # e veja como o código incha.
precisa

8

Eu apontaria que tudo o que você disse sobre linguagens funcionais, a maioria das pessoas estava dizendo sobre idiomas orientados a objetos há cerca de 20 anos. Naquela época, era muito comum ouvir sobre 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 terem a opinião de 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?


2
* O programador corporativo médio, por exemplo, a maioria das pessoas com quem trabalho, não o entenderá e a maioria dos ambientes de trabalho não permitirá que você programe - Isso ainda é verdade no OOP em muitos lugares em que trabalhei :) (é claro que eles dizem eles estão fazendo OOP, mas eles não são)
tolanj

7

O F # pode pegar porque a Microsoft está pressionando.

Pró:

  • O F # fará parte da próxima versão do Visual Studio
  • A Microsoft está construindo a comunidade já há algum tempo - evangelistas, livros, consultores que trabalham com clientes de alto nível, exposição significativa em conferências da MS.
  • O 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 não são tão completas quanto .Net é)
  • Forte apoio ao paralelismo

Contra:

  • É muito difícil iniciar o F #, mesmo se você é 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 ao F # se tornar importante. Outras linguagens funcionais não chegarão ao futuro próximo.


6
Eu argumentaria que Scala era uma base bastante profunda com o JRE.
Cdmckay

2
Em relação às bibliotecas, isso realmente depende do que você está fazendo. O F # é voltado para o setor financeiro e também é aplicável à computação científica, mas o OCaml realmente tem bibliotecas muito melhores para esses aplicativos que o .NET. Por exemplo, quando cheguei ao OC # no F #, não consegui encontrar um FFT decente e acabei escrevendo (e vendendo) o meu em C # e depois em F #.
Jon Harrop

1
LINQ é uma boa ponte para usando conceitos funcionais com C # e VB.Net ... E eu acho que ele seja muito menos doloroso para ler quando comparado com F #
Matthew Whited

5

Penso que um dos motivos é que algumas pessoas acham que a parte mais importante da aceitação de um idioma é a qualidade do idioma . Infelizmente, as coisas raramente são tão simples. Por exemplo, eu argumentaria que o maior fator por trás da aceitação do Python não é a própria linguagem (embora isso seja 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.

Idiomas como Clojure ou F # podem ser uma exceção à regra, considerando que eles são criados na JVM / CLR. Como resultado, não tenho uma resposta para eles.


+1, mas não se esqueça do poder do marketing e do fato de o código legado da sua empresa não mudar de idioma em virtude de alguma nova tendência interessante.
temp2290

E você esqueceu de mencionar: o Google está popularizando o python.
Hao Wooi Lim 31/03/09

4

A maioria das aplicações pode ser resolvida em [insira seu idioma, paradigma favorito etc. etc.].

Embora isso seja verdade, diferentes ferramentas podem ser usadas para resolver problemas diferentes. O funcional apenas permite outra abstração de alto nível (mais alto?) Que permite realizar nossos trabalhos com mais eficiência quando usada corretamente.


4

Parece-me que as pessoas que nunca aprenderam Lisp ou Scheme na graduação agora estão descobrindo isso. Tal como acontece com muitas coisas neste campo, existe uma tendência a 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í.

Acho que o que resultará disso é mais capacidade entre idiomas - por exemplo, implementar coisas em uma linguagem funcional e, em seguida, dar acesso a essas coisas em outras línguas.


1
Agora, o C # é uma linguagem de programação funcional (tanto quanto o Lisp) porque possui fechamentos lexicais de primeira classe. De fato, eles já são usados ​​no WPF e no TPL. Portanto, a programação funcional já está obviamente aqui.
Jon Harrop


3

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

E com o hardware massivamente paralelo colocando pressão evolucionária sobre todos - e as linguagens funcionais no melhor lugar para lidar com as mudanças - não é tão longe quanto era antes pensar que Haskell ou F # serão a próxima grande novidade.


3

Você tem acompanhado a evolução das linguagens de programação ultimamente? Cada nova versão de todas as linguagens de programação convencionais 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 características exóticas conhecidas apenas pelos hackers Lisp e ML. Porém, gradualmente, C #, Delphi, Python, Perl, Javascript adicionaram suporte a fechamentos. Não é possível que qualquer linguagem promissora seja levada a sério sem fechamento.

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

  • A ML foi pioneira 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 cinco anos. Se bem me lembro, o Fortran deu suporte a genéricos em 2003, seguido pelo Java 2004, C # em 2005 e Delphi em 2008. (Eu sei que o C ++ suporta modelos desde 1979, mas 90% das discussões sobre o STL do C ++ começam com "aqui existem demônios" .)

O que torna esses recursos atraentes para os programadores? Deve ser claramente óbvio: ajuda os programadores a escrever um código mais curto . Todos os idiomas no futuro apoiarão, no mínimo, o fechamento, se quiserem permanecer competitivos. A esse respeito, a programação funcional já está no mainstream.

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

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




2

Eu concordo com o primeiro ponto, mas os tempos mudam. As empresas responderão, mesmo que sejam adotantes tardias, se perceberem que há uma vantagem a ser obtida. A vida é dinâmica.

Eles estavam ensinando 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 "exponha bancos de dados relacionais na Web" continuará nesse sentido por muito tempo. Java EE, .NET, RoR e PHP desenvolveram algumas soluções muito boas para esse problema.

Você alcançou algo importante: pode ser o problema que não pode ser resolvido facilmente por outros meios que aumentem a programação funcional. O que seria aquilo?

O hardware multicore maciço e a computação em nuvem os impulsionarão?


2

Porque o FP tem benefícios significativos em termos de produtividade, confiabilidade e manutenção. Muitos núcleos podem ser um aplicativo matador que finalmente faz com que as grandes empresas mudem, apesar de grandes volumes de código herdado. não se encaixam bem com concorrência e paralelismo.

Não concordo que programadores "normais" não o entendam. Eles entenderão, assim como acabaram entendendo OOP (que é igualmente misterioso e estranho, se não mais).

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


Desculpe, mas o FP tem sido quase três vezes mais que OOP. Isso simplesmente não é uma questão de precisar de mais tempo. É preciso algo mais para tornar o FP mainstream.
Jason Baker

Como você pôde perder a parte do meu post, onde eu explico que o "algo a mais" poderia muito bem ter muitos núcleos? E algo "estar por perto" não é realmente relevante. As pessoas entendiam OOP porque, na época, oferecia benefícios tangíveis, o FP se tornou prático apenas recentemente.
Sebastian

2

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

O FP torna algumas tarefas relativamente simples (em comparação com idiomas não FP). As linguagens sem FP já estão começando a receber idéias do FP, então eu suspeito que essa tendência continuará e veremos mais uma fusão que deve ajudar as pessoas a facilitar o salto para o FP.


2

Eu não sei se ele vai pegar ou não, mas pelas minhas investigações, uma linguagem funcional quase certamente vale a pena aprender, e fará de você um programador melhor. Apenas o entendimento da transparência referencial facilita muito as decisões de design - e os programas resultantes são muito mais fáceis de raciocinar. Basicamente, se você encontrar um problema, 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 imparcial com efeitos colaterais.

A natureza apátrida do FP mapeia de maneira mais natural à natureza apátrida da web e, portanto, as linguagens funcionais se prestam mais facilmente a aplicativos da web RESTFUL mais elegantes. Contraste com as estruturas JAVA e .NET que precisam recorrer a HACKS horrivelmente feios, como as teclas 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 apátrida for sua aplicação, mais facilmente ela poderá ser processada em paralelo. Muito importante para a web, se o seu site ficar popular. Nem sempre é fácil adicionar mais hardware a um site para obter melhor desempenho.


2

Meu ponto de vista é que ele continuará assim que a Microsoft forçou muito mais o mainstream. Para mim, é atraente pelo que pode fazer por nós, porque é um novo desafio e pelas oportunidades de emprego em que se ressente para o futuro.

Uma vez dominada, será outra ferramenta para ajudar a tornar-nos mais produtivos como programadores.


2

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

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


1

Além das outras respostas, lançar a solução em termos funcionais puros obriga a entender 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 oferece um ângulo de ataque adicional.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.