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.

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.

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.

Basically, you can share a single socket amongst many servers. The OS ensures that just one process accepts each connection.

You can therefore have a manager process that owns the socket and passes it on to application processes.

To update, start new processes, then politely tell the old ones to go away.

Here are the official docs: http://msdn.microsoft.com/en-us/library/windows/desktop/ms72...

Still, cool stuff there too.

[1] https://github.com/stripe/einhorn

We track total threads, working or not. It works great as an indicator because it tends to stay below the number of CPU cores on the server.

edit: Found the code. :)

We rolled our own implementation. Our WAI application action increments a counter and decrements it again whenever an HTTP request is received and completed.

It doesn't track threads created as a part of HTTP request handling, but we don't allow those actions to forkIO anyway. There hasn't been any demand for it.

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.

The reason Gemfile.lock works is because it lets you achieve that the same way you create working code - figure out what works in dev, using a combination of skill and trial and error, then lock it down in version control and deploy exactly that to CI/prod/other devs.

People have written shell scripts to scan your sandbox for installed package versions and update your cabal file to require those versions, but it's an inherently approximate process - e.g. if you upgraded a transitive dependency but still have the previous version in the sandbox, the shell script has to guess which one you want, because there's no explicit relationship between your code and a particular version.

There's a more fundamental problem with that approach - it ignores the difference between "my app semantically requires package X at version y" and "I have tested my app with package X at version y". The cabal file expresses the former - which is why it doesn't include transitive dependencies, and why it's more idiomatic to specify broad version ranges than exact version constraints. "cabal freeze", if it existed, would express the latter. Reliable engineering requires both.

Like you said, there is nothing seamless that is part of cabal ... yet. I would like improve our workflow and integrate it into cabal.

http://www.yesodweb.com/blog/2013/10/core-flaw-pipes-conduit http://www.yesodweb.com/blog/2013/10/simpler-conduit-core

But the general issue can be encountered with lazy IO without any use of unsafePerformIO. There has been a lot of discussion about this around the various enumerator-like libraries - in particular, Snoyman has many posts about ensuring timely release of resources.

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.

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.

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...

Fortunately, outside of space leaks the Haskell runtime is actually really quite fast. At the end of the day most of your code which isn't leaky (buggy) will be really fast almost for free.

But that second step can be painful right now. The tools exist to profile and debug space leaks, but they're not cohesive and require a fair amount of black knowledge. It's also fairly murky as to how to escalate: if you've identified your problem area, strictified it a bunch, and it's still broken... well what then?

The answer seems to be growing that internal expertise. There are enough people out there writing enough stuff that a dedicated student of the runtime can learn all of the tricks needed to really attack failures like that—profiling, unboxing, reading core, figuring out the inliner, and a variety of style guide hints to making things all work smoothly (e.g. avoid the Writer monad).

GHC 7.10 is slated to (hopefully have): 1. exceptions will come with stack traces! a. Some of this same work will also allow for sampling based based performance tools b. mind you, a lots still in flux 2. theres a non zero chance you'll have in langauge facilities to create threads that get killed automatically if they exceed certain programaticaly set CPU/Memory/other resource limits! 3. Other things which are a combination of hard work and clever research grade engineering

I myself (as Tel knows) have plans for making GHC haskell AMAZING for numerical computing, and my wee ways of contributing to GHC are guided by that goal

"The answer seems to be growing that internal expertise."

Or you can go with OCaml. :)

As always, it's a tradeoff. At this point, I don't personally feel afraid of debugging core or profiling space leaks. I don't feel like I'm much more than 50% up to date on techniques to fix them... but when they arise I have little trouble eliminating them.

Lazy resource deallocation is a problem of lazy IO. The solution is to not use lazy IO and that's tremendously tenable today due to libraries like pipes and conduit.

Would like to note I've spent more time trying to optimize this[1] than writing code, however.

http://stackoverflow.com/questions/21654081/how-do-i-optimis...

Diving into processOrder since it's the big time/space hog I think strictness annotations might help uniformly since there's a lot of packing/unpacking going on. To really dig in you can add some manual SCC annotations or dump core on it and see what's doing all the indirection.

These are all pretty general, high-level Haskell performance notes, by which I mean if you learn them once you'll be able to apply them much more quickly in the future whenever you find bottlenecks.

It's also been the case historically that Haskell had much better concurrency support - I'm not sure whether that's still true - in which case a more parallel workload might push Haskell-wards (if it's not so parallel that simply spinning up N entirely separate processes make sense, in which case concurrency support doesn't matter).

I'm not familiar enough with the current state of OCaml, or with Haskell libraries outside the domains I've been playing in, to really give a thorough run-down of specific domains, sadly. I'd be interested to see it if someone else took a swing.

Although I'm excited about F#, the experience in Visual Studio is really great.

