And I could hardly understand how people getting hit in cross-walks related to jay-walking.
It doesn't. This is perfectly normal, though. After 9/11, they started checking IDs at the security checkpoint, even though all the hijakers had legitimate ID and did not use an alias. But it was easier to do that and appear to be tackling the problem than to address the underlying issues of terrorism. Same thing with pedestrian injuries and the university.
The thing that drives me nuts about the perception of SUV safety is that it's based soley on their mass and the head-on collision testing done in the U.S.
Most collisions between cars traveling in opposite directions are not dead-on center like when they crash an SUV against a wall in testing. Most collisions have the cars slightly offset and at a slightly oblique angle. In this case, the greater momentum of the SUV is actually worse as the impact will tend to make the SUV turn, but its momentum will make it want to continue forward. Then the SUV's high center of gravity makes it tumble. This is why safety tests that try to simulate this situation (I think some European safety testing is done this way, where the impact wall is offset from the front of the vehicle) actually put SUVs below most cars in terms of safety, even in a car-SUV collision.
Honestly, from driving an SUV and being able to feel the instability of the car at highway speeds, I can't see how anyone believes they are safer.
To all soccer moms: If you need a safe and practical kid-mover, buy a mini-van. You'll still have the extra mass that makes you feel safe, you'll have a lower center of gravity so you'll actually be safer, and your kids will have an easier time climbing in and out of a vehicle that isn't three feet off the ground.
To all soccer dads: Your SUV is not cool, and will not compensate for your expanding gut and receding hairline. Buy a mini-van and put flame decals on it if you have to have a practical kid-mover and your mid-life-crisis in the same vehicle.
Few people need SUVs for the things they're actually better than mini-vans at: towing capacity and ground clearance. Safety? Not a chance. SUVs are a ridiculous fad that needs to die. When the only ones driving SUVs are the ones who benefit from one, everything will be fine.
We use the same ballot system here in my little corner of Missouri, and I assure you that it's very possible to leave a chad hanging, even with the "approved" punch device that's part of the voting station. No icepick required.
Precisely. It is quite possible to create an invalid ballot. The notion, floated in 2000 with alarming ease, that only poor black people in a Democratic district were unable to produce valid ballots is pure nonsense.
The answer to why there were so many more invalid ballots in those districts is simple. In some districts, the machine was configured to reject an invalid ballot and spit it back out so the voter could fix it -- the behavior one would expect in a sane world. In other districts, the machine was configured to accept the ballot, and then of course not count it because it was invalid.
It was modded insightful because the post he replied to suggested that you should be able to verify your vote is correct once you get home. This is utterly unnacceptable, since it breaks anonymous voting. If you can verify your vote once you leave the polling station, then you can be coerced into verifying your vote for someone else.
As far as being illegal -- all forms of voting fraud are illegal, yet they still occur. All crimes are illegal (duh) yet they still occur. You might not believe this, but a lot of people would be willing to give in to coercion to keep their job, rather than lose their job and have to wait years to prosecute a lawsuit in hopes of getting compensation. Making vote buying or vote coersion possible by breaking anonymous voting is a bad idea.
Anonymous voting is good. Non-anonymous voting is bad. That's all; I guess it's only insightful if you didn't know that.
And then there are those of us who actually utilize our brains and realize that if a statement cannot be proven, it is not worth making.
There are many things that are true that cannot be proven. There are many decisions one must make where one cannot prove what the best solution is. There are many things that are simply matters of opinion, which intelligent people can discuss reasonably, realizing you cannot "prove" your position.
Then there are idiots like you, who failed 1st grade "fact or opinion?" exercizes. No, really. This whole thread is little more than a discussion of opinions on coding style and if you think your 'opinion' is 'fact' then you are indeed a retard of the highest order.
someVector += 5, 6; would be equivalent to someVector.pushBack(5); someVector.pushBack(6);
I thought from the article that it would have to look like someVector += {5,6}, like it would if 5,6 was intended to be a normal array initializer. That doesn't seem so bad. That is what I would expect array addition to do -- concatenate two arrays.
The main problem with 'vector' and operators as far as I'm concerned is the name. Absolutely terrible name for "better array". While a (math) vector is an array, an array isn't necessarily a vector. I would expect to be able to do a vector dot product with '*', but of course I can't. And then if you want to make a useful mathematical vector class, the name is already taken.:P
I think pretty much only best way to do it if you want to stick with printf stuff is to make a toString method, and then you can use that as you please.
Yeah, like I said, that's what I do. printf("%s", myObject.toString().c_str()) is the kind of thing you'll see in my code.
I do think the situation is worse with input though. You can't write a "read from this string" function because then how does the code that calls it doesn't know how much to read from the keyboard before it calls it; if it reads too little, the object can't be built, but if it reads too much it's extracted too much from the stream.
Serializing non-POD types from keyboard input is evil.:) But yeah, this is more difficult. To solve the problem, the interface would have to do two things: tell the caller how many bytes it read from the string, and second tell it if there were insufficient bytes to create the object. The second you can do either by returning an error code like pre-glibc2 snprintf(), or better by returning how many bytes the function -would- have read if there were enough, like post-glibc2 snprintf(). Returning the number of bytes needed being more difficult if not impossible to implement in every case.
I'm not a big fan of plain-ol text serialization of objects though. If the objects are complex, then the format should be structured (like xml or length encoding) such that the program -can- know how much data is intended for each object.
I had a bit of BASIC experience before moving to C++, and cout is a lot closer to PRINT than printf is (somewhat ironically given the names), so that's my theory as to why I almost always use cout.
*shudder* I have a lot of BASIC experience pre-dating my move to C, which pre-dated my move to C++ by several years. I never made a connection between PRINT and cout, but it could be that my subconscious is rejecting anything related to those long, dark years of GW-BASIC.
Heh. Remember when/. used to be full of cool geeky coding discussions like this one?
I would like to take a time out of this post and say just how wonderful the UndoCloseTab extension is in Firefox
I'll check it out. I use a dvorak keyboard, but have never had that problem (but I tend to be mouse-driven when using a browser anyway).
Shifting is nothing like being incomprably smaller than another number.... but that's what "
Just like calculus means different things to a dentist and a mathematician, the C/C++ programming language is a specific field with its own jargon and the 'obvious meaning' of an overloaded operator should be derived from that. Obviously. Since 1970-ish, << has meant bitwise left-shift in the realm of the C programming language and its derivatives.
Perhaps a better way to put it would have been to say that a programmer should be able to intuit the behavior of an operator based on the behavior of that operator on all other types.
Doesn't work. In normal times, when Child is-a Parent, then Foo(Parent*) can be passed either a Child or Parent and operate on it transparently.
True, if you use virtual functions. If that's the goal, has-a won't work. I still think that if you do want your child class to be used 'transparently' you're going to have to be able to access or change the child classes 'private' members. In many cases, anyway.
Even so, the syntax of printf is nicely more compact, and the speed is not hugely important, so one may wish for a "C++ aware" printf. Such a function could work by adding an additional format specifier (say %P), which indicates that the argument is a pointer to a class derived from PrintfCompatible. PrintfCompatible would have a single pure virtual toString function.
No, I don't wish for that. It's unnecessary. To make my objects 'printf compatible' I give them a function which returns a string, and use %s in printf. Actually it returns a std::string, which is nicer than returning a char* for a lot of reasons. Thus it looks like this: printf("%s", someObject.toString().c_str())
So reentrancy isn't a problem. Dynamic memory still is. I'm not certain the room for compiler optimization is that large (my off-the cuff guess is avoiding branch mispredicts by avoiding the indirect branch of a case statement is the most help). I'd be interested to compare the performance of cout and printf, with and without non-POD types. For printing to a console or other such, I highly doubt it matters. But for buffered file io or other in-memory operations it may.
But implement your own printf analog, and gcc won't know to check the format string for type information.
If your printf analog uses the same format specifiers as printf, then it can with a gcc-specific directive. In the general case though, yeah, varargs lack type safety.
I've seen advice that addresses this point, and recommends the use of reference parameters for situations in which null is invalid and pointers for when null is valid for this very reason. Sutter and Alexandrescu give this advice for when to pass by pointer and when to pass by reference:
* Prefer passing by (smart) pointer if the argument is optional (so callers can pass null as a "not available" or "don't care" value [the issue discussed above] or if the function stores a copy of the pointer or otherwise manipulates ownership of the argument
* Prefer passing by reference if the argument is required and the function won't store a pointer to it or otherwise affect its ownership.
Hmm, that isn't terrible advice, actually. You don't have to bring up examples of functions that take NULL to mean "don't care", I know of some. time() being the first one that springs to mind, and of course I've written some myself. I would still prefer some syntax that indicates that a value is being passed by reference.
If the input isn't valid, nothing you can legally do will find it.
In the sense that your reference/pointer might be referring to a deallocated (and possibly subsequently re-allocated) object, sure. That feeds into the issue that refrences are not a magical fix for memory management bugs, but that's a digression. I meant in the general sense that one must verify all inputs for logical validity. Indicies must be in the correct range, flags must have understood values, that kind of thing. Most substantial functions I write start with a block of assert() precondition and parameter checks, and checking for a null pointer is just one more. Granted, it is one more.
You just moved to runtime what the compiler could have enforced (as much as anything can be) for you at compile time.
I don't see how that is the case. Obviously there is a runtime check that didn't exist before, but in situations where one could actually get a null pointer I don't see how changing to references fixes it at compile time. I can only see it in the sense that you can't use new() to assign to a reference and then forget to check for null like you can with pointers, but that's just avoiding the functionality, not fixing the problem. I'm missing something, so help me out.
There are other places where references are "necessary" though (for instance the return value of vector::operator[]), so they couldn't be removed from the language entirely even if you didn't allow them in argument lists.
No, no, I didn't mean get rid of references, or even disallow them, I just think the other poster's favorite usage of references is anything but 'best'. For operators references are a necessity. Like operator overloading, I think references are a feature that should be used with care and that many C++ programmers go overboard using these features simply because they are there.
The only C++ feature I think should be removed is the 'private' keyword. It has just never worked out for me that I could derive from a class and override its functions without having an intimate knowledge of how the base class worked. The 'has-a' relationship seems much better if you want to treat the base class like a black box. Personally I think "private" should mean what "protected" does today, and "protected" should be changed to mean that members can be accessed but not modified. This would fix my other pet peeve, having to write swarms of getFoo() functions just to disuade random doinking with the internal state. But I digress into a dreamland...
And I posted another comment about how I don't find even the readability argument in favor of passing by pointers unconvincing.
Yeah, and I agreed with your caveats (especially that all my blather only applies to C++ references).
It's good rule, and one reason why I think that the proposed someVector += 5, 6; syntax is absolutely awful.
Ugh, what's that supposed to mean? Is that something using the sequence constructor?
However, I think that an exception can be made for the shifting operators and input and output partly because of the very long history that they have, and partly because (to my knowledge) the shifting operators were pretty much invented for programming. +, *, etc. all have meanings we've seen since kindergarden or before; << doesn't. It makes sense, but then it also sort of makes sense for stream operations.
Sure, now it has history, but at the time << had a long history of being only the shift operator. I agree that if one were going to pick an operator to make into the stream operator, that was the best one. I wish they had created a new one, like ~~, but I can think of a couple reasons why that could have been undesireable.
(I know this is a war I can't win, but: I think that printf syntax often looks nicer, but it's harder to learn, a lot harder to understand if you don't know it, and isn't typesafe. You also have issues with how you output with classes because you
Your original statement used Bjarne's approval as proof of correctness. That's the false logic that I disagree with. Sure, he has a lot of good ideas. That doesn't mean he's right, not even close.
A lot of people would grant more weight to the opinion of Bjarne Stroustrup, inventor of the C++ language, over Chris Burke, random/. poster. It was not intended to be a logical proof, though I won't fault you for assuming it was. Of course he isn't always right. Except in this case he is right.
Your entire argument logically follows from this statement. However, I don't agree with this statement, so I don't agree with the rest of your argument.
You're backwards. "Pass by pointer makes for easier to understand code" is my conclusion, not the axiom.
Don't be ridiculous. Of course I use descriptive variable names. That's why I don't need to use pointers to pass-by-reference. Because my function names are good.
Okay, maybe your function names are way better than mine, then. I'm trying to imagine how that would work for a non-trivial example. functionThatDoesFooWithParameterNPassedByReference () ? Hungarian notation? Help me out here.
Also, does this mean that you do see the value in making the pass by value/pointer distinction clear at the calling point instead of making them refer to the header file?
Ok, so your logic is that the more information is included at the call point, the better. Ok, then why don't we include all kinds of other information there too.
Yes, with the common sense caveat that there can be too much of a good thing. If it isn't an onerous burden on the author, and doesn't as a side effect make the code harder to read (e.g. including the entire function comment block before every call), then indeed why not? A single amphersand is hardly an onerous burden, and provides useful information.
How about including a cast to the true parameter type so that I know the true type of each of the parameters?
If the casts are non-trivial, then this would be good idea. The hidden costs of things like automatic casts creating temporary values are part of why C++ has a reputation for being slow. Making them explicit helps them be found and possibly optimized, eg by doing the cast outside of the loop when possible.
How about adding a little comment for each parameter that gives the name of the parameter local to the function?
This is a very good idea. Positional arguments can be confusing and difficult to remember, especially if you use constants. Something like translateAddress(linearAddress, true, false, true, true) can be maddening to read. Instead, something like translateAddress(linearAddress, true/*generateFaults*/, false/*write*/, true/*read*/, true/*code*/) is vastly more helpful. Python (and other languages) do this one better and don't require positional arguments, you can assign to the parameter name. E.g. optParser.add_option("--wiki", default=False, action="store_true", help="Generate Wiki-friendly table output with '|' between columns"). Nice, eh? In simple cases it isn't needed, in complex cases it keeps you from having to remember the order arguments are required to go in. This can make the code much simpler to read, and prevent you from having to constantly refer to docs/man pages/header files.
Or any number of things that might help our plucky maintainer? Because it's all in the header file.
If it would be helpful and isn't an onerous burden. Making your maintainer refer to the header file unecessarily is a good way to get your name cursed by said maintainer. But I'm a little confused -- on the one hand, you say the maintainer should have to read the header file, but on the other you say that it should be clear that the parameter is passed by reference at the calling point. I'm getting mixed messages.
This is surely a warning against the spirit of the antichrist that has fouled the scientific community since the heathen known as Charles A. Darwin. When you walk away from the path of righteousness, you bring a curse down upon your own house. Those meteor impacts may be the curse that rains down among the people who oppose Intelligent Design in favor of the lie of evolution.
Wait, wait, wait... are you saying that Darwin is still alive, and living on the moon?
Geeze, I need to rember to use preview./smacks self with the clue stick.
Well, I'm not beholden to Bjarne to be the final answer.
Of course you're not, but he does have a good grasp on the language. And he certainly knows why he put something into the language.
I really don't care if the parameter passing mechanism is known at the call point.
Then you don't care about writing maintainable code. That's fine, but having had to frequently maintain and modify code written by others I do care.
If I know what the function does (which is the first thing you *should* know), then I automatically understand how things are passed around.
Do you use expressive variable and function names? Or is your code riddled with X(a) + Y(b) < zz ? After all, the first thing someone should do is look up what X, Y, a, b, and zz are, and then everything will be clear from then on! Or do you helpfully clue people in to what all these things are and what they are for by giving them descriptive names?
You have to look at this from the perspective of someone other than you, the original author of the code. They might be your successor after you leave for greener pastures, or just someone who needs to modify the code without your personal guidance. They probably aren't starting by scrutinizing every function prototype, they're probably trying to understand a particular block of code they care about which calls this function. Yes, they can and should understand what the function does but having the usage of the function implied by it's name, it's parameters, and the way those parameters are used at the calling place makes the code easier to understand, both at initial bring up and when coming back to it in the future.
Pass by pointer makes for easier to understand code and if you care about that is preferrable. If optimizing ease of understanding isn't your goal, that's fine. Not everyone needs to care about that.
When using pointers, the NULL issue is rarely brought up because it's hard to deal with. With references, you don't have this problem (ignoring NULL references since they're hard to obtain in the first place).
void someFunc(int* foo) {
assert(foo);// How is this difficult? This argument is a non-starter.
I really don't care if the parameter passing mechanism is known at the call point.
Then you don't care about writing maintainable code. That's fine, but having had to frequently maintain and modify code written by others I do care.
If I know what the function does (which is the first thing you *should* know), then I automatically understand how things are passed around.
Do you use expressive variable and function names? Or is your code riddled with X(a) + Y(b) When using pointers, the NULL issue is rarely brought up because it's hard to deal with. With references, you don't have this problem (ignoring NULL references since they're hard to obtain in the first place).
void someFunc(int* foo) {
assert(foo);// How is this difficult? This argument is a non-starter.
int foo = 1; int* bar =// a few dozen lines of code here... do_something(foo);// so, is this pass by value or by pointer?
This case is perfectly clear: foo is passed by value. If we can assume do_something(foo) takes an int instead of an int&. I'd have to know that to say for sure, which is exactly the problem with references. I'm not sure that example worked as you wanted. Did you mean to pass bar or something (in which case it would still be clear, bar is passed by value, what bar is pointing to is passed by pointer)?
I strenuously disagree! Passing a parm by reference, rather than pointer, makes it well-nigh impossible for the parm to be null. <snip> No more sanity-checking-for-null at the entry to the routine...
But it doesn't make it nigh impossible for the object to be invalid. Checking for input validity is not something you can skip no matter your passing method. And checking for non null is simple: void pointerPassing(int* foo) {
assert(foo);//...
In point of fact, I find this the single best use of references
If the best use for references is to avoid a one line check at the expense of making the calling code more difficult to understand, then I'd say there's no use for references at all.
since I consider operator overloading something to be avoided in most cases. (Overloading operator* to do matrix multiplication -- sure, fine. Overloading the left-shift operator to do stream I/O.... wtf?)
The rule I use, which I've heard Bjarne himself utter while simultaneously destroying with the stream operators, is that the operator should have an obvious meaning analagous to the built-in operator. E.g. adding strings and complex numbers both have obvious expected meanings. Writing to a stream is nothing like shifting, so yeah. That's why I still use printf().:)
But sometimes operators do make sense (e.g. a 'uint128_t' class that is supposed to provide the same functionality as the uint64_t type) and for that you need references.
Python indentation defines blocks (end of blocks, to be precise). I kind of fail to see how using braces or begin/end construct is "cleaner", especially since you indent languages using braces or blocks keywords by blocks anyway (see, getting rid of keywords/braces is all python does).
Less typing, less misindented code and a lower rate of confusing constructs look cleaner to me.
I can't believe one character (the ending brace) per block is a non-trivial reduction in typing.
Sure properly indented Python code looks nice (though I find the simplicity of a '}' to be fine looking). The problem with Python's cleanliness occurs when you try to edit it. In C, changing blocks is simple because syntatically what is important are the opening/ending braces, so if you get that right you can then hit your auto-indent macro to get nice looking C code. In Python, it is impossible to write an auto-indent for the same reason it's impossible to write an auto-insert-braces macro for C. This means a lot more hand-editing of indentation and the possibility of introducing non-obvious bugs into code that was working fine before.
Don't get me wrong, i like python a lot and don't mind syntactically significant indentation. I just wish they'd left in braces. If you want to require indentation anyway, go ahead, but give me block delimiter characters so that it is simple to programatically determine what the indentation should be.
But I see that you *really* meant *pass* by reference, if you want to ensure that the function can have no side effects, cast the parameter to const. Otherwise, if you expect to write software without knowing what the functions do, you should not be writing software.
That's fine and dandy, but the fact remains that pass by reference makes it more difficult to understand code. There is no syntax at the place the function is called that indicates that it is pass by pointer (which is what pass by reference really is in C++) instead of by value, and this is by no means an insignificant difference. Thus you either have to check the prototypes or possibly miss an important distinction (and have it bite you in the ass later), when using pointer syntax would have made things clear from the get-go.
Bjarne put references into C++ in order to support overloaded operators for complex objects that use the same syntax as operators for basic types. This is pretty much the only reason you should use it (ask Bjarne). In almost every other situation, pointers are equally useful and more clear to someone reading your code and thus preferrable.
Passing references to functions is one of those things that comes from people gleefully trying to use every new feature, like making every member function of a class virtual even though it isn't needed. Thankfully it doesn't tank performance like using virtual everywhere.
P.S. Making a version of an operator/function that works with your object type is called 'overloading'. Making a new version of an operator/function with the same types as an existing one is called 'overriding'. But that's just me being pedantic.
I remember this assinine theory. A couple years ago there was a/. story, one of the precursors of the torrent of shit science we see today, about some "respected" professor who believed that gravity on earth was somehow weaker in the past. I don't recall if he had any theories for why on his website (Did the gravitational constant suddenly change? Did earth's mass increase dramatically? Nothing makes sense), but the real gem was the way in which he inferred this, and even better defended it.
There was some record-breaking power lifter this guy was impressed with. Based on the lifter's best lift and the size of his thighs, he calculated that because of square/cubed laws if you scaled the lifter up to the size of a brachiasaur he wouldn't even be able to stand up. Since this guy is clearly the pinacle of muscular performance, and probably loaded on steroids to boot, there's no way a brachiasaur could do a better job of standing up, thus gravity had to be lower. Clearly.
You may see some fairly obvious holes. Things like... structure. Human knees are designed for jogging, not lifting. The way our tendons go over the joint and attach doesn't provide maximum leverage. It seems unlikely that brachiasaurs were joggers, and their knees reflect that. Now, this guy had heard this criticism before, and felt he had to address it. His response, which I don't recall precisely except for the part in bold, was "Sure, the knee could have provided more leverage but all the leverage in the world won't make a brachiasaur out-perform my favorite power lifter!"
Then I remembered way back in school, hearing about Archimedes who said "Give me a lever long enough and a fulcrum on which to place it, and I shall move the world." Then I just started laughing.
I liked that description, actually. I thought if you're going to claim it creates the "illusion" of having a huge TV, why not take it to the limit? "Its makers say this creates the illusion of watching a 46,200 inch screen from a distance of 1 mile!"
Who wouldn't want the illusion of a 46 thousand inch screen? Seriously I should go into marketing.
Why does our government feel the need to auction off the spectrum?
Selling the spectrum will only accomplish two things: 1) Make some rich companies richer. 2) reduce innovation because only said companies can use the newly availble spectrum.
Right, so what we have is a possible single case scenario, but there is no evidence of when those aminos may have come from (could have been carried from another location)... there are just so many variables, that I can't see how this would be anything but a very weak connection.
Another location? Like... where? Another star? That would still support the theory. It's possible they escaped from the gravity well of a planet in large enough quantities for us to detect from earth. Yet nevertheless we have organic molecules in a star system without planets.
Here's the deal... theories make predictions, and you test those predictions with measured data. The theory predicts that you will find organic molecules in a star system that has yet to form planets. Here we have organic molecules in a star system that has yet to form planets. Thus it supports the theory. Could there be another explanation, a different theory for the same outcome? Of course! Yet other theories say that this would be unexpected, and we have here a theory that says it is expected. Is it possible that there is another explanation for the apparent time dilation we have seen in experiments? Of course, but relativity was the only theory predicting it.
I can appreciate skepticism, but this without a doubt supports the theory that complex organic molecules can precede the formation of planets in a system. Without a doubt you shouldn't treat it as the final word, either, but to say this doesn't mean anything is to take skepticism to illogical levels.
IMO, if he really were a totalitarian, it would have been much simpler for him to support a handpicked tyrant to replace Mr. Hussein in Iraq than to go through the complicated process of setting up three elections in a year and try to corrupt either the electoral process or the results of that process.
It's only simpler if you don't take into account the rest of the world who already find our reasons for going into Iraq dubious -- even the ones who still have troops there with us. Take away "bringing democracy", and what do we have left? Even Bush knows we still need the international community to at least tolerate if not support our unilateral behavior. No, he absolutely must go through the trouble of creating elections.
Of course their choice of appointed prime minister, Ilyad Allawi, former hitman for Saddam Hussein, shows that they were in fact thinking along those lines. Instead it looks like they'll end up with an Iranian-backed theocracy! Hooray!
At this early stage, I'm not willing to belive any particular report about this.
No, that's true, but at the same time if the answer was as simple as "we obtained the warrants as required by law" then I think Bush would have said so and defused the issue immediately. Instead, he is arguing that spying without warrants is legal and necessary. So that speaks pretty strongly to me that it is as the reports suggest: Bush authorized warrantless spying on people within the U.S.
However, the fact that we're even aware about these activities through the media and Mr. Bush has acknowledged at least some of these activities publicly shows that we still live in the freest nation in the world.
One of the most free. Or much more free than many nations. Both are correct, but the U.S. certainly isn't the only nation to have the kinds of freedoms you mention.
However this being true, it is just that much more important for us to protect those freedoms and react aggressively when someone attempts to take them! You don't counter a report that the President is issueing unconstitutional surveilance orders by saying "We are still free because free speech allowed us to discover this" The correct answer is "Thank God our free speech allowed us to discover this so we can crush the fool who thinks our other freedoms are optional!"
It worked 30 years ago when it became clear that Nixon had broken the law (there, the mere threat of impeachment was sufficient). And there's no reason that I can see right now why it wouldn't work now.
Hm, well, it's going to take people actually being upset about it, instead of justifying it or playing it off or saying that we're still the freeest nation in the world no matter what.
I belive that the idea that we're inevitably headed to a totaltiarian state is a load of bunk.
That it is inevitable is bunk, and I agree that we are equipped to deal with it. Yet merely being equipped does nothing to prevent it. We must act. And the alarming thing to me is more the tolerance for totalitarianism that has arisen in the last four years, so long as the words "anti-terrorism" are thrown around first. Of course we would not repeat the incidents of WWII, rounding up all asians. Yet we are content to allow anyone labeled (labeled, not demonstrated to be) "suspected terrorist" to be rounded up. So the question is are we less tolerant of totalitarianism, or has the would-be totalitarians just gotten smarter with regards to psychology?
Personally I think this incident will be something of a litmus test. So far the denials of the Pres have been extremely weak, which leads me to believe that he did in fact step outside constitutional limits. If that is the case, then the reaction will tell us a lot about how resiliant against totalitarianism we really are.
Then again, it might be hard to separate a staunch anti-totalitarian groundswell in Congress from normal political maneuvering in which a weakening leader is ripped apart at the first sign of drawn blood. But I am cynical that way.
Slashdot Mirror
And I could hardly understand how people getting hit in cross-walks related to jay-walking.
It doesn't. This is perfectly normal, though. After 9/11, they started checking IDs at the security checkpoint, even though all the hijakers had legitimate ID and did not use an alias. But it was easier to do that and appear to be tackling the problem than to address the underlying issues of terrorism. Same thing with pedestrian injuries and the university.
The thing that drives me nuts about the perception of SUV safety is that it's based soley on their mass and the head-on collision testing done in the U.S.
Most collisions between cars traveling in opposite directions are not dead-on center like when they crash an SUV against a wall in testing. Most collisions have the cars slightly offset and at a slightly oblique angle. In this case, the greater momentum of the SUV is actually worse as the impact will tend to make the SUV turn, but its momentum will make it want to continue forward. Then the SUV's high center of gravity makes it tumble. This is why safety tests that try to simulate this situation (I think some European safety testing is done this way, where the impact wall is offset from the front of the vehicle) actually put SUVs below most cars in terms of safety, even in a car-SUV collision.
Honestly, from driving an SUV and being able to feel the instability of the car at highway speeds, I can't see how anyone believes they are safer.
To all soccer moms: If you need a safe and practical kid-mover, buy a mini-van. You'll still have the extra mass that makes you feel safe, you'll have a lower center of gravity so you'll actually be safer, and your kids will have an easier time climbing in and out of a vehicle that isn't three feet off the ground.
To all soccer dads: Your SUV is not cool, and will not compensate for your expanding gut and receding hairline. Buy a mini-van and put flame decals on it if you have to have a practical kid-mover and your mid-life-crisis in the same vehicle.
Few people need SUVs for the things they're actually better than mini-vans at: towing capacity and ground clearance. Safety? Not a chance. SUVs are a ridiculous fad that needs to die. When the only ones driving SUVs are the ones who benefit from one, everything will be fine.
We use the same ballot system here in my little corner of Missouri, and I assure you that it's very possible to leave a chad hanging, even with the "approved" punch device that's part of the voting station. No icepick required.
Precisely. It is quite possible to create an invalid ballot. The notion, floated in 2000 with alarming ease, that only poor black people in a Democratic district were unable to produce valid ballots is pure nonsense.
The answer to why there were so many more invalid ballots in those districts is simple. In some districts, the machine was configured to reject an invalid ballot and spit it back out so the voter could fix it -- the behavior one would expect in a sane world. In other districts, the machine was configured to accept the ballot, and then of course not count it because it was invalid.
It was modded insightful because the post he replied to suggested that you should be able to verify your vote is correct once you get home. This is utterly unnacceptable, since it breaks anonymous voting. If you can verify your vote once you leave the polling station, then you can be coerced into verifying your vote for someone else.
As far as being illegal -- all forms of voting fraud are illegal, yet they still occur. All crimes are illegal (duh) yet they still occur. You might not believe this, but a lot of people would be willing to give in to coercion to keep their job, rather than lose their job and have to wait years to prosecute a lawsuit in hopes of getting compensation. Making vote buying or vote coersion possible by breaking anonymous voting is a bad idea.
Anonymous voting is good.
Non-anonymous voting is bad.
That's all; I guess it's only insightful if you didn't know that.
And then there are those of us who actually utilize our brains and realize that if a statement cannot be proven, it is not worth making.
There are many things that are true that cannot be proven. There are many decisions one must make where one cannot prove what the best solution is. There are many things that are simply matters of opinion, which intelligent people can discuss reasonably, realizing you cannot "prove" your position.
Then there are idiots like you, who failed 1st grade "fact or opinion?" exercizes. No, really. This whole thread is little more than a discussion of opinions on coding style and if you think your 'opinion' is 'fact' then you are indeed a retard of the highest order.
That's just my opinion though, lol.
someVector += 5, 6; would be equivalent to someVector.pushBack(5); someVector.pushBack(6);
:P
:)
/. used to be full of cool geeky coding discussions like this one?
I thought from the article that it would have to look like someVector += {5,6}, like it would if 5,6 was intended to be a normal array initializer. That doesn't seem so bad. That is what I would expect array addition to do -- concatenate two arrays.
The main problem with 'vector' and operators as far as I'm concerned is the name. Absolutely terrible name for "better array". While a (math) vector is an array, an array isn't necessarily a vector. I would expect to be able to do a vector dot product with '*', but of course I can't. And then if you want to make a useful mathematical vector class, the name is already taken.
I think pretty much only best way to do it if you want to stick with printf stuff is to make a toString method, and then you can use that as you please.
Yeah, like I said, that's what I do. printf("%s", myObject.toString().c_str()) is the kind of thing you'll see in my code.
I do think the situation is worse with input though. You can't write a "read from this string" function because then how does the code that calls it doesn't know how much to read from the keyboard before it calls it; if it reads too little, the object can't be built, but if it reads too much it's extracted too much from the stream.
Serializing non-POD types from keyboard input is evil.
But yeah, this is more difficult. To solve the problem, the interface would have to do two things: tell the caller how many bytes it read from the string, and second tell it if there were insufficient bytes to create the object. The second you can do either by returning an error code like pre-glibc2 snprintf(), or better by returning how many bytes the function -would- have read if there were enough, like post-glibc2 snprintf(). Returning the number of bytes needed being more difficult if not impossible to implement in every case.
I'm not a big fan of plain-ol text serialization of objects though. If the objects are complex, then the format should be structured (like xml or length encoding) such that the program -can- know how much data is intended for each object.
I had a bit of BASIC experience before moving to C++, and cout is a lot closer to PRINT than printf is (somewhat ironically given the names), so that's my theory as to why I almost always use cout.
*shudder* I have a lot of BASIC experience pre-dating my move to C, which pre-dated my move to C++ by several years. I never made a connection between PRINT and cout, but it could be that my subconscious is rejecting anything related to those long, dark years of GW-BASIC.
Heh. Remember when
I would like to take a time out of this post and say just how wonderful the UndoCloseTab extension is in Firefox
I'll check it out. I use a dvorak keyboard, but have never had that problem (but I tend to be mouse-driven when using a browser anyway).
Interesting, so what does this "foo" function that returns a "MyObject" do?
As an Real Programmer would know, it snafucates the enabalizer.
Shifting is nothing like being incomprably smaller than another number.... but that's what "
Just like calculus means different things to a dentist and a mathematician, the C/C++ programming language is a specific field with its own jargon and the 'obvious meaning' of an overloaded operator should be derived from that. Obviously. Since 1970-ish, << has meant bitwise left-shift in the realm of the C programming language and its derivatives.
Perhaps a better way to put it would have been to say that a programmer should be able to intuit the behavior of an operator based on the behavior of that operator on all other types.
Doesn't work. In normal times, when Child is-a Parent, then Foo(Parent*) can be passed either a Child or Parent and operate on it transparently.
True, if you use virtual functions. If that's the goal, has-a won't work. I still think that if you do want your child class to be used 'transparently' you're going to have to be able to access or change the child classes 'private' members. In many cases, anyway.
Even so, the syntax of printf is nicely more compact, and the speed is not hugely important, so one may wish for a "C++ aware" printf. Such a function could work by adding an additional format specifier (say %P), which indicates that the argument is a pointer to a class derived from PrintfCompatible. PrintfCompatible would have a single pure virtual toString function.
No, I don't wish for that. It's unnecessary. To make my objects 'printf compatible' I give them a function which returns a string, and use %s in printf. Actually it returns a std::string, which is nicer than returning a char* for a lot of reasons.
Thus it looks like this: printf("%s", someObject.toString().c_str())
So reentrancy isn't a problem. Dynamic memory still is. I'm not certain the room for compiler optimization is that large (my off-the cuff guess is avoiding branch mispredicts by avoiding the indirect branch of a case statement is the most help). I'd be interested to compare the performance of cout and printf, with and without non-POD types. For printing to a console or other such, I highly doubt it matters. But for buffered file io or other in-memory operations it may.
But implement your own printf analog, and gcc won't know to check the format string for type information.
If your printf analog uses the same format specifiers as printf, then it can with a gcc-specific directive. In the general case though, yeah, varargs lack type safety.
I've seen advice that addresses this point, and recommends the use of reference parameters for situations in which null is invalid and pointers for when null is valid for this very reason. Sutter and Alexandrescu give this advice for when to pass by pointer and when to pass by reference:
* Prefer passing by (smart) pointer if the argument is optional (so callers can pass null as a "not available" or "don't care" value [the issue discussed above] or if the function stores a copy of the pointer or otherwise manipulates ownership of the argument
* Prefer passing by reference if the argument is required and the function won't store a pointer to it or otherwise affect its ownership.
Hmm, that isn't terrible advice, actually. You don't have to bring up examples of functions that take NULL to mean "don't care", I know of some. time() being the first one that springs to mind, and of course I've written some myself. I would still prefer some syntax that indicates that a value is being passed by reference.
If the input isn't valid, nothing you can legally do will find it.
In the sense that your reference/pointer might be referring to a deallocated (and possibly subsequently re-allocated) object, sure. That feeds into the issue that refrences are not a magical fix for memory management bugs, but that's a digression. I meant in the general sense that one must verify all inputs for logical validity. Indicies must be in the correct range, flags must have understood values, that kind of thing. Most substantial functions I write start with a block of assert() precondition and parameter checks, and checking for a null pointer is just one more. Granted, it is one more.
You just moved to runtime what the compiler could have enforced (as much as anything can be) for you at compile time.
I don't see how that is the case. Obviously there is a runtime check that didn't exist before, but in situations where one could actually get a null pointer I don't see how changing to references fixes it at compile time. I can only see it in the sense that you can't use new() to assign to a reference and then forget to check for null like you can with pointers, but that's just avoiding the functionality, not fixing the problem. I'm missing something, so help me out.
There are other places where references are "necessary" though (for instance the return value of vector::operator[]), so they couldn't be removed from the language entirely even if you didn't allow them in argument lists.
No, no, I didn't mean get rid of references, or even disallow them, I just think the other poster's favorite usage of references is anything but 'best'. For operators references are a necessity. Like operator overloading, I think references are a feature that should be used with care and that many C++ programmers go overboard using these features simply because they are there.
The only C++ feature I think should be removed is the 'private' keyword. It has just never worked out for me that I could derive from a class and override its functions without having an intimate knowledge of how the base class worked. The 'has-a' relationship seems much better if you want to treat the base class like a black box. Personally I think "private" should mean what "protected" does today, and "protected" should be changed to mean that members can be accessed but not modified. This would fix my other pet peeve, having to write swarms of getFoo() functions just to disuade random doinking with the internal state. But I digress into a dreamland...
And I posted another comment about how I don't find even the readability argument in favor of passing by pointers unconvincing.
Yeah, and I agreed with your caveats (especially that all my blather only applies to C++ references).
It's good rule, and one reason why I think that the proposed someVector += 5, 6; syntax is absolutely awful.
Ugh, what's that supposed to mean? Is that something using the sequence constructor?
However, I think that an exception can be made for the shifting operators and input and output partly because of the very long history that they have, and partly because (to my knowledge) the shifting operators were pretty much invented for programming. +, *, etc. all have meanings we've seen since kindergarden or before; << doesn't. It makes sense, but then it also sort of makes sense for stream operations.
Sure, now it has history, but at the time << had a long history of being only the shift operator. I agree that if one were going to pick an operator to make into the stream operator, that was the best one. I wish they had created a new one, like ~~, but I can think of a couple reasons why that could have been undesireable.
(I know this is a war I can't win, but: I think that printf syntax often looks nicer, but it's harder to learn, a lot harder to understand if you don't know it, and isn't typesafe. You also have issues with how you output with classes because you
No, it was clearly neither. If you read the whole sentence, you'd see it was instead irony.
/. post into a step in a formal proof. This is idiocy, not logic.
You're trying to convert every phrase and sub-phrase of a
Your original statement used Bjarne's approval as proof of correctness. That's the false logic that I disagree with. Sure, he has a lot of good ideas. That doesn't mean he's right, not even close.
/. poster. It was not intended to be a logical proof, though I won't fault you for assuming it was. Of course he isn't always right. Except in this case he is right.
/*generateFaults*/, false /*write*/, true /*read*/, true/*code*/) is vastly more helpful. Python (and other languages) do this one better and don't require positional arguments, you can assign to the parameter name. E.g. optParser.add_option("--wiki", default=False, action="store_true", help="Generate Wiki-friendly table output with '|' between columns"). Nice, eh? In simple cases it isn't needed, in complex cases it keeps you from having to remember the order arguments are required to go in. This can make the code much simpler to read, and prevent you from having to constantly refer to docs/man pages/header files.
A lot of people would grant more weight to the opinion of Bjarne Stroustrup, inventor of the C++ language, over Chris Burke, random
Your entire argument logically follows from this statement. However, I don't agree with this statement, so I don't agree with the rest of your argument.
You're backwards. "Pass by pointer makes for easier to understand code" is my conclusion, not the axiom.
Don't be ridiculous. Of course I use descriptive variable names. That's why I don't need to use pointers to pass-by-reference. Because my function names are good.
Okay, maybe your function names are way better than mine, then. I'm trying to imagine how that would work for a non-trivial example. functionThatDoesFooWithParameterNPassedByReference () ? Hungarian notation? Help me out here.
Also, does this mean that you do see the value in making the pass by value/pointer distinction clear at the calling point instead of making them refer to the header file?
Ok, so your logic is that the more information is included at the call point, the better. Ok, then why don't we include all kinds of other information there too.
Yes, with the common sense caveat that there can be too much of a good thing. If it isn't an onerous burden on the author, and doesn't as a side effect make the code harder to read (e.g. including the entire function comment block before every call), then indeed why not? A single amphersand is hardly an onerous burden, and provides useful information.
How about including a cast to the true parameter type so that I know the true type of each of the parameters?
If the casts are non-trivial, then this would be good idea. The hidden costs of things like automatic casts creating temporary values are part of why C++ has a reputation for being slow. Making them explicit helps them be found and possibly optimized, eg by doing the cast outside of the loop when possible.
How about adding a little comment for each parameter that gives the name of the parameter local to the function?
This is a very good idea. Positional arguments can be confusing and difficult to remember, especially if you use constants. Something like translateAddress(linearAddress, true, false, true, true) can be maddening to read. Instead, something like translateAddress(linearAddress, true
Or any number of things that might help our plucky maintainer? Because it's all in the header file.
If it would be helpful and isn't an onerous burden. Making your maintainer refer to the header file unecessarily is a good way to get your name cursed by said maintainer. But I'm a little confused -- on the one hand, you say the maintainer should have to read the header file, but on the other you say that it should be clear that the parameter is passed by reference at the calling point. I'm getting mixed messages.
Beca
This is surely a warning against the spirit of the antichrist that has fouled the scientific community since the heathen known as Charles A. Darwin. When you walk away from the path of righteousness, you bring a curse down upon your own house. Those meteor impacts may be the curse that rains down among the people who oppose Intelligent Design in favor of the lie of evolution.
Wait, wait, wait... are you saying that Darwin is still alive, and living on the moon?
That's awesome!
Geeze, I need to rember to use preview. /smacks self with the clue stick.
// How is this difficult? This argument is a non-starter.
Well, I'm not beholden to Bjarne to be the final answer.
Of course you're not, but he does have a good grasp on the language. And he certainly knows why he put something into the language.
I really don't care if the parameter passing mechanism is known at the call point.
Then you don't care about writing maintainable code. That's fine, but having had to frequently maintain and modify code written by others I do care.
If I know what the function does (which is the first thing you *should* know), then I automatically understand how things are passed around.
Do you use expressive variable and function names? Or is your code riddled with X(a) + Y(b) < zz ? After all, the first thing someone should do is look up what X, Y, a, b, and zz are, and then everything will be clear from then on! Or do you helpfully clue people in to what all these things are and what they are for by giving them descriptive names?
You have to look at this from the perspective of someone other than you, the original author of the code. They might be your successor after you leave for greener pastures, or just someone who needs to modify the code without your personal guidance. They probably aren't starting by scrutinizing every function prototype, they're probably trying to understand a particular block of code they care about which calls this function. Yes, they can and should understand what the function does but having the usage of the function implied by it's name, it's parameters, and the way those parameters are used at the calling place makes the code easier to understand, both at initial bring up and when coming back to it in the future.
Pass by pointer makes for easier to understand code and if you care about that is preferrable. If optimizing ease of understanding isn't your goal, that's fine. Not everyone needs to care about that.
When using pointers, the NULL issue is rarely brought up because it's hard to deal with. With references, you don't have this problem (ignoring NULL references since they're hard to obtain in the first place).
void someFunc(int* foo) {
assert(foo);
I really don't care if the parameter passing mechanism is known at the call point.
// How is this difficult? This argument is a non-starter.
Then you don't care about writing maintainable code. That's fine, but having had to frequently maintain and modify code written by others I do care.
If I know what the function does (which is the first thing you *should* know), then I automatically understand how things are passed around.
Do you use expressive variable and function names? Or is your code riddled with X(a) + Y(b) When using pointers, the NULL issue is rarely brought up because it's hard to deal with. With references, you don't have this problem (ignoring NULL references since they're hard to obtain in the first place).
void someFunc(int* foo) {
assert(foo);
int foo = 1; // a few dozen lines of code here... // so, is this pass by value or by pointer?
//...
:)
int* bar =
do_something(foo);
This case is perfectly clear: foo is passed by value. If we can assume do_something(foo) takes an int instead of an int&. I'd have to know that to say for sure, which is exactly the problem with references.
I'm not sure that example worked as you wanted. Did you mean to pass bar or something (in which case it would still be clear, bar is passed by value, what bar is pointing to is passed by pointer)?
I strenuously disagree! Passing a parm by reference, rather than pointer, makes it well-nigh impossible for the parm to be null. <snip> No more sanity-checking-for-null at the entry to the routine...
But it doesn't make it nigh impossible for the object to be invalid. Checking for input validity is not something you can skip no matter your passing method. And checking for non null is simple:
void pointerPassing(int* foo) {
assert(foo);
In point of fact, I find this the single best use of references
If the best use for references is to avoid a one line check at the expense of making the calling code more difficult to understand, then I'd say there's no use for references at all.
since I consider operator overloading something to be avoided in most cases. (Overloading operator* to do matrix multiplication -- sure, fine. Overloading the left-shift operator to do stream I/O.... wtf?)
The rule I use, which I've heard Bjarne himself utter while simultaneously destroying with the stream operators, is that the operator should have an obvious meaning analagous to the built-in operator. E.g. adding strings and complex numbers both have obvious expected meanings. Writing to a stream is nothing like shifting, so yeah. That's why I still use printf().
But sometimes operators do make sense (e.g. a 'uint128_t' class that is supposed to provide the same functionality as the uint64_t type) and for that you need references.
Python indentation defines blocks (end of blocks, to be precise). I kind of fail to see how using braces or begin/end construct is "cleaner", especially since you indent languages using braces or blocks keywords by blocks anyway (see, getting rid of keywords/braces is all python does).
Less typing, less misindented code and a lower rate of confusing constructs look cleaner to me.
I can't believe one character (the ending brace) per block is a non-trivial reduction in typing.
Sure properly indented Python code looks nice (though I find the simplicity of a '}' to be fine looking). The problem with Python's cleanliness occurs when you try to edit it. In C, changing blocks is simple because syntatically what is important are the opening/ending braces, so if you get that right you can then hit your auto-indent macro to get nice looking C code. In Python, it is impossible to write an auto-indent for the same reason it's impossible to write an auto-insert-braces macro for C. This means a lot more hand-editing of indentation and the possibility of introducing non-obvious bugs into code that was working fine before.
Don't get me wrong, i like python a lot and don't mind syntactically significant indentation. I just wish they'd left in braces. If you want to require indentation anyway, go ahead, but give me block delimiter characters so that it is simple to programatically determine what the indentation should be.
But I see that you *really* meant *pass* by reference, if you want to ensure that the function can have no side effects, cast the parameter to const. Otherwise, if you expect to write software without knowing what the functions do, you should not be writing software.
That's fine and dandy, but the fact remains that pass by reference makes it more difficult to understand code. There is no syntax at the place the function is called that indicates that it is pass by pointer (which is what pass by reference really is in C++) instead of by value, and this is by no means an insignificant difference. Thus you either have to check the prototypes or possibly miss an important distinction (and have it bite you in the ass later), when using pointer syntax would have made things clear from the get-go.
Bjarne put references into C++ in order to support overloaded operators for complex objects that use the same syntax as operators for basic types. This is pretty much the only reason you should use it (ask Bjarne). In almost every other situation, pointers are equally useful and more clear to someone reading your code and thus preferrable.
Passing references to functions is one of those things that comes from people gleefully trying to use every new feature, like making every member function of a class virtual even though it isn't needed. Thankfully it doesn't tank performance like using virtual everywhere.
P.S. Making a version of an operator/function that works with your object type is called 'overloading'. Making a new version of an operator/function with the same types as an existing one is called 'overriding'. But that's just me being pedantic.
I remember this assinine theory. A couple years ago there was a /. story, one of the precursors of the torrent of shit science we see today, about some "respected" professor who believed that gravity on earth was somehow weaker in the past. I don't recall if he had any theories for why on his website (Did the gravitational constant suddenly change? Did earth's mass increase dramatically? Nothing makes sense), but the real gem was the way in which he inferred this, and even better defended it.
There was some record-breaking power lifter this guy was impressed with. Based on the lifter's best lift and the size of his thighs, he calculated that because of square/cubed laws if you scaled the lifter up to the size of a brachiasaur he wouldn't even be able to stand up. Since this guy is clearly the pinacle of muscular performance, and probably loaded on steroids to boot, there's no way a brachiasaur could do a better job of standing up, thus gravity had to be lower. Clearly.
You may see some fairly obvious holes. Things like... structure. Human knees are designed for jogging, not lifting. The way our tendons go over the joint and attach doesn't provide maximum leverage. It seems unlikely that brachiasaurs were joggers, and their knees reflect that. Now, this guy had heard this criticism before, and felt he had to address it. His response, which I don't recall precisely except for the part in bold, was "Sure, the knee could have provided more leverage but all the leverage in the world won't make a brachiasaur out-perform my favorite power lifter!"
Then I remembered way back in school, hearing about Archimedes who said "Give me a lever long enough and a fulcrum on which to place it, and I shall move the world." Then I just started laughing.
I liked that description, actually. I thought if you're going to claim it creates the "illusion" of having a huge TV, why not take it to the limit? "Its makers say this creates the illusion of watching a 46,200 inch screen from a distance of 1 mile!"
Who wouldn't want the illusion of a 46 thousand inch screen? Seriously I should go into marketing.
Why does our government feel the need to auction off the spectrum?
Selling the spectrum will only accomplish two things: 1) Make some rich companies richer. 2) reduce innovation because only said companies can use the newly availble spectrum.
Question, meet Answer.
Right, so what we have is a possible single case scenario, but there is no evidence of when those aminos may have come from (could have been carried from another location) ... there are just so many variables, that I can't see how this would be anything but a very weak connection.
Another location? Like... where? Another star? That would still support the theory. It's possible they escaped from the gravity well of a planet in large enough quantities for us to detect from earth. Yet nevertheless we have organic molecules in a star system without planets.
Here's the deal... theories make predictions, and you test those predictions with measured data. The theory predicts that you will find organic molecules in a star system that has yet to form planets. Here we have organic molecules in a star system that has yet to form planets. Thus it supports the theory. Could there be another explanation, a different theory for the same outcome? Of course! Yet other theories say that this would be unexpected, and we have here a theory that says it is expected. Is it possible that there is another explanation for the apparent time dilation we have seen in experiments? Of course, but relativity was the only theory predicting it.
I can appreciate skepticism, but this without a doubt supports the theory that complex organic molecules can precede the formation of planets in a system. Without a doubt you shouldn't treat it as the final word, either, but to say this doesn't mean anything is to take skepticism to illogical levels.
Not for long, they won't be...
IMO, if he really were a totalitarian, it would have been much simpler for him to support a handpicked tyrant to replace Mr. Hussein in Iraq than to go through the complicated process of setting up three elections in a year and try to corrupt either the electoral process or the results of that process.
It's only simpler if you don't take into account the rest of the world who already find our reasons for going into Iraq dubious -- even the ones who still have troops there with us. Take away "bringing democracy", and what do we have left? Even Bush knows we still need the international community to at least tolerate if not support our unilateral behavior. No, he absolutely must go through the trouble of creating elections.
Of course their choice of appointed prime minister, Ilyad Allawi, former hitman for Saddam Hussein, shows that they were in fact thinking along those lines. Instead it looks like they'll end up with an Iranian-backed theocracy! Hooray!
At this early stage, I'm not willing to belive any particular report about this.
No, that's true, but at the same time if the answer was as simple as "we obtained the warrants as required by law" then I think Bush would have said so and defused the issue immediately. Instead, he is arguing that spying without warrants is legal and necessary. So that speaks pretty strongly to me that it is as the reports suggest: Bush authorized warrantless spying on people within the U.S.
However, the fact that we're even aware about these activities through the media and Mr. Bush has acknowledged at least some of these activities publicly shows that we still live in the freest nation in the world.
One of the most free. Or much more free than many nations. Both are correct, but the U.S. certainly isn't the only nation to have the kinds of freedoms you mention.
However this being true, it is just that much more important for us to protect those freedoms and react aggressively when someone attempts to take them! You don't counter a report that the President is issueing unconstitutional surveilance orders by saying "We are still free because free speech allowed us to discover this" The correct answer is "Thank God our free speech allowed us to discover this so we can crush the fool who thinks our other freedoms are optional!"
It worked 30 years ago when it became clear that Nixon had broken the law (there, the mere threat of impeachment was sufficient). And there's no reason that I can see right now why it wouldn't work now.
Hm, well, it's going to take people actually being upset about it, instead of justifying it or playing it off or saying that we're still the freeest nation in the world no matter what.
I belive that the idea that we're inevitably headed to a totaltiarian state is a load of bunk.
That it is inevitable is bunk, and I agree that we are equipped to deal with it. Yet merely being equipped does nothing to prevent it. We must act. And the alarming thing to me is more the tolerance for totalitarianism that has arisen in the last four years, so long as the words "anti-terrorism" are thrown around first. Of course we would not repeat the incidents of WWII, rounding up all asians. Yet we are content to allow anyone labeled (labeled, not demonstrated to be) "suspected terrorist" to be rounded up. So the question is are we less tolerant of totalitarianism, or has the would-be totalitarians just gotten smarter with regards to psychology?
Personally I think this incident will be something of a litmus test. So far the denials of the Pres have been extremely weak, which leads me to believe that he did in fact step outside constitutional limits. If that is the case, then the reaction will tell us a lot about how resiliant against totalitarianism we really are.
Then again, it might be hard to separate a staunch anti-totalitarian groundswell in Congress from normal political maneuvering in which a weakening leader is ripped apart at the first sign of drawn blood. But I am cynical that way.