How Microsoft is changing the programming world

I write C# code in Visual Studio every day at work, and I've got some thoughts.

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.

> I find your willingness not to understand what you are doing quite amusing

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.

No, it's much, much better. For one, there's no such thing as the Linux world. "The Linux world" is everything else in this context, which includes Java, Ruby, Python, Web, C, and dozens of different technologies. With the exception of the Java community, none of those communities come even close to being as insular. None. Every Ruby and Python dev I know has at least checked out Java and C# before going back to their primary language. Every Java developer has dozens (too many, perhaps) of choices for libraries, app servers, and even other language that run on the JVM. Even PHP developers have some notion of other tools used for web development (generally Flash and Flex). It's true that many of these communities might not have much exposure to deeper subjects of more dubious relevance, like CS theory and classic FP languages like Lisp, but they at least know and understand that there are other choices out there. Meanwhile, most MS-only devs don't even know about Apache, SVN, or even the notion of using a text editor as your primary development environment.

But why is being parochial in an MS world a bad thing? People are upset not because that point was made but how that point was made. I'm a MS developer and although I do know other languages I don't necessarily see it as a big advantage. It's basically a question of breadth vs depth. The truth is that the MS stack is deep enough that a developer can dive in and few will ever hit the bottom of that pool.

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.

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

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