Hm, not sure I agree with this. As a professional rubyist I am aware of the wide variety of bugs that can and do happen because of things that Haskell simply wouldn't allow you to do (at least without pathological abuse of the language that would never pass a code review). The thing that makes Haskell special to me is just how much the commitment to functional purity and a powerful type system buy you in terms of decreasing the surface are of potential problems.

You've rightly pointed out that Haskell has its own memory and performance pitfalls that are very difficult to debug, but my instinct is that those things, while perhaps being showstoppers for embedded and realtime systems, are not intractable in a typical server environment, and that it's orders magnitude easier to improve the tooling around detecting and solving these problems than it is to ever make a language like Ruby code safer and require fewer tests.

Of course I'm an utter beginner at Haskell, so I don't have a real sense of its downsides at scale, so take my opinion with a teaspoon of salt.

Perhaps counterintuitively, I disagree here. I think using laziness enough will eventually change your mind that most code must be thought of in such discrete steps. Instead, I tend to keep in mind and think constantly about how a computation might be partially delivered and how it might be consumed. This is part of the declarative promise of laziness playing out, I feel.

Ultimately I don't think there's a "right" decision. I'm comfortable in strict and lazy languages. I do think everyone should experience both strict and lazy evaluations enough to no longer be worried about them and instead just see each as another, separate form of computation. At the very least it'll make you much more aware of what evaluation order and normalization feel like.

(I'd also highly recommend everyone plays with a total language for a while, too. That feel is quite distinct.)

At the end of the day, I feel like having laziness by default and picking around for places which ought to be strict is very dual to having strictness be default and picking around for places to make lazy. Both are pretty annoying.

I do think people are generally more sensitive to problems of excessive laziness than they are to problems of excessive strictness. Manually wiring around stopping criteria and consumption control through all of your (no longer decomposable) loops/recursion is the price of strictness. Both problems are helped by tooling, as well.

tel is right. We are desensitized to the problems of strict evaluation. It's the default, so we accept it as a fact of life. Lazy evaluation on the other hand, is "new", so whatever problems it have are magnified by our unwillingness to handle new problems. This is made even worse when we try to use lazy evaluation the same way we use strict evaluation: you get even more problems, and none of the advantages.

I think the best option is total-by-default, honestly. I really like how Idris works, for instance. If you must work with some code which is non-normalizing then your choice of laziness/strictness can be a major architectural one—like organizing the entire pipeline of your program around a lazy consumer stream/set of coroutines.

http://www.idris-lang.org/

We've only had one really disasterous space leak and it was caught and reverted right away. The hardest ones are generally the slow ones where the servers take 3-7 days to run out of RAM and fall over. If you never go more than a few hours without a code push, you might not even notice it.

This is largely mythology built up around a misunderstanding of the grain of truth at the core of it. Lazyness can create pathological performance issues, just as strictness can. 90% of the time neither matters, 5% of the time you need strictness, 5% of the time you need laziness. Using strictness in haskell is very simple, and knowing when you need to is very easy to learn. The profiling tools make it incredibly obvious when laziness is causing a problem. And I can't even imagine a case where it requires significant refactoring. It is generally adding a couple of "!"s or importing Module.Strict instead of Module.Lazy.

I agree. I've encountered a few space leaks in my Haskell code, but it's always been pretty easy to track down: profile the memory usage and look for a conspicuously huge peak. It will usually be fixable by forcing an intermediate result, or using a different recursion strategy (eg. a fold instead of explicit recursion). Haskell functions tend to be so small and single-purpose that there are no knock-on effects of doing this refactoring.

I think there's a perception that 'Haskell is difficult to debug', whereas the reality is more like 'Haskell will reject all of the easy bugs'. In other words, the average difficulty of a Haskell bug may be higher, but the density is less.

Wouldn't adding some bangs in the patterns kind of do the same thing as using foldl'?

For example in C/C++ your only ability to introduce laziness is via manual thunking, if, or the logical conjunctive (&&), and disjunction (||) which have non-strict semantics. For example you often see the idiom of:

    if (x != NULL && x.foo == bar) { ... }

    until :: Bool -> a -> a -> a
    until b t f = case (not b)
      True -> t
      False -> f

You just answered your own question. "If you don't need to compute a value, then don't compute it" is laziness.

>That seems absurd given that the overwhelming majority of programmers have gotten along without it for 50 years.

No they haven't. Most programmers don't understand it, but they tend to use it on a regular basis.

No -- "laziness" is saying "the programmer wants us to compute this value, but we don't need it just yet, so we're going to create a thunk that will sit on the heap until it's evaluated or garbage collected". Strictness is doing what the programmer says, which involves the programmer deciding what does and does not have to be computed while he's writing the program.

For example, imagine something happens which invalidates a property which must be calculated (say, a bounding box for a graphical object).

Instead of immediately recomputing it, just set it to nil, and only recompute it the next time the property is actually accessed.

This way you can harmlessly invalidate it multiple times without doing a potentially expensive calculation (which just gets thrown out by subsequent invalidations).

In other words, "sort lst" gives you a sorted list, but "take 5 (sort lst)" gives you the first five elements, without sorting the rest of the list.

    if (logger.isDebugEnabled())
        logger.debug("..." + ...);

return theObject; }

