Lambda the Ultimate

Given the low response rate, I wonder if there was any self-selection bias.

"Are they still trying to sell us functional programming?" and the mail went to the trash bin.

Guess Daan just got fed up playing Spacewars3d. [ Now that's snarky, I actually liked the approach taken with revisions. ]

Low response rates are attrition bias.

Self-selection bias is only one form of selection bias.

One interesting thing would be to pose a similar study elsewhere but change the wording of the questions. Sometimes the way a survey is bundled can affect participant attrition.

The tech report also doesn't explain the methodology for how the survey was disbursed, and so it could be subject to sampling bias, but I will suspend disbelief on that and assume the sample was drawn well (it says random sampling, but doesn't explain how they established the population of "Microsoft programmers").

Ehud has a dry and ironic sense of humor. :)

I don't get it. I agree with Barry, it is a throwaway comment that doesn't add anything. Should the authors be offended? Should the programmers at Microsoft be offended?

Instead of placing the snarky remark, I now have to imagine what Ehud meant. And I have a vivid imagination. ;) Best leave it.

I've read the report and I agree that it's almost asking for a specific kind of remark. What I don't get is why anyone should be offended by a remark not even made but only (redundantly because it's obvious) hinted at? Do you think the authors of the report or the programmers at Microsoft that participated have such low self-esteem that they might take offense? I guess the authors themselves had some "fun" compiling the responses because some of them are really hilarious. Not everything in life is dead serious.

To get back on topic: I find it remarkable that most responses agree on the point that functional programming is always side-effect free. And only one response mentions monads (without going into details) while several mention closures/lambda expressionsin C# and higher-order functions. The abundance of .NET, C#, and LINQ mentions suggests that functional programming concepts are really going mainstream. It would be fascinating to see a more representative version of this survey.

They tried to do a quantitative assessment of the use and opinions about functional programming at MS. Since the response rate was too low, they turned it into a qualitative report just listing the few responses.

To me personally. The whole report reads as: "Uuuh, we don't know (mostly), and we're not sure we should care."

It just shows that most (some?) developers probably got some form of FP while at college, and mostly forgot about it. Or misunderstood what they were being taught.

I guess I have the advantage of having been a CS college teacher myself. The report is exactly what I would expect. So, to be honest, there's just no real news here. (At least, for me.)

[ My own experience, guesstimated: Out of 30 who are interested in taking a course in a college for vocational training, 20 are too much challenged and maybe get to the point where they can read solutions of others, 9 will be able to produce programs but just see it as a strange exercise in programming and will like Java/C#/... more since it is so much more easy to program, 1 will get it. ]

I think Thomas's remarks fit well.

The tech report only shows what it shows. Quoting Thomas above:

I find it remarkable that most responses agree on the point that functional programming is always side-effect free. And only one response mentions monads (without going into details) while several mention closures/lambda expressionsin C# and higher-order functions. The abundance of .NET, C#, and LINQ mentions suggests that functional programming concepts are really going mainstream. It would be fascinating to see a more representative version of this survey.

I also think the survey indicates what Microsoft as a culture needs to work on if they want their programmers properly trained and using their tools effectively. Even the few answers provided demonstrate gaps in knowledge. Alternatively, Gates can write a big fat check to a bunch of universities and simply go the route of training the next generation of programmers around functional programming. The older programmers who don't get it will simply never be re-trained and will have to do it themselves if they want to do it at all.

I don't agree. (Although I don't go as far as some of my former colleagues who think that teaching recursion has little merit for those who vocationally train to become programmers.)

The people who grok FP are the same people who grok algebra, or difficult math like Hilbert spaces, and subsequently go for a PhD and don't understand why not everybody programs functionally while at the same time (often) not understanding that most problems in SE are not solved by a better (functional) programming language.

Moreover, functional programming certainly is no silver bullet. There are tons of programs better written in C than in Haskell.

What you can do is give the average programmer better tools for dealing with those things he/she finds hard. Better idioms for concurrency or dealing with state for your average Joe will do a lot more to the field than pestering him with manners of programming which are just not his potee.

I personally don't care or think that FP will become mainstream. At the same time, I think that functional programming will always have niche applications, and you can do a lot to lower the barrier. (Which is what my hi-language.org experiment is all about.)

People can acquire new skills.

Learn to Draw: Drawing on the Right Side of the Brain, the famous book by Betty Edwards, one of Alan Kay's collaborators¹, tries to demonstrate this (and is considered effective in doing so).

[1] She is also the person who drew the Cheshire cat image of Alan for his 70th birthday

I'm a great deal more optimistic on this subject.

Programmers tend to 'grok' whatever tools they use. Programmers easily see a need to 'control' side-effects when they are performing database queries, distributing code to a remote browser, injecting CUDA, working with parallelism and concurrency, etc.. They understand a need for idempotence once they're living inside the publish-subscribe architecture. Intuition and concern are provided by experience. And developers who have used 'self-discipline' for a while, and mucked up in subtle ways that bite them later, start to appreciate tools and languages that help maintain that discipline.

The difference between people who 'grok FP and algebra and difficult math like Hilber spaces' and those who do not is one of motivation, not ability. Joe Average programmer is quite clever, but a little lazy when it comes to self-education.

Explain monads after a developer has been using them for a while, not before they start. Before they start, a 'monad' is foreign and therefore scary... asking the programmer to use 'monads' is like asking them to feed a lion. This is only natural - humans have been wired to fear the unknown, and we are not very good at abstract thinking. You can't learn something until you already almost know it.

RE: 'better written in C' - Haskell makes a very nice imperative programming language... albeit a little on the verbose side for manipulating references, but you don't need to do that especially often. Haskell as an imperative language has cheap threads, atomic references, first-class procedures, excellent polymorphism (via typeclasses and type families), good integration with the C ABI (at least in the Haskell calling C direction). If you need it (e.g. to extend the language with a scheduler and future values) you even have global state and unsafe IO. The ability to 'isolate' certain code, such as creating an 'OpenGL' monad that only accepts OpenGL operations, is quite powerful for enforcing discipline in imperative programs.

