Programação funcional em ascensão?

In which scenarios should I consider a functional programming languages better suited to do a given task? Besides the so recently popular multicore problem of parallel programming.

Qualquer coisa que envolva criar uma sequência de elementos de dados derivados usando várias etapas de transformação.

Essencialmente, o "problema da planilha". Você tem alguns dados iniciais e um conjunto de cálculos linha por linha para aplicar a esses dados.

Nossas aplicações de produção fazem uma série de resumos estatísticos de dados; tudo isso é melhor abordado funcionalmente.

Uma coisa comum que fazemos é uma mesclagem de correspondência entre três conjuntos de dados monstruosos. Semelhante a uma junção SQL, mas não tão generalizada. Isto é seguido por um número de cálculos de dados derivados. Isso tudo é apenas transformações funcionais.

O aplicativo é escrito em Python, mas é escrito em um estilo funcional usando funções geradoras e tuplas nomeadas imutáveis. É uma composição de funções de nível inferior.

Aqui está um exemplo concreto de uma composição funcional.

for line in ( l.split(":") for l in ( l.strip() for l in someFile ) ):
    print line[0], line[3]

Esta é uma maneira de a programação funcional influenciar linguagens como o Python.

Às vezes, esse tipo de coisa é escrito como:

cleaned = ( l.strip() for l in someFile )
split = ( l.split(":") for l in cleaned )
for line in split:
     print line[0], line[3]

If I decided to switch to a functional programming language which do you consider are the biggest pitfalls that I will face? (Besides the paradigm change and the difficulty to evaluate performance due to lazy evaluation).

Objetos imutáveis são o obstáculo mais difícil.

Geralmente, você acaba calculando valores que criam novos objetos em vez de atualizar objetos existentes. A ideia de que é um atributo mutável de um objeto é um hábito mental difícil de quebrar.

Uma propriedade derivada ou função de método é uma abordagem melhor. Objetos com estado são um hábito difícil de quebrar.

With so many functional programming languages out there, how would you choose the one the better suit your needs?

Não importa a princípio. Escolha qualquer idioma para aprender. Uma vez que você saiba de algo, você está em posição de escolher outro para melhor atender às suas necessidades.

Eu li sobre Haskell apenas para entender as coisas que o Python não tem.

"Funcional" é um conjunto de recursos diferentes, cada um dos quais é útil de forma independente, e acho mais útil analisar cada um individualmente.

Imutabilidade

Agora que estou familiarizado com ele, sempre que posso dar o retorno de um resultado imutável, sempre tento fazer isso, mesmo em um programa orientado a objetos. É mais fácil raciocinar sobre o programa se você tiver dados do tipo valor. Geralmente você precisa de mutabilidade para coisas como GUIs e gargalos de desempenho. Minhas entidades (usando o NHibernate) também são mutáveis (o que faz sentido porque eles estão modelando dados armazenados em um banco de dados).

funciona como tipos de primeira classe

O que você quiser chamar, passando por delegados, ações ou funções, é uma maneira realmente útil de resolver uma classe inteira de problemas do mundo real, como o "buraco no padrão do meio". Eu também descobri que passar um delegado, ação ou função para um objeto é mais limpo do que ter essa classe declarar um evento e enganchar esse evento (assumindo que normalmente há apenas um "ouvinte"). Quando você sabe que há um ouvinte, a ação de retorno de chamada pode ser passada como um parâmetro de construtor (e ser armazenada em um membro imutável!)

