Slashdot Mirror

Im sick and tired of every other article being MMO-related. WoW is popular -- BIG FUCKING DEAL, quit flooding the section with that crap. How about a real article, like the one I submitted about the DS Wi-Fi Bounty, something way more interesting and news worthy than this tripe. Mod me offtopic, but you all know its true.

$1100 up for grabs for someone who makes a tcp/ip interface for the PSP. Wow.

No, no it isn't. Not even in the slightest.

FreeCiv has a long way to go before it catches up with Civ2, let alone Civ3 or Civ4. As far as being for Linux, Civ3 runs just fine in WINE.

Furthermore, that's not what irony means.

That's not what irony means.

That's not what Irony means.

America has one of the riches epicurean traditions on Earth, thanks. We've got immigrants from six more countries than actually exist on Earth, and they all brought their cuisines; the pastiche of cuisines which has erupted as a result is nothing short of fantastic.

Besides, you eat spotted dick, and that's not what irony is.

Your logging example is easily implemented in typical OO languages as the visitor pattern.

On another note, I think these types of critisms are really from people who are afraid of learning new languages or skills.

Curious, considering the criticism you levelled in response.

I presume that Java is your home language?

C++ and Java see exceptions quite differently.

Java uses exceptions to handle most problem conditions, including things as trivial as conversion errors and preventing the use of unallocated object instances (a particularly easy example comes in the form of trying to use a BinaryWriter without creating it first, thanks to checked exceptions.)

C++ uses exceptions quite differently. In C++, error conditions are not a reason to throw an exception. Exceptions are last-resorts. If someone detatches the drive while you're using it, then you throw an exception. I mean hell, there are a lot of C++ programmers out there which think that running out of RAM isn't a good enough reason to throw an exception, hence (nothrow) new.

While anything allocated on the stack will be destroyed when an exception is thrown

C++ exception handling was specifically designed to make this not true. Consider reading Sutter's dialogue on the difficulty of properly implementing constructors and destructors for safe behavior in exceptions, since the particulars of stack unwinding during exceptions and allocation/deallocation failures during construction are so complex. Nonetheless, it can be done if one knows the rules; grab the Sutter Trio, the Meyers Trio or the C++ Faq book if you want to find out how.

There is a trivial example about halfway down this MSDN page.

you never get an opportunity to clean up after the error condition

Yes, you do, by design.

To make matters worse, you never get an opportunity to rollback the state of the operation when you throw the exception.

You get control back safely, and if you implemented the Command pattern, you can make that rollback quite easily.

Not to mention the complications that arise when SEH is thrown into the mix

What problems do you suggest structured exception handling adds to an exception mechanism which, no offense, you're apparently not particularly familiar with in the first place? Particulars would be nice; it might be that I can provide you with the resources you need to use these admittedly difficult tools correctly.

Obviously you can write code to work around that.

No, you really can't. See, this is the difference between C++ and Java exceptions: Java exceptions get thrown a lot. You should never, ever see a C++ application throw an exception; if they do, they're 1) buggy, 2) written by programmers from languages with different opinions about exceptions, or 3) really buggy. Exceptions in C++ are for handling serious machine failures, not software errors. Software errors can be handled by less intrusive means with far less overhead and far less complicated rules about resource unwinding.

To be plain, if you're attempting to use C++ exceptions to catch code failures, you don't understand the purpose of exceptions in C++. Just because they use the same keywords doesn't mean they're particularly related.

Then, there is the overhead of actually throwing an exception ... making a pure virtual function call is cheap in comparison.

Frankly, the cost of a last-ditch "holy crap the machine just went apeshit" mechanism isn't important. You should never see an exception. Exceptions in C++ are for corporate-level fault tolerance, and nothing else.

I presume that Java is your home language?

C++ and Java see exceptions quite differently.

Java uses exceptions to handle most problem conditions, including things as trivial as conversion errors and preventing the use of unallocated object instances (a particularly easy example comes in the form of trying to use a BinaryWriter without creating it first, thanks to checked exceptions.)