I believe functional programming will continue to grow more important - as a 'layer' to support concurrency, confinement, mobility, language glue and DSL-based discipline. However, I don't believe that 'imperative' is a very good choice for the lower layer.

those who do not is one of motivation, not ability

I used to think so to. But I was somewhat spoiled by my own education where I found everything, especially around programming, mostly trivial. It takes years to understand the mindset of those in (or those who are better of in) vocational training.

Some people lay bricks, some people become physicists. Do you think you can train everyone who lays bricks to become physicists?

For a substantial part of students in vocational training, Javascript is something completely different than C#, and they already have problems understanding that a course in programming learns them abstract knowledge instead of a particular language.

Yes, you can train students to use formalisms. There's nothing very interesting or hard about the lambda calculus, for instance. But they'll go into industry, forget what you thought them, and bicker why they didn't learn decent skills like Javascript and Adobe Photoshop.

If a person is a bricklayer at heart, you might want to learn him physics, that's knowledge which is applicable everywhere, right? It's just not true, you end up with a very unhappy bricklayer who doesn't know how to apply physics.

In vocational training, as a teacher, you always try both. I.e., learn them to lay bricks and show the physics behind it. But most of them will not grasp the latter part, and that's just fine.

[ Note that I teached vocational training, i.e., up to bachelor level, sometimes beyond. This is different, in Europe, from classic universities, who usually teach up to master level sometimes only to bachelor level. For those who aspire to become masters, I agree, you should start with algebra and formalisms as early in the program as possible. ]

Talents are not equal. Not everyone is meant to be a racecar driver, but the vast majority of humans can learn to drive cars. Not everyone is meant to be a physicist, but the vast majority of humans can learn physics.

But talent is not a great predictor of success. Persistence is. And persistence requires motivation.

Classic schooling is a setting with limited time, limited resources, and a lot of ground to cover. And so talent makes a great difference to the student. Further, we only advance the people who perform well in this setting. The others are marked down, blocked, discouraged emotionally and bureaucratically from advancing. The school setting magnifies the benefits of talent far beyond anything you'll see in a business setting (where politics, resources, and a good idea are much more important).

We could probably change our school system to favor creativity, politics, and persistence, but that isn't a subject that motivates me. ;-)

People who favor concrete thinking (or 'lay bricks' as you say) are often well motivated to to understand patterns and apply theories that will directly help them in their jobs. They simply learn the theories after applying them. As Mr. Strathmann notes below, it's all about making the theory concrete before explaining it, giving the student the confidence and intuition before they try it on paper. This works pretty darn well for the abstract or theoretical thinkers, too, which is why we have lab courses.

There is a significant difference between applying a theory and advancing it. To efficiently advance a theory, you usually need the ability need to try it on paper first, often long before you find it intuitive, and you need to be motivated to do so repeatedly. This means that concrete thinkers aren't likely to become physicists even though they can learn and use physics.

I recently spoke with an engineer about how he went about building his WPF and Silverlight applications, and from his descriptions I was able to pick apart his design and describe to him how his program was structured. After he agreed I understood his code structure, I then pointed out several ways he could improve it further, and that he had not taken his ideas to their logical conclusion, but could.

On the one hand, he was frustrated I had picked apart something he and his coworkers worked hard on. On the other, he was exhilarated to know that his intuition was right and the thought that he could learn how to improve his skills in measurable ways, that he could measure himself improving as an engineer and being better at defending his ideas.

All I really did was explain a couple formal process models and object capability security to him. He handled the rest from there.

Re: comment-62989: Not everyone is meant to be a physicist, but the vast majority of humans can learn physics.

Unless you majored in la littérature française. In What You Can't Say, Paul Graham opined thusly:

… scientists are simply smarter; most physicists could, if necessary, make it through a PhD program in French literature, but few professors of French literature could make it through a PhD program in physics.

Mega ditto on “talent vs. persistence.” Talent is a liability.

On a completely unrelated topic, I can't believe someone would unsubscribe over a remark that doesn't even contain any pejorative verbs.

I found the unsubscribe comment odd too. LtU was never about impartial journalism, which seems to be what the poster found offensive about Ehud's comment. The readers and editors here often have strong opinions, and the ensuing debates are what make LtU so informative.

I suppose LtU might turn away people who are overly sensitive on such issues. Oh well, you can't please everyone.

Since I find it unlikely that my strongly held opinions actually came through, I find it even odder...

Our dear administrator / editor made a spelling error (srongly) in a home-page topic. Surely, he should be held to higher standards than that!

\unsubscribe

Thanks. Fixed.

Your Paul Graham's quote looked like utter garbage to me, so I decided to read it in context. Actually it is described as a pure speculation, not an actual claim of the author, like you make it look.

A good scientist, in other words, does not merely ignore conventional wisdom, but makes a special effort to break it. Scientists go looking for trouble. This should be the m.o. of any scholar, but scientists seem much more willing to look under rocks.

Why? It could be that the scientists are simply smarter; most physicists could, if necessary, make it through a PhD program in French literature, but few professors of French literature could make it through a PhD program in physics. Or it could be because it's clearer in the sciences whether theories are true or false, and this makes scientists bolder.

On the other hand, even in context it looks like the author may actually mean what is said in that quote; the example looks so natural that I'm confident some people hold it to be the truth.
I don't think any science PhD student could excel at litterature --- though I suppose some certainly would. It probably tells more about the author's ego (that he considers this affirmation as plausible).

...one programmer* who had undergraduate degrees in Classical Greek and Physics (and then also some other major), and was probably capable of doing a Ph.D. in any of them if he cared.

