Tag Archives: C++

Why isn't Haskell popular in Industry?

This question was recently posed (and closed!) on stackoverflow. The top voted reply is so good I thought I'd replicate it here! I'm afraid all I know of the original author is their "Orphi" posting name.

It's tongue-in-cheek and broadly true, although I'd argue the details of a few points. I think it's interesting that it doesn't contain the main reason blocking me from using it on a daily basis. More on that in a moment.

First, here's Orphi's response:

  1. Nobody's ever heard of it. No one's going to use something they don't know exists.
  2. It's unpopular. People assume that the most popular language is the best language, because if it wasn't good, it wouldn't be popular. This is actually untrue; as you can see, the most popular language is the most popular language. To put it another way, Haskell is unpopular because it's unpopular. This is what Haskell programmers refer to as "recursion", and despite what imperative programmers tell you, it's extremely common in The Real World.
  3. It's different. People are always afraid of what's different.
  4. It's difficult. People think that Haskell is difficult to understand or difficult to learn. This is almost certainly related to point #3. It's also related to the fact that the Haskell community is populated by people who casually remark "a monad is just a monoid in the category of endofunctors, what's the problem?" and expect normal human beings to comprehend this.
  5. It's risky. Most companies don't want to be the first to use something. Haskell isn't being used by many people, so not many people want to try it. (See this recursive unpopularity argument again?)
  6. Can't hire programmers. First, by #2, there aren't many programmers who already know Haskell. Second, most people believe #4, which means you can't train programmers to use Haskell. (At least, it would if it were actually true.) A language that you can't hire programmers for is a very, very risky proposition indeed. (Which leads us back to #5.)
  7. Libraries. This is probably the big one, so I'm going to spend some time on it.
    • Quality. We have the quantity. We do not yet have the quality. Most of Hackage is one-man hobby projects with little to no documentation. Some of it is incomplete, some of it has long since bit-rotted, some of it malfunctions if used in certain ways.
    • The Outside World. If you want a binary heap tree, Hackage probably provides a dozen implementations. If you want to connect to an RPC server and fire off a few procedure calls... good luck with that. Same deal for talking to databases, accessing OS resources, manipulating binary file formats... You'll basically have to write everything yourself from scratch. This is a big deal for commercial work.
    • Multiple incompatible libraries. You can, in fact, connect to a database in Haskell. Trouble is, at the last count there's about a dozen libraries for doing this, and it's bewildering trying to figure out which ones are actively supported and which ones are zombie projects that stopped working years ago. It's also not as simple as hooking up an ODBC connection; there are different backends for each library and each DB target. Yay. :-/
    • Windows. Almost all the important libraries (for cryptography, binary file formats, network protocols, data compression, talking to databases, etc.) are Haskell wrappers around C libraries. And these all fail to build on Windows. Given that Windows is
      the single biggest target platform on the market, this is a big deal.
  8. Unpredictable performance. This is way, way down at #8. Most people don't know enough about Haskell to even know this. Most people just assume that "Haskell is slow". This is demonstrably untrue. What is true is that it can be hard to predict the performance of a Haskell program. Subtle, apparently irrelevant changes can sometimes make big performance differences.
  9. Correctness. Most companies don't give a **** about correctness. They don't care about quality. They just want to shovel code out the door as fast as possible and earn wads of cash. If there are bugs, they'll charge the customer money to fix them. Getting code right is of no interest; getting code fast is what counts. Haskell is a language that rewards those who sit back and deeply analyse the problem, and then produce a beautiful solution. Most companies don't care for this approach; let's just hack something together as fast as possible, and worry about fixing it later (i.e., never).

There are a few places where correctness matters. These are either safety-critical systems, or financial systems, generally. I gather Haskell tends to be quite popular here.

One final pair of data points:

  • I can still remember not so long ago hearing people cry "C++ is a toy language for n00bs! You should use a proper programming language like C." Now take a look around you and see how many large-scale C++ programs there are.
  • People have been claiming that Lisp is "the next big thing" for, what, 40 years now? Lisp is older than almost every programming language in mainstream use. And now many large-scale Lisp programs are there?

