The second and main point is that since this large programmer population receives its knowledge almost exclusively from MS, it's a really good thing that MS have started teaching functional programming. It's probably the best chance FP has ever had to break into the mainstream. Even if it takes over just a corner of the MS world, that corner is probably larger than the rest of FP put together. This is a really good thing, and it massively kicks the ass of the crap that MS used to feed their "Elvises" and probably still do.

I'll add a third point. We know why this is happening. It's because a little less than 15 years ago, MS changed their direction, acquired some top-notch people (starting with Hejlsberg), and started moving in a direction more informed by CS and PL theory. This process is slow, but good. One can finally see it yield real fruit in the form of F# and the recent enhancements to C#. People like Meijer are having a very real influence. Come to think of it, that's probably why people like Meijer went to MS to begin with.

Simon Peyton-Jones is another heavy hitter at MSR.

If F# does well, I have to wonder if a sanctioned dialect of Haskell for the CLR is in the making. The only thing giving me doubt is that I can't think up a business case for it. OCaml has an audience in the financial world which gives MS a business case for F#. Having F# already, what would an H# give them?

Who besides Jane St?

My choice of development platforms and tools doesn't mean that I'm inherently less curious about what else is available to me, and the author's generalization and yours would seem to indicate otherwise. What you're reading in the HN comments are the objections to this generalization.

If I had written this article and wrote it about how PHP developers don't know anything about unit testing, agile, JIT compilation, pre-caching, and whatever, a different audience of HN readers would be tearing it up in the comments right now.

If I was looking for a job as a .NET dev, my depth in .NET is what is important, not how well I know N number of other languages. If I'm working in a .NET stack, my experience with Java, while not worthless, is not as useful ass more depth in .NET. An individual has a finite amount of resources to spend learning about other stuff. Yes, it would be awesome if I knew tons of other languages or how things work at ever lower levels of code. I just choose to spend those resources learning things that are more immediately useful to me.

The author just took a very derogatory approach to this point and I think it's understandable that it upset people.

It's a bad thing because the MS world has traditionally been cut off from the best ideas and even the best mainstream ideas around software. When I snapped out of my dogmatic slumber as an MS dev I was shocked at how much I had been missing and how much better my work got when informed by the computing world as a whole. Although my knowledge, like most people's, is still partial and fragmented, nevertheless this was a real and very valuable state change. So I can't help but respectfully suggest that if you want to grow as a software person, you should probably seek something equivalent in your own path. It's not a question of breadth vs. depth. It's a question of a pond vs. the ocean.

And I think he doesn't understand the difference between language features making it to your production language and the feature existing elsewhere (especially if elsewhere is an obscure academic language). I can be sincerely interested about lazy evaluation showing up in language -- but that doesn't mean that I hadn't used it for the past 20 years in toy projects.

Like the author, I commend Microsoft for using this influence to help bring functional techniques into the mainstream. The programming challenges we face today are more suited than ever to FP and the backing of a big vendor with mature, sophisticated tools is exactly the kind of boost FP has been waiting for. This can only be a good thing in the long run for Haskell, Clojure, Scala, Erlang etc.

I deplore a lot of Microsoft's business practices but the work they're doing in this area and in support of the Haskell team deserves kudos.

On the other hand MS don't treat their own workaday programmers much better by calling them "Mort".

Somebody knowing 20 languages does not necessarily make a good employee. What the enterprise wants is exactly what VS has been giving them for the past years.

Sure, as the enterprise is escaping IBM-isation of the workforce you can see a bit of a shift in perspective (evidenced by changes in VS), but nothing so drastic as to actually decrease "productivity".

The point here is that the article has the wrong name, the title should be "How enterprise lives with the programming world".

Mind you, I don't even know what the enterprise is. All I know is that I've shipped a lot of software, and really enjoy using Visual Studio.

Go, Microsoft! ^_^

Incidently, Smalltalk isn't normally considered a functional programming language (do doubt because object orientation overshadowed it) but with its closures (called blocks) and select:, collect:, reject:, inject: etc methods it seems (to me) as much so as Scheme.

Eric Raymond used to say the same thing about Lisp. I wholeheartedly agree.

That said, I also like to annoy my fellow Java programmers by saying that Smalltalk 80 was more advanced than Java 2010.

