Pattern languages are new to me but I'd guess that I know more about programming languages in practice than 97% of programmers, and 100.0% of the people (by definition) who think VisitorSingletonFactory classes are a good idea. So if I'm getting fundamentals wrong in that part of the discussion, and I could well be, then I think there are precious few people getting this stuff right.

Your competence as a programmer was not questioned, Michael, and was not even remotely a consideration. Have a beautiful day!

Sorry if I seemed aggressive and snarky. OOP gets my blood boiling. The disgraceful state of most software architecture is a hot topic for me, having seen a couple of companies fail on account of code quality issues.

That's not OOP, its the designers and coders. The "problem" with being the mainstream programming paradigm is that the bell curve of talent is fully stocked from high to low ends.

The marketplace of managers looking for: a) cheap labor b) well-understood technology c) ability to fallback to expert knowledge

grew up with object-oriented paradigms.

Since OOP frameworks removed many low-level coding tasks, the cost of entrance into the labor market allowed the labor pool to be flooded with developers, it helped that demand was so high and investors so hungry that proof-of-concepts often became products.

What came out of all this is that OOP matured, but OOA and OOD didn't keep pace as market demanded disciplines. What you see today is many OO systems that were not analyzed or designed by architects who were good analysts and designers, but who understood OOP and had access to a pattern-book.

But, taking a page from category theory, we could abstract OO from OOP, OOA and OOD, and should be able to easily see that the same could eventually apply to FP, FA and FD should the bell-curve of talent fill out due to market demand.

The nice thing about a language like Haskell, then, is that you have to be really smart to use it, reducing the market for low end programmers. Actually, many companies put Haskell (or even Scala) down as a requirement just to filter out the low end programmers, they have no strong intention of actually using those languages.

OO is accessible because it is much more naturalistic than FP, being based on natural metaphors (objects) and natural language concepts (subject verb) that make many computer scientists cringe (was it Dijkstra who was against anthropomorphic metaphors?). FP is much more based on math and logic, conveying certain benefits but requiring a change from the way we are normally wired; I've been in a room full of the best of the FP guys before and I could have sworn I was on a different planet.

FP is a reliable tool in moderation. But when I'm designing a text editor, object thinking is definitely preferable.

>The nice thing about a language like Haskell, then, is that you have to be really smart to use it

I'm living proof that you are mistaken.

>Actually, many companies put Haskell (or even Scala) down as a requirement just to filter out the low end programmers

If by "many" you mean "a couple", then it depends what you mean by "low end programmers". Asking for haskell is decent at weeding out people who have no interest in learning new things and improving themselves. It isn't particularly useful for filtering out people who aren't "really smart".

>OO is accessible because it is much more naturalistic than FP

It is interesting that you pre-suppose that is the case. My experience with teaching people programming with no prior experience is that OOP is not accessible at all, and FP comes quite naturally.

