Regardless of the poor decisions of some recruiters, I've found this to be true: the most competent and disciplined engineers tend to use as many checking techniques as possible (e.g., regression tests, unit tests, multiple static analysis tools, etc.). They use these techniques not as a substitute for a disciplined approach to design or to implementation (that would be foolish), but as a sanity check on a finished product. They use multiple checking techniques because they know they're human, and humans -- even the most skilled, most experienced, most disciplined ones -- make mistakes, and they want to do everything they reasonably can to catch mistakes before a product ships.
So to that end, model checkers (and other forms of checking) are Good Things(TM). The possibility that some will misconstrue checking facilities as a substitute for competent and disciplined engineers is a separate issue, and it's not the fault of the checking scheme. The *organizational* problem of poor recruiting cannot be solved by getting rid of model-checking systems, and if your recruiters think that talent can be replaced by a "verification" system, you've got bigger problems than merely the shoddy designs that will come down the pike.
(Please note that I prefer to use the term "check" rather than "verify", because the latter term, when used to describe a program, too easily connotes the notion that a "verified" program is free of any bugs (which is, needless to say, always a dubious claim). "Check" on the other had usually connotes the idea that there is a specific bug (or set of specific bugs) that is tested for. Of course, TFA mentions they don't want to imply that (verification == no bugs). But IMHO too many people make that mistake.)
Takamoto:
The internal fan is another case in which having a clear goal
from the beginning allowed us to achieve what we wanted. Because we had
the clear goal of not letting the fan spin at night, the LSI team had to
minimize the heat released from the ICs (integrated circuits), and the
design team had to take into consideration the heat that would be trapped
inside.
Iwata: We really couldn't give up on that goal once we decided to
make Wii a sleepless machine that stays on 24 hours a day. If the fan is
spinning in the middle of the night, I could just imagine mothers
everywhere pulling the plug right out of the wall because they thought it
had been left on again. (laughs)
This is going to be an important (but perhaps seldom noticed) feature.
Home theaters are beginning to sound too much like server rooms.
1) I prefer monospace; I find it easier on the eyes.
2) Where is it written that a variable-width font is preferred? Is there an equivalent of Strunk & White for Slashdot postings, or does it just grate on your own senses to see monospace used for plain text? If the former, I'll reform; if only the latter then I would have acquiesced except that...
3) It's difficult to yield to suggestions delivered with insult.
> Reading the code in the Boost libraries gives me headaches
I haven't had headaches yet, though I do go through a certain emotional pattern. There is pseudo-syntax for it:
human-reaction-to-boost: What/expletive-expression/... How/expletive-expression/ did they do that?! That's/expletive-expression/ amazing!
One of the upshots of reading Boost header code is that it forces you to learn more (or remember more) of the convoluted yarn that is Standard C++.
I see that as a good thing, though I can empathize with the notion that good generic code shouldn't force the reader to become too familiar with obscure language parsing rules.
> -- and often gives various compilers fits
It depends on the compiler. The key is ISO Standard compliance. The more your compiler supports Standard C++, the more likely it will handle the exploitive uses of C++ features found in Boost.
E.g., practically anything with an EDG front end released in or after 2003 can be regarded as fully Standard-compliant, which means you shouldn't get any fits when you compile Boost-using code. Recent versions of GCC (3.4.x and later) rank at a pretty close second on the compliance-o-meter. MSVC 7.1 and 8 are *much* closer to compliance than MSVC 6, but are still a bit rough in some less-provoked areas (mostly involving subtle aspects of name lookup and template processing). I think Sun is in a position similar to Microsoft, though I don't know what their weak points are. (All I know is that, due to pressure from Boost-using customers, recent versions of their compiler should handle it better.)
> I much prefer Objective-C's way of doing things to C++'s > even despite the mystical "woojiness" of Boost.
Well, to each his own; but just remember that the existence of Obj-C++ means the woojiness is always within your reach, should the desire for woojiness* suddenly overtake you -- or should you hit a problem that would be most elegantly solved with a design that uses a function template. (:
> For instance, you can't have a C++ array of "anything", > unless all objects descend from the same class, and then you > are restricted to functions that were declared in that base > class.
Sounds like someone hasn't tasted the sweet goodness of Boost. (:
In particular, Boost.Any gives you a simple and type-safe way to have a ${favorite_container_type} of anything.
The nice part is that if you're using XCode and you're writing an app for the Mac, you don't have to choose between Obj-C and C++; you can use Objective-C++.
Yes, the '?:' extension is non-Standard. But note that I *did* specify use of GCC with its '-pedantic' option. Using that option and an example using '?:', I get:
$ g++ -pedantic -c a.cpp a.cpp:4: error: ISO C++ forbids omitting the middle term of a ?: expression
It's true that Microsoft took a big step towards Standard compliance with VC 7. However, there are still (even in VC 8) a lot of subtle areas where they are bested by both EDG and the GNU people.
Anyone who has been compiling only with VC 7 should try using a copy of GCC/MinGW with '-pedantic' and Comeau with '-A'. Chances are that the code won't compile, and chances are that a majority of the errors will result from code that really is ill-formed according to the Standard.
But of course it's possible to write a Standard C++ program using VC 7/8. The question is whether Standard C++ features are being exploited. Most people who don't use modern libraries like the STL and the Boost libraries haven't really migrated to Standard C++ *in spirit*; they're just using a "better C" and taking advantage of some features that support object-oriented design.
Are you talking about Standard C++ or Microsoft++? There's a considerable difference, especially in recent years.
Microsoft likes to present a lot of its own extensions as "C++" features. In particular, they like to present C++/CLI (a.k.a "CLI++") keywords as "C++" keywords.
And then there are the managed extensions. (But even Microsoft has deprecated those in favor of CLI++.)
Going back even further, there's MSVC 6. Lots of people still use it, but it's just too old for anyone to expect it to be close to Standard compliance.
What compilers do you work with? Do you set compiler options to disable extensions and run in a "strict" standard-conforming mode? Do you use more than one compiler?
Do you make judicious use of the STL? Do you use any part of Boost? (If not, you should seriously consider taking some time to learn about these best-of-breed libraries that are available *for free* and for which support is available from multiple consulting firms.)
Did you give up trying either of those libraries before trying out STLFilt? (If so, go play with it. You'll probably want to give generic programming a second try.)
Have you and your team read any of the *good* C++ books? E.g.:
Have you invested in static analysis tools? (E.g., PC-Lint, etc.)
Most of the C++ programmers who cut their teeth on Windows learned a watered-down version of the language by way of the Microsoft libraries (e.g., MFC, which should *not* be mistaken for a model of modern C++ interface design). If that describes most of the people on your team, you should seriously consider migrating from "kinda-C++" to Standard C++.
That kind of works, but I think the authors wanted to make sure that nullptr has the same semantics everywhere, and the only clean way to force that is with a reserved word. If it's an identifier, the name can be hidden or replaced by some other library implementation, which could lead to all kinds of non-portable weirdness. And if the type is a normal user-defined type it can be used to deduce template arguments (which I think they wanted to avoid). Also, I think there were some other arguments about quality of code and diagnostics from compilers when referring to the type and to the value.
Rumor has it the ISO C++ committee is likely to pass through a proposal for a new keyword, nullptr, which will have a "magic" type "pointer-to-anything" and has the value of the null pointer constant.
So, E.g.:
struct A; int f( A* );// #1 int f( int );// #2
int m = f( 0 );// # calls #2 int n = f( nullptr );// calls #1
Of course, that wouldn't help in the aforementioned case. 0 will still be convertible to a pointer type as it is now; it's just that 'nullptr', being a pointer itself, makes for a "better" conversion to a real pointer type.
nullptr is supposed to be a non-disruptive pure extension (except for the fact that it breaks code that uses 'nullptr' as an identifier) -- meaning that it should not change the meaning of existing code.
> We're geeks - we don't really worry about something affecting our social status!
Apparently the great-grand parent does; else why care so much about the name? Notice he didn't say he's not going to *buy* the system. He said he "won't be asking for a 'Wii' over a shop counter". It is to laugh.
gamer: Hi, uh... I'll take a copy of Red Steel and uh... I'll also need a console to go with that.
clerk: [clearly audible] Oh, so you need a **Wii**?
gamer: <whispering> Would you keep your fucking voice down!? Fucking Nintendo...
clerk: Sorry about that sir.
clerk: [projecting] Ok sir, your ***Wii*** game and your ***Wii*** both come to $265.00.
gamer: [completely flushed; hands over cash, takes goods and walks away quickly while staring at floor]
clerk: HAVE FUN PLAYING WITH YOUR WII! ...I love this job.
Seriously, I think the only people who have a problem with this "issue" are the same people who are easily embarrassed when accompanied by their parents in public. It's a character flaw that most people grow out of after adolescence (if they ever have it to begin with).
> As a gamer, I won't be asking for a 'Wii' over a shop counter.
Why not? Everyone else will. In a way, I'm inclined to believe the hype: once you actually play a game or two, your perception of the system's name's effect on your social status will fade.
>... there definitly [sic] are some shallow people who will refuse to > buy a game because the name isn't cool enough.
Heh. Every neighborhood has a Cartman or two, on average. (:
But really, none of that matters. It's the games that will decide this. They'll be on display at local game shops. People -- and I mean *normal* people as well as "hardcore gamers" -- will try before they buy, and if they like the game they played, and if it doesn't hurt the wallet too much, they'll buy that game. And as an *incidental* event, they'll buy the system too.
Or, the games will suck and only the fanboys will buy. It's really that simple.
If the Cartmans really had any influence over what games become popular, then it would be difficult to imagine success ever visiting games with such silly names as "Pac-Man", "Donkey Kong", "Super Monkey Ball" or "Katamari Damacy".
("Hardcore gamers". Sheesh. A greater contradiction in terms would be hard to find.)
Re. search engine scoring: excellent point; their marketing people must have taken that into consideration. It would virtually guarantee that any name they chose would have to have been completely unheard of in all major languages (except possibly as a little-known acronym).
Consider the other criteria met by the name "Wii":
It's short (one or two syllables, depending on how syllables are delimited in a language).
It's easy to pronounce in all major languages (despite erroneous claims to the contrary).
It looks and/or sounds foreign in a lot of major languages (if not all of them). Thus it grabs attention when people first see it.
It's a homonym (or near-homonym) for other words in a lot of major languages. (Thus it's really easy to come up with a play on words, which leads people to use the word more, whether intentionally or by accident. There will be a lot of people saying, "no pun intended" for a while.)
All of that leads people to start talking about their product *FOR FREE*. It also serves to distinguish their image from that of their competitors.
And, as you point out, the name doesn't factor into the "buy/don't buy" decision-making process. The novelty, quality of games, and price will do that. The name is there mainly to help draw attention and curiosity, and it's doing a bang-up job of that so far.
Thus, despite comments like those from Penny Arcade's Tycho, I suspect someone at Nintendo is going to get a promotion (or a pay raise, or -- at the very least -- a cookie) because of this.
Ah -- others have pointed out that it refers to drum-based communication using the voice instead of drums. But I can't find a reference to the culture and/or language it comes from...
According to my wordtank, ekiga can be represented with two Han letters that individually mean "side" and "bud" and means:
"(usually leafy) buds that form at the base of a root; also, commonly, those that form on the upper side of the base of a leaf and (in large numbers) from within a stem."
(Translated from: "Ha no tsuke ne ni dekiru me. Futsuu, ha no kibu no uwakawa ni dekiru ga, youhei no uchigawa ni shou-zuru mono mo ooi." But my Japanese is so rusty that it's actually a small pile of *iron oxide* and various impurities, so you might want to double-check that. Also, apologies for the romaji; stupid Slashdot still doesn't come in UTF-8 flavor.)
What that has to do with VOIP... I have no idea. (:
But that assumes the word is intended to be taken as Japanese, which I'm not so sure of...
... and the most important of these would be the amount of time that the voters like to spend playing games. In the linked-to list, it's clear that the voters spend *much* more time on games than I prefer.
I would much rather see a "top fifty" list compiled where the voters do not like to spend any more than five hours per week on games. I would expect titles like Wario Ware, Inc and Katamari Damacy to be close to (or in) the top ten.
"does that make them right? No. If they jumped off a bridge, would you? "
I'm not following the advice blindly. They present compelling arguments, and you (so far) don't. It doesn't make sense for me to re-state their arguments here, so I'm suggesting that you make yourself familiar with those arguments before you attack the conclusion of those arguments.
["Status code" is not a term I invented. Note that the term is used in a quoted region. Again, see Sutter & Alexandrescu.]
To cut a long discussion short: I think you should brush up on some of the modern literature on the subject. Even if you don't agree with it, you would at least be better able to explain why you think the experts have it wrong. Again, see Sutter & Alexandrescu. See also Stroustrup, writings by David Abrahams on exception safety, and basically every C++ author who was ever given any credit by the community. I don't think any of them referred to the use of exceptions as the lazy person's weak substitute for good error handling; and they refer to exceptions (when discussing non-bug errors) as the first consideration, not the last resort. And they give plenty of compelling reasons for their recommendation, whereas you've given one *weak* reason ("it encourages lazy error handling"). So please forgive me, but I cannot take your opinion seriously just yet.
You're right in thinking that exceptions should not propagate from library code to client code though -- in fact, that's generally recommended practice -- see my earlier post. But it's also generally accepted to use exceptions *within* the library code, so long as it doesn't spill over into the space of the library user.
Re: ISO comittees changing meaning of 'int' from 'signed int' to 'implementation-defined'.
Not only is it "not likely"; it's "not-bloodly-likely", and it's "not-gonna-happen-in-this-universe--ever". This is a rule that held in K&R C, or, as some people like to call it, "Nixon-administration-C". It's one of those really, really old rules -- as old as C itself -- that all compiler vendors have always followed and will not dream of breaking unless we're talking about some experimental language that is not C or C++.
'signed int' is 'int'. They are different syntactic representations for the exact same internal type. No meaningful argument about this ever existed or will ever exist.
Same goes for operator precedence. The precedence rules have always just "been", and they have been followed consistently in every implementation of C and C++. There are other points of language interpretation that vary from compiler to compiler, but those points are overwhelmingly related to non-C, C++ features. I defy you to point out *one* implementation that proves me wrong.
Re: the 'explicit' keyword: Sorry, I didn't really mean to draw attention to the keyword itself; just that use of it ensures that you won't be left trying to figure out where all the implicit ctor calls are.
Re: the being-explicit-to-the-point-of-pointless-redundanc y-will-shorten-debug-times argument:
Bull. Having a better understanding of the language will shorten debug times. Adding meaningless layers of syntactic redundancy will only hurt the eyes of people who know what they're doing. If a newbie doesn't understand some nuance of the language, it means he needs to spend some time getting to know the language better, and no amount of adherence to a coding style will acceptably substitute that.
Slashdot Mirror
> It's a nice overview of how Nintendo's culture came up with the 'new-gen' system.
Oh, I see. The added value is *brevity*.
Is there anything in TFA that was not already mentioned in NOA's translation of Iwata's interviews?
Regardless of the poor decisions of some recruiters, I've found this to be true: the most competent and disciplined engineers tend to use as many checking techniques as possible (e.g., regression tests, unit tests, multiple static analysis tools, etc.). They use these techniques not as a substitute for a disciplined approach to design or to implementation (that would be foolish), but as a sanity check on a finished product. They use multiple checking techniques because they know they're human, and humans -- even the most skilled, most experienced, most disciplined ones -- make mistakes, and they want to do everything they reasonably can to catch mistakes before a product ships.
So to that end, model checkers (and other forms of checking) are Good Things(TM). The possibility that some will misconstrue checking facilities as a substitute for competent and disciplined engineers is a separate issue, and it's not the fault of the checking scheme. The *organizational* problem of poor recruiting cannot be solved by getting rid of model-checking systems, and if your recruiters think that talent can be replaced by a "verification" system, you've got bigger problems than merely the shoddy designs that will come down the pike.
(Please note that I prefer to use the term "check" rather than "verify", because the latter term, when used to describe a program, too easily connotes the notion that a "verified" program is free of any bugs (which is, needless to say, always a dubious claim). "Check" on the other had usually connotes the idea that there is a specific bug (or set of specific bugs) that is tested for. Of course, TFA mentions they don't want to imply that (verification == no bugs). But IMHO too many people make that mistake.)
Agreed. But I think Tycho put it best.
1) I prefer monospace; I find it easier on the eyes.
2) Where is it written that a variable-width font is preferred? Is there an equivalent of Strunk & White for Slashdot postings, or does it just grate on your own senses to see monospace used for plain text? If the former, I'll reform; if only the latter then I would have acquiesced except that...
3) It's difficult to yield to suggestions delivered with insult.
> Reading the code in the Boost libraries gives me headaches
/expletive-expression/... /expletive-expression/ did they do that?! /expletive-expression/ amazing!
I haven't had headaches yet, though I do go through a certain emotional pattern. There is pseudo-syntax for it:
human-reaction-to-boost:
What
How
That's
One of the upshots of reading Boost header code is that it forces you to learn more (or remember more) of the convoluted yarn that is Standard C++.
I see that as a good thing, though I can empathize with the notion that good generic code shouldn't force the reader to become too familiar with obscure language parsing rules.
> -- and often gives various compilers fits
It depends on the compiler. The key is ISO Standard compliance. The more your compiler supports Standard C++, the more likely it will handle the exploitive uses of C++ features found in Boost.
E.g., practically anything with an EDG front end released in or after 2003 can be regarded as fully Standard-compliant, which means you shouldn't get any fits when you compile Boost-using code. Recent versions of GCC (3.4.x and later) rank at a pretty close second on the compliance-o-meter. MSVC 7.1 and 8 are *much* closer to compliance than MSVC 6, but are still a bit rough in some less-provoked areas (mostly involving subtle aspects of name lookup and template processing). I think Sun is in a position similar to Microsoft, though I don't know what their weak points are. (All I know is that, due to pressure from Boost-using customers, recent versions of their compiler should handle it better.)
> I much prefer Objective-C's way of doing things to C++'s
> even despite the mystical "woojiness" of Boost.
Well, to each his own; but just remember that the existence of Obj-C++ means the woojiness is always within your reach, should the desire for woojiness* suddenly overtake you -- or should you hit a problem that would be most elegantly solved with a design that uses a function template. (:
*Props to you for use of the word "woojiness".
VoiceOver + foreign language text == nifty second language learning aid
> For instance, you can't have a C++ array of "anything",
... and see also:
> unless all objects descend from the same class, and then you
> are restricted to functions that were declared in that base
> class.
Sounds like someone hasn't tasted the sweet goodness of Boost. (:
In particular, Boost.Any gives you a simple and type-safe way to have a ${favorite_container_type} of anything.
See here:
http://boost.org/doc/html/any.html
http://boost.org/libs/libraries.htm
The nice part is that if you're using XCode and you're writing an app for the Mac, you don't have to choose between Obj-C and C++; you can use Objective-C++.
Yes, the '?:' extension is non-Standard. But note that I *did* specify use of GCC with its '-pedantic' option. Using that option and an example using '?:', I get:
$ g++ -pedantic -c a.cpp
a.cpp:4: error: ISO C++ forbids omitting the middle term of a ?: expression
It's true that Microsoft took a big step towards Standard compliance with VC 7. However, there are still (even in VC 8) a lot of subtle areas where they are bested by both EDG and the GNU people.
Anyone who has been compiling only with VC 7 should try using a copy of GCC/MinGW with '-pedantic' and Comeau with '-A'. Chances are that the code won't compile, and chances are that a majority of the errors will result from code that really is ill-formed according to the Standard.
But of course it's possible to write a Standard C++ program using VC 7/8. The question is whether Standard C++ features are being exploited. Most people who don't use modern libraries like the STL and the Boost libraries haven't really migrated to Standard C++ *in spirit*; they're just using a "better C" and taking advantage of some features that support object-oriented design.
Are you talking about Standard C++ or Microsoft++? There's a considerable difference, especially in recent years.
Microsoft likes to present a lot of its own extensions as "C++" features. In particular, they like to present C++/CLI (a.k.a "CLI++") keywords as "C++" keywords.
And then there are the managed extensions. (But even Microsoft has deprecated those in favor of CLI++.)
Going back even further, there's MSVC 6. Lots of people still use it, but it's just too old for anyone to expect it to be close to Standard compliance.
What compilers do you work with? Do you set compiler options to disable extensions and run in a "strict" standard-conforming mode? Do you use more than one compiler?
Do you make judicious use of the STL? Do you use any part of Boost? (If not, you should seriously consider taking some time to learn about these best-of-breed libraries that are available *for free* and for which support is available from multiple consulting firms.)
Did you give up trying either of those libraries before trying out STLFilt? (If so, go play with it. You'll probably want to give generic programming a second try.)
Have you and your team read any of the *good* C++ books? E.g.:
http://tinyurl.com/puhjb
http://tinyurl.com/ru625
http://tinyurl.com/mrdgo
http://tinyurl.com/ounbe
Have you invested in static analysis tools? (E.g., PC-Lint, etc.)
Most of the C++ programmers who cut their teeth on Windows learned a watered-down version of the language by way of the Microsoft libraries (e.g., MFC, which should *not* be mistaken for a model of modern C++ interface design). If that describes most of the people on your team, you should seriously consider migrating from "kinda-C++" to Standard C++.
That kind of works, but I think the authors wanted to make sure that nullptr has the same semantics everywhere, and the only clean way to force that is with a reserved word. If it's an identifier, the name can be hidden or replaced by some other library implementation, which could lead to all kinds of non-portable weirdness. And if the type is a normal user-defined type it can be used to deduce template arguments (which I think they wanted to avoid). Also, I think there were some other arguments about quality of code and diagnostics from compilers when referring to the type and to the value.
Rumor has it the ISO C++ committee is likely to pass through a proposal for a new keyword, nullptr, which will have a "magic" type "pointer-to-anything" and has the value of the null pointer constant.
// #1 // #2
// # calls #2 // calls #1
So, E.g.:
struct A;
int f( A* );
int f( int );
int m = f( 0 );
int n = f( nullptr );
Of course, that wouldn't help in the aforementioned case. 0 will still be convertible to a pointer type as it is now; it's just that 'nullptr', being a pointer itself, makes for a "better" conversion to a real pointer type.
nullptr is supposed to be a non-disruptive pure extension (except for the fact that it breaks code that uses 'nullptr' as an identifier) -- meaning that it should not change the meaning of existing code.
> We're geeks - we don't really worry about something affecting our social status!
Apparently the great-grand parent does; else why care so much about the name? Notice he didn't say he's not going to *buy* the system. He said he "won't be asking for a 'Wii' over a shop counter". It is to laugh.
gamer: Hi, uh... I'll take a copy of Red Steel and uh... I'll also need a console to go with that.
clerk: [clearly audible] Oh, so you need a **Wii**?
gamer: <whispering> Would you keep your fucking voice down!? Fucking Nintendo...
clerk: Sorry about that sir.
clerk: [projecting] Ok sir, your ***Wii*** game and your ***Wii*** both come to $265.00.
gamer: [completely flushed; hands over cash, takes goods and walks away quickly while staring at floor]
clerk: HAVE FUN PLAYING WITH YOUR WII! ...I love this job.
Seriously, I think the only people who have a problem with this "issue" are the same people who are easily embarrassed when accompanied by their parents in public. It's a character flaw that most people grow out of after adolescence (if they ever have it to begin with).
> As a gamer, I won't be asking for a 'Wii' over a shop counter.
Why not? Everyone else will. In a way, I'm inclined to believe the hype: once you actually play a game or two, your perception of the system's name's effect on your social status will fade.
>
> buy a game because the name isn't cool enough.
Heh. Every neighborhood has a Cartman or two, on average. (:
But really, none of that matters. It's the games that will decide
this. They'll be on display at local game shops. People -- and I mean
*normal* people as well as "hardcore gamers" -- will try before they
buy, and if they like the game they played, and if it doesn't hurt the
wallet too much, they'll buy that game. And as an *incidental* event,
they'll buy the system too.
Or, the games will suck and only the fanboys will buy. It's really that
simple.
If the Cartmans really had any influence over what games become popular,
then it would be difficult to imagine success ever visiting games with
such silly names as "Pac-Man", "Donkey Kong", "Super Monkey Ball" or
"Katamari Damacy".
("Hardcore gamers". Sheesh. A greater contradiction in terms would be
hard to find.)
Re. search engine scoring: excellent point; their marketing people must have taken that into consideration. It would virtually guarantee that any name they chose would have to have been completely unheard of in all major languages (except possibly as a little-known acronym).
Consider the other criteria met by the name "Wii":
It's short (one or two syllables, depending on how syllables are delimited in a language).
It's easy to pronounce in all major languages (despite erroneous claims to the contrary).
It looks and/or sounds foreign in a lot of major languages (if not all of them). Thus it grabs attention when people first see it.
It's a homonym (or near-homonym) for other words in a lot of major languages. (Thus it's really easy to come up with a play on words, which leads people to use the word more, whether intentionally or by accident. There will be a lot of people saying, "no pun intended" for a while.)
All of that leads people to start talking about their product *FOR FREE*. It also serves to distinguish their image from that of their competitors.
And, as you point out, the name doesn't factor into the "buy/don't buy" decision-making process. The novelty, quality of games, and price will do that. The name is there mainly to help draw attention and curiosity, and it's doing a bang-up job of that so far.
Thus, despite comments like those from Penny Arcade's Tycho, I suspect someone at Nintendo is going to get a promotion (or a pay raise, or -- at the very least -- a cookie) because of this.
From [a reply to] TFA:
"Vista - I wouldn't buy it with someone else's money. Then again What do I know, I've only been testing the dog for the last 2-3 yrs..."
Oy.
Ah -- others have pointed out that it refers to drum-based communication using the voice instead of drums. But I can't find a reference to the culture and/or language it comes from...
Sounds like you need a new dictionary. (:
According to my wordtank, ekiga can be represented with two Han letters that individually mean "side" and "bud" and means:
"(usually leafy) buds that form at the base of a root; also, commonly, those that form on the upper side of the base of a leaf and (in large numbers) from within a stem."
(Translated from: "Ha no tsuke ne ni dekiru me. Futsuu, ha no kibu no uwakawa ni dekiru ga, youhei no uchigawa ni shou-zuru mono mo ooi." But my Japanese is so rusty that it's actually a small pile of *iron oxide* and various impurities, so you might want to double-check that. Also, apologies for the romaji; stupid Slashdot still doesn't come in UTF-8 flavor.)
What that has to do with VOIP... I have no idea. (:
But that assumes the word is intended to be taken as Japanese, which I'm not so sure of...
... and the most important of these would be the amount of time that the voters like to spend playing games. In the linked-to list, it's clear that the voters spend *much* more time on games than I prefer.
I would much rather see a "top fifty" list compiled where the voters do not like to spend any more than five hours per week on games. I would expect titles like Wario Ware, Inc and Katamari Damacy to be close to (or in) the top ten.
"does that make them right? No. If they jumped off a bridge, would you? "
I'm not following the advice blindly. They present compelling arguments, and you (so far) don't. It doesn't make sense for me to re-state their arguments here, so I'm suggesting that you make yourself familiar with those arguments before you attack the conclusion of those arguments.
["Status code" is not a term I invented. Note that the term is used in a quoted region. Again, see Sutter & Alexandrescu.]
To cut a long discussion short: I think you should brush up on some of the modern literature on the subject. Even if you don't agree with it, you would at least be better able to explain why you think the experts have it wrong. Again, see Sutter & Alexandrescu. See also Stroustrup, writings by David Abrahams on exception safety, and basically every C++ author who was ever given any credit by the community. I don't think any of them referred to the use of exceptions as the lazy person's weak substitute for good error handling; and they refer to exceptions (when discussing non-bug errors) as the first consideration, not the last resort. And they give plenty of compelling reasons for their recommendation, whereas you've given one *weak* reason ("it encourages lazy error handling"). So please forgive me, but I cannot take your opinion seriously just yet.
You're right in thinking that exceptions should not propagate from library code to client code though -- in fact, that's generally recommended practice -- see my earlier post. But it's also generally accepted to use exceptions *within* the library code, so long as it doesn't spill over into the space of the library user.
Re: ISO comittees changing meaning of 'int' from 'signed int' to 'implementation-defined'.
c y-will-shorten-debug-times argument:
Not only is it "not likely"; it's "not-bloodly-likely", and it's "not-gonna-happen-in-this-universe--ever". This is a rule that held in K&R C, or, as some people like to call it, "Nixon-administration-C". It's one of those really, really old rules -- as old as C itself -- that all compiler vendors have always followed and will not dream of breaking unless we're talking about some experimental language that is not C or C++.
'signed int' is 'int'. They are different syntactic representations for the exact same internal type. No meaningful argument about this ever existed or will ever exist.
Same goes for operator precedence. The precedence rules have always just "been", and they have been followed consistently in every implementation of C and C++. There are other points of language interpretation that vary from compiler to compiler, but those points are overwhelmingly related to non-C, C++ features. I defy you to point out *one* implementation that proves me wrong.
Re: the 'explicit' keyword: Sorry, I didn't really mean to draw attention to the keyword itself; just that use of it ensures that you won't be left trying to figure out where all the implicit ctor calls are.
Re: the being-explicit-to-the-point-of-pointless-redundan
Bull. Having a better understanding of the language will shorten debug times. Adding meaningless layers of syntactic redundancy will only hurt the eyes of people who know what they're doing. If a newbie doesn't understand some nuance of the language, it means he needs to spend some time getting to know the language better, and no amount of adherence to a coding style will acceptably substitute that.