The example on page 3 was:

   Dim greetings() As String = {"hello world", "hello LINQ", "hello Apress"}

   Dim items = _
     From s In greetings _
     Where s.EndsWith("LINQ") _
     Select s

   greetings := #('hello world', 'hello LINQ', 'hello Apress').
   items := greetings select: [:s | s endsWith: 'LINQ'].

But this is the typical argument I hear from people about anything. "Hey, that was a good movie"... "Dude that plot is basically a derivative of Hamlet with a twist of Revelation, chapter 3. Nothing really new there". Or the most standard, "Actually you can do that with Lisp." I'm sure you probably know that everything in that Linq query is pure syntatic sugar. Not runtime changes needed.

But with all that said, I'm sure MS didn't do this to be "innovative". At least I hope not. I assume they did it to make the lives of developers easier. That's the real test, not if no other language ever implemented the feature.

I imagine you're right, and it's an entirely reasonable thing for MS to do. What I took exception to is the way the book spun it as an amazing new technology.

Plus, I have a personal feeling those gory details are there by design - Microsoft has every incentive to make it hard to port Microsoft code to any other platform and no incentive to play nice with code that will run elsewhere.

I cannot imagine going back to a career limited to a fully-Microsoft stack. There is just too much missing.

I miss the days without visual studio when I actually had to look up the documentation for most every data type to see what functions I could use, and when I had to look up how I named my variables and functions in my own classes.

It was wonderful. This whole auto complete functionality and when I press . is just to powerful. I also miss having to worry about garbage collection and debugging with printf statements. Not to mention the CLR taking care of buffer overflows and all sorts of other things.

Microsoft just has made it to hard on their programmers. </sarcasm>

I'm curious why you think it would be important or valuable for a VS developer to write makefiles.

Your subsequent statements seem to indicate that you believe it allowed MS to put more project complexity, hidden by the IDE. I don't particularly see anything wrong with that, but maybe I'm misunderstanding you.

My view on this is: I write code to create sellable product. I don't sell makefiles.

Microsoft writes nice tools, and they all work well together. It's a truly integrated environment up and down the stack. And for the simple cases, it's great. I hit F5, and my app runs, right out of the box.

But I find the tools difficult to extend, when it comes to it. They are mostly black boxes. This means I'm dependent on MS to add features before I can use them easily. It's possible to write plugins for VS, etc., but I don't get the sense that most people do that. I know I don't. It seems difficult and time-consuming; I'd rather just live with less than ideal behavior.

But I've been trying to branch out into other stuff in the past year or so and dabble in different things (app engine, some rails, some C code). What I've noticed is that low level tools like make are cool for a few reasons.

First, regardless of its syntax, make is pretty damn simple for the simple cases. Even as a novice, its easy for me to tweak a makefile to suit my needs. I think this simplicity is valuable. By the same token, the generated code for rails is all pretty easy to follow and tinker with. That's not always the case when you pull back the curtain from Visual Studio.

Second, make (and others) are orthogonal to the other tools I'm working with. It doesn't matter what editor or framework or languages I'm using. It's pretty easy to whip up a makefile to compile or deploy a dev build or whatever. This is true because steps in a makefile are expressed in terms of terminal commands. Simple and powerful.

Third, make is ubiquitous. I think it's pretty cool that I can use the same makefile to deploy my app engine site from Ubuntu or OSX.

I guess what I'm trying to say is that MS's powerful tool set feels oddly constraining to me. I feel much more in control with a set of simple and independent tools, even though I'm much less experienced with them.

Just my two cents.

Of you don't understand your build system, you really don't know what you are shippin.

VS provides the ability to do all of those things. You can both extend the IDE and create DSLs. And .NET runs on a VM, so it's write-once, run-everywhere (unless you're trying to port to Mono/Linux, but that's not what .NET is designed for). It also has the absolute best debugging toolkit of any IDE, ever.

Make files are for the people deep down in the guts of systems, writing bare-metal code. This isn't 1990, we don't to force ourselves to use these antiquated tools for all sides of development.

The idea that you need to "understand your build system" is particularly ridiculous. I understand that my code compiles, has no warnings from VS, passes all my test cases, and works fine in beta testing. Why do I need to write a make file to do what VS is smart enough to do automatically?

As for this not being 1990 (or 1980, BTW), I agree. One should not use antiquated tools to do a job, but I find your willingness not to understand what you are doing quite amusing. If I cared, I would find it distressing, but, since I don't, I will leave it as it is.

