I am not sure I can agree with the article. By hiding so many aspects of what a program is made of, Microsoft did a disservice to C programmers. Visual Studio programmers that can write a makefile are not many and, by hiding the gory details inside an IDE, Microsoft created - and enjoyed - a good excuse for, if not creating gory details, at least allowing them to exist and thrive. The recent "embrace" of functional programming is too little, too late.
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.
Yeah I miss the days of programming on linux, having my code run on one distro but not the next.
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>
> Visual Studio programmers that can write a makefile are not many
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.
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.
You write code to make sellable products and every avoidable complexity, every thing you don't understand in your code or build system will eventually come back as increased cost when you need to extend, adapt it to the next Microsoft OS or simply debug it in an environment that looks like what your clients use.
Of you don't understand your build system, you really don't know what you are shippin.
Have you ever use Visual Studio or written a production app in C#?
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?
I have used the Visual Studio family from 1997-ish to 2001 (VB, ASP/VBScript and C) and then, again in 2002 (C for WinCE) and 2004/2005 (this last time, with C# for IIS), so, I would say, I have used it quite enough. I have also used NetBeans since the time it was called Forté and Eclipse for Java/J2EE/J2ME. I find they are all at the same level in terms of debugging, with some advantage to the Sun complete toolset when running under OpenSolaris and when you want to optimize your C code for multiprocessors.
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.
> 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.
How does knowing makefiles help you understand your build system if you're using VS? You do realize that it doesn't use Makefiles (at least, not by default).
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.
A VS project is, more or less, a makefile with a little information around the edges.
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?
Whoa, it is most definitely not a makefile. Unless by a makefile you simply mean any file that has dependency information. If that's your claim, then I'd argue that every VS build engineer I've ever met understands "makefiles".
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.
> every thing you don't understand in your code or build system will eventually come back as increased cost
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.
I think the biggest point is that it's much harder to find a developer that understands the build mechanism of a project now than it was, say, by the mid-80's. We are doing more complex builds and VS makes it easy to fall prey to a huge pile of complexity where there should be a much smaller, addressable, tangle of dependencies.
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.
So if I compiled my C# applications from the command line using a project file which I wrote from scratch in an XML editor, would that suddenly give me a better understanding of "how my code works?"
You are confusing cause with effect. If you did understand what is going on in your build process, you could write a makefile for it. Since you don't, you can't. It has absolutely nothing to do with command lines or XML editors (and, while we are at it, if your answer is using XML, you are asking the wrong question).
And the C# build process is very simple. It should be easy to understand.
One can learn the syntax of standard make Makefiles in about two minutes, without cracking open the manpage for that.
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.
Visual Studio programmers that can write a makefile are not many
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.
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 mostly taste, really. You can do almost everything you do in one environment on the other. What I dislike most in Windows is the standard APIs and datatypes. Not only they "feel" more complicated, the naming and casing conventions are plain ugly. I will dig up some examples from my WinCE days.
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.
Yeah, that seems to be what most of the Windows bashing comes down to: taste. Not that there's anything wrong with subjective preference, I just usually see it stated as if it were simply a known fact.
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.
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.