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.