Devo aprender Haskell ou F # se eu já sei OCaml? [fechadas]

Question

Eu estou querendo saber se eu deveria continuar a aprender OCaml ou mudança para F # ou Haskell.

Aqui estão os critérios que eu estou mais interessado em:

• Longevidade

  • Em que língua vai durar mais tempo? Eu não quero aprender algo que pode ser abandonado em um par de anos por usuários e desenvolvedores.
  • Will Inria, Microsoft, Universidade de Glasgow continuar a apoiar seus respectivos compiladores para o longo prazo?

• Praticidade

  • este me faz medo de usar Haskell. Uma tabela hash é a melhor estrutura para recuperação rápida. proponentes Haskell lá sugerir o uso de Data.Map que é uma árvore binária.
  • Eu não gosto de estar preso a um framework .NET volumosos menos que os benefícios são grandes.
  • Eu quero ser capaz de desenvolver mais de analisadores e programas de matemática apenas.

• Bem Projetado

  • eu como os meus idiomas para ser coerente.

Por favor, apoiem a sua opinião com argumentos lógicos e citações de artigos. Obrigado.

Answer 1

Longevidade

• Haskell é de facto a língua dominante da pesquisa funcional de programação. Haskell 98 vai durar por muitos mais anos de forma estável, e algo chamado Haskell pode durar 10 a 30 anos --- embora a língua continuará a evoluir. A comunidade tem um grande investimento em Haskell e mesmo se os principais desenvolvedores GHC é atingido por um ônibus amanhã (o famoso "erro de ônibus em Cambridge" problema), há uma abundância de outros que pode pisar até a placa. Há também outros, compiladores menos elaborados.

• Caml é controlada por um pequeno grupo no INRIA, o laboratório nacional francês. Eles também têm um investimento significativo, outros também são investidos em Caml, eo código fonte é aberto, eo compilador não é muito complicado, de modo que também será mantido por um longo tempo. Prevejo Caml será muito mais estável do que Haskell, como as pessoas INRIA parecem não estar usando-o como um veículo para explorar novas idéias de linguagem (ou pelo menos eles estão fazendo isso em um ritmo menor do que no passado).

• Quem sabe o que a empresa vai fazer? Se F # for bem sucedida, a Microsoft poderia apoiá-lo por 20 anos. Se não for bem sucedido, eles poderiam puxar o plugue em 2012. Eu não posso adivinhar e não vai tentar.

Praticidade

Uma tabela hash é a melhor estrutura para recuperação rápida. proponentes Haskell lá sugerir o uso de Data.Map que é uma árvore binária.

Depende do que você está procurando. Quando as chaves são strings, ternário procurar árvores são muitas vezes mais rápido do que tabelas de hash. Quando as chaves são inteiros, Okasaki e Gill binário árvores Patricia são competitivos com hashing. Se você realmente quiser, você pode construir uma tabela hash em Haskell usando o IO mônada, mas é raro necessidade de.

Eu acho que sempre haverá uma penalidade de desempenho para avaliação preguiçosa. Mas "prática" não é o mesmo como "o mais rápido possível". A seguir são verdadeiras sobre o desempenho:

• É mais fácil prever o tempo e espaço comportamento de um programa Caml.

• F # está no meio (que realmente sabe o .NET e o JIT vai fazer?).

• É mais difícil de prever o tempo e espaço comportamento de programas Haskell.

• Haskell tem as melhores ferramentas de perfil, e, a longo prazo, isso é o que produz o melhor desempenho.

Eu quero ser capaz de desenvolver mais de analisadores e programas de matemática apenas.

Para ter uma ideia da gama do que é possível em Haskell, confira o xmonad gerenciador de janelas e vastas ofpackages matriz em hackage.haskell.org .

Eu não gosto de estar preso a um framework .NET volumosos menos que os benefícios são grandes.

Não posso comentar:

Bem Projetado

Eu gosto de meus idiomas para ser coerente.

Alguns pontos em que para avaliar a consistência:

• sintaxe concreta de Haskell é extremamente bem concebido; Estou continuamente impressionado com o bom trabalho feito pela comissão de Haskell. sintaxe OCaml é OK, mas sofre por comparação. F # iniciada a partir de Caml sintaxe núcleo e tem muitas semelhanças.

• Haskell e OCaml ambos têm histórias muito consistentes sobre a sobrecarga de operador. Haskell tem um mecanismo consistente e poderosa que você pode estender-se. OCaml tem nenhuma sobrecarga de qualquer tipo.

