(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
model.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.