What it's like to use Haskell

http://engineering.imvu.com/2014/03/24/what-its-like-to-use-haskell

by tikhonj • 12 years ago

378 300 12 years ago

engineering.imvu.com

amirmc• 12 years ago

It's good to hear stories about how FP is being used in industry and I'd like to read more.

For those who have an interest in this, I recommend the Commercial Users of Functional Programming workshop (http://cufp.org). It's where I first heard about Facebook's use of OCaml to create Hack (http://www.youtube.com/watch?v=gKWNjFagR9k)

teemo_cute5• 12 years ago

While visiting your link (http://cufp.org), I saw Chester Bennin of Linkin Park fame there. I didn't know that he's also a programmer! Programming in a functional manner. Another Wow!

omaranto3• 12 years ago

Isn't the Linkin Park vocalist named Chester Bennington? I think you're off by a gton.

kristianp• 12 years ago

It always surprises me to see these imvu.com posts on HN. They are often insightful and interesting, but when you see the website you wonder who pays money for this. Do they sell virtual goods for their own virtual world, similar to secondlife?

teemo_cute5• 12 years ago

They do. I was once an active IMVU user. Outward appearances can be deceiving, but believe me they are profitable. If you read Eric Ries book 'The Lean Startup' you can have a glimpse of IMVU's back story there.

piokuc• 12 years ago

Yeah, IMVU is a company behind a product which most people know about because of the "Lean Startup" book, not because they used the product itself. I must say I read the book with great interest but I never found the product itself interesting enough to even have a look at at :)

doesnt_know• 12 years ago

Here is the shop: http://www.imvu.com/shop/

Clothing, Furniture, Rooms, Avatars.

I've never heard of imvu before but I don't see how it's any different than micro-transactions within a MMO. If anyone plans to make the argument that MMO's are different because they have "gameplay", then you're probably someone that has never played a very social MMO before.

As an ex-EVE player, I can say with extreme confidence that at least 80% of our alliance ("guild"/social group) was not there to actually play the game. It's pretty common that after a certain amount of game time, you just see the "game" as a glorified chat room. It was an ongoing joke to point out how most of us paid $15 to CCP every month for the ability to talk to each other over XMPP.

auvrw• 12 years ago

i'd like to hear more about employers' perspectives on hiring for "an uncommon language without a comparatively sparse industrial track record." there was some debate about it in the clojure 1.6 release announcement. the author of the article didn't find it to be a problem, but then he was apparently only hiring one person.

good post, Tikhon!

copergi19• 12 years ago

I've had experience on both sides, plus know some other people who have been recently hiring haskellers. I have a huge problem hiring haskell people because the company I work for kinda sucks. I don't want to work here, so I can't really be surprised that nobody else does either. Haskell users seem to be more picky about where they work and what they work on, so if you've got micromanagement and "do this wrong because I said so" going on, you'll have a hard time. Where as you can still easily get hordes of PHP programmers willing to tolerate anything.

On the other hand, someone hiring remote haskell programmers for a company where the culture values quality had 100+ applications for half a dozen openings and really has their pick of a lot of top notch people. I think if you can offer a good job, finding haskell people isn't a problem. But if you can't, then I would stick to popular_language_x.

hibikir• 12 years ago

Not all uncommon languages are made equal. It's very different to hire someone to work on Scala than it is to hire someone to work in PICK.

I believe than when push comes to shove, the language your team uses is not the primary determination of the quality of your software. I've actually seen good programs in PICK, an ancient abomination that nobody should be using today. Your major difference is people. Good developers with a good direction will give you good software. Bad developers with the same toolset will give you bad software. So, if anything, your language selection is important because it gives you a very different talent pool.

Hiring a Scala developer, for instance, isn't all that easy, but it's definitely not impossible. For the extra pain you pay in finding someone that will use Scala instead of Java, you get, in exchange, a major filter on your applicants, which tends to be a good thing.

With an antique like PICK, the filter works against you, because what you get is the very old that have not moved on, and the desperate.

I do not think that getting more and more exclusive gets you a better filter, even when you are looking for relatively hip, uncommon languages. Is your Clojure developer naturally better than your Scala developer? How about Haskell? It's not really an issue of every filtering picking the best, but picking people that care about their tools.

So if someone told me that they are hiring developers, and that they completely lack a network to pull them from, it'll be easier to get a good core of developers in one of those uncommon languages than if you just place an ad for people that have 10 years of Java experience. This situation is uncommon though: If you are hiring, you typically have a network. Then what you do is to target some of the best developers you can get a hold of, and hire around the technologies they want to use. You'd be surprised by how much money a competitor has to pay a developer to poach them out of you if they really like your current toolset, but aren't really all that fond of the one the competitor uses.

We decided on Scala because our seed team wanted to use it, and just went out and hired locals that had similar technology interest. We also brought in a few major independent consultants that made sure our core team really understood the language, instead of just staring with good developers with little experience in their toolset. Overall, our experience was very positive, and we have a happy Scala crew.

Of course, YMMV.

mightybyte11• 12 years ago

When I left my last Haskell job, my employer put out ads to the Haskell community and quickly got a pool of 5-10 solid applications. A good number of those were from people outside the U.S. which was a no-go for them. After waiting a few weeks they decided to open it up and not require Haskell experience. I looked through a number of these resumes and there was a massive drop in quality. It was like night and day. None of those applicants were even remotely interesting IMO. They ended up waiting a few more months and finally found a Haskell applicant in the U.S. that they were happy with. If you're willing to accept people working remotely your chances of finding someone are much better.

noelwelsh3• 12 years ago

I can't like this post enough. It affirms everything I believe to be true about developing software using modern languages. I wish more developers would invest more time in learning better tools.

lallysingh2• 12 years ago

It's funny. I want to either give your comment a "+1 Me too!" response, or a huge rant on software quality and the language quagmire we're in with weak (C++/Java) or missing (JS/Python) type systems.

To throw a statement out there without substantiation, and then cowardly running away, I'll say that Haskell feels as easy as Python, where in Python you have to do a little thinking about what types of objects get passed where, often while debugging, in Haskell you have to figure out the types of data/functions while compiling. The result, I feel, is about the same amount of work. The difference is that the Haskell result is substantially, /substantially/ easier to use in larger projects.

Again, that's without substantiation, and with me immediately running away in cowardice!

ixmatus• 12 years ago

Haskell is definitely not as "easy" as Python but I actually think it's more straight forward than Python is. There's more cognitive work up-front but the pay off is very big in terms of stability, maintainability, etc... in the long run. I actually think it costs less in amount of work to do something in Haskell than in Python (and Erlang, even).

When I have to drop into Python or Javascript I feel like I'm pulling out my MiniTonka toys vs. the actual dump truck out back by the barn. When I went from PHP to Python it felt like that too.

As it stands though, I write systems critical services in HS now and keep the web app stuff in Python. I have written two production web apps in Snap and I loved every minute of it.

pekk• 12 years ago

I guess saying "This." didn't seem verbose enough.

Let me propose an incredibly controversial idea: Haskell isn't a better tool, it's just yet another tool. Which is aggressively promoted not so much with actual benefits, but by trying to shame people who prefer other tools by calling them dullards and telling them that they don't know what they are doing.

davidw• 12 years ago

"This." is an abomination, a pox upon the English language, and, what's more, serves absolutely no purpose on a site with little arrows to vote for things you like.

m0a0t0• 12 years ago

by trying to shame people who prefer other tools by calling them dullards and telling them that they don't know what they are doing.

I think this a minority but I have seen this. Generally with languages that have their roots in the more science side of things there is an air of elitism. For example quite often a venn diagram is posted which implies programs (or programmers, can't remember) not made/using type systems are worse.

The Haskell community aren't too bad though

collyw3• 12 years ago

But most of the time management want something working by yesterday. That usually seems to trump code quality / maintainability.

tel15• 12 years ago

And if your production timescale is longer than "next week" that's a failure of management and planning, not tech.

pron5• 12 years ago

Switching a programming language is a major decision for a company. It requires changing the runtime library and possibly re-writing a lot of in-house infrastructure. While personal affinity to a language is important, making a decision for a company might have substantial business consequences.

For a company, overall language adoption, availability of libraries, tools and talent (and I'm not talking about training someone to be productive; sooner or later you need real experts and training an expert is expensive in any language) are extremely important. That's why when choosing between two languages, assuming both are well suited to the job at hand, a company should always pick the one with the wider adoption unless the other is so significantly "better" to trump lesser adoption. And the smaller the adoption, the "better" the language needs to be.

There's no doubt Haskell is an excellent programming language. I'm learning it and enjoying it. But because it has such low adoption rates, it needs to provide benefits that are orders of magnitude higher than other, more popular languages. I guess that for some very particular use cases it does, but I just can't see it in the vast majority of cases.

Hobbyists can afford playing with different languages, and can (and perhaps should) jump from one to the next. Companies can't (or most certainly shouldn't, unless for toy projects); they should pick (wisely) a popular language that's right for them, and just stick with it.

BTW, I think that if a company does want to try a good, though not-so-popular language, it should pick a JVM language, as the interoperability among JVM languages, and the availability of libraries that can be shared among the popular and less-so JVM languages, reduces much of the risk.

boothead• 12 years ago

I about 50% agree with you here. The factor that you're forgetting is the filter effect: Haskell is not adopted, it's learned after a thankless (there are no jobs) process of deep study. This means that the quality of available talent is of a much higher standard. If you adopt a technology with these characteristics, and you're one of the few who are hiring in this pool then you have a significant advantage!

The only risk in my mind is when the big boys figure it out and start gobbling up Haskellers! :-)

pron5• 12 years ago

I think this is a bad filter. I'd rather filter prospective employees based on an ambitious algorithm or a complex project they've done. Most of the people I know that like solving hard problems with novel data structures, algorithms, or mechanically-sympathetic implementations are averse to spending time on learning new programming languages. It seems to them (and to me) like focusing on bling rather than on substance.

Of course, this is a crude generalization, and obviously, anyone who's interested in learning any new, perhaps unappreciated, and difficult skill would make a good hire, and Haskellers are no exception. But I wouldn't filter based on programming language preference.

collyw3• 12 years ago

This is my worry with Python. Its a good language, but it is too easy to learn.

implicit9• 12 years ago

Author here.

We've trained a few people up on Haskell at IMVU now, and I'm starting to think that learning Haskell is at its very hardest when you're building tiny toy applications and all you have for answers are google searches and books.

It seems to help a lot to root the learning process in a specific concrete goal, in an existing codebase that already has idioms and patterns in-place, and to offer direct access to people who have answers to newbie questions.

moron4hire2• 12 years ago

I see it the other way around. It's easier to find experts in esoteric languages because you don't have to sift through the same piles of dullards that use main stream languages. A person who has chosen to use a language like Haskell is probably not your average brogrammer.

Also, PHP in particular is so bad, to become an expert in it suggests a willing blindness to its problems, or a general attitude of "live with problems" that converges to a complete shit sandwich over time. When one could have just switched to something else so long ago, PHP is a point against any claim of being a software expert.

It is just like the traffic in DC: whatever your arguments against doing anything about a bad situation because "we don't have the time" or "we don't have the money", it ain't getting any better in the future. If you don't fix it now, it won't ever get fixed.

judk5• 12 years ago

It is a moral crime to recruit the Haskell pool for its precertified geniuses, and then force hek to use Java and Python.

nbouscal7• 12 years ago

My experience is that popularity does matter a lot, but that the value of popularity is logistic rather than e.g. linear. Not enough popularity does make using a language in production unrealistic, but there is a threshold of usability after which increased popularity seems to have rapidly diminishing returns. I would argue that Haskell passed this threshold a couple years ago for most use cases. There is still a lot of work to do on cabal and some of the core libraries, but we're happily using Haskell in production, and for us the benefits very clearly outweigh the occasional difficulties.

lallysingh2• 12 years ago

I don't think you need orders of magnitude improvements to get a large adopted base [Note: I'm specifically not saying "rate"]. Just wait for new projects (or new companies) who're looking for which one is just marginally a better/funner/cooler choice over the rest. They'll accrue credibility for the language, and that'll add to it's case for usage in organizations that have already selected languages, and are looking for new ones. I think an organization that's been paying for a prior PHP choice would be quite happy to jump into Haskell, but is just waiting for a little validation of their choice with some more success stories.

