## The C Family of Languages: Interview with Dennis Ritchie, Bjarne Stroustrup, and James Gosling

Herb Sutter's website has an interview with the main inventors of C, C++, and Java.

I think they all rightly raise the question of "C family of languages" means but I'm more interested in how the design decisions they discuss. I thought this bit by Gosling was interesting:

There have been a number of things [I would have done differently] -- like, for example, multiple return values -- that these days I kind of wish I had added. That was one where I really liked the feature and most other people just sort of went, "Huh?" Another one that sort of went that way was that I had been going down this route of having a bunch of stuff to do with preconditions and postconditions and assertions in an Eiffel-like way, and actually in the community of people who were using it at the time the average answer was, "Huh? Why would I ever want that stuff?" I think that the average developer today would say that too. But then there's a pretty reasonable crowd of people who believe in things like Design By Contract, and it's one of these things where a lot of people feel like, "If only the rest of the world was educated enough to understand what this is about, they'd be better off." And I actually kind of agree with that. The problem is that most of the world could actually care less.

## Comment viewing options

Although it's a tad out of date. It's interesting to see where the opinions diverge -- particularly the discussion around formal versus de facto standards.

### Should be: C-"Syntax" Family of Languages

It is superficial to think of all languages with "curly braces" as belonging to the same family, evolution or progression. Except for Java's use of C-like syntax, Java is actually a much closer relative of the Pascal/Cedar/Modula line of languages. Pascal isn't cool though and C is. In a similiar way, Perl shares very similiar semantics to Scheme, except that it has droped the lists and added C-like syntax (and added a lot of practical Unix shell-like stuff). Same for the evolution from NewtonScript to JavaScript and from Smalltalk/Self to Ruby. Perhaps the next "C" language should be Ruby (Self?) with braces? If no language or language concept can ever receive mass acceptance until it is cloaked in C-like syntax, then all progress forward will incorrectly appear to be in the evolution of C.

### It All Needs To Be 'Read

It seems to me, listening to these people talk, as if they are trying to cover up something, almost as if they are embarrassed these things are used like they are. It is important to note that Java wasn't meant to be more than a language for set-top boxes, a C++ with a VM, until Sun saw it as a potential revenue generator. C was for Unix building and C++ was an experiment in C. The reason they all took off is because you can do things in them without knowing the real computer science behind the ideas (especially Java, although C# is becoming a little academic now-a-days).

For instance, how many Java programmers do you think look at inner classes and see them as a poor man's closures, and understands the concept of closures and the reasons why the Java hack doesn't add up? I'd suspect very few.

In my mind, the next language for moving computer science forward has to be from the Lisp branch, because of it's flexibility and power. Sadly, we're getting more abstracted Java languages (RoR) and that isn't going to expand anyone's mind. Algol languages are getting so top-heavy because of their verboseness that the IDEs are in the GIGs now, implementation of applications written in these languages have a failure rate of 70% and new languages are still pushing the code out and down more, instead of sideways.

Java has always been, in my mind, a wrapper around a database with some poor interfaces stapled on top for web, desktop (swing,awt) and mobile. It's CRUD enabling, and that's all it can ever be. You can have as many objects dancing around caching and adapting and abstracting as much as you want, but at the end of the day, they all have to report to the same inflexible master.

In fact, many patterns are simply ways of managing the complexity their own existance brings about.

I think the idea of a database being invisible, and code / data being thought of as one and the same and automatically persisted is the important next step. The idea of making our code relational and then worrying about another relational model on another server and syncing with that will become laughable, Oracle be damned.

Of course, this already exists (Allegro 8.0) but to do this you need a large business advocate, and since Sun was interested in quickly converting C++ users (later, post Gosling) and Microsoft was interested in quickly converting Java users, the desire for innovation is just not there because of the need for the quick get.

We're still in the dark ages it would seem.

### Agreed.

I agree 100% with your conclusions. It seems that instead of less code and less testing we get more code and more testing for the same task as yesterday...

### Shrilly outside, isn't it?

...implementation of applications written in these languages have a failure rate of 70%...