C++ uses exceptions quite differently. In C++, error conditions are not a reason to throw an exception. Exceptions are last-resorts. If someone detatches the drive while you're using it, then you throw an exception. I mean hell, there are a lot of C++ programmers out there which think that running out of RAM isn't a good enough reason to throw an exception, hence (nothrow) new.

While anything allocated on the stack will be destroyed when an exception is thrown

C++ exception handling was specifically designed to make this not true. Consider reading Sutter's dialogue on the difficulty of properly implementing constructors and destructors for safe behavior in exceptions, since the particulars of stack unwinding during exceptions and allocation/deallocation failures during construction are so complex. Nonetheless, it can be done if one knows the rules; grab the Sutter Trio, the Meyers Trio or the C++ Faq book if you want to find out how.

There is a trivial example about halfway down this MSDN page.

you never get an opportunity to clean up after the error condition

Yes, you do, by design.

To make matters worse, you never get an opportunity to rollback the state of the operation when you throw the exception.

You get control back safely, and if you implemented the Command pattern, you can make that rollback quite easily.

Not to mention the complications that arise when SEH is thrown into the mix

What problems do you suggest structured exception handling adds to an exception mechanism which, no offense, you're apparently not particularly familiar with in the first place? Particulars would be nice; it might be that I can provide you with the resources you need to use these admittedly difficult tools correctly.

Obviously you can write code to work around that.

No, you really can't. See, this is the difference between C++ and Java exceptions: Java exceptions get thrown a lot. You should never, ever see a C++ application throw an exception; if they do, they're 1) buggy, 2) written by programmers from languages with different opinions about exceptions, or 3) really buggy. Exceptions in C++ are for handling serious machine failures, not software errors. Software errors can be handled by less intrusive means with far less overhead and far less complicated rules about resource unwinding.

To be plain, if you're attempting to use C++ exceptions to catch code failures, you don't understand the purpose of exceptions in C++. Just because they use the same keywords doesn't mean they're particularly related.

Then, there is the overhead of actually throwing an exception ... making a pure virtual function call is cheap in comparison.

Frankly, the cost of a last-ditch "holy crap the machine just went apeshit" mechanism isn't important. You should never see an exception. Exceptions in C++ are for corporate-level fault tolerance, and nothing else.

I presume that Java is your home language?

C++ and Java see exceptions quite differently.

Java uses exceptions to handle most problem conditions, including things as trivial as conversion errors and preventing the use of unallocated object instances (a particularly easy example comes in the form of trying to use a BinaryWriter without creating it first, thanks to checked exceptions.)

C++ uses exceptions quite differently. In C++, error conditions are not a reason to throw an exception. Exceptions are last-resorts. If someone detatches the drive while you're using it, then you throw an exception. I mean hell, there are a lot of C++ programmers out there which think that running out of RAM isn't a good enough reason to throw an exception, hence (nothrow) new.

While anything allocated on the stack will be destroyed when an exception is thrown

C++ exception handling was specifically designed to make this not true. Consider reading Sutter's dialogue on the difficulty of properly implementing constructors and destructors for safe behavior in exceptions, since the particulars of stack unwinding during exceptions and allocation/deallocation failures during construction are so complex. Nonetheless, it can be done if one knows the rules; grab the Sutter Trio, the Meyers Trio or the C++ Faq book if you want to find out how.

There is a trivial example about halfway down this MSDN page.

you never get an opportunity to clean up after the error condition

Yes, you do, by design.

To make matters worse, you never get an opportunity to rollback the state of the operation when you throw the exception.

You get control back safely, and if you implemented the Command pattern, you can make that rollback quite easily.

Not to mention the complications that arise when SEH is thrown into the mix

What problems do you suggest structured exception handling adds to an exception mechanism which, no offense, you're apparently not particularly familiar with in the first place? Particulars would be nice; it might be that I can provide you with the resources you need to use these admittedly difficult tools correctly.