Which fate awaits Haskell, I don't know. I rather suspect all the good ideas of Haskell will be stolen by the likes of C# and hybrids like F# or OCaml,and people still won't ever use Haskell itself. It's just too different.

But anyway, as to why industry doesn't use Haskell, see the points above. It's too rare, too unpopular, too weird, and has incomplete libraries. That's basically it, in a nutshell.

Embedding Haskell?

The missing item for me is how hard it is to embed. For my purposes, I need to embed Haskell within an existing C++ framework, not dissimilar to how you might embed Lua. I need to do so in a compiler agnostic manner, where I retain control over how the embedding occurs (i.e. compilation and linking) and have significant influence over the operation of the runtime. In short, Haskell must fit in to my existing C++ environment, not the other way round.

An interesting aspect of an "Embedded Haskell" would be you could remove most (if not all) of Haskell's IO support if it made the job of embedding Haskell significantly easier. The ability to efficiently embed 'pure' Haskell would be a very interesting and useful tool in it's own right 1. It's a simple idea, and therefore doesn't take many words to state, but I'm keen to not understate how significant this could be.

Incremental adoption

Playing the counter argument, it could be argued that my needs are rather domain specific and an Embedded Haskell is not likely to be important enough to aid mainstream adoption of Haskell. This attitude does appear to be reflected in some parts of the Haskell community.

To start anecdotally, when I hear people propose writing something in Haskell, they generally imply the only option on the table is to write it in Haskell wholesale. Most arguments about use of Haskell I have read online focus on this either-or situation. For nearly all the reasons made in the quote above, this polarised position doesn't appeal unless you have very tailored circumstances and considerable resources.

There is also evidence of a lack of emphasis at a more fundamental level. GHC and the tools and libraries ecosystem that surround it are not designed with embedding as a goal. GHC is primarily focused on producing stand alone executables, which it does very well. Interoperability tools like Greencard immediately sideline the ability to call Haskell from C as having "little demand". Most emphasis is placed on wrapping C libraries for use in Haskell. The best I can find online are some open student projects such as the ageing GSoC ticket #1555, or the Embedded Haskell thesis topic in the PLS group. I believe this situation might be starting to change though, as the desire to remove the implementation obstacles surrounding much of Haskell's inspiring research builds, and new developments such as the LLVM backend present additional options.

Wholesale adoption of Haskell is undeniably risky and definitely not the only way. Incremental adoption is where it's at, and in a nutshell, that's what Haskell is currently missing the most.

  1. As an interesting historical aside, when Haskell first took up its purity banner, monadic IO did not exist and Haskell programs were pure functions of type [Response] -> [Request], where these types provided a limited set of options such as ReadFile, WriteFile, RequestFailed, ReadSucceeded for the side-effecting wrapper program to interpret. (See the Awkward Squad tutorial for further details.) Generalise this to a pure iteratee and you are probably in the right ballpark. []

C++0x, "just about everywhere"

When I started this blog I promised myself not to post rants about C++. In something as large and complex as the C++ language there is always plenty of material to rant about, and I figured I'd quickly bore myself and everyone else. To be honest, I was planning on attempting to forget about C++ altogether as a fact of life every programmer must live with and learn to love. But here I am, writing about it quite fondly.

"C++0x" is the working title for the now feature-complete upcoming ISO standard of C++, hopefully to become "C++09" this year. In any coders diary, this is a significant occasion and shouldn't go by without some pause for thought.

I'm not going to comment on the contents of the upcoming standard for a while, but if you work with C++ I highly recommend you check it out so I'll provide some links at the end.

I'm currently more interested in the development trend of the language itself. The process is fascinating. Plus, I am cooking up a proposal for a new language project based on C++ that could be an interesting angle - but that's for another day.

Significant standards

The first standard for C++ came in 1998, almost 20 years after it's conception in 1979. By 1998, C++ itself had long since 'dug in' and by many accounts the standardisation effort was a big painful undertaking. Unsurprisingly it wasn't perfect and "C++98", as it became known informally, had a spring clean in 2003 but without any significant changes an end-user would notice.

C++0x represents the first major revision of the language since it was first standardised as C++98, and looks to be another dramatic undertaking. It's a pretty bold move on many levels. It has many bright innovations and the current draft appears to be very well thought through.

