Veteran developer Greg Colvin traces the evolution of C, C++ and Java with an eye to a better future.

http://www.artima.com/cppsource/spiritofc.html

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.

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.

Yes -- ML and Haskell are exactly what I had in mind.

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.

(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.

As I recall Erwin presented his proof of template Turing completeness at Santa Cruz, but I may well misremember.

As for java, I did hint that it had foolishly given up one eye in extremis. Still, I have seen a lot of good work by people I respect who choose java over C++ for some purposes.

One person's fault is another person's pet feature.

IMO Java got exceptions right in forcing them to be handled.
It's far too easy in C++ to just gloss over whatever problems are reported by functions and let someone else in the future wonder why the application keeps crashing who doesn't have the source of the function that throws the hidden exception.
Just a little example...

Again with exposure of implementation, it's all a design choice. You like it or not, that's up to you.
Which you prefer is up to your own pettiness, calling anything anyone else prefers wrong shows that pettiness and the shortsightedness of your own views more than anything else.
Maybe default access should better have been private, but then something else would have bugged you. Most likely the extra syntax needed to expose features to other classes.

C++ is IMO suffering from extreme feature creep. It's now so large and monolithic that it's impossible to learn the entire language on even one platform and portability is almost impossible to achieve as a result.

You seem to consider everything BUT C++ to be fundamentally flawed while in effect most of the world seems now of the opinion that pretty much the reverse is true.
Learn to live with it...

Hi,Greg Colvin :
I am a programmer in China. I like your article and want to translate it. Maybe it will be published in CSDN (most popular programming magazine in China). I need your permission before translation.

My Email:
chb_sh@hotmail.com

Regards
redguard

Looks like the ability to practice "typeless" programming is somewhat addressed with the typeof/decltype/auto facility that is currently being discussed by the C++ standard committee...

Though I certainly appreciate the way types are handled in Haskell and ML, I wonder if that is consistent with the other four concepts which described The Spirit of C.

Neither of these languages is truly typeless. In fact, they're strongly typed, and can be rather rich in different types. The fact that a programmer doesn't have to explicitly declare the types doesn't mean that he or she doesn't have to be concerned about them.

Perhaps more importantly, it clashes with the idea of trusting the programmer and offering freedom. In C, I would be free to, perhaps unwisely, cast an arbitrary memory address to an arbitrary data type. My knowledge of ML may be lacking, as I've only recently begun experimenting with O'Caml, but it doesn't seem that such a thing is possible with the type system that exists there.

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.