Obviously you can write code to work around that.

No, you really can't. See, this is the difference between C++ and Java exceptions: Java exceptions get thrown a lot. You should never, ever see a C++ application throw an exception; if they do, they're 1) buggy, 2) written by programmers from languages with different opinions about exceptions, or 3) really buggy. Exceptions in C++ are for handling serious machine failures, not software errors. Software errors can be handled by less intrusive means with far less overhead and far less complicated rules about resource unwinding.

To be plain, if you're attempting to use C++ exceptions to catch code failures, you don't understand the purpose of exceptions in C++. Just because they use the same keywords doesn't mean they're particularly related.

Then, there is the overhead of actually throwing an exception ... making a pure virtual function call is cheap in comparison.

Frankly, the cost of a last-ditch "holy crap the machine just went apeshit" mechanism isn't important. You should never see an exception. Exceptions in C++ are for corporate-level fault tolerance, and nothing else.

Yeah, and the problem is, if you accept the first seven axioms, Dianetics makes a lot of sense, too. You can't build an argument on faith. This is a textbook case of the fallacy of false premise - it doesn't matter whether the things you're taking faith on are true or not; if they're not known to be true they're false. Period.

Oh, also, you can pretty easily raise Alf to God on a set of logic built from two false base axioms, if you try. Watch:

1) Ecologically dominant creatures are superior.
2) Anything higher on the food chain is ecologically dominant.
3) Alf eats cats.
4) As the Egyptians well knew, cats are gods.
5) As a predator of cats, Alf is higher on the food chain to, and thus superior to, cats, which are gods; therefore Alf is a superior god.

The false premises are #1 and #4. #2 isn't false because the definition of ecologically dominant is already established as fairly clear reductionist nonsense, but from that reductionist nonsense definition #2 would be valid. #1 is the kind of "yeah, so if you just accept this" thing you just did, and #4 is Argumentum ad Verecundiam, which you commit both when you refer vapidly to scientists "arguing" about the burst patterns in the developmental record, which hasn't been argued since a year after it was noticed - having records is funny that way.

So, look, evolution is obviously true, and Alf is God. But hey, when those martians show up and start eating us, we'd better not fight back, because they're our predators and therefore ethically superior, too; the appropriate way to do things would be to worship them all the way down their throat.

And also we need to follow John Travolta to a meeting. You should read Dianetics, some time: it's pretty crazy how if you just accept the first ten crooked things, the rest just all falls into place.

Rotten foundations make rotten arguments, in short.

How ironic

Not in the slightest.

Please refer to this page for further definitions, etymology, examples, etc.

Q. (The Pedant)

1) Argumentum ad hominem means "argument against the person." Given that a corporation is not a person, one cannot apply argumentum ad hominem to the corporation, even if a fallacious argument is based on the attack of character. In this case, the appropriate fallacy is Appeal to Motive, though the cases can be made for Appeal to Ridicule, Appeal to Spite, Misleading vividness or Poisoning the Well.

2) No, a public postal service is not a natural monopoly. The USPS was once an unnatural monopoly - a monopoly granted by the government (it no longer is.) Microsoft is a natural monopoly, ie a monopoly which arose on its own, rather than one which was created to suit a task.

3) Logistics is a field; it cannot be or not be a monopoly. However, contrary to the impression you give, logistics does not lead to unnatural monopolies; it leads to natural monopolies by providing a more efficient workforce. You're just wrong.

4) Arguably nothing. Much like logistics, industry is not a company, and therefore the word monopoly simply does not apply to it. However, your implication that an industrial firm cannot be a natural monopoly is patently ridiculous. Were that true, the term would not exist. It doesn't depend on how you define an industry at all: either the monopoly arose on its own (natural; microsoft, bell, general motors) or was granted by an outside power such as government (USPS, utilities.)

Just because you don't understand the distinction does not empower you to comment upon its nonextance. You should take an economics course before telling people that an economics term never applies to any company. That's just boneheaded.