I find C++0x even more remarkable when considering how it has been developed. On face value, the end product could be considered fairly impenetrable and bears more similarity to a legal contract than a working design. The C++ standardisation committee is a huge international democratic effort with nearly 200 members consisting of "corporations to fanatics". It has no owner. It does no marketing. But it appears to know that the decisions it makes through its huge, painful, diligent and slow process will effect the lives of literally millions of developers. I think it's a spectacular organisational achievement and its coordinators probably possess saint-like levels of patience :).

C++ "everywhere"

Now, in theory, you could write any application in assembler - but it doesn't scale so you'd struggle to write large, complex software with it. And you couldn't write every application in C# or Java. As interpreted, garbage-collected languages, they are just not always going to fit with your hardware or application's performance demands. C++ is in a sweet spot.

Even so, I have a love/hate relationship with C++. On one hand, I've spent many an hour teasing out holes and swearing at my compiler, but on the other I have no doubt my job would be more more difficult without it. Despite its flaws it is a language that is unique in the range of applications it can address. And because of this it's a language that's "just about everywhere".

I'm quoting Bjarne Stroustrup, from a talk he gave to the University of Waterloo last year. As the language's father and original author he may have a bias, but he has some evidence to support his statement. It's arguable that this applications list could well be cherry-picked, but I'd hazard a guess that he's likely to be more in touch with the users of C++ than most, and frankly I agree with him.

Endless growth

"Give a man enough rope and he will hang himself". There's even a book on C/C++ with the same title. As I published this post I discovered Bjarne is quoted as saying, "C++ makes it harder to shoot yourself in the foot; but when you do, it takes off the whole leg". His argument is really that the idiom is as true of C++ as it is of any powerful tool. I think this is a fair point but I think it is still a valid concern to have of popular language, particularly one that's growing.

So, given the language is about to expand even further, I spent a surprisingly enjoyable couple of hours one Saturday morning watching Bjarne talk through some new features in C++0x and comment on its development.

C++0x appears to me to not be an extension in the sense it just provides some new features. In the literal sense, this is exactly what C++0x does. But when inspected more closely, some of the features actually help clean up some of the extraneous cruft. To me, features such as initialisation lists and concepts appear to be part of a crafty expand-but-consolidate manoeuvre. If you're worried about having too much rope, then this is the best possible route the committee could have taken, so I am suitably impressed.

Subtraction

The committee have one hand tied. They simply can't subtract. It's practically impossible for them to remove features or they risk breaking people's existing code and the fallout from that could be enormous.

To be fair, the standardisation committee pursue some other options as well. They look at revising the C++ standard libraries (stl). Libraries are a far simpler way to extend a language as they are intrinsically "turn on and off-able" in a way language extensions typically are not. Opinions on the stl tend to vary, but I don't think many people would argue that they could be considerably better.

Libraries are not immune from the subtraction problem. But it's definitely an area the committee could do a lot of further good.

C++ is dead. Long live Java/C#/Python/etc

Although it's not specific to C++, the 'subtraction problem' is a rather fundamental problem with all language development - and perhaps much "live" software. Like many humans, software has a tendency to grow-up too quickly, become fat and fidgety at the peak of its powers, leading to the inevitable replacement by younger leaner contenders.

Given the inevitable growth at each revision - however well constructed the revision - how far will the life of C++ extend? In the long run, is C++ condemned to expand its way to death? This is certainly the view many people like to hold.

The death of C++ was being widely touted while I was at university in the 90s, rather conspicuously around the same time the first ISO C++ standard was being agreed. C++ was an old messy language that Java would replace, we were told. This belief extended into the course structure where no C or C++ option was offered. As a consequence I was never taught the language I've used daily ever since. And to be honest, I would not be surprised if some universities continue to do the same thing now.

Despite it all, C++ lives on and does so with relative ease. C++0x should further increase the language's lease on life. However, C++0x will not - and can not - resolve all the problems with the language. Assuming we believe perfection is possible, to do so requires subtraction, and subtraction requires an alternative approach to the standardisation committee. I have a proposal brewing on this topic, which I'll return to in a follow-up post.

Some references