So far in my limited experience the rule still holds: If you drop a Haskell programmer into Blub they may well try to write Haskell-flavored Blub for a while. I've seen it happen.

I think you're misapprehending the problem. It's not that Haskell programmers can't understand the structure of Blub. Gods, no. It's that it takes time and tolerance to be able to immerse oneself in the Blub culture. Blub has its way of doing things, much of which is more accidental than logical, and alas, much of what passes for colloquial Blub is probably stuff that Haskell was specifically designed to avoid like the plague. There's an initial tendency to either run around waving one's arms like Jeremiah, trying to convert the Blub programmers to the side of Light, or to take to drink in despair at the sheer Rabelaisian sloppiness of the Blub universe. To work through this takes time, and possibly therapy.

It's like anthropology. It's one thing to be a linguist and work your way through library books about the syntactic structure of a family of languages from New Guinea, but it's another thing to be airdropped into New Guinea itself, insinuate yourself into a local village, pray you don't die of any tropical diseases, learn which compliments in your native language are actually mortal insults in your new host culture, try to laugh along with the natives when they convince you to lean against a tree filled with stinging ants, and simulate exquisite happiness when your host offers up a delicious sample of the local insects. It's a cultural problem. Not everyone is up for that experience. One may have to work through a certain amount of shock.

I agree it's largely culture, but I think there are some technical issues that go with the culture as well (which are sometimes the reason for some cultural elements). Even someone who solidly understands OOP, for example, may not know all the many specific gotchas and possible pain points of C++ if they haven't written a lot of it, and some of the cultural conventions common in C++-land were developed because of awareness of those gotchas, and in an attempt to minimize them. C++ is probably a limit case because it's so large and has so many interacting features that there's a lot of accidental complexity, so just knowing the PLs concepts only takes you so far, but I think many languages have some similar things.

Heck, even ye olde C has a whole litany of detailed spec edge cases you need to know about if you want to understand the finer points and avoid some nasty pitfalls (and an even bigger list if you go to C+POSIX).

Oh, I agree, and we're actually talking about the same thing. We're just defining the word culture with different scopes. My scope was, approximately, "anything about C++ that you really need to know to write idiomatic C++ code and interact productively with your C++ coworkers and community, but which you didn't learn from that Introduction to C++ for Lisp Nerds book that you skimmed last weekend."

Clearly not a hard-and-fast definition. The more "proper" scope of the word culture is, of course, ultimately a giant philosophical issue which I intend to blithely handwave away. ;)

(I suppose one could try to argue that all of C++ is a cultural artifact, and C and assembly for that matter, but sooner or later you'll reach the Turing machine, which if you chip away at it you'll soon discover is just the tip of an iceberg which consists of all of mathematics, and then folks like Plato will turn up on the battlefield looking for a fight and holy cow, look at the time, gotta run.)

I'd say the APL experience alone also requires a significant bit of masochism. And while you'll be able to relate to things you've seen before, concepts alone are not sufficient to be proficient in the language, as I noted:

> concepts and techniques he's never seen so far and building up new instincts

"techniques" and "instincts" have to do with the language's idioms, tools and ecosystems. The tools (libraries) and part of the ecosystem may be similar to ones you knew, but you'll still need to learn the new ones. The idioms may very well be brand new.

To use a real-world example, while they're fundamentally based on the same concepts (class-based OO, dynamic single dispatch) Python is not Java [http://dirtsimple.org/2004/12/python-is-not-java.html]. And acquiring Python "instincts" after a significant time of Java is not easy. It's not hard either, but it's not the "5 days to complete proficiency" necro asserts. And those are ultimately very similar languages.