Asking for Haskell is actually good for weeding out most American programmers, but whatever. The point is that you'll get a better programmer if they know lots of programming language paradigms. But I wouldn't for the life of me take on as an employee someone who knows Haskell but not an OOPL (like C#, Java, or at least C++), that would indicate severe ideological bias on their part.

I'm using naturalistic here as a real term related to natural language and humanistic fuzzy thinking that we seem to be born with as opposed to the logical mathematical thinking that we must learn at school. The idea that we think (or at least most of us) in terms of objects rather than formulas biases us towards object thinking when designing systems.

Its sort of preverse, but I agree with you: its easier to teach FP to people with no programming experience, since you can focus on simple stateless computations. Without objects, you can't even broach the harder topics that teachers carelessly throw into 101 courses. But even if you are using the SICP, you'll see object thinking introduced in Chapter 3.

But now we seem to be arguing about languages, of course you can have objects in an FPL and you can have lambdas on an OOPL. The best programmers will be able to apply both of course when applicable, and won't be ideologically biased. The not so great programmers are probably better off with OOP since that's what they'll need for their jobs, though a dose of FP can help them become better programmers.

>But I wouldn't for the life of me take on as an employee someone who knows Haskell but not an OOPL (like C#, Java, or at least C++), that would indicate severe ideological bias on their part.

Ironically, it actually indicates a severe ideological bias on your part, not theirs.

The rest of your post seems like it is entirely platitudes intended to say nothing. No, people don't think in terms of objects, that is why the leaky metaphor used to teach OOP traditionally causes so much confusion, and makes OOP harder to learn than FP. Thinking in terms of FP is not thinking in terms of "formulas", and it appears you are basing all the rest of your assumptions on top of that one faulty assumption. People intuitively understand "I make a thing that transforms other things" much easier than they understand "I make my things know how to transform themselves, or maybe other things, or maybe both, but sometimes neither and I make different things to do the transforming instead, but those things are wrapped inside an "object" that doesn't represent anything for no discernable reason".

I'm not sure I understand, do you mean, that someone only knows an FPL and not an OOPL means they are more well rounded than someone who has experience with both. And I didn't even mean they have to do most of their programming in an OOPL. For what I do, I cannot afford to work with a PhD student who does not know more than one programming paradigm!

I definitely meant to say something, I think the platitude remark is uncalled for. People don't talk in terms of transformations, they talk in terms of instructions, recipes, responsibilities, parts and pieces, and lots of encapsulated processes. Again, check out chapter 3 of the SCIP, which you already probably know about if you are teaching programming from an FP perspective.

>do you mean, that someone only knows an FPL and not an OOPL means they are more well rounded than someone who has experience with both.

No? How would you get to that interpretation when I didn't even say anything about this theoretical person, but rather about you?

>For what I do, I cannot afford to work with a PhD student who does not know more than one programming paradigm!

Unless you are doing programming language research, yes you can. Almost everyone already does, it is just that the only paradigm in question is imperative, rather than functional. That's not a significant barrier for the vast majority of roles, especially not PhD students.

>People don't talk in terms of transformations, they talk in terms of instructions,

That's the same thing. People think "beat the egg". Beating is a transformation, egg is a thing. People do not think "send the egg a message requesting it to change itself to the beaten state", which is why the OOP metaphor fails so badly. Functional programming directly maps to the normal way people think, as does traditional imperative programming. OOP does not.

> Unless you are doing programming language research, yes you can.

Yes, I do, but no, its still a problem. With my colleagues, they are even more strict about OOP experience. I'm sort of unusual in that I appreciate FP experience, or I actually demand it, as part of finding well rounded candidates (very difficult in China, to be sure).

You don't "transform" the egg chemically from an unbeaten to a beaten state. Instead, you beat it, and that well-known transformation happens as a side effect. Also, after you've beaten the egg, you don't have an unbeaten egg to reuse elsewhere in another operation. Finally, someone has to beat the egg, either yourself or your assistant, or a machine designed specifically for beating eggs. In this way, FP does not map to the way normal people think.

I'm now unable to tell if your post is serious or satire. The strawmen are so glaring and absurd that I have a hard time believing you are seriously attempting to use them to make an argument. Chemistry, seriously?

Totally serious. You picked beating, which is THE classic side effect operation, and you had no idea what was going on? If so, just refresh your memory on what beating the egg actually does (spoiler: people don't beat eggs because they are angry at them):

http://en.wikipedia.org/wiki/Mixture

Your argument doesn't become strong just because you accuse me of logical fallacies, and actually, that's all you are really doing here. Good day.

Well that is genuinely impressive then. Please explain to me how the fact that no chemical reaction occurs when beating an egg is in any way relevant, or even related to the discussion, or anything I said. I didn't say beating an egg caused a chemical reaction, and at no point would anyone who has even the loosest grip on reality consider that to be relevant at all.

Had you just suggested that beating eggs is a side effect, and thus not purely functional you would have gotten a response. But when you go so far off the rails that the only reasonable explanations are that you are trolling or insane you shouldn't expect people to take you seriously enough to bother responding.

Yes, beating an egg changes the state of the egg from unbeaten to beaten. Yes, this is a difference, however it is not a difficult to understand difference. I explain it all the time, that's why I used it as an example. "With functional programming, instead of the egg_beater function changing the egg, it takes in the unbeaten egg, and returns to you a beaten egg. If you gave the unbeaten egg a name, you can still use it.". That is easy to understand, which is why people respond with "oh, ok" instead of confusion. This concept has to be understood when teaching OOP too, as generally methods that just change state return "this" so you can chain method calls: egg->beat()->fry(). So proposing that it is some unfathomable difficulty with learning FP is ridiculous.