And that's not really a function of metrics, it just needs a few well-spoken cheerleaders with a few good stories.

The largest issue Haskell has with adoption is its intentional avoidance of (at least, mainstream) cargo-cult programming culture. The "avoid success at all costs" attitude makes cheerleading Haskell as a proper, valid selection for betting your project less cool. The best you can do is "look, I got away with using Haskell!"

nbouscal7• 12 years ago

I think it's fine to cheerlead for Haskell, as we're all happy to increase the size of the community. What we don't want is for the community values to be diluted by that size increase, which is the sense in which "avoid success at all costs" seems to be meant. For example, I'm always happy to help someone understand monads, but I would be very unhappy if that involved renaming them to "workflows".

dasil0036• 12 years ago

That's why when choosing between two languages, assuming both are well suited to the job at hand, a company should always pick the one with the wider adoption unless the other is so significantly "better" to trump lesser adoption.

I think it plateaus at a certain point. You don't need the largest community, you just need critical mass so you don't have to build everything yourself. In fact, at some point being the biggest ends up diluting the talent pool because of the number of people getting into it for the money, and this is becoming a much bigger problem as the traditional job economy dries up and the demand for programmers increases.

As to being "significantly better", I think Haskell has that in spades. In fact the things that make Haskell better are probably difficult to appreciate by a lot of younger programmers who are using relatively new languages and frameworks like Node and Rails. When you start seeing the effects of code rot and programmer turnover on a codebase over time, the types of static checks that are a couple orders more powerful and simultaneously less verbose and restrictive than what most people think of when they hear "static language" (ie. Java), then Haskell really starts to shine.