* and if you're a Java programmer reading this and ever wondered why Elliotte would use programming examples that threw in a gratuitous reference to Greek letters in Unicode, now you know the story.

Re: comment-62995: Your Paul Graham's quote looked like utter garbage to me…

Take solace in knowing that you're not the only one and that there are more quotes where that one came from. To wit:

The fatuousness of the parallel [between hackers and painters] becomes obvious if you think for five seconds about what computer programmers and painters actually do.

• Computer programmers cause a machine to perform a sequence of transformations on electronically stored data.
• Painters apply colored goo to cloth using animal hairs tied to a stick.

That said, we've drifted pretty far off-topic with this subthread. (There is a relevant topic buried in here that I'll save for another day.)

No they don't. There's a substantial portion which will never learn, or see the use of, theory even after practice.

To make it concrete with a few examples I'll hope you'll take as experience from the field.

Wadler once proposed the "Expression Problem" as a fundamental problem in a setting of FP. In another thread on this forum, his problem is taken over to the Clojure setting and generalized as "sometimes you want to add functionality but can't". A large amount of programmers will never even experience the expression problem as a problem as long as they can code around it. In their mindset, there just isn't a problem, and it certainly doesn't make Clojure a better language than Java. You think you are "Solving a fundamental problem." To them "You are seeing things which are just not there."

When designing protocols, you would think that learning students the basics of process algebra would help them implement protocols in C. For a substantial portion of students the mental gap between both is just too large. Even if you would show them after a failed attempt at implementing a protocol where the mistake is in a formalized notion of it in process algebra, they'll just see that as extra overhead to solving the problem in C. You think you help them by "Making the problem precise." To them "You are being difficult" since there is a concrete explanation in term of sockets and C too.

You might want to teach experienced programmers to learn COQ to advance their abstract thinking. To a lot of them, they'll never understand how proving certain properties like 1+1=2 or list properties will help them advance their careers. They just want to be (become) better at designing web-applications. As an academic, you think you "Raised their level of abstraction." To them "A weirdo just pressed his weird tools upon me and I still don't know how to solve problem X in php."

And also:

But talent is not a great predictor of success.

I don't see what this has to do with anything. I wasn't discussing talent or success. Just whether you would help the average Joe programmer with certain training or, more concrete, maybe even a functional programming course. Those same students can be very talented at writing web-servers or starting a company or whatever they do and are often way more 'successful' (socially/economically) than those in academia. I am not even sure persistence is that good a measure too, seems to me the most 'successful' people just know better what moves to make at whatever points in their career. (Reading LtU a lot certainly doesn't qualify as a good move ;) )

Wadler once proposed the "Expression Problem" as a fundamental problem in a setting of FP.

I call BS.

Lots of object-oriented and structured design books in the 1990s discussed this issue. Some referred to it as the extensibility problem.

Now, what is true is that many programmers are only familiar with double dispatch using operator overloading, and are not familiar with other techniques to model the concepts, are are not aware of how pleasant they look.

As an academic, you think you "Raised their level of abstraction." To them "A weirdo just pressed his weird tools upon me and I still don't know how to solve problem X in php."

Why do I need a Ph.D. in algebraic theory to solve most of my problems? Some problems I deal with are more concerned with the presentation of data, and so I could perhaps see Horn logic coming in handy, but only the application of Horn logic to making traversable sentences and uncovering inferences, and the further application of this to hypermedia design - elegant, automatic infinite drilldown, drill across hyperspaces.

I can't spend all my time reading Haskell papers. Some of it has to be spent reading Tufte if I want to create something truly great. A language and compiler for a niche market might be an exception, but most users are not programmers and writing great software for them requires more than just type theory.

Your false dichotomies don't illustrate this, but rather come across derisive to practitioners as those who don't value higher knowledge. There is more to higher knowledge than functional programming.

Your false dichotomies don't illustrate this, but rather come across derisive to practitioners as those who don't value higher knowledge.

Hey, tell that to my old poor students who I tried to lift into our great scientific CS universe. ;) This is just coming to you from me straight from practice.

There's no derisive comment in sight, only if you read that into it. I never claimed that (some) CS students shouldn't be exposed to the "expression problem," process algebra, or using COQ. And I think most universities do quite well doing that. I am talking about the average Joe programmer which, after a decade of teaching, I think I know just better than most here on LtU.

There is more to higher knowledge than functional programming.

The examples weren't limited to functional programming and I don't particularly think functional programming should be regarded as higher knowledge.

[ Anyway, if you don't trust that decade, than you might also read it as 'a decade learning from the experience of people who spend the majority of their life teaching the average Joe.' ]

There's a substantial portion which will never learn, or see the use of, theory even after practice.

Sure. In context, I meant that the training required for concrete thinkers is to teach them the theories after they had applied them. But, in hindsight, I can see that this was unclear.

A large amount of programmers will never even experience the expression problem as a problem as long as they can code around it. In their mindset, there just isn't a problem, and it certainly doesn't make Clojure a better language than Java.

Since we've already mentioned Paul Graham's essays, I'll raise you two words: Blub paradox.

Programmers might not see the problem until they see someone else avoiding it, or have used a tool that does better. Concrete demonstrations are important, as is concrete experience.

And even those workarounds (boiler-plate, design patterns, self-discipline) seem okay (a bit painful, but what isn't?) until one starts contemplating the need to bring young grasshoppers aboard to help out with a large project. Then those workarounds become a clear problem - a hurdle or obstacle to bringing in new developers and getting them up-to-speed.

A bigger difference is that a PL theorist might observe this problem and blame it on the development tools, while a typical programmer would observe this problem and think it a law of nature - boiler-plate code, deadlock concerns, memory leaks are right up there with friction and gravity.

But talent is not a great predictor of success.

I don't see what this has to do with anything. I wasn't discussing talent or success.

You have been arguing that people don't have the 'ability' to learn theories, and you have used your experience as an educator as anecdotal evidence for this. Though I failed to make it clear, whole spiel on talent vs. persistence was explaining why your experience as an educator is inherently biased and insufficient for your conclusion: The inability to grok a paper theory in a classroom setting, where talent for certain skills and learning styles is magnified, is not strongly indicative of inability to grok theory after it becomes concrete and intuitive through experience and exposure.

whether you would help the average Joe programmer with certain training or, more concrete, maybe even a functional programming course

I've not been saying we should just teach theory. I agree with your conclusion that we should give programmers better tooling, a good problem, and let them have at it. I also agree that you won't see the typical vocational programmer turning into a PL theorist - though it sometimes happens to good effect. But I find your estimates about programmer 'ability' to be entirely too pessimistic.

Based on my own experiences and observations, a typical programmer has plenty of Eureka moments in the field. Concrete experience with tools (architectures, languages, libraries), design-patterns, boiler-plate, and self-discipline give rise to new intuitions in a sort of balloon model of knowledge. At the edge of these Eureka moments, a little theory can go a long way - can direct the developer to the 'right' intuitions, offer confidence and a vocabulary with which to discuss them, reason about their code, develop and defend designs. The theory can help the developers understand why their tools and project gurus impose those strange restrictions that they had before taken as 'just the way it is'.

Every new generation will go through the same experience, of course, which leads to a sort of grasshopper to guru progression with a lot of mysticism - weird rules that the grasshoppers are taught to obey like a religion, without the foresight or theory for understanding why. If not supported by 'tooling' these weird rules must rely upon boiler-plate, design patterns, self-discipline, and code review, all of which will fail. If the tooling is poor, grasshoppers will write a lot of bad code on their way to becoming gurus. And many will never progress especially far. Children experiment with programming, then often choose other paths. I have heard, though never confirmed, that programming is considered a 'stepping-stone' career in India, with a typical lifespan of only a few years.

These observations have me believing that purity, object capability model, information flow analysis, termination analysis, effect-types, and other support for local reasoning are critical: you need the ability to reason about your applications even when they are infested with grasshoppers. Access to 'power' within a language should be controlled and progressive, with more power being offered as the grasshopper groks the reasons behind the restrictions and gradually grows into a guru.

The anecdotal evidence of a hundred teachers with strong connections to industry goes a long way. But having said that, the worst students I had never seemed to learn anything and the best students just were good despite their education (which I think is true for all students, everywhere). Guess some of my old grasshoppers found another career and some just advanced, so you're probably right.

"A bigger difference is that a PL theorist might observe this problem and blame it on the development tools, while a typical programmer would observe this problem and think it a law of nature - boiler-plate code, deadlock concerns, memory leaks are right up there with friction and gravity."

thanks for writing that. i feel very much like the first half of that quote, and it has driven me insane when i talk with / work with people who are the second half. :-(

Re: comment-63056:

it has driven me insane when i talk with / work with people who are the second half

When you say “people”, are you referring to Gonzo? Per http://en.wikipedia.org/wiki/Raoul_Duke:

[Raoul Duke] usually obtains and consumes these substances [ranging from marijuana to amyl nitrite to adrenochrome] in the company of his attorney, Gonzo, a half-crazed 300 pound Samoan, whose drug-induced frenzies give even Duke pause.

Rickrolled

[ Gonzo? Wth does this have to do with anything? ]

You'll need to ask John Galt that question.

Okay, I'll tell you: Raoul Duke (raould) is a character from the book Fear and Loathing in Las Vegas.

What I think you can read in the report (a lot) is that some programmers were exposed to Haskell/Lisp/ML sometime in college, and assumed that that particular language is what functional programming is all about.

It shows that a lot of programmers learn something, with difficulty, at the language level, and probably weren't exposed enough to the abstract ideas in functional formalisms or equational reasoning which was all what, for instance, the original functional pearls papers were about.

It leads to a lot of silly misunderstandings between those who think that FP=Lisp, or FP=Haskell, and FP advocates. The general response will often be 'I learned *insert FP language here* and found it weird' instead of being able to abstract from that and see, for instance, the general benefits of equational stateless reasoning about programs.

It hints that a lot of programmers would be better served learning, say for instance, Bird-Meertens or Manfred Broy formalisms than particular programming languages. (And even so, they will probably think they are learning a programming language and never see the merits of being able to write something down abstractly.)

Having said that. You'll be surprised how hard it is to push those in vocational training to learn anything which isn't directly applicable to what they perceive will be their vocational calling. If the choice is Javascript or an abstract formalism, my silly observation in vocational training is that those students are probably right. It's just not worth teaching it to them.

You'll be surprised how hard it is to push those in vocational training to learn anything which isn't directly applicable to what they perceive will be their vocational calling.

1) I am not surprised. My peers in college were not that interested in the major and mainly stuck with it because it was a free ride. I am amazed at how many of them are doing unrelated jobs right now, e.g. one of them owns a DJ company. Even my best friend who ran a IT business now works as a paper pushing VP. Others have taken less pressure jobs in unrelated industries, mainly because they were disenchanted with how they were treated as an intern.

Besides that, I know what the math and CS faculty told me when I was in undergrad - I was a TA in the Math department for three years, so knew a lot of the faculty quite well.

It hints that a lot of programmers would be better served learning, say for instance, Bird-Meertens or Manfred Broy formalisms than particular programming languages.

2) I agree; The comments, such as using F# for parsing problems, could suggest that one way you could teach students about the practical usefulness of FP would be Bird-Meertens/origami programming/FP with bananas/squiggolist school stuff. If an engineer at MS is thinking about this stuff, a good follow-up question would be related to what kind of parsing problem they were trying to solve and what their previous experience writing parsers was.

It shows that a lot of programmers learn something, with difficulty, at the language level, and probably weren't exposed enough to the abstract ideas in functional formalisms or equational reasoning which was all what, for instance, the original functional pearls papers were about.

3) This is going to be true for any subject matter if not dealt with directly. Substitute OOP for functional programming, and you have just flashed backwards 20-30 years.

It leads to a lot of silly misunderstandings between those who think that FP=Lisp, or FP=Haskell, and FP advocates. The general response will often be 'I learned *insert FP language here* and found it weird' instead of being able to abstract from that and see, for instance, the general benefits of equational stateless reasoning about programs.

Besides the fact that (in my experience) even many, if not most, CS students have problems seeing the usefulness (let alone the fun) of reasoning about programs or any notion of correctness, it seems to be quite hard to abstract from something to come up with a theoretical, conceptual view. Consequently many shy away from even trying to do so. They deeply need a concrete theory, a programming language, an environment, a tool to believe that the thing they are dealing with is real and working with it has real world implications, produces something visible, something tangible in a sense.

It hints that a lot of programmers would be better served learning, say for instance, Bird-Meertens or Manfred Broy formalisms than particular programming languages. (And even so, they will probably think they are learning a programming language and never see the merits of being able to write something down abstractly.)

Those formalisms (or schools of thinking about algorithmic problems) are all good and well, but as long as you keep students writing things down on paper instead of programming them up most of them will probably not believe that this works and can be useful. It's quite amazing to see that on the one hand students tend to believe things they (or someone else) can program or build, and they tend not to question the truth of theorems or the correctness of programs, but once you being to question truth and take out the hammer that are formal theories to hit a nail squarely on the head instead of maybe just cutting off the top with a saw, they start to question and disbelieve.

That's why I think courses like Benjamin Pierce's using a theorem prover are useful. Overall using a constructive logic and driving home the point that proofs are programs might bridge the gap between the theoretical world and the more tangible world of down to earth programming.

Having said that. You'll be surprised how hard it is to push those in vocational training to learn anything which isn't directly applicable to what they perceive will be their vocational calling. If the choice is Javascript or an abstract formalism, my silly observation in vocational training is that those students are probably right. It's just not worth teaching it to them.

Maybe we should not worry about those people. The fact that they tend to narrowly focus on all things applicable to their trade can be turned into an advantage. Just get them with the old routine "Hey, look at this problem here, you know the solution, it's ugly, haven't you ever thought that it would be cool to have such and such a device/language feature?" This is how FP concepts will take the world, by giving people lambda expressions, first order functions, showing them that declarative programming has uses outside of spreadsheets and query languages like SQL. Like learning to think in terms of objects (seeing objects in every problem, seeing the world decomposed into communicating objects, and so forth), people can learn to think in terms of functions. Those who are into the theoretical side, and mathematics, will follow up on those aspects and discover a whole new world that can inform all their subsequent design choices and implementation techniques.

As I said, I teached in vocational training, i.e., up to bachelor level. You actually need to understand (the history behind) European colleges to know the difference. Having said that, that is actually 90% of those going into industry, and I know those 90% of students pretty good.

Please read my other post above.

Your story I think is mostly true for the US universities and (better) colleges and classical European universities. There the percentages of skills between students are different. But even so, you'll just find out that still, I guesstimate a good 30% are (good) bricklayers, and never will become (or aspire to be) physicists.

And then

Maybe we should not worry about those people.

You can take that stand in a classic university which aims to teach the best students up to near PhD level. You can't take that stand in vocational training, which, as I said, delivers 90% of the work-force in industry.

A very good bricklayer is infinitely more worth than a very bad physicist. So the aim in vocational training is, in some sense, diametrically opposed to that of academia.

I've read your comment twice, but I still do not get what you are trying to say exactly. The connection to your other post you mention is not really clear to me although I think that I at least get the message that it's not motivation but ability that "limits" some people to becoming "mere" programmers instead of also learning about the fundamental concepts behind programming and PL. I have the feeling that we agree that you cannot force someone to become a theoretician, and do not have to in order for them to become productive and useful in their line of work. But, as I wrote, I'm not that interested in those people, I cannot comment on them, and consequently I'm talking primarily about what I know: A European university. In my experience there are parallels between the mentality of people who just train for a profession and university students.

My point was on an original comment that MS should invest heavily in (formal) training of programmers to make them see, for instance, the wisdom of what is FP.

The general feeling exposed in that mail would be that if we would train them better in formalisms you would end up with better programmers. My point is, more training (or more abstract training) will not help in anyway, I guesstimate, a good 70% of the work-force/programmers. They are best of by being taught well in the tools of the trade. Best you can do is supply them with better tooling.

Whether, for instance, Haskell is better tooling (for them) is very debatable.

I'm talking primarily about what I know: A European university. In my experience there are parallels between the mentality of people who just train for a profession and university students.

No, I would say you work with the 'top' 5% of the field. The other 95% doesn't understand, or care, is helped by, or is interested, for instance, in FP or what is discussed here on LtU. You should be very careful not to generalize what you know of [yourself or] those 5% to the other 95% of the field.

[ And, no, I don't agree they are 'mere' programmers. They are usually the ones which, often, just get the job done. ]

[ Btw, you hinted that for instance students should learn formal reasoning with for instance COQ. I tried that. All I can say: Hell no! ;) ]