Ser capaz de compor funções (por exemplo, transformar Action<T> em apenas um Action também é bastante útil em alguns cenários.

Devemos também observar a sintaxe do Lambda aqui, porque você só obtém a sintaxe do Lambda quando promove funções para tipos de primeira classe. A sintaxe do Lambda pode ser muito expressiva e concisa.

Mônadas

Admito que esse é meu ponto fraco, mas meu entendimento é que fluxos de trabalho computacionais em F #, como async workflow, são mônadas. Esta é uma construção sutil, mas muito poderosa. É tão poderoso quanto a palavra-chave yield usada para criar IEnumerable classes em C #. Essencialmente, está construindo uma máquina de estado para você sob as cobertas, mas sua lógica parece linear.

Lazy Evaluation & Recursão

Eu coloquei tudo junto porque, embora eles sejam sempre incluídos como recursos de programação funcional, eles se direcionaram tão rapidamente para linguagens de outra forma imperativas, que é difícil chamá-las de funcionais.

Expressões S

Eu acho que não tenho certeza de onde colocar isso, mas a capacidade de tratar o código não compilado como um objeto (e inspecionar / modificá-lo), como o Lisp S-Expressions ou o LINQ Expressions, é algumas maneiras, a ferramenta mais poderosa de programação funcional. A maioria das novas interfaces "fluentes" do .NET e as DSLs usam uma combinação de sintaxe lambda e LINQ Expressions para criar APIs muito concisas. Sem mencionar o Linq2Sql / Linq2Nhibernate, onde o código C # é executado "magicamente" como SQL, em vez de código C #.

Essa foi a resposta longa para a primeira parte da sua pergunta ... agora ...

If I decided to switch to a functional programming language which do you consider are the biggest pitfalls that I will face? (Besides the paradigm change and the difficulty to evaluate performance due to lazy evaluation).

A maior dificuldade que enfrentei foi tentar encontrar a linha entre o uso de soluções funcionais e soluções imperativas. No entanto, depois de tentar as duas abordagens algumas vezes, você começa a ter uma ideia de qual funcionará melhor.

With so many functional programming languages out there, how would you choose the one the better suit your needs?

Se você estiver familiarizado com o .NET, eu sugiro F #. Por outro lado, se você estiver mais familiarizado com a JVM, sempre haverá Clojure . Se você é mais acadêmico do que prático, então eu vou com Common Lisp ou Scheme. Se você já conhece o Python, acredito que existem muitas construções funcionais já disponíveis.

And this has been the case for quite some time. Functional programming simply has not become as popular as other models (i.e object oriented programming).

Isto é verdade se você contar programas desenvolvidos por programadores profissionais (ou pelo menos pessoas que se vejam assim). Se você expandir sua rede para incluir programas desenvolvidos por pessoas que não se consideram assim, o FP (ou pelo menos programação em um estilo funcional) é muito próximo ao OO (Excel, Mathematica, Matlab, R ... até mesmo JavaScript 'moderno') ).

In which scenarios should I consider a functional programming languages better suited to do a given task? Besides the so recently popular multicore problem of parallel programming.