• OCaml tem amais simples sistema de tipo, especialmente se você fizer objetos não escrever e functors (que muitos programadores Caml não, embora pareça loucura para mim não functors gravação se você estiver escrevendo ML). sistema de tipo de Haskell é ambicioso e poderoso, mas está continuamente a ser melhorado, o que significa que há alguma inconsistência, como resultado da história. F # utiliza essencialmente o sistema de tipo .NET, além de ML-como polimorfismo Hindley-Milner (ver Pergunta "O que é Hindley -Milner ".)

• OCaml não é bastante consistente sobre se pensa variantes deve ser digitado estaticamente ou dinamicamente digitado, por isso oferece ambos ( "tipos de dados algébricos" e "variantes polimórficas"). A linguagem resultante tem um monte de poder de expressão, que é ótimo para especialistas, mas que constroem a utilização nem sempre é óbvio para o amador.

• ordem de avaliação de OCaml é oficialmente indefinido, que é uma escolha de design pobre em uma linguagem com efeitos colaterais. Pior, as implementações são inconsistentes:. A máquina virtual bytecoded usa uma ordem e o compilador de código nativo usa o outro

Answer 2

Se você aprender F # ou Haskell se você sabe OCaml?

Creio que a resposta é certamente sim, idealmente você deve aprender todas as três línguas, porque cada um tem algo a oferecer, mas F # é o único com um futuro significativa assim, se você só puderem aprender um idioma, aprender F # através da leitura meu Visual F # 2010 para Computação Técnica livro ou subscrever a nossa A F # .NET Jornal .

Longevidade

Microsoft empenhada em apoiar F # quando lançou como parte do Visual Studio 2010 em abril. Então F # é garantido um futuro róseo para pelo menos alguns anos. Com uma poderosa combinação de características praticamente-importantes, como um alto desempenho REPL-código nativo, construções de alto nível para paralelismo embutido para .NET um modo IDE de qualidade de produção 4 e, F # é uma longo muito à frente de qualquer outra linguagem de programação funcional em termos de aplicabilidade no mundo real agora. Francamente, ninguém está mesmo trabalhando em qualquer coisa que possa ser capaz de competir com F # no futuro próximo. Meu próprio código aberto HLVM projeto é uma tentativa de fazê-lo, mas ele está longe de ser pronto.

Em contraste, tanto OCaml e Haskell estão sendo desenvolvidos em direções extremamente improdutivas. Este foi matando OCaml há vários anos e espero Haskell a seguir o exemplo ao longo dos próximos anos. A maioria dos ex-programadores OCaml e Haskell profissionais já mudou-se para F # (por exemplo, Credit Suisse, Voar Sapo Consultancy) ea maioria do resto, sem dúvida, de migração para alternativas mais práticas, tais como Clojure e Scala no futuro próximo.

Especificamente, de OCaml QPL impede licença ninguém de fixação de seu crescente número de falhas fundamentais de design (String 16Mb e limites da matriz em máquinas de 32 bits, não paralelismo de memória compartilhada, há tipos de valor, polimorfismo paramétrico via eliminação de tipo, interpretado REPL , complicado FFI etc.), porque eles devem distribuir trabalhos derivados única na forma de patches para o original e os mantenedores de pacotes Debian se recusam a reconhecer um montante alternativa. As novas funcionalidades sejam adicionadas à linguagem, tais como módulos de primeira classe em OCaml 3,12, estão longe de ser tão valiosa como a capacidade multicore teria sido.

Alguns projetos foram iniciados em uma tentativa de salvar OCaml, mas eles provaram ser um pouco tarde demais. A paralelo GC é praticamente inútil e David Teller sair do baterias incluídas projeto (embora tenha sido pego e lançado em um corte-down forma). Consequentemente, OCaml deixou de ser a linguagem funcional mais popular em 2007 para severo declínio hoje, com caml- lista de tráfego para baixo mais de 50% desde 2007 .

Haskell tem menos usuários industriais do que OCaml e, embora não têm suporte multicore, ainda está sendo desenvolvido em uma direção muito improdutivo. Haskell é desenvolvido quase que inteiramente por duas pessoas no Microsoft Research em Cambridge (UK). Apesar do fato de que a programação puramente funcional é ruim para o desempenho, design, eles estão continuando a tentar desenvolver soluções para Haskell paralelo que visam multicores quando as quantidades maciças de desnecessária copiá-lo incorre sucessos parede da memória e destrói qualquer esperança de paralelismo escalável em um multicore.

A única grande usuário de Haskell na indústria é Galois com cerca de 30 em tempo integral programadores de Haskell. Eu duvido que eles vão deixar Haskell morrer completamente, mas isso não significa que eles vão desenvolvê-lo em uma linguagem mais geral-útil.

Praticidade

