Why Haskell is beyond ready for Prime Time
I’ve read a few comments about why Haskell is awesome. I even wrote an ironic blog post about it. Today I’m going to explain why I use Haskell for doing real work, entirely in terms of the tools Haskell developers use.
Edit: Immediately after posting, I found this article on Sententia cdsmith about reasons why Haskell is a good language. So between this post on tools and his post on the language, I think we’ve got our bases covered :)
I first really came into appreciating libraries by way of Perl’s CPAN, probably around 1999. These days I’m absolutely convinced that your language needs to have a searchable, cross-referenced, dependency-tracking library repository. For Haskell, it’s Hackage.
Hackage has many desirable qualities: Packages are written to work together rather than compete with one another. Searching for packages by name or description is performed by Google, and has all of the quality you’d expect as a result. But Hackage has another search option, which brings me to my next point…
Haskell is strongly-typed and purely-functional. Good Haskell style is all about writing tiny functions (one-liners!) and remaining abstract (code-reuse!). These qualities make the type signature of a function very telling.
Think about how many times you’ve been working with data in one format and needed a function that could convert it to something else. You’d like to avoid writing the function yourself (code-reuse!) but don’t know what it is called. How would you find it? Google around with related terms? Ask a mailing list?
The Haskell community has two search engines that trivially solve this problem: Hooge and Hayoo!. These engines can search for a function by name or by its type signature; and Hayoo! is linked into Hackage, so it is able to tell you which library contains the function you want.
Here’s a concrete example: I’ve got a list of numbers, and I want to split it up into two lists — one consisting of the evens, one consisting of the odds. This seems like a pretty specialized task, so I doubt there’s a function written for it explicitly. So let’s look for a function that takes a list, and a boolean test, and splits it into two lists — one consisting of the elements satisfying the test, and the other consisting of the elements that don’t.
That is, I need a function that takes a list of integers, and a function from integers to bools, and produces two lists of integers.
No problem: I jump over to Hoogle and search for functions of type [Int] -> (Int -> Bool) -> ([Int], [Int]). It produces a short list of results, tells me what library they are in, and even gives a brief description of what the function does. I quickly see that partition is the function I want.
Remember that Hayoo! works in conjunction with Hackage, so that I have this ability for all of the libraries in the standard repository. What other language is so centralized?
We’ve got all the usual things — source control by darcs, unit testing by HUnit, automated testing by Quick Check, and source documentation by Haddock. We’ve also got package management by Cabal (tied into Hackage, of course).
We’ve got one other tool that is perhaps the strongest reason for the language — the Glorious Glasgow Haskell Compiler. You won’t find a more advanced compiler anywhere on earth. It produces code that is performance-competitive with C, has built in support for profiling, and features a rich interactive mode that both helps you test code and also explore types and interfaces.
For many people, the initial draw to Haskell is the advanced technology that is built into the language. Haskell was originally drafted as a “language playground,” giving researchers a place to experiment with new ideas. Over time it has adapted to keep the experiments that worked. Today it stands alone in its simultaneous support for many language features that the mainstream world probably won’t see for at least another 10 years.
This stuff isn’t just syntactic sugar, either. Haskell probably has better support for concurrency than any other language, due to a combination of its pure semantics, modern memory sharing techniques, and data-driven parallelism.
To get a sense for how wildly amazing Haskell-related technology, check out Automatic generation of free theorems — a tool that, given a function’s type signature, can write a function for you that has the correct signature! You won’t find this kind of thing anywhere else.
Lastly we come to one of the most special features that Haskell offers: its unique developer community.
The Haskell community is famous for its strange blend of pure academics, working engineers, and tinkering hobbyists. The community has active mailing lists where people pour unimaginable amounts of time into giving each other detailed and useful answers. It is not at all uncommon for the discussion on the lists to lead to groundbreaking developments in Haskell development.
The community also has one of the most active language-centric IRC channels, complete with an IRC bot that evaluates Haskell code publicly, giving everyone a chance to experiment with code together in real-time.
Of course, the community does the “web 2.0″ thing as well: we’ve got an active reddit, tons of active and insightful blogs, an electronic magazine, a Wikibook, and a weekly newsletter of online Haskell community happenings.
Haskell programmers generally feel like they’ve caught on to something very special. Every day there are new developments in the community that push the boundaries of technology, enabling people to write sophisticated programs in less time and with greater reliability. There really is a sense that we’re playing with the toys of the future, which have somehow been gifted to us today.
It’s a strange language — far enough ahead of the others that it can be tricky for beginners — but it really has quite a bit to offer. And with the availability of the supporting tools we’ve just looked at, it is beyond ready for prime time.
Very nice post, bookmarked for whenever I want to convince someone of Haskell’s superiority. :)
Tirpen
13 January, 2009 at 9:26 am
“far enough ahead of the others that it can be tricky for beginners ”
What the heck does that mean? If it’s so far ahead, why is it tricky? Shouldn’t it be LESS tricky if it’s so far ahead?!
Haskell hackers should just create cool stuff instead of fighting over whether it’s ready or not ready. Until we see some cool app come out of Haskell community, it will never be ready in the minds of most people.
mike
14 January, 2009 at 11:29 am
What does this ‘ready for prime time’ mean?
What you need isn’t some readiness, but rather a use case (like quick and dirty web hackery ala php) or a killer app that people wants to use. You want people to use Haskell? Go out there and make something with it that other will want to use. arguments like that there is a search engine that finds arbitrary method signatures really won’t convince anyone.
yhvd
14 January, 2009 at 11:30 am
‘The Haskell community has two search engines that trivially solve this problem: Hooge and Hayoo!’
Hooge? :)
gwern
14 January, 2009 at 11:46 am
@yhvd, @mike: We’re writing them! http://hackage.haskell.org/packages/archive/pkg-list.html
Don Stewart
14 January, 2009 at 11:53 am
I can’t reiterate how useful Hoogle and Hackage are. I always have both open when developing in Haskell.
Most answers to small problems are a Hoogle query away and the solutiont to the larger problems are a Hackage package away.
Colin Ross
14 January, 2009 at 12:58 pm
Ready for prime time absolutely amazing and i want to try it! but hwere are the ide’s at???? i can’t find a good ide for this. if you want people to like it and go crazy for it, we have to be able to easily find a killer ide for it.
rob
14 January, 2009 at 1:02 pm
Ready for prime time absolutely amazing and i want to try it! but where are the ide’s at???? i can’t find a good ide for this. if you want people to like it and go crazy for it, we have to be able to easily find a killer ide for it.
rob
14 January, 2009 at 1:03 pm
One thing about Hayoo is that unlike Hoogle, it doesn’t parse the types you give it, but just does a text search for them.
For example, if you search for `Monad t => a -> t a`, Hoogle will give `return`, but since the monad is actually called `m` in the source, Hayoo won’t find it.
Anders
14 January, 2009 at 1:16 pm
[...] citind cartea aia și verificând feed-reader-ul (multi-tasking frate ) am găsit pe reddit un articol care mi-a captat interesul. Tocmai mi-a mai fost oferit un motiv să aștept cu nerăbdare următorul semestru, un semestru [...]
The Sum of its Parts « Changing the world
14 January, 2009 at 1:41 pm
I’m gonna play the devil’s advocate but you say “GHC [...] features a rich interactive mode…”, however unlike the SML or Ocaml REPL, ghci does not let you define datatypes …
zorg
14 January, 2009 at 3:50 pm
Haskell is undeniably awesome, and you’ve rightly outlined the strong points in Haskell’s tools “ecosystem”. But if you define “prime time” to mean suitable for wide use in industrial programming, more is perhaps needed. In particular, a decent refactoring IDE, and sufficiently useful profiling and debugging tools.
Matt
14 January, 2009 at 5:12 pm
Haskell is definitely not ready for primetime, because Haskell isn’t even capable of doing the basics of programming.
It can’t handle making a collection of data without the individual fields being *global functions*
What does that mean exactly? It means you can’t freely just write two types in a file without their field names clashing.
That’s Haskell’s record system. Making the equivalent of a “struct” in this language is the most broken I’ve ever seen in any language I’ve ever worked with.
Please don’t recommend it for primetime use when you haven’t yet even matched the level of Visual Basic at REAL WORLD PROGRAMMING.
Jeremy Finkelstein
14 January, 2009 at 5:31 pm
Very good list with the exception of Darcs, which I hardly recommend for serious VC. Unfortunately, Haskell requires a relatively high level of intelligence, so it will never (IMHO) appeal to the masses as Ruby or Python (or, dear G-d, Visual Basic) do.
Seth
14 January, 2009 at 5:44 pm
mike-
> What the heck does that mean? If it’s so far ahead, why is it tricky? Shouldn’t it be LESS tricky if it’s so far ahead?!
Not necessarily; there is nothing fundamental about programming that says that the futuristic tools need to be easier to learn than the current tools. It might very well be the case that futuristic equipment is significantly better in a thousand respects, at the expense of a tougher learning curve. I think Haskell falls into this category; of course, this will put some people off, but that doesn’t mean that the language is flawed — just that it’s not for everyone.
I’d conjecture, however, that most experienced developers are willing to put in some extra learning time if the payoff is right.
yhvd -
> What you need isn’t some readiness, but rather a use case (like quick and dirty web hackery ala php) or a killer app that people wants to use.
There’s a great deal of good hackery in Haskell, though it’s not necessarily the right tool if what you want is a “quick and dirty” piece of software. If you want something of extreme quality, however, I’d argue that Haskell has proven itself greatly (the major case study is the work done at Galois Connections).
There’s a good bit of major software written in Haskell, but it’s only a couple of years old, so most people haven’t heard of it yet. We don’t have anything the size of Microsoft Office, but then again I’m not sure this is a good measure of the quality of a language (though it is admittedly a good sign that Office was written in a language that people can use in the real-world). My purpose in this post was to address the “but there’s no tools for it!” myth. Short of a Visual Studio-style IDE, Haskell has all of the tools you need.
Then again, I’m not convinced that an IDE is a necessary tool; even when my day job was full of C++ and Java, I didn’t really like using them. Judging from the popularity of languages like Python, I’m not convinced that an IDE really is a necessary component.
Jeremy-
> What does that mean exactly? It means you can’t freely just write two types in a file without their field names clashing.
For programming in the style of Visual Basic, I’d agree that this is a problem. But for programming in the style of a functional language, it is good: the record syntax is used for implicitly defining accessor functions, which is what you want in a functional programming language.
Matt-
> But if you define “prime time” to mean suitable for wide use in industrial programming, more is perhaps needed. In particular, a decent refactoring IDE, and sufficiently useful profiling and debugging tools.
A refactoring IDE is definitely important in an industrial setting; no argument there. It’s less important in smaller teams, so I don’t think that’s a killer weakness.
As for profiling and debugging, GHC has both built-in, and provides you with the ability to link much of that functionality directly into your apps (thereby making it much easier to deploy in-the-field testing).
intoverflow
14 January, 2009 at 5:53 pm
@rob: Who needs an IDE? Most people I’ve talked to on #haskell seem more than happy with editors such as Emacs and [G]Vi[m]…
Ivan Lazar Miljenovi
14 January, 2009 at 6:23 pm
Jeremy Finkelstein, you’re simply wrong. Record accessors have module scope. You can hide, show, qualify them, store them in other structures and do whatever, as they’re normal, first class functions, and all the usual scoping rules apply.
Don Stewart
14 January, 2009 at 6:53 pm
Don, still with module scope it can get inconvenient. This for instance will not work:
data D = D1 { accessor :: Int } | D2 { accessor :: String }
GHC will give you: Constructors D1 and D2 give different types for field `accessor’
Why are records not changed like proposed in “Extensible records with scoped labels” (http://www.cs.uu.nl/~daan/download/papers/scopedlabels.pdf)?
Anon
15 January, 2009 at 5:11 am
Partial translation of the trackback: I don’t know Haskell yet (only grasped a few lines of code) but I’ll have to learn it in the next semester. A period of time I hardly wait to arrive.
Haskell and Python are the most beautiful language as far as I’m concerned right now.
Mithrandir
15 January, 2009 at 5:52 am
@Ivan
Ivan, my friend, “Who needs an IDE?” Are you a programmer or a software engineer? Are you developing applications or developing full fledged systems? You don’t have to answer those questions, but my point is we are in the year 2009 and when developing large scale systems it is important to do so effectively and effeciently. If the technology is available to implement a robust IDE, then why not? Programmers and SE’s need features of an IDE to make coding and the development process in general more *effective* and *efficient*.
My other concern is, if we want Haskell to compete with C languages, VB, and Java we need to counter their pillars of success. One of those pillars is a strong development environment. (Eclipse, NetBeans, Visual Studio, and more).
Programmers need IDEs too. Even small scale systems need features of an IDE that provide another layer for ensuring quality.
When I am working on a system whether it is large or small, I often use a small, light weight editor changes. However, I always bring systems into an IDE for changes that are complicated and can be done within features of the IDE. Or else, I would spend for every in the small editor implementing the changes and still not get it as clean as the IDE could have (whether the change to the system be creating new functionality or altering existing).
I can just imagine how much time I would waste looking for functions if I didn’t have a function pane. How about build trees? Method/function hide? Save time and head ache. Work hard, but don’t forget my friend work smart too.
rob
15 January, 2009 at 10:33 am
@rob
IDE = “Integrated Development Environment.” Haskell has a development environment, it just isn’t “integrated” the same way as Eclipse or Visual Studio is integrated.
We have tools for all of the use cases you listed; they just aren’t all bundled into the same program. I know that it *sounds* like a big difference, but in practice it really isn’t.
Besides, Haskell doesn’t necessarily need to *replace* C or Java to be a successful, useful language. After all, Python lacks all of the above, yet no one seriously argues that Python shouldn’t ever be used; somehow, though, these complaints are used as evidence that Haskell isn’t developer-worthy.
You asked “If the technology is available to implement a robust IDE, then why not?”
The long answer is that Haskell thrives in the open source community, and evidently the people in the community haven’t been driven to develop an IDE (to be more precise: they *have* been driven to do so, but the projects haven’t been significant enough to be developed to the same degree that our other tools have been. Quick googling reveals a bit of history about Haskell IDEs.)
The short answer is that most people who use Haskell haven’t found an IDE to be a necessary tool for working in the language.
This seems to be the hardest thing for many programmers to accept: that when you change the language, it is possible that your development habits will change as well. Just as the best practices for writing Assembler don’t have to apply to writing Java, so too is it that the best practices for writing Java don’t have to apply to writing Haskell.
intoverflow
15 January, 2009 at 11:05 am
@anon
> Don, still with module scope it can get inconvenient. This for instance will not work:
> data D = D1 { accessor :: Int } | D2 { accessor :: String }
This is less annoying than it is convenient. For record types, you really want the fields to be functions. For instance, when I define
data D = D1 { accessor :: Int, foo :: Bar } | D2 { accessor :: Int, biz :: Baz }
I really want to think of accessor as a function: accessor :: D -> Int. By enforcing this typing requirement, that’s exactly what I get.
So that’s the advantage. Of course, you’re right — the way it is, your example doesn’t work. In practice, however, it’s not a problem; experience says that, in this case, you’re thinking about your data in the wrong way. A weak answer, I know, but “in my experience…” type responses usually are :/
intoverflow
15 January, 2009 at 11:12 am
[...] the surface of it and I’ve so far failed in my many attempts to grok how monads work. This blog post at Integer Overflow really sold me on the viability of Haskell as a serious albeit choice. Frankly, [...]
Bumblebee Labs Blog » Blog Archive » Evaluating Languages
15 January, 2009 at 12:48 pm
intoverflow….
Thanks for explaining what IDE means, it’s a tricky acronym.
“it just isn’t integrated” = not an Integrated Development Environment. My point exactly, thanks. Get it integrated, get an IDE, then ready for primetime. Work efficiently, effectively, and *smarter*.
*Replace* is what you are thinking and not what I wrote. You should *read* the comment for verification.
No one is arguing a language should never be used. Many have their appropriate implementation scenarios; this is dependent on an analysis of many factors.
There is a larger portion of the Haskell community that wants an IDE. You are judging a community base on your individual experience. Leksah, RhinoSoft, HEAT, HIDE, and if you keep digging a couple others. They are all attempts at an IDE for Haskell. All have varying success, non are prime time material. You equated the fact that the community has not been driven to develop an IDE with the need for an IDE. Even as you more specifically cite, they have not been significant. That is poor logic. That is like saying, no one has invented the seat belt or made a significant enough development involving passenger safety; therefore, we must not need one.
By the way, programmer and software engineer are two different professions. A quick Google search will explain that. May be this will clarify your understanding of the need for an IDE.
Finally, an IDE is a technology not a practice or a habit. Neither are equivocal.
rob
15 January, 2009 at 2:48 pm
@rob
I don’t want this to turn into a flame war, so I’ll be brief.
> Thanks for explaining what IDE means, it’s a tricky acronym.
I wasn’t trying to be condescending, I just needed to establish a context for my reply.
You brought up a lot of complaints about my choice of words. In each case, if you substitute your suggested language for what I said (ie s/replace/compete, s/programmer/software engineer), I’ll still stand by my claims.
And you’re right, an IDE isn’t a practice or a habit. But using one is.
I think that our core disagreement is between whether or not developers should use an IDE. I think we need to agree to disagree on this one.
intoverflow
15 January, 2009 at 5:57 pm
Are there any IDE’s for Haskell or should one use vi?
Josh
16 January, 2009 at 5:10 am
@intoverflow
**I don’t want this to turn into a flame war
rob
16 January, 2009 at 9:42 am
@intoverflow
**I don’t want this to turn into a flame war
rob
16 January, 2009 at 9:42 am
@Josh
There are a few IDEs for Haskell, though I haven’t used any extensively (I generally don’t like using integrated software environments, so I’m not a good person to ask about them :)
My work environment is pretty basic: I use vim, more or less because I know how to use it pretty well. I generally have GHCi open in another window to make sure that my code loads, and to browse my type definitions, check function signatures, etc. I also have a tab in my browser open to Hoogle and Hayoo so I can do quick “what was that function called again?” searches. I’m also generally in #haskell on Freenode in case I run into a tricky situation.
I’d be curious to know what environments everyone else uses!
intoverflow
16 January, 2009 at 9:51 am
[...] the same time, I have been following a discussion about Haskell at Integer Overflow where there has been a bit of a discussion in the comments about there not being an IDE for Haskell [...]
Does your IDE define you or support you? | Colin Ross
18 January, 2009 at 12:16 pm
Where are the IDE’s?!?! No good ones!?! Prime time is a no go without something like Eclipse or Visual Studio!
Jake
19 January, 2009 at 10:32 am
** for Haskell!
Jake
19 January, 2009 at 10:33 am
I do all my haskell projects in eclipse…. it works fairly well, not to the extent of the support it has for java, but it does a really nice job.
http://eclipsefp.sourceforge.net/
Cody
20 January, 2009 at 1:32 pm
@intoverflow, Stop pairing software engineers and programmers together and get a clue.
“In each case, if you substitute your suggested language for what I said (ie s/replace/compete, s/programmer/software engineer), I’ll still stand by my claims.”
I know this is mean, but you sound young and stupid. Sorry, I said it!
Steven
22 January, 2009 at 11:30 pm
@Steven
I’m pretty sure this is a troll, but for what it’s worth, I’m old enough to be OK with sounding stupid every now and again.
Still, I think you’re overlooking the fact that any reasonable definition of “programmer” and “software engineer” will necessarily share many properties. Trivial example: both are types of people. Meaningful example: both are involved in the building of software systems.
My intent was to suggest that my comments were drawing on the common meaning implied by those terms. If you’re going to bring forward the charge that they don’t — and that they fail to in such a monumental way as to make me “sound stupid” — then I think you owe me a more detailed explanation of where the problem is in my argument.
Specifically, what is it about Software Engineers, which cannot be said about programmers, which makes my argument so obviously false? (Or, if you’re upset about the words “replace” and “compete,” same question.)
intoverflow
23 January, 2009 at 8:05 am
[...] Update 3 Feb.! I’m still not ready to learn Haskell, but when I do, I think I’ll start here and [...]
Func. Prog. Lang. Ref. « More than a Tweet
3 February, 2009 at 10:37 am
Hello webmaster
I would like to share with you a link to your site
write me here preonrelt@mail.ru
Alexwebmaster
3 March, 2009 at 5:06 am
Hi Sir.
I learned something here. Thanks for posting.
Seaderydiah
20 May, 2009 at 9:20 am
[...] Why Haskell is Beyond Ready for Prime Time (This is the more convincing one in my opinion) [...]
Stephan Sokolow’s Blog » Functional Programming Concepts for the Lay Programmer – Part 1
13 January, 2010 at 2:06 am