Being condescending and rude isn't moving your point along any. In fact, I still don't know what you point is. You appear to think makefiles are inherently superior to VS solution/project files, but for no obvious reasons. The only reason you give seems to be that VS users don't understand their build system, whatever that means.

With that said, I know people who the old VC project system inside and out. And I know tons of people who know MSBuild as well as the most build engineers I know in the Unix world know make.

Makefiles are an artifact of a particular build system. It is not foundational to all build systems. Understanding Makefiles is useful for the world in which you use make, but I fail to see why it would be useful in a world where they don't use make.

It holds, within its structure, information enough for VS to build its targets. Who cares if it's not called "Makefile" and you don't invoke it with "make"?

The reference to makefiles is that, if most VS users did understand what goes on after they invoke "Build", they would be able to write a makefile. Since so few of them do, few of them could, conceivably, write one.

Or tell, exactly, what happens when they hit... What was it? F9?

And I think most developers do understand what happens in their build files. Especially since most of them are now msbuild files. We actually handcraft our own, because of the way we have our integration server set up. It's not rocket science, but its not a makefile either. But yes, it does capture dependency information.

Either you just know really poor devs, or you know a lot less than you think you do about what people know in this space.

I agree with this. But what has that got to do with Visual Studio and makefiles?

Is your point that Visual Studio is hard to use, somehow? I've created quite complex build systems using Visual Studio and scripting. I'll admit I've had rough patches where it's been hard to figure out where a setting might be, or where I forget to set things consistently (e.g. library inclusion across build targets), but it's pretty full-featured and reasonably easy to grasp. It strikes me as consistent, once you learn the basics.

Perhaps your point is that makefiles are easier to review "at a glance"? I don't really agree with that, since it depends entirely on one's competency with makefiles versus Visual Studio project/solution configuration.

I could be missing something entirely, though, so I welcome any additional take on it.

The point is that what appears to be an easy approach to project build management is, in fact, a loaded shotgun aimed at your feet.

Oh wait, no it wouldn't.

And the C# build process is very simple. It should be easy to understand.

Okay, your premise seems to be:

1) Understanding your build process means you can write a makefile for it.

This is only true if you know how to write a makefile. i.e. makefile syntax and the specifics of your toolchain.

2) Conversely, if you can't write a makefile, you don't understand your build process.

This is false, because I can't write a makefile since I don't know makefile syntax. I most assuredly do understand my build process, though.

Correct me if I've misunderstood you.

It does not follow that if you don't know how to write a makefile for your toolchain the necessarily you don't understand your build process. But, if you can't write it after you understand its syntax, then you are pretty much doomed.

That's a good thing, to be honest. One person fewer who needs to worry about stupid semantic differences between tabs and spaces is one person happier.

I would find debugging makefiles... enjoyable compared to writing Windows C++ code.

Care to share what you find so distressing in Windows C++ coding? I'm genuinely curious.

I hear a lot of people -- primarily Linux C coders -- bashing Windows[1], but they never seem to have any specific reasons, at all. I chalk it up to subjective taste and something that's like imagined oppression, or imagined insult (e.g. Windows is too easy to code on, dues aren't paid, etc.).

[1] I can rarely nail down if they dislike the Windows user experience, Visual Studio, the Windows API, it just seems like Windows-oriented angst.

It's gotten a lot worse since I started writing most of my code in Python (2001-). I can't look at C code for Windows and consider it elegant anymore.

If it's any comfort, I find most Unix/Linux APIs I've looked at to be painful, and long for (most) Windows API functions. :-)

One thing Unixy people seem to hate is "Hungarian" naming of variables. Granted, like most things, it can be taken to a ridiculous extreme, but I've always really liked it.

Every time I have to parse Hungarian notation, I feel compelled to change my name and renounce my ancestry ;-)

But it's a matter of taste. I also find it weird to start method names with uppercase in C#. Again, taste.

Yes, while I don't particularly like Win32, GNU make is objectively horrible.

It is, but it's simple, clear and readily understandable. It will never surprise you.

I have come to dislike surprises that happen during build ;-)

I sure didn't in 2001. The author is an idiot.

So many Kids These Days feel the entirety of Computer Science and Programming has been developed since 2000. I'm pretty sure LISP and functional programming existed in literature, learning, and practice before early 2000s.

