Existem desvantagens ou problemas com o Haskell?

Algumas desvantagens posso pensar:

• Devido à natureza da linguagem e suas raízes firmes no mundo acadêmico, a comunidade é muito voltada para a matemática; Se você é uma pessoa pragmática, às vezes isso pode ser esmagador, e se você não fala o jargão, terá mais dificuldade do que com muitas outras línguas.
• Embora exista uma incrível riqueza de bibliotecas, a documentação é frequentemente concisa.
• Os tutoriais de nível de entrada são poucos e difíceis de encontrar, por isso a curva de aprendizado inicial é bastante íngreme.
• Alguns recursos de idioma são desnecessariamente desajeitados; um exemplo proeminente é como a sintaxe de registro não introduz um escopo de nomenclatura, portanto, não há como ter o mesmo nome de campo de registro em dois tipos diferentes dentro do mesmo espaço de nome de módulo.
• O Haskell é padronizado para avaliação preguiçosa, e embora isso seja uma grande coisa, ele pode te atacar de maneira desagradável às vezes. Usar a avaliação preguiçosa ingenuamente em situações não triviais pode levar a gargalos desnecessários de desempenho, e entender o que está acontecendo sob o capô não é exatamente direto.
A avaliação preguiçosa (especialmente combinada com a pureza e um compilador que otimiza agressivamente) também significa que você não pode raciocinar facilmente sobre a ordem de execução; na verdade, você nem sabe se determinado código realmente é avaliado em uma determinada situação. Conseqüentemente, a depuração do código do Haskell requer uma mentalidade diferente, apenas porque percorrer seu código é menos útil e menos significativo.
• Por causa da pureza de Haskell, você não pode usar efeitos colaterais para fazer coisas como E / S; você tem que usar uma avaliação preguiçosa de mónadas e 'abuso' para conseguir interatividade, e você tem que arrastar o contexto monádico para qualquer lugar que você queira fazer I / O. (Este é realmente um bom recurso em muitos aspectos, mas torna a codificação pragmática impossível às vezes.)

A maioria das desvantagens de Haskell (assim como a maior parte do lado positivo de Haskell) vem de suas duas características definidoras: é preguiçoso e puramente funcional.

Ser preguiçoso torna mais difícil raciocinar sobre o desempenho. Especialmente para pessoas não acostumadas à preguiça, mas mesmo para Haskellers experientes, pode ser difícil ver como a preguiça afetará o desempenho em certos casos.

Preguiça também significa que é mais difícil criar benchmarks precisos sem usar bibliotecas como o Criterion.

Ser puramente funcional significa que sempre que você precisar usar estruturas de dados mutáveis (nos casos em que não é possível obter o desempenho desejado sem elas - embora graças ao otimizador do GHC não aconteça com a freqüência que você possa imaginar), Estará preso na món IO (ou ST), o que torna o código mais complicado.

Como você mencionou a velocidade como um dos seus objetivos, devo salientar que há muitas diferenças enormes de desempenho entre o código Haskell otimizado para as mãos e o código Haskell que foi escrito sem pensar muito no desempenho (mais do que em outros idiomas ). E o código Haskell otimizado manualmente é muitas vezes bastante feio (embora eu suponha que isso também seja verdade na maioria das outras linguagens).

Eu não sou especialista em Haskell: aprendi o básico, mas infelizmente não tive a chance de fazer um projeto sério em Haskell (eu gostaria, porém, porque eu gosto muito dessa linguagem).

No entanto, pelo que sei e por uma discussão com alguém que está trabalhando em um campo bastante próximo da programação funcional, Haskell pode não ser o melhor solução quando você deseja implementar algoritmos gráficos, onde você precisa, e. percorrer o gráfico e realizar muitas alterações locais na estrutura do gráfico.

Como um gráfico não tem uma estrutura recursiva em geral, meu sentimento é que a melhor abordagem é construir uma cópia do gráfico usando estruturas e ponteiros entre eles (como você pode fazer, por exemplo, em C + +) e manipular isso copiar mudando ponteiros, criando ou destruindo nós, e assim por diante.

Gostaria de saber como essas estruturas e operações de dados podem ser manipuladas adequadamente em Haskell, desde que eu saiba em Haskell, não é possível usar a representação / abordagem acima. Alguns problemas com algoritmos gráficos em Haskell são brevemente discutidos em este artigo

EDITAR

Falei recentemente com um especialista em programação funcional e ele confirmou que implementar um algoritmo gráfico com eficiência pode ser bastante complicado em Haskell: mover ponteiros como em C ou C ++ pode ser muito mais rápido.

O lado negativo de Haskell é que é diferente. É um passo maior longe das linguagens que são mais comumente ensinadas ou discutidas, então haverá uma curva de aprendizado maior. Também é menos popular de uma linguagem que pode limitar a disponibilidade de ajuda se você ficar preso. Estes realmente não são grandes desvantagens embora.

A única coisa que é uma desvantagem potencial é que é uma linguagem funcional, por isso é menos útil para determinados domínios de problemas, mas isso também é válido para linguagens orientadas a objetos. Geralmente, as linguagens não têm negativas verdadeiras além das curvas de aprendizado, pelo menos para os idiomas relativamente populares. Enquanto uma linguagem é Turing completa, é teoricamente capaz de qualquer coisa.

So, given this, what I'm looking for are the downsides or problems that come along with Haskell

Os "problemas com o Haskell" tendem a aparecer em determinados domínios. Haskell é uma linguagem maravilhosa para programação de aplicativos, muito mais agradável de escrever do que qualquer outra coisa. Os problemas tendem a surgir quando você tenta fazer algo para o qual não há suporte, como:

• Compilação cruzada. O GHC pode ser construído como um compilador cruzado, mas o processo é bastante envolvido.
• Aplicativos incorporados. Haskell tem gerenciamento de memória através de um coletor de lixo, então este não é muito surpreendente.
• Velocidade. Haskell não é tão rápido quanto Rust, apesar de na maioria dos casos competir razoavelmente bem. Depende muito do domínio da aplicação - os cálculos puros são otimizados, mas algo como "ler um arquivo em um buffer e contar o número de linhas" é mais difícil de expressar em Haskell.