So we seem to be in agreement. I'm not generalizing from the top 5% as you say, I was talking about the rest of the field (or 95%, if you will) who are not interested in theory and more so in specific tools and getting the job done. In fact generalization was not intended, I was relating my experience with people which is probably not different from other's. I cannot (and will not) quantify anything of what I say, I'm not much into guessing numbers, it is just my feeling that teaching abstract concepts for the sake of themselves does nothing to attain the goal of promoting FP or thinking functionally/mathematically. And I'm about as doubtful as you about whether it's even necessary at all to think this way and know concepts. Once you start down that road you'll end up requiring that not only should programmers and CS students understand the mathematical theory but also the physical phenomena and the electrical engineering aspects of the systems they use. It might help (especially those theoreticians that build theories of systems that have no connection to the real thing but are merely beautiful in their own right), but it's not really necessariy for most jobs. Anyway, I'm getting off-topic and this post is probably already incoherent enough, so I'll close. I just wanted to have this misunderstanding cleared up. Thanks for explaining your line of thought in more detail.

Grow up, Ehud.

/unsubscribed

Of course I didn't...

Since I guess snarkiness is an acquired taste (as is overreaction), let me be quick to say that I didn't mean to offend the authors of the report.

And since the discussion seems to me to be very one sided, let me also suggest that without too much effort some snark remarks can be made about those who promote FP, say on LtU...

Hey, I generally laugh when people get snarky! It keeps the juices flowing. ;)

All in all, better to place a comment than say you want to, but didn't.

Never mind. I thought we finally found Ehud trolling but turned out you didn't. ;)

Trolling? Moi? Never!

We'll never know unless they force the other 81 to respond, right?

Let's assume it's somewhere in the middle. Even 14/100 isn't too bad - many are also probably using FP constructs w/o even being able to name it as such. And given (like most places) that the best 20% of devs probably do about 80% of the good/creative work on any given project, it's probably those devs that have sought out the knowledge and are using and reporting it - assuming they feel like answering some random survey. (I'm counting Linq, fluent interfaces w/lambdas, using HOFs, computation exprs in F#, etc., as FP - if you need lazyness, or typeclasses or whatever to count as FP, then at MS I agree the # will be smaller.)

Actually, the survey found that the 14 who were familiar with the term "functional programming" were among the 80% who get nothing done, spending their time learning new programming languages and filling out surveys.

True. Though this 20% is sooo good that they have time to respond to surveys and read LtU :)

Non-respondents are spending their time getting stuff done, like creating the next horrible version of SQL Server Management Studio, SQL Server Integration Services, etc. :)

Actually, the way Microsoft works (as far as I'm aware) is that there are systems groups, application groups, consulting groups, and research and development groups (roughly).

Consulting groups really just focus on filling in the gaps left behind by systems groups and application groups. Stuff like "Application Blocks" and "SmartClient" are "consulting groups".

Systems groups are people like WCF, WPF, OS Kernel, etc.

Application groups can range from anything from PerformancePoint to BizPoint to Office to Expression Blend to Visual Studio to SQL Server Management Studio.

R&D groups are the SDEs that work closely with Microsoft Research on productizing ideas and lending extra manpower to research projects that would take too long to get done otherwise, thus focusing capital investment on a few large bet projects rather than spreading researchers across many smaller bets.

All 14 turned out to have an account on a simple website in a distant corner of the Internet they referred to as LtU. ;)

The paper doesn't go into methodology, but with a company directory a simple random sample is possible, and 100 samples is enough to put the standard error under 5%.

IIRC, 'standard error' assumes that measurements fall on a bell curve (Gaussian distribution).

But, for this survey, I would expect to see clusters of responses rather than a smooth Gaussian distribution. This sort of free-form response makes visualization difficult, but, if we had a larger sample set, we could feasibly cluster responses based upon words, concepts, phrases, rubrics. I hypothesize we would see multiple 'schools of thought' with regards to FP, with the largest school being "huh, what's FP?".

If we could constrain responses, we would have an easier time processing them. What could we do to constrain responses? Maybe we could provide small code examples and ask of each: does this look FP to you? (I bet the response after a few such samples would be 'go to hell'.)

Anyhow, nineteen responses after considerable attrition bias doesn't give us much to go on - not nearly enough data for interesting cluster analysis, and well more than 20% standard error even if it was unbiased and fell on a bell curve.

Again, I don't think the survey was made for quantitative purposes but as a pilot to help orient the real thing. Otherwise, +1 for the bell curve fallacy (though, due to the likely relevance of network effects and basic segementation, I doubt think the emergent distribution will be super complicated).

The standard error makes no assumptions about the population. The randomness in question is the choice of people to survey from a complete directory of employees, not any unsupported hypotheses about properties of the population.

Consider the difference between a quicksort which always takes the first element as pivot, because the programmer thinks the input is "random", and a quicksort which selects a pivot according to a physical source of randomness. The first will run into problems on sorted data, the second is exponentially unlikely to take quadratic time. (it might, but the expected running time is n log n so it cannot do that very often).

For answering the question "what fraction of Microsoft employees, when given this survey, will indicate that they are familiar with functional programming?", the survey is fine, each name selected and polled is an independent Bernoulli trial. Trying to extract any higher information, clusters, whatever, is as you suggest fraught with peril.

