Summary: Last year I made a list of four flaws with Haskell. Most have improved significantly over the last year.
No language/compiler ecosystem is without its flaws. A while ago I made a list of the flaws I thought might harm people using Haskell in an industrial setting. These are not flaws that impact beginners, or flaws that stop people from switching to Haskell, but those that might harm a big project. Naturally, everyone would come up with a different list, but here is mine.
Package Management: Installing a single consistent set of packages used across a large code base used to be difficult. Upgrading packages within that set was even worse. On Windows, anything that required a new network package was likely to end in tears. The MinGHC project solved the network issue. Stackage solved the consistent set of packages, and Stack made it even easier. I now consider Haskell package management a strength for large projects, not a risk.
IDE: The lack of an IDE certainly harms Haskell. There are a number of possibilities, but whenever I've tried them they have come up lacking. The fact that every Haskell programmer has an entrenched editor choice doesn't make it an easier task to solve. Fortunately, with Ghcid there is at least something near the minimum acceptable standard for everyone. At the same time various IDE projects have appeared, notably the Haskell IDE Engine and Intero. With Ghcid the lack of an IDE stops being a risk, and with the progress on other fronts I hope the Haskell IDE story continues to improve.
Space leaks: As Haskell programs get bigger, the chance of hitting a space leak increases, becoming an inevitability. While I am a big fan of laziness, space leaks are the big downside. Realising space leaks were on my flaws list, I started investigating methods for detecting space leaks, coming up with a simple detection method that works well. I've continued applying this method to other libraries and tools. I'll be giving a talk on space leaks at Haskell eXchange 2016. With these techniques space leaks don't go away, but they can be detected with ease and solved relatively simply - no longer a risk to Haskell projects.
Array/String libraries: When working with strings/arrays, the libraries that tend to get used are vector, bytestring, text and utf8-string. While each are individually nice projects, they don't work seamlessly together. The utf8-string provides UTF8 semantics for bytestring, which provides pinned byte arrays. The text package provides UTF16 encoded unpinned Char arrays. The vector package provides mutable and immutable vectors which can be either pinned or unpinned. I think the ideal situation would be a type that was either pinned or unpinned based on size, where the string was just a UTF8 encoded array with a newtype wrapping. Fortunately the foundation library provides exactly that. I'm not brave enough to claim a 0.0.1 package released yesterday has derisked Haskell projects, but things are travelling in the right direction.
It has certainly been possible to use Haskell for large projects for some time, but there were some risks. With the improvements over the last year the remaining risks have decreased markedly. In contrast, the risks of using an untyped or impure language remain significant, making Haskell a great choice for new projects.
Flaw 5: Reads like a spaghetti.
ReplyDeleteFeature 1: It's just as edible too, with curry and everything.
DeleteCould you link to the original blog post? I couldn't find it.
ReplyDeleteTom: which post? Our space leak one? http://neilmitchell.blogspot.co.uk/2015/09/detecting-space-leaks.html
ReplyDeleteFlaw 6: People writing Haskell tutorials are unable/unwilling to describe the language without using degree-level mathematics. Mathematicians are unable/unwilling to explain things without using Haskell.
ReplyDeletepndc: Hardly. There's a lot of math terminology, but there's a lot of math terminology everywhere. And you really don't need to know anything at all about category theory to use a functor in haskell, anymore than you need to understand anything about vector spaces to use vectors.
ReplyDeleteIDEs are so passé!
ReplyDelete¡Viva el ghcid!
pndc: just read haskellbook.com and you are good
ReplyDelete> Flaw 5: Reads like a spaghetti.
ReplyDeleteNot always, the problem imo is just the style that is encouraged and is common in the community. Usually used by people who have never had to work on legacy software, software that has to be maintained, people who still foolishly believe that typing less is a good excuse to write shitty code etc.
like any code, good variable naming, function naming, good design, encapsulation, good comments and all the rest can make it perfectly readable.
Someone once said that writing haskell is easier than reading it.
ReplyDeleteThis applies to most programming languages naturally but some programming languages may make it easier or harder. (I can not evaluate haskell much at all since I did not really write anything in it myself. I consider the syntax cleaner than say php)
I think the lack of a good IDE is the most disappointing thing to Haskell considering it's uniquely strong type system. I would think that an IDE for Haskell would be able to implement some awesome features that would be very hard to implement with any other language.
ReplyDeleteHoping to see some kind of graphical representations of code in the future, maybe VR or AR. Maybe something of the sort would in the future make it easier to learn Haskell, perhaps representing types as shapes and pegs to indicate that something is typed soundly or some rang e of functions can fill the place of a type hole.
I'm rambling, but I think that Haskell is almost uniquely in a position to redefine what is possible in an IDE.
One minor flaw not on your list, which affects those wanting to embed Haskell, is that the runtime cannot be reinitialised. For example, we cannot call Haskell from C++ and safely handle an out-of-memory from the runtime without restarting the process.
ReplyDeleteTim: Out of memory handling is ferociously difficult in C++. You have to ensure all your catch paths don't allocate and that they all work perfectly. In practice, I'd just restart the process to be sure.
ReplyDeleteHi Neil, I'd like to be able to specify a maximum runtime heap size for Haskell such that there is little danger of the process itself not being able to allocate more. Then being able to reinitialise the runtime would be useful. This came up at Barclays when we wanted to use Haskell code from within Excel. I agree that process isolation is more desirable in most cases.
DeleteDoesn't Backpack solve the array/string issue? See http://blog.ezyang.com/2014/08/whats-a-module-system-good-for-anyway/
ReplyDeleteJanus: Backpack lets you mix different string implementations, which certainly helps the problems. However, I'd still say none of the packages work nicely together, backup just lets you be polymorphic over which you want until a bit later.
ReplyDelete