(This guest blog was written by Nick Harrison, March 2017.)
In college, I did everything in UNIX. On UNIX, everything was centered around programming. Of course, you probably had to be a programmer to get anything done or at least appreciate it. The big debate of the day was the merits of vi vs emacs. After much deliberation, I settled on emacs. Despite its power, vi was just a bit too cryptic for me. Emacs was very powerful, still quite cryptic, but had nearly endless options for customization.
You could start up emacs and stay there all day. It didn’t matter whether you wanted to run a command shell, query a database, read email, or even browse the web, there was no reason to leave emacs. Regardless of the type of file you were editing, there was a custom mode available to help with editing that file. Whether it was the password file, Fortran, lisp, C, C++, HTML, SQL, Eiffel, or something else, there was a language-specific editor mode ready to help with syntax highlighting, indention support, matching parenthesis, and more. If you weren’t doing actual “work,” you could get diversions with such distractions as Life, Towers of Hanoi, or Doctor. It had everything!
To make it even more enticing, emacs was available anywhere you wanted it to be. You could find it on any flavor of Unix; I used it on VAX/VMS, Data General, Windows, even Mac. Wherever you found yourself, emacs was there and pretty much worked the same way as anywhere else in all its cryptic glory.
As I left college, I took emacs with me everywhere I went. I stayed in Unix land with brief forays over to Windows. I brought emacs with me on these incursions and Perl, working to make this new land more Terre Familiar. You know the expression, “If you are good with a hammer, everything looks like I nail.”
Eventually I had to delve into the world of Visual Basic. I searched and found visual basic mode.el. This of course was the ultimate “square peg round hole” hack, but I kept going. Actually, I kept trying to ignore Visual Basic specifically and Windows in general. I tried to keep making Windows as Unix-like as I could and cast as many problems as possible as Perl scripts. I was pretty creative at times.
Then came DotNet. DotNet solved all the problems I ever saw with Visual Basic. VB.Net felt more like a “real language,” and C# felt natural and intuitive. It felt like the obvious heir apparent to C++. Even from its original version, the DotNet framework was fully flushed out Much more so than you would typically expect for an initial release. My reasons for clinging to the past were rapidly disappearing, and just in time. Stringing together my hacks and fitting everything into the molds of beloved, bygone days was beginning to fall short.
So in January 2002, I jumped on the DotNet bandwagon with the latest beta and the official .1.0 when it was released in February. I would like to say that I got with the program and never looked back, but old habits die hard. While I was testing the waters with Visual Studio, I also experimented with csharp-mode.el, but this flirtation was short lived. Despite everything that I knew about emacs, despite how familiar I was with emacs and all that it could do, Visual Studio was simply a better environment for editing DotNet code.
For many of my friends, I had ventured into heretical territory. Friends jokingly called me Saruman, a reference to how the wizard from Lord of the Rings turned on his friends to serve Sauron. It was quite the scandal.
Visual Studio from its earliest days knew all about editing C# code and VB.Net code. Support was pretty good for HTML and very good for CSS. There was some support for editing SQL, but even less for editing JavaScript. These deficiencies were annoying but would improve over time. In fact, it wasn’t always apparent how little support there was for JavaScript until future versions showed just how much better support could be.
Most of my favorite features from emacs show up in Visual Studio. Language sensitive editing modes. Visual Studio detects what you are editing and optimizes the editor accordingly. The editor behaves differently if you are editing HTML than if you are editing C#. When you are editing VB.Net, VB keywords are highlighted. When you edit C# code, C# keywords are highlighted. When you format code, it is formatted appropriately based on the current language. Regardless of the language you are using, the syntax and semantics of that language is used. This seems obvious today and is often taken for granted, but this was and is a big deal.
There are other great features that were first seen in emacs that are now firmly baked into Visual Studio. Many of these features you probably never thought of as originating from emacs. Incremental search is a subtle feature. It is so intuitive that is seems obvious and natural. We don’t even think about it. We expect incremental search and its close relative auto complete, search suggest drop down lists, etc. In Visual Studio, simply type Ctrl+I and start typing what you want to find. As you type, you are moved in the file to the first occurrence of what you have typed so far. You can quit typing as soon as you find what you are looking for. The time savings from this simple change adds up quickly.
Closely related to incremental search is IntelliSense. This is an even bigger time saver for developers. IntelliSense allows you to easily complete the word that you are typing, whether that word is the name of an object, a reference to a member of an object, or the parameters to a method. This means less typing for the developer. It also means that you don’t have to remember all the details. You don’t have to keep track of how these things are spelled or how they are cased. You just start typing the beginning of the name and then press Ctrl+Space to activate IntelliSense. This allows you to write code faster with less typing which means less opportunities for you to spell something wrong or worry about which letters are capitalized and which are not. It also makes it easier to learn about the objects you are working with and their members. All wins for the developer.
IntelliSense brings more to the table than simply listing out the members in the objects you are using. If a library is compiled with the /doc switch, any XML comments supplied in that library can be incorporated into the details exposed with IntelliSense, so if you create a library and add XML comments explaining the parameters to a method in one of your classes, the descriptions from these comments will be displayed to anyone using your library. This takes developer training to a whole new level and further boosts developer productivity. The documentation you include in your library is readily available to anyone using the library as they are using the classes and methods in your library.
Now, with Visual Studio 2017 and Roslyn, developer productivity is pushed to even higher levels. Using Roslyn, we can get real time analytics on our code as we type it. Anyone can write extensions using Roslyn to flag potentially problematic code as the code is being written. Not only can you flag code as being problematic, you can also provide a quick fix. The extension can rewrite the code to fix any problems found. Want to encourage developers to check if an IEnumerable has any elements matching some criteria instead of counting how many times some specified criteria are met? This can easily be caught and corrected in an extension. Want to encourage developers to use LINQ instead of a for each loop with an embedded if statement? This can be detected and corrected in an extension. Want to create a compile error if a method has too many parameters? You can easily create such an extension.
So yeah, I clung to the familiar past and resisted change for a long time, but in the end Visual Studio provides a compelling developer experience that is tough to beat.
