A Heterogeneous Developer

As of December 2011, this topic has been archived. As a result, it is no longer actively maintained. For more information, see Archived Content. For information, recommendations, and guidance regarding the current version of Internet Explorer, see Internet Explorer Developer Center.

Robert Hess
Microsoft Corporation

April 9, 2001

There are few programmers out there who know only a single language. It is common to find people who pick up several different computer languages during their movements from one job to another, or from one computer environment to another. It always seems like there is a certain language that is the defacto standard for any given project. And then there are the "hobbyist" programmers who pick up different languages just for fun, and not as part of any job requirement.

I personally take a certain pride in the number languages I not only know, but also have been paid to program in. From the mainstream languages of C, C++, Fortran, and COBOL, to the more esoteric and less known languages of FORTH, Modula-2, and Postscript (for those of you who didn't know, yes, Postscript is a programming language, based on Forth, that is specifically designed for printers). One of my first programming jobs was working for the State of Washington during summer break from the university. I interviewed with them and we talked about my programming background, about database design, and various other topics, and they told me to show up to work the following Monday. Almost as an afterthought as I headed out the door, I asked them what language I'd be programming in. "Cobol" was the response… Ooops, that's one I'd never done before, but a quick phone call to a buddy of mine, and I had a Cobol book that I could study over the weekend. By Monday, I was proficient enough that nobody was the wiser.

As the years have progressed, I've had fun picking up various other programming languages, sometimes just for little one-off projects, or experiments on the side, but other times for actually doing some serious coding in.

Some of my more modern programming experiences have given me a better understanding of the whole application development landscape. I remember the very early days of "Visual Basic." I would kick the tires a little bit, write some rudimentary programs just to find out what I could and couldn't do in this new development environment. It was tantalizing. This simplified visual programming environment was quite interesting. I had used a few other advanced visual development environments before, but Visual Basic® presented a more comprehensive simplification that made it appealing. However, at the same time there were certain areas where it felt that Visual Basic was, uh… protecting me from. The traditional Windows API was hidden from me, as was the Message Loop, and Window Handles, and Device Contexts. As a Windows developer, I was comfortable with these concepts and it felt awkward not to have them available.

Over the years, the strength and capabilities of the Visual Basic development environment have grown to the point that virtually anything that you can do in a C/C++ program, you can now do in Visual Basic. However, many of the core concepts of interfacing with the underlying OS (Windows®) are still significantly different between the two development environments.

More recently, the Web has brought about a significantly new model and concept in development. I'm not sure how many of the rest of you share my own experiences here, but I find that I am often switching back and forth between VBScript and JavaScript; more so than I have ever switched back and forth between two different languages before. It is a relatively straightforward scenario to be writing one project in one language, and another project in some other language. Or perhaps even writing the main EXE using Visual Basic and the DLLs using C/C++. However, on Web pages it can often be common to be writing VBScript code in one portion of the page and JavaScript code in another. Sometimes this is done due to some inherit benefit that one of these scripting languages might have over another, but it is also often due to some existing code I have written in one language that I want to be able to use in a page I am developing using the other language. It was just recently that it struck me how desirable this ability to mix and match development was. Particularly because I wasn't just intermixing function calls, but I was even intermixing access to global variables, regardless of which language they were defined in. But of course a problem with Web-page programming is that the languages aren't even second-class citizens, but third, or perhaps even forth class when compared to all of the capabilities available in C, C++, or VB.

So when the new .NET development environment came out, and one of its prime tenets was that all languages were not only first class citizens, but also that language interoperability was a core design goal, it was clear to me that this was an excellent approach at providing a rich and full-featured system in which to develop applications. As a programmer, I love having the opportunity to discover and develop in new languages, but I also feel cheated when one of these new languages can't provide access to all of the features that I've been using in other languages. So with .NET, we'll not only be able to choose the best programming language for the task at hand, but hopefully we'll also find some of the more esoteric languages coming back into fashion. Anybody working on a FORTH for .NET that I could mess around with?