Por que o OCaml não é mais popular?

Eu sempre ouvi dizer que C é o idioma de escolha a ser usado em sistemas embarcados ou qualquer coisa que precise ser executada na velocidade máxima. Eu nunca desenvolvi uma predileção por C, principalmente porque não gosto de aritmética de ponteiros e a linguagem é apenas um degrau acima da montadora.

Por outro lado, as linguagens ML são funcionais, as linguagens de coleta de lixo e o OCaml ainda tem um modelo de objeto, mas elas têm a reputação de serem tão rápidas quanto as linguagens C. As linguagens ML têm a abstração que qualquer um poderia pedir para escrever de forma concisa e de alto nível. código, mas mantém a velocidade necessária para escrever aplicativos de alto desempenho.

O OCaml, em particular, pode ser usado em qualquer lugar em que C seja tradicionalmente usado, como para dispositivos embarcados, drivers gráficos, sistemas operacionais etc. Por todos os direitos, o OCaml deveria ter dominado o mundo agora, mas quase ninguém ouviu falar do idioma sozinho. usado.

Essa é uma pergunta subjetiva, mas por que os outros idiomas do OCaml e do ML permaneceram tão obscuros, enquanto o C e outros idiomas se tornaram populares?

A primeira resposta é que ninguém sabe realmente por que as línguas se tornam populares e quem diz o contrário é iludido ou tem uma agenda. (Muitas vezes, é fácil identificar por que um idioma não se torna popular, mas isso é outra questão.)

Com esse aviso, aqui estão alguns pontos sugestivos e mais importantes:

• O primeiro compilador C maduro apareceu em 1974; o primeiro compilador OCaml maduro apareceu no final dos anos 90. C tem um avanço de 25 anos.

• C foi lançado com o Unix, que foi o maior "aplicativo matador" de todos os tempos. Por um longo tempo, todos os departamentos de CS do mundo tiveram que ter o Unix, o que significava que todos os instrutores e todos os participantes de um curso de CS tiveram a oportunidade de serem expostos a C. OCaml e ML ainda estão esperando seu primeiro aplicativo matador. (O MLdonkey é legal, mas não é o Unix.)

• C preenche tão bem seu nicho que duvido que nunca exista outra linguagem de baixo nível dedicada apenas à programação de sistemas. (Para ver as evidências a favor, leia o artigo de Dennis Ritchie sobre a história do C no HOPL II.) Não está claro o que é o nicho do OCaml e o nicho do Standard ML é apenas um pouco mais claro. Portanto, Caml e ML têm muitos concorrentes, enquanto C matou seu único concorrente (BLISS).

• Um dos pontos fortes de C é que seu modelo de custo é muito previsível: é fácil olhar para qualquer pequeno fragmento de código C para obter instantaneamente uma idéia precisa de quais operações da máquina terão que ser executadas para executar esse código. O modelo de custo do OCaml é muito menos claro, principalmente porque a alocação de memóriaé muito menos explícito e o custo total da alocação de memória (igual ao custo da alocação mais os custos incorridos durante a coleta de lixo) depende de propriedades emergentes, como o tempo de vida dos objetos e quais objetos se referem a outros objetos. O resultado líquido é que o desempenho é difícil de prever e até difícil de analisar após o fato. (As ferramentas de criação de perfil de memória do OCaml não são o que deveriam ser.) Como resultado, o OCaml não é bom para aplicativos em que o desempenho deve ser muito previsível - como sistemas embarcados.

• C é uma linguagem com um padrão e muitos compiladores. OCaml é um artefato de software: o único compilador é de uma única fonte e o compilador é o padrão. E esse padrão muda a cada versão. Para pessoas que valorizam a estabilidade e a compatibilidade com versões anteriores, um idioma de fonte única pode representar um risco inaceitável.

• Qualquer pessoa com um curso de compilador de graduação meio decente e muita persistência pode escrever um compilador C que mais ou menos funcione e com desempenho adequado. Obter uma implementação do OCaml ou ML do zero requer muito mais educação, e obter um desempenho comparável a um compilador C ingênuo requer muito mais trabalho. Isso significa que há muito menos entusiastas com idiomas como o OCaml, por isso é mais difícil para a comunidade desenvolver um profundo entendimento sobre como explorá-lo.

