Lambda the Ultimate

I didn't ask them to give a list, but Java, C (also C++), Javascript, and Python were mentioned. I know they are familiar with some other languages as well.

My point was that I am most effective in evangelizing when I figure out what is taking people forever to accomplish. If they don't need to learn a new language to accomplish those things, then I don't even bother mentioning something like Haskell, Maude, Clojure or Scala.

Maybe their problem is best solved using GNU command line utilities for the first time.

But when they have a problem that fundamentally demonstrates they're either using the wrong tool or that the tool has predisposed them to solving problems a certain way, THEN I show them a new language to learn. And I make the case that this saves them time in all phases of software development. Petre's 1989 Ph.D. thesis on productivity empiricially shows that the thing that radically improves technical acuity more than anything else is awareness of problem solving styles. Factors such as years of experience actually have almost no impact at all.

And I learn something from this, too. I learn what even highly successful programmers can struggle with. Today, it might be concurrent programming with threads; so you show them something like Erlang, maybe even explain Erlang's internals a bit. Or you show Clojure. It depends on what the problem they're taking forever to solve is. If you can then solve that problem in the mysterious language an order of magnitude faster than they did, then you get eyes turning.

Most successful people are not like me. More importantly, I am smart enough to recognize I am not representative of the average person. When I give advice, I try to frame it in some context, such as the 40 year old dad with two kids and a wife with another kid on the way. I am years away from stepping into those shoes, but I understand the last thing on that person's mind (when they are highly successful) is to potentially waste time learning Haskell. And that is how it is seen without fruitful justification: a waste of time, when you can be spending it on other life priorities.

Good points. Me? I am not selling anything, and I wasn't giving advice, just chatting. One thing though: I think many people are curious and interested in hearing and learning about things, whether they have a practical need for them or not. Not everyone, for sure, but the ones I hang with...

Factors such as years of experience actually have almost no impact at all.

Only someone without years of experience could believe that. ;-)

Aptitude, interest and experience are all different things, and they each contribute something that the others alone don't.

And that is how it is seen without fruitful justification: a waste of time, when you can be spending it on other life priorities.

I think that is a titch glib. It is not just life commitments that can promote a more conservative approach to new ideas, but also the experience of seeing an endless parade of "awesome new" technical ideas and panaceas come and go. Healthy cynicism about "easy" ways to solve problems is in order.

Wearing my programmer and PLT geek hat, I think that one of the best ways to improve your programming skill is to learn new PLs, especially new paradigms.

Wearing my manager and project manager hat, I know that incrementally improving your programming skill isn't always the most important consideration.

So choosing not to learn Haskell may not be a question of "life distractions", but a sensible prioritization of technical effort within a professional context.

Generally speaking, people refer to Barry Boehm's study that says programmers can differ in productivity by 10 to 30 times.

Can we simply find a correlation between experience and such productivity? No, we cannot.

Expert programmers, the ones most productive, conciously change the programming paradigm they are working in, as a way to gain a new perspective on the problem. Expert programmers tend to have a habit of deliberately acquiring knowledge of new paradigms. When they are stuck solving a problem in one paradigm, they prototype a design using another one. As far as I'm aware, the statistical correlation between this and productivity is one of the strongest indicators of a high-level programming master; level of education, such as C.S. Ph.D. degree, are not anywhere near as instructive, because you can get a Ph.D. but still have no clue what will efficiently map to common hardware.

Now, if by "experience" you mean somebody who has written programs in assembly language, written compilers, written embedded systems, written GUI systems, then yes, you're right. But you are also restating what I said, less strongly: The reason their experience is so valuable is because they've been exposed to different problem solving styles. This was Marian Petre's point. It's also why when Microsoft posts job postings for an "architect", they often seek candidates with many years of experience in a broad depth of programming situations. Compare this with the "experience" accolade given to the Chandler developers in Dreaming in Code; if you scrutinized their achievements, they actually had fairly narrow experiences. Rosenburg even talks about how the developers on the project were uncomfortable with new styles, and spends much of the book talking about how the programmers were engaged in effectively political battles rather than cooperative learning.

Z-bo: Rosenburg even talks about how the developers on the project were uncomfortable with new styles, and spends much of the book talking about how the programmers were engaged in effectively political battles rather than cooperative learning.

Rosenburg didn't quote my emails or attribute me in any way, but I told him what happened was mostly politics. I was only there at the beginning, though. Chandler's incentive structure caused a negative sum game; this is worse than a zero sum game. It was my first big political experience, where some folks revealed none of their intentions in what they said, and only spoke for effect as game plays. (That's enough talk about Chandler; now I'll say something useful.)

My current work environment (3 plus years now) is partly political, partly technical. My technical efforts are strongly limited by what's politically acceptable. Tech parts of what I do are trivial, yet they confuse others by complexity. That's the political part: aiming for the least complex thing, hoping it can be grasped in a few seconds by folks who will not read. (They can read, they just won't.)

Productivity in quantity is not appreciated. Any effort taking longer than a short attention span to review is considered impenetrable. Thus brevity is highly prized. If you can write more than 10 times as much code as others, this is viewed as a problem, not an asset. It does make it easier to plan to throw N away, since writing N more isn't hard.

There's a mild correlation between experience and productivity, but I think it only works like this: productive folks get more so with experience. Sometimes a lot more so, until vetting results is the limiting factor. Writing persuasive tests can gate acceptance.

I think it's a good idea for folks to learn a new language, to gain insights. But it won't help you persuade others why your next tech approach is good. Unless you can leverage a few magic phrases with high prestige. Everyone wants to scale with more cores without locking, so if a language does that, you can transfer knowledge to other contexts.

not really... by the time the masses learn the state of the art, there is a new state of the art. I've been through a couple of these cycles already, and I ain't that old...

Why is so much of PLT all about making the Next Big Crazy Breakthrough language and so little about incremental refinement? We don't hear many stories like "These crazy folks wrote their killer app in AWK! Can you believe it? But then they hired a PLT person and their second generation product was in an incrementally but significantly improved version of AWK, saving them 20% of the time spent on maintenance bug fixing." I understand the economic reasons why not but I do wonder if the market is genuinely efficient here: is that a property of the nature of PLs or of PLTists? Why can't I get an NSF grant to make, say, an improved AWK (other than my lack of credentials and academic standing, of course).

Said differently, are we really talking about "the state of the art" or are we talking about "the state of the field"?

Big issues, to be sure. My tongue in cheek claim was descriptive, not normative. But since you ask: My take is that we are still so far from knowing how best to build software, that there is no danger of innovation stopping anytime soon.

But I love the "here is how we did it in AWK" examples as much as the next PL hacker. Just go through the archives... (and if you have more examples do share!)