Home

Bjarne Stroustrup: The Problem with Programming

A Bjarne Stroustrup interview about programming and about his language design philosophy. Two choice quotes:

I want elegant and efficient code. Sometimes I get it. These dichotomies (between efficiency versus correctness, efficiency versus programmer time, efficiency versus high-level, et cetera.) are bogus.

TR: In The Design and Evolution of C++, you claim that Kierkegaard was an influence on your conception of the language. Is this a joke?

BS: A bit pretentious, maybe, but not a joke. A lot of thinking about software development is focused on the group, the team, the company. This is often done to the point where the individual is completely submerged in corporate "culture" with no outlet for unique talents and skills. Corporate practices can be directly hostile to individuals with exceptional skills and initiative in technical matters. I consider such management of technical people cruel and wasteful. Kierkegaard was a strong proponent for the individual against "the crowd" and has some serious discussion of the importance of aesthetics and ethical behavior. I couldn't point to a specific language feature and say, "See, there's the influence of the nineteenth-century philosopher," but he is one of the roots of my reluctance to eliminate "expert level" features, to abolish "misuses," and to limit features to support only uses that I know to be useful. I'm not particularly fond of Kierkegaard's religious philosophy, though.

Now go read the whole thing, or go directly to the discussion already raging in the LtU disucssion group.

By Ehud Lamm at 2006-12-07 12:28 | General | other blogs | 8616 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

the second part of our interview with Bjarne Stroustrup

More Trouble with Programming

By Isaac Gouy at Fri, 2006-12-08 20:08 | login or register to post comments

supplier substitution

Nearly the last paragraph (on the fourth and last page of this second installment) addresses the inability of users to replace Microsoft as the language supplier, where Bjarne comments on C# as a language. That's rather interesting. I was thinking recently if you can't replace your supplier, the language is not a commodity that can be substituted, and that makes it hard to use the name of the language as identifying a thing independent of the one context where it lives.

But on the platform where you can get C#, you can substitute another language instead, so there's still at least one kind of subsitution.

(The concept of substitution is a big deal in many places and contexts in programming languages, as well as design and engineering practice. It's good practice to ask early and often what can be subsituted where and when.)

By Rys McCusker at Sat, 2006-12-09 00:58 | login or register to post comments

mono

Arguably you can find other suppliers for C#.

By Isaac Gouy at Sat, 2006-12-09 03:39 | login or register to post comments

C# from mono

Yes, it sure looks like the Mono project provides C# as an alternative, and it even looks free. I assumed Bjarne was right without checking his facts. (Not very clever, I guess.) Anyway, substitution is still very important.

By Rys McCusker at Sat, 2006-12-09 18:41 | login or register to post comments

Deja vu?

I even went to the slashdot thread. What objection does his responses address? From what I can tell, Stroustrup hasn't said anything different in years. I think I'm just going to skip reading his next interview.

By Koray Can at Fri, 2006-12-08 22:13 | login or register to post comments

first hand

There are so many third/fourth/fifth... hand accounts of what some programming language person thinks and says. I find it interesting when the person shows up in discussion and speaks for themselves. Bjarne Stroustrup commenting on Artima:

"Letting lots of threads loose in a shared address space is fundamentally a bad idea. It forces users to deside where synchronization is needed and to choose which kind of synchronization is appropriate. Separating concurrent activities so that they communicate only through explicitly declared channels is key to most good solutions. I like the ideas of futures (for individual concurrent activities) and message queues (for long-running activities)."

By Isaac Gouy at Wed, 2006-12-13 17:13 | login or register to post comments