Ci sono dei lati negativi o problemi con Haskell?

Alcuni aspetti negativi a cui riesco a pensare:

• A causa della natura della lingua e delle sue solide radici nel mondo accademico, la comunità ha una mente molto matematica; se sei una persona pragmatica, a volte può essere travolgente, e se non parli il gergo, avrai più difficoltà rispetto a molte altre lingue.
• Mentre c'è un'incredibile ricchezza di librerie, la documentazione è spesso concisa.
• Le esercitazioni di livello base sono poche e difficili da trovare, quindi la curva di apprendimento iniziale è piuttosto ripida.
• Alcune funzioni linguistiche sono inutilmente goffe; un esempio importante è come la sintassi dei record non introduce un ambito di denominazione, quindi non c'è modo di avere lo stesso nome del campo del record in due tipi diversi all'interno dello stesso spazio dei nomi del modulo.
• Haskell ha come impostazione predefinita una valutazione lenta e, sebbene spesso sia una cosa grandiosa, a volte può morderti in modi cattivi. Usare la valutazione pigra in modo ingenuo in situazioni non banali può portare a inutili colli di bottiglia nelle prestazioni, e capire cosa sta succedendo non è esattamente semplice.
• La valutazione pigra (specialmente combinata con la purezza e un compilatore aggressivamente ottimizzante) significa anche che non è possibile ragionare facilmente sull'ordine di esecuzione; in effetti, non sai nemmeno se un determinato pezzo di codice viene effettivamente valutato in una determinata situazione. Di conseguenza, il debug del codice Haskell richiede una mentalità diversa, se non altro perché passare attraverso il tuo codice è meno utile e meno significativo.
• A causa della purezza di Haskell, non puoi usare effetti collaterali per fare cose come I / O; devi usare una monade e 'abusare' di una valutazione pigra per ottenere interattività, e devi trascinare il contesto monadico ovunque vuoi fare I / O. (Questa è in realtà una buona funzionalità in molti modi, ma a volte rende la codifica pragmatica impossibile.)

La maggior parte degli svantaggi di Haskell (così come gran parte del vantaggio di Haskell) deriva dalle sue due caratteristiche principali: è pigro e puramente funzionale.

Essere pigri rende più difficile ragionare sulle prestazioni. Soprattutto per le persone non abituate alla pigrizia, ma anche per gli Haskellers esperti può essere difficile capire come la pigrizia possa influire sulle prestazioni in certi casi.

Pigrizia significa anche che è più difficile creare benchmark accurati senza utilizzare librerie come Criterion.

Essere puramente funzionali significa che ogni volta che è necessario utilizzare strutture dati mutevoli (nei casi in cui non è possibile ottenere le prestazioni desiderate senza di esse - sebbene grazie all'ottimizzatore di GHC ciò non avvenga tutte le volte che si potrebbe pensare), Sarò bloccato nella monade IO (o ST), il che rende il codice più ingombrante.

Dato che hai citato la velocità come uno dei tuoi obiettivi, devo sottolineare che ci sono spesso enormi differenze nelle prestazioni tra il codice Haskell ottimizzato a mano e il codice Haskell che è stato scritto senza riflettere troppo sulle prestazioni (più che in altre lingue ). E il codice Haskell ottimizzato a mano è spesso abbastanza brutto (anche se suppongo che sia vero anche nella maggior parte delle altre lingue).

Non sono un esperto di Haskell: ho imparato le basi, ma sfortunatamente non l'ho fatto ho avuto la possibilità di fare un progetto serio in Haskell (vorrei, però, perché mi piace molto questo linguaggio).

Tuttavia, da quello che so e da una discussione con qualcuno che ha lavorato in un campo abbastanza vicino alla programmazione funzionale, Haskell potrebbe non essere il migliore soluzione quando si desidera implementare algoritmi di grafici, dove è necessario ad es. per percorrere il grafico ed eseguire molte modifiche locali sulla struttura del grafico.

Dato che un grafico non ha una struttura ricorsiva in generale, la mia sensazione è che l'approccio migliore è quello di costruire una copia del grafico usando le strutture e puntatori tra di loro (come si può fare ad es. in C ++) e manipolarlo copia cambiando i puntatori, creando o distruggendo i nodi e così via.

Mi chiedo in che modo tali strutture dati e operazioni possano essere gestite correttamente in Haskell, dal momento che a mia conoscenza in Haskell non è possibile utilizzare la rappresentazione / approccio di cui sopra. Alcuni problemi con gli algoritmi di grafi in Haskell sono discussi brevemente in questo articolo

Modifica

Recentemente ho parlato con un esperto di programmazione funzionale e ha confermato che l'implementazione di determinati algoritmi di grafi in modo efficiente può essere abbastanza complicata in Haskell: spostarsi tra i puntatori come fai in C o C ++ può essere molto più veloce.

Il lato negativo di Haskell è che è diverso. È un passo più grande rispetto alle lingue che sono più comunemente insegnate o discusse, quindi ci sarà una curva di apprendimento più ampia. È anche meno popolare di una lingua che potrebbe limitare la disponibilità di aiuto in caso di blocco. Questi però non sono grossi inconvenienti.

L'unica cosa che è un potenziale svantaggio è che è un linguaggio funzionale, quindi è meno utile per alcuni domini problematici, ma questo vale anche per i linguaggi orientati agli oggetti. Generalmente le lingue non hanno veri negativi oltre le curve di apprendimento, almeno per le lingue relativamente popolari. Finché una lingua è completa, Turing è teoricamente in grado di fare qualsiasi cosa.

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

I "problemi con Haskell" tendono ad apparire in determinati domini. Haskell è un linguaggio meraviglioso per la programmazione di applicazioni, molto più piacevole da scrivere rispetto a qualsiasi altra cosa. I problemi tendono a sorgere quando si tenta di fare qualcosa per cui non c'è un buon supporto, come ad esempio:

• Compilazione incrociata. GHC può essere costruito come un cross-compilatore, ma il processo è piuttosto coinvolto.
• Applicazioni integrate. Haskell ha la gestione della memoria tramite un garbage collector, quindi questo non è troppo sorprendente.
• Velocità. Haskell non è veloce come Rust, anche se nella maggior parte dei casi sarà abbastanza competitivo. Dipende molto dal dominio dell'applicazione: i puri calcoli vengono ottimizzati bene, ma qualcosa come "leggere un file in un buffer e contare il numero di righe" è più difficile da esprimere in Haskell.