Really? Every year I read on haskell a bunch of uniformed dismissal of haskell from people who seem to have a deep seated hatred of learning. How do you get "this year is haskell's year" from his comment at all?

>Anyone got a link to a good todo-mvc implementation

A what? MVC is an object oriented pattern, I would certainly hope nobody tried to do it in haskell.

That sounds a lot like you putting words in other people's mouths. I've never seen anything like that.

>Then you get like the same 3 or 4 dudes talking about how it's only a matter of time until the enterprise picks it up and all the dumb people go away.

Or that.

>I just want to see a working to-do list application, or anything resembling that size before we start the name-calling.

Now I am even more confused. Why do you want to call people names, who do you want to call names, and why do you want to see some random toy app first?

So when someone out of college makes more than someone with 10 years experience, they assume this must be due to agism, since the 10 years experience must, in their view, be more important than being one of the top graduates of that year.

On the original comment, I usually associate Haskell with younger programmers, since it is taught in many schools like MIT and UW. So I found the comment a bit grating since I thought Haskell was the one thing we could have.

Huh. FWIW, I associate it more with older programmers. Certainly, some of the more interesting and visible members of the Bay Area meetup are older than me and I'm not fresh out of school.

No it isn't.

>I think it's annoying.

Ok, but that doesn't support the claim you made and I questioned.

On the other hand if you take a 20 year old student still doing their undergraduate degree (like many of the people in the classes I TA), and try to explain the value of immutable data, many of them just don't get it. It has nothing to do with their intelligence or age, but the fact that they haven't written enough code to develop a sense of why such a thing would be useful.

If you want example apps their are plenty littering the internet all covering the various web frameworks, for example here is one covering Happstack: http://happstack.com/docs/crashcourse/index.html

http://en.wikipedia.org/wiki/Ageism#Ageist_prejudice

All you keep saying is 'no its not'. And then trying to move on as if that's the final word. Not interested in talking to you bro, we're not going to come to any kind of understanding.

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.)

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

We have a general Monad typeclass called "World" which gives access to MySQL, Redis, HTTP, Memcache, and so on. There are more specific Monad typeclasses if you have a function that, for example, should only ever talk to Memcache and nothing else. I think it's called SupportsMemcache.

My point about the Haskell type system is that the _ability_ to limit the operations in a context is a capability that few languages have.

We have a simple mechanism for controlling access to IO.

There are a series of type classes that provide access to all of the IO based services (mysql, redis, memcache, etc.). All of the request handlers are written to use these type classes not IO. There are two instances of the type classes, one pure for tests using fakes, and one real using IO.

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.

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

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.

Any advise on learning haskell out in the wild?

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.

First, the implicit point you are making that ambitious algorithms or novel data structures are useful in industry. For the vast majority of applications this simply isn't the case.

Second, the argument that people interested in learning advanced computer science aren't interested in learning new programming languages. This goes against all of my experience; my friends who are most interested in advanced computer science concepts are exactly the ones who spend the most time exploring different programming paradigms as well.

I have one idea of what the distinction might be, though: learning different programming paradigms is very different from learning different programming languages. I certainly wouldn't want to waste time learning yet another Java or yet another Python, since as you say that would be focusing on bling rather than substance. If this is the distinction, Haskell comes out fine, as it is clearly a different paradigm from the mainstream languages.

I drool over Rust, too, but I wouldn't switch my company's (little) C++ code to Rust tomorrow. Also, Rust appeals mostly to C/C++ programmers, who don't usually need as many OSS/OTS libraries as application-level programmers (and those, usually specialized, libraries they do need, either work with Rust or don't; if they don't, that alone would be a deal breaker).

People who risk their company's investment (or make any important decision) based on stuff they drool over, might need to get their priorities straight.

As primarily a Scala programmer, Rust appeals greatly to me. It's basically the same language without cruft inherited from Java, and its much more amenable to optimisation that Java. For example, large heaps have unacceptable GC pauses, so projects like Cassandra invest a lot of effort into "off-heap" memory management (i.e. manual memory management). With Rust that just works a whole heap better (pun intended).

People tend to talk about "expressiveness" when discussing programming languages, which usually mean concision. I'm much more interested in what I call "expressive width", which means how high- and low-level can get in a language. PHP is little expressive width, because its runtime is so poor. Scala has good expressive width because I can play with threads, CAS operations, mem-mapped files, and even manual memory management (which is going quite far off-piste, but possible with sun.Unsafe). Rust has even more expressive width than Scala.

