Deixando Haskell para trás

• O autor compartilha sua jornada de se afastar de Haskell, uma linguagem de programação funcional que usou por 10 anos como engenheiro de software.
• O autor foi atraído pela capacidade do Haskell de permitir compreender o código de forma simbólica e algébrica, além de seu sólido sistema de tipos.
• O sistema de tipos de Haskell permite uma verificação de tipos rigorosa sem ser excessivamente restritiva nem barulhenta, o que facilita escrever e manter código.
• O autor valorizava muito a capacidade do Haskell de expressar invariantes usando tipos, o que faz o compilador verificar a lógica em dobro e melhora a segurança e a precisão do código.
• Apesar dessas vantagens, o autor se afastou de Haskell por três motivos principais: o desejo por novidade estilística, ferramentas desajeitadas e mudanças contínuas.
• A novidade estilística se refere à tendência da comunidade Haskell de experimentar novas abstrações, o que é inovador, mas pode dificultar a manutenção do código.
• O autor avaliou as ferramentas do Haskell como "boas o suficiente", mas observou que não existe nada tão fácil de usar e estável quanto o cargo do Rust.
• As mudanças contínuas em Haskell, especialmente correções regulares sem compatibilidade retroativa, aumentaram o atrito no uso da linguagem.
• Mesmo tendo se afastado de Haskell, o autor ainda reconhece seus pontos fortes: a capacidade de refatorar código de forma algébrica, o sistema de tipos e o ecossistema de bibliotecas declarativas.
• O autor conclui que usar Haskell ou não depende dos objetivos de cada pessoa, recomenda aprendê-lo para se tornar um programador melhor, mas pede cautela ao adotá-lo como linguagem principal por causa dos desafios que descreveu.

[GN⁺]

Comentários do Hacker News

• A comunidade Haskell é conhecida por sua forte ênfase no aprendizado e por cultivar um ambiente de curiosidade e compartilhamento de conhecimento.
• No entanto, a comunidade frequentemente tem dificuldade em testar ideias e depois descartá-las, o que faz com que bases de código Haskell profissionais fiquem confusas.
• As ferramentas de Haskell são criticadas, mas também há quem argumente que a maioria das linguagens de programação tem ferramentas inferiores.
• As ferramentas de Haskell têm um recurso único chamado Hoogle, que é muito reconhecido por sua utilidade.
• O desenvolvimento de Haskell e de sua única implementação pública razoável, o GHC, é criticado por causa das mudanças constantes e da falta de consistência.
• A ligação entre versões específicas do GHC e da biblioteca padrão base é vista como um problema, pois força mudanças nas dependências quando uma nova versão do GHC é lançada.
• A perda de interesse do autor por Haskell é atribuída a três fatores principais: novidade estilística, ferramentas desajeitadas e mudanças constantes.
• A documentação e as ferramentas de Haskell eram difíceis de usar, e a transição da comunidade de Cabal para Stack, e depois de volta para Cabal, é vista como um sinal de melhora.
• Outras linguagens de programação incorporaram elementos de programação funcional, tornando-se mais atraentes para alguns desenvolvedores.
• Alguns desenvolvedores migraram de Haskell para F# porque escrever código é mais simples.
• Haskell é considerado difícil de aprender, e suas bibliotecas frequentemente estão desatualizadas ou são incompletas.
• O desempenho de Haskell é criticado, e a avaliação preguiçosa causa problemas de memória e desempenho lento.
• Considera-se que as perspectivas de emprego para desenvolvedores Haskell são limitadas por causa da natureza especializada da linguagem.
• Depurar em Haskell é descrito como desafiador devido à complexidade da linguagem.
• Scala é vista como uma boa alternativa ao Haskell, oferecendo o melhor dos dois lados.
• Alguns questionam a necessidade de recursos avançados da linguagem em tarefas cotidianas de engenharia de software.
• Considera-se que o foco de Haskell em pesquisa e objetivos acadêmicos pode entrar em conflito com as necessidades da programação prática.
• A postagem sugere que Haskell precisa de uma forma de separar recursos experimentais de recursos estáveis.
• O autor diz que não se sente pressionado a usar novos recursos avançados de tipos em Haskell e sugere desenvolver intuição sobre o quanto usar tipos complexos.