Yes it's a bit of hyperbole, but...Ever heard of something called hypocricy, or irony. When our 'president' talks about Freedom{tm} in his Inagural speach, and yet it's obvious to those around the world looking at things like Gitmo that Freedom{tm} isn't total for this country, you've got to wonder. Yes, Mao did some dispicable things, but, that dones't excues us from actually following our retoric.

We talk about freedom and democracy, but, if we can't show that we follow it in our everyday life then we're just blowing hot air. This is why the world laughs at us. We talk of freedom, but, count China, Saudi Arabia, Pakistan, Russia, etc. among our 'friends' how is that embracing freedom?

You definitely need to pay more attention to the keys you press. Also, stop misusing that word

Stop misusing that word!

This piece is a nice criticism of IGN's article. It seems that the author doesn't know much about games from previous generations and the complexity involved on creating the fancy stuff he wants so much.

I think the separate header is simply code duplication and memory limitations of old C compilers.

Headers have never had anything to do with memory limitations, and by definition code in a header cannot be repeated in an implementation file. It's worth noting that code should only ever be in a header if it is to be inlined, which doesn't exist in C until C99, by which point memory limitations simply don't matter. (It is worth pointing out that placing templates in headers is not placing code in headers, but rather placing code factories in headers, which is quite a different thing.)

Larger programs (compilation unit)

The phrase "compilation unit" does not mean anything in C++. I expect you mean Translation Unit, but TUs aren't a function of larger programs; it's simply that in larger programs not seperating your code into TUs is suicide. A translation unit is simply the code block associated with an object file (or other prelinker binary.)

The main problem with headers is that preprocessor stat is global to the entire operation, not per header or C file.

This is not a problem; it is an asset. Without preprocessor effects spanning the compile tree, virtually every metaprogramming technique and virtually every compile-time code removal not built on SFINAE would simply fail.

This makes conditional state flow from one to the other, which makes separate precompiled headers hard (since the conditionals might not match).

State does not exist in the compile tree. This is a critical misunderstanding of the way in which a compiler works - the preprocessor effectively does not exist within the code tree. There is no state whatsoever; that would imply that during either compilation or runtime the preprocessor's effects could be altered, which simply isn't true. There is a good explanation in Modern C++ Design of the limitations which statelessness imposes on metaprogramming techniques in C++, and how one can avoid them by other means such as typelists. As far as making seperate PCH hard, well, it's not really hard in any way. There's no issue of conditionals matching, because since the preprocessor is stateless, there is no way to ordinate a conditional. (There are arguments that metaprogramming techniques like Substitution Failure Is Not An Error defeats this; they are wrong. SFINAE is a compile-time polymorphism, not a conditional; no branch is ever taken.)

Also the header system requires manual making of makefiles (or using quite complex scanners and tools)

Uh, no it doesn't. Here's a rudimentary generic makefile. It would be wise not to discuss limitations of tools with which you are not familiar. Besides, the idea that something like NMake is complex is sort of funny; it's actually quite retarded. Back in reality, it's the languages which implicitly generate header-type interface definitions which need complex scanners, which are built into the compilers themselves; that's probably why you remain unaware of them.

See most Wirthian languages (e.g. Turbo Pascal vs Turbo C++) for examples.

Wirth has nothing to do with Turbo Pascal, which is an instance of (depending on the year) either Borland Pascal or Object Pascal. This is a bit like calling C++ a Kernighan language. Object Pascal and Borland Pascal are both significantly distant from ANSI Pascal, the closest non-dead relative to the original teaching tool.

Namedropping doesn't make you seem correct, y'know.

I think the separate header is simply code duplication and memory limitations of old C compilers.

Headers have never had anything to do with memory limitations, and by definition code in a header cannot be repeated in an implementation file. It's worth noting that code should only ever be in a header if it is to be inlined, which doesn't exist in C until C99, by which point memory limitations simply don't matter. (It is worth pointing out that placing templates in headers is not placing code in headers, but rather placing code factories in headers, which is quite a different thing.)