[Rust needs higher-kinded types before it will truly make me happy. I believe they'll arrive soonish.]

For your other points:

- P(interested in PL | interested in CS) != P(interested in CS | interested in PL).

Agreed, but I don't think it matters. Anyone interested in discrete maths (so, CS) will pick up Haskell quickly.

- "People who risk their company's investment (or make any important decision) based on stuff they drool over, might need to get their priorities straight."

Depends on your company's size and ethos. I'd rather have a few great people than a room full of monkeys, but I understand arguments that go the other way.

Depends what you mean by soonish... there's certainly no concrete plan for how to implement them yet (or even a vaguely sensible proposed syntax).

There's actually a lot of people who aren't coming from C++ too. A whole bunch of Rubyists are checking out Rust, for example.

That said, you're totally right that production Rust is probably a bad idea. You'd be user #4!

I don't think you're speaking from a lot of knowledge here.

As long as you can sample from a decent talent pool, I think it's a good filter. (Provided you only care about your outcome, not fairness to job seekers.)

I've never needed the former, and only have a little bit of the latter. I wish I had more of both, but I find I have to do hard stuff on the side.

What do you do, exactly?

So downvoters, how do you differentiate a good coder who chose the language based on features and reputation, over a poor coder, who chose it "because its easier than Perl"?

The point I am trying to make is that I think there are benefits to having a higher bar to entry.

My guess is that python is a more well rounded language, with a nicer syntax, which enforces indentation rules (that's a plus for teachers). PHP only shows its merits after a while, and through good practices.

However, looking at the charts over at langpop.com, I don't see how people would choose PHP over perl for its easiness, given the wide difference of popularity. They just don't sit in the same ballpark (except for maybe a few specific markets).

I don't think you need to worry... YET.

1. Python is simply a superior language.

2. There isn't currently a "WordPress" type of project that is bringing in droves of awful Python coders.

Will it eventually turn sour? If things continue with Python, I think so. But the language and community will do a good job keeping things slightly sane. I think the Python community understands the importance on both fronts. Sure, bad programmers are everywhere. But bad contributing programmers need to be kept at bay and out of our favorite GitHub repo's.

In my experiences as a solo founder needing junior-level programmers, Python is currently in the perfect sweet spot for adoption vs. quality. It's largely up to us in the community as to how long that will last.

> There should be one--and preferably only one--obvious way to do it.

Even something like significant whitespace forces everyone to format their code similarly.

That's not to say an incompetent programmer can't write horrible code in Python, just that Python tries to make it easier to do the right thing than the wrong thing.

http://paulgraham.com/pypar.html

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.

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).

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.

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.

We write our own application code. We often write our own (specialized) library code. Sometimes, we even write our own little frameworks. But we very rarely write our own languages. There's a wall somehow between languages and everything else: the language is something you chose. Everything else is something you might build —or at least adapt to your ends.

Why? This is beyond silly.

Take one example: Closures in Java. Closures are very useful. If you put garbage collection in your language, but forget about closures, you fail at language design forever. Java made this mistake, and forced us to use anonymous inner classes, and other equally horrible workarounds instead. Java need closures and we knew that for years.

What did we do? We waited for the landlord.

We didn't have to. I'm sure some of you have heard, there's this nifty concept called "source to source transformation"[1]. Here's how it translate in Java: you take source code that is like Java, but is not quite Java. Feed that into your compiler, output Java code, and voilà, you have modified the language. In the specific case of closures, it would mean invent a syntax for closures, and compile that into those ugly anonymous inner classes.

Some people probably have done that, and I just don't know about them. Anyway, it seems the technique didn't get any traction. (The only example I know of is here[2]. Skip to page 6 and 7. Then read the whole thing.)

I don't know about you, but the next time someone forces me to use a language that sucks, I'm going to at least write a preprocessor, and modify the damn language. In other words, I can write LISP in any language, and I will. And when I'm done, even COBOL won't suck.

[1]: http://www.youtube.com/watch?v=EGeN2IC7N0Q

[2]: http://www.cs.indiana.edu/~dfried/dfried/dfried/mex.pdf

But 1000 ad-hoc human written micro a frameworks and spaghetti approximations or workarounds to closures etc? No problem. Massive LoC throughput, solving "complex problems" as demonstrated by code base size...

While it makes sense to follow some unified standard as a team, it makes much less sense across teams. With few exceptions, there is no "grand scale".

I have the feeling that you know something I don't. What do you mean by "ecosystem demand"? Could you please name three?

I'm basically assuming that the only reason why you'd have enough business value in creating a new language comes from it either modeling something interesting or having a different semantic focus. Everything else is just wasted time then.

Some examples:

1. Documentation. How do people know what your language means? How do they know what happens when it breaks?

2. Shaking out edge cases (much harder to do than debugging a program!)

3. Syntax. Picking it. Parsing it. Ensuring it's complete and doesn't have weird edge cases.

4. Compiler. Runtime. Parallel (!) runtime? Platform independence? Efficiency?

5. Static analysis (type checking, memory analysis, nulls)

6. Managing modules/files/packages

7. Foreign calls

8. Dependency management

All of these are fun in their own right, but most businesses would have a hard time arguing that they're worth working on unless they've already got a language tied into their core value proposition. It's also important to mention that there exist tools to make some of them easier (bnfc, llvm, &c).

But if you just start with an embedded DSL you can get right to the modeling or semantic issues by piggy-backing on the host language for (most of) 2, 3, 4, 5, 6, 7, and 8. If you prove that there's something valuable there and the host language is slowing you down then you can start to unembed it by building the "whole ecosystem".

The way I see it, source-to-source transformation helps a lot with 2, 4, 5, and 7: we can rely on the host language for these. Actually, 5 is even better than an embedded DSL: you can implement additional checks. As for 6 and 8, you will generally avoid the issue altogether by letting your host language deal with them.

An example of source-to-source transformation at work is OMeta. The thing compiles itself to JavaScript, and its source code takes about 400 lines of JavaScript and OMeta. I'm currently working on a clone for Lua, and my prototypes so far are under 300 lines.

I agree that picking up a syntax is hard (parsing it is trivial). But with enough feedback, you can make a decent one. Just make sure to tell everyone that the first 5-10 versions of your language are all pre-alpha, and totally incompatible with each other. And source to source transformation isn't about building a whole new language. Most of the time, it is about extending the host language. This means much less syntax to worry about in the first place.

Actually, if you're smart about it, you can often write most of the semantics of your language in a library, then add a light layer of syntax sugar on top of it. That's what I did when implementing a PEG syntax for Haskell[1]. It's just syntax sugar over Parsec.

[1]: http://loup-vaillant.fr/projects/metacompilers/ (bottom of the page)

---

Now back to my Java example: It was just a matter of adding a nice syntax sugar over anonymous inner classes, and maybe allow a syntax for calling objects as if they were functions, C++ `operator()` style (Even so, writing obj.app(args) isn't that cumbersome). Not much work, really.

I think another important example of source-to-source is Lisp macros. Super powerful and when used well and marketed well they can really transform what Lisp means. I also think that when marketed poorly they lead to an explosion of competing "languages".

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!"

First, the simple reason that they are accurate terms for which there are no good replacements. The English language does not have the necessary scope to cover the relevant abstractions. This leaves you with two options: use the accurate term from mathematics, or make up some new term. Either way the term will be something new to most people, and making something up does not provide any value.

This leads me to the second reason: the mathematical terms actually do provide additional value. If you are working with monoids and do some Googling, you can discover a wealth of information that is directly applicable in practice, for example you can learn that List is the initial monoid [1]. You don't have to learn any of this, it's completely optional, but if you do choose to explore it you can get real benefits. Renaming monads "workflows" would prevent you from gaining those benefits, and would not get you anything in exchange other than making the people who are scared of math more comfortable.

[1] An example of why this is useful to know: http://byorgey.wordpress.com/2012/11/05/foldr-is-made-of-mon...

Also this post from the wiki, though it's a bit heavier on the theory: http://www.haskell.org/haskellwiki/Free_structure

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.

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.

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.

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 :)

I'm not so sure that's the case. For example, debian's user base is vastly larger than openbsd's, yet debian has bugs like "all the keys you ever generated are garbage" and openbsd doesn't. The "many eyes" hypothesis is bogus. Bugs are found and fixed more through deliberate effort than just large numbers of people.

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)

