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

Functional Languages in Games: Plotting the Coup

[Slides as PDF]

As a games developer by trade, my experience of the industry leads me to suspect games development is approaching a tipping point where functional languages could enact a successful coup. The revolution would claim a chunk of C++-owned territory for the victor and mark an important milestone in the development of functional languages. It will not be easy. Games development is notoriously demanding and the successful functional language would need to meet stringent performance requirements, have clearly demonstrable ‘killer apps’, jump through hoops of fire and tell jokes at parties. This talk will discuss how close Haskell is to meeting these demands, the challenges that remain, evidence of functional languages already in games, and how Haskell compares against its nearest competitors.

Haskell For Games!

At first glance it sounds like a crazy idea. One to file away with the other crazy ideas to replace C++ with Java/C#/Python/etc. Most alternatives to C++ are so unlikely to succeed in practice that they appear to taint the very idea of replacing C++. I’ve written before about my high regard for C++,  but as powerful and effective as it is for games development, it does not represent an impossible challenge and we don’t have to look to replace it entirely. Finding it a suitable companion would be a major step forward and is the goal I’d choose to focus on.

Multi-core

There are powerful currents moving in modern computer hardware, pulling us inevitably into murky multi-core waters. However this movement also begins to make the idea of doing games development in an alternative language more plausible. What do we do when large multi-core systems become a standard hardware platform? (A reality that I note is only a handful of years away.) I have yet to see a parallelisation option that don’t make me think life in this new age in C++ will be rather hard. And would it be any easier in C# or Java? No. Multi-core life there will likely be just as tough. However, these aren’t the only options.

Functional languages

I’m far from the first to notice this, but pure functional languages – as opposed to the imperative languages most of us are used to – do at least have a theoretical advantage. Pure functional code does not have side effects. If you call it with the same parameters you will always get the same answer. It is thread-safe at a fundamental level giving opportunities for optimisation and parallel evaluation that are either infeasible or impossible with imperative code. They aren’t so alien as you may immediately think. You may well already work with such a language without really realising it. Ignoring some syntactical obfuscations, both CG and HLSL are essentially pure, referentially transparent languages. Neither language can wipe your hardrive or save state in global variables, and it’s no coincidence that they both optimise exceptionally well.

As you can well imagine, this is not an open-and-shut success case. Achieving good parallelism, even from a functional starting point, is still hard. In the previous example of CG/HLSL, the hard parallelism work is still done by the programmer by setting up the GPU pipeline, rather than magically derived from the CG/HLSL. Doing complicated, dependent operations in a GPU architecture is tricky and the subject of many GPGPU articles, although to be fair many of these obstacles are due to the current GPU architecture than the more fundamental issues in utilising parallelism.

Achieving parallel code that includes grubby details like nesting and runtime data dependencies are hard problems. But in the long term I think it’s more plausible to turn these problems into successes in functional languages than anywhere else. Compiler-parallelised code, even if partly programmer controlled, would be a Killer App for any alternative language, and one feature that C++ is unlikely to ever have. Without this feature, there are many other benefits for games development to adopt a functional sister-language, but the cost of doing so may cancel out the cost of the adoption.

Multi-core Haskell

I’m championing Haskell from the functional language pack for a variety of reasons, several of which are noted briefly in my talk and the rest I’ll expand on further in the future. I hope many of the benefits of Haskell will be apparent to anyone prepared to spend the time learning it, and I’d urge anyone interested to get stuck in immediately. There are several decent tutorials referenced from the Haskell Wiki, and I can highly recommend, “Learn You A Haskell For Great Good!”, as a great starting point. One other very notable highlight is the on-going research into extending the language to support Nested Data Parallelism. Although not complete, this research does look very promising and where I’m hoping some of the magic may take place.

Haskell for Games is by no means a done deal, but my enthusiasm for this project has at least withstood it’s first challenge – presenting these ideas to members of the Haskell community – and if anything has grown as a result.

Taking “X” to be a geeky subject: The belief that “X” is truly a thing of beauty but scorned, unloved and misunderstood by the masses is by no means a modern concept. But it lingers on all the same. I suppose it’s no coincidence that the culmination of many geeky subjects into a sort of geeky mega-subject (software development) might attract a bit more than it’s fair share of abuse. People at least have some respect for mathematicians and physicists, even if they choose to distance themselves. Tell people you develop software for a living and they promptly fall asleep, or complain that their computer never works. Unless of course, you develop games for a living at which point you become every kid’s best friend. (It’s a strategy I highly recommend.)

Here’s a few thoughts and some of my favourite quotes on the topic of beauty and software.

Art
First up is Donald Knuth’s, “Art of computer programming”. For non-coders out there, this book is the equivalent of Steven Hawkings, “Brief History of Time”, to most people: Everyone has heard of it. Many people own a copy. Some people have even attempted to read it but few have actually completed it and even less understood it. It’s the kind of “compulsory reading” that most programmers skip but know they probably shouldn’t have.

Knuth justifies his use of the word “Art” in the title:

Computer programming is an art, because it applies accumulated knowledge to the world, because it requires skill and ingenuity, and especially because it produces objects of beauty. A programmer who subconsciously views himself as an artist will enjoy what he does and will do it better.