Personally I think companies that invest in Haskell are going to start seeing major dividends in terms of productivity and agility over the lifetime of the company.

meric3• 12 years ago

I don't disagree with your major point - "companies that invest in [[functional programming languages with a strong typing system]] are going to start seeing major dividends in terms of productivity and agility over the lifetime of the company." Haskell in particular I'm not sure of - the 'code rot' could easily manifest itself in performance. Haskell's laziness makes slow code and code that use up a lot of memory hard to locate, and at times require significant refactoring, to correct, though this is offset by haskell's type system somewhat...

You can see this manifesting in the project of the article's author under the "Not All Sunshine and Rainbows" section.

What I'm getting at - Bad code can be written in any language. IMO what's more important with regards to the language is how easy does it make to fix it.

I've only used haskell for my thesis project as well as having toyed with it in my free time now and then over the past two years, and have no commercial Haskell experience, so perhaps someone with more experience can chime in...

EDIT: A Haskell project I was working on: http://stackoverflow.com/questions/21654081/how-do-i-optimis...

ulisesrmzroche7• 12 years ago

Every year I read on HN that this year is Haskell's year. What's so different about 2014? The whole 'only for REAL PROGRAMMERS ' argument still hasn't gotten any traction, my dudes, lisper's been trying it since the beginning of time.

Anyone got a link to a good todo-mvc implementation or something like that?

microtonal2• 12 years ago

I used to agree with that, but I think the interoperability of JVM languages is overstated. For instance, using a Scala library from Java or Kotlin is a painful experience, unless its developers invested time to export a Java-friendly API (e.g. to some extend Akka).

The situation for Haskell/C is comparable to that of Scala/Java. It is easy to use Java libraries from Scala, but hard to use Scala libraries from Java. In a similar fashion, it is easy to use C libraries from Haskell, but hard to use Haskell libraries from C.

My experience with large projects is that it is more important to avoid using a large mixture of languages without clearly defined boundaries. E.g. nowadays it's popular to use a mixture of C, C++, Python, Cython, and perhaps even a little Prolog on the side. And while it all links, it is very hard to maintain, debug or for a new developer to get into. Pick one language/ecosystem and stick to it.

loup-vaillant8• 12 years ago

Pick one language/ecosystem and stick to it.

For a given executable, you mean. One exec, one team, one language ecosystem ("C + Lua" would count as one ecosystem).