Larger programs (compilation unit)

The phrase "compilation unit" does not mean anything in C++. I expect you mean Translation Unit, but TUs aren't a function of larger programs; it's simply that in larger programs not seperating your code into TUs is suicide. A translation unit is simply the code block associated with an object file (or other prelinker binary.)

The main problem with headers is that preprocessor stat is global to the entire operation, not per header or C file.

This is not a problem; it is an asset. Without preprocessor effects spanning the compile tree, virtually every metaprogramming technique and virtually every compile-time code removal not built on SFINAE would simply fail.

This makes conditional state flow from one to the other, which makes separate precompiled headers hard (since the conditionals might not match).

State does not exist in the compile tree. This is a critical misunderstanding of the way in which a compiler works - the preprocessor effectively does not exist within the code tree. There is no state whatsoever; that would imply that during either compilation or runtime the preprocessor's effects could be altered, which simply isn't true. There is a good explanation in Modern C++ Design of the limitations which statelessness imposes on metaprogramming techniques in C++, and how one can avoid them by other means such as typelists. As far as making seperate PCH hard, well, it's not really hard in any way. There's no issue of conditionals matching, because since the preprocessor is stateless, there is no way to ordinate a conditional. (There are arguments that metaprogramming techniques like Substitution Failure Is Not An Error defeats this; they are wrong. SFINAE is a compile-time polymorphism, not a conditional; no branch is ever taken.)

Also the header system requires manual making of makefiles (or using quite complex scanners and tools)

Uh, no it doesn't. Here's a rudimentary generic makefile. It would be wise not to discuss limitations of tools with which you are not familiar. Besides, the idea that something like NMake is complex is sort of funny; it's actually quite retarded. Back in reality, it's the languages which implicitly generate header-type interface definitions which need complex scanners, which are built into the compilers themselves; that's probably why you remain unaware of them.

See most Wirthian languages (e.g. Turbo Pascal vs Turbo C++) for examples.

Wirth has nothing to do with Turbo Pascal, which is an instance of (depending on the year) either Borland Pascal or Object Pascal. This is a bit like calling C++ a Kernighan language. Object Pascal and Borland Pascal are both significantly distant from ANSI Pascal, the closest non-dead relative to the original teaching tool.

Namedropping doesn't make you seem correct, y'know.

You don't want to abandon headers; they are the basis of seperation into translation units. If you're compiling from the top and it's faster than compiling small pieces, then that means your source needs a hell of a lot more decoupling; by definition the only way that top-down build could possibly be faster than incremental build is if incremental build is still making everything anyway.

Consider reading Modern C++ Design, specifically the section about generic functors, which should help you with your coupling problem until you have the time to learn to seperate TUs aggressively on your own. In my opinion, the Boost functors are better than the Loki functors, but the book is a hell of a lot better than the Boost documentation, so read it anyway.

Ask a large project supervisor in a company with aggressive compilation tactics about the large compile-time wins of precompiled headers. Whereas it's not the same issue, the same critical foundations are there, and it's generally easier to squeeze out an answer about PCH than properly seperated TUs.

Why do I always run out of mod points right before I read a comment that really deserves to be modded up?

I read the IGN article, and I'm sorry, the guy doesn't know what he's talking about.

I was planning to write a long critique on the article, until I read the link in the parent post ... it says most of what I wanted to say. So go ahead and read it

This article is actually worse than most of IGN's bilge.

This sig, in its attempt to be clever, is secretly ironic.

Not even remotely. (I hope you aren't going to suggest a structure paradox wherein the irony is the misuse of the word irony; that doesn't work, intended secrecy or no.)

I don't have time to respond you your entire diatribe

You wrote five long paragraphs after saying this. Smells like an excuse to me; this is quite nicely fortified by that you've ignored every single criticism I've made of you, hoping instead to just talk about things you want to discuss and to ignore the earlier ignorances you floated, as if you're unable to face what you said. This is fortified by the argumentum ad hominem which follows. Luckily, I'm under no such restriction.