You can almost hear a revolt starting.

Is coding Art? Well, I think there’s one thing missing in Knuth’s description that would make his assertion particularly convincing – Art can tell you something about humanity. Can your code do that? Well, I’m not sure. But, in the defense of code and the study of patterns in general, there are features and patterns of the world that are better reflected through them than Art. I think some of these patterns are surprisingly deep and beautiful – eigenvectors are the first to spring to mind. Certainly beautiful enough that I’d hang them on my wall if I could capture them in a picture.

Expression
You can express yourself through Art. Can you express yourself through code? Certainly. The most obvious example of this is the rapidly growing cross-over world of programming visual artists. Generative art is a topic all of it’s own, so I’ll just recommend anyone interested to check out Processing and follow links from there. I’m a fan of Robert Hodgin, especially this.

Is it possible to be defined by your creations, as many artists become defined by their output? This seems to be true of Justin Frankel, creator of several popular and sometimes controversial projects. There’s a popular quote to go with his resignation from AOL to go with this, but please be aware I’m including it with some reservations as it’s second hand and comes from a somewhat opinionated article. Just be aware it might be porky pies:

For me, coding is a form of self-expression. The company controls the most effective means of self-expression I have. This is unacceptable to me as an individual, therefore I must leave.

(I should probably also note his most recent project, REAPER, is absolutely fantastic and all you Cubase users should jump ship immediately.)

Elegance
I might be nitpicking, but I suspect the most common understanding of ‘beauty’ in reference to code is actually something closer to ‘elegance’ rather than beauty as such. Code elegance is arguably the reading-between-the-lines topic of many software engineering mailing lists.

Some noteworth texts from the small to the large include a decent blog post, On Beauty in Code; a presentation on how to go about writing beautiful code (in PHP of all things!); and of course there’s a rather interesting looking book, Beautiful Code. I haven’t read this yet, but intend to shortly. The highlight for me is an interesting review of a review of the book entitled, Code isn’t beautiful:

Ideas are beautiful. Algorithms are beautiful. Well executed ideas and algorithms are even more beautiful. But the code itself is not beautiful. The beauty of code lies in the architecture, the ideas, the grander algorithms and strategies that code represents.

I think that’s pretty much on the button.

Architecture
If your code was a building – an analogy that happens to be a good fit a lot of the time – you could marvel at it’s architecture. You could be impressed by the construction, or the balance of functionality and aesthetics. And like appreciation of architecture, a lot can be in the eye of the beholder!

Coventry’s Belgade Theatre.

Is it a “bold and dynamic” statement, developed through a “sculpural process” where “the spaces that it embraces, and that it implies around itself, are as important as the form itself”? Or, an unimaginative concrete cube ungracefully slapped into the middle of an already concrete-heavy town, representing little but the staggering lack of inspiration present in its creators? You decide! Comparisons with your most loved or love-to-hate software engineering projects as comments please.

Creation
Ignoring the code and algorithms for a moment, it’s undeniable that the output of code can be beautiful – after all it’s a major goal of computer graphics research. And not all of it involves artists in the traditional sense. Data visualisation has become a big topic in recent years. I find the growth of this area quite fascinating as it produces attractive, often intriguing images but apparently skipping over the role of an artist in a traditional sense and deriving input purely from real world data. It’s arguably an expression of humanity – although not quite in the same sense I originally had in mind!

On a personal note, I still remember the first implementation of our radiosity algorithm emerge. The whole thing happened quite quickly and we lost several days to just playing with it: tweaking the scene, changing the lights, adding some post processing. It was something none of us had seen before, and it took us quite by surprise. I’d had that feel-good effect from previous projects, but there’s something about actually being able to see the result and play with it that makes it all the more tangible.

Process
I clearly remember my tutor at university complaining that too many people focus on process over product. In fact, he was my music tutor complaining about composers, but the point applies very well to software engineering. But that’s not to say there isn’t beauty – even joy – to gain from the creation of code. This leads me to my last, but perhaps favourite quote of all time. Here’s Alexander Stepanov (author of the C++ standard library) and Mat Marcus in some lecture notes:

Programming has become a disreputable, lowly activity. More and more programmers try to become managers, product managers, architects, evangelists – anything but writing code. It is possible now to find a professor of Computer Science who never wrote a program. And it is almost impossible to find a professor who actually writes code that is used by anyone: the task of writing code is delegated to graduate students. Programming is wonderful. The best job in the world is to be a computer programmer. Code can be as beautiful as the periodic table or Bach’s Well Tempered Clavier.

It’s one of my favourite quotes because it’s so passionate: I too love programming! I love patterns and algorithms! The world is fantastic!

But – and it’s a big but – that quote simulateously shines light on the big elephant in the room: Software development is programming but with people. That ‘people’ part is vitally important, and is occasionally neglected by programmers of code, beautiful or otherwise. It mustn’t be. Coding is empowering, but the power still lies with people. I suspect software development does have a thing or two to tell us about humanity.

And that’s why software development really is amazing. Even if it’s simultaneous one of the most mind-numbingly difficult, painful and exhilarating things I can think of.