I was reading scrollback on irc this morning, where a number of my students were discussing the unit tests for the webvtt project we’re doing this term. The main issue was that Visual Studio didn’t seem to provide the equivalent of our autotools build system’s `make check‘, that is, it can’t run all our tests and report back. Various solutions were discussed, some sensible, some less so.
Our autotools build actually works in Windows; you can `make check‘ to your heart’s content. The real issue here is, in my opinion, an unhelpful (I would go so far as to say ‘harmful’) reliance on Visual Studio. I make this bold claim because I was once in the same position. I can remember very well being wholly, and completely dependent on Visual Studio for just about everything I did as a programmer. And why not? Visual Studio is an amazing tool, right?
The longer I’ve programmed, the more I’ve come to see it as a trap. Not because it costs money, or because Microsoft makes it, or because it isn’t open source. I’m writing this blog post on a Mac, so I’ve already made my peace with pragmatism over Free as in Open. No, the trap of Visual Studio is being able to do only what Visual Studio can do, which seems like a lot, until you need to start doing things it can’t do, or worse, things it doesn’t want you to do.
I spend much of my time training new developers, and what I’m going to say will seem to run counter to the teaching of my colleagues. I want to be clear that I think you should learn how to use Visual Studio, if for no other reason than to learn how its debugger works. While you’re learning and using that debugger, understand what’s happening; understand that as a programmer you have a set of needs, and debugger is one of the main ones. Now spend some time with Visual Studio’s editor. It’s pretty good. While you’re doing this, understand that you’re using an editor, that this is another of the fundamental needs you’ll have for your entire career.
Take an approach to using Visual Studio that makes you aware of its constituent parts, and less as a monolithic whole. Why should you do this? It’s important to understand that you need various kinds of development tools, from editors to debuggers to compilers to linkers (quick, what is the name of the compiler and linker on Windows?) to static analysis tools of all kinds, and that Visual Studio provides some of these. It does not provide them all. Not by a long shot.
When this isn’t done, and Visual Studio is viewed as a whole, as a development platform, as the way I write code, a number of immediate consequences follow. First, the only kinds of programs you’ll write are those which Visual Studio can produce. In essence, your platform isn’t even Windows any more, it is Visual Studio. Want to work on OS X? What about Linux? What about embedded systems? What about gaming consoles? The scope and scale of your work as a developer becomes the answer to the question, “Does it run Visual Studio?”
If, on the other hand, you start to understand Visual Studio as a set of tools, and more, a set of replaceable tools instead of your go-to-dev-platform, interesting possibilities arise. You might notice, for example, that you’re writing code in C or C++, and this code is being compiled by cl.exe. What if you switched compilers? What if you used clang or gcc? What if you tried a different editor, one that also worked on other platforms, one that supported languages Visual Studio doesn’t seem to know about?
A number of things happen in that moment. Suddenly, and it is like opening a dam, a flood of new tools, languages, and platforms comes into scope. Maybe you’ve avoided trying some new language or tool that others are raving about, putting it off because it didn’t seem to fit into the world-view that Visual Studio provided. Don’t tell me you haven’t because I know it to be true–I used to do this all the time. If your choice of tooling, platform, language, etc. begins with a question about Visual Studio, you are missing out already.
And what am I advocating instead of Visual Studio? Should you do what I do? Probably not. I use the command line and emacs for everything, and there are probably better options for someone starting today. Whatever you pick, be aware of the limitations your choices impose on you. I still use emacs because it’s important to me to be able to SSH into remote boxes and work identically to how I work locally. I also choose to only work with tools that work on Windows, Mac, and Linux, so I can be productive everywhere. If I was starting today, I’d probably use Sublime.
It doesn’t matter what you use, and the best programmers I know change their tools and platforms all the time, making decisions based on project needs vs. what their old tools can do.
You should use what works until it doesn’t, and then move on to other things. Don’t be nostalgic. Your life as a programmer will involve constant changes in languages, tools, and platforms, and if the only thing making that decision for you is Visual Studio, you will quickly lose the agility you need to stay relevant in the industry.
4 Comments
I use whatever tool is most appropriate for the job. Is it java, then eclipse is my weapon of choice. Large PHP projects are also managed with eclipse, for smaller ones I use vim. I use visual studio for some .NET programming, which I rarely do. Everything else is vim, and make. Even LaTeX…
But this highlights one of the most important skills of a developer: knowing your tools, and which one is right for the job. Not only in terms of editors or compilers, but also with respect to libraries and languages.
I had to laugh when you mentioned Sublime Text, because I just yesterday tried to see if I could switch to ST2 from Eclipse (for Java). Eclipse has spoiled me too much, even with simple things like automatic compilation. For web development, though, ST2 is awesome!
For doing heavy desktop programming, perhaps in C++, C#, or just plain C, Visual Studio would be my first choice.
IDEs are tools rather than toolboxes, though some try to be everything for everyone.
I don’t want to jump in and say “OH IN OUR DEFENSE X, Y, Z, θ, γ, ε!!” or anything, but I think the general tendency is to agree. At least most of us seem to be using Visual Studio as a convenience (largely because of the debugger), while using the autotools build system for most of everything else.
On the other hand, being a library, it’s likely that some developers WILL be stuck using Visual Studio, or Xcode, or some other package that can’t figure out what to do with autoconf/automake/shell scripts, and it would be nice for us to provide a usable build system for them that would allow them to integrate the library into projects for their IDE of choice. An example of a desire to do this was an attempt at integrating the BTStack library directly into the Xcode project for the NexJ stuff, and ran into some great difficulty. It’s not so much about being “tied to Xcode”, so much as it’s about ease of use and integration.
Anyway, having said that, I think it’s actually pretty good of Shayan to be concerned about the usability of the Visual Studio projects, and their ability to do everything/most of what the autotools buid can do. Not necessarily for his benefit, but for the benefit of potential users, I guess.
Visual Studio was on the new look and feel the public opinion is that no work has been happening except the icons and colors have changed. For doing heavy desktop programming, perhaps in C++, C#, or just plain C, Visual Studio would be my first choice.
2 Trackbacks
[...] this article http://vocamus.net/dave/?p=1562 by david.humphrey, published on January 09, 2013 at 06:01PM. Share this:StumbleUponDiggRedditLike [...]
[...] Visual Studio considered Harmful. Or any other tool in your toolchain. You should be able to swap any bit up for one of similar functionality. The number of Eclipse programmers absolutely dwarfs the number of Java programmers. [...]