But you're kind of right. I can't really find information on Chester (from Linkin Park) doing functional programming.

It's either the guy on the picture really looks like Chester, or the said person (programmer) used Chester's pic as his avatar (unlikely, though, since they are a reputable sight).

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.

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.

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!

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.

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.

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

So, Cabal is in good company in that regard.

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.

I've been using Haskell for more than 6 years and in my experience the worst build problems happen with parts of the ecosystem that don't specify upper bounds. There's been a lot of discussion about this in the community. We're aware of the issues and we're working on solving them. One attractive possibility being discussed is adding a flag to cabal that allows one to ignore upper bounds. In theory this seems like it can preserve the benefits we get from the added information in an upper bound while eliminating the pain. An extension to this idea is to make two operators (say < and <!) that specify a "soft" upper bound that is just the highest you've been able to test against and a "hard" upper bound where you're telling cabal that your package is known to break. This extra information would make the solver much better when you tell it to ignore upper bounds because it would only ignore the ones that are safe to ignore.

I suspect that this problem is more visible in Haskell than in other languages. Haskell's type system gives you a way to bound the number of things that you must understand about an API in order to use it. The confidence that we get from having these guarantees makes code reuse orders of magnitude easier in Haskell than it is in pretty much any other language in mainstream use today. Others have made this same observation. Here (https://www.youtube.com/watch?v=BveDrw9CwEg#t=903) is a presentation given at CUFP last year by a company using Haskell in production that gives the actual reuse numbers that they've seen for several different languages.

