1. That was interesting, thanks

2. If you eel like functional languages are more powerful than OOP or procedural languages and you're much less comfortable in them than in C or Java, you should do a major project in one, or switch your scripting language. After all, you're still in college, you have fucking up time and capability. Haskell for the Summer of Code, or Jane Street Ocaml?

3. Never, ever pre-emptively apologise. It is a signal of weakness and lack of confidence and will cause people to give you abuse and disrespect you who would not have done so if you hadn't done it.

The problems you had or still have with ML and Haskell are probably mostly about pure syntax. For beginners, syntax matters a lot. Over time, we get over it, and learn to see the underlying structure of the code.

About the deeper problem of "thinking in OOP", I wrote a small tutorial[1] about the first step: avoiding mutable state where you can help it. The second step is to remove loops (even the recursive loops as well). Instead, use `map` and `filter` (the bulk of list comprehension) where you can. The final step is to generalize this approach by writing your own "higher order" functions to capture common patterns.

[1]: http://www.loup-vaillant.fr/tutorials/avoid-assignment

It takes weeks to retrain one's mind to think in a new paradigm. It took me 8 weeks (years ago) to 'get' OOP, coding every day. Maybe I'm slow, but something on that order is expected.

To change means painful, unproductive days. I went home sweating every day(!)

So some of the emotion regarding choise of paradigm is of course personal - we all want to stay where we are comfortable. Then we rationalize why that is best.

I believe the CMU profs have taken a different tack - how to teach folks relatively new (< 20 years?) to computers. They may choose any paradigm that works, and they seem to be perfectly trained to make that decision well.

As for job opportunities for their graduates, CMU has traditionally had zero problem there. So we shouldn't cry any alligator tears for them. They will learn 'practical' OOP etc as needed at their first job.

If you are comfortable with FP at a low level then jump in and give it a try. At a high level the two approaches tend to not look that different. Why, because the end goal is the same: clean interfaces to logically organized components. It shouldn't be too surprising that a logical, and consistent interface to a Balanced binary tree or bank account looks very similar once you get past the implementation details.

> I'd rate my abilities in C and Java as probably a 7/10.

To go off on a tangent here, this is something that's been bothering me for a while. These one-to-ten scales are seductive, but they do a very poor job of representing people's actual skills.

The problem, for me, is the 10. Where is 10? If you're at 7/10, you're 70% of the way to whatever 10 is. But how do you know what 10 is? If you're a novice C programmer, you really have no idea. You know about some things you can't do, but you don't really know what you don't know.

Skill differences are really hard to measure. If you compare me with, I don't know, Rob Pike, Fabrice Bellard, Ian Lance Taylor, Landon Curt Noll, P.J. Plauger, Peter Deutsch, or Dan J. Bernstein, or somebody like that — well, if we're working on a project that I can reasonably do myself, they might get it done in ⅔ of the time it would take me. Or maybe ½. So maybe I'm a 7/10? Or 5/10?

But suppose the project at hand was something of the difficulty of otcc or gold or mawk? Those are probably things I could write, given enough time. But those guys could probably do it ten times as fast as I could. Does that mean I'm at 1/10? (Also, their version would work better than mine.)

The trouble with rating my skills at 1/10 is that it suggests that my C skills are close to the minimum. But I'm probably as much better than your average C-speaking CS undergrad as Peter Deutsch is better than me.

We really want some kind of exponential scale, like the Richter scale for earthquakes (or its modern replacement, the moment magnitude scale), or dBa for sound pressure levels. There's no actual ceiling on dBa or earthquake magnitude, but in practice, the numbers stay within a usable range, because of physical limits.

So maybe on this exponential scale, the CS undergrad guy is a 10, and I'm a 12, and Peter Deutsch is a 14. Or maybe a 16. And this comes to the other problem: how do you judge people above you? You can't, really. If they complain about your variable name choice when you send them a patch, and you can't tell that their suggestion is a real improvement, well, is that because something is really obvious to them that I'm missing? Or is it just an idiosyncrasy? I can't tell until I'm at their level.

To some extent, though, I can judge objective achievements. GhostScript has held its own against a much better-funded competitor, managed by adept programmers, for decades. Yahoo Groups still runs on qmail, as do thousands of other mail sites, and still nobody's found a practically exploitable bug in qmail. ffmpeg and tcc are impressive achievements. And so on.

But how can I quantify whether the skill required to create GhostScript or to create ffmpeg was greater? Both are probably beyond my own ability. So I can't even tell whether Deutsch beats Bellard or vice versa. There's no batting average to put on our Genius Hacker Trading Cards. So I can't tell whether Deutsch is at 14, or 16, or 18 — whether he's a hundred, or ten thousand, or a million times better than I am.

But if he's at 10/10, I'm sure as fuck not 70% of the way there.

>And this comes to the other problem: how do you judge people above you? You can't, really.

Relevant Wikipedia article: The Dunning-Kruger Effect http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect