I *do* maintain a program without a strict OEOE rule, and it *is* quite feasible; we've been doing it for many, many years now. There are several places where we have things set up OEOE-style because it helps the algorithm, but we really don't need it *everywhere*. There are lots of functions where OEOE would be an imposition that does not arise from any real need, but from blind adherence to coding "standards".
We write source code to solve problems in a way that other programmers can understand. If there is a function where OEOE doesn't improve a reader's understanding, why use it?
And yes, I'm quite aware that dynamically allocated objects will not be automatically destroyed upon exiting from the scope of their allocation, because such objects don't have a "scope". That's why you *give* them a scope by using smart pointers.
I think we're working with slightly different definitions of the word "crash". When I think of a crash, I think of a program that was terminated not of its own volition, but by the operating system in response to, say, a memory segmentation fault.
assert() is (usually) a macro, and you can define it to expand to whatever you want. By default, it usually expands such that if the tested expression is false, then exit() is called after some debug message (like "failure in foo() at line 1234") is sent to stderr.
I *guess* you could refer to the call to exit() as a "crash", but to me it seems like deliberate behavior. In other words, the exit() call itself is not a sudden failure. The failure happened -- silently -- long before we got to the assert(). The call to exit() is done to limit the damage of the failure and to aid the programmer in debugging.
Now, an assertion failure doesn't have to result in a call to exit(). It could result in a cute GUI pop-up window that says, "sorry it didn't work out; please fill out this form that we'll send back to the developers. Try to give as much relevant info as possible." And that could be sent back to the developers along with a core dump. A lot of developers have chosen this route, and it seems like a valid one. In a debug build, an assertion failure could instead result in a call to a function that pauses execution and launches an interactive debugger; this too is valid.
But I think it's unhelpful to try to convince people that "assert will just crash the program" for two reasons: 1) assert() is only a messenger, and the programmer is always in control of how that message is to be delivered, because she always has control over the definition of the macro. 2) you're going against the writings of the experts, and if you don't qualify your meaning very carefully, you'll just end up confusing people.
I think we pretty much agree in principle, but the definitions we're using are at disjoint. (That's a problem, because clear communication is very important in this business.) I think what you *meant* to say is, "don't use the default definition of assert because the default assertion failure action is to halt the program without giving much useful information to the end-user." That's a statement I can much more readily agree with.
Note that the run-time cost of copying a class object may be such that it makes more sense to pass a copy instead of a const ref (and incur the cost of constantly "dereferencing" that reference).
I agree with item 10, but it should be stated earlier and more often. Bugs in the analysis of requirements and in the design can literally cost years of lost time -- and I'm not counting man-years. If the design is correct, then so many other decisions just naturally fall into place. If it's flawed, you'll spend a lot more time than expected on development. If it's deeply incorrect, you'll be in a world of hurt.
Note that because C++ allows automatic destruction, having a single exit point explicitly represented in the program source code is not terribly important, and sticking hard-and-fast to this rule may lead to some unnecessary performance hits on account of extra calls to class assignment operators, extra class object temporaries, etc.
An explicit "single exit" rule makes more sense in a language like C, where there is no language feature that enables simple automatic clean-up.
It's good to be explicit about some things, but don't be inane.
For example, "int" is *always* "signed int" -- this is in the language definitions. So it's a waste of time to spell it out. Note the signed-ness of plain 'char' is implementation defined, so you could legitimately be explicit about that. But note again that a lot of Standard Library functions use plain 'char', so you have to be careful that your explicitness doesn't break things.
It does help to be explicit about, say, constructors (which is why the creators of C++ added a keyword just for that purpose). E.g.:
struct A { explicit A(); explicit A( const A& ); explicit A( int ); };
In short: be as explicit as you need to be (such that any human reader could draw the same conclusions), but no more. E.g, the parentheses in "a + (b * c)" are superfluous because everyone knows (or can quickly find out) that binary '*' has higher precedence. But then again, with lots of sub-expressions, it can help to add parentheses, line breaks, and indentation at certain points to ease readability. There's no hard rule for it; you just have to feel things out.
Ok, but note that some C++ Standard Library functions will throw if they fail. So when you call these functions, you have to think about exception safety, but you can also assume that they have succeeded on the lines that immediately follow the call.
(Implementations vary though, so you'll need to check up on this for your compiler. E.g., with some older compilers, operator new returns NULL upon failure, whereas the Standard says it must throw.)
Perhaps I misunderstood, but it seems that you're advocating the use of error codes instead of exception throwing/catching.
Quoth Herb Sutter and Andrei Alexandrescu (C++ Coding Standards, item 74): "Report errors at the point they are detected and identified as errors. Handle or translate each error at the nearest level that can do it correctly."
And then there's item 72, which is pretty lengthy and contains lots of references:
"Prefer to use exceptions to report errors.
"Summary
"Prefer using exceptions over error codes to report errors. Use status codes (e.g., return codes, errno) for errors when exceptions cannot be used (see Item 63), and for conditions that are not errors. Use other methods, such as graceful or ungraceful termination, when recovery is not required or is not possible."
(Item 63 basically says, "don't let exceptions propagate beyond the boundaries between your code and the code you don't control.")
Given that these experts have written at length about error handling, and that they suggest a preference for exceptions when dealing with [non-bug] errors from which you can recover, I think you need to talk more about the kinds of cases where you think exceptions are inappropriate (and give some complete code samples).
C++ has been accused of containing some useless features, but I don't think anyone of note has said that about exceptions.
I really think you had better qualify this. IMO, assertion failures do not *cause* problems; they are messengers, and the message is always this: "Your program is broken."
I don't think you want to *recover* from a broken state. I think you want to debug it -- find out what went wrong, fix the code, recompile, test, and re-deploy.
Because, if you get to the point where an assertion fails, it means the state of the program is corrupted, and therefore you can't trust any part of it; e.g., you can't trust error-recovery code to be well-behaved. The best you can do is bring everything to a halt and fix the bug.
There are rare exceptions (no pun intended) to this rule, but for the most part, if you write out a condition and say, "if this is false, then the program has a bug", then you have some explaining to do if you *don't* want to use an assertion.
> Um, are there Japanese-made alternatives to the American-made MS Windows?
Yes. Maybe the most commercially successful one of this century is Chokanji. It's a nice environment, highly responsive, and has the shortest boot-up time I've ever seen for a desktop OS released near the turn of the century. (It's been a few years since I used version 3, so my memory's fuzzy, but I think it was about five seconds -- possibly less -- from the end of BIOS loading to a usable desktop on a 1GHz Athlon Thunderbird box.)
> Some hot Japanese operating system that people are latching onto? No?
It's not terribly popular, but those who decided to use it did latch on, mainly because it has useful features not found in Microsoft's offerings. And it's still on the market.
But I digress...
Microsoft was not always the dominant OS vendor in Japan. See some of the more obscure names in the Japanese Wikipedia entry for operating systems. Google a bit; you can see that there was a time when the OS-ecosystem there was much more diverse than it is today. And yet, an American company took control of that market. So, when Jakub Wojnarowicz claims that "a stiff, impenetrable and informal wall of Japanese nationalism" is part of what's keeping Microsoft from dominating the gaming industry too, I call bullshit. It's not *nationalisnm* that makes Japanese users cling to certain computer products that just happen to be created by companies whose world headquarters are in Japan. It's *preference* for one product over another, just the way it is in the rest of the world.
In the case of the XBox 360, we can blame supply problems and a small game library. Oh, and a high price. Compare that to the existing cheaper systems in abundant supply with huge libraries and expectations of better systems yet to come that will maintain full compatibility with existing libraries -- unlike Microsoft's platform -- and you can only conclude that the 360 will sell poorly *regardless* of the would-be consumers' nationality.
"Japanese nationalism hurt XBox 360 sales"? Bullshit.
From TFA: "In Japan, as usual, an American-made (or rather, American-designed) product has flopped. Like countless other American companies, Microsoft has faced a stiff, impenetrable and informal wall of Japanese nationalism which clings stubbornly to a Japanese product."
The author ignores the fact that Microsoft dominates the desktop PC OS market in Japan as it does in most other parts of the world.
Look, I wouldn't try to counter claims that there's a lot of unchecked racism in Japan, and I've been told -- by many Japanese people -- that believe they take their nationalism more seriously than people in other countries. But I think that when it comes to games, the formula is this simple:
( fun game + reasonable price ) -->yields--> ( customer of game producer and platform manufacturer )
It's the kids of middle-class families and the teen-to-thirtysomethings who decide whether the 360 will sink or swim, and they sure as hell aren't thinking about the emperor when they try to decide whether to drop the money for it. It may be that Microsoft didn't cater to the gaming preferences that are more prevalent in that country, but if so, that's their *avoidable* problem. It's not like they don't have huge corporate offices in Japan.
I thought it was a matter of public record that Nintendo is going to release the Revolution console sometime in 2006; if that the case then isn't it kind of obvious that they would have to release it in time for pre-winter holiday shopping?
> It's like the stairs in world 1-3 of Super Mario Brothers -- a 1-up that keeps on giving.
Even the magic life-giving stairs impose a limit: if you keep getting those 1-ups -- more than 127 or more than 255; I can't remember -- you'll cause an overflow in the NES and the game will crash. This may have been patched in the more recent releases of the game (e.g., in those classic-games-in-a-joystick models that have been peddled in recent years), so your odds of being able to reproduce this may be better with an original SMB cart.
Eben Moglen (the FSF's general counsel) feels differently. Almost two years ago, while speaking at Harvard Law School, at he had this to say on the subject:
"To those who like to say there has never been a court test of the GPL, I have one simple thing to say: Don't blame me. I was perfectly happy to roll any time. It was the defendants who didn't want to do it. And when for ten solid years, people have turned down an opportunity to make a legal argument, guess what? It isn't any good."
I think you're being a bit unfair. You must understand a few things:
First, the work of the ISO C++ committee is (and always has been) a volunteer effort. Everyone on the committee has a day job that has practically nothing to do with committee work. (The organizations they represent may pay some or all of the expenses associated with committee membership, but the "real work" rests purely on the shoulders of each individual member. It's truly a labor of love.) On top of that, most of them have a family life.
Second, C++ was a fairly mature language even before they finished drafting for the first Standard back in 1997 -- and adding features to *any* mature system always takes a lot more work than designing features for a new system.
Third, it's a committee. Each individual has in mind a set of features that they would like to see added to either the core language or the library, and whatever they propose must meet with the consensus of the majority, or *the*proposal*doesn't*move*forward*. A lot of the features you're asking for have been proposed in one form or another, and a good number of them will simply be left out of C++0x because a number of reasonable people made sound objections on technical grounds. This doesn't mean they object to the general notion of, say, strong typing. It's just that they objected to the specific way in which it was proposed.
Fourth, their time is limited. Each ISO meeting lasts for only five (5) days, and there are only two meetings per year. They do get a lot done on mailing lists, but nothing beats face-to-face communication for rapid development, and they don't get very much of that.
Fifth, they have to be *really*careful* when they consider the addition of a major new feature. They really got burned by the likes of 'export' -- i.e., features that sounded good to a lot of people but ended up adding a **HUGE** amount of complexity for practically no real benefit. They clearly understand that a lot of the features you're asking for would be nice to have, but specifying the details of that feature to fit into Standard C++ in a non-disruptive and straightforward way -- and *proving* that it will be non-disruptive and straightforward to implement -- is a difficult thing to do correctly.
To sum up: they're over-worked, under-supplied, forced to be highly cautious, pressed for time, and under-paid (in fact, they're *not* paid -- at least, not paid for committee work). And somehow they're giving us a language that's fairly portable and is a superior tool for a broad range of applications. So cut them some slack. Better yet, join the committee and help out if you can.
It implies to me that it's a big effort to take off and put on my shoes (I have things called shoelaces) and I don't expect to be in your house long enough to warrant such effort. Gah.
Oh, and heaven forbid they put a CHAIR next to the big pile of shoes so I don't have to bend over and risk toppling myself TWICE in the period of my visit. Often I end up going outside to sit on the front step to take off my shoes -- usually dirting my socks (and therefore your carpet) in the process.
AAAAAAAAAAHHH I really hate it. Sorry.
1) Regarding difficulty of removal and donning of shoes: It really needn't be a big effort, nor should it take much more than two seconds. You don't tie and untie your shoes at each donning and removal; you simply leave them slightly loosened so that you can quickly slip them on and off. I've moved furniture and removed my shoes with my feet while entering the house so as not to sully the carpet, and this was always an effortless operation. If you think this sounds like a difficult thing to do, you probably haven't tried doing it long enough. When you live for a very short time -- like a couple/few weeks -- in a culture that requires this kind of behavior, you'll get the hang of it. I admit it's more annoying to cope with this practice in a country like the U.S., where the understanding that "you-remove-your-shoes-**here**" is seldom established. (For example, most houses and apartments in the U.S. are not built with a special area with a recessed floor near the front door where people are expected to take off their shoes.)
2) The amount of time you spend walking around on the inside floor with your shoes is irrelevant. The problem (if you do that) is that you're getting filth on the inside floor, and people/cultures with "no-shoes-**here**" policies tend not to like the idea of walking on *filth* in their socks.
3) I agree that a chair would help in cultures where the "take-your-shoes-off-**here**" policy is not widely practiced; those who live in cultures with relaxed shoe policies and who want to adopt the cleaner rule would do well to provide transitional aids like that. (It would be considerate to provide one's guests with a couple of swiveling chairs, shoehorns, footstools, and some way to steady one's self and prevent toppling.)
To sum up: I understand why you're annoyed, but trust that once you get used to it, you remove/don so quickly that you give it about as much thought (and time!) as closing the door behind you.
I wonder how hackable they would be to send 'pleasure' signals... Kinda like a star trekkie thing that keeps your brain in extacy for hours upon hours... That would be the life... who cares about money after that implant.
But obviously, amateurishly hacking the vagus nerve is ill-advised.
>...Does any of this matter as far as Joe Sixpack is concerned? > Not a bit! > > What does matter then? The stuff they're emphasizing - tabbed > browsing, design, and integration. You can spend hours explaining > what's better to a layman, and in the end they'll use the browser > that looks better and is more comfortable.
Very often, Joe and Jane Sixpack use the phrase "The Internet" to refer to the web browsing program that came bundled with their PC, which is usually a Microsoft Windows machine. Therefore, they are acclimated to bad (or outdated) design. Do you really expect people like that to/choose/ a better web browser? We're talking about people who have neither the awareness that such things exist nor the motivation to find or learn to use them.
Firefox's boosted popularity notwithstanding, I see no reason to expect this situation to change in the coming years.
But perhaps you refer to another family -- within the widely dispersed Sixpack clan -- with whom I have not yet had the privilege of being acquainted.
I can't help but feel that the Bitkeeper folks are going to lose a lot of sales due to programmers regarding them poorly as a result of this action.
Lots of programmers do not regard them poorly -- Linus included. From his post this morning:
"So I just wanted to say that I'm personally very happy with BK, and with
Larry. It didn't work out, but it sure as hell made a big difference to
kernel development."
It seems to me that the only programmers who really view BitMover poorly at this point are those who adopted the view that all software should be FLOSS. They happen to be the same ones who, in general, tend not to pay for binary-only software. In other words, I don't see how BitMover will lose sales from people who weren't customers anyway. And I don't see how this move affects existing customers or potential customers, who are obviously willing to lay down money for the best tool said money can buy.
Larry's comments seem not to disagree with this reasoning. From TFA:
When asked if he was concerned about this resulting in the creation of a project that ultimately competes with BitKeeper, Larry replied, "yes, of course. We'd be idiots to not be." However, he then went on to point out some reasons that this was unlikely. In maintaining two products, he was suprised to learn that the needs of the open source community was much different than the needs of the commercial community.
...so I think BitMover will be around for some time to come. A good thing too, because they're kicking ass and indications are that future versions of BK will further impress.
It will also be nice if their future features will eventually become available in the form of an equally compelling open-source RCS, but if the past five years are any indication, we can expect not to see truly innovative features on the FLOSS side for a long time. And that is really unfortunate, but hopefully the monotone people will pick up the slack.
Slashdot Mirror
I *do* maintain a program without a strict OEOE rule, and it *is* quite feasible; we've been doing it for many, many years now. There are several places where we have things set up OEOE-style because it helps the algorithm, but we really don't need it *everywhere*. There are lots of functions where OEOE would be an imposition that does not arise from any real need, but from blind adherence to coding "standards".
We write source code to solve problems in a way that other programmers can understand. If there is a function where OEOE doesn't improve a reader's understanding, why use it?
And yes, I'm quite aware that dynamically allocated objects will not be automatically destroyed upon exiting from the scope of their allocation, because such objects don't have a "scope". That's why you *give* them a scope by using smart pointers.
I think we're working with slightly different definitions of the word "crash". When I think of a crash, I think of a program that was terminated not of its own volition, but by the operating system in response to, say, a memory segmentation fault.
assert() is (usually) a macro, and you can define it to expand to whatever you want. By default, it usually expands such that if the tested expression is false, then exit() is called after some debug message (like "failure in foo() at line 1234") is sent to stderr.
I *guess* you could refer to the call to exit() as a "crash", but to me it seems like deliberate behavior. In other words, the exit() call itself is not a sudden failure. The failure happened -- silently -- long before we got to the assert(). The call to exit() is done to limit the damage of the failure and to aid the programmer in debugging.
Now, an assertion failure doesn't have to result in a call to exit(). It could result in a cute GUI pop-up window that says, "sorry it didn't work out; please fill out this form that we'll send back to the developers. Try to give as much relevant info as possible." And that could be sent back to the developers along with a core dump. A lot of developers have chosen this route, and it seems like a valid one. In a debug build, an assertion failure could instead result in a call to a function that pauses execution and launches an interactive debugger; this too is valid.
But I think it's unhelpful to try to convince people that "assert will just crash the program" for two reasons: 1) assert() is only a messenger, and the programmer is always in control of how that message is to be delivered, because she always has control over the definition of the macro. 2) you're going against the writings of the experts, and if you don't qualify your meaning very carefully, you'll just end up confusing people.
I think we pretty much agree in principle, but the definitions we're using are at disjoint. (That's a problem, because clear communication is very important in this business.) I think what you *meant* to say is, "don't use the default definition of assert because the default assertion failure action is to halt the program without giving much useful information to the end-user." That's a statement I can much more readily agree with.
Note that the run-time cost of copying a class object may be such that it makes more sense to pass a copy instead of a const ref (and incur the cost of constantly "dereferencing" that reference).
I agree with item 10, but it should be stated earlier and more often. Bugs in the analysis of requirements and in the design can literally cost years of lost time -- and I'm not counting man-years. If the design is correct, then so many other decisions just naturally fall into place. If it's flawed, you'll spend a lot more time than expected on development. If it's deeply incorrect, you'll be in a world of hurt.
Note that because C++ allows automatic destruction, having a single exit point explicitly represented in the program source code is not terribly important, and sticking hard-and-fast to this rule may lead to some unnecessary performance hits on account of extra calls to class assignment operators, extra class object temporaries, etc.
An explicit "single exit" rule makes more sense in a language like C, where there is no language feature that enables simple automatic clean-up.
It's good to be explicit about some things, but don't be inane.
For example, "int" is *always* "signed int" -- this is in the language definitions. So it's a waste of time to spell it out. Note the signed-ness of plain 'char' is implementation defined, so you could legitimately be explicit about that. But note again that a lot of Standard Library functions use plain 'char', so you have to be careful that your explicitness doesn't break things.
It does help to be explicit about, say, constructors (which is why the creators of C++ added a keyword just for that purpose). E.g.:
struct A
{
explicit A();
explicit A( const A& );
explicit A( int );
};
In short: be as explicit as you need to be (such that any human reader could draw the same conclusions), but no more. E.g, the parentheses in "a + (b * c)" are superfluous because everyone knows (or can quickly find out) that binary '*' has higher precedence. But then again, with lots of sub-expressions, it can help to add parentheses, line breaks, and indentation at certain points to ease readability. There's no hard rule for it; you just have to feel things out.
Ok, but note that some C++ Standard Library functions will throw if they fail. So when you call these functions, you have to think about exception safety, but you can also assume that they have succeeded on the lines that immediately follow the call.
(Implementations vary though, so you'll need to check up on this for your compiler. E.g., with some older compilers, operator new returns NULL upon failure, whereas the Standard says it must throw.)
Perhaps I misunderstood, but it seems that you're advocating the use of error codes instead of exception throwing/catching.
Quoth Herb Sutter and Andrei Alexandrescu (C++ Coding Standards, item 74): "Report errors at the point they are detected and identified as errors. Handle or translate each error at the nearest level that can do it correctly."
And then there's item 72, which is pretty lengthy and contains lots of references:
"Prefer to use exceptions to report errors.
"Summary
"Prefer using exceptions over error codes to report errors. Use status codes (e.g., return codes, errno) for errors when exceptions cannot be used (see Item 63), and for conditions that are not errors. Use other methods, such as graceful or ungraceful termination, when recovery is not required or is not possible."
(Item 63 basically says, "don't let exceptions propagate beyond the boundaries between your code and the code you don't control.")
Given that these experts have written at length about error handling, and that they suggest a preference for exceptions when dealing with [non-bug] errors from which you can recover, I think you need to talk more about the kinds of cases where you think exceptions are inappropriate (and give some complete code samples).
C++ has been accused of containing some useless features, but I don't think anyone of note has said that about exceptions.
By the way: to get good formatting for code, use the "Code" format (see the drop-down menu next to the "preview" and "submit" buttons).
I really think you had better qualify this. IMO, assertion failures do not *cause* problems; they are messengers, and the message is always this: "Your program is broken."
I don't think you want to *recover* from a broken state. I think you want to debug it -- find out what went wrong, fix the code, recompile, test, and re-deploy.
Because, if you get to the point where an assertion fails, it means the state of the program is corrupted, and therefore you can't trust any part of it; e.g., you can't trust error-recovery code to be well-behaved. The best you can do is bring everything to a halt and fix the bug.
There are rare exceptions (no pun intended) to this rule, but for the most part, if you write out a condition and say, "if this is false, then the program has a bug", then you have some explaining to do if you *don't* want to use an assertion.
... but humans *are* animals.
"The Goober". (:
Kidding aside: they weren't patented, but they were copyrighted. (See the bottom of every Slashdot page for a reminder of this.)
> Um, are there Japanese-made alternatives to the American-made MS Windows?
Yes. Maybe the most commercially successful one of this century is Chokanji. It's a nice environment, highly responsive, and has the shortest boot-up time I've ever seen for a desktop OS released near the turn of the century. (It's been a few years since I used version 3, so my memory's fuzzy, but I think it was about five seconds -- possibly less -- from the end of BIOS loading to a usable desktop on a 1GHz Athlon Thunderbird box.)
> Some hot Japanese operating system that people are latching onto? No?
It's not terribly popular, but those who decided to use it did latch on, mainly because it has useful features not found in Microsoft's offerings. And it's still on the market.
But I digress...
Microsoft was not always the dominant OS vendor in Japan. See some of the more obscure names in the Japanese Wikipedia entry for operating systems. Google a bit; you can see that there was a time when the OS-ecosystem there was much more diverse than it is today. And yet, an American company took control of that market. So, when Jakub Wojnarowicz claims that "a stiff, impenetrable and informal wall of Japanese nationalism" is part of what's keeping Microsoft from dominating the gaming industry too, I call bullshit. It's not *nationalisnm* that makes Japanese users cling to certain computer products that just happen to be created by companies whose world headquarters are in Japan. It's *preference* for one product over another, just the way it is in the rest of the world.
In the case of the XBox 360, we can blame supply problems and a small game library. Oh, and a high price. Compare that to the existing cheaper systems in abundant supply with huge libraries and expectations of better systems yet to come that will maintain full compatibility with existing libraries -- unlike Microsoft's platform -- and you can only conclude that the 360 will sell poorly *regardless* of the would-be consumers' nationality.
"Japanese nationalism hurt XBox 360 sales"? Bullshit.
From TFA: "In Japan, as usual, an American-made (or rather, American-designed) product has flopped. Like countless other American companies, Microsoft has faced a stiff, impenetrable and informal wall of Japanese nationalism which clings stubbornly to a Japanese product."
The author ignores the fact that Microsoft dominates the desktop PC OS market in Japan as it does in most other parts of the world.
Look, I wouldn't try to counter claims that there's a lot of unchecked racism in Japan, and I've been told -- by many Japanese people -- that believe they take their nationalism more seriously than people in other countries. But I think that when it comes to games, the formula is this simple:
( fun game + reasonable price ) -->yields--> ( customer of game producer and platform manufacturer )
It's the kids of middle-class families and the teen-to-thirtysomethings who decide whether the 360 will sink or swim, and they sure as hell aren't thinking about the emperor when they try to decide whether to drop the money for it. It may be that Microsoft didn't cater to the gaming preferences that are more prevalent in that country, but if so, that's their *avoidable* problem. It's not like they don't have huge corporate offices in Japan.
I thought it was a matter of public record that Nintendo is going to release the Revolution console sometime in 2006; if that the case then isn't it kind of obvious that they would have to release it in time for pre-winter holiday shopping?
> It's like the stairs in world 1-3 of Super Mario Brothers -- a 1-up that keeps on giving.
Even the magic life-giving stairs impose a limit: if you keep getting those 1-ups -- more than 127 or more than 255; I can't remember -- you'll cause an overflow in the NES and the game will crash. This may have been patched in the more recent releases of the game (e.g., in those classic-games-in-a-joystick models that have been peddled in recent years), so your odds of being able to reproduce this may be better with an original SMB cart.
The GPL needs to be tested in court.
Eben Moglen (the FSF's general counsel) feels differently. Almost two years ago, while speaking at Harvard Law School, at he had this to say on the subject:
"To those who like to say there has never been a court test of the GPL, I have one simple thing to say: Don't blame me. I was perfectly happy to roll any time. It was the defendants who didn't want to do it. And when for ten solid years, people have turned down an opportunity to make a legal argument, guess what? It isn't any good."
You can read the entire transcript or watch the speech (but make sure you'll be free for the following 90 minutes or so).
I think you're being a bit unfair. You must understand a few things:
First, the work of the ISO C++ committee is (and always has been) a volunteer effort. Everyone on the committee has a day job that has practically nothing to do with committee work. (The organizations they represent may pay some or all of the expenses associated with committee membership, but the "real work" rests purely on the shoulders of each individual member. It's truly a labor of love.) On top of that, most of them have a family life.
Second, C++ was a fairly mature language even before they finished drafting for the first Standard back in 1997 -- and adding features to *any* mature system always takes a lot more work than designing features for a new system.
Third, it's a committee. Each individual has in mind a set of features that they would like to see added to either the core language or the library, and whatever they propose must meet with the consensus of the majority, or *the*proposal*doesn't*move*forward*. A lot of the features you're asking for have been proposed in one form or another, and a good number of them will simply be left out of C++0x because a number of reasonable people made sound objections on technical grounds. This doesn't mean they object to the general notion of, say, strong typing. It's just that they objected to the specific way in which it was proposed.
Fourth, their time is limited. Each ISO meeting lasts for only five (5) days, and there are only two meetings per year. They do get a lot done on mailing lists, but nothing beats face-to-face communication for rapid development, and they don't get very much of that.
Fifth, they have to be *really*careful* when they consider the addition of a major new feature. They really got burned by the likes of 'export' -- i.e., features that sounded good to a lot of people but ended up adding a **HUGE** amount of complexity for practically no real benefit. They clearly understand that a lot of the features you're asking for would be nice to have, but specifying the details of that feature to fit into Standard C++ in a non-disruptive and straightforward way -- and *proving* that it will be non-disruptive and straightforward to implement -- is a difficult thing to do correctly.
To sum up: they're over-worked, under-supplied, forced to be highly cautious, pressed for time, and under-paid (in fact, they're *not* paid -- at least, not paid for committee work). And somehow they're giving us a language that's fairly portable and is a superior tool for a broad range of applications. So cut them some slack. Better yet, join the committee and help out if you can.
1) Regarding difficulty of removal and donning of shoes: It really needn't be a big effort, nor should it take much more than two seconds. You don't tie and untie your shoes at each donning and removal; you simply leave them slightly loosened so that you can quickly slip them on and off. I've moved furniture and removed my shoes with my feet while entering the house so as not to sully the carpet, and this was always an effortless operation. If you think this sounds like a difficult thing to do, you probably haven't tried doing it long enough. When you live for a very short time -- like a couple/few weeks -- in a culture that requires this kind of behavior, you'll get the hang of it. I admit it's more annoying to cope with this practice in a country like the U.S., where the understanding that "you-remove-your-shoes-**here**" is seldom established. (For example, most houses and apartments in the U.S. are not built with a special area with a recessed floor near the front door where people are expected to take off their shoes.)
2) The amount of time you spend walking around on the inside floor with your shoes is irrelevant. The problem (if you do that) is that you're getting filth on the inside floor, and people/cultures with "no-shoes-**here**" policies tend not to like the idea of walking on *filth* in their socks.
3) I agree that a chair would help in cultures where the "take-your-shoes-off-**here**" policy is not widely practiced; those who live in cultures with relaxed shoe policies and who want to adopt the cleaner rule would do well to provide transitional aids like that. (It would be considerate to provide one's guests with a couple of swiveling chairs, shoehorns, footstools, and some way to steady one's self and prevent toppling.)
To sum up: I understand why you're annoyed, but trust that once you get used to it, you remove/don so quickly that you give it about as much thought (and time!) as closing the door behind you.
> It's pronounced "corrosion." See the FAQ. It means "lustful ferret" or something like that.
Or, perhaps "kuro go hin" ("black five things").
I mean, if it's going to start out looking all Japanese-y, you might as well say "5" in Japanese -- FAQ be damned! (:
Well, it's not as though usable substitutes don't exist. Several are listed here, for instance.
I wonder how hackable they would be to send 'pleasure' signals... Kinda like a star trekkie thing that keeps your brain in extacy for hours upon hours... That would be the life... who cares about money after that implant.
But obviously, amateurishly hacking the vagus nerve is ill-advised.
> ...Does any of this matter as far as Joe Sixpack is concerned?
/choose/ a better web browser? We're talking about people who have neither the awareness that such things exist nor the motivation to find or learn to use them.
> Not a bit!
>
> What does matter then? The stuff they're emphasizing - tabbed
> browsing, design, and integration. You can spend hours explaining
> what's better to a layman, and in the end they'll use the browser
> that looks better and is more comfortable.
Very often, Joe and Jane Sixpack use the phrase "The Internet" to refer to the web browsing program that came bundled with their PC, which is usually a Microsoft Windows machine. Therefore, they are acclimated to bad (or outdated) design. Do you really expect people like that to
Firefox's boosted popularity notwithstanding, I see no reason to expect this situation to change in the coming years.
But perhaps you refer to another family -- within the widely dispersed Sixpack clan -- with whom I have not yet had the privilege of being acquainted.
Larry's comments seem not to disagree with this reasoning. From TFA:
It will also be nice if their future features will eventually become available in the form of an equally compelling open-source RCS, but if the past five years are any indication, we can expect not to see truly innovative features on the FLOSS side for a long time. And that is really unfortunate, but hopefully the monotone people will pick up the slack.