The Lesson from BASIC, Visual Basic, and VB.NET

This week Microsoft announced that VB.NET would receive no enhancements. In effect, Microsoft has announced the death of VB.NET. And while some developers may grieve over the loss of their favorite language, we should look at the lesson of VB.NET.

But first, let's review the history of BASIC, the predecessor of VB.NET.

BASIC has a long history, and Microsoft was there for most of it. Invented in the mid-1960s, BASIC was a simple interpreter, designed for timeshare systems and people who were not programmers. The major competing languages, the programming languages one could use instead of BASIC were FORTRAN and COBOL. BASIC, while less powerful, was much easier to use than any of the alternatives.

Small home computers were a natural for BASIC. Microsoft saw an opportunity and built BASIC for the Apple II, Commodore's PET and CBM, Radio Shack's TRS-80, and many others. Wherever you turned, BASIC was available. It was the lingua franca of programming, which made it valuable.

BASIC was popular, but its roots in timeshare made it a text-oriented language. (To be fair, all other languages were text-oriented, too.) As computers become more popular, programmers had to manipulate hardware directly to use special effects such as colors and graphics. Microsoft helped, by enhancing the language with commands for graphics and other hardware such as sound. BASIC remained the premiere language for programming because it was powerful enough (or good enough) to get the job done.

Microsoft's Windows posed a challenge to BASIC. Even with its enhancements for graphics, BASIC was not compatible with the event-driven model of Windows. Microsoft's answer was Visual Basic, a new language that shared some keywords with BASIC but little else. The new Visual Basic was a completely different language, even more powerful than the biggest "Disk BASIC" Microsoft ever released. Microsoft's other language for Windows, Visual C++, was powerful but hard to use. Visual Basic was less powerful but much easier to use, and it had better support for COM. The ease of use and COM support provided value to developers.

Microsoft's .NET posed a second challenge to Visual Basic, which was not compatible with the new architecture the .NET framework. Microsoft's answer was VB.NET, a redesign that looked a lot like C# but with some keywords retained from Visual Basic.

For the past two decades (almost), VB.NET has been a supported language in Microsoft's world, living beside C#. That coexistence now comes to an end, with C# getting upgrades and VB.NET getting... very little.

The problem with VB.NET (as I see it) is that VB.NET was too close, too similar to C#. VB.NET offered little that was different (or better) than C#. Thus, when picking a language for a new project, one could pick C# or VB.NET and be assured that it would work.

But being similar, for programming languages, is not a good thing. Different languages should be different. They should offer different programming constructs and different capabilities, because the differences can provide value.

C++ is different from C, and while C++ can compile and run every C program, the differences between C++ and C are enough that both languages offer value.

Python and Ruby are different enough that both can exist. Both offer value to the programmer.

C# and Java are close cousins, and one could argue that they too are too similar to co-exist. For this case, it may be that the sponsoring companies (Microsoft for C#, Oracle for Java) is enough of a difference. For these languages, the relationship with the sponsoring company is the value.

But VB.NET was too close to C#. Anything you could do in VB.NET you could do in C#, and usually with no additional effort. VB.NET offered nothing of distinct value.

We should note that the end of VB.NET does not mean the end of BASIC. There are other versions of BASIC, each quite different from VB.NET and C#. These different versions may continue to thrive and provide value to programmers.

Sometimes, being different is important.

The types of standards for programming languages

A programming language must have a reference point, a standard, which is used to decide what is in the language and how it behaves. There are different ways to build and distribute this standard:

Independent committee In the past it was an ANSI committee, today it is an ISO committee. The committee, independent of vendors, defines the language and publishes the standard. Anyone can create an implementation of the standard; the committee often provides tests to verify compliance with the standard.

Benevolent dictator A single person decides what is in the language and what is not. He (it is usually a male) runs a team of people who develop the implementation and publish it. The implementation is usually open source. Tests are used by the development team to ensure compliance with the standard. There may be more than one implementation published; the development team may publish advance and legacy versions, and other individuals or companies may publish their own implementations.

Corporate closed source A corporation designs a language and builds and publishes it as a product. The language may change at any time to suit the needs of the corporation. Other entities can publish "clones" of the language but they do not have access to the source code.

Corporate open source A corporation designs a language, builds and publishes it as in the "closed source" model, and then provides the source code as open source. Other entities can use the source code. The language can still change to suit the needs of the corporation.