Minha opinião pessoal é que o multicore não é o recurso matador do FP (pelo menos até os compiladores Haskell, Scala, Clojure, F # resolverem o problema da localidade do cache). O recurso matador é map , filter , fold e amigos que permitem uma expressão mais sucinta de um grande grupo de algoritmos. Isso é composto por linguagens FP com uma sintaxe mais concisa do que a maioria das contrapartes OO populares.

Além disso, o FP estando mais próximo do modelo relacional reduz a incompatibilidade de impedância com o RDBMS ... o que é - novamente pelo menos para não-programadores - muito bom.

Além disso, quando você tem dificuldade em satisfazer os requisitos de "correção" - de uma forma que é difícil de testar (comum em computação científica / análise de dados grandes onde o objetivo é ficar desconhecido anteriormente e como resultados não especificáveis) FP pode oferecer vantagens.

If I decided to switch to a functional programming language which do you consider are the biggest pitfalls that I will face?

• falta de suporte a ferramentas (F # e alguns Lisps sendo a exceção, Scala está a caminho)
• difícil de extrair o último desempenho do seu hardware
• comunidades que geralmente se concentram em problemas diferentes daqueles enfrentados por um grande grupo de projetos de desenvolvimento de software comercial
• muito poucos desenvolvedores experientes no uso de FP em um ambiente industrial e, se você puder encontrá-los, provavelmente terá que competir com o salário e os benefícios que o setor financeiro pode oferecer
• o estilo funcional de programação tende a ser mais difícil de depurar; ou seja, observar entre resultados em uma longa cadeia de funções compostas geralmente não é possível na maioria (todos?) depuradores

With so many functional programming languages out there, how would you choose the one the better suit your needs?

• Quantos dos seus problemas podem ser resolvidos ao sair de bibliotecas / frameworks em qual plataforma (por exemplo, JVM ou .Net) quantos são novos? Existem construções de linguagem capazes de expressar esses problemas diretamente?

• Quanto controle de baixo nível você precisa sobre o desempenho de espaço e tempo de sua aplicação?

• Quão rigorosos são os requisitos de "correção"?

• Você tem recursos para treinar desenvolvedores e / ou competir com os benefícios oferecidos por alguns nichos altamente lucrativos no desenvolvimento de SW?

If I decided to switch to a functional programming language which do you consider are the biggest pitfalls that I will face? (Besides the paradigm change and the difficulty to evaluate performance due to lazy evaluation).

Supondo que você seja um desenvolvedor de C ++ / C # / Java na indústria ...

Esteja preparado para colegas rabugentos que não querem aprender nada. Esteja preparado para chefes de cabelos pontudos que imponham más escolhas de linguagem "porque eles já foram codificadores". Esteja preparado para acadêmicos vigorosos em fóruns patrocinadores sobre monóides. Esteja preparado para intermináveis guerras de linguagem porque o Scala não tem nem mesmo a eliminação da chamada e o Clojure realmente requer pedais para todos os parênteses e não me faça começar no Erlang.

Se você é um programador da Web, a maior armadilha provavelmente será seu cabelo.

With so many functional programming languages out there, how would you choose the one the better suit your needs?

Eu começaria com a plataforma:

• O OCaml é ótimo no Linux e terrível no Windows.
• O F # é ótimo no Windows e é péssimo no Linux.
• Scala e Clojure são ótimos na JVM.

Por uma perspectiva (reconhecidamente viciada) sobre essa questão, você pode conferir o blog de Bob Harper, Tipo Existencial . Carnegie Mellon recentemente reformulou seu currículo de ciências da computação para ensinar programação funcional em primeiro lugar, com outros paradigmas sendo ensinados apenas quando uma base sólida em programação funcional foi estabelecida, e Harper está dando um golpe quando o novo currículo é implementado na prática .

Harper é um dos principais desenvolvedores da linguagem de programação Standard ML, então é justo dizer que sua própria opinião sobre o assunto pode ser adivinhada com antecedência, e ele certamente não se esquiva de declarações controversas ao defender essa posição, mas ele faz bem o seu caso.

In which scenarios should I consider a functional programming languages better suited to do a given task? Besides the so recently popular multicore problem of parallel programming.

Não existe uma fórmula mágica que lhe diga quando usar a programação funcional. Não é como se a programação orientada a objetos fosse adequada às nossas atuais situações de programação. É apenas outra maneira de estruturar programas em termos de outro conjunto de abstrações.

If I decided to switch to a functional programming language which do you consider are the biggest pitfalls that I will face? (Besides the paradigm change and the difficulty to evaluate performance due to lazy evaluation).

A programação funcional não tem nada a ver com preguiça. ML e OCaml são linguagens funcionais e rigorosas. O maior obstáculo a ser enfrentado é estruturar as coisas em termos de valores imutáveis e dar uma olhada em qualquer abstração usada no sistema de tipos de efeitos colaterais. As linguagens funcionais são mais adequadas para otimização devido ao fato de tornarem os efeitos colaterais muito explícitos no sistema de tipos. Haskell usa monads, mas existem outras abordagens para usar efeitos em linguagens funcionais puras. Clean tem tipos de exclusividade e algumas outras linguagens em desenvolvimento têm outras coisas.

With so many functional programming languages out there, how would you choose the one the better suit your needs?

Entre as linguagens de programação que conheço, eu diria que apenas o Haskell e o Clean podem ser chamados de linguagens funcionais. Todos os outros permitem efeitos colaterais sem tornar esses efeitos explícitos no sistema de tipos. Então, se você vai dedicar tempo para aprender programação funcional, então Haskell é provavelmente o único que se encaixa no projeto. Todos os outros que eu conheço, Erlang, Scala, Clojure, etc. fornecem apenas abstrações funcionais em cima de uma linguagem imperativa. Então, se você quiser abordar o paradigma funcional em bits, então eu recomendo Scala ou Erlang e se você quiser resolver tudo de uma vez e possivelmente desistir de frustrações, então você deve ir com Haskell.

Eu atribuiria o aumento atual de interes em linguagens funcionais ao fato de serem ideais para computação paralela. Por exemplo, toda a ideia de map-reduce é baseada no paradigma funcional. E não há dúvida de que a computação paralela estará em alta, pois está claro que, atualmente, o scale-out é mais fácil e barato do que o scale-up. Mesmo em CPUs de mercado consumidor, obtém mais núcleos, não mais GHz.

EDIT: já que não é óbvio para todos.

Na programação funcional pura, uma função recebe entrada, produz saída e não tem efeitos colaterais. Sem efeito colateral, significa que não há estado compartilhado, portanto, não há necessidade de mecanismos de sincronização, que de outra forma seriam necessários durante a execução simultânea. A sincronização é a parte mais difícil de qualquer software concorrente / paralelo, tornando-a puramente funcional, você basicamente não tem que lidar com a parte mais difícil de todo.

Quanto ao map-reduce, até o nome vem da programação funcional (mapeamento e redução são operações típicas em paradigma funcional). Ambas as etapas de redução de mapa são funções, que são executadas em paralelo, recebem entrada, produzem saída e não têm efeito colateral. Então, essa é exatamente a ideia de programação funcional pura.

Alguns exemplos de FP usados para paralelismo:

• CouchDB - construído em Erlang
• Bate-papo no Facebook - criado em Erlang
• Twitter - grande parte do Scala