|
Thursday, December 07, 2006 More Trouble with ProgrammingThe second part of our interview with Bjarne Stroustrup, the inventor of C++. By Jason Pontin
The first part of this interview engendered such debate in the comments section of our site, as well as on aggregator sites like Slashdot, that Technology Review chose to address some of the objections to C++ raised by readers. Technology Review: Name the coolest and lamest programs ever written in C++, and say what worked and didn't work. Bjarne Stroustrup: Google! Can you even remember the world before Google? (It was only five years ago, after all.) What I like about Google is its performance under severe resource constraints. It possesses some really neat parallel and distributed algorithms. Also, the first Web browsers. Can you imagine the world without the Web? (It was only about 10 years ago.) Other programs that I find cool are examples of embedded-systems code: the scene-analysis and autonomous driving systems of the Mars Rovers, a fuel-injection control for a huge marine engine. There is also some really cool code in Photoshop's image processing and user interfaces. What I like about these programs is how they are structured to be reliable and responsive under pretty harsh resource constraints. Some of Photoshop's ways of managing internal complexity (for instance, the graphical user interface [GUI] layout and access from image-processing algorithms to the pixel data) are just beautiful. If you look at code itself, rather than considering the resulting program, we could look at something like Shape [an abstract class that defines an interface by which shapes like circles and rectangles can be manipulated in C++], which I borrowed from Simula. It's still the language-technical base of most GUIs, such as the one on your computer or your iPod, or whatever. A more modern example would be the find or the sort algorithm in the Standard Template Library [STL] in C++. That's the language technical basis for much modern high-performance C++ code, especially of programs that need to do simple operations on lots of data. What is common to these examples of code is that they cleanly separate concerns in a program, allowing separate developments of parts. That simplifies understanding and eases maintenance. These basic language techniques allow separate "things" to be separately represented in code and combined only when needed. However, code is something appreciated by programmers, rather than most people. I have always been a bit envious of graphics people, robotics people, etc. What they do is so concrete and visible; what I do is invariably invisible and incomprehensible to most people. I know many mathematicians feel the same way. Sorry, I'm not going to shame anyone by naming their work "the lamest C++ program ever." It's oh so tempting . . . but no, it wouldn't be fair.
|
 |