These four models cover almost all programming languages. Looking at some popular programming languages, the grouping is:

Independent committee: FORTRAN, COBOL, C, C++, SQL, Ada, JavaScript

Benevolent dictator: Forth, Pascal, AWK, Perl, Python, Ruby

Corporate closed source: APL, PL/I, Visual Basic, Delphi, VB.NET, SAS, Objective-C, Objective-C++

Corporate open source: Java, C#, Swift

Some languages change over time. For example, BASIC started as with the "benevolent dictator" model, but Microsoft's success changed the dominate form to "corporate closed source". Java started as "corporate closed source" and is shifting to "corporate open source".

What's interesting is that the languages governed by independent committee tend to have longer lives. Of the seven languages (Fortran, Cobol, C, C++, SQL, Ada, and JavaScript) all but Ada are in use today. (Yes, Ada may be in use somewhere, on some obscure legacy project, but that is true of just about every language. Ada is, for all intents and purposes, a dead language.)

Languages governed by a benevolent dictator fare less well. Python and Ruby enjoy success today, while Perl declines from its previous popularity. Forth, Pascal, and Awk are used rarely and I see no activity, no growth to those languages.

Corporate languages enjoy popularity ... as long as the corporation pushes them. APL and PL/I, developed by IBM, are in the "dead" list. Microsoft's Visual Basic is dead and VB.NET (purported to be a successor to Visual Basic) is languishing. Delphi is used only in legacy applications.

I expect that with Apple's introduction of Swift, Objective-C and Objective-C++ will drop to "dead" status. The Mac OS X platform was the only place they were used. The current index at tiobe.com confirms this drop.

What does all of this mean? For anyone developing a large, long-term project, the selection of a language is important. Committee-governed languages last longer than other languages.

Notice that Java is not a committee-governed language. It is managed by Oracle.

... or the few

Software development is maturing.

I suppose that is has been since the Eldar days, when programming meant wiring plug-boards. Programming languages and tools have been changing since the first symbolic assemblers.

There have been two types of changes ("improvements"?) for programming: changes that benefit the individual programmer and changes that benefit the team.

Changes that benefit the individual include:

 - FORTRAN
 - Unix, which let a programmer use many tools and even build his own
 - Integrated development environments
 - Interactive debuggers
 - Faster processors and increased memory
 - Unit tests (especially automated unit tests)
 - Diagnostic programs such as 'lint'
 - Managed environments with garbage collection (eliminating the need for 'delete' operations)
 - Early forms of version control systems

Changes that benefit the team include:

 - COBOL, with its separation of concerns and support for discrete modules
 - Early operating systems that scheduled jobs and managed common resources
 - The 'patch' program, which allowed for updates without transmitting the entire source
 - Network connections (especially internet connections)
 - Code reviews
 - Distributed version control systems
 - github

One can argue that any of these technologies help individuals and teams. A better debugger may directly help the programmer, yet it helps the team by making the developer more productive. Some technologies are better for the individual, and others better for the team. But that's not the point.

The point is that we, as an industry, look to improve performance for individuals and teams, not just individuals. We look at teams as more than a collection of individuals. If we considered teams nothing more than a group of people working on the same project, we would focus our efforts on individual performance and nothing else. We would develop better tools for individuals, and not for teams.

Some languages are designed for teams, or at least have aspects designed for teams. The Python and Go languages have strong ideas about code style; Python enforces rules for indentation and Go rules for bracket placement. They are not the first; Visual Basic would auto-space and auto-capitalize your source code. That may have been a function of the editor, but since the editor and interpreter were distributed together one can consider the action part of the language.

Python's indentation rules, Go's bracket rules, and Visual Basic's auto-capitalization are all beneficial to the individual programmer, but they are more beneficial to the team. They enforce style upon the source code. Such enforced style ensures that all members of the team (indeed, all members of those programming communities) use the same style. Programmers can more easily move from one project to another, and from code contributed by one person to another. Some programming teams () using other languages) enforce local styles, but these languages have it built into their DNA.

Enforced style is a move against the "cowboy coder", the rebel programmer who insists on doing things "his way". Programming languages are not a democracies -- team members don't get to vote on the rules of the language that they are using -- but it is a step towards government.

Let's count that as maturation.