Ah the memories of why started down this path in the first place.

My personal trek started in '87 with the minor battle of Object C vs. C++ (grad student in Mathematics doing non-linear dynamics on a Next prototype...type safety verses the elegance of Smalltalk...) and took me through most all the ordeals surveyed. I reluctantly jumped off the C++ boat for Java just as it was becoming standardized and generic programming better understood.

I want to point out that the spirit lives on in an odd corner: the Javascript branch of the language tree. Though branded a bastard child because of the torching it took in the browser wars and hindered by a horrific misnomer, the language proper (calling it ECMAScript helps avoid some of the most embarrassing moments) is an elegant re-simplification of C to the typeless world of script-oriented languages (i.e.: perl and company). In this strange lange, instead of everything being a word or a byte or a pointer, everything is a number, string or object reference and loose typing thrives again and the programmer is trusted. If only the object-oriented features were more transparant...

Thanks for a both insightful and pleasent refresher.

BCPL is available for various platforms from
http://www.cl.cam.ac.uk/users/mr/BCPL.html

Try typeless programming with BCPL & MCPL.

...the lack of stack-allocated objects can make it more difficult to manage resources other than memory.

The correct answer is "escape analysis". C#'s notion of stack-allocated pseudo-objects is a brain-dead idea.

I do agree with the bits about Java's concurrency being problematic. And Java's generics are beyond redemption.

It's great to see an informed view of the trade offs involved in the evolution of C++!

I remember BCPL with a fair bit of fondness and did a lot of C and then C++ programming over the years but I've been off the scene for a while (I pretty much switched to Java in '97/'98 although, frankly, I've never really enjoyed Java as much as I enjoyed C++).

The 'optional template' idea is intriguing... One of the issues there is the 'implicit type' syntax problem - one of the reasons why we removed the 'implicit int' rule from C++ (following the lead of the C Standards committee) but, assuming that could be solved, it would certainly do away with quite a bit of syntactic baggage!

I'm looking forward to future material in this series.

I think including Java in an article about the Spirit of C is probably unfair, it's designers were trying to move away from it. Guy Steele once said:

"we were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp."

http://fishbowl.pastiche.org/2004/03/17/halfway_between_the_gutter_and_the_stars

Of course, basing a programming language on one that you don't even like, is not going to produce the best results.

The author appears to be describing the kind of static type system which languages like ML and Haskell have had for ages. They are strongly typed (as in, all type errors are caught at compile time, rather than hanging around to runtime) but the compiler automatically infers almost all of the types itself. Writing "generic" functions becomes easy, since you have none of the syntactic mess of C++ and the "generic-ness" falls out for free.

I love C - economy of expression - bare bones - spartan - portable assembly. Brilliant language.

Two different individuals set out to add OO capabilities to C. One focused on bringing the dynamic typing and message sending features of Smalltalk. The result was Objective C, the core of the vaunted NextStep development system (and now of Mac OS X). Objective C is a tiny and elegant extension to C with astonishing flexibility and provides useful strategies for typing errors at runtime (doesNotUnderstand: messages).

The other focused on text processing tricks along the lines of the C preprocessor and paid excessive attention to preventing rather than dealing with type errors. This approach imposes a rigidity on code that results in developers working extra hard to pacify the compiler rather than focusing on the problem domain at hand. While C++'s generics are an interesting feature for implementing high performance algorithms, dynamically typed language users do without them simply because they don't need them to work around their type system.

Java is simply C++ taken too far.

What I find most interesting in the hoopla around various new tools such as scripting languages and web services is the drive to replace the loose coupling that the C++ model strives to eliminate. It begins to look like a very silly game to the dedicated Smalltalker who starts out with a language based on loose coupling in the first place.

C++ was a wrong turn in language design. Its time we recognized that and began working towards more flexible software construction environments that encourage experimentation and innovation rather than punishing the developer for the slightest error. With laptops starting at 1GHz, I could give a fig about performance.

I really appreciate this article and look forward to reading the sequels.

I never paid much attention to B or BCPL because I assumed they were just variants of C, so I was unaware that their typing system was so different.

However, you introduce the term "typeless" without defining the term. I've learned through long study that a language that allows you to give function arguments without specifying the type can have very different meanings and behaviors. I can only guess that since this is a C-like language, everything is determined at compile time, like C++ templates. But does "typeless" mean that all variables are of a single unified type, or does some kind of type inference take place to figure out if something is an int, long, float, double, etc.? Or is it something else? I'd really like a more specific definition of "typeless."

(Was it really in Santa Cruz where Erwin demonstrated his compile-time prime filter? I seem to recall King of Prussia, Pennsylvania, or maybe Kitchener, Ontario.)

I found the article far too kind to Java. Had Java come along before C++, many of its design mistakes could be forgiven. Given full hindsight, though, there can be no excuses.

C++ "exception declarations" were recognized early as a mistake, but incorporated into Java nonetheless in even more intrusive form. (In C++ they can be ignored; not so Java.) Real C++ exceptions work well to reduce error-handling clutter, but in Java they actually increase clutter. C++ destructors, combined with template techniques, make it possible to encapsulate management of any kind of resource -- enough so that I have not needed to code a "delete" statement in many years. Java handles memory invisibly, but all other resources must be managed manually, C-style. C++ got the default "virtualness" of member functions right; Java got it wrong, so that Java classes, by default, expose much more of their implementation. Haste is a disastrous ingredient in language design.

The designers of Java, freed from compatibility constraints, had a golden opportunity to correct many of the problems inherent in C, and incorporate the power of C++ while leaving behind much of its complexity. They squandered that opportunity. C# designers had the same opportunity, again, and (given the greater hindsight) did even worse, retaining even many of the failed choices from Java. D did only a little better.

I call them "cargo-cult languages". Their designers copied features from other fashionable languages, but without understanding. They are the language equivalent of those shareware CDs that used to be described as shovelware. They are full of features, tossed into a bag with little thought given to how the features will interact.

A true successor to C++ is dearly needed. We need a language that leaves behind C's promiscuous conversions, its chaotic declaration syntax, its gratuitous undefined behaviors, its ill-thought-out library. We need a language that leaves behind C++'s name-lookup complexity, its awkward compile-time pattern-matching and expression syntax, its unfortunate library history. These other languages are only distractions.