The Role of the IDE in Programming Languages

Email.Email weblog link
Blog this.Blog this

Jose Mojica
Jul. 14, 2002 10:41 PM

Atom feed for this author. RSS 1.0 feed for this author. RSS 2.0 feed for this author.

I was teaching Visual Basic .NET last week and I jokingly made the following statement about intellisense: “I believe that without intellisense .NET programming would not be possible.” I said that after typing something in the order of System.Runtime.Serialization.Formatters.Binary.BinaryFormatter, which caused a few students to chuckle and say, “There is no way I will ever remember that.” I told them that the only way I remembered that was because of intellisense. I had memorized System.Runtime and intellisense helped me remember Serialization, then Formatters, then Binary, etc.

I was joking at the time but then I started thinking about the statement. How successful would a class hierarchy in which classes are buried five namespaces deep be without features like intellisense and the object browser? Don’t take me wrong, I love the way the classes are grouped in .NET and namespaces are definitely a good thing, but would we be able to be productive without features like intellisense, the object browser, and even dynamic help to a certain extent?

Let’s go back to the days of the win32 programming. How did we know back then the name of the right API to use? I think in those days I relied heavily on the sample code and the help files, and just text searches. I remember opening header files and searching for anything that had a keyword remotely similar to what I was looking for. But being able to find the correct function to use in those days, using only the index in the help and text searches, was only successful because the function names described the purpose of the function in one phrase. Take for example a fictional function like SerializeWithBinaryFormatter. I might have been able to find such a function if I had searched the header files for the key words Serialize and Binary. With object-oriented class hierarchies functions are often named more simply like Serialize. However, a quick search through the object browser reveals that there are at least 40 versions of “Serialize” and that is not taking into consideration functions that use Serialize as part of a bigger name. Take a word like Open. If I did a search in the object browser for anything that contained the word Open I would probably find hundreds of entries with that word. How could I find the class name that contained the particular Open I wanted?

This train of thought made me think about the role of the features in the IDE, not only in relation to productivity but as things that make the language itself successful. Take for example Visual Basic. I would say that the IDE played a tremendous role in the success of the language. The form designer made it possible for us not to have to remember fifty or so API functions. So the form designer was a good thing because it enabled a developer to represent API functions graphically, but is the form designer part of the language or is it a feature of the IDE? Could VB have been successful without it? Suppose that the form designer had been a wizard instead that generated source code for creating a window. I remember back in the old days, Quick C for Windows. Quick C had a wizard that enabled you to design some aspects of a Window and would then generate some source code to replicate the Window. Now this was, as far as I remember, one-directional. Once you generated the code, if you modified it, there was no way to get back a visual representation. As great as the Wizard was I never used it much because it was only good at the beginning of the app and only really for learning purposes. In the very least the wizard needed to be bi-directional. The form designer in .NET is primarily a code generator, but it is bi-directional. If you change the code, the changes are reflected visually. But it is the code that really creates the form, not the visual picture. In fact it is possible for a developer not to use the visual designer at all to create forms. The question is, is this the same as the form designer in previous versions of VB in which the only way to construct the form was visually? How many developers are going to create rich forms without a visual designer and is having the code available really an advantage? Let’s take another small feature. In VB 4 through 6 if you wanted to create a class, you asked the IDE to add a Class Module to your project. The IDE would open a window for you to type in your code. The IDE window represented the class itself. One IDE window was equal to one class. Now in VB.NET you can write as many classes as you would like in a single file. The question is, is this a good thing being able to write many classes in a single file? I think that we do not understand the relationship that the IDE and the language have at times and we focus on the written language as though that is the primary source of productivity and consider IDE features as merely frosting on the cake. What do you think?

Jose Mojica is the author of the C# & VB.NET Conversion Pocket Reference and an instructor and researcher at DevelopMentor.