By the time two different team work on two different executables, the boundaries you speak of are pretty clear: the two pieces of program will communicate through inter-processes means: files, pipes, sockets… At that point, you don't really care about programming language mismatch: the only common logic will be parsing and generating the common formats. If those are simple enough, you simply won't care. And if they are not, you can always use a compiler generator that outputs C code, and use that in both programs (most ecosystems have a C FFI, so that shouldn't be too hard).

mattgreenrocks2• 12 years ago

I've worked on projects with single executable deliverables that needed two languages: Python for the interesting bits, and C for the fast bits. FFI is not always fun (I used ctypes) but there was really no other way.

mightybyte11• 12 years ago

It requires changing the runtime library and possibly re-writing a lot of in-house infrastructure.

I think this is a bit overstated. (See below.)

BTW, I think that if a company does want to try a good, though not-so-popular language, it should pick a JVM language, as the interoperability among JVM languages, and the availability of libraries that can be shared among the popular and less-so JVM languages, reduces much of the risk.

For the most part I think this advantage of JVM languages goes away if you design your system as loosely coupled services. Amazon is the canonical example of this, but I've worked in places where C++ and Java were used together easily because of this kind of design.

Also, I'll echo some of the others and say that Haskell has pretty good adoption and a fantastically helpful community. Three or four years ago I would have agreed with you, but the community has come a long way in the past few years.

new_guy123• 12 years ago

This argument is called "Go home and use Java" in latin.

Infact, by this logic it is impossible for any language to be a competitor to java, because it is trumped in community, adoption and programmer replacability.

The diff any language can offer cannot be more than the advantage java has in these three aspects for a guy who wants to use java. Typically, you will find the good java advocate agreeing that the shiny new language is better - but common the net advantage is "trumped" by java's reach.

In case someone has ever convinced the seasoned java advocate, please share your angle of attack and the language of your choice. I don't think there are any.

pron5• 12 years ago

I think there are.

Java was not the first popular programming language, and software has been around long enough to know how language adoption works. The secret is incrementalism. If you want to consider the Java world, then Java was an incremental change in syntax over C++ and a revolution in the runtime, while other JVM languages might be an incremental change in use of the runtime but a revolution in syntax/concepts.

So incrementalism is one way. The other is picking a niche. Some languages are widely used in certain industries because they are particularly well suited to some use cases. That kind of success is often enough, but sometimes a language might expand from its original niche after having achieved success there.

But in many cases, the sentiment you're reeling against is actually correct. The fact that language B is better than language A does not always (or even often) mean that the best course of action for the organization is to adopt language B. Switching a language has a very significant cost, and it's a change that a company should never consider more often than once every five years and optimally not more than once a decade, unless language B is so advantageous that it would be stupid not to switch. Well, that's assuming the choice of language A was wise in the first place.

Because the switching cost is high, there's a very high bar to competing successfully, as there well should be.

copergi19• 12 years ago

I think you are vastly overstating things. You need an acceptable level of adoption. One where there are high quality libraries for common needs. One where you can hire experts. Beyond that level, increasing popularity doesn't really get you anything. Haskell is already beyond that level.

jfischoff6• 12 years ago

Haskeller at IMVU.

Haskell could still benefit from a larger community. We have had to write some key low level tech, but we have been able to do so at an incredible pace.

The /dev/urandom bug mentioned was caught by us because we are one of the few places using Haskell that also has a fairly large user base. If the community was larger we would have run into less issues.

That said, we have run into a surprisingly few amount of issues :)

dscrd2• 12 years ago

So always choose PHP?

chadaustin3• 12 years ago

Hi pron, you're absolutely right. Transitioning to a new language and runtime is a huge undertaking. I work with Andy, the author, and he took exactly the right steps in getting Haskell adopted. Nothing was forced through, and he got both engineering and executive buy-in for the transition.

We do not use Haskell exclusively -- we also have a pile of PHP and some Python -- but it's awesome to have such a great tool at our disposal. I've been very impressed at how mature GHC's runtime system is. The Haskell services have run perfectly for months with no problems.

The Haskell type system even lets us say, for example, that you cannot talk to MySQL within a Redis transaction, preventing entire classes of bugs.