There is a policy that says you're supposed to do this:

http://www.haskell.org/haskellwiki/Package_versioning_policy

The idea is that by specifying upper bounds, the package is more likely to build after the dependencies change.

This idea is subject to considerable controversy.

http://www.haskell.org/pipermail/haskell-cafe/2012-August/10...

There's also been more recent mailing list traffic on it, but my Google skills are failing me here and the arguments haven't changed all that much.

My opinion is that we are relying too heavily on upper bounds to solve a whole bevy of interrelated, but separate, problems. Other solutions are evolving to help deal with some of the problems. cabal sandboxes allow you to build a package separately from your others, reducing dependency issues. cabal freeze will help you specify exact dependencies, including transitive ones. Another project, Stackage, aims to maintain a whole slew of packages in a buildable state:

https://github.com/fpco/stackage

However those features aren't necessary to productively use pip for example. Because Python package maintainers are very good at maintaining backwards compatibility (or using deprecation cycles when those are needed) because people that depend on their packages get upset with them. The rules are different for beta releases because it's your own fault if you depend on them and their api changes.

Precisely because specifying upper bounds is encouraged, Haskell maintainers seem to act as if they have a free card when it comes to backwards incompatible changes. In the long run that causes much more packaging troubles then specifying upper bounds saves. Perhaps there's nothing wrong with Haskell nor Cabal, but the Haskell community's way to handle backwards compatibility is wrong imo.

I've been on the other side of the fence with a large app written a long time ago that did not specify upper bounds. Now that app is essentially unbuildable given the time I'm willing to put in. If I and all my dependencies had followed the PVP and specified correct upper bounds everywhere, I would still be able to build my app today. No, I wouldn't be able to build it with the latest version of other libraries, but that's not what I want to do.

If you don't specify upper bounds, the probability of your package building goes to ZERO in the long term. Not epsilon...zero. That's unacceptable for me. If it works today, I want it to work for years to come.

Not really; the upper bounds generally are speculative. They specify that the package will not work with particular versions when typically those versions have not yet been released. Often when those versions are released they work fine, which prompts a useless flurry of dependency bumping.

"If I and all my dependencies had followed the PVP and specified correct upper bounds everywhere, I would still be able to build my app today."

I now distribute my packages with the output of the ghc-pkg command so you can see the exact versions the library builds with. That solves your problem without using speculative upper bounds.

I wouldn't expect it to work for "years to come" in any event, though: Haskell changes too much. You probably won't be able to get today's package to work with the compiler and base package that will exist years hence. It's hard to even get an old GHC to build: today's GHC won't build it because of...dependency problems.

Yes, an upper bound is still useful information. It says that a package is known to work with a certain range of dependency versions. This is why I think cabal should support something like < for speculative upper bounds and <! for known failure upper bounds. Then we could have a flag for optionally ignoring speculative upper bounds when desired.

> I wouldn't expect it to work for "years to come" in any event, though

I can still download a binary of GHC 6.12.3. Hackage also keeps the entire package history so there's no reason things shouldn't build for years to come. I'm all for the fast moving nature of the Haskell ecosystem, but we also need things to be able to build over the long term and there's no reason we shouldn't be able to do that.

Which won't even work on current versions of Debian GNU/Linux because the soname for libgmp changed.

"Hackage also keeps the entire package history so there's no reason things shouldn't build for years to come."

No it doesn't. I had specified a dependency on a particular version of text, and it summarily vanished from Hackage.

Even assuming that it's a worthwhile goal to make sure old software builds with current tools, upper bounds do nothing to get you there.

Again, my argument assumes that you're not upgrading to current versions of things. Enterprise production-grade deployments often fix their OS version because of this. There's a reason RHEL is so far behind the most recent versions. If you are upgrading, then you'll be fixing these problems incrementally as you go along and it won't get out of hand.

> No it doesn't. I had specified a dependency on a particular version of text

You're making my point for me. It looks like you were probably depending on 0.11.1.4, which doesn't exist now. Your problem would not have happened if you had used an upper bound of "< 0.12" like the PVP says instead of locking down to one specific set of versions. If you had done that, cabal would have picked up subsequent 0.11 point releases which should have worked fine. Also, I can still download text-0.1 which is more than 5 years old.

In fact, if any of the packages demanded an upper bound it would suck because I don't want to use a legacy Django web server containing tons of exploits which no one is ever going to fix because it's not maintained anymore.

