Just to kick things off – a commentary on the development of programming languages and paradigms as I see them. If you want to find out more about KIS Systems, Inc, go here (or the main URL of this page.)

OO Languages Update
So, the darling language of the OO set back in the 70’s was SmallTalk. Pure. Elegant. Darling. And a damned nuisance to write anything real in. But, it has served as a sterling example of what an OO language should be like, if only we didn’t have to worry about real-world conditions.

After SmallTalk, there were attempts to turn everyone’s favorite structured language – C – into an OO language. C++ and Objective C were the primary outcomes. Objective C never really caught on outside of the Next folks – native compilers were hard to come by, and the dynamic binding aspects were still difficult for C programmers to get their heads around. C++ was more comprehensible to compiler writers – no dynamic binding like Java or Objective C. In the end, C++ compiles to mostly static objects. But, it interfaced with C seamlessly, was comprehensible to C programmers, and you could (and still can) write some wicked-fast code with it. So, it has become the de-facto standard development environment.

C++ is a bear to code and maintain. Separated header files, time consuming compiler optimizations, and direct access memory management make for fast code, but slow development and challenging debugging. Granted, there are tools and toolkits (I’ll be getting around to those) to make things easier.

However (thought many) there must be a better way.

The New OOs
And so, the birth of a plethora of OO languages to try to redo the SmallTalk paradigm, only more efficiently, and with more than a passing nod to C syntax.

We’ll ignore Perl and Visual Basic for this discussion – OO concepts have been grafted into the languages, but aren’t complete or enforced. The “new” OO languages widely used for large system or application development fall basically to Java or C#. Of course, there are devotees of other incarnations – PHP, Python, and Ruby, for instance, but they’re held by a narrow few.

What do we lose? Performance, of course – although there are devotees of all that claim near C++ performance, but never quite.

Actually, the stories from Java-land have been pretty horrific. Large-scaled systems that were coded in the holy-grail of “new paradigms” collapsed under their own weight, and have been abandoned and re-writted in C++ because they were simply unworkable in an interpreted language. And, too many practitioners tend to encourage expensive constructs, without regard to system resources.

Of course, things improve – Sun is working on the development environment, continually – and the hardware is getting faster and faster.

On the Microsoft end, we have C# and the CLR. A “better” Java, according to some. (Actually, Microsoft is quick to point out that code is never interpreted – JIT technology is used to produce machine-code right on the metal, when it’s needed.) Unfortunately, even though Microsoft is pushing it as a “standard”, it’s Microsoft’s standard, and it takes the rest of the world years to catch up with the million-man-army-of-programmers in Redmond. And, C# is tied intimately with .NET, which is decidedly not a standard, nor will it ever be, if MS has it’s way.

So, it’s (C#/.NET) a Microsoft only – which means Windows only. Which means narrow platform constraints, any way you cut it.

Personally, I don’t like getting locked into a single platform, even if it has the potential of being a superior technology. When C# and some ubiquitous cross-platform UI toolkit come together, I may ballyhoo it (and it may happen – see the mono project and the KDE Qyoto (mono-Qt) progress.)

Those are slow in coming. In the interim, I’m still sticking with C++ and Qt as the cross-platform development toolset of choice for any real (=large-scale) development projects.

Until the next great thing.

rickb