TR: The idea behind C++ was that programmers would work harder in return for more-efficient code. Bell Labs wanted a language that a few really smart people would use to write code that would run on computers like Electronic Switching Systems (ESS) that weren't very fast. Today, there are a lot of software developers and computers are very fast. Does that vitiate the point of C++? BS: C++ wasn't designed specifically for the large switching machines, but for a huge range of applications. Bell Labs was the home of an incredible range of interesting projects spanning every scale and using essentially every kind of computer and operating system. But yes, the average Bell Labs programmer was significantly more able than most people's notion of an "average programmer," and reliability and performance (in that order) were considered significantly more important than in most other places. Performance is still an issue in many of the applications that I'm interested in: responsiveness of interfaces, start-up and close-down time of applications. Software developers have neutralized the astounding performance of modern computer hardware by adding layer upon layer of overelaborate [software] abstractions. We seem to have hit the limits of linear speedup for hardware, but in many cases, we could win a couple of orders of magnitude back from the software. That said, C++ has indeed become too "expert friendly" at a time where the degree of effective formal education of the average software developer has declined. However, the solution is not to dumb down the programming languages but to use a variety of programming languages and educate more experts. There has to be languages for those experts to use--and C++ is one of those languages. TR: In retrospect, in designing C++, wasn't your decision to trade off programmer efficiency, security, and software reliability for run time performance a fundamental mistake? BS: Well, I don't think I made such a trade-off. I want elegant and efficient code. Sometimes I get it. These dichotomies (between efficiency versus correctness, efficiency versus programmer time, efficiency versus high-level, et cetera.) are bogus. What I did do was to design C++ as first of all a systems programming language: I wanted to be able to write device drivers, embedded systems, and other code that needed to use hardware directly. Next, I wanted C++ to be a good language for designing tools. That required flexibility and performance, but also the ability to express elegant interfaces. My view was that to do higher-level stuff, to build complete applications, you first needed to buy, build, or borrow libraries providing appropriate abstractions. Often, when people have trouble with C++, the real problem is that they don't have appropriate libraries--or that they can't find the libraries that are available. Other languages have tried to more directly support high-level applications. That works, but often that support comes at the cost of specialization. Personally, I wouldn't design a tool that could do only what I wanted--I aim for generality.
|
|
|
|
|
|
|
|
|
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 |
© 2009 Technology Review. All Rights Reserved. |
Comments
dbarthel
11/28/2006
Posts:1
bmn
11/28/2006
Posts:25
b_russel
11/28/2006
Posts:2
OsGuy
11/29/2006
Posts:2
brianr987
12/05/2006
Posts:1
DarkWater
12/05/2006
Posts:1
rjmcguire
12/08/2006
Posts:1
I find personal attacks, such as "living in denial", less useful than evidence to support your points.
asw_tr
11/28/2006
Posts:2
wakko4cpp
11/29/2006
Posts:1
Selling a finished, quality, reliable product is VASTLY easier than one on paper - and being able to sell it NOW, one can ask for more $$ than the startup who is promising it in 6 months. When you've completed 30yrs in this business, you might appreciate the above comments.
Z.
zhaopian
11/29/2006
Posts:1
The single biggest cause of programming errors is in imporper use of pointers and memory mis-management. The face that C++ allows programmers (and forces programmers) direct access to addresses and allows pointer arithmetic means that undisciplined coders have more than enough rope to hang themselves. However driver writers must have this low-level of control.
C++ however tries to satisfy device driver writers and at the same time to be an abstract object oriented language for extremely large projects. To mix bit flipping and multiple inheritence puts the burden of developing quality, high-performance, reliable software on the corporate process (The Bell Labs processes were extremely rigid and followed religiously until the ATT/Lucent disaster).
No compiler and no language can compensate for a lack of discipline in a project's software engineering practices.
appleg
11/30/2006
Posts:1
Stroustrop is not living in denial, he is merely pointing out that the trend for the last ten years has been to dumb down the languages because most developers aren't capable of handling a language that requires a large amount of discipline. Unfortunately, educators are as much to blame as anyone for this trend because they have taken the easy way out to teach job skills to get a minimum wage programming job right out of school rather than computer science.
Sadly, most people won't take responsibility for their own shortcomings and want to blame things on just about everyone/everything else. Can you write bad code in C++? Sure, no problem. The old joke of C++ enables you to create multiple instances of the gun to concurrently shoot yourself in the foot is really a truism.
The fascination with abstraction for its own sake which Stroustroup refers to in the interview in rampant in too many languages / libraries / frameworks / etc. so that the lowest common denominator can make a huge, bloated, underperforming mess of things. It's frightening to realize that we have more computing power at our fingertips than at any time in the past and yet badly written software (as Stroustrop notes) has virtually eliminated all of those gains.
I've heard developers say "first you make it work, then you make it work fast" as if performance (and security for that matter) are bolt-on items. The fallacy here is that if you don't design a system for performance (and security) from the outset, then you will not get it by hacking on it after the fact. Quoting "get there first with most" is just another cop-out for not having the discipline to do it right the first time because apparently that's too hard and takes away from the developers who fancy themselves misunderstood artists instead of engineers.
And yet there are individuals, like yourself, who don't blink an eye when saying "we just need more/bigger hardware and the performance problem will be eliminated." Now who's living in denial?
cmcknight
12/01/2006
Posts:2
Pranab
pkghosh
12/04/2006
Posts:1
Any necessary I/O or character manipulation abilities is available in function libraries, not as part of the language and so not capable of being checked for correctness as part of the language compile.
As well C does not have true arrays (arrays in C are syntactic sugar for pointers), nor proper strings (strings are just a sequence of 8 bit integers finished by the number 0), although it does have syntax for converting a character string to such a sequence.
This design (unbounded arrays, uncounted strings) has been the cause of most security problems of the last 30 years (buffer overflows only happen in C or libraries written in C, for example).
C++, unfortunately, kept the flaws in C as well as its good points. It did add many good features to encapsulate objects, and provide many conceptual tools. But in many places, raw C shows though, muddying what could have been a clean object language.
And example is the syntax for declaring a pure virtual function.
In C++ the syntax is
resultType Foo() = 0;
which confuses variable assignment with function definition (why is an integer 0 also a valid function declaration?).
It still kept the confusion in C between arrays and pointers, so that one can not declare an array with more than one dimension without declaring an array of arrays.
int A[3,4];
is an error rather than a guaranteed contiguous piece of memory on which slices and other array functions can work efficiently. Fortran still handles mathematical calculations more efficiently than C.
The main reason C++ is used today is because it is an extension of C. Its problems are also for the same reason.
BRoyds
12/05/2006
Posts:1
If you had done any assembler programming you'd know that many assemblers terminate strings, defined as a sequence of characters, with a null character. Long before there were OS functions that handled output, characters were sent to the output device one at a time in a loop that terminated when the null character was reached.
Your ignorance continues by saying that the libraries cannot be checked during compile. Apparently you know nothing about compiler design, or you'd know that the prototypes are checked as tightly as you direct the compiler to check. The functions in the libraries have already passed a compile and do not get recompiled. If they fail in your program, it's because the maximum syntax and language checking was not done while these libraries were compiled to begin with.
C++ was originally "compiled" to C code and then the C compiler compiled it to object code for the linker.
You may have limited experience with languages, but some of us do not. I've worked on platforms ranging from a Cray-XMP to an IBM 4381 (and later a 3090). I've programmed for four-bit and eight-bit processors including the 6502 in the Apple II, the 8080 in several machines running CP/M, the Motorola 68000 in Macs, and all incarnations of the intel x86 product line. I've done systems programming for the IBM AS/400 and for customized linux installations. I ported compilers to oddball platforms when many did not exist and still don't.
Programmers who were taught to write quality code and who told bosses who wanted quantity over quality to get lost often lost their jobs. The mass market demanded software, and they got what they asked for. In fact, I can't think of too many products on the market that don't fit that paradigm.
Crap will be crap until people make it better.
zhrinze
12/09/2006
Posts:1
To sell quality you need a market that wants quality.
I think there are markets where quality matters, and where it is demanded, eg in consumer electronics.
All the ideas how to develop high quality depends on someone demanding it. That's it.
gandor
12/12/2006
Posts:1
TechMonk
12/06/2006
Posts:1
I think that the problem that people generally have with C++ is that they don't truly learn it before using it. Languages such as Java and C# protect a person from the typical mistakes that can be made in writing C++ code (garbage collection). However, that isn't to say that the very same people write good code in Java or C# either.
I enjoy writing code in C++ because of the challenge it gives me. However, languages such as Java and C# are not inferior. Java and C# are from a different era. I don't like all this negativity towards C++. I feel that it's unfair to make a critical account of the differences between C++ and C# because of the difference in maturity of both languages. Could one compare a mobile of ten years ago with one of today and be making a fair comparison?
I conduct many code reviews within my organistation and I'm finding that more and more people are making silly mistakes in C++ because they are also using C#. I also conduct interviews for Senior C++ development roles and find that it's almost impossible to find enthusiastic, experienced senior C++ developers. Interesting...
mthomas
01/15/2007
Posts:1
1. The programmers involved in a project had no OOP skills and this is a time bomb for a C++ project. You can write C code without reading tons of books and articles, but an efficient OOP design requires some experience and good OOP skills.
2. The project was not so important in terms of reusability, maintainance, testing or so. If you just want to code and delivery to client, then the lifecycle of C++ programming seems to be longer than C. But if you write code for a huge project which spread on multiple years, with multiple changes in requirments and request, you can see better advantages of OOP programming.
C++ has clear problems which Java and C# solves, or, more exactly, their VMs. But C++ remains a great OOP language for those wants to use it properly.
pcr
05/30/2007
Posts:3
bobhargraves
11/28/2006
Posts:7
If there is no need for a language with the "dangerous" capablilities that C++ has, what language do you suggest the byte-code interpreter be written in?
A relevant analogy might be the way, in the Middle Ages, Latin was used for certain highly specialized topics (law, medicine, science), and the local language for general purposes. This approach was abandoned in favor of using a single language with special terminology for certain topics.
Instead of having multiple programming languages, wouldn't it be better to have tools that help make sure dangerous features are used properly? Such tools could restrict the use of built-in arrays to certain files, or flag all usage of "new" for careful scrutiny during code review. This would be analogous to the editor who checks to make sure that medical or legal jargon is not being used in a general-circulation newspaper.
wkaras
11/28/2006
Posts:8
To be fair, you'll have to admit that languages like Pascal, OCaml or Ada have been around for years, and they all have either bytecode interpreters or native compilers written in Pascal, OCaml or Ada.
b_russel
11/28/2006
Posts:2
wkaras
11/29/2006
Posts:8
C certainly does have its place, and perhaps C++ does, too. But people use both far outside of the domains for which they work the best. If you're at all interested in safety, abstraction, and preventing stupid errors---and such things are probably more interesting than absolutely maximizing performance for all but a few things---then languages like Haskell, OCaml, Ada, etc. are easily the right choice over C.
No amount of code scanning is going to make it as easy to write correct programs in C as it is in those languages, and the performance advantages of C are shrinking as well (hell, they may disappear when we end up with lots of cores, which can be used easily via data parallelism in higher level languages, but requires lots of confusing threading to use in C).
dolio
11/30/2006
Posts:1
Generally speaking, not doing something is easy, regardless of the language you are not doing it in. It seems likely that using a single language with support tools to control if/when certain features are used is more simple/flexible/conducive to economies of scale than using multiple languages with multiple "safety" levels.
wkaras
11/30/2006
Posts:8
The problem, is that C++ is an unnice language, and while I'm a college dropout (which happens to know C++ anyway), there is a disturbing aspect about the people I'd accept on a C++ project. Hmm. 2 guys I know which could discuss the finer points of generic programming in C++. And one guy with whom I debugged memory errors in a huge C++ app.
Guess what these guys all have in common. Let's start, guess a Ph.D. in CS and a good number of years of work experience?
The problem basically is, that the lowlevel stuff is well enough covered by other languages, e.g. C.
And all the high-level stuff is scary enough without being added-on to an "unsafe" base language.
Now my current project has reminded me, that developers can be the "enduser" too (if one does a language or framework), and one needs to consider their requirements.
Guess what, no matter how much we want to whine about these facts, most "commercial" developers have not enough capabilities to think in really abstract terms. (Although I guess the numbers of guys knowing C++ good enough to work safely with it is still higher than count on the guys knowing predicate logic :) )
The point is, that C++ is a huge language, containing many warts in the name of performance.
Now many propose that one can program effectivly in C++ without knowing the whole language in detail. That's not so. First you have libraries/old code. You need to know everything that's in there. In theory you don't need to know that stuff by heart. In practice you do, because you need to understand it when troubles happen. Be it a cryptic error from the compiler (about not finding the right method for these types), or even worse be it an obscure memory handling bug.
So basically to repeat the problem: C++ misses completly on the requirements for 99% of commercial software developement.
And btw, software maintainability is usually the most important criteria, performance is way down the line and raises in the stack only when the stuff is not fast enough.
Now to the details, what languages should operating systems and VMs be written in? Well, C/C++/Modula3 come to mind. And even here the complexity of C++ is usually not worth the hassle.
E.g. see Modula3 for a high-level language that supports all the lowlevel manipulations needed for operating system stuff in a sane way.
Why are VMs written in C++? Who says so? Smalltalk usually has it's VM written in a Smalltalk subset. Python has it's own written in C, lua is Ansi-C too. The only one I'm not sure at the moment is Java. Actually, all the complexity of C++ makes it a bad glue language too, so the lowlevel stuff is often written in C.
(Btw, for Python, there is a project underway to express the VM in a Python subset that gets automatically compiled to C)
And well the performance myth. The truth is, that in most practical cases, using a more highlevel language, perhaps with some lowlevel helper modules (or not), is fast enough. Actually it's usually faster, at least when it comes to developers time. And with all these man months free, these developers have to time to think about better algorithms, micro optimizing and the general design of your software.
(Again my personal experience shows in at least two project that I can beat C++ performance, even for atypical tasks like parsing and interpreting huge binary data recordings in Python. And yes, in this case I did it in one third of the time the C++ guys used up before giving up on the complexity of the files involved)
So the niche for C++, where I would recommend it for a new project is very small. On the lowlevel side, C is often a better solution, as it has no surprise-surprise effect for developers. And on the high-end side, Java and dynamic languages like Python, Ruby and Perl are usually better suited.
And even for that small niche, where you need big systems with many lowlevel parts, there are other alternatives (e.g. Modula3, Java-to-platform-binary compilers).
One last thought before I close. One has to consider C++ as it is, and not as what it could be. E.g. that means usually one string class for every second library you use. Combined with the fact that C++ normally does not include garbage collection, which forces library developers to include informal memory ownership into their APIs, this leads often to a situation that a cool C++ program has to copy strings multiple times where a Python or Java program passes just a pointer around.
yacc
12/05/2006
Posts:1
When this is not appreciated, programmers in c++ suffer especially. This is partly because there are some "C" relics in the language which should never be touched in normal use, and partly because the flexibility of the language sometimes encourages an "anything goes" mentality among programmers.
Idiomatic c++ should be clear and safe, corresponding almost line for line to "high level" scripting languages like python but with dramatic greater possible performance.
There should be a preference for use of the standard library. No arrays but vectors. No char* but std::string.
There should be no explicit memory handling. Instead all programme resources (including files, memory, OS handles, painting DCs) should have clear lifetimes either by being created within local scope (on the stack) or as members of objects which themselves should have clear lifetimes. They can be managed using smart pointers (http://www.boost.org/libs/smart_ptr/smart_ptr.htm) which also cover rare cases (shared ownership, cyclical ownership etc.)
Memory handling on legacy programmes created without a clean design can be patched by dropping in Hans Boehm's free garbage collection library.
There should be no typecasting.
Naked pointers should not be used.
There are free and high quality peer reviewed libraries for regular expression matching, graphs, string handling, parsing, programme options etc. from boost.org which every c++ programmer should be familiar with.
These rules are meant to be broken but whenever they are, c++ programmers should understand that "Here be dragons" is writ large all over and should manage the risks and tradeoffs accordingly.
This is very different from what c++ programming was like when I started in the 1990s and many self-styled "gurus" and programmers haven't caught up with this new safer, simpler, library-driven approach yet.
The power of c++ should be used to write libraries with clear abstraction, great flexibility and extreme performance (again see the examples at boost). The user of those libraries should not have to worry about these issues any more than a driver of a car has to worry about fuel injection technology.
There are still many deficiencies within c++: the lack of a really well designed threading library, error messages can be truely awful even for simple errors, the lack of clean syntax for iterating over a range. There and other problems look like they will be taken care of at the next round of standardisation being completed so things are on the up.
Modern c++ is getting more powerful so that ordinary users can write simpler cleaner code.
If your own c++ code is in a mess, maybe you are being too clever for your own good?
Leo
bunbun
12/05/2006
Posts:1
Obviously, C++ isn't perfect. Neither are any of the other languages, of course. C++0x should deal with some of the very reasonable points you mention towards the end: there will (finally) be a standard threads library (hopefully well designed), a garbage collector (which can be optionally enabled) will be part of every implementation (saving people the bother of downloading one), and the spectacularly bad error messages that you can get from using templates will be eliminated through the use of "concepts". For example, see http://www.artima.com/cppsource/cpp0x.html or search for C++0x on the web.
bs
12/05/2006
Posts:6
Your comment is very fallacious. Being able to discuss the finer points of C++ has nothing to do with how many years of experience you have or if you hava Ph.D. It doesn't even have anything to do with whether you're a bookworm or a nerd or a geek. It has everything to do with whether you learn, or you want a quick fix.
C++ is not a quick fix language - you can't learn it for a specific purpose and expect to understand all it's idiosyncracies. You can learn the aspect you wanted to learn and that's about it. Unless you want to learn the langauge in general in which case it's really easy to assimilate. Granted, the ARM is a little longer than the C book, but only because it's annotated. But then again, if you understand what the heck you're reading you should be able to quote parts of the ARM. It's VERY straightforward.
Most of the other languages you see are more forgiving. You can learn one aspect of the language and it easily segues into other parts, and soon enough, but doing enough, you eventually know the rest. C++ is not designed this way. It's partitioned for specific uses. You can only know what you seek to learn.
Oh, by the way. In school I was part of pretty much every club, was one of the star athletes (soccer, volleyball, tennis, track), and was the most popular boy in school. So much for your Ph.D. theory.
One example, does not a generalization make. But it does realize one.
Cheers
kellin
12/05/2006
Posts:1
My super high-tech cell phone crashes fairly often, and it takes 2 minutes to reboot. Sometimes I wonder, what if this ever happens in an emergency situation?...in an emergency, 2 minutes is an eternity, and it can easily mean the difference between life and death. The list of our everyday software dependence could go on and on, yet whenever you buy a software package, you're always forced to accept the "...as is..." terms. In other words, the software makers never take responsibility if their crappy creations are causing you damage. I don't know of any other product category, which is sold on an "as is" basis. Only used cars perhaps...but even there you can find lemon laws, and dealers who are willing to sign a warranty.
Part of the problem is also that the software workforce is completely unregulated. Anyone can build software, and there is no societal oversight over the qualifications of these people. Society requires of most other professionals to pass certain tests - not everyone can be a medical doctor, pharmacist, lawyer or even a bus driver. But anyone is allowed to build software, and sell it.
Perhaps there should be some restrictions. Certain software applications should be developed only by coders who pass some strict tests, and they should be accountable for their creations. That would make software more expensive, but in the long term it would be worth the price. Just think of the time wasted, when next time you're installing your 'n'th Windows security patch.
gabrielg01
11/28/2006
Posts:400
Now that sounds like people everywhere!
kitk
11/28/2006
Posts:65
There are plenty of pretty robust phones with less fancy features out there, but some people always want to be on the bleeding edge and the people that choose that should be aware that bleeding edge usually means less reliable.
As a consumer you have a choice, and there's plenty of information out there about things like phones and their reliability. If you really care, do your research. Don't just select based on flashy features and then blame the developer.
hobart
12/05/2006
Posts:1
hmm... that is the same attitude you get from people I know that work on outlook when I ask
"Why does the entire outlook application hang when all I want to do is get contact info real quick, why does the user interaction level of an application (especially calendar and contacts) is tied waiting for the syn/ack communication with a pop server? The response I always get "well, it works with exchange server".
This is a running joke I have with a few I know on the MS Office team that they are not competent enough to fork (CreateExceve) off some network process and do some IPC...
getting back on topic...
the point I am getting at, if you sell something and advertise it to do such is should do such. Most CONSUMERS want products that work as advertised- that is all, that is all consumers want. If your organization does not have the self-respect to deliver on a simple request... your organization is not technically capable and has no honor </rant>
parksnj
12/05/2006
Posts:1
The first breeze of change will be a requirement for professional registration for software engineers and certification of code by someone so registered, just as in the other major fields of engineering. Then comes the whirlwind. How to certify the code is unaltered? Who made what changes and when? Which revisions are certified? Which combinations of operating system and code are certified? Which OS patches are authorized with which code revision? How to hold foreign people/companies accountable?
Maybe when a few companies are bankrupt with their Chief Software Architects serving jail time, maybe then people will learn how to create rigorously designed, stable, well tested, maintainable, traceable code. Maybe... just like the other fields of engineering.
ctommmey
11/29/2006
Posts:1
richparisi
11/29/2006
Posts:1
cohesion
11/29/2006
Posts:1
NutSoft
11/29/2006
Posts:1
ensiferum
11/29/2006
Posts:1
cmonkey
11/29/2006
Posts:1
But accountability and reliability of software requires different approach to engineering and much longer development cycle. Engineers at Boeing or Lockheed might have 100 pages of documentation and specifications per 1 page of code. Customers seem to demand new features and faster changes rather than rock-solid software with provable reliability.
If software develpers were completely accountable we would have been using windows 3.11 still. Except it would never crash
alex_ognev
11/29/2006
Posts:1
As an analogy, let us consider a football stadium. A football stadium is a system of components comprised of raw materials that are assembled on a solid foundation. It is a system that tens of thousands of people interact with simultaneously several times per year. If this system experiences a large-scale failure, thousands of people can potentially die.
Now let's consider the traditional processes involved in developing a football stadium. First, a team of architects will spend, in some cases, several years developing and refining a high-level design. This high-level design is then passed off to teams of engineers from many different disciplines to develop and refine detailed design specifications. For the structural components (steel beams, columns, girders, etc.), a team of detailers use the design specifications to develop the blueprints describing with exact precision how each and every structural component should be built. Each blueprint must then be reviewed and approved by a certified engineer. The blueprints are then used by a steel fabricator to fabricate and assemble the components. These components are inspected by quality control personnel to again insure specifications are followed with exact precision. The components are then erected (assembled) at the jobsite, inspected and signed off on by certified engineers.
This is a very methodical, lengthy and expensive process. It is done this way to insure low-failure rates in the resulting structures.
How many of us enter a football stadium worried that they may not make it out alive? Not too many I hope. We don't think about it. That is because failure rates for such systems are so low that your chances of being killed on the way to the game are higher than being killed due to a failure of the stadium. But wait a minute, the traffic control system that safely guided you to the stadium is a software system. Did you worry about a failure in that system. No. That is because that system is truely critical to the safety of human life and was developed with the same level of scrutiny as the stadium. Again, you do not think about these issues because failure rates in these systems are also extremely low.
Do you really expect your cell phone to be developed with the same level of rigor? If it were, there would be few in the world that could afford to own one. And if it were developed this way, it would have to be a tightly-controlled closed system. There would be no downloading of ringtones, add-on software, music, video, etc. Any of these bells and whistles exponentially increases the potential for failure in the overall system.
I would agree that more accountablility is needed in the software development community. Unfortunately, that is hard, if not impossible, to do. Today's software is built on top of soooo many layers of software that it is near impossible to determine where the source of failures originates. There are limitless combinations of hardware and software that make up today's computers. How can I as a developer write software and guarantee that it will work on any and every system when the mix of hardware and software make each system virtually unique. Going back to the construction analogy, this would be like asking architects and engineers to design and build a structure that will work on ANY concievable foundation. You wouldn't do that. You couldn't do that and expect the resulting structures to maintain low-failure rates.
Just my $.02 worth.
caseychester
11/29/2006
Posts:1
Comparing Software development to other engineering disciplines and indeed other professions is a mistake. It is a different animal that needs to be considered in a different light
morr0339
11/29/2006
Posts:2
I suggested quality regulation only for the "backbone" applications: if operating systems and general productivity software fail and cause material damage or worse, then the producers should be at least partially liable.
I also think there are a lot of frustrated people out there, who would gladly pay a higher price for stable, rock-solid software.
gabrielg01
11/29/2006
Posts:400
I definitely think greater accountability is needed. How to go about it is another question, for which I do not have a good answer.
cmmdevries
11/30/2006
Posts:1
manager: "great! how long will that take?"
mbloore
11/30/2006
Posts:28
gblock
12/21/2006
Posts:2
In addition, I think you cannot fairly blame the software community and not level your sights also at the consumer for their part in this economy. In any market the consumer is responsible for investigating various products to determine fitness before purchasing. Looking for a reliable cell phone? Compare before you buy. I'm always telling people who ask if I recommend the Treo (I use one) that if they just want a simple phone that doesn't crash they should buy something else. If they die in an emergency because their Treo crashed, they cannot blame Palm.
On another track, it seems unlikely to me that the legislators are going to do anything to compromise the competitiveness of the software industry. Requiring that everyone and everything be certified and audited will put a huge chunk of the software industry out of business. This will hurt innovation, the economy and reduce tax revenues. ;-)
CarlGundel
12/29/2006
Posts:1
desertRose
11/29/2006
Posts:1
So there are fundamental technical reasons to choose one language, toolset, OS, or platform over another. Each has its place in the world. And the success of one language is built on the shoulders of another, C to C++ to C#. These are understood by science and not speculation. However, I do agree that a lot of Jr. Software development is more Art then Science. But a sound platform of understanding and science does yield impressive results. Just look at Google.
OsGuy
11/29/2006
Posts:2
These small pieces act as the glue between the higher level languages we all love (C, C++, C#, Java, ...) and the microprocessor. No mass-manufactured CPU I know of has an interrupt handling sequence that melds perfectly with a C function as compiled by (say) the GNU compiler suite.
Each OS, has, at its lowest levels a smattering of assembler to bridge the gap between electrical hardware and the CS-abstraction of computer languages.
The scary thing is that because this 'glue' is so thin there is very little need for the majority of developers to ever learn, or understand, it.
gordy
11/30/2006
Posts:1
The challenge is in taking the necessary time to nail down the requirements, create a design, and implement / test to that design. Too often non-technical management creates an impossible deadline and nobody has the spine to say it's not possible and stick by that.
What business really needs (besides a heavy jolt of reality) are the tools to allow the business people to write business specifications that get translated into applications. Yet most developers decry "code-generation" as the antithesis of their existence. So you have two opposing forces, the business side of things (usually non-technical) and technology side of things (usually no concept of how business works) contributing to an equally bad situation for all sides.
cmcknight
12/01/2006
Posts:2
There is indeed a serious lack of understanding (and of communication) between the technical people and the business people. This is often made worse because the business people typically control hiring, policies, and funding.
So, the views of management can be self fulfilling: Management often underestimate the complexity of the technical problems, the technologies needed to cope with them, and the degree of skill and education needed to cope. When that's reflected in the hiring policies and promotion policies, the technical people will be less capable and less professional than needed and their voices wont be heard in the meetings where decisions are made.
The net effect is often a fevent wish for (leading to a belief in) miracle technologies and a disdain of technologies that only "help a bit". This happens to both technical people and business people. IMO no technology is going to do more than "help a bit". We need a balanced
mix of technologies and people with the skills and professionalism to apply and manage them. That's a serious and difficult challenge to the management community, to the technical community, and to the educational community. What hope I have comes from the observation that these communities are not completely disjoint.
-- Bjarne Stroustrup; http://www.research.att.com/~bs
PS on the specific issue on generating code from "business specifications" my view is that it's great when it works, but people tend to seriously overestimate the range of application areas in which it works and underestimate the difficulties in writing a good specification. Generating acceptable code from specifications (of various forms) has been an alluring promise for at least 30 years, but has had only limited successes. "Model based development" was one of the technologies I listed as "helpful in specific areas" but "but pushed as the solution to the
exclusion of other approaches, ... guarantees failure in large-scale projects".
PPS. I served for 7 years as department head in industry and was given a basic education in business management to help me cope. However, I'm basically a geek.
bs
12/02/2006
Posts:6
if anyone is interested in discussing such stuffs are welcome at: www.egzone.info
or visit my blog and opne a new thread where we do have many domain experts in their respective fields at: www.egzone.info/blog
EGZone
12/06/2006
Posts:3
Hacking your way to a quick solution is ART. This approach provides quick payoffs and higher cost of ownership; maintenance costs, faster more expensive hardware, lost productivity and data due to software crashes. Software engineering is science. It costs more up front, you need better paid professionals and the long term benefits are hard to recognize. The business people of the world can make the choice over which they want. Well, I guess they already have.
-- Harvey Sugar; http://nerd1951.com
nerd1951
12/22/2006
Posts:2
Robert Tischer
rtischer
11/29/2006
Posts:3
Rather, the best programming languages, from my standpoint, serve the need to specify behavior with precision, but not at a cost of generalization and reuse. And, good languages are designed with some thought to learability (which begs the question, what is foo?)
Would I like to see learning machines taught skills naturally thru their sensory datastreams, left to write their own internal symbols?
Sure, but there will be some odious tradeoffs. Unique computer individuals of this type have a private symbol system not sharable (except in its entirety). So, there won't be the "knowldge pill" capability we enjoy when downloading
plug-ins. Plug-ins are only possible because symbol compatibility is prearranged for by human agreements. The same applies to applications, which are OS plug-ins. Incompatibility, and how to overcome it, has been the bane of software going back to ENIAC.
I think S.I. Hayakawa (semanticist) was way ahead of the people studying formal grammars like Chomsky. Hayakawa says that the meaning of audible words and utterances are the situations in which they have previously been used. This suggests that situational awareness and memory is a prerequisite to learning and understanding natural communication. That spoken words are an indexing system for evoking recall of experience. This runs totally against the notion that meaning is carried in the utterance itself (modeled by Chomsky/Shannon as a sequence of tokens).
The adoption of ASCII symbols as computer input (as opposed to more face-valued camera or auditory datastreams) likely set the field of AI back 50 years, and is an example of the "quick and dirty" school of computing Bjarne is challenging. I totally agree.
The stakes are very high, now that life depends on software.
I would very much like to see the "anything goes", libertarian mentality (nobody is accountable) of the software industry replaced with some system of checks and balances.
Programmers know they are working in an extremely powerful medium, but are reluctant to have the value of their inventions debated in a larger context. Evil genius grows in such an unfettered environment. Witness the long reach of global computer crime -- clear evidence that software adhocracy is becoming an "experiment gone bad".
pbierre
11/29/2006
Posts:2
With his many C++ human semantic constructs (class encapsulation and protection, method overloading, operator methods so 'object3 = object1 + object2' looks like '5 = 2 + 3', exception vs. error handling balance, polymorphism, abstract base class, etc.) Stroustrup was able to allow the programmer to express the subtle connection of concepts and linguistic habits into code text. Imagine what he could have done if his implicit language goal had been front and center instead of brought in through the back door.
Any Psycho- or SocioLinguist will agree totally with your reference to S.I. Hayakawa, the semanticist, that meaning is squarely related to the situation of the declaration itself (context). Sort of puts after-the-fact data mining into perspective as being an exercise in meaning futility. The name for the theory that it is the declarative sentence that carries the meaning, is the 'talking heads' theory and goes all the way back to the father of linguistics, F. Saussure, and his linguistic circuit. Chomsky had the chance to include meaning in his "Syntactic Structures" science, but, being the positivist he and the times were, he couldn't find any convincing science that described it. Hence, he thought, no good science? Ergo, it doesn't exist (for real). But, of course, we know it does. The rest is software history.
The fundamental flaw with the compiler is that, assumed higher order language concepts are the 800 pound gorilla that needs to be put on the table. Granted, ontologies are being cranked out by "language authorities" by the ton. Unfortunately again, they have fallen prey to yet another first year PsychoLinguistic language fallacy: esperantoism which expresses the naive view that if we all just spoke the same language, communication would be perfect. This is also called the 'fixed code' theory. For example, just look at the amount of work done on the Dublin Core, a simplistic set of "universal" concepts, to see how feckless knowledge science is today.
The obvious answer to the compiler dilemma is for the compiler to be able 1) to connect and maintain connections to the original (Hayakawa) meaning situations and 2) to be distributed so that executable code could be emitted as a distributed choreography of executables that support and make societally sharable and explicit, the higher-order meaning constructs that everyone, including Bjarne, uses.
rtischer
11/30/2006
Posts:3
I suggest that what you are currently experiencing is string of tokens that approximately conform to a Human Grammar system called the English Language. What do they mean to you? Do they mean the same to you as they do to me? What is the meaning of meaning ...? Is this question decidable?
The Category Grammar and the Category Semantics are different Human concepts. A Grammar instance may have no Meaning to one person and some Meaning to another person.
A string of Mandarin Grammar Ideograms about elephants has no meaning to me at all. That does not mean it is not a perfectly meaningful expression to a person that understands that Grammar system.
One the other hand, one person may Visualise African elephants the other person may Visualise Asian elephants and a third person may Visualise Pink elephants all triggered by a symbolic representation of the token "elephant" in a particular Grammar system, depending on the person's life experience to date.
Human Meaning is the Collection of Relations between a Human Symbolic Grammar and Human Experience.
If you prefer a more geometric "picture", Meaning is a Subspace of the Hyperplane between the Hyperplane Grammar and the Hyperplane Experience.
All such Hyperplanes are Symbolic anyway. The Human brain does not contain facsimile slide shows of visual experience, or collections of soundwaves somehow stored and resonating in our heads. These experiences are all transformed into internal symbolic representations somehow in our neural networks and maybe even in other aspects of our cell bodies, organs and functional systems.
So your plea for some kind of early camera input system into computers is beside the point, all the information would have to be transformed into a symbolic representation to perform any type of computation on the data. Computers don't do any thing else except compute, apart from shuffling data about the place. To compute you need an algebra, a set of rules about symbolic tokens, a symbolic grammar. All current computers are Turing machines using Boolean Algebra and higher Algebras at higher levels of abstraction.
What is one picture of a tree + one picture of a cheese cake ?
How are you going to combine them? What is the Algebra?
What does the combination Mean?
A cheese cake up a tree? Maybe some rules of symbolic geometry are being suggested? Such geometrical algebra ideas are hundreds of years older than "computers" but they are beside the point.
So as for photographic or video pictures instead of ASCII what is the relevant algebra of pictures? Are you going to add up your tax return in pictures?
The tax department would not be impressed!
In fact they might be tempted to say it is all "cheesecake" and increase your tax bill for good, symbolic, measure.
In fact you are going to add up your tax return in pictures they are just special symbolic pictures called "numbers", agreed by conventions of semantics, experience, to have an agreed meaning, although a rather abstract and generic meaning.
You could use more direct facsimile symbols maybe pictures of lots of sheep, or chickens, to represent how much tax you need to pay or get refunded. I guess we have moved on from such very direct facsimile representation systems a few thousand years ago.
The fact that in the 1950's - 1960's when ASCII was introduced memory and processing capacity was a little bit scarce is not really the semantic point but it may just have had a little to do with the engineering reality at the time.
So we haved moved away from the issue of programming language goodness or badness by introducing issues of facsimile repesentation of experience into this symbolic dialogue. So now please visualise a "Red Herring". What "Colour"is it?
I hope this has been a joyful semantic, symbolic experience for you.
Here is a hand waving, "goodbye".
Curious
12/01/2006
Posts:1
rtischer
12/04/2006
Posts:3
http://www.edmblog.com/weblog/2006/11/the_problem_wit.html
jamet123
11/30/2006
Posts:5
wkaras
11/30/2006
Posts:8
One is the "Agile" methodology's focus on the developer talking directly to the end-user. This allows the programmer to use the language and schema that make sense to the end-user.
The other is the use of DSLs (Domain-Specific Languages) to allow the end-user to describe what they want in something close to their own words - the programmer creates something that interprets the end-users words to cause the intended action. It is specific to a particular industry and is essentially throw-away code if applied to any other industry - but it allows the end-user greater access to the levers and dials of their business.
C++ is a good language and fulfills much of Bjarne's intentions but its in-memory schema representation using structs breaks down at the point where we want to persist it to disk. Ruby-on-Rails turns the schema representation of persistent data into executable in-memory structures. C++ moves forward from C toward both elegant and efficient code but when push comes to shove it leans more toward efficiency; Matz has pushed Ruby towards elegance at the intentional expense of run-time efficiency (see http://www.cs.byu.edu/colloquia/2006Fall/presentations/Matz_slides/mgp00001.html).
Its an interesting gamble - I'm interested to see how it turns out. It may be that, as some of its proponents say, the ever-changing functionality can be written so quickly that the extra time can be used to address bottlenecks. I see many instances today of well-optimized C++ code that gets dropped on the cutting-room floor as requirements change. I'd rather write and throw away un-optimized ruby code - it hurts less when you chisel it out of your masterpiece.
jbaylor
12/05/2006
Posts:1
If the Ruby language is really resolving the problems of schema encoding and matching to allow for natural language understanding, I'm sure we'll soon be reading about that as front-page news.
For the time being, successful SW development will depend on programmers and application experts holding up their end, and understanding that each needs the other. Or, they can not do this, fail, kick the dog, and blame the programming language.
wkaras
12/06/2006
Posts:8
My congratulations and highest regard to Bjarne Stroustrup and all those who have contributed to the power, flexibility and undeniable success (and continued evolution) of C++ (Lippman, Sutter, Meyers, Josuttis, and Alexandrescu come to mind).
mtimperley
12/05/2006
Posts:1
I don't think Jason Pontin was at all unreasonable about C++; after all, his job is to ask questions that interest people and help elicit useful information in answers.
bs
12/05/2006
Posts:6
The industry has evolved. Systems have become continually more interconnected, and interdependent thus requiring increasingly diminishing turn around times. With this has also come an increasingly high demand for new talent, faster than the industry can keep up. Languages such as PHP, C#, Java, Ruby, etc have greatly reduced turn around time for developing applications. Additionally they have made software developmetn more approachable to a wider mass.
Now I totally agree that this is a double edge sword, in that it has allowed those with "no business" programming to enter the industry. But at the same time they have allowed the industry to meet the demand.
gblock
12/21/2006
Posts:2
The acme of professional skill for the coming decades is going to be to push the envelope of the cheap-fast-good space. This is going to be largely a matter of getting semantic gaps out of the development process and changing the economics of maintenance so that "doing the right thing" is rewarding to the decision makers. But I believe that we're going to have to live with the paradigm of "the cheapest and fastest that's marginally acceptable" for most applications, for as long as I can forsee.
Nathaniel Fi...
12/05/2006
Posts:1
I think the problem, however, is that over-application of this mantra can lead to the act of programming becoming the end rather than the means to an end. Design patterns based on best practices are a tremendous help in this regard. After all, the whole point of classes was to make code more re-usable and maintainable. If you're spending your time writing something that someone else has written, debugged and provided as a design pattern, then you are a fool.
In my opinion, it is relatively easy to write good C++. I'm a gung-ho type of programmer who likes to jump in and get going once I have a good mental understanding of the application specifics. Of course I end up re-factoring fairly often, but that's the case even on projects I've been involved with where there were long (6 month+) technical design phases with many programmers contributing. It's nice to put that much thought into something, but frankly there's no way to foresee every eventuality.
It's a lot like chess. Every move is calculated as far in advance as is *practical*...but there's no way to see the checkmate before you move your first piece.
And honestly, it doesn't matter if you're writing C++, Java, BASIC, etc. A language that protects you from yourself does not automatically make better software and in fact can have the opposite effect. In that sense, unmanaged C++ is among the last totally "pure" programming languages. (Hey you allocated that memory, delete it yourself!)
IMHO.
-John
jnagle
12/05/2006
Posts:1
Actually, I rarely delete my memory directly any more, nor indeed allocate it. I leave that to my containers, and to my constructors and destructors. Contrary to the common view, C++'s resource management was always "semi-automated".
bs
12/05/2006
Posts:6
"...tools have the unfortunate tendency to backfire (Easing the correction of errors immediately leads to more errors being made)" -Edsger W. Dijkstra
marcodorante...
12/08/2006
Posts:1
I have wondered, would C++ have been easier to learn (or teach) if the language was developed without using C as its overlying context? C++ would be a separate language without any care in the world for compatibility with C. Would it differ from the C++ we have today in terms of keywords, syntax, semantics, ...?
C++ works nicely, but it is also filled with narrow contexts, making it difficult to generalize.
ars
12/06/2006
Posts:1
It may be easier to teach and learn a language designed from scratch from first principles. It can certainly limit language complexity. However, people rarely learn just from first principles - they build on an amorphous mass of prvious knowledge and skills. Both Simula and C++ built on existing knowledge and skills to make adoption easier, to benefit from existing tools, and to avoid accidentally leaving out something important in an attempt to eliminating "old-fashioned and useless" language constructs.
IMO, it is far easier to design a language than to get people to use it; especially if you don't have a marketing budget.
bs
12/06/2006
Posts:6
I wasn't convinced that he didn't make ANY trade off between runtime performance and programmer time!
Believing that there is no need to trade off between these things means that we don't need to develop programming languages at all and a programming language developed ages ago would compete head to head with any programming language developed today!
And I can't see why being "designed for a huge range of applications" is a good thing, I can't see the need to write hardware drivers and financial software in the same language, all we need is good interoperability between software systems.
foaad
12/06/2006
Posts:1
C++, to me, is a kludge, when taken in total. At the fundamental level, though, it's elegant.
I work in a world in which domain experts write code for use in their domains. Most of these code writers aren't professional programmers; they are domain experts. Most still write in FORTRAN! As a result of the use of FORTRAN, if someone writes a simulation of an object -- think of a car in a video game -- it's impractical to wrap it to create a class for a larger-scale OO-based game. I beg these good people to just learn procedural C++, which is a trivial effort for a decent FORTRAN programmer. I figure, once they're comfortable working at that level they can grow gracefully into OO. It's a tough sell because they've heard that the OO languages, especially C++, require a huge time investment. My point is this: you don't have to use most of C++, even if you're doing OO, to get a huge benefit. You can learn to use your subset well and stay out of trouble. Of course, that means learning by doing, and, unfortunately, there's too little of that in the formal education process. We tend to take one or two courses before we try to do anything productive. We are being set up by the system, being handed all the rope we need to hang ourselves. Is that BS's fault too?
One last parting shot: I've seen more disasters from mistakes with pointers than with OO. (Obviously, I'm not talking super-large-scale software here.) Should we add Dennis Ritchie to our hit list along with BS?
tnaff
12/11/2006
Posts:1
I'm a hardware guy so I'm no expert on the latest OO languages, but I find that the landscape is littered with too many languages and tools. None of which help me to get my job done any faster.
My ideal language would be semantically simple (ala Perl without the confusion that Perl creates by reusing keyword tokens), Self-checking (why can't the IDE lint the code as I'm typing it in like a good word processor; formal methods should be part of the language -- the tools should check the 90% of the code for common errors, tests should be easy to create).
In hardware development we use automatic test pattern generation and formal methods to debug our code. It's not fool proof and requires much effort, but a simpler system for software development should be created. I've been writing code for 20 years and haven't seen any great improvement in productivity. We're still pounding in code one line at a time on the keyboard.
WhiskeyRebel
12/12/2006
Posts:2
pcr
05/30/2007
Posts:3
apolkhanov
12/14/2006
Posts:1
wkaras
12/18/2006
Posts:8
What about O-O? Maybe in 80's it was a big deal to choose beautiful Ada without O-O or awful monster with O-O. But nowadays it's not an issue. I don't care what was in 80's. Here and now I have Ada 2005 with dynamic polymorphism, tasks, protected objects, Java-like interfaces, task interfaces, genuine modular architecture and so on...
OCTAGRAM
04/01/2007
Posts:1
The reason C++ is so difficult to use is that it allows an intelligent and educated software engineer to choose the best implementation strategy from many approaches. C, Java, and C# are simpler to use but limit these choices. So for embedded systems I'll take C++ every time, if I'm given the choice and thank you Bjarne Stroustrup.
-- Harvey Sugar; http://nerd1951.com
nerd1951
12/22/2006
Posts:2
Cool colors and graphics dazel the end user and managers.
Performance and proper coding practice gets overlooked.
i don't think c++ is to blame. It's just not the right tool for most of todays apps.
grid0lock
12/28/2006
Posts:1
I found reading the comments from 'bs' and others here intriguing, but some of the latter forget about that. I used to be a Java programmer. And then I awoke from my (brief) dogmatic slumber to C++. Thought I'd chime in about it; that's about it.
tmharada
01/12/2007
Posts:1
JF
02/26/2007
Posts:1
pcr
05/30/2007
Posts:3
The reward of a great program running flawlessly ought to give programmers pause.
Entrepreneurs attest to American’s disgust of the inefficiency of our working structure. Their efficiency is a far cry from the sloppy craftsmanship of Corporate America. Sad. We could, and should, do so much better. All we need is freely given to us at our fingertips – and very few seem to get it.
cappi101
09/13/2007
Posts:1