1. Survey design is an iterative process. Otherwise, you increase the risk of just confirming one of a preselected set of narratives, etc. Sounds stupid but powerful. Short cuts lead to bad science (and it's obvious they were feeling the water here.)

2. You can get similar knowledge from TIOBE etc. practices already; once you want more invasive knowledge, you need to convince the relevant production teams to be invasive for you. That's not actually an easy sell.

I'm actually on the same floor as Daan right now; I'm hoping to get a more thorough (and general) survey out in the next month or so. Odd that I had to find out about his work through LtU!

Odd that I had to find out about his work through LtU!

Well, Caitlin is the primary author on the tech report (it seems), and she was at PLATEAU 2010, where she also published User Evaluation of Correctness Conditions: A Case Study of Cooperability. She told me at SPLASH that she is getting more interested in evaluation of programming languages, and that this paper is representative of the work she wants to do in the future.

Another person at SPLASH told me that usability people have a hard time arguing their case with product engineers who create forward-facing APIs, and left Microsoft because of it. I wish I could read an experience report from those people, since just hearing anecdotes like that only confuse me rather than enlighten me; I learn nothing from these comments.

I would like to know: Why do engineers reject usability recommendations? What were the usability recommendations? This sort of information is valuable but extremely hard to publish, at least today. The reason is confidentiality. Somethings are best kept secret. A (large) open source project would be more likely to write about why a present design is busted and what will be done about it (but of course writing code and doing testing takes precedence).

Something I mentioned at PLATEAU was my dislike of API Usability Studies published, and I made the analogy to Fagin's seminal code review study, the results of which were only really questioned slowly over time until the full idea behind code review was developed. Code reviews got a bad rap for being a heavyweight process tool, mainly because practitioners would cite Fagin's seminal study on its effectiveness and Fagin's insistence on the amount of time you had to take to do it well. Later studies showed Fagin didn't answer the question he thought he answered, and demonstrated new experiments to provide new insights. Today's API Usability Studies are at similar infancy in their thought process.

i hope you know of PPIG. might be worth posting on their list.

Here is the gist of a survey I would like to see answered by a pool of professional developers, including a significant subset who work primarily with functional languages:

Here is a list of 50 features (and possibly mis-features) of programming languages. Please rank each of of them in desirability on a scale from 20 (most valuable) to -20 (most harmful).

That view is motivated by the following perspective. I read LtU regularly, and I'd classify myself as an agnostic about functional languages. It's really hard to tell from most discussions where I might agree or disagree with people who see themselves as advocates for functional languages. But my general impression is that I largely agree with them about the goodness of the language features they like, but often evaluate those features as a little less important than other ones they don't care so much about or are willing to do without. Perhaps they also regard some imperative language features as very negative wheeras I see the same drawbacks but rank them as fairly low down on my list of concerns (e.g. one person may regard a segfault as among the worst possible bugs, while another person sees it as an easy bug to find and much less serous than outputting a nicely formatted answer that is nevertheless a mistake).

my arm-chair philosophizing and stereotyping is that we can put people into 2 camps: there are people who rank things based on pragmatic "can i work around it, and is it so unique that it makes me look stupid compared to my peers?" vs. there are people who rank things base don "crap, this is inconsistent and arbitrary and stupid and there is a better way, even if it doesn't have a compiler for winxp yet."

I'm sure I'd wonder, with such a survey, whether I'm supposed to be stuffing all the listed features into one language. Some features overlap and would compete for territory. Some features would compose poorly - using both would hinder performance or safety. Some features only become effective in combination with certain others. How is it we are to rank individual features?

Maybe a different take: build a list of 'scenarios', written as anecdotes - short stories of success or failure, maybe a paragraph each. Then have them rate these scenarios for 'importance' to a new language design - a judgement not of desiderata, but rather of whether to be dismissive of the scenario or give it careful attention.

For example, there might be a couple stories regarding memory safety and modularity. One might tell a story of a programmer who managed to corrupt his own data by fencepost errors or whatnot. Another might tell a story of how a library they were using, developed by a third party, corrupted the data. The scenario would not say how long it takes to isolate the problem, or would say the same time (e.g. '2 days'). How will people rate these stories in importance?

One could presumably compare STM vs. Locks, and concerns about deadlock and starvation and personal control over performance and integration with third-party modules or scripted code... using stories such as this.

But I'm sure that developing a list of stories, even at a paragraph each, would be an enormous undertaking. You cannot just lift scenarios from Daily WTF because each scenario should isolate just a few concerns. The 'mix' of concerns (allowing more than one per scenario) allows us to combine a few features, but with mixed concern scenarios we would also require a vastly larger number of them.

Any version would be incomplete and require informal interpretation. Scenarios vs. features is not really too different, because ideally one would do the exercise in stages, with questions in later stages based on stuff identified as important by some contributors in early stages. One type of response that could either be a feature or a scenario is stuff along the lines of "Has available time saving libraries (or built in capability) for doing X on platform Y". If such a capability is not already available then one has to spend time creating it. Project managers may talk about the ability to hire a team of people who can work together using specific tools. Someone else might emphasize having a good source level debugger. Automated serialization of functions and data might be important to some else. Or generated embedded SQL to talk to some particular database. Real world concerns tend to go in a lot of different directions.

I was thinking about how one can ascertain the intuition or knowledge people have on how language features interact (on the semantic level). My best idea so far is to give a matrix (let's say of 5X5 or slightly bigger) of features, and ask respondents to indicate in each box if they (a) think the two features go well together/are synergistic (b) hard to use together/should not be combined (c) unsure (d) don't know either or both.

I can actually imagine some pretty fun statistical analysis one could try to do on data of this sort...

It might be more productive to ask them which features recently introduced they know, use, how often and for what, and ask them which features they think are missing. Most programmers are not language designers, I don't think they actually know.

On some level I think we certainly agree about this. But, and this is a big but, if FP is typically introduced by talking to programmers about (say) immutability, and referential transparency, you'd expect programmers to know what these are. Similarly, if you want programmers to think about using laziness, you'd expect them to have some feeling about whether laziness has any relation to the factors just mentioned.

Now clearly, if languages could hide all this complexity, by offering a different computational model which doesn't expose these issues, asking programmers about them would be unnecessary. I just think FP is not there (yet?).

Most of the research looks to be done. I think FP is there, but that 'there' is some other place than initially aimed at, i.e., I think FP shouldn't hope to achieve GPLs ready for systems engineering.

When I look at FP over the decades, broadly, I think you can divide it such:

Sixties and seventies: early explorations (LISP, ML).

Eighties: emergence of FP (CLEAN, HASKELL, OCAML).

Nineties: performance considerations. (fast compilers, functional algorithms and data structures.)

Two-thousand: aim on SE and FP problems. (GADTs, monad zippers, more type theory.)

Looks to me FP has become introspective aiming at researching problems for which you first need to be a hard-line FP programmer to even encounter them. Which is fine, of course, but I think they've overshot the best target. I think FP has proven by now it is just bad as a systems engineering paradigm but very good at mathematical modelling. Imho, FP should aim to compete with Matlab, not C.

In that sense, FP is ready. Lacking is possibly better alternatives than Haskell for mathematical modelling, but I am sure they'll be developed at some point.

FP has proven by now it is just bad as a systems engineering language but very good at mathematical modelling.

I'm not sure I agree. Depends what you mean by "systems engineering" I suppose.

With systems engineering I mean low-level stuff. Writing an OS, device drivers, complex gaming engines. My mileage varies ;)

Mind you, I am not saying it is impossible to write an OS in a functional language. Just, when I think of the tricks you need to employ to do that, I in general think: "Why Bother?"

Mind you, I am not saying it is impossible to write an OS in a functional language. Just, when I think of the tricks you need to employ to do that, I in general think: "Why Bother?"

That's what I thought you meant. Fortunately, this is not a limitation of FP for systems programming in general, just current FP languages and runtimes, which lack nice constructs for manipulating bit-level data or low-latency GC. See the work on the House OS, High Level Views on Low Level Representations, BitC, and others.

The lower-level you go, the stricter the requirements, but as evidenced by data parallel programming on GPUs, you can still have high-level compositional programming style that compiles to efficient code. It's still an active area of research though, so I disagree that the question of whether FP is suitable for all low-level domains has been settled.

I can certainly see a kernel written in an FP language with a real-time GC. I'm actually surprised no one has tried this yet. While not a top performer, you could probably get some nice properties out of it; at least you should expect a reduction in bugs and security vulnerabilities, and kernel extensions would be much easier and safer.

BitC was originally started to push the envelope in this domain, though not likely not using FP in the kernel itself.

Two-thousand: aim on SE and FP problems. (GADTs, monad zippers, more type theory.)

Looks to me FP has become introspective aiming at researching problems for which you first need to be a hard-line FP programmer to even encounter them

Type theory is not restricted to functional programming. Research in type theory is relevant as soon as you want to prove properties of your program.

There are strong bounds between the groups that develop functional programming languages and the groups that are interested in the semantics of programming languages (one could even argue that they're the same people). But that does not mean that only the semantics of functional languages are interesting; and most of the advances in type systems could probably be used in other settings as well.

My original point was on whether FP is ready (yet). Now type theory is cool, has lots of applications, and is great research. But is FP ready for prime time? Yeah, sure. It doesn't get more ready than this. At least, according to me.

My point is: More type theory will not push FP mainstream any sooner. The research is done [to make FP mainstream], except for maybe a better or simpler programming language than the current alternatives.

That was not to imply that all research on type theory is done.

aim on SE and FP problems. (GADTs, monad zippers, more type theory.)

If FP PL designers consider these to be the SE problems to solve, the community is getting what it deserves.

FP with moderate use of more advanced type system features (phantom types, mptcs, fundeps or type families) is making great headway as a language for systems level code *generation* as is. The greatest obstacle to making things suitable for systems and hard real time work is, I think, still garbage collection. That's not an issue with FP per se, but an issue with all high level languages. I think that there's nothing that you can do with, e.g., google's Go language, that you can't do with Haskell.

What about the huge ocean in between. What percentage of developers are writing device drivers or operating systems? To me, the sweet spot of FP (for the mainstream) is in the "software engineering" as opposed to "systems engineering" space. I'm talking Java,.NET, Ruby, PHP, etc. FP is already making inroads into that space. Any additional provable correctness to a million+ line codebase would be extremely valuable, not to mention the concurrency aspect.

I'm actually trying to put together a survey right now about catalysts and barriers for PL adoption, and, when rereading this thread, realized

1) it's worth (re?)linking the hammer principle language survey:

2) I should solicit any further questions / hypotheses you guys might have on it