Eu escrevi o artigo que você citou sobre tabelas de hash. Eles são uma boa estrutura de dados. Outras pessoas têm referido alternativas puramente funcionais, como árvores ternários e árvores Patricia mas estes são geralmente ~ 10 × mais lento do que tabelas hash em prática. A razão é simplesmente que falta de cache questões de desempenho dominam hoje e árvores incorrer em um O adicional (log n) indireções ponteiro.

A minha preferência pessoal é para a preguiça opcional e pureza opcional porque ambos são geralmente contra produtivo no mundo real (por exemplo, a preguiça faz desempenho e consumo de memória descontroladamente imprevisível e pureza diminui muito o desempenho do caso médio e faz interoperabilidade um pesadelo). Eu sou uma das únicas pessoas que ganham a vida inteiramente de programação funcional através da minha própria empresa. Basta dizer que, se eu achava Haskell eram viáveis ??eu teria diversificado em que anos atrás, mas eu continuo escolhendo não, porque eu não acredito que seja comercialmente viável.

Você disse "eu não gosto de ser amarrado a uma estrutura volumosa .NET menos que os benefícios são grandes". Os benefícios são enormes. Você ganha um IDE de qualidade de produção, um compilador JIT de qualidade de produção que executa otimizações extremamente eficazes como os genéricos-especializado tipo, bibliotecas com qualidade de produção para tudo, desde a programação GUI (veja jogo da vida em 32 linhas de F # ) para processamento de números. Mas o benefício real da NET, pelo menos para mim, é que você pode vender as bibliotecas que você escrever em F # e ganhar muito dinheiro. Ninguém jamais conseguiu bibliotecas de venda para programadores OCaml e Haskell (e eu sou uma das poucas pessoas que têm tentado), mas F # bibliotecas já vendida em quantidades significativas. Assim, o quadro volumosos .NET vale a pena se você quiser ganhar a vida escrevendo software.

Bem concebido

Estas línguas são todos bem concebido, mas para diferentes fins. OCaml é projetado especificamente para provadores de teoremas escrita e Haskell é projetado especificamente para a pesquisa de Haskell. F # foi projetado para atender todos os mais graves problemas práticos com OCaml e Haskell como fraca interoperabilidade, a falta de coleta de lixo simultânea e falta de amadurecer bibliotecas modernas como WPF, a fim de trazer uma linguagem moderna produtivo para um grande público.

Answer 3

Este não era um de seus critérios, mas você já pensou disponibilidade trabalho ? Haskell listar atualmente 144 empregos no fato, lista Ocaml 12 e C # lista de 26.000. Estes números não são perfeitos, mas eu aposto que você que uma vez que F # navios que não será muito antes que sopra passado Haskell e OCaml no número de anúncios de emprego.

Até agora, cada linguagem de programação incluídas no Visual Studios tem milhares de anúncios de emprego para ele. Parece-me que, se você quer a melhor chance de usar uma linguagem de programação funcional como seu trabalho do dia, em seguida, F #, em breve seja.

Answer 4

Longevidade

Ninguém pode prever o futuro, mas

• OCaml e Haskell foram surving bem para um número de anos, o que é um bom augúrio para o futuro
• quando F # vem com o VS2010, MS terá obrigações legais para apoiá-lo por pelo menos 5 anos

Praticidade

Perf: eu não tenho bastante experiência em primeira mão com Haskell, mas com base em segunda mão e informações de terceira mão, acho que OCaml ou F # são mais pragmática, no sentido de que eu acho que é improvável que você' vai ser capaz de obter o mesmo perf de tempo de execução em Haskell que você faz em OCaml de F #.

Bibliotecas: Fácil acesso à Framework .Net é um benefício enorme de F #. Você pode vê-lo como sendo "amarrado a essa coisa volumosa" se quiser, mas não se esqueça de que "você tem acesso a uma enorme biblioteca volumosa de coisas muitas vezes extremamente útil". O 'conectividade' a Net é um dos grandes pontos de venda para F #. F # é mais jovem e por isso tem menos bibliotecas de terceiros, mas já existe, por exemplo, FsCheck , FParsec , Falso , e um monte de outros, em além das bibliotecas "na caixa" na Net.

Tooling: eu não tenho experiência pessoal suficiente para comparar, mas acho que a integração VS com F # é superior a qualquer coisa que você vai encontrar para OCaml / Haskell hoje (e F # vai continuar a melhorar um pouco aqui durante o próximo ano).

Alterar: F # ainda está mudando à medida que se aproxima do seu primeiro lançamento apoiado no VS2010, por isso há algumas alterações significativas à linguagem / biblioteca que você pode ter de suportar no futuro próximo.

Bem Projetado

Haskell é definitivamente bonito e consistente. Eu não sei o suficiente OCaml, mas meu palpite é que é semelhante atraente. Eu acho que F # é 'maior' do que qualquer um daqueles, que meios cantos mais empoeirados e inconsistências (em grande parte como resultado de mediar a incompatibilidade de impedância entre FP e .Net), mas no geral F # ainda se sente 'clean' para mim, e o inconsistências que existem são pelo menos bem-fundamentado / intencionado.

No geral

Na minha opinião, você estará em 'boa forma' saber qualquer um dos três idiomas também. Se você conhece um grande projeto de longo prazo que você quer usá-lo para, pode-se destacar, mas acho que muitas das habilidades serão transferíveis (mais facilmente entre F # e OCaml do que de / para Haskell, mas também mais facilmente entre qualquer destes três do que com, digamos, Java).

Answer 5

Não há uma resposta simples para essa pergunta, mas aqui estão algumas coisas a considerar:

Haskell e OCaml são ambas as línguas maduros com implementações fortes. Na verdade, existem vários bons implementações de Haskell, mas eu não acho que é um ponto importante a seu favor para o seu propósito.

F # é muito mais jovem, e quem pode prever onde a Microsoft vai decidir levá-lo? Como você se sente sobre isso depende mais de como você se sente sobre a Microsoft do que qualquer coisa que alguém pode dizer sobre linguagens de programação.

OCaml (ou ML em geral), é uma boa escolha linguagem prática que suportes fazendo coisas legais funcional sem forçá-lo a trabalhar de uma forma que pode ser desconfortável. Você recebe o benefício cheio de coisas como tipos de dados algébricos, correspondência de padrões, inferência de tipos, e todos os outros é coisa favorita. Oh, e objetos.

Haskell dá-lhe tudo o que (exceto objetos, praticamente), mas também mais ou menos força você a repensar tudo o que você pensa que sabe sobre programação. Isso pode ser uma coisa muito boa, se você está procurando para aprender algo novo, mas pode ser mais do que você quer morder. Digo isso como alguém que só está talvez no meio do caminho a ser uma produtiva, feliz programador Haskell.

Ambos OCaml e Haskell estão sendo usados ??para lotes de gravação de diferentes tipos de programas, não apenas compiladores e AI ou o que quer. Google é seu amigo.

Uma última nota: OCaml lhe dá Hashtable, mas dificilmente é sensato para usá-lo no código, se você realmente quer abraçar programação funcional. árvores persistentes (como Data.Map) são realmente a solução certa para Haskell, e têm muitas propriedades agradáveis, o que é uma das coisas interessantes para aprender sobre quando você pegar Haskell.

Answer 6

F # e OCaml são muito semelhantes na sintaxe, no entanto, obviamente, F # é melhor com .NET.

Qual deles você aprender ou uso deve ser dependente de qual plataforma você está apontando para.

Em VS2010 F # vai ser incluído, e uma vez que compila para .NET bytecode, ele pode ser usado em um sistema operacional Windows que suporta a versão .NET você usou para ele. Isto lhe dará uma grande área, mas há limites, atualmente com F # que OCaml não têm, em que F # parece não tirar proveito de todos os processadores em uma máquina, mas, que é provavelmente devido a F # ainda está sendo desenvolvido , e isso pode ser um recurso que não é tão importante ainda.

Existem outras linguagens funcionais, como Erlang que você pode olhar, mas, basicamente, se você é forte em um idioma FP, então você deve ser capaz de pegar um outro rapidamente, por isso, basta escolher um que você gosta e tentar desenvolver aplicações interessantes e desafiadores na mesma.

Por fim escritores de língua vai encontrar uma maneira de obter linguagens OO para trabalhar bem com multi-núcleos e FP podem cair no esquecimento novamente, mas, que não parece estar acontecendo tão cedo.

Answer 7

Este não é diretamente relacionado à pergunta do OP quanto à possibilidade ou não de aprender F #, mas sim, um exemplo de uso OCaml mundo real no setor financeiro: http://ocaml.janestreet.com/?q=node/61

Muito interessante conversa.

Answer 8

Em termos de longevidade, é muito difícil de julgar a popularidade de linguagens, mas apenas fazer uma verificação rápida aqui, estes são os números de perguntas marcados com o apropriado linguagem (funcional): -

2672 Scala, 1936 Haskell, 1674 F #, 1126 Clojure, 709 Esquema, 332 OCaml

Eu diria que esta era uma boa indicação de quais idiomas as pessoas estão aprendendo ativamente no momento e, portanto, pode ser uma boa indicação de quais poderiam ser popular nos próximos anos.