I can tell a 5-year-old that his spinach has vitamins that will help him grow, and he'll eat it for that reason?

I never said that. All I said was that it was your responsibility to explain edicts that you give to others. (That said, my child at five years old listened to me when I told her things. Maybe that's because I took the time to treat her like an intelligent individual, capable of grasping concepts like "spinach is good for you," which honestly isn't that difficult.)

Do you actually think 5-year-olds are motivated by rationalisms

When you treat them rationally when raising them, yes. I've got two kids that came out just fine that way. Naive as you may think it, it's also drawn from experience.

and that by giving him a reason he doesn't really understand (no, sorry, 5-year-olds don't understand nutrition)

Maybe yours doesn't. Stop treating him or her like an idiot, and things might change. "Hey daddy, why is that man fat?" "Because he eats too much and of the wrong things. That's why I keep making you eat the spinach." That said, spinach is actually pretty good, if you know better than to overcook it; my five year old never actually fought the issue. At all. Ever.

Talk to me after you've had one or two of your own.

I already did, captain guesses a lot.

There's a difference between refusing to explain your reasoning, and realizing that an explanation won't achieve your goals.

Fatalism doesn't excuse you from proper behavior.

Certainly you should be forthcoming if it's appropriate.

At any point you've given someone a command, an explanation is not only appropriate, but ethically required.

You'd think that this is the time when you'd most want to explain your reasoning, but how much will that really mean to a room full of high-school students half of which are only in the course to fill out their schedules?

Quite a bit. As the son of a college professor, I'm intimately familiar with the lives of a number of students whose lives were changed by finding out that a curricular requirement turned out to be their life's drive.

That said, none of this is important. If you really think that you're excused from standing up for the things you say just because you doubt explanations will do any good, well, then I understand the tone you've taken with the rest of this letter, guessing about whether I ahve children and so forth; frankly you're contemptuous. If you give a thousand commands and explain them all, and if only one of those explanations gets through to someone, then you've still done good, at the cost of ten or fifteen seconds of being an adult after being pompous.

You could explain until you're blue in the face and you'll only make an impression on a minority.

This is a non-sequitor: the issue is your ethical requirements, not their upshots.

If you read my post more carefully anyway, you'll find I suggested nothing like a blanket "harrass[ment](!)" of GOTOs.

You didn't have to suggest it: you began the harassment yourself by simply blanket stating that they're wrong, which is simply incorrect, no matter how many ways you want to spin it as a different issue.

It's more worthwhile to save it for the advanced classes where the students actually give a damn.

Has it ever dawned on you that the reason nob

"I don't believe people should do things for reasons they don't understand--things like looking healthy, eating spinach, or avoiding GO TO statements. Rules without reasons focus on the appearance of things, not the substance."

No, rules without reasons help a person develop healthy habits and to benefit from them before he learns the reasons for them. That can come in its own good time.

The mantra of indocrination everywhere.

It rarely does any good to try to explain to a child why he should eat his spinach

Don't confuse explanation with convincing. It's one thing to tell a child to eat his spinach because it's got vitamins and iron whether he wants to or not; entirely another to tell him to eat his spinach without telling him why.

By the time he understands why it's good for him he's in the habit of eating it

Honestly, if you have a hard time explaining "this has vitamins which you need to grow" to a five year old, you need a Doctor Spock book or three.

A novice programmer might not understand why GOTOs are to be reserved for a small number of special situations, but you impose standards enforced via peer review that makes him avoid them when unnecessary anyway.

Yes yes, and this seems like a perfectly rational viewpoint. The problem is, it's not; this is an exposition of bias, and whether or not there's a real underlying motive, at best it's nothing more than an enthymeme.

