Thursday, October 14, 2004
« Web site about .NET languages | Main | One way SOA is fundamentally new and dif... »

Earlier this week I spoke at the Vermont .NET user group in Burlington, VT. I count myself fortunate to have been in VT in early October, as the fall colors were out in their full splendor. Many parts of the world have their legends, and one of Vermont’s is the majesty of the fall colors. I have got to say that in this case the reality is at least as good as the hype, and probably better. I saw views that were simply breathtaking, and the day was cloudy! I can only imagine how impressive it would be under bright sunshine.

 

At the end of my presentation to the user group a gentleman (who’d driven all the way up from southern Connecticut!) asked whether I thought VB or C# was the better language. This is not an uncommon question, and it has been a perennial issue since .NET was in alpha release. Normally I tend to brush the question off by either answering with the typical Microsoft wishy-washy stuff about culture and freedom of choice, but it turns out that I’ve been giving this issue quite a lot of thought over the past few months and my views have been changing.

 

To fully understand my perspective, you need to realize that I spent many years working on DEC VAX computers using the VMS and then OpenVMS operating system.

 

It was, by the way, renamed to OpenVMS as a marketing response to the “open” Unix world. Yes, the same Unix world that is now being eaten alive by the more open Linux world. The humor to be found in our industry is often subtle yet truly impressive.

 

One of the key attributes of VMS was language neutrality. The operating system was written in assembly and FORTRAN, and there was some small benefit to using FORTAN as a programming language over other languages. However, other languages such as Pascal and VAX Basic were adapted to the platform and were easily equals to FORTRAN for virtually any task. In fact VAX Basic was often better, because it had taken language concepts from Pascal, FORTRAN and other languages and was basicall a powerful hybrid with the best of all the other languages. All the OS-level power of FORTRAN with the elegance of Pascal.

 

As a side note, the only second-class language I ever encountered under VMS was C++. It turns out that C and C++ were/are way too tied to the stream-based Unix world-view to be good general use languages across multiple platforms. Things that were trivial in any other VMS language were insanely difficult in C++, especially as they related to any sort of IO operation. Since most programs do some IO, this made C++ really nasty…

 

For some years I was a manager in the IT department of a manufacturing company. At that time one of my key hiring requirements was that a developer had to know at least two languages. Knowledge of just one language was an absolute sign of immaturity and/or closed-mindedness which would lead to a dangerous lack of perspective.

 

Once Windows NT and Visual Basic came out I started migrating from VMS to Windows – basically following David Cutler (the creator of both VMS and Windows NT).

 

In many ways Windows NT lost a great deal of the language neutrality offered by VMS. The primary language of NT was C++, and the language warped the OS in some ways that made it more like Unix and less like VMS. The idea that FORTRAN or Pascal would be comparable to C++ in Windows was (and is) absurd. This lack of language neutrality certainly slowed the adoption of NT as a primary development target for the first several years of its existence. Just look back at the books and code of the early 90’s – writing even simple applications was ridiculously complex. Especially when compared to more mature environments like Unix or OpenVMS.

 

Enter Visual Basic (and a whole host of competing products). Vendors, including Microsoft, Borland, IBM and others rapidly realized that C++ would never be the vehicle for most people to develop software on Windows. Many languages/tools were created in the early 90’s to make Windows actually useful from a business development perspective. The common theme in all these products was abstraction. Since the Windows OS itself wasn’t language neutral, every one of these tools added an abstraction layer of some sort to “get rid” of the Windows OS and provide a platform that was more programmable by the language in question.

 

In the end three tools emerged as being dominant. In order of popularity they were Visual Basic, Powerbuilder and Delphi. While each of these had their own abstraction layers to make Windows programmable, there was no commonality between their abstractions. And C++ had grown its own abstraction too – in the form of MFC (and I should mention OWL as well I suppose). Even so, C++ was not competitive with VB or Powerbuilder, though it may have been more popular than Delphi on the whole.

 

In an effort to shore up the Windows OS, Microsoft created COM. In many ways this was an attempt to provide some common programming model akin to what we had in OpenVMS in the first place. And COM had its good points – chief among them being that there was finally some common programming scheme that would work across languages. Sure, each language out there could mess up and create components that weren’t interoperable, but at least it was possible to interact between languages.

 

Really this is all we asked. Under OpenVMS too, it was possible to violate the common language calling standard and create libraries that couldn’t be used by other languages but yours. Most people weren’t dense enough to do such a thing of course, because the benefits of cross-language usage were too high. Part of this, I think, flowed from the fact that most OpenVMS developers worked in multiple programming languages as a matter of course.

 

In Windows COM development in the mid to late 90’s most people didn’t intentionally write components that could only be used by C++ or VB or whatever. The benefits of cross-language usage were too high.

 

