Obviously, we don't want our tools--including our programming languages--to be more complex than necessary. But one aim should be to make tools that will serve skilled professionals--not to lower the level of expressiveness to serve people who can hardly understand the problems, let alone express solutions. We can and do build tools that make simple tasks simple for more people, but let's not let most people loose on the infrastructure of our technical civilization or force the professionals to use only tools designed for amateurs.
In any case, I don't think it is true that the programming languages are so difficult to learn. For example, every first-year university biology textbook contains more details and deeper theory than even an expert-level programming-language book. Most applications involve standards, operating systems, libraries, and tools that far exceed modern programming languages in complexity. What is difficult is the appreciation of the underlying techniques and their application to real-world problems. Obviously, most current languages have many parts that are unnecessarily complex, but the degree of those complexities compared to some ideal minimum is often exaggerated.
We need relatively complex language to deal with absolutely complex problems. I note that English is arguably the largest and most complex language in the world (measured in number of words and idioms), but also one of the most successful.
TR: Please talk about the pros and cons of maintaining backward compatibility with the existing knowledge base (for example, consider your determination to maintain high compatibility to C when you developed C++). It might seem that a clean break would produce leaps of progress; but is this really a realistic proposition?
BS: Java shows that a (partial) break from the past--supported by massive corporate backing--can produce something new. C++ shows that a deliberately evolutionary approach can produce something new--even without significant corporate support. To give an idea of scale: I don't know what the marketing budget for Java has been so far, but I have seen individual newspaper advertisements that cost more than the total of AT&T's C++ marketing budget for all time. "Leaps" can be extremely costly. Is such money well spent? Maybe from the point of view of corporate budgets and corporate survival, but given a choice (which of course I'll never have), I'd spend that money on research and development of evolutionary changes. Note that almost by definition, research money is used to fund attempted leaps that tend to fail while competing with evolutionary changes.
However, evolution shouldn't be an excuse for doing things the way we've always done them. I would like for evolutionary changes to occur at a faster pace than they do in C++, and I think that's feasible in theory. However, that would require funding of "advanced development," "applied research," and "research into application" on a scale that I don't see today. It would be essential to support the evolution of languages and libraries with tools to ease upgrades of real systems and tools that allowed older applications to survive in environments designed for newer systems. Users must be encouraged to follow the evolutionary path of their languages and systems. Arrogantly damning older code as "legacy" and recommending "just rewrite it" as a strategy simply isn't good enough. "Evolutionary languages" tend to be very conservative in their changes because there is no concept of supporting upgrades. For example, I could imagine accepting radical changes in source code if the change was universally supported by a solid tool for converting from old style to new style. In the absence of such tools, language developers must be conservative with the introduction of new features, and application developers must be conservative with the use of language features.
E-mail
Audio »
Print
Favorite
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
Massachusetts Institute of Technology
Comments
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++.
wkaras
12/07/2006
Posts:8
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
bs
12/10/2006
Posts:6
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.
mcsandberg
12/12/2006
Posts: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.
acc1
12/15/2006
Posts:1
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.
wkaras
12/18/2006
Posts:8
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.
bluemonki
12/29/2006
Posts:1
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?
ssargent
01/09/2007
Posts:11
tonyd
01/17/2007
Posts:1
ssargent
01/19/2007
Posts:11
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.
jnfombanu
02/26/2007
Posts:1