And to be honest, there was little practice in Lisp before 2000... and frankly little after 2000.

And the statement that there's "little practice" in Lisp is a statement about the current mindset of most programmers, not about the language itself. Whether it's useful is orthogonal to whether people use it.

And my statement about Lisp was just about the state of the world. It's a fine language, but we shouldn't pretend that its used more than it is. Actually in teaching it is used a fair bit, and teaching is practice of a sort.

I'm a pretty well-rounded developer, but I know there are innumerable things that I don't know. I also know that I research enough that the things I'm not comfortable with aren't particularly important for me or my projects.

I've never developed anything real in a functional language, for instance, aside from doing some tutorial tests and realizing that the friction (with coworkers trying to maintain, for instance) overwhelmingly demolished any potential advantage.

I will say one thing though -- the most mediocre developers I've ever worked with tended to have the widest "range" of "skills".

It's a way to compensate for never being able to provide solutions. Instead they always weaved, always sure that if you just embraced the latest thing and did things entirely differently it would be so much better (which they never actually do themselves because their role is more "OMG, you don't know about {X}? OMG!")

If programming is just a job, and you don't care about it when you leave the workplace, that's a reasonable attitude.

If, OTOH, programming is something you care about and that actually interests you (which is true of nearly all good programmers), it's an attitude you won't have.

> actually interests you (which is true of nearly all good

> programmers), it's an attitude you won't have.

Whoa! So what you're saying is that if I don't know the recent trends in functional languages, I don't care about programming? Seriously?

Do you see the problem here? This guy is laying out arbitrary things which appear in his domain of knowledge, and discounting others for not having the exact same set of experiences. I see this a lot among software people.

Sure, broadening your horizons gives you new insights, but there is a lot to be said for mastery and focus.

Additionally, why is it that there is an expectation in software that my job has to also be my hobby, or else I don't care and/or I'm no good? Do you think mechanical engineers working for an auto manufacturer are expected to be at home designing bicycles, lest they be thought of as not caring?