I'll agree that Haskell moves faster and has more breaking changes, but that statement is just wrong. Look at http://semver.org/ (not related to Haskell at all) and you'll see that the very first point on the page is about incompatible API changes. So clearly this issue exists outside of Haskell and people have developed methods for managing it with version bound schemes. You are arguing against rapidly changing software, not against upper bounds. In your example where the Django server is not making backwards-incompatible changes, upper bounds wouldn't hurt you at all because the bounds are on the major version number, but exploit fixes that don't break backwards compatibility will only bump the minor version number.

Comparing Haskell to any other mainstream language in this discussion is invalid because the other languages have been around a lot longer and have reached a more stable state. Python appeared in 1991. The first Haskell standard appeared in 1998. So that means Python has at least 7 years of stability on Haskell. I would argue that Haskell gained adoption much more slowly because it is much less similar to any mainstream language that came before it, so the actual number should be larger. Paul Graham's essay "The Python Paradox" came out in 2004. I would suggest that Haskell is just now getting close to the point that Python was at when PG wrote that essay. That means that Python has at least 10 years on Haskell. So if you're comparing breaking changes in Haskell today with Python, you need to compare it with Python as it was 10 years ago. If you think the breaking changes are not worth that much pain for you, then don't use Haskell right now. But you shouldn't make that decision without educating yourself about the benefits the language has to offer. For me, it is a small price to pay compared to the benefits I get from Haskell.

Only time will tell, but I predict that companies based solely on Haskell will emerge in a few years dominating their competition because they can write better quality software, iterate faster, with fewer people, more reuse, fewer bugs, and easier maintenance than companies not using Haskell.

I've not really used the others, but Gemfiles have the concept of upper bounds: http://stackoverflow.com/questions/5170547/what-does-tilde-g...

Docs: http://guides.rubygems.org/patterns/#pessimistic_version_con...

Because having working code spontaneously break is very bad. You can't just blindly pretend any future versions of all your dependencies will work without updating your code. APIs change. So you specify the version range your code works with.

>Backwards compatibility either is very hard to achieve in Haskell

Backwards compatibility is the whole point of upper bounds.

>But at least pip, npm and gems are a breeze compared to cabal.

I had constant problems with pip. Because it will blindly install the latest 'foo' dependency even though the API changed and now my app is broken.

If you have a risk of arbitrary changes in APIs happening in any minor update, your infrastructure and dependency management are fundamentally flawed and ongoing development will always be difficult. There is nothing unique to Haskell about this, it's just software development 101, separating interface from implementation and all that jazz.

There does seem to be a surprising... I'm not sure how to describe it, maybe a lack of respect?... for this principle in parts of the Haskell community, given the same community's obvious general preference for correctness and being sure everything fits together in a controlled way.

Of course sometimes you want to make major changes to an API and maybe they break backward compatibility, but usually that is a Big Deal in software development, it doesn't normally just get done in some quick point release along with a couple of bug fixes and a security patch.

I had constant problems with pip. Because it will blindly install the latest 'foo' dependency even though the API changed and now my app is broken.

Not that I'm doubting you, but I do find that experience surprising. I work with Python all the time, on different kinds of projects but typically always using pip for package management, and I can't immediately think of a single time that's happened to me. Of course, you can also tell pip to install only within a specific version range if you ever need to.

Upper bounds typically restrict major version, not minor version numbers which would represent non-breaking changes.

I suppose it's a similar situation to what we see in web development. There are always people who want to push the envelope with the latest HTML7/CSS5/SomethingScript technologies, and it's helpful for advancing the state of the art for some people to do that. At the same time, if you're trying to build real web sites for paying clients, what you really need is solid foundations that are as standardised and portable as possible.

Oh, no question. It just was an example I had off the top of my head of somewhere there has been a lot of instability recently.

"For better or worse, I think this rapid evolution does lend some weight to claims that Haskell isn't ready for use on most mainstream projects yet and to the idea that it's more of an academic's or theoretician's language, even if a few such people happen to work in industrial software development rather than in research now."

To an extent, but I'm not sure I accept the dichotomy. The great thing about Haskell over HTML7/CSS5/SomethingScript is that the people doing experimental stuff are doing it in the same language you're working in, and it will bleed directly back into "things that are stable enough to use" as they get stable. The thing that Haskell-in-industry has over academia is that those experimental innovations scratch itches found by people working in industry. The presence of Haskell in academia means those industrial innovators have more things to reach for. Where it works, it works very well. Because the Haskell community is small, we don't have the large mass of stable libraries that something like Python has, but how much that matters depends both on how stable you need things and on what you need in the first place.

"At the same time, if you're trying to build real web sites for paying clients, what you really need is solid foundations that are as standardised and portable as possible."

Absolutely. If you need things stable, stick to stable packages. There are efforts (stackage, Haskell Platform) toward making this easy. If you need things stable, and you have needs that stable libraries don't meet, and it doesn't make sense for you to get involved in maintaining less stable libraries, then Haskell is probably not a good fit for your project.