There were two exceptions to this. The first were developers that only worked in C++. They’d often create COM components that could only be used by C++ through sheer ignorance. The second were developers that only worked in VB. They’d often expose VB-only types (like collections) from their components, making life difficult or impossible for users of other languages. In both cases, the developers simply didn’t have the perspective of working in multiple languages and so they had no clue that they’d written inane code. Incompetence through ignorance.

 

But COM had its limitations in other areas. With the advent of Java the limitations of COM became painfully apparent by contrast and Microsoft had to do something. They could have taken the Java route and created yet another platform that was language-focused like Windows or the JVM. Almost certainly this would have given rise to another round of VB/Powerbuilder tools that abstracted the platform into something that could support more productive business development. (you can see some of this belatedly starting in the Java world even today with things like Java Faces, etc.)

 

Fortunately Microsoft decided to go with a language neutral approach. Though on its surface .NET is very unlike OpenVMS, it has the common trait of language neutrality. Like OpenVMS, the neutrality has its limits, but it is pretty darn good. Also like OpenVMS, .NET did create a set of second-class languages (ironically including C++).

 

So here we sit today, working with a language neutral platform that actually has multiple viable languages. Like the languages on VMS, some of the .NET languages have runtime libraries, but by and large the focus is less on the language than it is on the platform. To me this is familiar territory, and I must say that it makes me happy in many ways.

 

