Productivity is somewhat subjective, and I disclaimed that I was focusing on larger projects.

“Brand X” meant a common imperative language as typically used. If you have great developers and you’re using Python or Ruby, you can still get a fast growth curve. It’s just harder and relies on social contracts that don’t always scale. Dynlangs tend to suffer from a “one bad apple” problem more than statically-typed languages.

As for the salaries, I have a lot of data but I’m not allowed to share it. With $1.00 indexed to the median Java engineer, those numbers are about correct. Can I defend those numbers down to the penny? No. Does experience confirm that Haskell engineers are a comparative bargain? Absolutely.

I was at the talk and the closest thing you gave to support for these slides was that claim the salary numbers were based on unverifiable private conversation.

That doesn’t support your claims about effectiveness over time in Java, “Brand X”, or Haskell; the relative effectiveness of Java, “Brand X”, or Haskell; for salary differences at different levels of effectiveness; measuring different levels of developer effectiveness by percentile; knowing the distribution of developer effectiveness in Java and Haskell; or comparing effectiveness at different percentiles for Java and Haskell developers. You made huge, sweeping claims based on nothing at all. Cite evidence or stop handwaving.

If there’s a flaw in my learning curves, it’s that I was probably conflating cultural behaviors with languages to a large extent. Aware of this, I put “enterprise Java” instead of “Java” at the bottom. Java doesn’t intrinsically emit moron rays that force people to make VisitorFactory classes: that’s cultural. So the green curve (the good one) might only actually apply to Haskell and the culture I imagine would emerge from it in a typical production setting, based on past experience and observation of the existing community.

Salary data is a mess, because the easy-to-get public stuff isn’t that informative and private data is often either anecdotal or company-specific. That the difference in salary between Haskell vs. Java is much smaller than the difference in productive output and programmer talent isn’t really debatable by anyone who’s been involved in hiring or management (which I have) for more than about 12 seconds. If anything, the numbers I gave under-represented the case.

So the green curve (the good one) might only actually apply to Haskell and the culture I imagine would emerge from it

isn’t really debatable by anyone who’s been involved in hiring or management (which I have) for more than about 12 seconds

Thank you for admitting that the graph is not based on evidence but your imaginings, and that the rest is based on your anecdotal intuitions.

In case anyone is wondering why those are the only slides I’m asking about, I recognize where much of the rest of the uncredited material was taken from. The horseshoe story about Java comes from Steve Yegge’s “Execution in the Kingdom of Nouns”, the fixation on static typing comes from Brian Hurt’s “A Pragmatic Case for Static Typing” (though Church left out the key section differentiating the static typing in Haskell from the static typing in Java), the bit about hiring good Haskell devs being easier comes from Paul Graham’s “The Python Paradox”, “Brand X” and the ALGOL rant comes from David Given’s “On Go”, and so on.

Reminds me of the old quote, “Your manuscript is both good and original. But the part that is good is not original, and the part that is original is not good.” I hope people do not judge Haskell or the Chicago Haskell group by this talk.

Church edited his response to this comment to remove mention of him banning me from the Chicago Haskell group. The group had existed for several years at ChicagoHaskell.com before he appropriated its name for a Meetup group featuring this talk of his.

The slides have also been edited in response to my comments, but I don’t have an earlier version to know how broadly. I posted narrowly about the most unambiguously dishonest slides, but it was the rest of the talk’s constant insults of Java developers, business decisionmakers, startup financing, etc. that got me grumpy enough to publicly interact with this troll.

I will happily consider myself banned from future events run by Michael O. Church.

I changed the labels on the salary estimates to qualitative labels, not because of him, but because someone else pointed out that they detract from the presentation– and, on looking at them again, I agree.

The productivity graphs are not intended as precise or exact, and I already addressed here that they probably pertain more to behaviors and developer cultures than languages themselves. In no way were they “dishonest” slides, and he is the only person who has taken them that way.

Peter did not approach me at the Meetup with any objection, nor did he speak to me in private when asking for clarification on the slides or suggesting that they were misleading. I may have interacted with him in person, but have no memory of it. He is trying to make a name for himself via drive-by snark, and there’s really nothing else to see here.

I wish I knew exactly what you’re trying to achieve here, and whose friendship you’re trying to win.

Are you trying to make a name for yourself? I understand the impulse, but I’m a small fish; you’d get more attention if you scratched higher.