Besides, the fact of the matter is that people are just sometimes wrong. If you refuse to expose your reasoning, then you also deny the person being controlled their oppoirtunity and right to suggest counterpoints or alternatives. Consider for example the first game I wrote for a cellular phone development firm: they simply told me that I was not to use C++. It being a new job I simply rolled over. However, as time went on, as is typical, it became more and more obvious that the lack of proper encapsulation was helping certain of my coworkers retard my code up something proper. Eventually I took the employer, who'd set himself up in mch the same manner as you've set yourself up, to task on the issue; I got him to admit that the issue was supposedly efficiency, and proceeded on my own time to perform a proper code seperation. The application was actually very slightly (insignificantly) faster, presumably due to the compiler being able to make some obscure tiny optimization somewhere based on new knowledge.

In my admittedly limited experience, it has been the case that people which set limits without explaining them generally do not understand the limits, and as a corrolary effect have usually picked them up by hearing them repeated by other supposedly clueful people.

In fact, in my experience, frequently the people which repeat these mantras think that just being aware that there is such a principle is what creates clue. But, if you ask them to justify why gotos are bad, they tend to flounder: "because, well, it breaks the, uh, path of flow of the function, and, er, because they're just bad form, everybody knows it, god, just do your work." I've been aware of and annoyed by this principle for quite some time now; it's become my habit to attempt to catch people in it. Unfortunately, I only know how to catch people in conversation, and I don't feel like rereading this thread, so I'll just show you how it works.

Start by saying "GOTOs aren't really that bad, though. People just use them in broken ways." When the response is inevitably "yeah, GOTOs are bad because people use them wrong," say "No, no: I mean, people just write bugs with GOTO. It's hard to use it in a capital-B bad way which isn't just incorrect." When they insist that's not true, ask them for an example.

When they tell you they don't have time to write the code, then grab the GOTO fascicle from Dewhurst and ask them if they think th

My prediction for 2005: Slashdotters will continue to think that "Redudant" means "I saw that coming a mile away." (If I were less of a man, I'd call it ironic.)

I nominate you for most cruelly coincidental combination of content error and sig discussion of knowledge ever.

Oy.

"Maintain." "Veneer." Neither republic nor autocracy are capitalized, and Augustus was not an autocrat. That's not what RE: means. Yes, he was a king (though the Romans used the term Emperor.) "Consulate," "Triumvirate," and none among consulate, triumvirate, censorship, pontificate or president are capitalized. (Yes yes, many history books say consulship. They also think it's ironic that the Senate which created the Caesars also ended up killing them; just because a textbook uses a word doesn't mean it's used correctly, these days, unfortunately.) "Cabinet." There is nothing in the Constitution nor any of its amendments about the cabinet. There's only one Constitution, and it's kind of sad that you didn't capitalize it, when you capitalized so many words which don't deserve it. s/I'd/It would/ , and no, it wouldn't. Maybe you didn't realize this, but the President has to deal with more people than just the Cabinet. Thousands more people, in fact.

Generals cannot be six star, and whereas I'm sure you're going to tell me that that's supposed to be some kind of crafty joke based on some observation that false statements don't suddenly become true just because they're spoken, I think your post has already done quite a neat job of straight manning that point already. Commander in Chief does not actually confer military rank, nor even the ability to give any military orders beyond deployment (for example, Commander in Chief may not reassign military staff.) Besides, it's mostly a ceremonial title since the establishment of the five central command branches in the Goldwater-Nichols defense reorganization act of 1986. It may be time for you to get a basic understanding of the government you're attempting to discuss.

On a more serious note, instead of discussing how you have a flaw in your grammar on average every 3.2 words (throw it in MS Word and check; I'm not making that number up,) let's discuss what horseshit your analogy is.

Republics cannot be veneered in the way you suggest. Either the populace can or it cannot vote. Now, before you go on spouting all these conspiracy theories about how the US doesn't allow its citizens to choose their own show color anymore, let me remind you that the US is a federal republic, not a republic; the two are about as different as a herd of cats and a single cat. Most of the time people spend whining about what their federal government won't allow them to do would be better spent face down in a highschool civics book learning how their state government worked, since their state government is significantly more involved in their lives than their federal government is.

Either a government gives voting power to its people, in which case it is a republic, or it does not, in which case you're a moron trying to make an Orwellian point without actually having a point to make. Now look, I'm usually the first person on the "Bush stole the vote" bandwagon, but let's at least try to pretend to be reasonable: when you come in swinging with no facts, no examples, and nearly literally everything you said wrong both in presentation and content, then really, someone's going to as for you to be modded into the floor.

I am that someone. Please mod parent through the floor and into the very core of the Earth.

And some final nit-picking:

1) Shut up.

