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.

Haskell's tools for modularity cut in a dimension you're not used to, and if you're not experienced with it, won't see. Percentage-wise in the last 15 years I haven't spent that much time in Haskell, but it's Haskell's tools I'm missing more often in imperative languages than the other way around. (And note the "more often"; it's not that I never miss more conventional tools in Haskell, it's just that I spend more time missing Haskell tools in other languages.)

> ...I don't see myself using much Haskell precisely because its tools for modularity seem limited.

> Dynamic languages are naturally more modular

Why is that? I'm pretty convinced pure and especially lazy languages allow for great modularity.

See http://augustss.blogspot.nl/2011/05/more-points-for-lazy-eva... for an interesting view on this.

I would think it is because of how "modules" can effectively be "bolted" on top of existing things quite easily.

Consider putting a new "module" on a bicycle. If you were doing it statically, it would have to have the screws in the proper place to be able to attach as it needs. Dynamically, however, you just use a zip tie to hold your piece onto the bike.

To be sure, if you buy a nice bike, many of the common attachments have "static" points where things can be added. If you want to place a holder for a phone, however, you are much more likely to do something that is much more adaptable at fitting things on.

becomes much more easy to bolt on funct

Yeah, Carmack has weight due to his history of being incredibly technical and writing lots of incredibly useful code. Also, he has a huge profile in the industry.

He's been a heavyweight proponent of static typing for a while - 2-3 years IIRC - and so it doesn't totally surprise me that Haskell is up his alley. It's particularly notable that he prefers it as a technical lead as a low-pass filter on bugs.

Tim Sweeney (Unreal Engine) has also written about haskell and specifically STM (http://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-...) and more recently on dependently typed languages (http://arxiv.org/pdf/1307.5277v1.pdf).

Thank you so much for that second link! I've been interested recently in how dependently typed languages can be made more natural for general-purpose programming, and this looks like a really good read. It gives me hope that it won't be too long before there's a dependently typed language comparable to Haskell in terms of community and ecosystem - in my (limited) experience, Agda and Idris are awesome for theorem proving and for small programs, but they're both a ways off from being usable for large, complex programs, and I feel like a big part of what they're lacking is just well-documented libraries for common operations.

I agree.

When Carmack speaks, I do listen. He's a very good programmer and has the level of experience and technical expertise few will get to enjoy. I think it's awesome to see how far he has come from being a C purist, to C++, and now nice functional languages like Haskell.

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

Here's one of the presentations comparing C++ to Haskell http://lambda-the-ultimate.org/node/1277

http://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-... (PDF)

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.

To me, that is a great reason to listen to him.

He builds big and complicated programs that people actually use.

Agreed. I listen to him because I want to know what's practical, not necessarily what's theoretically stimulating.

> He builds big and complicated programs that people actually use.

That's kind of an insult to, well, every working programmer.

Most people don't build big and complicated programs.

Please qualify "most people".

As an intermediate haskeller (I use it for my business every day) his criticisms largely mirror mine. I found the quake codebase to be great in the 90s. I have also found him more than most other developers to admit when thing didn't work out, specifically that doom 3 was c++ in name only and he didn't fully understand it. A scheme based language would have been better for most modders than quakeC.

There is a reason Lua has taken over so decisively: speed, simplicity, and good support for both functional and oo programming.

> As an intermediate haskeller

Are you serious?! If you're only intermediate - then there's no hope for me!

That's one of the nice things about the Haskell community. The experts tend to be much, much better than in other places. There's much more depth there than memorization of quirks and ability to hold large numbers of arbitrary, disconnected pieces in your head all at once.

So, while becoming an expert haskeller is enviable, intermediate still suggests an ability to tackle a Fantastic array of problems.

Indeed - it's definitely one of the best places to be if you like to be surrounded by incredibly talented, but also very humble folks.

In fact I'd go so far as to say that the pool of wicked smart people who would love to build stuff in Haskell represents a significant opportunity to start ups right now. How have you found hiring for your company?

I asked around speculatively and got great response. Right now we've got exactly the team we need, and I'm not too worried about hiring in the future.

Well while I can produce large swaths of elegant code when I need crazy instances I usually call upon my colleague for his invaluable assistance. I don't claim to be an expert in the language. Many people know much more about it than me.

I've been trying to come up with a general way to rank Haskell experience, and so far I've got:

Beginner: Can read the basic syntax, knows about E.G. Monads and folds

Intermediate: Understands and can use the more advanced classes like Applicative, Arrow, lenses, and how to use things like fix

Advanced: ??? Makes new powerful classes/libraries like Pipe, Conduit, or Netwire? Can easily translate a problem domain into a concise and elegant type representation.

Maybe there needs to be some more layers in there, I don't know... also the advanced level feels weak to me. I'm still somewhere between beginner and intermediate myself.

Well I don't claim to understand the mathematical basis of Monads, and I don't use arrows and just started using applicative more often. Lenses rock and I have used those for a long time. I do build my own Monad Transformers so maybe I am still a beginning with intermediate tendencies. :-)

If Carmack isn't an expert programmer, no one is. There are very few people with a comparable resume.

Being an expert C++ programmer doesn't make you an expert Haskell programmer, or vice-versa ;-)

I can understand saying he isn't an expert on languages, but to say he isn't an expert programmer is honestly just condescending.

What I meant by that is that he doesn't use what most people qualify as "best practices" today. At least per the language he uses. If you look at his (or id Software's, rather) C++, it doesn't follow anything resembling standards in that area. They don't use design patterns, there are straight C (stdio, for example) calls in C++, etc.

I'm not saying that's bad. But it's obvious he doesn't keep on top of trends that well. Or languages, for that matter.

An outside perspective is valuable in its own right, and especially when it comes from a widely respected programmer. I think it's valuable to have both long time expert users, intermediate users and relatively new users chime in on issues: the experts often lack a certain perspective, since it was so long ago that they were novices themselves. And of course the intermediate and novice users lack experience. Together they can hopefully complement each other.

I think that's part of why people are so interested in his opinion in this case. The games programming industry has some very unique challenges, and the focus on squeezing every last drop of performance out of the stuff you write tends to make it a pretty brutal environment for programming languages. From his background as a voice of authority in the games programming industry it's interesting to hear his feelings on the merits/drawbacks of something like Haskell specifically from that perspective.

The fact that he's not a long time user, or particularly a fan of functional programming, but a relative newcomer to it just adds more weight as he isn't some known fanboy that's going to praise FP no matter what. He's got extensive background in C, and at worst, average C++ skills if not considerably better than that, so he makes a fairly good case study of how practical it is for a non-functional programmer (but someone who's really experienced with imperative/OO programming) to pick up something like Haskell and actually do something useful with it.

It's also good to listen to the things he doesn't like about Haskell, E.G. debugging, and see if anything can be done to improve that.