I deeply resent the implication that my material was unoriginal. You’re right that Steve Yegge uses the “for what of a nail” rhyme (his variant is more elaborate and interesting in its own right; I didn’t want to get into Java’s flaws, as deeply as he did, on slides) but I did not have this in mind when I wrote my slides. In fact, I haven’t read that essay, though I’ve heard of it and I probably should have. It’s a fairly common parable (for what of a nail, that is) and applicable to technology. It’s not surprising that it would show up in one place.

The “fixation on static typing” might have something to do with… the fact that Haskell is a statically typed language.

The coincidence of “Brand X” is actually detrimental, insofar as I had a different meaning for it than David Given did. I’d never heard “Brand X” used in that context. If I had, I wouldn’t have used it for my slides because my points had nothing to do with ALGOL.

the bit about hiring good Haskell devs being easier comes from Paul Graham’s “The Python Paradox”

Yes, I have read that article, but it “comes from” personal experience, because it’s actually true. Spend some time in a leadership or hiring role in a company of sufficient size, start interviewing people, get a sufficient sample, and get back to me.

Reminds me of the old quote, “Your manuscript is both good and original. But the part that is good is not original, and the part that is original is not good.”

It’s ironic that you’re forced to fall back on a lame misattribution (Samuel Johnson never actually said that) just to come up with a 2-bit insult.

Can we rename this: “How to sell Haskell” (because most of it is about Haskell)

I wonder if more experienced people than me can link to articles that sell other languages that were hip in their day. Say, like “COBOL blows assembly out of the water: how convince your manager”. That would give me some context for the hype

Personally, I’m fascinated my Haskell. I’m slowly trying to learn it, but I’m even more fascinated by the hype. It offers a glimpse into zealotry and general hammer-nail type of thinking.

Huh? I have a strict superset of options in Haskell for solving problems as contrasted with, say, Golang, Erlang, Java, etc. It’s precisely because I don’t want to be stuck with one tool that I use Haskell.

Race conditions in Golang? I have IORef and atomicModifyIORef.

Erlang copying overhead is too costly for your problem? MVars and Chans in Haskell let me send references, not just copy data - which is safe because everything is immutable by default.

OS threads are expensive? I can use forkIO for the green threads that are as cheap as Erlang’s. This enables code written in a synchronous style to be made concurrent & performant without a rewrite. Want to write it in an explicitly asynchronous style with CPS anyway? Go for it.

Haskell isn’t really being hyped. It has become practical for real-world business use. It probably was so, for years if not more than a decade, but people (myself included, as I didn’t give it a serious look until a year ago) are slow to realize such things. People are becoming aware of this now– and it’s still a niche language.

I think it’s quite good. People are friendly, if opinionated. I do think that some are a little bit too prematurely dismissive of dynamic languages.

I’d like to see Haskell’s community take on the good traits of Clojure’s. I prefer static typing over dynamic, but Clojure has a great community: one focused on practicality, outreach, and user-experience. Clojure has 2 national conferences in the US (Conj and West) and Haskell has zero, and that could stand to change.

Well, I gave one example: the suggestion that because of all that Haskellory theory (the parts of category theory that interest Haskellers), I should like Haskell just because I like math. I’m sorry, the most interesting parts of category theory for me are things like the Galois functor or how there is a natural transformation of double dual of a vector space, or the snake lemma, or flatness of modules, or the functoriality of tensor products. These interesting topics never come up in Haskellory theory. I don’t think the average Haskegorical theorist cares that much about abelian categories.

Also, yes, the enamourment that Haskellers have with “pureness” and how IO is the only way to handle impurity, and how OCaml gets it all wrong because it allows plain for loops, or how there’s no possible way that some of OCaml’s awesome ideas like named function parameters could ever be adopted into Haskell, or how complete un-arbitrary and reasonable Haskell’s precedence rules are. I still stuff parens everywhere, to the point where my Haskell almost looks like sexps, because I can’t remember these precedence rules.

I also don’t like that Haskell turns simple things like a Fibonacci implementation into an interview puzzle. It’s not that I am stupid (I am), but why are they puzzles to begin with? I want a programming language for doing things, and things are done in order, one after the other, with state, with loops, whether explicit or implicit. I don’t want to think too hard to translate my thoughts into code. I don’t want to contort my thoughts into a mold that will fit a programming language.

