Slashdot Log In
Bjarne Stroustrup and More Problems With Programming
Posted by
Zonk
on Sat Dec 09, 2006 06:39 PM
from the nothing-pleases-a-programmer dept.
from the nothing-pleases-a-programmer dept.
Phoe6 writes "As a follow up to the first part of his interview, Technology Review Magazine has another article running titled 'More Trouble with Programming'. Bjarne Stroustrup shares his point of view on good software, bad software design and aspect oriented programming." From the article: "Technology Review: Name the coolest and lamest programs ever written in C++, and say what worked and didn't work. Bjarne Stroustrup: Google! Can you even remember the world before Google? (It was only five years ago, after all.) What I like about Google is its performance under severe resource constraints. It possesses some really neat parallel and distributed algorithms. Also, the first Web browsers. Can you imagine the world without the Web? (It was only about 10 years ago.) Other programs that I find cool are examples of embedded-systems code: the scene-analysis and autonomous driving systems of the Mars Rovers, a fuel-injection control for a huge marine engine. There is also some really cool code in Photoshop's image processing and user interfaces."
Related Stories
[+]
Technology: Bjarne Stroustrup on the Problems With Programming 605 comments
Hobart writes "MIT's Technology Review has a Q&A with C++ inventor Bjarne Stroustrup. Highlights include Bjarne's answers on the trade-offs involved in the design of C++, and how they apply today, and his thoughts on the solution to the problems. From the interview: '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.'"
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Coolest and lamest! (Score:4, Funny)
int main()
{
cout "Hello World" eol;
return 0;
}
Very cool at first, then it just goes down from there.
Java (Score:5, Funny)
Parent
Re:Java (Score:4, Informative)
Parent
Re:Coolest and lamest! (Score:4, Informative)
Actually, the "hello world" program using the native Win32 API is:
You don't need 100 lines of code, obviously. The WinMain function can be a little intimidating, unless you consider that the parameters actually make ince. hInstance is a handle to your program in memory - you only need this if you want to dig icons or other resources out of your EXE while it's running. hPrevInstance is no longer used. szCmdLine is - you guessed it - the command line (rarely used) and iCmdShow is whether your program should be starting maximized, minimized, etc (but can be ignored.)
Granted, the 100 lines of code comes in when you want to make a "real" Windows app - have a real window that responds to events. But, all this entails is filling out a struct that describes your window, creating the window from that struct, and setting up your message queue. About 1 page of code, but it's the same for every program and you can copy/paste.
MFC makes this easier, of course, but that's C++.
Parent
Re: (Score:3, Informative)
Apart from the fact that the #includes are missing it's not C++. Shure (with the missing includes) it might compile. But it is not the way it is done in C++.
The Windows API is written in C, and designed for C. Of course it's not C++.
MFC - the Microsoft Foundation Classes - are a C++ object-oriented encapsulation of the original C API.
Besides, just correcting parent poster (who didn't use correct cout syntax, or #include . But, yes, you would need a #include at the top of your program, and you'd pro
Stroustrups (Score:5, Informative)
Re: (Score:2, Flamebait)
Re:Stroustrups (Score:4, Insightful)
Bull. At least sort of.
First, it depends in part on what your definition of computer science is. Most CS courses are taught in a C-like languages. At my undergrad institution, most of my programming assignments were done with C++. Sure, there was exposure to ML, but my impression is that most places that's mostly confined to the PL classes. (There are some notible exceptions that use ML or Scheme for intro courses.) Even at those institutions, I expect that later classes have assignments in a C-like language.
Second, there's a lot of CS that relates to C++. Compiler theory of how you implement things about it, and language design. It's not about C++ specifically, but it certainly relates.
Third, there is a fair bit of work in PL that directly relates. Not all PL is people in ivory towers coding in ML and Lisp. CCured is a very nice bit of work, though it's only C because it's built on top of the C Intermediate Language (CIL). There's early work now to create a CIL++, and I'm sure that it hasn't escaped anyone there about the potential to extend CCured to C++ once that's done. The parser for CIL++ will be something called Elsa, which was a major part of the research of one of the people there. My own research is indirectly related even. I'm looking at static analysis of binary code. Earlier work done in my group was explicitly directed to being able to find vtable pointers that C++ compilers produce.
You're right to the extent that the core of CS is really in some sense applied math, and is entirely language-neutral. However, to say that C++ has no relation to CS because it's just programming (which CS isn't about) is just wrong.
Parent
Re:Stroustrups (Score:4, Insightful)
Parent
Re: (Score:3, Informative)
Er, where did you get that from? I don't think Stroustrup ever said anything like that. See this interview [smartcomputing.com] for example:
Re:Stroustrups (Score:5, Interesting)
I don't particularly like java (and it's particularly painful watching the hoops people jump through to make it perform well), but while it doesn't seem to really be the best at anything, I guess on average it turns out pretty well -- it's pretty safe, pretty fast, pretty readable, pretty well supported, pretty widespread,
The languages you mention are all great languages, and have carved out productive niches, but they seem to remain niche languages, even in academia...
[Disclaimer: I have never written a java program (!), though I have read many...]
Parent
Re: (Score:3, Insightful)
You know why schools teach Java instead of C++? So they don't have to teach pointers first. At least that's how it seems to work at Georgia Tech...
Re: (Score:3, Insightful)
The best intro language remains to be pascal. I don't know why people get so fed up with it. Sure it's not as powerful or as popular as C/C++/Java, it's a bit verbose, but the language is clean and readable.
CFG (Score:3, Interesting)
Re:CFG (Score:4, Informative)
Semantics.
Parent
Re:CFG (Score:4, Insightful)
I suspect that's because, in the grand scheme of things, parsing is easy, particularly if you can structure your language so that it's simple to parse. It's also easy to write a textbook on parsing, because it's basically a cookbook of the usual methods with a few examples thrown in (though most authors don't seem to be very good at that part, which makes me question how much they really understand themselves and how much is just regurgitating what they once read in someone else's notes).
On the other hand, writing a compiler that optimises well (particularly in languages that don't lend themselves to easy optimisation), or a virtual machine that uses JIT compilation efficiently, or code generation engines that support compatible ABIs so you can link across programming languages... those things are seriously difficult. Even with all the effort concentrated on the big commercial tools or the big OSS players like the GCC, it's only in fairly recent times that JIT has become popular, and optimisation over the whole code base of a language like C++ is performed.
I've been interested in this field for a long time, and I've never seen a book or a set of lecture notes that come even close to the kind of detail you'd need to understand to write code that does these things. As you said, most of the standard references are just a checklist of compilation stages and a few kiddie examples of parsing that don't really convey the significance of each step anyway. All in all, I think compilation techniques are probably the least understood (and perhaps most misunderstood) of all the major programming areas. That's a shame, because we could certainly do with someone developing a good programming language one of these years! :-)
Parent
Re: (Score:3, Insightful)
What? What kind of question is that?
If anything, it's the context free grammar part of languages that is LEAST interesting and, with the arguable exception of C++, easiest part!
A language is a mapping of syntactic elements to an actual action that the computer will perform. Saying "x ? y : z" is a legal expression means almost nothing; saying "x ? y : z means that the computer will evaluate x, convert it to a boolean value; if it is true, the computer wi
Re: (Score:3, Interesting)
But then, of course, this is Wisconsin we are talking about. We tend to be practical up here, and have students learn stuff they will actually use in
Google's in C++? (Score:3, Informative)
Re:Google's in C++? (Score:5, Informative)
Parent
Re:Google's in C++? (Score:4, Informative)
http://www.robotstxt.org/wc/active/html/googlebot
When you need high performance, C++ is better choice than any other language. Google(or Yahoo) wont have a single language framework to run its platform. Always it will be combination of languages. Whatever have I read so far Google's core search engine is in C++ and several C++ libraries are available as python modules. Standalone products may be written in specific languages. Gmail and Google Calender are written in Java.
Parent
Re: (Score:3, Interesting)
Re: (Score:2, Insightful)
Re: (Score:3, Informative)
That's benchmark-dependent. For some benchmarks, under some circumstances, you can generate faster native code during execution than a traditional compiler would generate beforehand.
Re:Google's in C++? (Score:5, Informative)
What I usually say when interview candidates ask about this is that back-end and data crunching code tends to be C++, web GUI front-end stuff tends to be Java and Javascript, and scripts tend to be Python. Whatever tool works best for the job. It's not much different from what I've seen at other jobs, except for using Python instead of something like Perl. But there are no hard and fast rules. For example, there was a slashdot article [slashdot.org] last week about an internal web app written in Python. Here's an older article [acmqueue.org] that talks a bit about Google's philosophy for choosing tools. There are various articles [google.com] on Google technologies floating around on the web site too. Before anyone asks, I have no idea what the relative size of the code base in each language is.
Disclaimer: I work for Google.
Parent
Can you imagine the world without the Web? (Score:4, Insightful)
Re:Can you imagine the world without the Web? (Score:5, Funny)
Parent
Re: (Score:3, Funny)
Maybe you can. Some of us aren't that old... or have ingested massive amounts of memory modifying substances [about.com].
First web browser not written in C++ (Score:5, Informative)
Aspect Oriented Programming is a Hack. (Score:5, Interesting)
Totally agreed. AOP is a strange form of "dynamic" insertion of code at special "cut points" of execution within the code and represent a very very lazy way to avoid good OOP structure of your applications.
In a bigger framework AOP can be totally unpredictable and wreck otherwise locked and working code.
When AOP started to pick some speed in the beginning I was naturally both interested and slightly annoyed that so short after OOP here's yet another concept for programming I have to learn and implement in my software.
Not so fast though, since as much as OOP provides useful abstractions that makes your code more readable and predictable, AOP does exactly the opposite except in few very limited cases.
The cons outweigh the pros.
Re: (Score:3, Insightful)
AOP solves the N times problem nicely. For instance, if you wanted to take an object with N methods and add a call x() to each of them, if you used ordinary OOP, you'd have to override every method, then call x() from each method. What's the elegance of that? I don't see how "proper" OOP can solve this sort of problem better than AOP.
AOP is largely mysterious and confusing because it's not something (yet) integrated with any standard languages. If it were integrated, then there would be proper tool support,
Re: (Score:3, Insightful)
AOP is object oriented come from [wikipedia.org]. It can trash maintainability. In any program using AOP you can't look at any call in the entire program without assuming there's an arbitrarily large block of code somewhere else messing things up.
While it's true that AOP can help the classes of problems it solves are fairly small compared to the cost it brings. Instead, adding calls to the first/last line of method implementations is no big deal. Less consistency checking but more debugability. If all you've got is binar
Google (Score:5, Interesting)
Also, for what it's worth, Google's use of Aspect-oriented programming is ramping up pretty fast.
"Severe resource constraints" (Score:3, Insightful)
Re:"Severe resource constraints" (Score:5, Insightful)
Parent
"Also, the first Web browsers." (Score:5, Informative)
"WorldWideWeb was written in Objective-C." [w3.org]
Re:"Also, the first Web browsers." (Score:5, Informative)
Parent
Long Memory... (Score:3, Insightful)
Vividly... Searches for Hippopotamuses turned up porn. Searches for C++ turned up porn. Searches for Slashdot turned up porn...
Other than the porn, there were dozens upon dozens of pointless hits for sites that only in-passing included the search term you wanted, and perhaps not even that, as search engine databases were often years old, and sites completely changed in that time. What's more, there was never any spell-checker, so with a trivial mistake, you could be wasting all that time with the wrong term, and never find what you want.
Finding anything was laborious and extremely time consuming. Now with Google, almost ALL search engines have raised their standards near the Google level (alltheweb seems to be somewhat of an exception) and now only a tiny fraction of searches turn up page after page of pointless crap.
However, Google doesn't seem to be improving much these days, while there are obviously other ideas to be explored. On vague or expansive subjects (or just if you aren't particularly good at searching) Clusty tends to be a better bet, as it automatically categorizes your results for you, allowing you to trivially easily narrow them down... much moreso than if you just included additional categorizing terms in the search.
Yes... fondly. Links neatly grouped together in the same spot on every page, not in colors that blend in with the background, in tiny font sizes, or hidden in buggy, inconsistent javascript sub-sub-sub menus.
No god awful color schemes, or Flash-only sites. No sites that have huge columns on the left and right sides (with almost nothing useful in them) that squish the center column (content) down to one-word-per-line (I'm looking at you, Slashdot).
Never a single site that depended on your screen resolution (now all but 0.01% of websites are utterly unusable in 640x480 or below).
No cookies, no javascript, no background images, no BLINK element, no pop-up windows, etc. To make a site, you actually needed CONTENT, not overindulgent designers.
Re: (Score:3, Insightful)
I think that would be misguided. The idea of programming as a semiskilled task, practiced by people with a few months' training, is dangerous. We wouldn't tolerate plumbers or accountants that poorly educated. We don't have as an aim that architecture (of buildings) and engineering (of bridges and trains) should become more accessible to people with progressively less training. Indeed, one serious problem is that currently, too many software develop
Re:This line explains a thing or two (Score:5, Interesting)
The reason behind all this bureacratic, intrusive government oversight is that building codes are written in blood. Code specs have emerged over time because people died when buildings collapsed, or bad electrical wiring caused fires. The lesson is that if you're not doing something that could cause injury or death, go ahead and do it yourself. If not, you'd either better learn the right way to do it or hire somebody.
Code divides into similar categories, although I the decision point is different: Is the failure of this application tolerable? It may be a question of lives at risk (avionics, air traffic control, miliary systems, automotives braking/control, medical) or it might just be economic (my business stops and I lose money when our servers bug out). It's only prudent to analyze your situation and come to a rational decision about whether you want to tolerate the risks of hiring professionals (or learning professional methods and implementing them yourself), versus playing pickup ball.
Having lived through a couple of start-ups, both successful and unsuccessful, I can tell you that the different approaches do make a difference. I think that's what Bjarne is getting at: if the application matters, you'd better do it right.
Parent
Professionals... (Score:3, Insightful)
Severe ranting ahead, you have bee
Re: (Score:3, Insightful)
This stuff is not even funny (Score:4, Insightful)
Unfortunately the code I write is performance critical, so I have to put up with the nightmare that maintaining and extending a million line of code C++ project is...
Parent
It's not meant to be funny... (Score:3, Insightful)
The answer to this is not to hire unwary C++ programmers, but rather competent professionals. C++ is not a language for newbies or cash-grabbing McProgrammers, and I rather doubt Bjarne or anyone else on the standards committees has ever claimed it was.
A professional would immediately tell you that you should not rely on the order of construction or destruction for statics, that the derived class implementation will hide the base class one in your const modification case (precisely to prevent the kind of
Re: (Score:3, Informative)
Relevant parts from Section 3.2 of the cpp standard:
"There can be more than one definition of a class type
In the example provided, two translation units have definitions for struct A. However, they are not identical; in
Re: (Score:3, Interesting)
Re: (Score:3, Insightful)
And the three Smalltalk books describing it are even more pages than the C++ book, so obviously ObjC is inferior to both? What a stupid way to compare programming languages.
ObjC is a language which has a core with a static type system, which is somewhat weak because of the ease of casts and on top of that a language with a dynamic type system. So basically you have the worst of two worlds. It is neither as efficient as C/C++ nor as elegant as Smalltalk. And yes, C++ is multiparadigm, structured if you ba
Re: (Score:3, Interesting)
No, the reason is very simple, C++ was to be compatible to C and C uses pass by value as default. What kind of language would have resulted from passing variables of type int by value and objects by reference? Sorry, but I don't think I would want to program in that.
Re: (Score:3, Interesting)
The most powerful flow control construct is if/then goto. It's more power than you need.
Likewise C++ has more features than anybody needs, although most of the features may be needed by somebody some of the time.
This is not a criticism of Stourstrup; C++ simply implements what everyone thought was necessary in a high performance OO language twenty five years ago. Since the paradigm was not in widespread use, it's no surprising that the design is different from what we'd come up with
Re:Bjarne Stroustrup (Score:4, Insightful)
Sorry, no, that's false. People knew pretty much as much about OOP and high performance language implementations back then as they do today: dynamic compilation, dynamic optimization, generational garbage collection, incremental compilation, runtime class updating, method dispatch optimization, etc.
Since the paradigm was not in widespread use, it's no surprising that the design is different from what we'd come up with today.
We haven't "come up" with anything "today". What happened is that people like Stroustrup incorrectly postulated 25 years ago that efficiency was more important than good design and designed languages without what they naively considered "inefficient" constructs. We have been spending the last 25 years putting these features back in again. Today, Java and C# are almost where OOLs were before C++, except that Java and C# are far more bloated and less consistent.
Stroustrup was simply wrong, and he could have known better if he had done his homework.
Parent