(I have many complaints about Haskell too, but net net, it's an enormous win over PHP and Python.)

tinco2• 12 years ago

The Haskell type system does not let you do that by default. What kind of monads do you use? Are they part of some library or did you develop them in house?

Do you have a policy around the use of I/O monads versus specialized monads for controlling access like that?

lanna• 12 years ago

Always use the best tool for the job. As long as it is compiled, statically typed, runs on the JVM, and blends functional and OO programming seamlessly.

loup-vaillant8• 12 years ago

What do you mean, the job ad was tailored to this specific person?

implicit9• 12 years ago

Hi, I'm the author of the article.

I think you're right, and I think Haskell delivers on your definition of "better." I chose to try Haskell because I've been through a lot of agonizing maintenance work and I'd much rather do it in an environment that has mandatory, pervasive static analysis and tests that are by default isolated from all possible nondeterminism.

We don't have any 8-year-old Haskell yet, so I can't fairly compare it to refactoring our PHP codebase, but I have made a few sweeping changes to our 60k lines of Haskell over the past year and a half. It tends to be mostly effortless, no matter how much code needs adjusting.

jwatte• 12 years ago

As the executive sponsor for this effort, I'd like to point out that we considered a wide variety of options. Java (and other JVM languages) as well as node.js, ruby, python, C++, and others. We also already had in-house Erlang experience, but chose not to go with that for web services for various reasons. Haskell really is special, in that it represents a very strong point very far out on the "statically typed" spectrum. Among the options, it had the best bang for the buck. Erlang was also functional, but not statically typed. C++ was statically typed, but not functional. The others were largely not sufficiently better than our existing PHP solution, and/or were beat out by Haskell in the consideration. It's also important to understand that Haskell is not replacing PHP; it's augmenting PHP. We have many millions of lines of PHP running, serving many millions of active users, and there would be very little value in porting the "long tail" of that business logic. Meanwhile, there is huge value to be un-locked in gaining tight error checking and great performance on the "important core."

rlander• 12 years ago

I'd be really curious on why you chose not to go with Erlang. Could you expand on that a little?

pnathan• 12 years ago

I'm profoundly puzzled by your statement. Most of the really high quality developers I've seen have at least poked Haskell - the really lousy developers don't even touch it.

One way to phrase my objection is that popularity is a really good measure of how many really bad developers exist for a language. I am not interested in being replacable by a really bad developer, working with them, or hiring them.

Haskell (and a few other languages) occupy a very nice space where entire classes of errors are wiped out by language design (null pointers); other classes are strongly limited by the type inferencing. This bonus in particular scales non-linearly with the LoC of your codebase due to the interaction of multiple components of the codebase all having to be type safe.

Kiro• 12 years ago

The problem I had with Haskell when trying it out was that every time I wanted to use a package with dependencies I ran into "cabal: Error: some packages failed to install. The exception was: ExitFailure 1.". The solution was most often trying earlier versions of the package until it worked or not use the package at all. Cabal just seemed so broken.

chopin• 12 years ago

Not to diminish the Cabal problems here, but you run into similar problems with Maven as well. Version management is a real hard problem. Especially when there is little awareness in producing compatible successors. Especially this problem made my experiences with Haskell somewhat bitter. But I have the same problem (in really productive code) with Maven. Writing a working Maven plugin can be made pretty challenging by that as especially the stuff you want to use in Maven plugins is burdened with incompatibilities.

So, Cabal is in good company in that regard.

bjourne3• 12 years ago

Haskell packages like to specify requirements using both a lower bound and an upper bound. So package A depends on B being version 0.55 <= B < 0.99. Package C depends on B being version 0.90 <= B <= 1.35. So if you installed C before A you will get version 1.35 of B and will now need to either downgrade B or have two versions installed. Chaos ensues.

Why Hackage packagers like to specify upper bounds I'm not sure of. Backwards compatibility either is very hard to achieve in Haskell or maintainers just don't care that much about it. I don't know about Maven so I can't say whether that is as bad. But at least pip, npm and gems are a breeze compared to cabal.

creichert07• 12 years ago

Using cabal sandbox'ing helps avoid this issue.

dscrd2• 12 years ago

It's not really cabal but libraries that are broken. They tend to define dependencies too liberally with >=, which obviously breaks things when the depended library makes non-backwards compatible changes.

Also, the primary language implementation itself makes rather large changes sometimes.

soofaloofa• 12 years ago

This has been my experience exactly. It was such a problem that it really turned me off of trying to use Haskell for a serious project.

nbouscal7• 12 years ago

Cabal has been the focus of a ton of work lately, much of which is still ongoing. It has been improving rapidly, notably with sandboxes in 1.18. It still has a long way to go, admittedly, but I find myself having trouble with it way less frequently now.

codygman• 12 years ago

so a dumb little thing that fixes that a lot:

--max-backjumps 10000

Also the latest HEAD of cabal has the freeze command which is remniscient of pip freeze.

jroesch5• 12 years ago

Cabal sandboxes have fixed a lot of these problems, usually this results from having installed all packages globally, and then cabal tries to find a satisfying version between all global packages and fails. You can also take Ed Kmett's approach and just do --force --reinstall every time. I prefer the sandboxes though, when something breaks you can always nuke the sandbox and quickly reinstall. I would recommend upgrading to Cabal 1.18.x and try the sandboxes out.

iaskwhy2• 12 years ago

I didn't know what Haskell code looked like so I went to the official website and there was this code example[1]:

qsort (p:xs) = qsort [x | x<-xs, x<p] ++ [p] ++ qsort [x | x<-xs, x>=p]

Is this a good example of good Haskell code?

[1] http://www.haskell.org/haskellwiki/Introduction#Brevity

emillon2• 12 years ago

It indeeds looks a bit magical, like the infamous fibonacci example that uses lazy lists.

I don't think that list comprehensions are very idiomatic in Haskell, one would probably use Data.List.partition instead:

    qsort [] = []
    qsort (p:xs) = low ++ [p] ++ high
        where (low, high) = partition (< p) xs

microtonal2• 12 years ago

I think you are missing the recursive calls ;).

thetwiceler• 12 years ago

Absolutely not. I'm actually very frustrated that they give that code as an example. First of all, it misses the most important of quicksort - the fact that it can be implemented in place (and yes, you can write an pure in-place quicksort using STArrays).

Second of all, it's bad because it runs through the list xs twice. Instead, they should use the partition function to get both the left-hand and right-hand sides at once.

And thirdly, it's inefficient by use of the (++) operator, which takes time proportional to the length of the left-hand list. A better (out-of-place) implementation of quicksort would use an accumulator so this wouldn't happen (and actually, this means that we should do the partitioning ourselves rather than using the partition function as mentioned above).

Here is an example that makes these improvements with quicksort [1].

[1] http://en.literateprograms.org/Quicksort_(Haskell)#Using_an_...

ww22• 12 years ago

This is a typical pitfall of many FP code chuck examples. trading efficiency for superficial succinctness.

th0114nd• 12 years ago

I'd say it's good in the sense that it is readable provided you are familiar with the syntax for list comprehensions and appendings, and obviously correct if you know quicksort.

dllthomas21• 12 years ago

Unless you consider part of the definition of quicksort to be "in place".

nbouscal7• 12 years ago