The final thing I have with Haskell, not Haskellers, per se is that I still have no clear conception of the execution model. What is going to allocate a lot of memory? What is fast, what is slow? How do I profile? How do I step through my code in a debugger? I realise this is just a limitation of my current Haskell knowledge.

Category Theory I am still trying to “grok”. I can see its usefulness, but most of what makes Haskell a great real-world language is only very loosely connected to CT. The concept of a Haskell Monad (or Functor, or Monoid) is incredibly useful but I almost find the word to be somewhat of an albatross. There’s a misconception that you have to know Category Theory to get Haskell, and that’s demonstrably not true. I know very little Category Theory.

I like OCaml’s named function arguments and don’t think OCaml “gets it all wrong”. I see OCaml’s niche as being in the very-high-performance single-threaded space and in system programming, where stateful effects are common and sometimes necessary. (OCaml doesn’t have, to my knowledge, the sort of ultra-powerful compiler that can make Haskell fast.) So I’m not bothered by its lack of IO annotations on functions. It’s still far better than nothing.

There’s a great book on Haskell performance called Parallel and Concurrent Haskell. It’s not a good first Haskell book (I’d look at Learn You a Haskell and Real World Haskell first) but once you know Haskell itself, it’s one of the best books (as far as Haskell books and multithreaded programming books go) out there.

(OCaml doesn’t have, to my knowledge, the sort of ultra-powerful compiler that can make Haskell fast.)

This is true, but also has some quite nice features: it’s very easy to look at Ocaml code and predict what the assembly will be like. The memory model is very understandable and the code is quite understandable. This is great for scaling in production. That is one thing that would make me think twice about Haskell, the distance between what I write and what runs on the machine is quite large. It’s certainly understandable, but with Ocaml it’s quite simple. Real World Ocaml is also great in that it explains these things at an operational level to the reader.

In my experience that might be nice, but since Ocaml is already pretty fast the motivation just isn’t there. My main concern with the language is it continues to be come more complicated with more concepts. What has drawn me to it is it is the ratio of complexity to simplicity. I worry in a few years that will be very eroded.

I can certainly understand where you are coming from but I think that the talk goes a bit deeper than Haskell. Really it’s about how to sell business on an idea, wrapped up in a Haskell story. I think it’s pretty positive that he argues for equality with business and that we need to adopt a way of talking to them that matches what they understand. That doesn'thavr anything to do with Haskell.

The evil isn’t coming from “business”, which, as you said, is language-agnostic and just wants the products to work.

The problem is that mediocre ex-technologists (who often failed out of it) are better at selling Big Java and “Scrum” than we are at selling Haskell and the ideal of doing things right the first time.

Trust isn’t transitive. I might trust Bob but I don’t trust everyone Bob trusts. Every one of us have blind spots. I think my tax accountant is good at his job, but I don’t really know because I can’t evaluate the work in the way that an accountant can. Likewise, a smart business leader can still fall prey to an idiot if he picks the wrong guy to listen to, when it comes to technology. I’d be as much in the dark if I had to hire a non-technical executive on limited information.

I think the downvotes on your post are indicative of the fanatic zealotry of some Haskellers. Just because a language is good doesn’t mean it is good for everyone and everything.

Reality-check: Purely functional programming is /not/ necessarily better than other paradigms, it’s just different. It really is not in most companies best interest to convert gigantic codebases to Haskell. Also, that slide deck fails to emphasize that it is very difficult to find Haskell developers in many parts of the world.

I guess the word Zealot is slightly pejorative. However, “Enthusiast” doesn’t quite capture it either. There is a sense, in many Haskell presentations, that you ABSOLUTELY MUST USE IT, or you are, quite decidedly, an idiot and an old fuddy duddy. I’m not saying at all that this presentation is like that, but the presentation did come across to me as full of zeal and conviction.

There is a sense, in many Haskell presentations, that you ABSOLUTELY MUST USE IT, or you are, quite decidedly, an idiot and an old fuddy duddy.

Exactly. Give me another word and I’ll gladly use it instead. Zealot just seemed to fit the bill.

Also, just for the record, I love Haskell. I just find that many Haskell programmers think that they have reached the epitome of enlightenment, and then proceed to look down on everyone else for not reaching enlightenment, and also make it out that it absolutely must be used FOR EVERYTHING. Not to mention that when people think they know monads they tend to think they are the elitist of the elite and the brightest programmers ever.

