One reason I am cautious is that I saw an earlier language built on similar ideas, called R++, struggle to gain acceptance some 15 years ago. It did well for a major application, but repeatedly, enthusiastic people discovered [that] introducing major changes into their tool chains and processes was complicated and expensive, and that educating new developers was difficult and time-consuming. Naturally, aspect-oriented programming may avoid some of these problems, but to succeed it needs to dodge all, and more. In computer science, a major new idea will succeed only if it is sufficiently capable in
every relevant area. To succeed on a large scale, a new language must be good enough in all areas (even some the language designer has never heard of), rather than just superb at one or two things (however important). This is a variant of the simple rule that to function, all essential parts of a machine must work; remove one, and the machine stops. The trick is to know which parts are essential. Please note that I'm not saying, "Aspect-oriented programming doesn't work," but to be "the next big thing," you have to provide major gains in an enormously broad range of application areas.
All that said, I don't know what the next major conceptual shift will be, but I bet that it will somehow be related to the management of concurrency. As programmers, we have been notoriously bad at thinking about lots of things happening simultaneously, and soon our everyday computers will have 32 cores.
You didn't mention generic programming. It is definitely worth thinking about in this context. Over the last decade, it has made a major change to the way C++ libraries are designed and has already led to the addition of language features in Java and C#. I don't think of generic programming as the "next paradigm," because C++ has directly supported it since about 1990, and the C++ standard library crucially depends on it. What if the next big thing has already arrived and nobody (except programmers) noticed?
It's worth noting, perhaps, that I don't actually believe in a popular [use] of the word "paradigm" (that derives from Thomas Kuhn's ideas in The Structure of Scientific Revolutions) when it is applied to programming. I do not believe that a paradigm completely replaces previous paradigms in one revolutionary moment (or "shift"). Instead, each programming paradigm adds to what worked previously, and as a paradigm matures, it is increasingly integrated with previous paradigms. Kristen Nygaard was fond of saying that multiplication didn't completely replace addition, and, by analogy, whatever would come after object-oriented programming would include object-oriented programming as a subset. I tend to agree. The evolution of C++ was guided by this view, and the evolution of Java and C# provides further examples.
TR: Computer languages remain generally difficult to learn. One might argue that for computers to become more than "helper" tools that enable mass computations and widespread communications, they must evolve again--and one key may be in simplifying the process of coding so that more individuals are able to participate in development.
BS: I think that would be misguided. The idea of programming as a semiskilled task, practiced by people with a few months' training, is dangerous. We wouldn't tolerate plumbers or accountants that poorly educated. We don't have as an aim that architecture (of buildings) and engineering (of bridges and trains) should become more accessible to people with progressively less training. Indeed, one serious problem is that currently, too many software developers are undereducated and undertrained.
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.