List comprehensions actually don't tend to get used very frequently, so I would not point to that as a good example of what Haskell code looks like. It's hard to point to one example, as different parts of the code look very different. That is, pure functions look very different from monadic functions, which both look very different from datatype declarations and typeclass instances. I would recommend poking around a whole codebase, one example of which can be found here: https://github.com/xmonad/xmonad

This post may also be useful: http://blog.ezyang.com/2011/11/how-to-read-haskell/

marcosdumay• 12 years ago

As good as sort is a good example of real world problem.

It does give you a broad idea, but does not in any way show what a complex program looks like.

probably_wrong2• 12 years ago

I think that's a bit extreme for an example - I'd go for the following version, which is less concise but easier to read:

  quicksort :: Ord a => [a] -> [a]
  quicksort []     = []
  quicksort (p:xs) = (quicksort lesser) ++ [p] ++ (quicksort greater)
      where
          lesser  = filter (< p) xs
          greater = filter (>= p) xs

So, what's going on here? First you have the declaration of the function - in this case, you have a list of items of type A which can be compared to another one (Ord means "I can use <, <= and so on over this element"), and you'll return a list of type A.

Then you have the base case - if the list is empty, you'll return an empty list.

After that you have the case "item++[list of items]" (note that the second one can be an empty list), where you return [list of smaller items]++item++[list of larger items] (the two lists are defined under the "where" - filter removes elements from a list).

Note however that, instead of "(lesser) ++ item ++ (larger)" you have "(quicksort lesser) ++ item ++ (quicksort larger)" - this will call the algorithm recursively over smaller lists, but I bet you already knew that.

Both pieces of code do the same thing, but I think mine is what you'd expect from a typical piece of Haskell code - the one you have is closer to "see how small I can make this function".

iaskwhy2• 12 years ago

Thanks for the insightful reply! I can understand most of the code but I still do not understand how should I know what "p" and "xs" is. Is it something you get when you declare the function as being "possible" to order (I believe that's what "Ord" means based on your explanation)?

funky_lambda• 12 years ago

This is a nice example what Haskell can do, but the sort itself is quite inefficient and it's not a true quicksort.

AnimalMuppet3• 12 years ago

If I understand correctly, this code has a bug.

The list is the sorted list of lesser items, then the pivot, then the sorted list of greater items. But since the list of greater items is defined with ">=" rather than just ">", the list of greater items will also contain the pivot. That will put the pivot in the sorted list twice (for each recursive call).

danpalmer• 12 years ago

It's a good example of how quickly you can express an algorithm, but in terms or readability, some additional whitespace, and possibly some better naming would make it nicer.

Once you understand what bits like "p:xs", "++" and "[x|y,z]" mean though, it will make much more sense.

tel15• 12 years ago

It's fairly natural "teaching code". I'd say it's a concise example of one of the ideas behind quicksort, though, as many are quick to point out, it ignores a lot of other very important aspects.

That said, it's not very good practicing Haskell code. We can look at the Data.List module from the base package to see some optimized list operations with a well-designed module API [0] though some of the optimization methods will be non-obvious and kludgy looking. Data.Complex shows some fairly natural data structure work [1] if you factor out the CPP headers which are there so it'll compile on both GHC and Hugs while using all of the newest GHC features.

[0] http://hackage.haskell.org/package/base-4.6.0.1/docs/src/Dat...

[1] http://hackage.haskell.org/package/base-4.6.0.1/docs/src/Dat...

exDM69• 12 years ago

Thanks especially for the "Not All Sunshine and Rainbows" section. It is all too easy to write about the positive things and leave the negative parts out.

Resource leaks in Haskell perhaps a bit trickier to track than in other languages and I would appreciate hearing more about the issue you were experiencing and how you solved the problem. In many blog posts there have been warnings against long running Haskell processes but you guys seem to have fairly successful with it.

Also, the problems you were experiencing with Cabal might be fixed in newer versions with the sandboxes feature which is now built-in with later versions of Cabal.

klrr• 12 years ago

As for resource leaks, the particular example in the post was a bit unfortunate. The problem in general have a solution though. You can either use functions that limit a resource inside a limited scope, and then have it clean up automatically when done (like 'withFile'). And if you want to do more complicated things there are the resourcet and pipes-safe libraries.

implicit9• 12 years ago

We deal with Haskell resource leaks the same way you would in C++ or Java.

We have production monitors on every host that show basic metrics like memory, disk, and CPU utilization. Atop that, we added a tracker for the number of suspended Haskell threads. (that is, threads which are not blocked on I/O, but are also not running)

We found that the machines are usually able to handle requests as soon as they come in, so if the number of Haskell threads goes above 0 for any length of time, the machine is about an hour away from melting down.

We can restart the process without losing any connections, so this leaves us a very comfortable margin of error.

Once we know we have a problem, it's usually pretty simple to run the heap profiler on the process and look at recent commits. We continuously deploy, so there's only about a 10 minute delay before a particular commit is running in front of customers. This makes tracking regressions down really fast.

Even in cases where we can't figure out why a bit of code is leaking, we can almost always identify it and revert it until we understand what's going on.

benmos3• 12 years ago

"we added a tracker for the number of suspended Haskell threads" - would you mind sharing how you did that? I couldn't see any obvious GHC APIs for it.

joehillen• 12 years ago

Except in Haskell you can build ekg right into your server. http://ocharles.org.uk/blog/posts/2012-12-11-24-day-of-hacka...

pmahoney• 12 years ago

We can restart the process without losing any connections

Would you mind expanding on this a bit? I'm not too familiar with Haskell, but I am familiar with various was of blocking new connections while allowing existing connections to complete, either at the load-balancer level or built-in each individual process.

What Haskell stack are you using, and how are graceful restarts accomplished?

Thanks.

whatgoodisaroad• 12 years ago

One Haskell resource leak I've encountered a couple of times has to do with opening large numbers of files combined with non-strict semantics. By default Haskell will open IO handles but not consume them until the contents are needed, and thus, not close them. To read the contents of many files in a directory, the result is opening thousands of concurrent file handles and exhausting the OS's IO handle pool. The solution is to add strictness annotations to force evaluation and relinquish the handles, which isn't fun and isn't pretty.

mightybyte11• 12 years ago

This problem is being addressed by a number of packages like conduit, pipes, and (at a lower level) io-streams. These are second-generation solutions to the problem that was pioneered by the iteratee and enumerator packages.

jfischoff6• 12 years ago

The library in question was using unsafePerformIO to open a file handle. It was just a bug.

samstokes3• 12 years ago

I don't believe sandboxes fix the particular problem the OP was describing, which is that of reproducible builds across multiple environments (different team members / CI / prod).

A cabal sandbox means once you've got your dependencies to resolve and your app to build, it'll continue to build and use the same versions of its dependencies, when building from that sandbox (which pretty much means "when building in that working directory"). But it gives you no guarantee that if your dev build got version 0.1.2 of a transitive dependency, then your CI server will also get version 0.1.2, and not 0.1.3.

If it turns out that your app works with 0.1.2 but not with 0.1.3, then your dev machine will reproducibly produce working builds, while your CI server will reproducibly produce broken builds.

What's really needed is an analogue to the Gemfile.lock used by Ruby or npm-shrinkwrap.json in the Node world, which is checked into version control, and freezes the exact versions of all transitive dependencies until explicitly updated. I think there's a "cabal freeze" command in development, but I'm not sure what the status is.

nightski• 12 years ago

You can easily lock to a specific dependency version in the cabal file if that is your desire.

hyperpape2• 12 years ago

I'm curious about the claim that it only takes a few days to get people productive working in Haskell. I like the language a lot, but learning it has definitely been slow compared to any other language I've learned. It just seems like there are a lot of changes to how you think.

Is this a feature of the way your code is structured that simplifies what people have to understand about the language before they can contribute?

goalieca• 12 years ago

I've been learning haskell for the better part of 8 years. I say learning, because I spend far too much time trying to study the patterns and math from the abstract point of view. Every few months I print off a research paper and struggle with it for a few days until I get it. I never get to code large projects in it because no one uses it in industry up in the north.

I can code in the language no problem but sometimes I feel that idiomatic ideal is always just out of reach to all but the Simons.

tel15• 12 years ago

I highly suggest reading Richard Bird's book "Pearls of Functional Algorithm Design". It's a really great way to get some insight into top-style FP.

nbouscal7• 12 years ago

To be fair to the OP, the original claim was: "People who have prior functional programming knowledge seem to find their stride in just a few days." I would be somewhat surprised if someone with no prior functional programming experience could be productive in a few days in Haskell, because as you say, there are a lot of changes to how you think about programming. It's a lot easier for people with experience in a Lisp, and even easier yet for people with experience in another ML descendant.

All that said, the structure of the code definitely does help a lot in lowering the bar for contributions. When Don Stewart was on the Haskell Cast [1], he mentioned that the way they use Haskell allows contributions from people who not only have no prior functional experience but who have little CS background at all past basic programming literacy. Much of the ability to do this comes from Haskell's rigorous isolation of side effects.

[1] http://www.haskellcast.com/episode/002-don-stewart-on-real-w... around 42:40 or so

hyperpape2• 12 years ago

I probably should have been more explicit: I use higher order functions and recursion all over the place in higher level languages that I use, so I'm familiar with parts of functional programming. But structuring impure programs in Haskell still has taken a long time to get used to (and I'm not great at it yet).

