Summary
In the second part of his interview with Technology Review, C++ creator Bjarne Stroustrup shares what he thinks are some of the greatest C++ programs ever written, discusses what he considers to be the next important programming paradigms, talks about what it takes for a language to succeed and about the utility of evolutionary language design.
Advertisement
Bjarne Stroustrup continues his interview with Technology Review in More Trouble with Programming, where he first laments that beauty in code is not a universally admired value because it can only be appreciated by programmers:
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.
When asked if he thought that aspect-oriented programming would be the next big programming paradigm, Stroustrup disagreed:
I don't see aspect-oriented programming escaping the "academic ghetto" any day soon, and if it does, it will be less pervasive than OO. When it works, aspect-oriented programming is elegant, but it's not clear how many applications significantly benefit from its use. Also, with AO, it appears difficult to integrate the necessary tools into an industrial-scale programming environment.
According to Stroustrup, for a language or paradigm to become truly successful:
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.
Instead of AOP, Stroustrup notes that generic programming has been an influential force already:
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?
When asked if programming languages should be simpler to learn and understand so that non-programmers can also write code, Stroustrup commented that:
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... 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.
Finally, Stroustrup talks about evolutionary design of languages versus radically new paradigms:
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...
Users must be encouraged to follow the evolutionary path of their languages and systems... 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...
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...
Excellent interview! I especially liked the following:
*** 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. 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. ***
I think that this sumarizes one of the most common problems in software industry today.
"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... 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."
But we do tolerate them. We have no choice. I learned long ago from expensive experience that when I hire a plumber or accountant, I had better double check his work. Plumbing in particular isn't hard for amateurs to do just as good (and usually better) a job as a professional.
We absolutely do keep working on engineering tools to make them less error prone. I'd rather use a computer to do stress calculations than a slide rule. Back when I worked on airplanes, it was just before the transition from using manual drafting to computer drafting. The old hands would scoff at me using the computer to do calculations. They stopped that when I found errors in their work. They were much better engineers than I was, it's just that the tools they were used to were hard to use and error prone.
As for "tools designed for amateurs" - I see an implication that amateur tools are tools that are easy to learn and/or easy to use. One thing I've found when working on machinery, cars, etc., is that the professional tools are easier to learn, easier to use, produce better results, save time, etc. I buy pro tools to work on my car because I am sick to death of hard to use amateur tools.
Sometimes people use an analogy that flying a 747 must be hard because it's a big, expensive, professional airplane. Quite the opposite. A 747 is an easy airplane to fly. Tremendous effort has gone into making it so. No airliner wants to buy airplanes that are hard to fly - hard to fly means more expensive pilot training at the best, and crashes at the worst. Airliners do put their best pilots on 747s not because they're harder to fly, but because they are flying the most people and $$$ around.
So let's get back to software. I cannot agree that professional languages should necessarily be harder to use. A professional language should be easier to use. A professional language should have more fit and finish to it. A professional language should have more capabilities in it. A professional language should produce faster code. A professional language should have better documentation and better support. It should have fewer bugs.
None of that implies harder to use, or experts only. I got rid of my old radial arm saw and bought a professional one, because the pro one made it easy to produce 90 degree cuts to absolute perfection every time. It isn't a whit harder to use. It is certainly safer to use. It's a beautiful, finely made piece of machinery. Yet I'm certainly an amateur in the woodshop.
As for not allowing amateurs to be "let loose", what are you saying? Are you suggesting government licensing of software engineers? Is something really wrong with designing tools that require less training to use?
Would you like to use an operating system designed and created by semiskilled people or a programming language created by amateurs?
Or would you like to use tools created for amateurs, of course, created by amateurs?
The point is not about avoiding unnecessary complexity, it's about problems being inherently complex.
It's not about flying a 747 but about creating it. Would you fly a 747 created by semiskilled people? Atleast I wouldn't do that.
You need to simplify tools. But creating those tools is complex where I need skilled people and I can't use undereducated, undertrained and inexperienced people there. That's what Bjarne was talking about. Complex tools to solve complex problems.
Bjarne's quote is apt here. "Proof by analogy is fraud" whether I do it, you do it or Bjarne does it.
> Would you like to use an operating system designed and > created by semiskilled people or a programming language > created by amateurs? Or would you like to use tools created for amateurs, of course, created by amateurs?
Of course I'd like to only use stuff created by geniuses. I'd like to have the best accountant in the world doing my taxes. I'd like to have the best plumber in the world fix my leaking sink. I want to fly with the eagles.
But unfortunately, I live in the real world, and such isn't possible. I'm much more likely to be successful if I'm able to work with people who aren't the best.
> The point is not about avoiding unnecessary complexity, > it's about problems being inherently complex.
Is it? Genius is not finding a complicated solution to a complex problem. Genius is finding the underlying simplicity where everyone else saw complexity. I ain't no genius, but I'm always looking for that underlying simplicity, and I'm not satisfied with complexity.
> It's not about flying a 747 but about creating it. Would > you fly a 747 created by semiskilled people? Atleast I > wouldn't do that.
You already have, if you've ever flown. Do you think Boeing has 10,000 geniuses doing design work? (Yes, 10,000 engineers.) Sure, there are a few geniuses here and there, but the vast bulk of the work is done by ordinary joes like you and me. What Boeing does have is a process for designing airliners that makes it possible to use ordinary engineers. Think of that process as being a programming language, enabling ordinary programmers to achieve great programs.
> You need to simplify tools. But creating those tools is > complex where I need skilled people and I can't use > undereducated, undertrained and inexperienced people > there.
You have no choice but to use them. Your best bet is to keep working on those tools so they aren't so complicated. We haven't even come close to the point where programming tools can't be made simpler while retaining the power.
> That's what Bjarne was talking about. Complex tools to > solve complex problems.
I don't agree with the fatalistic idea that programming tools have to be complicated and suitable only for professionals. Jet engine fuel controls used to be fiendishly complicated, and a lot of pilots died from mismanaging it in the heat of the moment. They've since been reengineered into a simple lever that moves between "less power" and "more power." The answer wasn't better pilot training, or dismissing pilots as "amateurs". Chuck Yeager is one in a million. It was adapt the controls to the realities of real pilots.
A current programming bugaboo is multithreaded programming. This challenges the best of the best programmers. We have no choice but to come up with a simpler, more intuitive way to do multithreaded programming that regular programmers can use successfully.
How many of the early adopters of C++ were "amateurs" who helped C++ to advance to the point of being considered useful for the "professionals"?
If we were to wait for the professionals of the world to create everything that humanity needs, we would not have progressed as much as we have in all these thousands of years, that's for sure. But programming is special, I know. :-)
I think you took the post too seriously ;) Didn't you? I too will :)
I never said we need geniuses for every task, I think you understood that.
Solving complex problems requires complex tools, most of the times trying to create something simpler requires complex tools. Do you think we can create database management system with SQL? Do you think we can create operating system with shell scripting?
And yes we require 10000 engineers(Would you say we require 10000 developers to create a software product, or 10000 people?) to create a Boeing. Do they all use the same tools? Or some complex and some simpler for different tasks.
I believe different tools are required for diffterent tasks.And definitely complexity and simplicitiy are relative. Which is simpler to use, c++ or java ? To create an operating system, do we require the complexity of c++? Probably yes. For creating a web application, definitely not.We can't create everything in ruby or java or python, whether we like it or not.
>>Do you think Boeing has 10,000 geniuses doing design work? (Yes, 10,000 engineers.) Sure, there are a few geniuses here and there, but the vast bulk of the work is done by ordinary joes like you and me. What Boeing does have is a process for designing airliners that makes it possible to use ordinary engineers.
Did 10000 engineers created the process?
>>Think of that process as being a programming language,
And if the process is the programming language, how many people are required to create a programming language?
>> enabling ordinary programmers to achieve great programs.
What's a great program? Can 10000 fools create a great program?
Is D simple? Is it simpler than Java? What influenced D? Was it created for ordinary programmers?
The problem with programming is the same problem as the legal system. We have the same people who both design and implement the system. This is wrong. Buildings have architects as well as contractors. They are two different breeds. Cars have designers and mechanics, not to mention drivers. The only two fields I can think of where the same people are judge, jury and executioner are the legal system and programming. It's not a coincidence that they both suck equally and have the same problems of stagnation.
There are ideas and techniques available to solve concurrency. We've had them for over 30 years. Programmers just don't like them for some reason. And people don't like change. Especially not programmers. There are currently no high level languages and no high level programmers. We are all low level software contractors. If you deal with memory management, execution (OO, FP etc.), threads, locking or any of that, then you are a low level programmer. There's nothing wrong with that. But the thing is that we're being told lie after lie that we're using high level languages. C++, Java, Lisp, Oz, O'Caml, etc. are low level.
Bjarne was right on one thing. Whatever the next big thing is, it will enhance previously existing tools. But perhaps not in the way everyone thinks.
Oh, and programming should be 1000 times easier. A computer is a tool, and all users (programmers or not) should be able to use that computer and make it do things in a much easier way than is possible today.
The problem with programming is the same problem as the legal system. We have the same people who both design and implement the system. This is wrong. Buildings have architects as well as contractors. They are two different breeds. Cars have designers and mechanics, not to mention drivers. The only two fields I can think of where the same people are judge, jury and executioner are the legal system and programming. It's not a coincidence that they both suck equally and have the same problems of stagnation.
The solution (or at least proposed solution) to the problem you seem to be describing is what Charles Simonyi and the guys over at intentsoft are doing - intentional programming.
Most of the really early adopters were highly skilled at delivering quality software. I'd call them professionals even if their 1985-vintage C++ code doesn't meet today's standards. It might have been better for C++ if there had been more people with lesser development skills in the mix and fewer with expert-level knowledge of C. However, this is now ancient history and we live with the results. The more interesting question is then "what do we do now?" My personal answer is "trying to make C++0x as good as possible". For details of what I think that means and what I consider feasible, see my publications page.
> > I don't agree with the fatalistic idea that programming > tools have to be complicated and suitable only for > professionals.
Neither do I. I hope (probably in vain) that nobody thought that was what I was saying.
The trouble is that *many* - especially in the non-programming levels of management - dream of miracle cures, such as "just have business people outline the business rule and then generate the code from those" or "use UML; never code" or "exclusively use a really simple and really safe language and you don't need to hire university graduates" (by "really simple" people sometimes mean "simpler than the original Java"). This is seriously unrealistic, but not a complete carricature. It affects people's attitudes to education, training, and reward structures. It of course also affects people when they consider what's important in realistically complex programming languages and especially when they consider what features and techniques that it is worth while to learn and use.
> The answer wasn't better > pilot training, or dismissing pilots as "amateurs". Chuck > Yeager is one in a million. It was adapt the controls to > the realities of real pilots.
I think you are oversimplifying the issue here. And possibly confusing it through analogy.
The solution to the air traffic safety problem wasn't just better plane design. It was a whole complex mass of approaches including better planes, better airports, better airspace control, better pilot training, better differentiation of different role in the air traffic system, better controls for the pilots to use, better tools for the air-traffic controllers to use, better systems for gathering and presenting weather data, and much, much more. The results have been quite spectacular - and took many decades to mature.
As I said in the interview, many approaches can help and exclusive focus on one approach is a recepie for disaster.
And part of the solution was licensing. You just don't fly a 747 without serious general education, serious specific training, and a license.
Raising our sights from plummers and accountaints to pilots and surgeons, we realize that other professions are respected as professions partly because they have a generally accepted shared body of knowledge required by practitioners.
In theory, I'm strongly in favor of differentiation of the roles in software development, with licensing. However, I just can't see who should define the "shared body of knowledge" required for licensing tests. We would risk the some of the worst practices becoming mandated. However, I do consider "a required shared body of knowledge" as the ideal - for now, we may have to settle for an attempt to improve education and training, hopefully guided by relevant research.
With a proper usage of STL, Boost and similar libraries C++ can be reasonably easy to use by moderately skilled programmers. It is not easy for such programmers to create such libraries, nor it should be. I think that one of the most important facts about C++ is that it allows creation of very sofisticated and powerful libraries. It seems to me that most complaints about the language comes from trying to hand-craft something that's difficult in its nature by someone who doesn't have the appropriate skill level (I don't mean this in a derogatory sense). I think a good example of some of these complexities is Appendix E in TC++PL (exception safety). Perhaps we can use math as a good analogy: Algebra is much simpler than calculus, but with calculus you can solve much more complex problems than with just using algebra.
Flat View: This topic has 54 replies
on 4 pages
[
1234
|
»
]
Previous Topic