“Purely functional programming” is a weird concept that exists largely in academia. I love diving into theory as much as the next guy, but I don’t like Haskell because I have any conception of “statelessness” being meaningful. I like it because it’s a practical language in which you can write very trustable, fast code.

Practical FP is about managing state, not eliminating it. It’s about composition. An IO is capable of anything. It’s very powerful. But when we’re reasoning about code, we like the pieces to be less powerful. If we can make a system where simple/“less powerful” components can quickly and reliably be snapped together to make powerful software that we can still reason about, that’s great. Of course, that’s a very hard design problem: Haskell is 26 years old and still not perfect, although it’s one of the best mainstream languages out there.

Also, that slide deck fails to emphasize that it is very difficult to find Haskell developers in many parts of the world.

Fair point. I think that if you’re going to build a serious Haskell team, you will have to train some of your talent in-house. The good news is that you’ll probably have more loyalty. Once they get deep into Haskell, they’re not going to want to go back to Java. So you’ll get a long-term benefit in terms of retention.

It’s unfair, but at my level of seniority and ability, Java engineers make 2x as much as people using better languages. Why? Because Java engineers can create bidding wars for their talent every two years, and the ones who are any good (not VisitorFactory ScrumDrones who can’t code outside of an IDE, but genuinely good engineers who actually understand Java rather than just being able to code in it) bid their comp up into the 300k+ range. They go out to the Valley and play Google, Amazon, and Facebook against each other and walk away with 7-figure stock packages. On the other hand, you can get a great Haskell engineer for 1.2-1.4 times a regular salary. This will change, but right now, Haskell is still a small niche job market where setting up bidding wars every 2 years isn’t really possible unless you want to move your family across the country each time (and, besides, word will get around). For the next 5 years at least, a Haskell engineer is an enormous bargain– even if you have to train up the talent in-house.

Learning haskell syntax is NOT a problem. There is so little to learn its really a non issue. Learning the concepts behind that tiny amount of syntax however, now that is the problem that people from C like languages will hate. That hate is normally masked by “it looks different”. Well yeah, it embodies a different view of computation as a concept.

Expecting Japanese to kowtow to always use romanji because katakana and hiragana and kanji is “too foreign” is the equivalent to your argument in my view. Its utterly the entire point and why the argument is effectively baseless and nothing more than a thought terminating cliche.

That is what scares me about the language. You might say that one doesn’t need to know all of that to write in the language, but that is a red herring. For example, one doesn’t need to know half of C++ to write it, but one does need to know the whole language in order to read and understand other people’s code. The same is true of Haskell.

On the other hand, languages that use Lisp-based syntax truly can claim to have clean, beautiful, elegant syntax. No other style of programming comes close to combining simplicity and power.

I know, and I find myself putting necessary parens in Haskell and F# enough that a few extra required parens wouldn’t really be that annoying, and then tools like Paredit and Vim would get to shine as much as they do in Clojure.

I did but it causes inconvenience to other developers. Ideally I would like to flip flop between begin / end and parens within the editor. Paren indenting is not easy as some macros can be block macros as well :(

I’m not sure how I am downplaying the complexity. The syntax is simple. The concepts tend to be hard. The typeclassopedia I’ll be honest I don’t even fully know. Doesn’t mean I’m not able to use Haskell to accomplish goals however.

I consider that to be an example of the complexity of Haskell. It isn’t however endemic to Haskell, just a byproduct.

I will disagree with the lisp syntax being “clean, beautiful, elegant” however. Function application with spaces isn’t a hugely hard thing to grasp.

The typeclassopedia I’ll be honest I don’t even fully know. Doesn’t mean I’m not able to use Haskell to accomplish goals however.

This is a really interesting point. I know exactly what you’re saying. Haskell isn’t a language where you can get the comfort of knowing “everything” about it in 6 months– or even 6 years. You can get productive almost as quickly as in any other language, but that comfort of having mastered “the whole thing” probably never comes. I consider that a plus, because I enjoy learning new things, but I can see that it would make some people uncomfortable.

My biggest problem with Haskell ‘syntax’ (more often than not it comes from libraries like lens, not Haskell itself) is understanding operator precedence. I’ve used Haskell on a few projects now and have largely given up on trying to understand it. At this point I’m just pressing forward til I develop an intuition for it.