justinhj• 12 years ago

I think it's easier in general to work on an application that's up and running . Architecting a new system in a language you're new to would be much more time consuming. But in the case where the groundwork is laid you get by with much less language depth. Recent someone posted on here about how financial analysts were able to use a subset of Haskell in the field without really having to think of it as programming at all, as all the plumbing under the DSL is covered up.

implicit9• 12 years ago

I'm the author of the article.

This is very true in every language, and doubly so in Haskell. If you just take the language as it is without any context, the language leaves whole classes of problems with a ridiculous overabundance of potentially viable solutions.

The one that springs to mind most prominently is error handling. What's the right way to do this? Option types? Exceptions? EitherT? We even explored a library that used type classes to provide Java-style checked exceptions.

We sorted this out early, when the "team" was just 2 people working in extra hours, but if we'd still been in that state when we scaled up, the project would have been a disaster.

FYI, the solution we came up with was to use option types for all recoverable errors. We only use exceptions for nonrecoverable failures that should trigger production alerts.

chadaustin3• 12 years ago

I work with Andy, the author. I watched the Haskell push from the sidelines and did not learn it until well after it had already gained momentum. My intend behind not learning the language was to retain empathy with people who hadn't yet gone through the spin-up.

When I finally got around to learning Haskell, I found myself able to productively make small changes within a few days. A lot of the more... idiomatic? uses of Functor and Applicative took another week or so to learn. The books Learn You a Haskell and Real World Haskell were helpful there.

I am by no means an expert at Haskell now, but within a few weeks I was able to contribute to most areas of the stack.

jfischoff6• 12 years ago

Haskeller at IMVU.

I was surprised how fast people were picking up the language when I started

It is way different learning the language surrounded by teachers and a working environment. That was my takeaway.

