One problem with an evolutionary approach is that there are few academic outlets for incremental change--especially not when that incremental change directly relates to real-word systems. This is a sign that computer science and software engineering haven't yet emerged as the theoretically and empirically well-founded foundation of real-world software development. Theory and practice seem rarely to meet, and researchers are pushed away from real-world software towards less messy academic topics. Conversely, many developers completely ignore research results.
A major issue in language evolution is control of its direction. For a new language, users have a choice: they can adopt it or not (though this becomes less clear-cut if the new language is heavily pushed by their platform supplier). But once they use a language, it is harder to ignore new features (e.g., one user might not like a feature, but a colleague or a library supplier may think it great and use it). And it is impossible to ignore incompatible changes. The ISO C++ standards process relies on volunteers, who can devote only part of their time to the standards work. This implies that it is slow moving. It also seems to imply that end users are consistently underrepresented compared to suppliers of compilers and tools. Fortunately, the C++ committee has always been able to attract many dozens of active members for its meetings and many more online, so it avoided the parochialism of a small group. Until very recently, academics have been completely absent.
C++ provides a nice, extended case study in the evolutionary approach. C compatibility has been far harder to maintain than I or anyone else expected. Part of the reason is that C has kept evolving, partially guided by people who insist that C++ compatibility is neither necessary nor good for C. Another reason-- probably even more important--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." That, combined with backwards-looking teaching of C++, has led to many failures to reap the potential benefits of C++ as a high-level language with powerful abstraction mechanisms.
TR: Would you consider Microsoft's heavily marketed language environment .NET one of your progeny? It does, after all, offer a high level of extrapolation and "pluggable" components. It's also the language most desired in corporate job candidates. What are its pros and cons?
BS: .Net is "the progeny" of a large organization, though Anders Hjelsberg has a large hand in it through C#, the language he designed, and its libraries. I suspect that C++ played a significant role, but primarily through MFC (which is not one of the more elegant C++ libraries) and as an example of something perceived as needing major improvement. C# as a language is in some ways closer to C++ than Java is, but the main inspiration for .Net and C# is Java (specifically, J2EE). Maybe C++ should be listed as a grandparent for .Net but as both a parent and a grandparent of C#.
.Net is a huge integrated system backed by Microsoft. That's its major advantage and disadvantage. Personally, I'm a great fan of portability. I want my software to run everywhere it makes sense to run it. I also want to be able to change suppliers of parts of my system if the suppliers are not the best. Obviously, suppliers of huge integrated systems, such as .Net and Java, see things differently. Their claim is that what they provide is worth more to users than independence. Sometimes they are right, and of course some degree of integration is necessary: you cannot write a complete application of any realistic size without introducing some system dependencies. The question is how deeply integrated into the application those system dependencies are. I prefer the application to be designed conceptually in isolation from the underlying system, with an explicitly defined interface to "the outer world," and then integrated through a thin layer of interface code.
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
Download
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