It also means that this silly language debate is rapidly losing my interest. As a corollary, I am beginning to think that my hiring criteria from VMS is valid on .NET. Namely that a prerequisite for hiring a developer is that they should know at least two languages. Only knowing one language (such as C# or VB) means that a developer has a seriously limited perspective and will be far less effective than one who knows more than one language. Such developers are likely to be incompetent through ignorance.

 

And I’m not talking only about VB or C# specifically here. COBOL.NET or J# or any other language is fine. The point is that a language gives a person a perspective on the platform, and having only one perspective is simply too limiting.

 

A while ago I posted a list of VB features that I think should also be in C#. I got numerous comments from C# developers who obviously had no perspective. Many of the comments showed that they simply didn’t understand what they are missing. I pity those people.

 

Likewise, there are features of C#, J# and COBOL.NET that VB should incorporate. People who live entirely in the VB world would likely disagree, and I pity them as well.

 

The whole idea behind having a language neutral platform is to have multiple languages that compete and try new and innovative ideas. The whole idea is to compare and contrast and take the better ideas and improve each language over time.

 

And for this discussion to be meaningful I think we need to accept the reality of “language families”. Knowing both C++ and C# is generally meaningless, as they are in the C family. C, C++, Java and C# follow the same fundamental philosophy and so limit the perception of people who never branch into the rest of the languages.

 

If you only know one language or language family then your ability to compare and contrast language features is severely restricted.

 

Now I’m not saying that absolute mastery of multiple languages is required. That makes no sense. I am very good at VB. I am competent in C#, and with a bit of brushing up I can probably do a good enough job in FORTRAN, Pascal, Modula II, C, rexx, awk, DCL and a handful of other languages I’ve learned over the years.

 

The point is that knowledge is power, and in the case of languages this power comes in the form of perspective. And perspective provides flexibility of thought and improves your ability to do your job.

 

But the thing that scares me the most at this point is that C# is just VB with semi-colons. And VB is just C# without semi-colons. And Java is just C# with a different runtime library. How can we have language innovation when the majority-usage languages have such little variation between them? We desperately need some real innovation in at least one of these languages, because I can’t believe that C#, VB or Java are the best that the human race can come up with…

 

Thursday, October 14, 2004 5:45:41 AM (Central Standard Time, UTC-06:00)
I like your comment about sticking within the same family of language design is limiting in terms of the collective growth of the developer community. You should check out Ruby... I've played with it only a little bit, but you immediately see some pretty cool stuff that would be great to see in parts of the CLR and BCL.
Kris
Thursday, October 14, 2004 8:08:29 AM (Central Standard Time, UTC-06:00)
Excelent, excelent piece that I agree all the way through it. I also come from 6 years way back at Digital and a VMS background when Cutler was there. I also switched over with Cutler to NT. I really liked your analogy. I also get really incensed at the vain language wars in .NET (especially since many have no idea what they are talking about) and always maintained "It's The Runtime Stupid" (http://samgentile.com/blog/articles/1989.aspx) since 2002. I preached that to Julie's group and they really got it. I think I know the person from Conneticut. I have always encouraged my audiences to learn as many languages as they can. Myself, I have worked with over 20 and I like to think it gives me some perspective. Anyhow, see you at HDC!
Thursday, October 14, 2004 9:30:34 AM (Central Standard Time, UTC-06:00)
Just a teensy correction... I would consider Delphi to have been a bigger player than PowerBuilder. Delphi was not only useable for business software, but worked equally well for "tools". It also survived much longer... believe it or not there are still a lot of shops clinging to Delphi, and there continues to be new releases. It could also be argued that a great number of the core .NET FCL features (especially within System.Windows.Forms) trace their roots back to the Delphi VCL released in 1995.

It's probably just a difference of perspective, but I gotta defend my old "home turf". Old habits die hard!
Thursday, October 14, 2004 11:28:59 AM (Central Standard Time, UTC-06:00)
Sam has it right, but I think he's mistaking "runtime" for "libraries" in the historical sense. Innovation in this field has long been driven by libraries, not language changes. Innovations in VB3, 4 and 5/6 were really related to the jump to COM, although of course the language did change a bit. Same for VC++, which was driven by MFC, ATL, WTL and things like managed code and attributed programming nowadays. But C++ itself remained essentially static. I assume it's largely been the same with VFP.

Four years ago you could use the same *libraries* for C++ and VB and Delphi and VFP (all of which could consume COM) and so on, yet you were using different languages *and* different runtimes.

The great thing about .NET is the fact that it not only allows you to use the same libraries for a bunch of languages - you now also get to use the same *runtime* as well.

I really don't see this changing. The Last Great Innovation was .NET itself, C# and the changes made to VB to bring it up to .NET. I expect the only changes we'll be seeing in a long time will be related to the BCL/CLI and friends.
Thursday, October 14, 2004 1:42:20 PM (Central Standard Time, UTC-06:00)
Klaus, thanks for the correction, you are right. I should have been specific that its runtime + BCL that gives the language independance. The fact that there is one set of libraries no matter which of the CLR languages you use is truly powerful and innovative. No more MFC, ATL, WTL, Delphi prog model, VB6 prog model, etc. Its just one and equally available. I guess when I say "Its The Rumtime Stupid", I mean "Runtikme" to include CLR + BCL, but I should be more expilcit. Thanks.
Thursday, October 14, 2004 8:02:13 PM (Central Standard Time, UTC-06:00)
Watch out! With sentences like that last one, it's only a matter of time before the SmallTalk and LISP snobs come crashing through your comment door. ;)

While I'm always tickled to see someone come up with another language parser for IML, I believe that the best language advanced are usually *evolutionary* rather than revolutionary. The C# syntax has a long ancestry of C, C++, and Java. VB.NET (B#) is something almost, but not quite, completely unlike its VB/QBASIC/GWBASIC/BASIC heritage. I don't need 15 other syntaxes to define an object or call a method, I need more language features that extend what I already know.

Another important point to make: more and more, declarative languages are taking over where traditional languages have reached their efficiency limits. .NET's support for XSLT and RegEx, database support for SQL, browser support for XML/(X)HTML/CSS, and Longhorn's coming XAML, all prove the point that some of the best stuff of programming right now is embedded within string variables of traditional languages.

Frankly, while there are certainly language improvements that could be made to all .NET languages (example: Eiffel's design-by-contract), I'd rather see more movement in IDE and compiler integration of various declarative and functional languages into the same syntax-colored, Intellisense editor space and source files, using smart context-switching and partial class compilation. As much as ASP/ASPX are derided for people abusing it by not separating concerns, combining languages into a single file is an extremely powerful programming concept, one that has been a compelling feature of most web-based scripting languages over the last decade.
Sunday, October 17, 2004 6:24:19 PM (Central Standard Time, UTC-06:00)
There are some languages that give a different perspective, but: they have been slow to arrive, don't seem to have a large following, are abandoned...

1) F# still new, so defer judgement.
2) S# (haven't looked for a while, not sure where it stands).
3) JScript.NET (C--). Those protoptype based classes can be useful at times! VS support poor.
4) Mondrian. Was still a research language last time I looked.
5) Eiffel. Who is using it?
6) IronPython. This could be really interesting.
7) Delta Forth was a demonstration.
...

Has anyone here got a handle on why the alternate languages are not developing faster?
Monday, October 18, 2004 2:47:16 PM (Central Standard Time, UTC-06:00)
You should also check out www.dotnetlanguages.net - a site devoted to discussion of all .NET languages.

Rocky
Sunday, October 24, 2004 7:26:24 PM (Central Standard Time, UTC-06:00)
I don't think we will ever see a revolutionary innovation in the big three languages. It would be a terribly high risk don’t you think? Millions of lines of enterprise code out there now serving as an anchor. The frameworks and IDEs might innovate, but I think the only way for a language innovation to make it into the big three is if it happens somewhere else first (python?, comega?), then gains some acceptance and a demand exists first.
Sunday, January 29, 2006 2:41:38 AM (Central Standard Time, UTC-06:00)
If you want different perspectives, you must know at least one essentially *imperative* and one *functional* language. Amazingly, .NET allows this. F# is basically a .NET implementation of Ocaml, with some (minor) drawbacks.

But let's not forget the *best* .NET language for rapid proto-typing: Boo! The Boo language contains the best parts of Python, Ruby, and C#.
Christopher Dunn
Comments are closed.