Pxtl2• 12 years ago

Wait, IMVU? As in those terrible banner-ads with the Bratz-dolls-looking avatars? They use Haskell under the hood?

Seriously, this is like finding out that McDonalds' restaurants are powered by nuclear fusion.

Although this does make me very curious about learning Haskell - I've been pretty stagnant about learning new languages.

mtford• 12 years ago

But also the same IMVU co-founded by Eric Ries i.e. The Lean Startup

cordite• 12 years ago

That was my response, I actually gained a high amount of respect from seeing that and I browsed the rest of their engineering blog.

judk5• 12 years ago

McD's runs the most technically sophisticated operation in the industry.

AnimalMuppet3• 12 years ago

I wouldn’t write an OS kernel in it, but Haskell is way better than PHP as a systems language.

What's the definition of "systems language"? If PHP could even remotely be considered an option, the definition is clearly not what I think it is...

csense2• 12 years ago

Haskell is a terrible choice for a production system.

I know well over a dozen programming languages. I have a stronger theoretical background in mathematics, computer science, and compiler design than most web developers. But Haskell has always been utterly mystifying to me.

I've attempted to learn Haskell several times, and I've had monads explained to me several times right here on HN -- but I simply don't seem to be able to wrap my mind around the concept.

To be sure, if I had a year or so to devote to studying the theory behind Haskell's type system, I might indeed become more productive writing web applications in Haskell. And I don't doubt that there are certain problems in logic programming or language theory for which Haskell provides useful concepts and powerful tools, to the point where the solutions to important problems may have trivial implementations.

I've always thought that a major problem with Haskell for web development is: (A) You'll have difficulty finding people who both know Haskell and are interested in web applications, and (B) you'll have difficulty training web developers in Haskell. The author of the article apparently has a training process that gets around (B), and I'd kind of like to know what it is -- a way to learn Haskell without a ton of study.

mightybyte11• 12 years ago

Haskell is something that really needs to be used in order to "learn" it. I didn't learn monads by study/reading, I learned them by just using Haskell for real-world projects.

We use Haskell for all our production systems and it is great. Maintenance is MUCH easier in Haskell and it's usually quite simple for new people (with Haskell experience) to get up to speed with a project. We even had a situation where one guy was able to make a highly nontrivial refactoring to a several thousand line project that he had no prior involvement with. It took him a few hours to do the refactoring and once he got it compiling it worked the first time. We are convinced that this feat would have been impossible in any other mainstream language.

implicit9• 12 years ago

It's a huge help to ask a newcomer to start off by make changes to an already-established project that has best practices and idioms already sorted.

If you just start with the full language, there are just too many ways to solve every problem and it's not clear which is better for your particular use case. It's a bit like Perl, except moreso: even basic flow control is a library.

yetanotherphd2• 12 years ago

I found Haskell was not that hard. But I did try to learn by reading Learn You a Haskell twice and gave up.

When I really learnt it, I treated it like I would any other language: I tried to write nontrivial programs in it, in my case the 2048 game. I learnt Monads by adding real randomness to the game.

So I would say the main problem with Haskell is that people treat it like something special, and not like any other language.

anaphor2• 12 years ago

I'm sorry you're only now realizing that just having a bunch of credentials doesn't mean you're a genius. It just means you took the time to study a few specific things in-depth.

Sadly there is no way around actually taking the time to try and understand something in order to understand it. I guess we need to perfect the art of brain transplants.

devwebee2• 12 years ago

I've seen experienced programmers failing at learning Haskell for the same reason experienced programmers fail at learning Vim, the initial learning curve is very steep, and they don't see the value on climbing that wall. Now, if you know Vim, ask yourself, was it worth it? I'm convinced 99% of people would say yes. It is the same with Haskell, all those seemingly complex concepts come with a big reward.

Learning Haskell is easier with a strong functional programming background; sadly CS students don't learn much about FP, so having lots of experience in CS and compilers won't necessarily put you in a better position than somebody who has no formal background in CS but lots of programming experience.

A math background on the other hand should help you. Learn about how category theory is applied in Haskell, and you're already half way there. Monads are just a piece of the puzzle.

I do agree with your last three points. I haven't used Haskell in production, so my experience in "real world Haskell" is limited, but it has helped me immensely in my daily work with other languages. Haskell forever changes the way you think and approach problems, just like Vim changes the way you write and edit code; it will make you a better programmer.

csense2• 12 years ago

the same reason experienced programmers fail at learning Vim, the initial learning curve is very steep, and they don't see the value on climbing that wall.

This is definitely me. I only got really into Linux with Debian-like systems after Nano became those distributions' standard editor. I know the bare minimum about vim for occasional, minimal editing of configuration files. I only ever use it when I'm stuck with a rescue prompt or some third-rate distro that has nothing else. Usually one of my first goals is to get either a GUI, or file transfer capability, or a package manager up and running; then I stop using it.

dllthomas21• 12 years ago

"I've had monads explained to me several times right here on HN"

Well, let's add one to the pile, though I second the "use some monads" recommendation. This is one perspective; there are others:

Monad is an interface. It is used when reifying certain kinds of context to give a standard way of chaining those contexts. That reification means 1) you can talk explicitly about those contexts, and 2) the type system can enforce more rules around those contexts. The abstraction provided by the interface means we can hide away a lot of the plumbing.

The Monad interface is defined in terms of a type constructor; that is, a type-level function that takes a type as an argument and produces another type - like a C++ template with one argument. There is a sense in which the monad "wraps" the "inner" type, though for some monads this is metaphorical at best. Still, it provides a vocabulary.

What it's like to use Haskell

Related Stories