Where does 70% percent come from? And what do you mean by "failure"? By failure do you mean -- you can't even run the blasted thing? Or, it doesn't do what you wanted? You couldn't compile it in the first pass? Or...?

### It means it does not do what you wanted.

Most of the time it means that it does not do what you wanted. It also means nasty bugs like wild pointers, memory corruption etc.

### Maybe we should remember

Maybe we should remember what Richard Gabriel stated 1996 in "Patterns of Software" that Lisp went down in the late 80s - early 90s with all the Lisp machine and AI companies because big vendors moved to C++ considering C++ maintenance as safer, cheaper and simpler. I don't believe they will revise their judgement about Lisp 15 yrs later just because scripts will now be stored in databases.

We're still in the dark ages it would seem.

I always thought the "dark ages" were also those of the big cathedrals some software engineers would like to construct? Mental disorientation?

Kay

### The grass is always greener

Maybe we should remember what Richard Gabriel stated 1996 in "Patterns of Software" that Lisp went down in the late 80s - early 90s with all the Lisp machine and AI companies because big vendors moved to C++ considering C++ maintenance as safer, cheaper and simpler. I don't believe they will revise their judgement about Lisp 15 yrs later just because scripts will now be stored in databases.

The grass is always greener on the other side of the fence. C++ seemed safer, cheaper, and simpler, but C++ didn't last long. For the most part C++ has lost to Java (C# in Microsoft shops), which was supposed to be this really great language. Now there is a large group of disillusioned Java programmers looking to languages like Ruby or Python to save the day. My guess is this sort of thinking will continue ad infinitum, not because languages are improving (most in the language community will agree that there hasnâ€™t been a whole lot of ground breaking research in languages for the past 20 years, especially research that has found its way into mainstream languages), but because â€œthe grass is always greener on the other side of the fence.â€

The unknown always promises the best to those who are optimistic enough to believe, despite what history has shown us, the next popular language will fix all our problems. A quick glance at our past shows us that despite all the optimism, languages donâ€™t deliver on the promises, because languages canâ€™t fix the idealism of optimistic managers who believe some technology will fix all of their bad decisions (decisions which may include, but are not limited to, hiring the wrong programmers and choosing the wrong language).

That said, Hindsight is twenty/twenty (Iâ€™m full of clichÃ©s today, arenâ€™t I?). In other words, why should be believe that managers will not conclude that Lisp was the better choice 15 to 20 years later? For the most part itâ€™s a different set of managers, so they wouldnâ€™t be admitting to making a mistake (â€œthose managers before us made some bad decisions that we need to fixâ€). In hindsight, C++ clearly wasnâ€™t the answer and Java doesnâ€™t look like the answer either. The previous generation of managers made some bad decisions, whatâ€™s to say that moving from Lisp to C++ wasnâ€™t one of them? (Iâ€™m not arguing for or against here, Iâ€™m just pointing out a possible reasoning of a modern technology manager).

Not all languages are created equal. However what language is best varies from person to person. If all people had the same thinking process then we would all be writers, artists, and mathematicians, but weâ€™re not because we donâ€™t have the same thinking process. Even among those who are writers, artists, or mathematicians the thinking process varies. This is evident by the variation in literature, art, and styles of mathematical proof and the varieties of mathematics, from Numerical Analysis to Group Theory. Java isnâ€™t the language for the masses, and neither is Python. If this were so, then why are many Java programmers getting hyped up on Python or Ruby? Why do so many programmers consider Lisp or Scheme to be the most elegant language? The truth is, Scheme fits the thinking of some programmers and another language (especially one that isnâ€™t functional) feels foreign and even wrong when the most obvious solution is simple and elegant in Scheme (and very likely not even possible in the other language). The same is true of Python. Why do you suppose there is so much argument over ideas like map() and reduce() in Python? Why is the debate so heated? Because, those who find functions like map() and reduce() intuitive, cannot fathom why Guido would consider them worthless and claim the incomprehensible list comprehension more readable. Likewise Guido cannot fathom why some programmers argue in favor of retaining map() and reduce() when list comprehensions are clearly more readable, and just as powerful.