Acho que o problema com o OCaml é que ele não é muito útil "pronto para uso". A eventual razão pela qual as pessoas usam uma linguagem é porque ela possui bibliotecas de que precisam. Com nada "pronto para uso", porém, ninguém chega longe o suficiente em um projeto para perceber que eles precisam escrever uma biblioteca. O resultado é uma linguagem sem bibliotecas, o que dificulta a criação de "aplicativos reais".

Eu acho que é disso que o OCaml sofre - ninguém se incomoda em iniciar "projetos reais", porque tudo o que existe é uma linguagem de programação. Sim, posso adicionar dois e dois e imprimir o resultado. O resultado é uma coleção de bibliotecas que são principalmente abandonware acadêmico (o autor obteve seu doutorado e seguiu em frente), o que não é muito útil para a prática de programadores.

(Eu sei que há trabalho em andamento para mudar isso, com projetos como "Baterias incluídas". Volte aqui em cinco anos e talvez o OCaml seja mais popular.)

Existem algumas exceções a esta regra. O Java começou sem bibliotecas, mas a Sun pagou às pessoas para escrevê-las todas em casa e, em seguida, elas venderam o inferno. Certificação Java, hardware específico para Java, livros sobre Java, aulas sobre Java etc. Até convenceram a maioria das universidades a ensiná-lo exclusivamente, mesmo que não seja uma linguagem muito boa para aprender programação.

O resultado foi popularidade. O dinheiro pode resolver muitos problemas.

Na arena da linguagem funcional, podemos ver que Haskell está se tornando bastante popular. Penso que a maior parte da popularidade se deve a pessoas como dons que escrevem bibliotecas úteis e nunca param de comercializar o idioma. Todos os dias você vê alguns artigos da Haskell sobre Programação de Reddit. Isso o mantém preso na mente das pessoas até que elas finalmente decidam: "Vou tentar Haskell". Quando o fazem, veem coisas úteis como estruturas da Web, bancos de dados de objetos, bibliotecas OpenGL e bibliotecas de processamento XML. Isso significa que eles podem realmente fazer algo útil "Right Now". Portanto, entre o potencial de ser produtivo e ouvir muito sobre isso, Haskell ganhou muita popularidade.

O CL tem muitas das mesmas bibliotecas que Haskell e é quase tão rápido, mas ninguém fala sobre isso, então "parece morto". De fato, #lisp é muito mais silencioso que o #haskell, mas o Lisp ainda é uma linguagem muito produtiva com muitas bibliotecas. Nenhum outro idioma possui SLIME. Mas o marketing é muito importante, e Haskell faz isso melhor do que Lisp ou OCaml (e concorre pela mesma base de usuários).

Finalmente, algumas pessoas nunca "obtêm" programação, portanto, quebrar seu modelo mental (variáveis ​​são caixas com valores, o código é executado de cima para baixo) garantirá que eles não usem sua linguagem. Esse tipo de programador é uma grande porcentagem da população de programação, limitando ainda mais a possível base de usuários de linguagens abstratas como Lisp, Haskell e OCaml.

Eu gosto muito do OCaml como idioma. MAS...

O suporte às ferramentas simplesmente não está lá. O depurador funciona apenas OK, mas não funciona no Windows (a última vez que verifiquei) e simplesmente não existem muitas ferramentas de desenvolvimento disponíveis para ele.

Seu sistema de tipos é, às vezes, um pouco forte demais . Para alguém que não entende como a inferência de tipo funciona ou o sistema de tipo ML em geral, o fato de ele não poder adicionar um número inteiro a um float é uma grande desativação imediata.

Às vezes, a biblioteca padrão pode ter uma sensação inconsistente.

O modelo de objeto parece um pouco adiado e a biblioteca padrão mal o utiliza, optando por bibliotecas baseadas em módulos.

Existem muitas outras coisas que basicamente significam que o idioma não se sente "polido" e que afasta as pessoas durante o período muito crítico, quando estão escolhendo um idioma e tentando decidir se gostam ou não.

Penso que o seu legado mais importante será que, juntamente com outros dialetos de ML, teve uma influência muito forte em outras linguagens funcionais. A maioria das linguagens funcionais da geração atual pega os melhores elementos dos dialetos ML e refina alguns dos aborrecimentos.

Os sistemas embarcados geralmente exigem duas coisas: velocidade e determinismo. O OCaml pode fornecer velocidade, mas o fato de ter um coletor de lixo o torna inerentemente não determinístico, e para um sistema em tempo real simples que não funciona.

