John Carmack: Thoughts on Haskell [video] (opens in new tab)

If you'll go read his opinions, you'll see that he has been a strong advocate for static analysis. His position is very understandable since he spent a lot of time working on complex pieces of C/C++ code, encountering a lot of subtle accidental errors that could have been avoided with better tools for static analysis or with a better language. He also worked mostly on client side software, where the fail fast / fail hard strategy of projects built in dynamic languages doesn't work so well.

Lisp vs ML vs others is a very subjective issue since languages involve different kinds of trade-offs, so optimal choices depend on the project or on personal style.

Also, this is John Carmack. For me he was a God 10 years ago and he's still one of the best and most practical developers we have today. Seeing him talk about Haskell is amazing.

BTW, I've been a big fan of Scala lately, and I don't see myself using much Haskell precisely because its tools for modularity seem limited. In Scala you can use OOP to build abstract modules, with the much hyped Cake pattern being based on that. Dynamic languages are naturally more modular, however I still prefer static languages.

Already mentioned in previous threads, but Tim Sweeney (Epic Games), who made a long presentations about the benefits of FP around 2006, is presenting a paper about a formalism related to dependent typing http://lambda-the-ultimate.org/node/4791

I can't watch his talk right now, but at QuakeCon he recently discussed Scheme, and the potential for embedding it in a game. I think he also pondered what Quake would have been if QuakeC was based on Scheme instead.

But my basic issue with talking about Carmack with respect to programming languages is that he never struck me as an expert on languages. Or even programming for that matter. The source code to Quake was on the messy side of things. His rationale for switching to C++ always seemed a little on the thin side of things, and seemed more like industry pressure than anything. He's great on concepts, on graphics, and keeping up with OpenGL and whatever NVidia/ATI are doing. But he's just now coming around to Scheme and Haskell. I don't really think his perspective on languages carries that much weight to be honest. But I'll listen to him talk about it anytime.

This is highly anecdotal, but I've built and been part of very practical/non-theoretical, large Haskell projects (100k+ lines, which is a lot for Haskell). The only big complaint I have is that it's somewhat hard to do loose coupling, i.e. for something somewhere to reference a type without either redeclaring the type (when that's possible), or having a huge, centralized Types.hs that declares all the types that are used in different places (to avoid cyclic imports.) (Contrast with e.g. Go or ML where you have interfaces/modules without 'implements'.)

This isn't unique to Haskell by any means, but it's the only real complaint I have about Haskell as a language for non-toy projects. The benefits definitely make it my go-to language. It's hard to list them all, but by far the nicest feeling is the correctness: when your code compiles, 60% of the time your program works every time. (Not to imply that tests aren't necessary--QuickCheck is great for that.) It's an otherworldly feeling to write a program not in terms of what to do, but what kinds of filters you want to put on something, and have it just work (and either stay working, or break future compiles if something's changed!) after compiling 10 lines of code, when you would have written at least 50-70 and had to debug it in almost any other language.

Edit: I'll add another complaint: Haskell is like C++ in that it's incredibly easy for a codebase to become completely unmanageable if your team doesn't have a common style/discipline. Go is a nicer language for "average"/"enterprise" teamwork, I think, since it almost forces you to write programs in a way everyone will understand. If you're in a team with good programmers that you trust not to abuse the language, this is a non-issue.

Edit: Okay, another one: If you change your Types.hs, the recompilation can take a long time in a large codebase, similar to C++. But GHC/Cabal keep getting faster.

Think that's it.

I think it would be fair to say that Wolfenstein would qualify as a relatively small system in Haskell. Haskell's own compiler, GHC is a highly complex system and one of the most sophisticated compilers in existence. The source is free, so it's a great way to see what Haskell looks like when used for large applications in the hands of experts.

If you want to see where Haskell is being used in industry, check the Haskell in Industry page out: http://www.haskell.org/haskellwiki/Haskell_in_industry

And if you really just want to see what it is like for game development, check out Frag: http://www.haskell.org/haskellwiki/Frag

Haskell is very well suited to large applications in my personal experience. My feeling is that it is actually worse for small-scale applications where you don't need the type system guarantees it provides.

I've been using the xmonad window manager, which is roughly 1000 lines. While not a vastly complex system, it's non-trivial, especially solving things like gui interaction in a side-effect free world. I believe they had to use some sort of zipper structure for the mouse detection to overcome things that are easy in other languages.

You should check out Real World Haskell, it's much more practically focused than other things.

This is where I'm at with Go.

Go seems to have been used in lots of networking-related scenarios, but I have yet to see either a major graphical application or even well-known open source game written in it yet.

I would love to see what the architecture of a 3D renderer looks like in Go, as an example.

Like you, I also share the same interest with Haskell.

Laugh as you might, but this is the interface of Datomic, the database system by Rich Hickey, the creator of Clojure.

To perform a query, you connect to a database and request the present state of the database. This is an immutable representation of the database at that point in time, and you can query it however you like, or even hold on to it forever. Of course, the database isn't actually fully copied.

I don't really get the joke. Generally functional languages will share more data than imperative languages, and therefore will copy less data. In an imperative language, it makes sense to copy whatever data you are working on, so your modifications don't inadvertently affect other parts of the program. In Haskell it doesn't.

Explain?

Reminds me of something a former boss used to say. "Pay me now, or pay me later; either way, there has to be a payment". It sounds like Carmack is saying that brutal purity always forces the "pay me now" approach since it's harder to write this code, but it is worth it in the long run.

While i can see his point, I'm not entirely sure this is the case. A text-book example of a multi-paradigm language is Scala. And yet with Scala, the more I've learned about the functional side of things, the more tempting it is just to avoid any imperative or object-oriented idioms or patterns and just go functional all the way. it's almost as if the designers of scala knew if they could convert java programmers over, the temptation to do bad things would go away if only because functional is so much more elegant that it doesn't make sense not to use it as much as possible.

He starts talking about FP/Haskell at the 2:06 mark.

http://www.youtube.com/watch?v=1PhArSujR_A#t=126