No, I'm saying that if you're not interested in different programming paradigms, you're not interested in programming. You don't have to know about "recent trends" in functional programming (it's not actually that recent -- Lisp has been around forever, and the Haskell standard is over a decade old). But if you're not interested in functional programming at all, then no, you're not interested in programming.

> This guy is laying out arbitrary things which appear in his domain of knowledge, and discounting others for not having the exact same set of experiences.

But I'm not doing that. I'm saying that programmers ought to have some familiarity with some of the basics of the technology they work with. Knowing nothing about functional programming is like knowing nothing about HTML -- it is a big gap in one's knowledge.

> there is a lot to be said for mastery and focus.

I agree. Focus is good. But you can't have mastery without knowing the right programming techniques and paradigms -- these can change a 500 line program into a 100 line (and easier to understand) one, or a 5000 line program into a 500 line one.

> why is it that there is an expectation in software that my job has to also be my hobby

I have no such expectation. I neither know nor care what you do for a living or in your spare time. What I am saying is:

1. some skills take a lot of effort to master.

2. programming is one such skill

3. you're more likely to take the time and effort to learn a skill if you like doing it

4. therefore, programmers who program because they like doing it are going on average to be better at it than programmers who program because it's just a job

I'm going to go ahead and call B.S. on that. At my most interested, I've had no interest (nor awareness) in functional programming.

Now I'm aware of it, but still not particularly interested in it. What I am interested in is working with a platform that has better foundations (e.g. .Net vs raw C++).

> Knowing nothing about functional programming is like knowing nothing about HTML -- it is a big gap in one's knowledge.

Completely arbitrary. A lack of HTML knowledge would be shocking only due to its ubiquity.

> Focus is good. But you can't have mastery without knowing the right programming techniques and paradigms

You seem to be saying that functional programming can be used to greatly reduce code. But if my employer doesn't allow it, and my teammates aren't experienced in it, what good is it to me?

> therefore, programmers who program because they like doing it are going on average to be better at it than programmers who program because it's just a job

I agree with this statement, which is nothing like your earlier statements.

> I'm going to go ahead and call B.S. on that. At my most interested, I've had no interest (nor awareness) in functional programming.

FP is just one programming paradigm. Other important concepts in programming include: object orientation, stack based languages, model-view-controller, macros, templates/generics, structured programming, lazy evaluation / dataflow-based programming, interrupts, cooperative v. coercive multitasking, memory protection, pipes between processes, serialisation, event loops, modularity / seperation of concerns, common data structures such as lists, arrays, binary trees, hash tables, etc.

My contention is that a programmer who doesn't have a large number of concepts such as these is likely to build bad software when confronted with a large, complex software project.

> You seem to be saying that functional programming can be used to greatly reduce code. But if my employer doesn't allow it, and my teammates aren't experienced in it, what good is it to me?

Functional programming doesn't just mean esoterica like Haskell. In the wider sense of the term, it means anywhere where you're passing a function as a parameter or the return value form another function. You can do it in such mainstream languages as Python, Ruby, C#, and JavaScript. They're even adding closures to Java.

I'd be very surprised if your employer has a blanket edict against higher-order functions, because employers are either clueful or clueless -- clueful ones will allow it, clueless ones won't know what it is.

Right, but this article was bashing people for not knowing, specifically, about functional programming. My entire point has been that it is ridiculous and petty to do this. Let's say you know A, B, C, and E. Aha! What about D, I ask. You're clearly an idiot, I can't believe you don't know about D. And here you get F, which is related to D, and you act like it's something new to the world. Pssh!

See?

> I'd be very surprised if your employer has a blanket edict against higher-order functions

Er, every employer I've ever had has been very strict about the introduction of any new technology, library, language, etc. This is because every employer I've had is concerned with maximizing productivity and shipping product. Tinkering with new stuff on the job can be rather dangerous to one's employment.

Again, I'm not promoting ignorance, what I'm doing is speaking out against this alpha-nerd judgment of others.

Your experience differs from mine. For me, while I've often been told what language to write code in, I've never been told what features of the language I am or am not allowed to use. Regarding libraries, I've always used relevant open source ones, paying attention to licensing issues as appropriate.

Because really good programmers love to learn new tricks. Because learning new tricks will make them good programmers. You admit learning about PHP made you a better C++ programmer.

A couple years back, on a mailing list, a novice asked what she should learn during her vacations, Python or Ruby. I answered she should not master, but learn a bit of Lisp, Smalltalk and, having time, Forth. There is little chance she will ever use any of those languages directly, but each language holds valuable lessons that will prepare her better for her career.

And that's why it's important for Dick to learn to develop for Linux.

Right. And because you don't know the particular tricks I learned, it indicates some sort of deficiency in your knowledge or character. Hmm... Nah.

> You admit learning about PHP made you a better C++ > programmer.

Uh. I learned PHP while coding for a company. No way I would be at home learning PHP for 'fun'. I would rather be out cycling, rock climbing, or being with friends.

> a novice asked

You're effectively talking about a student. Students get a sampling of a lot of ideas. Experienced software engineers are expected to have mastery in one or more areas.

> And that's why it's important for Dick to learn to develop for Linux.

That's an absurd conclusion. Perhaps, "that's why learning Linux may be important for Dick." There are a lot of things in the world to learn. Perhaps Dick will benefit vastly more from learning some other platform, API, language, or entirely unrelated skill.

My point is that this guy comes off as superior and snarky because the MS plebes are discovering what he's known for rh so long. That kind of attitude is corrosive, dismissive, and unproductive.

Aren't you exaggerating a bit? I never judged the value of a specific field of knowledge. If you want to master Z-80 assembly language, feel free to do so. I prefer the 6502.

> No way I would be at home learning PHP for 'fun'.

Are you sure this is the right career for you? Because if programming is no fun, you will treat your job as a burden. I enjoy weekends (walking, being with friends, reading, playing with my son) as much as I enjoy weekdays (solving mind-bending programming problems, preparing lectures - will do two a month from now).

> You're effectively talking about a student

Aren't we all students? I am re-learning Smalltalk and learning Lisp. My wife is going towards her MBA. I am learning to program micro-controllers in order to build hardware for a vintage 8-bit computer. Learning is good.

> That's an absurd conclusion.

Why would it be absurd to learn how to program for an OS lineage that goes back to the 70s, that has shown incredible adaptability, is used in all kinds of business, from the tiniest to the top Fortune 10, being deployed in all kinds of exciting applications, from the tiniest cellphones to the largest supercomputers?

Why would Dick prefer to miss such a party?