Esta é uma comparação entre maçãs e laranjas. O OCaml é uma linguagem bastante jovem [1] e nunca houve um esforço sério e contínuo para empurrá-lo para o mainstream (exceto o trabalho atual da Microsoft com F #). Diferentemente de C, não é a língua franca do sistema operacional corporativo mais amplamente suportado e imitado (por exemplo, UNIX). Ao contrário do Java, ele não teve uma grande corporação empurrando-o como uma plataforma de computação da próxima geração. Diferente do Perl, Python e Ruby, ele não se apoderou de um nicho influente e de alto perfil (ou seja, seu nicho é a linguagem de programação e a pesquisa de raciocínio automatizada - não muito destacada em comparação com o desenvolvimento da Web). Portanto, não é super popular.

[1] Para ser justo, a linguagem ML original existe desde os anos 70. Mas o OCaml não apareceu até 1996 e não herdou as bibliotecas Standard ML. É, em termos práticos, uma linguagem mais jovem que C, C ++, Java, Python, Haskell ou até Ruby.

A comunidade OCaml falhou ao desenvolver uma biblioteca padrão grande e confiável (além do que vem hoje com o OCaml) que facilita o desenvolvimento de aplicativos. Existem várias tentativas para resolver o problema, mas basta dar uma olhada no Python ou Ruby para ver o que está faltando. O OCaml é uma ótima linguagem se você deseja resolver um problema algorítmico que não depende muito de ter que interagir com módulos padrão avançados como XML, rede, cálculo de dados e assim por diante, que você prefere não implementar.

Acredito que parte do problema é como os módulos são mapeados para arquivos pelo OCaml: conceitualmente, todos os arquivos * .ml vivem no mesmo espaço de nome e os diretórios não têm significado. Isso torna difícil para uma comunidade evoluir uma biblioteca. Se o compilador mapeasse hierarquias de diretório para hierarquias de módulos, eu veria uma chance melhor de que uma biblioteca padrão evoluísse. Isso, no entanto, exigiria um esforço considerável dos desenvolvedores do compilador principal. (Estou ciente dos módulos de empacotamento, mas acho que isso é um problema.)

Outro problema da biblioteca é a compatibilidade binária entre as versões do compilador. É bastante seguro dizer que todo o código da biblioteca deve ser recompilado após uma atualização do compilador. Isso dificulta o fornecimento de versões binárias de módulos ou bibliotecas.

Provavelmente porque muitas pessoas aprenderam ML como parte de uma introdução a coisas teóricas estranhas e confusas sobre tipos. Foi o que aconteceu comigo.

Foi-me mostrado ML e Smalltalk na mesma época. O Smalltalk parecia legal demais, e era imediatamente compreensível o que era o OO e como você podia criar coisas bonitas e interativas nesse ambiente. ML era sobre coisas matemáticas abstratas que não pareciam relevantes para o que eu queria fazer. E, ao contrário de C, não prometeu me deixar escrever jogos rápidos em micros de 16 bits.

Isto é, obviamente, profundamente injusto e subjetivo. Mas essa é provavelmente a história verdadeira para a maioria das pessoas.

Hoje em dia, acho que a pergunta seria: agora sinto que preciso conhecer essas coisas teóricas estranhas e confusas sobre tipos, por que escolheria ML em vez de Haskell ou Erlang?

Acredito que a questão principal é a falta de uma biblioteca padrão real. Daí o projeto OCaml Batteries Included , que deve melhorar bastante a situação. Ele deve entrar na fase Beta dentro de alguns dias, então você terá que fazer a pergunta novamente em um ano ou mais.

Concordo que o suporte insuficiente ao Windows, uma curva de aprendizado acentuada e uma biblioteca padrão fina abafaram a aceitação do OCaml no passado, mas eu acrescentaria que houve uma enorme falta de informações sobre tutoriais (por exemplo, livros) sobre o OCaml em comparação com linguagens comuns como Java.

Além disso, os tipos de pessoas que conhecem idiomas como OCaml são extremamente heterogêneos. Entre os programadores da Web, talvez 1 em 1.000 já tenha ouvido falar do OCaml. Entre as pessoas que fazem computação científica na Universidade de Cambridge, cerca de 90% das pessoas que eu conhecia eram fluentes no OCaml. Na verdade, eu fui um dos últimos entre meus amigos a aprender OCaml. Até rodamos o OCaml em nosso supercomputador de 256 CPUs ...

Devo também mencionar que essas questões estão sendo abordadas rapidamente. O OCaml se reinventou recentemente para a programação da Web com projetos como a Ocsigen e já possui pelo menos duas grandes histórias de sucesso industrial nesse contexto. Há outro livro novo sobre o OCaml já disponível. A comunidade está colaborando em uma biblioteca padrão abrangente chamada "baterias incluídas" que acabou de ser lançada na versão beta e parece fantástica. Uma versão compatível com vários núcleos do OCaml está prestes a ser lançada. A versão mais recente do OCaml também inclui muitos novos recursos excelentes, como padrões preguiçosos e bibliotecas OCaml de código nativo carregadas dinamicamente.

Acho que parte do problema é que a programação funcional simplesmente não é uma maneira natural para a maioria das pessoas pensar (e digo isso como alguém que tem um grande interesse e apreço pela programação funcional). Isso é agravado pelo fato de que a grande maioria dos programadores hoje começou a aprender programação procedural (as linguagens OOP mais populares ainda são procedimentais) e, portanto, as linguagens funcionais são difíceis de ajustar inicialmente.

Quando comecei a universidade, eu já conhecia uma quantidade razoável de BASIC, C ++ e Java e um pouco da linguagem assembly Pascal e x86. Eu estava longe de ser um especialista, mas havia chegado à conclusão (um pouco ingênua) de que todas as linguagens de programação eram basicamente as mesmas, com sintaxe um pouco diferente. Nossa introdução ao curso de programação usou ML, o que rapidamente me desiludiu dessa noção. Eu tive problemas para entender o ML nessa fase da minha carreira em programação e realmente não via o sentido da programação funcional. Eu acho que é preciso um pouco mais de experiência com alguns dos problemas da programação processual para realmente apreciar os benefícios de uma abordagem funcional.

Nosso professor de ML frequentemente alegava que expressar problemas recursivamente era mais "natural" e mais fácil do que usar loops ou outros conceitos de procedimento. Eu nunca fui convencido por essa afirmação e ainda não a comprei. Às vezes, funções recursivas podem fornecer soluções concisas e elegantes para problemas, mas ainda acho uma maneira não natural de pensar sobre problemas. Talvez se você tiver um fundo matemático muito forte, isso parecer mais intuitivo, mas não acho fácil para a maioria das pessoas pensar recursivamente. Dada a centralidade das funções recursivas no paradigma de programação funcional, acho que isso também pode ser uma razão da menor popularidade das linguagens funcionais.

Há também um efeito de feedback sobre a popularidade do idioma. Quando comecei a programar, queria saber como programar efeitos e jogos gráficos. Depois de aprender um pouco do BBC BASIC e, mais tarde, do QBASIC, eu naturalmente investiguei quais eram as linguagens mais comuns usadas pela cena demo e pelos programadores de jogos e comecei a aprender C ++ e montagem x86. Hoje em dia, alguns novos programadores podem querer saber como produzir aplicativos da Web e, portanto, irão se interessar pelo aprendizado de PHP, Ruby ou C #. Existem muito poucas áreas de aplicação para programadores iniciantes motivados, onde a resposta para 'qual é a melhor linguagem para aprender a programar algo como X' será 'Ocaml'.

Muitas das razões práticas apontadas para a popularidade limitada do Ocaml (falta de bibliotecas, depuradores, IDEs etc.) maduras são abordadas pelo suporte oficial da Microsoft ao F # como uma linguagem .NET de primeira classe. Será interessante ver se o F # ajuda a trazer um maior nível de popularidade para a programação funcional.

Eu acredito que o núcleo do problema é política. Os desenvolvedores da Ocaml estão interessados ​​principalmente em pesquisa e não têm os recursos para fornecer e manter uma biblioteca rica. No entanto, eles também não estão dispostos a liberar o controle do produto para a comunidade que possui esses recursos; o resultado é que várias tentativas para resolver esse problema se basearam na cooperação e no financiamento inexistentes de bibliotecas de terceiros e essas tentativas falharam. As baterias falharão pelo mesmo motivo, a menos que os desenvolvedores da Ocaml mudem de atitude.

Uso o Ocaml para desenvolver meu produto e tenho uma regra simples: minimizar a dependência de código de terceiros. Quando um item de terceiros for útil, se possível, incorpore os códigos-fonte diretamente no pacote. Por exemplo, o OCS Scheme e o Dypgen são partes essenciais do analisador Felix; portanto, eles são copiados para nossas fontes, para que tenhamos algum controle sobre eles. O controle é um pouco ilusório (já que Dypgen é pelo menos tão complexo que é improvável que possamos mantê-lo, mas pelo menos temos uma cópia que achamos que funciona :)

Não usarei baterias porque a licença é restritiva, por isso não posso copiar a fonte e não acredito na viabilidade a longo prazo dela como um produto independente: a única maneira de usá-la é se fosse incorporado diretamente na distribuição padrão do Ocaml.

No mundo C ++, eu poderia considerar o uso do Boost: embora seja uma biblioteca de terceiros que não faz parte do Padrão, ela tem um suporte pesado da comunidade e é realmente excelente sincronizada com o processo de desenvolvimento de Padrões. As idéias desenvolvidas e testadas no Boost se tornam o tipo de prática existente que pode ser padronizada, e o processo de normas é aberto o suficiente para permitir a participação da comunidade.

O Ocaml obteve a popularidade que realmente tem porque é um produto muito bom, mas isso não é suficiente para permitir que ele se torne um idioma comum. Java é grosseiro, tornou-se popular com bilhões de dólares em marketing e desenvolvimento de bibliotecas, mas no final teve que ser liberado para a comunidade para sobreviver.

Gostei de codificar em ML e C para uma ampla variedade de projetos. O que me impede de usar o ML em projetos incorporados (a maioria dos quais possui restrições em tempo real e requer validação) é a coleta de lixo.

Há pesquisas em gerenciamento de memória com regiões (consulte o MLKit ), mas a complexidade das implementações e o treinamento necessário para usá-los adequadamente (e os riscos associados) foram um impedimento para usá-los.

IMHO, acho que um grande problema do OCaml não está na linguagem (isso é ótimo), mas nas pessoas que a desenvolvem e, consequentemente, em sua licença:

http://caml.inria.fr/ocaml/license.en.html

Eles usam a licença Q Public para o compilador! Sim, a licença ex-Trolltech usada para bibliotecas Qt! Esqueça de obter qualquer contribuição com essa licença.

Se você estava checando o Language Shootout ( http://shootout.alioth.debian.org/ ) há cerca de 7 a 8 anos, o OCaml estava logo atrás de C e C ++ para velocidade de execução. Enquanto isso, outras línguas (como Haskell) obtinham um compilador melhor (devido a uma abordagem diferente da comunidade, suponho) e agora a velocidade de execução do OCaml não é tão grande quanto no passado.

Em pouco tempo, eu não usaria o OCaml, porque não o vejo indo a lugar algum sem que alguns hackers realmente bons criem um compilador OCaml que tenha uma licença de código-fonte REALMENTE aberto e uma comunidade com um comportamento de código-fonte REALMENTE aberto.

Bem, se é sobre dinheiro, como diz @jrockway, veremos se o F # ganhará popularidade como java ou C #.

Para mim, acho que os desenvolvedores não se sentem à vontade com a maneira funcional de fazer as coisas (isso é da sessão de F # na techdays 2009, onde cerca de 10 pessoas disseram conhecer programação funcional entre quase 100 pessoas).

Comecei a OCAML este ano, nunca sujo minhas mãos com programação funcional, mas agora realmente aprendo coisas novas sempre com a OCAML e a maneira funcional de resolver problemas (mas não posso dizer que vou desistir de C # para usar o OCAML :)).

Bem, talvez o F # se torne popular.

Não ajuda que c-> ocaml seja uma transição mental maior que c-> lisp. Eu considerei o ocaml algumas vezes e sempre achei que o custo / benefício simplesmente não estava lá para mim, então reserve-o novamente. Não foram as construções que fizeram com que parecesse difícil, elas realmente pareciam realmente legais. Ele estava tentando aprender um significado completamente diferente para '!'. Lisp pelo menos parece tão diferente que é fácil evitar interpretar pequenos pedaços dele como c.

Se você deseja que um idioma seja usado em sistemas embarcados em tempo real, precisa de ponteiros e não pode pagar um GC.

Eu acho que o principal motivo é que poucos desenvolvedores conhecem o OCaml.

E quando converso com outros desenvolvedores (aqueles que ouviram algo sobre o Ocaml), sempre tenho a impressão de que eles pensam no OCaml como uma linguagem "apenas para educação" ... triste, mas verdadeira

Eu gosto muito de O'caml ... Eu implementei um monte de coisas usando, compilador, intérpretes, sistema para se comunicar com C ...

quando soube, o principal problema era que as mensagens de erro não eram muito claras ... então, por exemplo, no começo eu não tinha muita certeza de quando colocar ';' e isso foi realmente difícil de descobrir que, na verdade, o; foi extraviado ...