Slashdot Mirror
Bjarne Stroustrups and More Problems With Programming
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."
It is,
int main()
{
cout "Hello World" eol;
return 0;
}
Very cool at first, then it just goes down from there.
Please... he's one of the most influential people in the field of computer science today, at least spell his name right.
Why try to imagine it, can't we just remember it?
Googlebot is mainly written in Python. Google is mainly written in C/C++.
Roses are #FF0000, violets are #0000FF, all my base are belong to you
I should probably add that i 100% agree with this statement
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 developers are undereducated and undertrained.
Very interesting read all together!
WorldWideWeb, being on a NeXT box, was written in Objective-C, not C++.
FTFA: I hope you didn't put too much money on it! I don't see aspect-oriented programming escaping the "academic ghetto" any day soon, and if it does, it will be less pervasive than OO. When it works, aspect-oriented programming is elegant, but it's not clear how many applications significantly benefit from its use.
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.
Javac is the coolest program written in C++ :-)
Some drink at the fountain of knowledge. Others just gargle.
Claiming Google as a cool C++ program is about 1/3 true. Most Google code is written in C++, Java, and Python: C++ for performance-critical stuff, Python for scripting, and Java for everything in between. The trend is definitely toward Java at the expense of the other two.
Also, for what it's worth, Google's use of Aspect-oriented programming is ramping up pretty fast.
Ooh, but your analogy can extend! Sure, I can go down to Home Depot and buy some interior paint to spruce up my living room, or some 2x4s to build a new deck, or something like that. But have you ever heard of building inspections? Anytime you do serious work, like an addition or a new building or even heavy electrical, you're probably going to have to get permits, submit plans, and then have a licensed building inspector come out and check your work. And it if ain't done to code, you're going to have to rip it all out and hire somebody who know what they're doing.
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.
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 last week about an internal web app written in Python. Here's an older article that talks a bit about Google's philosophy for choosing tools. There are various articles 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.
The problem is that two different translation units define two different versions of struct A.
... in a program provided that each definition appears in a different translation unit, and ... each definition of [the name defined more than once] shall consist of the same sequence of tokens ..."
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 particular, one has members that are ints, the other, shorts.
However:
"If the definitions of the [name defined more than once] do not satisfy these requirements, then the behavior is undefined."
In other words, the compiler is not required to diagnose violations of the ODR (One Definition Rule).
In this particular example, the compiler compiled bar as if doprint had a four-byte argument* (two shorts) but then threw out one of the definitions of doprint, leaving the other to treat shorts as if they were ints.
*or maybe an eight-byte argument with misc padding that wasn't cleared
Since always ... Getting a 10% performance gain in a 500,000 servers data center could mean a cost saving of 50,000 servers. On 5 servers you wouldn't bother because you wouldn't save anything. The resources we are talking about here are in essence entirely economical and pragmatical. Adding 50,000 servers is not easily done nor particularly cheap.
Look a monkey!
Um. Yeah. Er.
"WorldWideWeb was written in Objective-C."
No Google bot is written in C++. html
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.
Large part of the many (most?) business applications is glue to the system ("integration"), especially nowadays where much of the basic algorithms (supplied lib), data access (SQL), and UI are handled by underlying systems.
Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
Semantics.
What is a language anyways but a context free grammar?
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 will evaluate y and that will be the result of the expression, otherwise the computer will evaluate z and that will be the result of the expression" is what a language IS.
Even ignoring semantics, there's a large number of syntactic rules that can't be specified in a CFG. For instance, "int main() { return x; }" is not a legal C++ program, but there's no way to say that variables must be declared before they are used. "5.4 + "hello world"" is (I hope and think) not a valid C++ expression, but the CFG doesn't capture that.
The language part of the C++ standard is about 300 pages. The context free grammar is about 25. (And that's not doing much to make it compact either; that might be one column of grammar rules per page.)
I have quite a bit of experience with C++ and this example is just _one_ of a seemingly unending list of problems that bite the unwary C++ programmer. And without 10s of years of experience, there is _no way_ you can know about all of these. Some of my other 'favourites' are problems related to ordering of construction/destruction of static objects, virtual overrides becoming overloads without warning (try to change one of the arguments of a virtual function to be 'const' in the base class and what happens if you forget to do the same change to the override in some derived class?), all kinds of memory overwrite bugs caused by hanging on to pointers to memory that have been freed, being able to pass the address of an object on the stack out of a function (there is no excuse for this, the kind of program analysis done by optimising compilers could catch this easily -- the worst thing is the code often works at first but breaks much later when no-one has a clue where the bug is). And so on, and so forth...
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...
The interactive way to Go -- http://www.playgo.to/iwtg/en/
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 basically use the C core, object-oriented when you use the class system and generic when you program with templates. ObjC is also multiparadigm, structured and object-oriented, but dynamic typing doesn't need generics, so it has no concept for it.
And sorry, but the learning speed of a language is not determined by the number of symbols. Without the supporting libs you can't do anything in either and I doubt you learnt the OpenStep libs in a day. The same is true of C++ and expecially Smalltalk. That language is so small that its syntax graph fits on two pages of the first Smalltalk book. So by your reasoning you should use Smalltalk, why don't you?
Please understand me right. I don't like ObjC as you obviously don't like C++. I have my reasons and you yours. But I really, really dislike the claim of ObjC being "basically C + Smalltalk" because that is simply not true. And I have programmed in all four languages, C, Smalltalk, ObjC and C++, although the least amount in ObjC because I heard the claim "it is like Smalltalk" (which I already knew at the time before trying ObjC) and was very disappointed, no, it is not like Smalltalk. Interestingly I never heard someone claim it who also knows Smalltalk.
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.
And I always thought that was what the Java developers said, that they made the language simpler by removing the confusing parts from C++ which are rarely needed. By simple reasoning you get exactly what Bjarne Stroustrup said, no? C++ is more powerful but also much easier to get wrong. So it needs better and more experienced developers (which it rarely gets and that is in large part why C++ is blamed so often). 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?
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! :-)
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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.
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.