Summary
In a Technology Review interview, C++ creator Bjarne Stroustrup explains why most software is "so bad," and what can be done to improve the situation.
Advertisement
In The Problem with Programming, interviewer Jason Pontin asks Bjarne Stroustrap why most software is so bad. Stroustrup replies that:
Some software is actually pretty good by any standards. Think of the Mars Rovers, Google, and the Human Genome Project. That's quality software! ...
On the other hand, looking at "average" pieces of code can make me cry. The structure is appalling, and the programmers clearly didn't think deeply about correctness, algorithms, data structures, or maintainability. ...
Stroustrup goes on to suggest that the real problem lies in the pressures facing developers and that developers often force their way to an acceptable result, without necessarily knowing how they got it:
I think the real problem is that "we" (that is, we software developers) are in a permanent state of emergency, grasping at straws to get our work done. We perform many minor miracles through trial and error, excessive use of brute force, and lots and lots of testing, but--so often--it's not enough.
Software developers have become adept at the difficult art of building reasonably reliable systems out of unreliable parts. The snag is that often we do not know exactly how we did it: a system just "sort of evolved" into something minimally acceptable. Personally, I prefer to know when a system will work, and why it will.
Pontin next asks Stroustrup how we can "fix the mess we are in." Stroustrup suggests:
In theory, the answer is simple: educate our software developers better, use more-appropriate design methods, and design for flexibility and for the long haul. Reward correct, solid, and safe systems. Punish sloppiness.
In reality, that's impossible. People reward developers who deliver software that is cheap, buggy, and first. ...
One problem is that "academic smokestacks" get in the way: too many people push some area as a panacea. Better design methods can help, better specification techniques can help, better programming languages can help, better testing technologies can help, better operating systems can help, better middle-ware infrastructures can help, better understanding of application domains can help, better understanding of data structures and algorithms can help--and so on. For example, type theory, model-based development, and formal methods can undoubtedly provide significant help in some areas, but pushed as the solution to the exclusion of other approaches, each guarantees failure in large-scale projects. People push what they know and what they have seen work; how could they do otherwise? But few have the technical maturity to balance the demands and the resources.
What do you think of Bjarne's statements on the current state of software, and how do you suggest we "fix this mess we are in?"
Stroustrup is, of course right about all the technical aspects of how quality can be improved. But I think he is only pointing at the symptom, not the problem when he says that pressure is a big problem. The real problem with pressure is that the people (managers, customers etc.) that pressure the developers have too little knowledge about software quality. They just want a piece of working software, and does not really care if it has good quality.
If buildings or ships was constructed with average quality in software, the contractors would have been sued and unemployed pretty quick. Why is this so different in the Software industry? Why does not (most) stakeholders care about quality? When stakeholders can balance the pressure for both quality and time schedules, then software quality will improve too.
So how should we (developers) act to get stakeholders interested in software quality? We must produce tools, or improve existing ones, that measures quality and gives feedback stakeholders understand. Most of the understand the language of money. I do not have a good answer on how these tools should be, but it certainly help to have someone who can both program and talk money language involved in the process.
I think XRadar (http://xradar.sourceforge.net) and other tools have come a long way measuring the quality at a technical level. Maybe this project or some other tool vendor will try to implement business reports based on code quality and progress.
I used to be a big fan of C++ and Stroustrup alike, but his recent statements these past years have made me very sad. This one is no exception, although this time, he refrained from his usual Java jabs.
This interview is interesting in the sense that it rightfully gives credit to C++ where credit is due (C++ did help usher us into the OOP era) while stubbornly refusing to acknowledge that the language's obsession with performance and its innumerable compromises to backward compatibility are the main reasons why it's also so hard to program in the first place (no GC, pointer arithmetic, 1000+ page spec, buggy implementations even today, etc...).
I'm also very disappointed that he continues to completely ignore that next-generation languages like Java and C# are more productive and overall, create more robust programs than C++ ever did, as any soldier in the trenches (such as myself) can attest.
Java and C# are not perfect, but they did build on the shoulders of giants, just like C++ did, and I wish Stroustrup showed a little bit more objectivity and acknowledged these achievements.
Finally, the college resumes that I've been reading on a regular basis these past years clearly indicate that C++ is on its way out (grad students show in average three months of C++ study, and it's usually mostly theoretical) while Java and C# now represent the lion share of their education, both theoretically and practically (long-term projects).
> If buildings or ships was constructed with average quality > in software, the contractors would have been sued and > unemployed pretty quick. Why is this so different in the > Software industry? Why does not (most) stakeholders care > about quality?
I believe that most people have been conditioned to accept software that is of poor quality. The other problem is that most people believe that it is too expensive to write software of good quality, which can be true depending on the choice of tools and language.
A lot of software is the engineering equivalent of a go-cart. You may be able to get around in a go-cart, but few people would mistake it for a decent car. And few would think it a simple task to transform a go-cart into a BMW. In software both of these mistakes are made all the time.
Although I know very little about cars, but I'd gladly pay more for a Beamer based on the idea that I'm buying better engineering. In software, decision making is harder.
In order for software buyers to make quasi-rational decisions about the level of quality they want or can afford, there needs to be at least a rough correspondence between the cost and the level of quality. That implies that software engineers can reliably produce a known level of quality at a given price, which is largely not true.
Until our field can offer a reasonable certainty of the outcome, asking clients to invest up-front for software quality will continue to be a tough sell.
> I'm also very disappointed that he continues to completely > ignore that next-generation languages like Java and C# are > more productive and overall, create more robust programs > than C++ ever did, as any soldier in the trenches (such as > myself) can attest.
Like you, I was once a 'Mel' for C++. I was thinking it was ironic that "just "sort of evolved" into something minimally acceptable." fits how I imagine C++ has come to be as it is. I know I'll get flamed for this, but C++ (the language) now strikes me as very inelegant and sloppy.
> Although I know very little about cars, but I'd gladly pay > more for a Beamer based on the idea that I'm buying better > engineering. In software, decision making is harder.
Interestingly enough, if you did know about cars you'd know that a BMW's reliability is poor and maintenance is extremely costly. Many people make this mistake with software too, assuming a fancy logo and good marketing means the product is better.
> I'm also very disappointed that he continues to completely > ignore that next-generation languages like Java and C# are > more productive and overall, create more robust programs > than C++ ever did, as any soldier in the trenches (such as > myself) can attest. > > Java and C# are not perfect, but they did build on the > shoulders of giants, just like C++ did, and I wish > Stroustrup showed a little bit more objectivity and > acknowledged these achievements.
Java/C# are really aimed at a different audience than C++ is. C++ is a systems level language. That means you can use it to write an OS. That doesn't mean that it is the correct choice to write your database driven app in. C++ is the right language to write your database in.
Generally, those HLLs are written in C or (increasingly) C++.
> Finally, the college resumes that I've been reading on a > regular basis these past years clearly indicate that C++ > is on its way out (grad students show in average three > months of C++ study, and it's usually mostly theoretical) > while Java and C# now represent the lion share of their > education, both theoretically and practically (long-term > projects).
As you said, C++ is not being taught in college. That does not mean that C++ is somehow in decline. That means that these colleges are not doing their job educating students for the real world. There is probably more shrinkwrap software written in C++ than any other language. The poor guy holding a bachelor's degree who has hardly seen a line of C++ is going to be right out of his depth when he applies for a job at a place like Microsoft, Adobe, Oracle, NASA, etc.
As a language C++ certainly has its warts. Bjarne will also admit that. (He has a euphemism; "Expert Friendly.") Much of this is due to some of the design constraints that C++ has maintained over the years. (Don't break working code, and don't pay for what you don't use come to mind.)
If C++ does not suit your needs, go write your program in Python, Ruby, C# or Java. Don't dismiss C++ as irrelevant. Every language has its tradeoffs, and every new language will too. As Fred Brooks put it, "there is no silver bullet."
Although programmers and managers share some responsibility for the limtations of software, I believe it is really the marketplace that sets the balance between quality and other factors such as cost, time to market etc.
Startup companies who do everything "by the book" are quite likely to go out of business before they have the profits to become self-sustaining.
As far as quality is concerned, it depends on your definition. For a user, quality software is useful, responsive, realiable, and in some cases, cool. A user has no idea if the software is made of spaghetti code or follows the latest trends in design patterns and "best practices".
When Google is held up as an example of a company with quality software, I assume that it's based on the user experience, since most of us don't have access to Google's source code or documentation. Or perhaps the assumption is that any company who has a challenging interview process must be writing quality code.
> Java/C# are really aimed at a different audience than C++ > is. C++ is a systems level language. That means > you can use it to write an OS. That doesn't mean that it > is the correct choice to write your database driven app > in. C++ is the right language to write your > database in.
In my experience those people who permamently distinct between "systems" and "applications" have the least understanding what systems really are and how this term is used non-metaphorically.
I don't even think that C++ is yet a good language for computational intensive stuff. It is hard for the compiler to reason about and optimize C/C++ programs due to their flexibility. Program specialization and parallelism are not among the virtues it supports well. However Stroustup made an interesting proposal recently about SELLs [1] ( semantically enhaced library languages ) that points into the right direction. He is far from being a grumpy old man who refused to realize the time in which he lives.
>> However Stroustup made an interesting proposal recently >> about SELLs [1] ( semantically enhaced library languages ) that points into the right direction. He is far from being a grumpy old man who refused to realize the time in which he lives.
I think we are already doing that since a long time when we started to use a well-supported generic markup language XML as our special purpose language and provide libraries to interpret it in our well-supported general purpose language (such as Java). For example, Ant, XUL and more recently, XAML. XML may not be the most expressive of all languages, but it definitely comes with an impressive array of tools and utilities. Though the combination XML + Java may not be the best, but it meets 80% of our flexibility and extendability requirements.
> >> However Stroustup made an interesting proposal recently > >> about SELLs [1] ( semantically enhaced library > languages ) that points into the right direction. He is > far from being a grumpy old man who refused to realize the > time in which he lives. > > >> [1] http://citeseer.ist.psu.edu/753846.html > > I think we are already doing that since a long time when > we started to use a well-supported generic markup language > XML as our special purpose language and provide libraries > to interpret it in our well-supported general purpose > language (such as Java). For example, Ant, XUL and more > recently, XAML. XML may not be the most expressive of all > languages, but it definitely comes with an impressive > array of tools and utilities. Though the combination XML + > Java may not be the best, but it meets 80% of our > flexibility and extendability requirements.
The combination of XML and Java equips Java with declarative programming elements and adds some flexibility because XML elements can be transformed easily and dynamically. SELL is a completely different issue. Bjarnes idea is to provide specialized compiler support for subsets of C++ that have specific library support. These libraries are trivially complient with their host language and can be compiled by any ANSI C++ compiler. Different compilers within the Pivot framework will accept only subsets of otherwise valid C++ programs but these programs together with a domain specific library can be optimized in a particular way because the sublanguage has a far simpler semantics.
> Like you, I was once a 'Mel' for C++. I was thinking it > was ironic that "just "sort of evolved" into something > minimally acceptable." fits how I imagine C++ has come to > be as it is. I know I'll get flamed for this, but C++ > (the language) now strikes me as very inelegant and sloppy.
B.S. has certainly done more in the field of computing than moost of us could ever dream of doing, but nonetheless I too have a hard time taking advice from someone who has gotten mentally stuck in the rut of his own fugly 20-year-old invention that was stapled to the back of a cobbled-together language that we lovingly referred to as "assembly with macros".
Java (warts and all) did to C++ the most humane thing imaginable: It made it usable.
>Java and C# are not perfect, but they did build on the >shoulders of giants, just like C++ did, and I wish Stroustrup >showed a little bit more objectivity and acknowledged these >achievements.
In fact, it is Java crowd that often forgets to acknowledge the giant's shoulders on which it stands and Stroustrup points it out in the interview. In the light of recent push back to functional programming roots it is clear that Java architects have failed in that realm. Neal Gafter's blog at http://gafter.blogspot.com/2006/11/reified-generics-for-java.html shows where Java architects have gone wrong with respect to generic programming. Because of the language shortcomings, the Java "productivity" argument is a bogus one. A seasoned C++ programmer actually more productive than his Java peer because his tool is much more powerful and versatile. Admittedly, to learn how to properly use the tool is much harder in C++ case, but there are no shortcuts to any place worth going to. In that sense, the interview strikes right at the heart of the problem - nowadays anyone can write and sell software. That must change, no matter what language is used.
> I'm also very disappointed that he continues to completely > ignore that next-generation languages like Java and C# are > more productive and overall
Maybe he doesn't ignore it, but rather has a different opinion? I have used C++ and Java and a lot of scripting languages for many years. It's not so clear to me whether Java is generally more productive than C++.
Yes, garbage collection has made many things easier and more robust. But Java makes it very hard to write libraries and frameworks that provide high level abstractions to the user. In my opinion, that's why J2EE has become such a monster and Java programmers need so many tools to generate, post-process and deploy code.
Dynamic languages provide more facilities for abstraction as part of the language, but at a high performance cost and without any kind of compile time checking. C++ templates can do many similar things at compile time, but admittedly, templates are very hard to debug and the advanced tempalte features (not present in Java generics) are not easy to understand.
For me, the bottom line is that C++ can be more productive than Java only if used by very advanced C++ programmers. The average C++ program will be worse than the average Java program. And in that sense, there is no way to objectively tell whether one language is more productive than the other. It's a matter of who uses the language for what kind of problem.
Maybe the combination of C/C++ and Python/Ruby is not such a bad idea after all.
Flat View: This topic has 212 replies
on 15 pages
[
123456
|
»
]
Previous Topic
