Bjarne Stroustrups and More Problems With Programming 313
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."
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)
Re:Java (Score:4, Informative)
Re: (Score:2, Informative)
-If
Re: (Score:2)
Because you aren't paying attention. Javac is in the package com.sun.tools, see documentation here [sun.com].
When you're done reading, download jikes [sourceforge.net] and use that instead.
Lamest - Slashdot HTML parser (Score:2, Funny)
Re: (Score:2)
Psh, infix languages are lame. Try:
you forth love if honk then
or
(cond ((love 'you 'lisp) honk))
Re: (Score:2)
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++.
Only it's not C++ (Score:2, Insightful)
The C++ (as well as C99) standart define 0 to be the null pointer. With older C standards that was different and there where indeed some platforms with:
#define NULL ((void*)-1)
which means that
if (s && s[0] != '\0')
won't work. But that' all over now - it's the null pointer is 0 now. on the other hand C++2008 is likely to get an extra null pointer
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: (Score:2)
Re: (Score:2)
Re: (Score:2, Informative)
Re: (Score:2, Insightful)
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...]
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:2)
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.
Re: (Score:2)
I didn't say they used Java as an intro language; by the time students learn Java they've already had a semester based on either Python or Matlab.
Now, a really good intro language is Scheme (which is what was taught before the switch to Python and Matlab). IMHO, it's best to instill the idea of programming without side-effects early, and Scheme does a much better job of that than imperative languages like Python, Matlab, Java, or C.
Re: (Score:2)
Re: (Score:2)
Yes, the world will truly be a better place when it's full of people who use pointers all the time, without appreciating the significance of what they're doing, the ways to take advantage of it, and the pitfalls to avoid...
For reasons I've never quite understood, the CS department where I studied also used Java in its introductory programming courses. This is odd, given that the department in question is a focus
Re: (Score:2)
Re: (Score:2)
Junior level? No, pointers come in the third CS class, which for any self-respecting CS major is taken first semester of sophomore year. At Tech, the progression for CS majors goes "Python->Java->C" (although when I was doing it, it went "Scheme->Java->C" instead). For everybody else (i.e., engineering students) it goes "Matlab->Java," which is unfortunate because I think Scheme did a better job of teaching fundamental programming concepts than Matlab.
CFG (Score:3, Interesting)
Re:CFG (Score:4, Informative)
Semantics.
Re: (Score:2)
True enough, but to read a typical "compilers 101" book, you'd easily get the impression that it was all just parsing.
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! :-)
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:2)
Me do agree. Just syntax was a languages.
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
Re: (Score:2, Informative)
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.
Re: (Score:2)
That's probably the most succinct description of academics, ever.
Your three points just clarified that it was CS you're specifically talking about.
Re:Stroustrups (Score:4, Insightful)
Re: (Score:2, Interesting)
There is also another little spoken of field of Computer Science called Systems. Many people claim that all systems research is dead, but there's really still much more to do. In systems they care ALOT about languages like C++. More recent experimental OS' like L4 are often implemented in C++ (often ignoring the bulk of the language features). PL people even are actually very interested in languages like C++. Yes they blelieve such languages are the bane of our very existant and the fact that any sys
Re: (Score:2)
Um, Von Neumann was a hard-core mathematician.
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: (Score:2)
Re: (Score:2)
Yet another huge point here is that when C++ was designed and written it really had one goal in mind, which was to bring the wonders of object orientedness to the unwashed masses of computer programming. At the time real code was written in C, Fortran, Pascal, Lisp, and Cobol primarilly.
I followed the development in his columns, and the object oriented part of C++ was only one of many extensions to the language he was trying to create. If you list them all, most have nothing to do with being object oriented. C++ code can be written perfectly nicely with no object oriented features, and those that do exist are a subset intended to be the most useful parts (and I personally think it was influenced a bit by what could be compiled using Cfront).
Your other comment is amusing too... at t
Google's in C++? (Score:3, Informative)
Re:Google's in C++? (Score:5, Informative)
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.
Re: (Score:2)
When you need high performance, C++ is better choice than any other language.
Bullshit, C is. Assembler (just for the pedants) is too labour intensive and platform specific to be a good choice. With C++, lots of the features that on the face of them seem to be improvements over C, are in fact far less performant than C. Consider the "one size fits all" and implicit copying of the STL, or the brainfuck that is the iostream library once you actually want to format something.
Re: (Score:3, Interesting)
Re: (Score:2, Insightful)
Re: (Score:2)
Re: (Score:2)
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: (Score:2)
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.
Mars rovers in C++? (Score:2)
Yes, I think so too. In addition, I don't think, the Mars rovers certainly aren't programmed in C++ either... Would be pretty lame for the author of the language to claim credit like this...
Can you imagine the world without the Web? (Score:4, Insightful)
Re:Can you imagine the world without the Web? (Score:5, Funny)
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:2)
def blah():
x();
return foo()
return blah
for name, val in some_obj.__dict__.iteritems:
if type(val) == instancemethod:
some_obj.__dict__[name] = wrapper(val)
You'd need some other stuff to handle arguments but it is definitely possible, I just didn't feel like remembering. (also I don't know where the instancemethod type is.. in its place yo
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
Not a Hack (Score:2)
AOP is not a hack, is just one indirection level ahead of usual programming, I like to think about this kind of concepts as something that has full sense somewhere between the system and the programs.
It's not about what a program must do, it's about what should be done when a program do something.
Google (Score:5, Interesting)
Also, for what it's worth, Google's use of Aspect-oriented programming is ramping up pretty fast.
Re: (Score:2)
I prefer programming in Java, but have been doing a lot of programming in C++ recently. From my experience, while Java produce larger code and slightly less performant code than C/C++ there are many advantages: shorter development cycle (assisted by a large and complete API and you avoid many issue with pointers vs references), works without recompilation no matter the OS/architecture you are using.
"Severe resource constraints" (Score:3, Insightful)
Re:"Severe resource constraints" (Score:5, Insightful)
"Also, the first Web browsers." (Score:5, Informative)
"WorldWideWeb was written in Objective-C." [w3.org]
Re: (Score:2)
WorldWideWeb was in Objective-C.
WWW. the line-mode CERN browser, was in plain C.
Erwise was in plain C.
ViolaWWW was written in the Viola toolkit/language system.
Mosaic was early, and Mosaic was important, but to say the "first web browsers" to have been written in C++, one has to ignore the actual first web browsers.
Re:"Also, the first Web browsers." (Score:5, Informative)
Best part of interview (Score:2, Interesting)
Re: (Score:3, Interesting)
Re: (Score:2)
Moo (Score:2)
The web was created by Al Gore in 1996?
My word ignorance has passed on even to our elders.
Just a quick look at AltaVista [altavista.com]'s about [altavista.com] pages shows they *indexed* the web in 95. Of course, the Internet wasn't there before Google, so it must be bogus.
RFC 1580/FYI23 [rfc-editor.org] which was published in March 1994, contains a definition of the web.
In actuality, the World Wide Web came about in 1992 about 15 years ago.
Now, had Bjorn meant that sl
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:2)
As opposed to Google, where searching for almost anything turns up an ad for buying it on eBay, an ad for downloading ringtones for your phone, a dozen price comparison/review sites (with a dozen links each) none of which has any human-written reviews of the search item, a sponsored ad for someone selling a related item, and a reference to the Wikipedia article?
What you never knew about C++ (Score:2, Funny)
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: (Score:2)
This must be threatening to Bjarne for some reason. I submit that it is only in C++ where even a few months training is dangerous.
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.
Re: (Score:2)
Re: (Score:2)
Professionals... (Score:3, Insightful)
Severe ranting ahead, you have bee
Re: (Score:2)
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...
Re: (Score:2)
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, 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:2)
Using const when you create an object states that the object may not be modified. Using const when referring to an object is a promise that it will not be modified. The other rules all follow from these two statements.
The confusing factor in C++ is that using const qualification can have two different meanings, depending on context.
Used simply, you get "physical constancy", where the memory representing an object cannot be changed at all. This can be useful if you're working in a low-level environment w
Re:Const - the ugly (Score:2)
class A { virtual void f(const A *pA); }
class B : public A { void f(A *pA); }
quick, which functions are the following calling?
A *p = new B(); p->F(p);
const A *p = new B(); p->F(p);
B *p = new B(); p->F(p);
const B *p = new B(); p->F(p);
And that's just overloads...
Re: (Score:2)
Do I really have to find gcc to test it
It's all completely logical! (Score:2)
Nice trick question.
For one thing, C++ is case-sensitive, so your p->F(/*whatever*/) calls have nothing to do with the f members of your classes.
For another, class visibility defaults to private, so you can't call any of your member functions via a pointer (other than from within the same class).
Next up, and this is perhaps where you think there is a difficulty, there are no overloads or overrides in your example at all. The function f in class B hides the function of the same name in class A becau
Re: (Score:2, Troll)
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:2, Informative)
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.
But that is exactly what Java does. I thought it sounded bad at first too, but it works really well.
Is it so hard to accept that there might be languages which are "better" (I don't even know, if harder and needing more experienced programmers is "better") in some way or other?
When I first started on Java (I was 'forced' to learn it for a Uni class) I thought it was lame. 'How will I be able to do anything without pointers?!' After a few weeks I gave up the ghost deciding that there was a lot of stuff in Java that made life easier. C++ does need developers that are very experienced--in C++, but I don't think that necessarily makes them 'better'. As I said, it has its place in a
Re: (Score:2)
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.