Thoughts grounded on sociological / psychological / economic models are especially welcome :)

Publish your list of features to reddit.com or a similar size and you'll get a big response.

Echoing dmbarbour's concerns, my response to such a survey would be that language design is a highly non-linear problem; a language can be much more or much less than the sum of it's parts, and the desirability of a given language feature depends on the rest of the language.

One classic example is call-by-name evaluation and imperative effects; if you desire effects, then you (should) see call-by-name as a harmful feature, and vice versa. I might be tempted to rate each as modestly desirable; each certainly has their use cases. But having both is pretty harmful.

Still, it's not a bad idea, and if anybody does it I'd be interested in looking at the results.

Design by focus group is always a bad idea in any domain, not just language design. The problem is, people will always drift toward what they are comfortable with. In a survey, it would be better to look at programming problems and compare solutions in different languages using them in one style or another; e.g., F# vs. C# (imperative rather than functional C#). I think looking at individual features would result in a bunch of incoherent results and it would be difficult to draw any useful conclusions. Or perhaps a user study could look at how hard is it for developers to pick up functional programming and guage how functional programming improves developer performance?

Design of a survey, interpretation of the survey, and design of a programming language are all different activities that involve skill and hard work. The first two might be part of the same project and the third is different. My purpose in this thread was just to suggest a general idea for survey design to someone committed to doing that work. There wasn't any pretense of trying to think through all the details for them. I very much agree with the points that a popularity contest is not what we are after. That is one reason I suggested in another comment that they could use an iterative with one stage designed to solicit info about features that are important to many programmers and also ones they think about without prompting. Another stage could then ascertain which of those features were familiar, which of the familiar ones are valued or disapproved of, and which ones they use together on projects.

I don't see call by name as a harmful feature in the presence of imperative effects (though I do see it as a good feature of a language/toolset if it makes it very easy to find all the variables/state modified by a given function/procedure call). The fact that everybody has different opinions is the premise for the exercise.