|
||||||||||||||||||
| |||||||||||||||||||
Audio »
Share »
Digg this
Add to del.icio.us
Add to Reddit
Add to Facebook
Slashdot It!
Stumble It!
Add to Newsvine
Add to Connotea
Add to CiteUlike
Add to Furl
Googlize this
Add to Rojo
Add to MyWeb
Favorite
Print
E-mail
Comments
wkaras on 12/07/2006 at 7:23 PM
8
Seems more reasonable to ask for speculation about possible future developments. Could/should C++ be adapted for use with programmable logic devices (FPGAs, CPLDs)? Suppose that (as a consolation prizes for lack of faster clock speeds) CPU makers start including integrated indirect and/or associative lookup logic. Might that result in languages like SmallTalk, eiffel being viable alternatives to C++ in more cases?
Subroutines, libraries, O-O, generic programming are all capabilities for code reuse. They do not obsolete or replace each other. All of these have been around for a while. It was compartively easy to think up these techniques, the hard part was getting them all in one low-overhead programming language. Unless the chip makers force the machine model to change, it's hard to see any upcoming major dramatic changes or additions to C++.
bs on 12/10/2006 at 5:19 PM
6
To contrast, any architecture directly supporting high-level constructs becomes a burden to traditional programming languages and applications. And such architectures are harder and slower to design, so they tend to get to market a generation or two after a traditional hardware architecture.
C++ relies on the traditional architecture plus compiler techniques for abstraction. With the current glut in transistors on a chip, the world for which C++ was designed may indeed be coming to an end. That's why I pointed to "something related to concurrency" as the likely next big thing in programming language constructs.
However, given the amount of software designed for that world (essentially all we have) depending on the conventional style of hardware architecture, it might be a good idea to hedge any specific bet.
-- Bjarne Stroustrup; http://www.research.att.com/~bs
mcsandberg on 12/12/2006 at 8:52 AM
1
A complete language is one whose compiler can be written in the language, an incomplete one requires an interpreter written in a complete language.
Once you make this distinction, you can clearly see that the complete languages are going to be more complex and harder to use, but absolutely necessary. The incomplete ones will be considerably more numerous because there are a lot of different things that can be removed, resulting in many of the special-purpose languages we see today.
acc1 on 12/15/2006 at 1:05 PM
1
"Another reason is that organizations prefer interfaces that are in the C/C++ subset so that they can support both languages with a single effort. This leads to a constant pressure on users not to use the most powerful C++ features and to myths about why they should be used "carefully," "infrequently," or "by experts only.""
1) C++ as it now exists, is really better to be used "carefully". It's the nature of it. The "abstraction" and "separation" C++ promises breaks as soon as you want to have something like a DLL. And there I don't mean "Windows DLL" but just a concept of "something" which should be compiled and used separately. When you export only structures and C functions, you can do much better then when you start to export classes. I don't want to even mention the nightmares of exporting classes which use STL. It's not that it's impossible to do that initially, it's the maintenance nightmare afterwards that will kill you.
2) Whoever uses C++ exceptions more than in some very extreme situations, (or to handle the exceptions of some other piece of software who unwisely introduced it) is doomed just to make the problems for himself, getting no gain, just pain. Exceptions were introduced because the constructors work as they do, not separating allocation and construction and not being able to return errors. And then the hell break loose. Exceptions introduce unpredictability of the worst order. In fact, if you want to be sane, for most thing you do, much safer method is to separate the allocation and construction, constructing things with separate functions which can return error codes -- and that can be done with the "old" C equally well.
The most of the gain from a lot of C++ "features" went to "experts" and "consultants" who were to explain to to the masses how to use latest and greatest (earning from the "expertize") when the users were better off not using these at all.
There you have it. When you often have to avoid doing much in constructors and destructors, avoid C++ exceptions, avoid classes as such and particularly STL when you want to have a separately compiled library to get things safely done, what's left? I consider C++ as often useful syntactic sugar for the pieces of code that don't have to be exported (luckily there's enough such places too) but that's about it.
wkaras on 12/18/2006 at 4:47 PM
8
I don't understand specifically what you mean by exporting classes, but normally you can't just memcpy data structures that have pointers in them. The C++ Standard has lots of requirements in it to make sure that any data structure you could memcpy in C, you can also memcpy it in C++.
Exceptions are safe as long as any locked resource is mapped to an object, and would be released by the object's destructor (unless it had already been released). Some people feel that use of exceptions, virtual functions, function pointers, etc. make programs harder to understand. Programs that are more complicated than they need to be are harder to understand, but believe me, the true masters of obfuscation need only the "if" statement. Time will tell if exceptions make programs more or less maintainable, but "more" is my guess.
It takes more effort to learn to effectively use C++ than it takes for C. It also takes more effort to learn to drive a tractor-trailer than it does a car. That does not mean there is something wrong with tractor-trailers. It could very well be that, in your particular situation, the effort needed to use C++ (or some of its features) would be more fruitfully spent on something else. But it's not reasonable to criticize C++ because it can't give you something for nothing.
bluemonki on 12/29/2006 at 8:46 AM
1
Sure C is better than C++ in some places, but I don't think it's unreasonable to assume that the opposite may also be true.
Anyways on to more constructive stuff:
1) You can pass you user defined classes over the DLL boundary using the PIMPL design pattern to hide an STL filled implementation behind a pointer. This does mean you have to write a facade class for every interface class - but it'll just a be a barebones pass-through class.
2) Exceptions are great - programmers are lazy so returning false won't cut it anymore. If someone ignores the return value only the really high level warnings will mention it. You throw and exception and the whole world knows about it. There is an important distinction here between passive (returning 1 or 0 or whatever) and active (exceptions, asserts) programming. The only thing that would be nice is a java-esque way of enforcing that the exception will eventually be caught by something.
ssargent on 01/09/2007 at 3:56 AM
11
For someone who is most specialized at finance or law, time spent learning how to be a specialist at programming trades off with their ability to learn how to be specialist in finance or law. Likewise, the specialist in programming may not know all the nuances of finance and may not create the perfect program for the financial specialist. If the laity could program, so could those overspecialized in other areas. They could create applications custom tailored to their specialized knowledge in the field that goes beyond the functions of a multi-purpose one size fits all program. But this would be vision of the user knowing best what the user wants instead of the specialist programmer...seems like there should be some room for both. Hopefully Simonyi in "anything you can do, I can do meta" will help create that meeting place.
BS's vision of programming is dismal as well as problematic. If the specialist programmers aren't cutting it now, what incentive is their for change? Programmers getting smarter won't happen magically, so what will make them do the work. Maybe we just need to pay a higher price for a new set of higher quality programs. These of course will have their own new compatibility issues with old programs, and issues with proprietary file formats, but...essentially people will have to pay more and hope that the new programs won't introduce any new bugs or complications that add additional cost to the already high price justified by their higher functionality. If the specialists keep the system running kudos to them, and people should always try to excel in their field, but if many people can cut out the middleman: they will...question is when will someone finally tap into that market and who?
tonyd on 01/17/2007 at 3:32 AM
1
ssargent on 01/19/2007 at 6:56 PM
11
jnfombanu on 02/26/2007 at 10:07 PM
1
BS seems to be encouraging the follwoing approach when designing/coding application: with a specific well understood problem to solve, you step back and consider the space in which that problem exist. Then design a solution of which the case in point is 'a' solution. While mathematician may easily understand, it maybe a little difficult for lots. This approach requires training on its own.