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.
Integer Overflow 
Tirpen
/ 13 January, 2009Very nice post, bookmarked for whenever I want to convince someone of Haskell’s superiority. :)
mike
/ 14 January, 2009“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.
yhvd
/ 14 January, 2009What 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.
gwern
/ 14 January, 2009‘The Haskell community has two search engines that trivially solve this problem: Hooge and Hayoo!’
Hooge? :)
Don Stewart
/ 14 January, 2009@yhvd, @mike: We’re writing them! http://hackage.haskell.org/packages/archive/pkg-list.html
Colin Ross
/ 14 January, 2009I 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.
rob
/ 14 January, 2009Ready 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, 2009Ready 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.
Anders
/ 14 January, 2009One 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.
zorg
/ 14 January, 2009I’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 …
Matt
/ 14 January, 2009Haskell 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.
Jeremy Finkelstein
/ 14 January, 2009Haskell 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.
Seth
/ 14 January, 2009Very 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.
intoverflow
/ 14 January, 2009mike-
> 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).
Ivan Lazar Miljenovi
/ 14 January, 2009@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]…
Don Stewart
/ 14 January, 2009Jeremy 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.
Anon
/ 15 January, 2009Don, 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)?
Mithrandir
/ 15 January, 2009Partial 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.
rob
/ 15 January, 2009@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.
intoverflow
/ 15 January, 2009@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@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 :/
rob
/ 15 January, 2009intoverflow….
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.
intoverflow
/ 15 January, 2009@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.
Josh
/ 16 January, 2009Are there any IDE’s for Haskell or should one use vi?
rob
/ 16 January, 2009@intoverflow
**I don’t want this to turn into a flame war
rob
/ 16 January, 2009@intoverflow
**I don’t want this to turn into a flame war
intoverflow
/ 16 January, 2009@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!
Jake
/ 19 January, 2009Where are the IDE’s?!?! No good ones!?! Prime time is a no go without something like Eclipse or Visual Studio!
Jake
/ 19 January, 2009** for Haskell!
Cody
/ 20 January, 2009I 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/
Steven
/ 22 January, 2009@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!
intoverflow
/ 23 January, 2009@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.)
Alexwebmaster
/ 3 March, 2009Hello webmaster
I would like to share with you a link to your site
write me here preonrelt@mail.ru
Seaderydiah
/ 20 May, 2009Hi Sir.
I learned something here. Thanks for posting.
Orphi
/ 27 February, 2010Much as I love Haskell, I’m afraid I must disagree that it is “ready”.
1. Hackage has the *quantity*, but not yet the *quality*. Most packages are 1-man hobby projects, often with little or no documentation.
2. Cabal fails to build Haskell-to-C bindings on Windows. This means that all of the *most important* packages on Hackage won’t work on Windows. So no GUI, no DB access, no multimedia, no compression or cryptography, nothing.
[Fortunately, Gtk2hs provides binary packages for Windows. Intermittently. Otherwise there’d just be no GUI *at all* for Windows.]
3. We have tools like Cabal, Haddock, Darcs and so forth, but they’re all a bit immature. Not unusable, just immature.
Haddock’s markup is ad hoc and poorly documented. Cabal doesn’t use XML or other common format for package description, instead using a (poorly documented) custom format. (E.g., did you know that backslashes have to be Haskell-escaped? It’s not documented anywhere…) Cabal doesn’t seem to support optional dependencies, or multiple packages that can provide the same feature, or anything else you’d expect of a “real” package manager. There’s Cabal and then the separate Cabal-Install tool [which isn’t part of the standard install]. I could go on, but you get the gist.
3. Windows support isn’t fantastic. It’s OK, but not brilliant.
For example: Why the hell does installing GHC only install it for the administrator running the installer, and not for all users? Why does installing Graph Vis make Gtk2hs stop working? Why does the expression
doesDirectoryExist “C:\\”
return False? (This one, I’m told, is due to the POSIX emulation layer that the Haskell I/O subsystem does through.)
I might also mention that the GHC team seem strongly opposed to implementing dynamic linking on Windows because of the “DLL hell” problem that stopped being a problem about ten years ago…
A minor quibble: You say that “DPH is great!”, but it doesn’t actually *work* yet. When it’s finished and usable it’ll be great. ;-)
All of these problems can be, and maybe will be, fixed. But I feel Haskell needs to attain a critical mass that there are enough developers working on it for this to happen. Currently there just don’t seem to be enough people available to test and fix stuff.
Orphi
/ 27 February, 2010Heh, I hit send too soon.
The Haskell Community. Apparently I’m part of a different Haskell Community to everybody else.
If you ask “what does ~ mean?”, you’ll receive literally THOUSANDS of replies within seconds. If you ask “how do I get wxHaskell to build on Windows?” you will receive blank silence.
Easy problems get answered very quickly, but more difficult ones tend to get ignored or forgotten. Not out of maliciousness, but just because nobody knows the answer.
I regularly visit the Haskell IRC channel to find 700+ users connected and nobody speaking. Ask a question and listen to the silence.
Maybe I live in the wrong timezone or something?
Ivan Miljenoviic
/ 27 February, 2010@orphi :
1) How does the Quantity vs Quality debate compare to other “similar” languages such as Perl, Python, etc. ? I seem to recall that the vast majority of Perl’s CPAN packages are of rather dubious quality…
2) I would argue that this is a failing of the OS in terms of providing information for Cabal to be able to build those bindings, possibly coupled with a lack of Windows-proficient programmers who are interested in and capable of solving such problems.
3) I find the Haddock documentation explains the syntax rather well: http://www.haskell.org/haddock/doc/html/index.html . Also, Why should Cabal use XML or some such? It is a textual description of the project in question. With regards to the Description field, etc. my understanding is that the backslashes have to be escaped because it uses Haddock to render the Description on Hackage, and in Haddock /foo/ means that the text “foo” is emphasised (i.e. italicised). And I hate it how people keep calling Cabal a package manager: Cabal is the Common Architecture for Building Applications and Libraries: that is, it’s a textual description of that projeect and hwo to build it. There are flags support for different builds, etc. Cabal-Install is just there to make it easier to interact with the packages on Hackage, especially for people who don’t use an OS/Distro with decent Haskell support.
And no, I don’t get the gist about why they are all “immature”. I have no problems with them (though I wish Haddock had support for bold markup as well as italics…).
4) Can’t comment; I try to avoid that particular OS as much as I can (partially because of these kinds of problems). But I thought that the Haskell Consortium had implemented DLLs on Windows with dynamic linking…
5) Maybe people don’t comment on wxhaskell because they don’t know how to answer? What would you prefer: no answer or a lot of useless ones saying “no idea”? And I very rarely (no matter what time of the day; I’ve been on #haskell pretty much around the clock and always had people there) find #haskell to be quiet. Again, possibly no-one answers because they don’t know the answer. For example, I wouldn’t know how to build wxhaskell on _any_ OS, etc. since I have no need for writing GUIs in Haskell.
Orphi
/ 2 March, 2010@Ivan:
1. Never having used Perl or Python, I couldn’t possibly comment. (Not sure in what way these are “similar” to Haskell. Certainly they’re both wildly more popular and they’re both a completely different kind of entity.)
2. I suspect lack of developers is probably the main problem here. As I say, if Haskell ever reaches critical mass, this should get fixed.
3. OK, how about this: If a module description begins with the magic words “Stability”, “Portability” and “Maintainer” (but only in a certain order), this gets put into the documentation header. But if those words appear in the wrong order, they appear as part of the module description. (And, amusingly, the correct order is NOT the order in which the fields appear in the document header!) I cannot find this fact documented or even mentioned *anywhere* in the Haddock documentation. (I also can’t figure out why bullet points work in the source markup, but not in Cabal package descriptions…)
Why should Cabal use XML? Because everybody already knows what the parsing rules for XML are. If it used XML, you’d just have to specify what the element names are and what they do. As it is, you have to define the entire file grammar. XML may not be the best standard ever, but standards exist for a reason.
And the escaping is nothing to do with Haddock. I had to escape the backslashes in a filename. It wouldn’t surprise me if Cabal is just using the standard Read instances for this stuff. It’s not a crushing problem (although it IS very irritating), but I don’t see it documented anywhere.
I’ve repeatedly asked what Cabal is supposed to do, and repeatedly got no answer. (Astonishingly, the documentation doesn’t seem to explain this.) I would have thought if you just want to compile some code, you just give it to the compiler and say “compile this, please”. You don’t need a tool for that. Given that Cabal provides a way to describe “packages” and specify dependencies, it certainly *sounds* like a package manager to me. As I say, nobody has ever clearly explained to me what it’s purpose is supposed to be.
The tools are “immature” in that they all work, but they’re a bit rough around the edges. The quality is variable. The documentation is sometimes an afterthought. Sometimes tools assume things which aren’t true for everyone. (Not so long ago, people were recommending the use of Bash scripts in your Cabal packages!) If enough people start using these things, it should all get smoothed out.
4. I know lots of people don’t like Windows, but it *is* the biggest desktop OS on the market. And Haskell is supposed to be cross-platform. (IMHO the language itself actually does this rather well. We also have lots of nice libraries for doing things in a portable way – e.g., System.FilePath.) And no, the Haskell Consortium got dynamic linking implemented *on Linux only*. Windows is supposedly on their to-do list. (But judging by the off-hand comments from the GHC devs in a video I saw, it seems they don’t like Windows very much either…)
5. Like I said, “not because of maliciousness, just because nobody knows the answer”. And while I have never, ever seen #haskell with less than 400 users connected, sometimes 30 minutes or more can elapse between people saying anything. (And sometimes it’s so loud you can barely make yourself heard – but not often.)
Curiously, regardless of traffic, if you say “@seen dcoutts”, Duncan always magically appears. I don’t know how he does that…
To summarise: I’m not saying Haskell will *never* be ready. I’m just saying it’s not quite there yet. (I gather it’s a lot more ready now than it used to be…)
ram
/ 7 January, 2011“Real World Haskell” is an excellent book to learn haskell from. What is missing are a bunch of cookbooks — many enterprise devs would not have the time to come-up with solns on top of having to master a new language — need at least 3 books:
(i) cookbook for doing regular things — read/write files, sockets, process control, db access — like typical Java/C# cookbooks
(ii) cookbook for web activities — SOA, XML, Web Services, REST etc
(iii) cookbook for special topics — distributed/parallel programming, debugging, tuning etc
Haskell is a wonderful language, but lacks customer (i.e. enterprise developer) focus — haskell community needs to stop pointing out haskell’s superiority because no one wants to feel stupid, a normal experience whenever learning anything new — writing Haskell for Dummies/Beginners type books would help — a book contrasting how code in Haskell can be more efficient than Java/C#/C++ would go a long way
Flat Rate MRI Coil Repair
/ 9 April, 2013You could definitely see your expertise in the work you write. The arena hopes for more passionate writers such as you who aren’t afraid to mention how they believe. All the time follow your heart.
Cyrus Allvin
/ 17 February, 2017Reparacion urgente de lavadoras en Madrid, servicio técnico ofrecido por la empresa Abeto Hogar S.L., contamos con un servicio urgente de reparacion de lavadoras, todos sabemos el contratiempo que causa que cualquier electrodoméstico se averíe, pero cuando se trata de la lavadora nos parece que la suciedad ha invadido la vivienda y no hay nada en ese momento mas importante que reparar la lavadora.
las vegas estate planning attorneys
/ 16 March, 2023Hello there I am so grateful I found your site, I really found you by mistake, while I was browsing on Google for something else, Nonetheless I am here now and would just like to say kudos for a tremendous post and a all round exciting blog (I also love the theme/design), I don’t have time to read it all at the minute but I have bookmarked it and also added in your RSS feeds, so when I have time I will be back to read much more, Please do keep up the superb work.