you are instructed to pretend that the pointer isn't a pointer, it's an "abstract link". If I tell you to pretend that an integer is a grapefruit it doesn't make it one.
Ta Da!
Broken computer science students everywhere applaud you for concisely showing why Java is a bad language for learning computer concepts.
Everything else you say is crap. The Java vm has a garbage collector. If I want a garbage collector in C or C++ I can link it in (see libgc etc). The fact that I then don't have to worry about freeing my memory doesn't then magically convert my pointers to something else. they are still pointers.
You overstate your understanding of my point. _PLENTY_ of languages have had pointers with feature-impoverished sets of operations. (See COBOL for examples) but you know what? The lack of interesting operators on a type doesn't change the nature of the type.
They are pointers no matter how deeply you cram your fingers into your ears and no matter how loudly you shout and stamp your feet.
P.S. Learn to READ. I didn't call "not having to type an extra character" a "fundamental characteristic of references"... I called it "syntactic sugar". The only feature of a reference that makes it a reference is immutability, and we have already demonstrated that you can re-point your pointers in Java via the assignment operator. (Getting out the crayola) See I took where you were trying to invent all these differences between pointers in C++ and references in C++ and boiled it down to two facts. First (labeled with a little "1") was immutability, and then second (labeled with a little "2") was the syntactic sugar. I made no statements about "fundamental characteristics of references" because "references" are "pointers" because, in truth, and as stated, references are, first and foremost, pointers.
Answer me this: What is the difference between a duck and a Mallard?
One is a general kind of thing and the second is a more specialized version of that thing. So references are pointers because, well, references are pointers. They are the same damn thing. period.
Now take a lollipop out of petty cash and STFU you clueless noob.
I frequent bars. I don't drink. It's not that I _never_ drink, but if I were to divide the number of "drinks" I have ever had in public by the number of times I have been in a bar, the number would be non-zero but significantly less than one.
So the very fact that people think of this as a "drinking record" long before it is even a prevalent thing is disturbing in the extreme.
The dataset so generated is replete with "inferred fact" that is, in fact, not fact. (to alliterate nearly unto death 8-)
This is serious, and not just for the tinfoil hat crowd. The courts certianly accept data that "smells like evidence" as actual evidence with no information theory to back it up. See the copyright nonsense. See the very low bar that has been set to determine "intent to sell" especially with respect to LSD where the gross weight of drug and delivery method divided by the microgram weight of the dose, turns a guy with 6 hist of acid in his pocket into a "major distributor". (no really, look that one up.)
So these jet-fuel geniuses in court, and in your hr office, and your local child welfare office will be inferring alcoholism from barfly status.
Well, you either like booze too much, or pool too much, or talking to people too much, and since we suck at pool, and we are boring, you must be a drunk.
In C++ a reference is a pointer with two additional traits:
1) The value of the pointer cannot be changed after initialization; that is, it is "immutable".
and
2) Since the value is properly immutable by virtue of item 1, the language provides the "syntactic sugar" of relieving the programmer of the chore of explicit dereferencing (using the "*" operator) on use or using the address-of ("&") operator on construction.
ASIDE: As a consequence of 2, the uninitiated may be confused by the use of the address-of (&) operator on references to regain the raw address of the referenced object. This operation is, however, inevitable in this form since [reference_name] is the same as [*pointer_name] &[reference_name] is the same as &[*pointer_name] so the auto dereference is preserved in exact semantics. This leads, for the purposes of semetry, to the auto-address-of operation takes place when a formal function call argument is initialized "by reference" since G(T&x){} F(T&x){ G(x) } {T thing; F(thing);} would be asymmetric for the calls of F and G if I had to take the address of thing, but nof of F::x etc.
Since Java _does_ let you change the value of the pointer using the assignment (e.g. "=") operator, it is not immutable and it fails to qualify in item one.
Similarly equality (e.g. operator "==") in Java compares the addresses of the two operands, which tests whether the two pointers point to the same object, as opposed to the equals() method which, when present, compares semantic equality of the contents of the object so pointed to. In c++ "[reference_name] == [reference_name]" is actually "[*pointer_name] == [*pointer_name]" whereas in Java it is "[pointer_name] == [pointer_name]".
So given that there are three possible metrics to determine if Java "object references" are "more like" "pointers" or proper "references" analysis reveals that at two-to-one out of a field of exactly three discriminants (counting the gross appearance provided by the "sugar" just to be nice to you here and spare you utter humiliation), they most closely resemble pointers. Losing the test of distinctiveness two-to-one cannot, by any measure mean the defeated proposition is "*Much* more" victorious, no matter how much punctuation you add.
Sorry about that guy, but you are completely utterly and inarguably wrong. You really _should_ just take the hit and move on with your life.
But were I to cede you the "they are like C++ references" out of the pure kindness of my heart, you would then have just proved my initial contention, that Java only has pointers, because remember, C++ references are pointers with syntatic sugar on them.
So, more simply said, you have agreed that Java uses pointers with sugar coating.
I already and initially said that those pointers are lame because you cannot do interesting pointer maths on them (a la pointer_name++ etc). This is, again, not "immutability" because that word doesn't mean what you think it means.
Immutable: Not mutable; not capable or susceptible of change; unchangeable; unalterable.
So it doesn't matter what _you_ mean by immutable. I can do "thing=null;" or "thing=other_thing;" which changes thing, so thing was and is mutable no matter what you care to think. And _again_ that makes it a pointer. You are arguing that they are reference because since they are such lame pointers they must not be pointers at all (or something equally dense and pointless, if you will excuse the pun).
In super-super-simple terms that even a Java bean can understand: You are _insisting_ that "it isn't a vehicle its a car!" when you insist "it isn't a pointer its a reference" since references are _specializations_ of pointers with most of the methods hidden. (Was that clearer son or do I have to get out crayons and crate paper?)
And now you should understand why I "laugh a little" when people _insist_ that there are no pointers in Java. It's like arguing that there is no water in the ocean because p
Yes. Crappy programmers can easily make crappy code where the smart pointers are reduntantly used raw.
So what? Java has jini that can call a library that _could_ damage the reference counting built into the java language because it, by definition, passes raw references about. All the same caveats apply. The JINI user could invalidate a pointer and leave you pointing at anything etc...
Meanwhile I _can_ craft a class where all of what you mention is so difficult as to approach impossibility to such a degree that mendacity is the only route to harm.
No language can prevent the actions of a programmer with evil in his heart.
Meanwhile its not that you "need to" destroy immediately on the drop of the last reference, its that the _ability_ to _know_ that you destroy immediately on the drop of the last reference _allows_ for "proper closure" over the core predicates of being "object oriented" _AND_ simultaneously be able to code precisely against your object invariants because you have the certainty of their lifetime.
Duh? you ask...
Lets say I read a file into memory on creation of an object, and I want to let write operations happen on that memory cache, and then I want to flush the cache to storage and close on destruction. That maps the state of the file to the lifetime of the object.
In C++ the destructor is the place to do the close, and for as long as the object exists, operating on the object is valid within that invariant.
In Java I _cannot_ use finalize to do this write-and-flush because I could make such an object, write to it, drop the reference, make another one, write to that and drop that reference and be left with _no_ _clue_ as to which cache set will end up written last.
If I provide my own "force close" method, anybody could call that method and then any operations on the file object after that force close would be erroneous. And so, sure, I could then throw a specialized exception that said "someone invalidated this object" but now I have had to add _two_ levels of complexity to properly represent a closure over an object that is "either an opened file, or not, maybe". Yay, another win.
The downside in C++ is that I have to take _responsibility_ for making sure that object lifetime is managed if the object is on the heap. (On the stack it is automagical). So that cost is a wee bit of diligence. A diligence I can encourage and all but enforce to the nth degree.
Is C++ "idiot proof"? oh hell no.
Lets face it. There are things that you just cannot do in Java. One of those things is trash your memory map. The other is to make sure that your objects are valid from construction to destruction... because there _is_ not destruction to be had. The first is a danger. The second is required for "semantic correctness" over the whole of the object oriented paradigm. Danger of the former is worth the simplicity and elegance you can create with the second.
Just as losing my car in a parking lot, or a bet, doesn't cause my car to explode into its constituent pieces and resume their life as raw materials...
losing the last reference to memory isn't destruction.
So your first point which talks about "the memory being available" is immaterial, and a tad vague.
Meanwhile...
Custom end of life routines _do_ automatically occur in C++ as long as the object reaches an end of life condition. Leaking an object doesn't imply end of life in C++ (though it is the only way to reach end-of-life in Java), it indicates a serious semantic error in the code.
So where end of life is managed (or not boned up by a bad programmer), which in C++ is automatic for automatic variables, automatic for reference-counted pointers to heap objects, and manual for manually managed objects (manual management being the default heap lifetime model in C++), end of life calls happen _precisely_ at end of life. So there you go. I did explicitly mention that for full heap-based automation you have to add pointer reference management.
Also, I made the point that "waiting for the garbage collector" to notice the object needed to be finalized was not the same thing as having a _predictable_ point of destruction at a _predictable_ end of life. (though I must have used less-clear wording.)
Consider a specific example. I have an object that represents a cache of the image of an open file. It has one reference on the stack and that reference is passed into various methods as well. An exception is thrown and all of the referencing pointers on the stack are unwound. Now I fix the problem and reenter the code, where I make a second cache object and call the hierarchy of functions which runs to completion.
In C++ (with proper lifetime management via automatics and reference counted pointers as necessary) the first cached region on the file was taken _COMPLETELY_ out of play by the exception. The destructor, with absolute certainty, has flushed the cache and closed the file during the exception, and so the open read and cache update and close cycle of the second, successful pass can take place in absolute safety and with proper closure and no uncertainty what so ever.
In Java I potentially have two separate caches that _think_ they have authoritative knowledge of what the file _ought_ to contain, and when "finalize" comes around to flush and close the file I could end up with _either_ set of data in the file or, worse, some combination of both.
So in Java I (the programmer) _MUST_ add a manual end-of-lifetime call that YOU-or-I (the user) _must_ call in every possible logical branch out of the code. {hence "finally" clauses etc added into the language.} The problem is, _requiring_ this _extra_ call to the object violates the whole concept of objective encapsulation as you _must_ end up with an "object is no longer a file" _OR_ an uncertain object validity that, by definition, extends to some uncertain time in the future (possibly "never" if the program ends).
Now yes, in C++, a "bad" programmer may leave trash on the heap at exit and violate his the fundamental lifetime of an object, but in both languages a bad programmer _could_ do damage in any number of places.
Okay? Java doesn't have destructors. It has "finalize" which has no _predictable_ semantic over the domain of time. And you can _add_ a method to do anything, including and especially, to invalidate an object that will still exist, leaving you with an invalid object {look up "invariants" to understand what I mean by "invalid" here} in scope. This is _not_ better.
Actually, since class definitions are bound in C++, the two base classes inherited into the new class, can not, by any definition or possibility, interfere with one another. Java uses "signatures" and so, the classes could possibly be so harmfully interjoined.
So your concern about the "dangers" of multiple inheritance and semantic cross contamination are based on a false dichotomy. They are predicated on the implementation of a particular language, but not on language theory. So when I say "language X has missing feature Y" it is false dichotomy to argue that "feature Y is essentially flawed" based solely on the reasoning that "since it would be dangerous in language X" it must be a mis-feature wherever it is found.
See in a language like Java, where "signatures" are searched for in a purely derived-to-base class order, a call in an ancestor could, in the presence of multiple inheritance, cause an implementation in one class to cross-invoke a method from another ancestor.
In a bound language, where symbols are bound at compile time to the symbols available in fixed scope visibility (like C++), the symbols are bound to either explicit entry points or vtable offsets, that is to known symbolic quantities, there is _NO_ possibility of _accidental_ cross-tree calling. That means that the danger you claim wouldn't be possible.
The difference is inherent in the difference between the languages, where in java everything is overridable unless it is "final" where as in C++ nothing is overridable unless it is "volatile".
This actually points out _another_ weakness of Java. At any point in a C++ class one cannot "forget" to finalize and have a descendant bone a stable class. In Java you have to remember to lock every door, or it is opened. In C++ you have to explicitly unlock a door to let your descendants participate in your paradigm.
Or, to fold it the other way:
In C++ you _can_ create an interface class with no default implementation at all, or you _can_ provide a default implementation. In Java you cant provide a default implementation. If Java let you provide an implementation for an interface, that interface could _bone_ your class hrearchy because of signature search order. Since every implementer of an interface in Java must recreate predominantly identical code, the empty interface is more likely to induce mistakes born of repetition. Lucky you.
In short, your entire argument is bunk _outside_ of Java. Indeed Java "invented" the problem you claim they solved by making interfaces only workable as empty lists of functions, because they cannot multiply inherit code because they can only find functions by signature and to classes could implement distinct functions with the same signature....
Your position is logically circular... With a through understanding of both C++ and Java (and compiler theory and symbol resolution etc) your position reads to me as: "nuh uh, they did it right, because they did what they had to do, because they did it wrong."
This, of course, is another support of the fact that Java breaks young programmers understanding of important and subtle concepts. You have been mentally infected with some sort of late-binding meme that you think is universal to languages instead of being restricted to, well, Java...
What does "finally" as a scope in a method have to do with destructors?
I am not talking about static scopes in code, I am talking about directly mapping object lifetime to resource durration.
Sure, anybody can write code to explicitly end a resource state, but the idea of object lifetime is unclosed over the domains of both time and accessibility.
There are things "like" predictable lifetime and accurate destruction that "can be made" in any language "more or less" but that is far different than actually having a proved language feature doing that exact thing.
Once you understand reliable object lifetime, and particularly spesific context destruction, "sort of like it" is a PITA compared to actually having it.
Now, C++ isn't a panacea either. But I can _add_ the missing reference counted pointers to C++, but I _cannot_ add destroy _immediately_ while dropping last reference to Java.
Its the combination of the two that makes some truely sublime implementations possible.
So C++ distructors combined with something like boost.org 's shared and weak pointers produces a perfect storm of functionality over both the domains of time and scope.
The simple truth is that kit-like languages can build up to any primitive or feature rich state, but "feature safe" or "feature complete" languages cannot be "cut down" to primitives.
=== MEANWHILE ===
Nobody in the learning stage should ever be tossed in to "sink or swim". The fact that it may be harder to drown in Java doesn't excuse any school for trying to teach by sink or swim. That's not a way to teach a thing to anybody.
Thing & thing1 = new Thing;// make some thing Thing & thing2 = new Thing;// make some other thing thing2 = thing1;// still have two separate things, but the original value of "some other thing" is obliterated by the value of "some thing"
It was provided for congruency of example not correctness of text. A more useful construct would have been something like
I even _warned_ you not respond on the subject of destructors...
YOU: And here I thought Java had no destructors because you had a garbage collector. There's an easy way to "destruct" an object in Java:
YOU: myThingy = null;
The above is so wrong on so many levels it threatens to induce apoplexy... 8-)
At the end of the instruction above, nothing has been destructed at all. The object has lost visibility in this scope. Once the compiler notices that the object has no visibility anywhere it will schedule finalization, which may or may not ever take place. Finalization does not necessarily occur if the program exits before the garbage collector sees and finalizes the object.
So yes, you don't understand destructors. Having never really _needed_ one, you have never really understood what it is to _know_ and be able to _rely_ on the timely entry into a method/callback at the end-of-lifetime of an object. Oddly enough, if you have ever done any Java programming of a GUI etc, and so been exposed to "window destruction notifications" you _OUGHT_ to know why destructors are important. But clearly you have not learned to generalize your knowledge.
And amusingly enough, you _AGAIN_ demonstrate that Java only has pointers by having the "alleged reference" mutate from pointing to an object to pointing to "no object" which is something that a proper reference, being immutable over the course of its lifetime, would not be able to do...
That word. "Mutability". I don't think it means what you think it means. -- (with apologies to The Princess Bride 8-)
ME: The field of computer science has not yet come up with a "basic theory"... a starting place...
YOU: There are decent basic theories: Universal Turing machines, state machines, boolean algebra, lambda calculus, resolution with horne clauses, etc.
Q.E.D. You will notice that you present a bunch of basic theories (as in simple ideas" but not "a basic theory... a staring place... {redacted significant point, paraphrasing myself} the set of things a student must know before you begin filling their head with syntax". The _SINGULARITY_ of that absence-bemoaned starting place is the point.
We have a glut of starting places, none common, and most intransitive to one another and most, as you point out, "not taught in first year CS for good reason."
See then that these [more properly "core"] theories serve no purpose as a foundation to install at time T0 at the biginning of the first year of a CS education. We still have no "[single] basic theory..." we just play sink-or-swim with our students till they "figure enough out on their own" so that we can expose _then_ expose them to core theories.
Consider instead, science...
Science has a basic theory. It consists of all the parts of "the scientific method". First we teach observation. Then we teach measurement. Then we teach hypothesis. Then we teach invalidation of hypothesis. Then we teach recoverable analysis as a way to refine the remainders of refuted hypothesis into new stronger hypothesis. Thus do we make a student learn "science" before we expect a student to execute "science" on his own.
In "computer science" we make the student execute a bunch of code, then we force them to mimic a bunch of code, then we try to get them to invent a bunch of code based on the code they have previously mimicked or executed. All in the hopes that they will suddenly or eventually intuit what we mean by "programming".
It's like cramming a bunch of grammar rules and structures down a student's throat and expecting them to "figure out" what a verb is and how it is different from a noun or adjective.
We have no "parts of speech" for computer science. We have no observation and measurement before hypothesis structure to the way we teach algorithmic thought.
We are a bunch of monkeys hoping the younger monkeys will eventually figure out why we poke our particular blades of grass into the particular holes we choose.
The way we teach programming is the worst combination of oral tradition and tribal knowledge, and then we act surprised when the results make no sense but do generate heated invective.
ME: Every time someone tells me that there are no pointers in Java I laugh a little.
YOU: They would be correct. Java contains references, not pointers. The distinction is obvious to anyone who understands C++ as it has both (& for references, * for pointers). Pointers are mutable, references are not. This makes references (somewhat) safer to use and also allows a garbage collector. It also means it has a lot less functionality (particularly as an iterator).
Sorry, they are not references, they are pointers. They _call_ them references in the documentation, but what happens when you use "=" on a reference, you replace the contents of the item referenced. In java, when you use "=" the pointer-miscalled-reference takes on the address of the right-hand-side as a second means of access to that now-shared object.
to whit, in java:
Thing thing1 = new Thing;// make some thing Thing thing2 = new Thing;// make some other thing thing2 = thing1;// lose "some other thing", now have two pointers to "some thing"
so yes, "pointer are mutable and references are not" and here the pointer itself "thing2" is mutated by the assignment where a reference would not be. The fact that the object originally pointed to by thing2 is unchanged is a question of object mutability, not pointer mutability. But thank you for demonstrating to the audience that learning Java harms your ability to understand and deal with the concept of a pointer. You have served as an admirable example of what the article was trying to say. Bravo!
But to continue, for those who still do not get it...
This is the same (ignoring the memory leak) as the identical code in C++ using pointers:
Thing * thing1 = new Thing;// make some thing Thing * thing2 = new Thing;// make some other thing thing2 = thing1;// lose "some other thing", now have two pointers to "some thing"
But when _references_ are used things are different. (note that for the reference one to work correctly the anonymous objects would need to be const or some such, e.g. the language resists letting you code this mistake directly etc)
Thing & thing1 = new Thing;// make some thing Thing & thing2 = new Thing;// make some other thing thing2 = thing1;// still have two separate things, but the original value of "some other thing" is obliterated by the value of "some thing"
So anyway, java... just has pointers... no references... no mater what they choose to call them.... They are "reference counted pointers" but not properly references. The "just references" semantic is a lie, and one you have fallen for. And so, I laugh a little.
As for your other questions and observations, I wasn't writing a technical treatise on Java, but even so:
Why would I want to pass a the contents of a non scalar by value? Why to have a private copy of the structure to work with you silly boy. Kind of the definition of "why copy" anything.
The pedant will point out that Java "only passes by value" where the "value" is the address stored in the pointer, or the bit pattern stored in the scalar. Semantically, however, since the language struggles so desperately to make you think of the pointer as the object, it is everything we expect as technical professionals, in every detail, when we say "Java does not pass [non scalars] by value". Meanwhile, the language makes us create an entire object to entomb a simple scalar if we want to pass _that_ by reference. I am sure you don't know why I might want to do that either. Right tool for the job my boy. In a "real language" (to use the pejorative 8-)pass by value cheaper for scalars, more expensive for aggregates; pass by reference cheaper for aggregates, marginally more expensive for scalars (especially when optimization is considered) but both techniques have their uses and misuses.
I you make everyone special, nobody is really special.
Every time someone tells me that there are no pointers in Java I laugh a little. EVERYTHING in java that isn't a scalar is actually referenced through pointers. That is, you declare the pointer variable and then "new" the object into place.
They are just incredibly _boring_ pointers. You cannot math on them. There is no sense of location to those pointers. But the absence of interesting pointer operations, and the absence of the _semantic_ _copy_ operation is what all this alleged pointerlessness is all about.
I have only two _Real_ problems with java... (okay three if you count the complete requirement that you constantly have to deal with exceptions even when you know they cannot really happen, and if they did, you would want the thing to abort all over the place... but I digress)
(1) Java has no useful destructors because no object has predictable scope. If you think finalize methods are the same as destructors then don't bother responding, you don't know what destructors are...
(2) Since everything is a pointer in Java, you have to bend over backwards to pass-by-value. The fact that the language doesn't even begin to provide copy-construction semantics. What a miserable PITA.
Now the _dumbest_ thing about java is that they were so set against multiple inheritance that they never bothered to ask themselves why _every_ OO language starts out life without multiple inheritance only to have to add it later. By making everything a proper linear subclass of Object, they left themselves with having to graft on "interfaces" which is just multiple inheritance with the "bonus" of completely preventing default implementations. (Which lead to delegation etc.)
The way the language keeps sprouting things it claims to never have and never need, well it's very like watching a clown car endlessly explode with ridiculous archetypes. After a while it just isn't funny any more.
So yea, teaching people Java as an introductory language is something of a disservice if you ever want to make them truly think about programming and what makes some things machine smart, while others are machine stupid.
--- BUT ---
I worked in education for years. The fundamental problem with computer science education is that it is being taught by computer scientists instead of educators. We are stuck learning from the people who learned from the people who made it up. None of these people ever learned to EFFECTIVELY IMPART INFORMATION.
Consequently, the students are largely unemployable on the day of graduation.
The classic computer curricula seems to consist of throwing three or four languages at a kid in the hopes that they will "just kind of figure out this programming stuff."
The field of computer science has not yet come up with a "basic theory"... a starting place... The list of things a student simply must know before you start filling their head with syntax.
And so we are a bunch of prelates training our acolytes in our special, individualized deeper mysteries.
And that's what everybody is doing worldwide, so our graduates are just as lame as everyone else's...
Science isn't am entity, "it" cannot guess. It cannot "LEAD to" anything anywhere. Just because you feel comfortable anthropomorphizing the entire universe, doesn't make it so. Just because you feel that need to be lead by an all-powerful it, doesn't for the tiniest moment endow science with entity or purpose.
You really just dont' get it at all do you?
"People of faith" demand that science provide "proof" that they themselves cannot supply about their faith.
"People of science" would like "people of faith" to shut the fuck up, not in general, but specifically about their attempts to misuse the trappings of science to validate their positions of faith.
Science doesn't lead, and the pursuit of science can only go two ways. Honestly forward into what is, or horribly astray by what people demand to see. The pursuit of science, diligently and precisely exercised by persons of honest endeavor, does reveal fact. But it only does so only asymptotically. Ever closer, but never complete. And then, armed with the best available approximation of fact, we hope men of conscience will lead.
Be as faithful as you want to your choice of deities, but you won't win the scientifically minded over until you try to rigorously examine that faith with an eye to trying to disprove it. When you honestly assail that attempt at disproof, and fail to disprove it, then you will earn the right to call your position validated in a scientific sense.
Meanwhile, the classification of things scientific is _solely_ and _wholly_ dependent on the method of ascertainment. Asserting any atom of knowledge, even if you assert it to have been gained "scientifically", it isnt necessarily so unless the science behind it was sound.
You say "semantic" as if semantics are invalid. As if the lowest thing is semantic differences. But each distinction in all things is semantic before it is systematic. Reality is the infinite sum of the infinitesimal pieces. The distinction between "the best, most rigorous guess we can make" and something with the "ring of truthiness" (credit to mister Colbert for that word) is that the former is ground fine under the wheels of doubt and reason, while the later is simply pronounced with an air of certitude.
All of life is vocabulary, and all of understanding is semantics, at least all of the all that can be shared between people effectively. Even your faith, and your wars of faith, dance semantically with angels on pinheads.
I'll give you "science" not being a verb. I'll point you to the definitions of the noun "science" and the adjective "scientific" as its close antecedent. But then I must paste the annotation from that very noun:
Note: Science is applied or pure. Applied science is a
knowledge of facts, events, or phenomena, as explained,
accounted for, or produced, by means of powers, causes,
or laws. Pure science is the knowledge of these powers,
causes, or laws, considered apart, or as pure from all
applications. Both these terms have a similar and
special signification when applied to the science of
quantity; as, the applied and pure mathematics. Exact
science is knowledge so systematized that prediction
and verification, by measurement, experiment,
observation, etc., are possible. The mathematical and
physical
They bible is not a myth. The bible is a fact, in that I can go out and get one and possess it and demonstrate its factual reality by, say, reading it, or using it to prop up one corner of a tippy sofa...
The bible is not a myth, it _presents_ a _mythos_. That is, it presents a _set_ of many interlocking or interdependent myths.
Please use more correct English when deriding the belief systems of others, else you'll make all us technical realists look bad...
You had me till your third paragraph, whereupon you instantly got reclassified as an oratorical goon. (no offense. 8-)
"Science" is a "provable fact", and is even a "proven fact" because it is a _technique_ or _approach_, and so its existence and its practice is a fact. If you want to say "science has yet to ever be proven as a fact" you must be willing and ready to replace "science" with "reading" or "throwing a ball". That is you would have to be ready to say "reading has yet to ever be proven as fact" but you are reading and people do read, so reading is a fact.
Now not every person reads well, nor effectively, but the action of reading is factual.
Now not every person throws a ball well, nor effectively, but the action of throwing a ball is factual.
Now not every person [practices or performs] science well, nor effectively, but the action of [practicing or performing] science is factual. [ASIDE: read is to reading as science is to "sicencing"? In the absence of an active tense for the word "science" I prefaced practicing or performing. It is left as an exercise to the reader to assess whether this damages the symmetry of the argument. 8-)]
From there on you systematically demonstrate a fundamental misunderstanding of the scientific method, or at least a profound inability to express what you believe you understand about it.
The super-short super-simplified version is this: In Science you make observations, from those observations you make a guess (hypothesis), indeed the _best_ _guess_ you _can_, and you then construct a test or suit of tests that would invalidate that hypothesis. Then you contrive to execute that test, in the hopes that your test will fail to invalidate that hypothesis, and you observe the results. You use those observations to construct a better hypothesis and another set of tests. Lather Rinse Repeat. Once you have a hypothesis that you cannot refute, you promote your hypothesis to a thesis (in your mind, and a "candidate thesis to others) or in short "a theory", and present it to the world, along with your test methodology and results. Those others consider your thesis as a hypothesis of their own, and both act to verify your test results and also attempt to come up with their own test sets that would validate re-validate the hypothesis to themselves before accepting your thesis as their own.
Really consider the words.
"Hypo-" A prefix signifying a less quantity, or a low state or degree, of that denoted by the word with which it is joined, or position under or beneath. "Thesis" A position or proposition which a person advances and offers to maintain, or which is actually maintained by argument. "hypothesis" a proposal intended to explain certain facts or observations.
In the technique we call "the scientific method" or just plain "science" nothing is _EVER_ proved, but many things are frequently _DISPROVED_.
The [egregious misnomer] "scientific proof" is messy, and largely meaningless.
It is odd, then, that religionists require proof and act like scientists normally offer such proof; while scientists only demand evidence that an "honest and insistent attempt to disprove" has failed to so disprove.
People who speak of proof, barely understand the ideas and ideals of science. Science is the art of disproof. The reason that scientists are often religious is not, therefore, difficult to understand. Only _disproof_ is a final condition in science.
I find it odd that you toss "stupidity" around while demonstrating your own lack of knowledge... (I can be one stupid sucker myself from time to time, but I try to never "correct" _and_ deride someone at the same time. It leads to irony 8-)
Now if only we could get them to... in no particular order...
1) sell lossless formats like FLAC instead of MP3 and then also provide the free down-sample as the customer desires, if they so desire. (I can downsample by my own self)
2) stop compressing the hell out of all the music so that the CD can be "louder" than its peers. It was truly problematic in the first days of the CD that some CDs were so quiet that you had to turn up the volume to "hiss and spit" to hear the music, but once they got loud enough to represent the sound without requiring the hiss, they could have stopped.
3) stop bankrolling the DRM in other formats (hello? Sony? Aren't you responsible for BluRay or some such?)
4) stop doing things that prevent Actual Artists from distributing their music without the corporate tax.
5) die in a corporate conflagration born of sudden, budding social conscience.
(Yes, I was a dick, I think I made that perfectly clear in the text.)
For the analogy to be correct, the new car would have to have been left running, unlocked, and unattended in the parking lot and I would have had to take it out and get it what? have it cleaned?
People who leave their cars running and unlocked and unattended get their cars stolen all the time. I didn't "steal" the account nor do the equivalent of taking the keys and throwing them into the bushes.
I also didn't take the car for a ride and run it into things or rack up a bunch of red-light camera offenses. (other people had been sending messages on the account).
Nor did I copy down the registration information and use it for my own purposes (someone had been looking through chat logs for phone numbers and such if the open window contents were to be believed).
So yea, I was a dick. Not my best moment by a long shot. I started with that. But at least criticize me with a reasonable analogy and perhaps understand why I shared the story in the form of a cautionary tale. 8-)
I thought I was fairly obvious in my presentation of that as a malicious act. I didn't delve into the nature of what someone more malicious could have done, and what it seemed others had done before me, I thought it was fairly obvious. (someone had left open a chat history with personal information in it, which is how I noticed the active session in the first place).
Most of the time I am reasonably responsible. Like telling the phone center guy that his gmail account was registered on the iPhone I was looking at and people were browsing his email history. Of course in that instance I could actually find the relevant party. He had been trying to figure out why he kept getting strange emails and pissed responses from people on his contact list.
So I was a dick. Anybody can slip to the dark side from time to time.
you say "they were created to access a website" which is totally wrong...
They were created to "let a person find a computer" and the web is just _one_ computer application. As a side effect they are also useful for things like making sure the namespace you create in java (etc) applications is unique (barring bad actors) which improves portability of applications.
I have two domain names. Neither one has a web page backing it in any way. Nor do they accept email as there is no email server at that address.
I am always concerned when I see people and regulations requiring things like (a) the existence of postemaster@some.domain and which purport to measure the validity of the user of a domain's use of that domain solely on what happens when you type that domain into a web browser. It's a dangerous precedent.
That being said, I was thinkig of starting a web thingy (more than a page, less than a server) and there were shite-loads of clever names for it and they were all being squatted on by the same entity. Register.com had a "make an offer on this domain" (though I don't know if register.com is the squatting entity) and I tried to. The offer I wanted to make was $10 because that's about what it was worth. The _minimum_ offer the site would even let me post was $200, which I didn't do.
I think the whole mechanized "make an offer" thing is a true enabling evil. Punk-ass company wants to squat the domains, they should have to pony up real contact information and deal with the real people they are trying to extort.
Were I to set the rules?
If you are a comercial entity, and you hold more than ten domains, and you offer any of those domain for sale as a matter of course (e.g. "want to buy this domain?" on the page etc) or have previously sold off more than 10 domians, then any domain you hold that doesn't have actual content tied directly and uniquely to the domain name should be _presumed_ _invalid_ in any dispute. So you can pay for all the domains you want, but once you start selling them and reach the lowest bar to be considered a squatter, it should take little more than a letter to ICANN from me to get the domain stripped and delivered to me.
It doesn't take that much evidence to establish bad faith and I think domain names are, essentially, a public trust and once bad faith is demonstrated by a party, they should lose their rights.
Keep in mind that in this system a company can still buy up a bunch of domains to use, or to keep from misuse (e.g. bestbuy.com could buy up bestbuysucks.com and leave it fallow or point other domains like iwantacomputer.com back into the betsbuy.com hirearchy) and their interests would still be preserved. That is until they started selling off domains as domain-squat.bestbuy.com at which point they lose the presumption of good faith. So real companies doing real work to maintain their public images can do what they feel necessary, but the squatters can only waste their money.
Because I am a mean old man, on at least one occasion I have visited the Apple store only to find someone has used their personal iChat login on a machine...
How does this make me a mean old man?
When I find that mistake has been made, I delete all their buddies from their buddy list before closing iChat.
I have to admit, I never thought of looking for.mac history elements, but I am not sure I am mean enough to delete all of someones stored files...
Though I have considered sending (but have never sent) "I hate you, never talk to me again you lying slut" messages to the iChat buddies first.
I am trying to educate little darlings, but telling there buddies to fuck off would prevent the lesson from spreading...
While I own no stuffed logo of any sort (I despise and abhor "fun fur" as the diseased miasma of petrochemical crime-against-the-environment that real fur would never be) I am The Wiz Kid (note: no h in wiz, whiz is urine or alteration, "wiz" in this use is short for wizard) but all grown up.
The flaw in that statement is that you mistake "gamer" for "computer gamer". I am a long time gamer (back into the seventies) but I rarely use my computer to play computer games. The fact that these "console gamers" and "computer gamers" have complicated the life of the true "gamer" is a sad state of affairs indeed. If I ask someone if they are a gamer, and they say yes, but then don't know anything about any kind of game or game theory beyond how to cheat at Counter Strike, well it just gets my goat.
So linux person being gamer is highly likely. It is also likely, in decreasing order of probability, that they could be a "console gamer" or a "computer gamer" as well.
So... um... there! 8-)
[End Nit Pick]
P.S. if you don't know the difference between rearranging a deck and performing "a fair shuffle", if you don't know "fair dice" from "biased dice", if you cannot tell action from narrative, or if you have ever "gotten the cheat codes" before you started "the game", then you are not any kind of gamer.
(Mis)Using enum to introduce constants is _evil_ (IMHO of course) since you are poluting the global space but you aren't providing any kind of certian type info. That is, you don't know the size or signed-ness of an enum element.
const unsigned int Target = 8; const unsigned int Repeat = 17; const double Factor = 16; const int Fault = -1;
The explicit typing (in C++ and ansi C, the enum above is possibly a signed char) and the removal of "bogus" associations Fault and Factor don't necessarily have a relationship to Target or Repeat, so why are they in the same enum? What would be the increase in clarity if they were each in a single element enum?
See, even you have bad shortcuts in your standard approach...
Indeed your company's lawyers _do_ need to go to some training somewhere. They have obviously been listening to some FUD somewhere. There is _no_ language in GPL3 that even pretends to address use without distribution, beyond the whole "yep, use it however you want", so there can be no "Ambiguous language that could grant patent rights to other companies, even if [company] only uses the software internally."
Among other things, all the patent grants require your company to have granted patent license rights to a select set of recipients while purporting to deny those rights to others. Since a patent holder can not be said to grant licenses to itself, internal use would not be a selective grant. And so on.
Now IANAL, and if you take legal advice from strangers in internet posts, then you are an idiot. Then again, if your lawyers are not competent to understand "patent license", and if they are _that_ susceptible to FUD, then _they_ are idiots and you need to have _them_ replaced.
There is plenty of plain language in the GPL3 that even a non-lawyer can understand that the license kicks and binds you only when you do the things the license grants.
Actually it was extremely obvious. It was also considered an extremely bad idea. Anybody who has ever mis-clicked anything will know why it is a bad idea if they take a moment to generalize their knowledge.
Its a bad idea for exactly the same reason that most erase features of most operating systems erase to a clipboard or a trash folder of some sort.
See, people click on and mis-operate all sorts of things in all sorts of circumstances.
Amazon is simply big and slow enough to be able to afford to do a ship-and-return or a block-that-order action when the customer screws up. It was also well-funded enough that it could operate at a loss for something like three years from startup and not die outright.
Smaller, more responsive, less funded business would have gone bankrupt long ago. And such businesses could never have survived under the onslaught of "I didn't order this $3,000.00 flat screen so you credit back my card immediately and I'll get this back to you once you send me a shipping label" type calls.
One Click Shopping is bad business in most uses, so people didn't design their web pages that way till the "big players" came in with a lot of financial ballast.
"Do it in fewer steps" (e.g. in one step, e.g. without asking "are you sure") is _always_ obvious and is almost _never_ implemented because people screw up. And when it is implemented someone usually gets fired because its hard to teach people that they _should_ slow down and double check before they do something (a) expensive, (b) irreversible, or (c) embarrassing.
Consider: Didn't you think to double-check that order before you just (a) fired the nuke, (b) ordered a whole shipping container of toilet paper for a one-stall bathroom, (c) sold off the entire calculator division of HP, (d) fired everyone in human resources. (etc.)
Slashdot Mirror
Yes!
you are instructed to pretend that the pointer isn't a pointer, it's an "abstract link". If I tell you to pretend that an integer is a grapefruit it doesn't make it one.
Ta Da!
Broken computer science students everywhere applaud you for concisely showing why Java is a bad language for learning computer concepts.
Everything else you say is crap. The Java vm has a garbage collector. If I want a garbage collector in C or C++ I can link it in (see libgc etc). The fact that I then don't have to worry about freeing my memory doesn't then magically convert my pointers to something else. they are still pointers.
You overstate your understanding of my point. _PLENTY_ of languages have had pointers with feature-impoverished sets of operations. (See COBOL for examples) but you know what? The lack of interesting operators on a type doesn't change the nature of the type.
They are pointers no matter how deeply you cram your fingers into your ears and no matter how loudly you shout and stamp your feet.
P.S. Learn to READ. I didn't call "not having to type an extra character" a "fundamental characteristic of references"... I called it "syntactic sugar". The only feature of a reference that makes it a reference is immutability, and we have already demonstrated that you can re-point your pointers in Java via the assignment operator. (Getting out the crayola) See I took where you were trying to invent all these differences between pointers in C++ and references in C++ and boiled it down to two facts. First (labeled with a little "1") was immutability, and then second (labeled with a little "2") was the syntactic sugar. I made no statements about "fundamental characteristics of references" because "references" are "pointers" because, in truth, and as stated, references are, first and foremost, pointers.
Answer me this: What is the difference between a duck and a Mallard?
One is a general kind of thing and the second is a more specialized version of that thing. So references are pointers because, well, references are pointers. They are the same damn thing. period.
Now take a lollipop out of petty cash and STFU you clueless noob.
I frequent bars. I don't drink. It's not that I _never_ drink, but if I were to divide the number of "drinks" I have ever had in public by the number of times I have been in a bar, the number would be non-zero but significantly less than one.
So the very fact that people think of this as a "drinking record" long before it is even a prevalent thing is disturbing in the extreme.
The dataset so generated is replete with "inferred fact" that is, in fact, not fact. (to alliterate nearly unto death 8-)
This is serious, and not just for the tinfoil hat crowd. The courts certianly accept data that "smells like evidence" as actual evidence with no information theory to back it up. See the copyright nonsense. See the very low bar that has been set to determine "intent to sell" especially with respect to LSD where the gross weight of drug and delivery method divided by the microgram weight of the dose, turns a guy with 6 hist of acid in his pocket into a "major distributor". (no really, look that one up.)
So these jet-fuel geniuses in court, and in your hr office, and your local child welfare office will be inferring alcoholism from barfly status.
Well, you either like booze too much, or pool too much, or talking to people too much, and since we suck at pool, and we are boring, you must be a drunk.
What a winner...
In C++ a reference is a pointer with two additional traits:
1) The value of the pointer cannot be changed after initialization; that is, it is "immutable".
and
2) Since the value is properly immutable by virtue of item 1, the language provides the "syntactic sugar" of relieving the programmer of the chore of explicit dereferencing (using the "*" operator) on use or using the address-of ("&") operator on construction.
ASIDE: As a consequence of 2, the uninitiated may be confused by the use of the address-of (&) operator on references to regain the raw address of the referenced object. This operation is, however, inevitable in this form since [reference_name] is the same as [*pointer_name] &[reference_name] is the same as &[*pointer_name] so the auto dereference is preserved in exact semantics. This leads, for the purposes of semetry, to the auto-address-of operation takes place when a formal function call argument is initialized "by reference" since G(T&x){} F(T&x){ G(x) } {T thing; F(thing);} would be asymmetric for the calls of F and G if I had to take the address of thing, but nof of F::x etc.
Since Java _does_ let you change the value of the pointer using the assignment (e.g. "=") operator, it is not immutable and it fails to qualify in item one.
Similarly equality (e.g. operator "==") in Java compares the addresses of the two operands, which tests whether the two pointers point to the same object, as opposed to the equals() method which, when present, compares semantic equality of the contents of the object so pointed to. In c++ "[reference_name] == [reference_name]" is actually "[*pointer_name] == [*pointer_name]" whereas in Java it is "[pointer_name] == [pointer_name]".
So given that there are three possible metrics to determine if Java "object references" are "more like" "pointers" or proper "references" analysis reveals that at two-to-one out of a field of exactly three discriminants (counting the gross appearance provided by the "sugar" just to be nice to you here and spare you utter humiliation), they most closely resemble pointers. Losing the test of distinctiveness two-to-one cannot, by any measure mean the defeated proposition is "*Much* more" victorious, no matter how much punctuation you add.
Sorry about that guy, but you are completely utterly and inarguably wrong. You really _should_ just take the hit and move on with your life.
But were I to cede you the "they are like C++ references" out of the pure kindness of my heart, you would then have just proved my initial contention, that Java only has pointers, because remember, C++ references are pointers with syntatic sugar on them.
So, more simply said, you have agreed that Java uses pointers with sugar coating.
I already and initially said that those pointers are lame because you cannot do interesting pointer maths on them (a la pointer_name++ etc). This is, again, not "immutability" because that word doesn't mean what you think it means.
Immutable: Not mutable; not capable or susceptible of change; unchangeable; unalterable.
So it doesn't matter what _you_ mean by immutable. I can do "thing=null;" or "thing=other_thing;" which changes thing, so thing was and is mutable no matter what you care to think. And _again_ that makes it a pointer. You are arguing that they are reference because since they are such lame pointers they must not be pointers at all (or something equally dense and pointless, if you will excuse the pun).
In super-super-simple terms that even a Java bean can understand: You are _insisting_ that "it isn't a vehicle its a car!" when you insist "it isn't a pointer its a reference" since references are _specializations_ of pointers with most of the methods hidden. (Was that clearer son or do I have to get out crayons and crate paper?)
And now you should understand why I "laugh a little" when people _insist_ that there are no pointers in Java. It's like arguing that there is no water in the ocean because p
Yes. Crappy programmers can easily make crappy code where the smart pointers are reduntantly used raw.
So what? Java has jini that can call a library that _could_ damage the reference counting built into the java language because it, by definition, passes raw references about. All the same caveats apply. The JINI user could invalidate a pointer and leave you pointing at anything etc...
Meanwhile I _can_ craft a class where all of what you mention is so difficult as to approach impossibility to such a degree that mendacity is the only route to harm.
No language can prevent the actions of a programmer with evil in his heart.
Meanwhile its not that you "need to" destroy immediately on the drop of the last reference, its that the _ability_ to _know_ that you destroy immediately on the drop of the last reference _allows_ for "proper closure" over the core predicates of being "object oriented" _AND_ simultaneously be able to code precisely against your object invariants because you have the certainty of their lifetime.
Duh? you ask...
Lets say I read a file into memory on creation of an object, and I want to let write operations happen on that memory cache, and then I want to flush the cache to storage and close on destruction. That maps the state of the file to the lifetime of the object.
In C++ the destructor is the place to do the close, and for as long as the object exists, operating on the object is valid within that invariant.
In Java I _cannot_ use finalize to do this write-and-flush because I could make such an object, write to it, drop the reference, make another one, write to that and drop that reference and be left with _no_ _clue_ as to which cache set will end up written last.
If I provide my own "force close" method, anybody could call that method and then any operations on the file object after that force close would be erroneous. And so, sure, I could then throw a specialized exception that said "someone invalidated this object" but now I have had to add _two_ levels of complexity to properly represent a closure over an object that is "either an opened file, or not, maybe". Yay, another win.
The downside in C++ is that I have to take _responsibility_ for making sure that object lifetime is managed if the object is on the heap. (On the stack it is automagical). So that cost is a wee bit of diligence. A diligence I can encourage and all but enforce to the nth degree.
Is C++ "idiot proof"? oh hell no.
Lets face it. There are things that you just cannot do in Java. One of those things is trash your memory map. The other is to make sure that your objects are valid from construction to destruction... because there _is_ not destruction to be had. The first is a danger. The second is required for "semantic correctness" over the whole of the object oriented paradigm. Danger of the former is worth the simplicity and elegance you can create with the second.
Just as losing my car in a parking lot, or a bet, doesn't cause my car to explode into its constituent pieces and resume their life as raw materials...
losing the last reference to memory isn't destruction.
So your first point which talks about "the memory being available" is immaterial, and a tad vague.
Meanwhile...
Custom end of life routines _do_ automatically occur in C++ as long as the object reaches an end of life condition. Leaking an object doesn't imply end of life in C++ (though it is the only way to reach end-of-life in Java), it indicates a serious semantic error in the code.
So where end of life is managed (or not boned up by a bad programmer), which in C++ is automatic for automatic variables, automatic for reference-counted pointers to heap objects, and manual for manually managed objects (manual management being the default heap lifetime model in C++), end of life calls happen _precisely_ at end of life. So there you go. I did explicitly mention that for full heap-based automation you have to add pointer reference management.
Also, I made the point that "waiting for the garbage collector" to notice the object needed to be finalized was not the same thing as having a _predictable_ point of destruction at a _predictable_ end of life. (though I must have used less-clear wording.)
Consider a specific example. I have an object that represents a cache of the image of an open file. It has one reference on the stack and that reference is passed into various methods as well. An exception is thrown and all of the referencing pointers on the stack are unwound. Now I fix the problem and reenter the code, where I make a second cache object and call the hierarchy of functions which runs to completion.
In C++ (with proper lifetime management via automatics and reference counted pointers as necessary) the first cached region on the file was taken _COMPLETELY_ out of play by the exception. The destructor, with absolute certainty, has flushed the cache and closed the file during the exception, and so the open read and cache update and close cycle of the second, successful pass can take place in absolute safety and with proper closure and no uncertainty what so ever.
In Java I potentially have two separate caches that _think_ they have authoritative knowledge of what the file _ought_ to contain, and when "finalize" comes around to flush and close the file I could end up with _either_ set of data in the file or, worse, some combination of both.
So in Java I (the programmer) _MUST_ add a manual end-of-lifetime call that YOU-or-I (the user) _must_ call in every possible logical branch out of the code. {hence "finally" clauses etc added into the language.} The problem is, _requiring_ this _extra_ call to the object violates the whole concept of objective encapsulation as you _must_ end up with an "object is no longer a file" _OR_ an uncertain object validity that, by definition, extends to some uncertain time in the future (possibly "never" if the program ends).
Now yes, in C++, a "bad" programmer may leave trash on the heap at exit and violate his the fundamental lifetime of an object, but in both languages a bad programmer _could_ do damage in any number of places.
Okay? Java doesn't have destructors. It has "finalize" which has no _predictable_ semantic over the domain of time. And you can _add_ a method to do anything, including and especially, to invalidate an object that will still exist, leaving you with an invalid object {look up "invariants" to understand what I mean by "invalid" here} in scope. This is _not_ better.
So... you don't understand destruction...
The music is still playing here...
Actually, since class definitions are bound in C++, the two base classes inherited into the new class, can not, by any definition or possibility, interfere with one another. Java uses "signatures" and so, the classes could possibly be so harmfully interjoined.
So your concern about the "dangers" of multiple inheritance and semantic cross contamination are based on a false dichotomy. They are predicated on the implementation of a particular language, but not on language theory. So when I say "language X has missing feature Y" it is false dichotomy to argue that "feature Y is essentially flawed" based solely on the reasoning that "since it would be dangerous in language X" it must be a mis-feature wherever it is found.
See in a language like Java, where "signatures" are searched for in a purely derived-to-base class order, a call in an ancestor could, in the presence of multiple inheritance, cause an implementation in one class to cross-invoke a method from another ancestor.
In a bound language, where symbols are bound at compile time to the symbols available in fixed scope visibility (like C++), the symbols are bound to either explicit entry points or vtable offsets, that is to known symbolic quantities, there is _NO_ possibility of _accidental_ cross-tree calling. That means that the danger you claim wouldn't be possible.
The difference is inherent in the difference between the languages, where in java everything is overridable unless it is "final" where as in C++ nothing is overridable unless it is "volatile".
This actually points out _another_ weakness of Java. At any point in a C++ class one cannot "forget" to finalize and have a descendant bone a stable class. In Java you have to remember to lock every door, or it is opened. In C++ you have to explicitly unlock a door to let your descendants participate in your paradigm.
Or, to fold it the other way:
In C++ you _can_ create an interface class with no default implementation at all, or you _can_ provide a default implementation. In Java you cant provide a default implementation. If Java let you provide an implementation for an interface, that interface could _bone_ your class hrearchy because of signature search order. Since every implementer of an interface in Java must recreate predominantly identical code, the empty interface is more likely to induce mistakes born of repetition. Lucky you.
In short, your entire argument is bunk _outside_ of Java. Indeed Java "invented" the problem you claim they solved by making interfaces only workable as empty lists of functions, because they cannot multiply inherit code because they can only find functions by signature and to classes could implement distinct functions with the same signature....
Your position is logically circular... With a through understanding of both C++ and Java (and compiler theory and symbol resolution etc) your position reads to me as: "nuh uh, they did it right, because they did what they had to do, because they did it wrong."
This, of course, is another support of the fact that Java breaks young programmers understanding of important and subtle concepts. You have been mentally infected with some sort of late-binding meme that you think is universal to languages instead of being restricted to, well, Java...
More clown music here maestro!
What does "finally" as a scope in a method have to do with destructors?
I am not talking about static scopes in code, I am talking about directly mapping object lifetime to resource durration.
Sure, anybody can write code to explicitly end a resource state, but the idea of object lifetime is unclosed over the domains of both time and accessibility.
There are things "like" predictable lifetime and accurate destruction that "can be made" in any language "more or less" but that is far different than actually having a proved language feature doing that exact thing.
Once you understand reliable object lifetime, and particularly spesific context destruction, "sort of like it" is a PITA compared to actually having it.
Now, C++ isn't a panacea either. But I can _add_ the missing reference counted pointers to C++, but I _cannot_ add destroy _immediately_ while dropping last reference to Java.
Its the combination of the two that makes some truely sublime implementations possible.
So C++ distructors combined with something like boost.org 's shared and weak pointers produces a perfect storm of functionality over both the domains of time and scope.
The simple truth is that kit-like languages can build up to any primitive or feature rich state, but "feature safe" or "feature complete" languages cannot be "cut down" to primitives.
=== MEANWHILE ===
Nobody in the learning stage should ever be tossed in to "sink or swim". The fact that it may be harder to drown in Java doesn't excuse any school for trying to teach by sink or swim. That's not a way to teach a thing to anybody.
Obviously this construct would not compile:
// make some thing // make some other thing // still have two separate things, but the original value of "some other thing" is obliterated by the value of "some thing"
Thing & thing1 = new Thing;
Thing & thing2 = new Thing;
thing2 = thing1;
It was provided for congruency of example not correctness of text. A more useful construct would have been something like
void assign(Thing & thing1, Thing & thing2) {
thing1 = thing2;
}
and then some convoluted combinations of either automatic values or overtly contrived pointerisms...
Thing auto_thing;
Thing * pointer_thing = new Thing();
Thing & reference_thing = *pointer_thing;
assign(auto_thing,*pointer_thing);
Or possibly...
Thing & thing1 = &some_object;
Thing & thing2 = &some_other_object;
thing1 = thing2;
Or some such, but for teaching purposes the original (illegal) code is more illustrative.
I went for the cheap but obvious example, and I just know the sophomore in question will go all hoppy all over it.
It was a deliberate act, so I won't be indulging in defending it elsewhere in the thread. 8-)
But I apologize to those seeking compilable code examples... 8-)
I even _warned_ you not respond on the subject of destructors...
YOU: And here I thought Java had no destructors because you had a garbage collector. There's an easy way to "destruct" an object in Java:
YOU: myThingy = null;
The above is so wrong on so many levels it threatens to induce apoplexy... 8-)
At the end of the instruction above, nothing has been destructed at all. The object has lost visibility in this scope. Once the compiler notices that the object has no visibility anywhere it will schedule finalization, which may or may not ever take place. Finalization does not necessarily occur if the program exits before the garbage collector sees and finalizes the object.
So yes, you don't understand destructors. Having never really _needed_ one, you have never really understood what it is to _know_ and be able to _rely_ on the timely entry into a method/callback at the end-of-lifetime of an object. Oddly enough, if you have ever done any Java programming of a GUI etc, and so been exposed to "window destruction notifications" you _OUGHT_ to know why destructors are important. But clearly you have not learned to generalize your knowledge.
And amusingly enough, you _AGAIN_ demonstrate that Java only has pointers by having the "alleged reference" mutate from pointing to an object to pointing to "no object" which is something that a proper reference, being immutable over the course of its lifetime, would not be able to do...
That word. "Mutability". I don't think it means what you think it means. -- (with apologies to The Princess Bride 8-)
ME: The field of computer science has not yet come up with a "basic theory"... a starting place...
YOU: There are decent basic theories: Universal Turing machines, state machines, boolean algebra, lambda calculus, resolution with horne clauses, etc.
Q.E.D. You will notice that you present a bunch of basic theories (as in simple ideas" but not "a basic theory... a staring place... {redacted significant point, paraphrasing myself} the set of things a student must know before you begin filling their head with syntax". The _SINGULARITY_ of that absence-bemoaned starting place is the point.
We have a glut of starting places, none common, and most intransitive to one another and most, as you point out, "not taught in first year CS for good reason."
See then that these [more properly "core"] theories serve no purpose as a foundation to install at time T0 at the biginning of the first year of a CS education. We still have no "[single] basic theory..." we just play sink-or-swim with our students till they "figure enough out on their own" so that we can expose _then_ expose them to core theories.
Consider instead, science...
Science has a basic theory. It consists of all the parts of "the scientific method". First we teach observation. Then we teach measurement. Then we teach hypothesis. Then we teach invalidation of hypothesis. Then we teach recoverable analysis as a way to refine the remainders of refuted hypothesis into new stronger hypothesis. Thus do we make a student learn "science" before we expect a student to execute "science" on his own.
In "computer science" we make the student execute a bunch of code, then we force them to mimic a bunch of code, then we try to get them to invent a bunch of code based on the code they have previously mimicked or executed. All in the hopes that they will suddenly or eventually intuit what we mean by "programming".
It's like cramming a bunch of grammar rules and structures down a student's throat and expecting them to "figure out" what a verb is and how it is different from a noun or adjective.
We have no "parts of speech" for computer science. We have no observation and measurement before hypothesis structure to the way we teach algorithmic thought.
We are a bunch of monkeys hoping the younger monkeys will eventually figure out why we poke our particular blades of grass into the particular holes we choose.
The way we teach programming is the worst combination of oral tradition and tribal knowledge, and then we act surprised when the results make no sense but do generate heated invective.
Its a pity.
ME: Every time someone tells me that there are no pointers in Java I laugh a little.
// make some thing // make some other thing // lose "some other thing", now have two pointers to "some thing"
// make some thing // make some other thing // lose "some other thing", now have two pointers to "some thing"
// make some thing // make some other thing // still have two separate things, but the original value of "some other thing" is obliterated by the value of "some thing"
YOU: They would be correct. Java contains references, not pointers. The distinction is obvious to anyone who understands C++ as it has both (& for references, * for pointers). Pointers are mutable, references are not. This makes references (somewhat) safer to use and also allows a garbage collector. It also means it has a lot less functionality (particularly as an iterator).
Sorry, they are not references, they are pointers. They _call_ them references in the documentation, but what happens when you use "=" on a reference, you replace the contents of the item referenced. In java, when you use "=" the pointer-miscalled-reference takes on the address of the right-hand-side as a second means of access to that now-shared object.
to whit, in java:
Thing thing1 = new Thing;
Thing thing2 = new Thing;
thing2 = thing1;
so yes, "pointer are mutable and references are not" and here the pointer itself "thing2" is mutated by the assignment where a reference would not be. The fact that the object originally pointed to by thing2 is unchanged is a question of object mutability, not pointer mutability. But thank you for demonstrating to the audience that learning Java harms your ability to understand and deal with the concept of a pointer. You have served as an admirable example of what the article was trying to say. Bravo!
But to continue, for those who still do not get it...
This is the same (ignoring the memory leak) as the identical code in C++ using pointers:
Thing * thing1 = new Thing;
Thing * thing2 = new Thing;
thing2 = thing1;
But when _references_ are used things are different. (note that for the reference one to work correctly the anonymous objects would need to be const or some such, e.g. the language resists letting you code this mistake directly etc)
Thing & thing1 = new Thing;
Thing & thing2 = new Thing;
thing2 = thing1;
So anyway, java... just has pointers... no references... no mater what they choose to call them.... They are "reference counted pointers" but not properly references. The "just references" semantic is a lie, and one you have fallen for. And so, I laugh a little.
As for your other questions and observations, I wasn't writing a technical treatise on Java, but even so:
Why would I want to pass a the contents of a non scalar by value? Why to have a private copy of the structure to work with you silly boy. Kind of the definition of "why copy" anything.
The pedant will point out that Java "only passes by value" where the "value" is the address stored in the pointer, or the bit pattern stored in the scalar. Semantically, however, since the language struggles so desperately to make you think of the pointer as the object, it is everything we expect as technical professionals, in every detail, when we say "Java does not pass [non scalars] by value". Meanwhile, the language makes us create an entire object to entomb a simple scalar if we want to pass _that_ by reference. I am sure you don't know why I might want to do that either. Right tool for the job my boy. In a "real language" (to use the pejorative 8-)pass by value cheaper for scalars, more expensive for aggregates; pass by reference cheaper for aggregates, marginally more expensive for scalars (especially when optimization is considered) but both techniques have their uses and misuses.
And
I you make everyone special, nobody is really special.
Every time someone tells me that there are no pointers in Java I laugh a little. EVERYTHING in java that isn't a scalar is actually referenced through pointers. That is, you declare the pointer variable and then "new" the object into place.
They are just incredibly _boring_ pointers. You cannot math on them. There is no sense of location to those pointers. But the absence of interesting pointer operations, and the absence of the _semantic_ _copy_ operation is what all this alleged pointerlessness is all about.
I have only two _Real_ problems with java... (okay three if you count the complete requirement that you constantly have to deal with exceptions even when you know they cannot really happen, and if they did, you would want the thing to abort all over the place... but I digress)
(1) Java has no useful destructors because no object has predictable scope. If you think finalize methods are the same as destructors then don't bother responding, you don't know what destructors are...
(2) Since everything is a pointer in Java, you have to bend over backwards to pass-by-value. The fact that the language doesn't even begin to provide copy-construction semantics. What a miserable PITA.
Now the _dumbest_ thing about java is that they were so set against multiple inheritance that they never bothered to ask themselves why _every_ OO language starts out life without multiple inheritance only to have to add it later. By making everything a proper linear subclass of Object, they left themselves with having to graft on "interfaces" which is just multiple inheritance with the "bonus" of completely preventing default implementations. (Which lead to delegation etc.)
The way the language keeps sprouting things it claims to never have and never need, well it's very like watching a clown car endlessly explode with ridiculous archetypes. After a while it just isn't funny any more.
So yea, teaching people Java as an introductory language is something of a disservice if you ever want to make them truly think about programming and what makes some things machine smart, while others are machine stupid.
--- BUT ---
I worked in education for years. The fundamental problem with computer science education is that it is being taught by computer scientists instead of educators. We are stuck learning from the people who learned from the people who made it up. None of these people ever learned to EFFECTIVELY IMPART INFORMATION.
Consequently, the students are largely unemployable on the day of graduation.
The classic computer curricula seems to consist of throwing three or four languages at a kid in the hopes that they will "just kind of figure out this programming stuff."
The field of computer science has not yet come up with a "basic theory"... a starting place... The list of things a student simply must know before you start filling their head with syntax.
And so we are a bunch of prelates training our acolytes in our special, individualized deeper mysteries.
And that's what everybody is doing worldwide, so our graduates are just as lame as everyone else's...
Cue "Enter the Gladiators"...
Science isn't am entity, "it" cannot guess. It cannot "LEAD to" anything anywhere. Just because you feel comfortable anthropomorphizing the entire universe, doesn't make it so. Just because you feel that need to be lead by an all-powerful it, doesn't for the tiniest moment endow science with entity or purpose.
You really just dont' get it at all do you?
"People of faith" demand that science provide "proof" that they themselves cannot supply about their faith.
"People of science" would like "people of faith" to shut the fuck up, not in general, but specifically about their attempts to misuse the trappings of science to validate their positions of faith.
Science doesn't lead, and the pursuit of science can only go two ways. Honestly forward into what is, or horribly astray by what people demand to see. The pursuit of science, diligently and precisely exercised by persons of honest endeavor, does reveal fact. But it only does so only asymptotically. Ever closer, but never complete. And then, armed with the best available approximation of fact, we hope men of conscience will lead.
Be as faithful as you want to your choice of deities, but you won't win the scientifically minded over until you try to rigorously examine that faith with an eye to trying to disprove it. When you honestly assail that attempt at disproof, and fail to disprove it, then you will earn the right to call your position validated in a scientific sense.
Meanwhile, the classification of things scientific is _solely_ and _wholly_ dependent on the method of ascertainment. Asserting any atom of knowledge, even if you assert it to have been gained "scientifically", it isnt necessarily so unless the science behind it was sound.
You say "semantic" as if semantics are invalid. As if the lowest thing is semantic differences. But each distinction in all things is semantic before it is systematic. Reality is the infinite sum of the infinitesimal pieces. The distinction between "the best, most rigorous guess we can make" and something with the "ring of truthiness" (credit to mister Colbert for that word) is that the former is ground fine under the wheels of doubt and reason, while the later is simply pronounced with an air of certitude.
All of life is vocabulary, and all of understanding is semantics, at least all of the all that can be shared between people effectively. Even your faith, and your wars of faith, dance semantically with angels on pinheads.
I'll give you "science" not being a verb. I'll point you to the definitions of the noun "science" and the adjective "scientific" as its close antecedent. But then I must paste the annotation from that very noun:
Note: Science is applied or pure. Applied science is a
knowledge of facts, events, or phenomena, as explained,
accounted for, or produced, by means of powers, causes,
or laws. Pure science is the knowledge of these powers,
causes, or laws, considered apart, or as pure from all
applications. Both these terms have a similar and
special signification when applied to the science of
quantity; as, the applied and pure mathematics. Exact
science is knowledge so systematized that prediction
and verification, by measurement, experiment,
observation, etc., are possible. The mathematical and
physical
They bible is not a myth. The bible is a fact, in that I can go out and get one and possess it and demonstrate its factual reality by, say, reading it, or using it to prop up one corner of a tippy sofa...
The bible is not a myth, it _presents_ a _mythos_. That is, it presents a _set_ of many interlocking or interdependent myths.
Please use more correct English when deriding the belief systems of others, else you'll make all us technical realists look bad...
8-)
You had me till your third paragraph, whereupon you instantly got reclassified as an oratorical goon. (no offense. 8-)
"Science" is a "provable fact", and is even a "proven fact" because it is a _technique_ or _approach_, and so its existence and its practice is a fact. If you want to say "science has yet to ever be proven as a fact" you must be willing and ready to replace "science" with "reading" or "throwing a ball". That is you would have to be ready to say "reading has yet to ever be proven as fact" but you are reading and people do read, so reading is a fact.
Now not every person reads well, nor effectively, but the action of reading is factual.
Now not every person throws a ball well, nor effectively, but the action of throwing a ball is factual.
Now not every person [practices or performs] science well, nor effectively, but the action of [practicing or performing] science is factual. [ASIDE: read is to reading as science is to "sicencing"? In the absence of an active tense for the word "science" I prefaced practicing or performing. It is left as an exercise to the reader to assess whether this damages the symmetry of the argument. 8-)]
From there on you systematically demonstrate a fundamental misunderstanding of the scientific method, or at least a profound inability to express what you believe you understand about it.
The super-short super-simplified version is this: In Science you make observations, from those observations you make a guess (hypothesis), indeed the _best_ _guess_ you _can_, and you then construct a test or suit of tests that would invalidate that hypothesis. Then you contrive to execute that test, in the hopes that your test will fail to invalidate that hypothesis, and you observe the results. You use those observations to construct a better hypothesis and another set of tests. Lather Rinse Repeat. Once you have a hypothesis that you cannot refute, you promote your hypothesis to a thesis (in your mind, and a "candidate thesis to others) or in short "a theory", and present it to the world, along with your test methodology and results. Those others consider your thesis as a hypothesis of their own, and both act to verify your test results and also attempt to come up with their own test sets that would validate re-validate the hypothesis to themselves before accepting your thesis as their own.
Really consider the words.
"Hypo-" A prefix signifying a less quantity, or a low state or degree, of that denoted by the word with which it is joined, or position under or beneath.
"Thesis" A position or proposition which a person advances and offers to maintain, or which is actually maintained by argument.
"hypothesis" a proposal intended to explain certain facts or observations.
In the technique we call "the scientific method" or just plain "science" nothing is _EVER_ proved, but many things are frequently _DISPROVED_.
The [egregious misnomer] "scientific proof" is messy, and largely meaningless.
It is odd, then, that religionists require proof and act like scientists normally offer such proof; while scientists only demand evidence that an "honest and insistent attempt to disprove" has failed to so disprove.
People who speak of proof, barely understand the ideas and ideals of science. Science is the art of disproof. The reason that scientists are often religious is not, therefore, difficult to understand. Only _disproof_ is a final condition in science.
I find it odd that you toss "stupidity" around while demonstrating your own lack of knowledge... (I can be one stupid sucker myself from time to time, but I try to never "correct" _and_ deride someone at the same time. It leads to irony 8-)
Now if only we could get them to... in no particular order...
1) sell lossless formats like FLAC instead of MP3 and then also provide the free down-sample as the customer desires, if they so desire. (I can downsample by my own self)
2) stop compressing the hell out of all the music so that the CD can be "louder" than its peers. It was truly problematic in the first days of the CD that some CDs were so quiet that you had to turn up the volume to "hiss and spit" to hear the music, but once they got loud enough to represent the sound without requiring the hiss, they could have stopped.
3) stop bankrolling the DRM in other formats (hello? Sony? Aren't you responsible for BluRay or some such?)
4) stop doing things that prevent Actual Artists from distributing their music without the corporate tax.
5) die in a corporate conflagration born of sudden, budding social conscience.
(Oh, well, I can dream... 8-)
The enemy of my enemy is my enemy's enemy and nothing more...
Don't you the 12 habits of truly effective pirates? (SchlockMercenary.com)
(Yes, I was a dick, I think I made that perfectly clear in the text.)
For the analogy to be correct, the new car would have to have been left running, unlocked, and unattended in the parking lot and I would have had to take it out and get it what? have it cleaned?
People who leave their cars running and unlocked and unattended get their cars stolen all the time. I didn't "steal" the account nor do the equivalent of taking the keys and throwing them into the bushes.
I also didn't take the car for a ride and run it into things or rack up a bunch of red-light camera offenses. (other people had been sending messages on the account).
Nor did I copy down the registration information and use it for my own purposes (someone had been looking through chat logs for phone numbers and such if the open window contents were to be believed).
So yea, I was a dick. Not my best moment by a long shot. I started with that. But at least criticize me with a reasonable analogy and perhaps understand why I shared the story in the form of a cautionary tale. 8-)
I thought I was fairly obvious in my presentation of that as a malicious act. I didn't delve into the nature of what someone more malicious could have done, and what it seemed others had done before me, I thought it was fairly obvious. (someone had left open a chat history with personal information in it, which is how I noticed the active session in the first place).
Most of the time I am reasonably responsible. Like telling the phone center guy that his gmail account was registered on the iPhone I was looking at and people were browsing his email history. Of course in that instance I could actually find the relevant party. He had been trying to figure out why he kept getting strange emails and pissed responses from people on his contact list.
So I was a dick. Anybody can slip to the dark side from time to time.
you say "they were created to access a website" which is totally wrong...
They were created to "let a person find a computer" and the web is just _one_ computer application. As a side effect they are also useful for things like making sure the namespace you create in java (etc) applications is unique (barring bad actors) which improves portability of applications.
I have two domain names. Neither one has a web page backing it in any way. Nor do they accept email as there is no email server at that address.
I am always concerned when I see people and regulations requiring things like (a) the existence of postemaster@some.domain and which purport to measure the validity of the user of a domain's use of that domain solely on what happens when you type that domain into a web browser. It's a dangerous precedent.
That being said, I was thinkig of starting a web thingy (more than a page, less than a server) and there were shite-loads of clever names for it and they were all being squatted on by the same entity. Register.com had a "make an offer on this domain" (though I don't know if register.com is the squatting entity) and I tried to. The offer I wanted to make was $10 because that's about what it was worth. The _minimum_ offer the site would even let me post was $200, which I didn't do.
I think the whole mechanized "make an offer" thing is a true enabling evil. Punk-ass company wants to squat the domains, they should have to pony up real contact information and deal with the real people they are trying to extort.
Were I to set the rules?
If you are a comercial entity, and you hold more than ten domains, and you offer any of those domain for sale as a matter of course (e.g. "want to buy this domain?" on the page etc) or have previously sold off more than 10 domians, then any domain you hold that doesn't have actual content tied directly and uniquely to the domain name should be _presumed_ _invalid_ in any dispute. So you can pay for all the domains you want, but once you start selling them and reach the lowest bar to be considered a squatter, it should take little more than a letter to ICANN from me to get the domain stripped and delivered to me.
It doesn't take that much evidence to establish bad faith and I think domain names are, essentially, a public trust and once bad faith is demonstrated by a party, they should lose their rights.
Keep in mind that in this system a company can still buy up a bunch of domains to use, or to keep from misuse (e.g. bestbuy.com could buy up bestbuysucks.com and leave it fallow or point other domains like iwantacomputer.com back into the betsbuy.com hirearchy) and their interests would still be preserved. That is until they started selling off domains as domain-squat.bestbuy.com at which point they lose the presumption of good faith. So real companies doing real work to maintain their public images can do what they feel necessary, but the squatters can only waste their money.
Because I am a mean old man, on at least one occasion I have visited the Apple store only to find someone has used their personal iChat login on a machine...
.mac history elements, but I am not sure I am mean enough to delete all of someones stored files...
How does this make me a mean old man?
When I find that mistake has been made, I delete all their buddies from their buddy list before closing iChat.
I have to admit, I never thought of looking for
Though I have considered sending (but have never sent) "I hate you, never talk to me again you lying slut" messages to the iChat buddies first.
I am trying to educate little darlings, but telling there buddies to fuck off would prevent the lesson from spreading...
[Begin Nit Pick]
While I own no stuffed logo of any sort (I despise and abhor "fun fur" as the diseased miasma of petrochemical crime-against-the-environment that real fur would never be) I am The Wiz Kid (note: no h in wiz, whiz is urine or alteration, "wiz" in this use is short for wizard) but all grown up.
The flaw in that statement is that you mistake "gamer" for "computer gamer". I am a long time gamer (back into the seventies) but I rarely use my computer to play computer games. The fact that these "console gamers" and "computer gamers" have complicated the life of the true "gamer" is a sad state of affairs indeed. If I ask someone if they are a gamer, and they say yes, but then don't know anything about any kind of game or game theory beyond how to cheat at Counter Strike, well it just gets my goat.
So linux person being gamer is highly likely. It is also likely, in decreasing order of probability, that they could be a "console gamer" or a "computer gamer" as well.
So... um... there! 8-)
[End Nit Pick]
P.S. if you don't know the difference between rearranging a deck and performing "a fair shuffle", if you don't know "fair dice" from "biased dice", if you cannot tell action from narrative, or if you have ever "gotten the cheat codes" before you started "the game", then you are not any kind of gamer.
P.P.S. Yes, this is _mostly_ tongue-in-cheek...
(Mis)Using enum to introduce constants is _evil_ (IMHO of course) since you are poluting the global space but you aren't providing any kind of certian type info. That is, you don't know the size or signed-ness of an enum element.
scoped constants are why god invented "const"...
Which is cleaner and more clear:
enum {
Target = 8,
Repeat = 17,
Factor = 16,
Fault = -1
};
or
const unsigned int Target = 8;
const unsigned int Repeat = 17;
const double Factor = 16;
const int Fault = -1;
The explicit typing (in C++ and ansi C, the enum above is possibly a signed char) and the removal of "bogus" associations Fault and Factor don't necessarily have a relationship to Target or Repeat, so why are they in the same enum? What would be the increase in clarity if they were each in a single element enum?
See, even you have bad shortcuts in your standard approach...
Indeed your company's lawyers _do_ need to go to some training somewhere. They have obviously been listening to some FUD somewhere. There is _no_ language in GPL3 that even pretends to address use without distribution, beyond the whole "yep, use it however you want", so there can be no "Ambiguous language that could grant patent rights to other companies, even if [company] only uses the software internally."
Among other things, all the patent grants require your company to have granted patent license rights to a select set of recipients while purporting to deny those rights to others. Since a patent holder can not be said to grant licenses to itself, internal use would not be a selective grant. And so on.
Now IANAL, and if you take legal advice from strangers in internet posts, then you are an idiot. Then again, if your lawyers are not competent to understand "patent license", and if they are _that_ susceptible to FUD, then _they_ are idiots and you need to have _them_ replaced.
There is plenty of plain language in the GPL3 that even a non-lawyer can understand that the license kicks and binds you only when you do the things the license grants.
Actually it was extremely obvious. It was also considered an extremely bad idea. Anybody who has ever mis-clicked anything will know why it is a bad idea if they take a moment to generalize their knowledge.
Its a bad idea for exactly the same reason that most erase features of most operating systems erase to a clipboard or a trash folder of some sort.
See, people click on and mis-operate all sorts of things in all sorts of circumstances.
Amazon is simply big and slow enough to be able to afford to do a ship-and-return or a block-that-order action when the customer screws up. It was also well-funded enough that it could operate at a loss for something like three years from startup and not die outright.
Smaller, more responsive, less funded business would have gone bankrupt long ago. And such businesses could never have survived under the onslaught of "I didn't order this $3,000.00 flat screen so you credit back my card immediately and I'll get this back to you once you send me a shipping label" type calls.
One Click Shopping is bad business in most uses, so people didn't design their web pages that way till the "big players" came in with a lot of financial ballast.
"Do it in fewer steps" (e.g. in one step, e.g. without asking "are you sure") is _always_ obvious and is almost _never_ implemented because people screw up. And when it is implemented someone usually gets fired because its hard to teach people that they _should_ slow down and double check before they do something (a) expensive, (b) irreversible, or (c) embarrassing.
Consider: Didn't you think to double-check that order before you just (a) fired the nuke, (b) ordered a whole shipping container of toilet paper for a one-stall bathroom, (c) sold off the entire calculator division of HP, (d) fired everyone in human resources. (etc.)