>If you have a risk of arbitrary changes in APIs happening in any minor update

You don't. API changes require changing the major version. Read the PVP.

>There is nothing unique to Haskell about this

Precisely my point.

>Of course, you can also tell pip to install only within a specific version range if you ever need to.

Same with cabal. So what is the problem again?

No, I'm not literally saying any such thing.

There are two points here. One is whether or not your version numbering scheme and package/dependency management tools systematically track breaking changes. The other is how often breaking changes happen.

As far as I'm aware, Haskell doesn't generally have a big problem with the first point. As you say, PVP takes care of that as long as people follow it.

But breaking changes, even if properly acknowledged, seem to happen with amazing (not in a good way) frequency in the Haskell ecosystem. No doubt there's some variation between packages, but I'm another example of someone whose early experiments with the language proved very frustrating because of the constant maintenance headaches with Cabal etc.

You wrote yourself, "having working code spontaneously break is very bad". You can protect against dependencies breaking by adding upper limits on version numbers for your dependencies, but that doesn't fix the problem, it just conceals it, and it has a cost: every time someone makes a breaking change in a library API, everyone using that library needs to check through what actually changed to see whether it affects their particular situation and then update their dependency management again.

In my original post, I never even mentioned version numbering schemes, and in two different posts now I've reiterated that this isn't what I'm concerned about.

I wasn't having a dig at Cabal for how it supports controlled dependencies either, nor suggesting that other package managers do that job better. That would be like blaming the UI for every bug in software because the UI is where the consequences of bugs are visible to the user. Cabal isn't the problem, the implied need to use certain features of Cabal routinely because otherwise things will break is the problem.

I wasn't even objecting to Haskell libraries developing "too fast for my liking". I think the innovations coming out of the Haskell community are some of the most interesting and promising ideas in the programming world right now, and in general I'm a big fan. I'm just saying that, other things being equal, breaking changes in APIs are undesirable, and that the Haskell ecosystem seems a lot more tolerant of such changes than most, whether because of that desire to move forward quickly or otherwise. That's great in a research language, but I don't think it is helpful for mainstream industrial development, because it does have practical consequences particularly in terms of maintenance overheads.

As every sane system does. So again, why are you acting like this is a haskell thing?

>but that doesn't fix the problem

Yes it does.

>every time someone makes a breaking change in a library API, everyone using that library needs to check through what actually changed to see whether it affects their particular situation

That is the case no matter what. If I write an SSL application in C, I need to pay attention if a new version of openssl comes out. Once again, this isn't even remotely a haskell issue.

>but I don't think it is helpful for mainstream industrial development

You are not required to update to every new version that is released. If you do not want to track the bleeding edge then don't. That's why we have upper bounds.

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

--max-backjumps 10000

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

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

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

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".

In this case, as in all others, the Haskell compiler would decide what is the optimal way to implement it, given whatever other constraints you've placed on the program.

You can add additional constraints that ensure the compiled code turns out to be in-place, at a cost of verbosity.

I mean, to a very large extent, this is the reason why classical imperative languages are so easy to understand and reason about. The programmers directions are much more straight forwardly executed than in examples like these hypotheticals.

Oh, I just got to your last sentence. Basically, that this would be a lot more verbose if written in such a way that it would be in place. Which is kind of the point of this criticism. Isn't it?

Don't get me wrong, the power of Haskell is not really in question. Just that example.

Sometimes, you really do want to make commands to the bare metal regarding exactly how you want the program implemented. For general use, however, you don't: compilers are (at least these days) a lot better at finding optimizations than the typical user.

It comes down to abstraction levels: pick the one that matches the problem you're working on. The FP philosophy is "speaking about specific memory cells is way too low" in most cases, like telling it you want a sorted list.

In fact, it would probably be even better (from that selfsame philosophy) to define a sort in terms of the conditions the final list would meet (as opposed to nested, recursing conditions like in the example). Something like, "return a list where every element is <= the one after it, and where every element is also in the original list, as many times as it occurs there".

If you want to see the examples of quicksort in Haskell to enforce in-place and other requirements, see this discussion here, with links:

http://www.haskell.org/haskellwiki/Introduction/Direct_Trans...

tl;dr: Yeah, Haskell is worse at letting you force the sort to be in-place, but that can be a very good thing.

That said, it is highly telling that none of the actual implementations of quick sort in any of these languages are that succinct. To the point that it is still a truism to "use a library" for something such as sorting. Because that isn't easy. Do not be fooled by such a quaint example.

http://www.haskell.org/pipermail/haskell-cafe/2009-August/06...

Twice as slow as C but without also in-place like C and extremely similar (see the sort function here):

http://en.wikibooks.org/wiki/Algorithm_Implementation/Sortin...

It's interesting to see is how very similar Haskel and C sources fundamentally become once they really solve the same problem and not the different ones.

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).