2) Wait. You're not going to appoint a cabinet, but you're still going to have joint chiefs of staff? Who do you think makes up the top end of the cabinet?

3) Suit. Jesus, it's called a suit. A suite is a nice room. And who cares how you'd barbie yourself up when you were in the job that you seem to think makes you king of the world?

Personally, if I were President I wouldn't appoint any cabinate officals. The constitutions says I can, not that I have to.

4) Oy

No, we can only infer that if it's not deceptive, then it's not warfare.

You can't infer anything at all from a fallacy. This one is called Argumentum ad Verecundiam which is loosely translated "Appeal to Authority." The general idea (yay for puns) is that it really doesn't matter to whom you refer; witty quotes are not a legitimate basis for argument, and neither is referring to another person's opinion, regardless of their topical status.

The idea that all war is deception is outright silly. Yes, there's quite a bit of deception involved in war, but sometimes (with all apologies to Freud, for once) a fleet of tanks is just a fleet of tanks. Yes yes, hollywood, world war two, knockdown sets, we all know how the Battle of the Bulge worked. (Hear that, Europeans? Americans know about things that happened further away than California!) Nonetheless, just because there are many things in war which are based on misdirection, there are also many things which are not; pretending otherwise, even based on an aesthetically pleasing three thousand year old quote about war from when the avant garde was guys on horses with sharp sticks (because surely all that wisdom applies in the era of the supersonic space bomber,) is nothing better than affected ignorance.

template <class Topic>
volatile float GetSlashdotPostQuality<const AboutLogic>(const Post&) {
return std::numeric_limits<float>::min();
}

It is ironic

Whereas I agree with the sentiment, that's not what irony means.

Simply the fact that one can make a movie based on and using the title of a copy-written work without consulting the author

That's not frequently true of well-known authors, or in fact of most book contracts with little-known authors. Pretty much the only publishing subindustries with that sort of conjoinder in their contracts standard-issue are science fiction and horror; if you try to run that sort of clause in a fiction contract you will be summarily laughed off of the phone by any typical book agent.

Furthermore, in science fiction and in horror, movies and miniseries are rarely made from the work of little-known authors. So, whereas it is an issue for those two genres, it's less of an issue IMOALE than you suggest.

No author wants to give up rights to their creations, but if they want to be published, they have little choice.

If this is spoken from experience rather than guesses and prejudice, then my friend, you need a better agent. This is a bit like hearing "no programmer wants to use Microsoft tools, but if they want SQL, they have little choice." Well yes, they do, given a simple familiarity with what's available to them.

Amusingly, both the Los Angeles Valley and Mexico City had smog before the invention of the combustion engine. Just because you can see it doesn't mean that you're correctly estimating its origin or its impacts, even if (and in fact often when) it seems totally obvious. To wit, New York City puts out more emissions than Los Angeles, and yet it's barely even hazy.

The bulk of the gasses we currently believe are contributing to global warming are totally invisible. The next time you point to smog and start to tell yourself you can see the roots of global warming, remind yourself that in fact you cannot.

I'm not arguing your point; I agree that reducing emissions is critical. That said, your example is worthless, and your tone towards the parent utterly unwarranted. This is the sort of thing which, if said on the city street, often leads to a missing tooth. It may surprise you to learn that, rather than being seen as insightful and witty, you're actually seen quite differently.

Anyone find it extremely ironic

No.

Isn't it cruelly coincidental that the person mocking someone for not knowing the difference between a memorandum and a referendum doesn't know what irony is?