The article says almost exactly that:
"However, Objects are not passed by reference. A correct statement would be Object references are passed by value."
"However, Objects are not passed by reference. A correct statement would be Object references are passed by value."
Instead it rants at length to somehow save definitions that are clearly not particularly helpful in a language like Java.
This article just reeks of this certain kind of socially inept, completely unhelpful attitude and technical pedantry that has infected mailinglists and IRC channels over the world. Actively trying to misunderstand people in an effort to expose their ignorance or unfamiliarity with intricacies of whatever language or tool they are trying to navigate.
Its a terrible habit up there with feigned surprise.
We should be consistent in terminology. If we accept Sun's terminology, then objects are indeed passed by reference. If we're insisting on the more traditional C++ terminology, then Java has no references, only pointers.
The author recognizes the two meanings of "reference", but isn't sufficiently clear about which meaning he's using at a given time.
If you don't know Java, and need an explanation, then you need one based on terminology that exists outside Java. Pass by value and pass by reference are concepts that predate and exist outside of Java, describing programming language semantics in a way where statements about different languages can be compared and contrasted, because they're not phrased in vocabulary specific to the language the statement is about.
Java passes all arguments by value.
The idea of overloading the term 'reference' to mean 'pointer', but without all the power you get from pointers in languages like C, has at this point grown far beyond Java. I don't think it's a logical muddying of the waters to use it in a phrase like "references are passed by value" when describing Java using terminology that exists outside of Java.
1) To say that Java "passes all arguments by value" implies astonishing behavior if one passes an object and calls a mutator on that object changes it everywhere else that reference is used. If it were truly passed by value, the target would get a _copy_ of the original. Which is NOT the case in Java. So this terminology is misleading!
2) An admittedly weaker argument you imply that a given Java developer has never looked at any other language that doesn't use Java's approach to parameter passing. That's a tiny, tiny audience, my friend.
Foo x = new Foo();
x.setBar(42);
Foo y = x;
y.setBar(0);
assert(x.getBar() == 42); // fails! astonishing behaviour!
To understand this, you need to know that Java objects are reference types. And this has nothing to do with parameter passing.
And once you understand reference type semantics, you don't need anything extra to understand parameter passing, because parameter passing in Java uses the same semantics as assignment: that is, the value of the actual parameter is copied into the formal parameter, just like values on the right of an assignment are copied into the locations on the left. It's pass by copy.
Note that it you change the pointer (object reference) directly, instead of following it and mutating the pointed-to object, the caller would NOT see the change. Like "x = new Foo()" inside a routine would not change what was passed in at all.
But if Java was pass by reference, then things would act differently.
Please learn Java. It's not about not knowing other languages. It's about not knowing Java. This is all in the JLS.
A C++ pointer is a simple thing: an address within the program's address space. In an earlier response to a similar claim of yours, RayleyField pointed out that "In HotSpot references are double pointers (useful for moving GC), but in general it's up to JVM implementation." Certainly, if you dig into a Java reference, you will find an address that is analogous to a C++ pointer, but the same can be said of a C++ reference. Java references are not exactly equivalent to either C++ references or C++ pointers, and the statement that Java passes by value is not dependent on an arguable claim that Java references are more like C++ pointers than C++ references. This line of argument has just added to the confusion in these threads.
Logically, a C++ pointer and a Java object reference are nearly identical, as described and defined by their respective language standards. Independent of the implementation chosen.
This is not the same as a C++ reference, which is logically an alias (and may be implemented via pointers, but that's irrelevant).
The confusion in this thread stems from people confusing many things, indeed.
Same with "Java object reference" and "Java pointer" (synonyms).
If we can't discuss this topic using those well-defined things, what can we use?
I am told you will find all the things you need well-defined in the JLE, and in doing so you will avoid positing a plurality without necessity, as Billy Ockham may or may not have put it.
But if people in this thread could read and understand the JLS, this thread wouldn't exist. Since it does, some of us feel like we should contribute and correct the false statements we see.
It's only obvious if we assume some knowledge of Java's semantics.
"A word means what I want it to mean, nothing more, nothing less." - Humpty Dumpty, 'Through The Looking Glass and What Alice Found There'.
There should be a variant of Occam's Razor specifically against unnecessary semantic splitting and proliferation.
Correctness is important.
But also, for the purposes of this discussion, it is very useful and illustrative to equate pass-by-reference to C++ references, and object references to C++ pointers, because the languages are similar and the concepts match up very well, and because these things are more explicit in C++.
Sure, one could have defined everything without comparing to C++ (in fact that is what the JLS does) but, for the purposes of this discussion, many of us assumed that wasn't good enough for many posters here, because if it was, this discussion wouldn't exist.
Seems to me like a good place is a modern, widely-used language which is similar to Java but also has both pass-by-value and pass-by-reference so one can illustrate what those terms actually mean and how they differ.
Seems like C++ is as good a choice as any Feel free to use another language if you can do better.
Explaining pass-by-reference using Java, which can't express pass-by-reference, is one of the sources of the confusion people here are experiencing (the other is Java using reference to mean something different from established meanings).
Clearly, one should turn to computer science fundamentals. Considering the totality of your posts under this article and the responses to them, picking the language with arguably the most complex panoply of ways to denote values, of any language in common use, hasn't worked out as a pedagogical device.
So do not conflate what you consider clear with what the thread is reflecting as clear. They are quite different.
'Please learn Java. It's not about not knowing other languages. It's about not knowing Java. This is all in the JLS.'
'Read the JLS. This is Java as defined by its creators, absent of C++.'
I think you are being particularly clear in that last one.
As I said before, if people understood the fundamentals, or if the fundamentals were good enough, then this entire thread wouldn't exist. This stuff is child's play. Anyone who is confused by this needs more help than shrugging and saying "stop trying, just point them at more fundamentals"...
Which is not to say that there is anywhere this post belongs, as you attempt to use a couple of tired old rhetorical ploys: insinuating a position that has not been stated, and the insertion of a specific item into a list of disjunctions in the hope of insinuating that it is necessary.
Your argument here depends on the misunderstanding that all explanations in computer science are abstract, and specifically that they are inevitably more abstract than a discussion of the same topic in C++. That is not so; a discussion of argument-passing can be (and is) done in terms of addresses and stack frames. That's more concrete than 'abstract pointers', and also more straightforward than making qualified analogies between elements of Java and C++, which are of no help to anyone who doesn't have a solid understanding of C++, anyway.
This is just as well, or how else would anyone have understood this stuff before they had C++?
> you attempt to use a couple of tired old rhetorical ploys
I do no such thing.
> Your argument here depends on the misunderstanding that all explanations in computer science are abstract
Not at all.
> That is not so; a discussion of argument-passing can be (and is) done in terms of addresses and stack frames.
Sure you could do it that way. But it becomes exponentially more complicated because you need to either stick to one specific implementation of one specific language runtime, or you have to deal with explaining them all. Neither is ideal.
> are of no help to anyone who doesn't have a solid understanding of C++, anyway
You just need a basic understanding. This isn't advanced stuff here. People learn Java's object references the very first time they
Thing x = y; y->something(); // Why has x changed?
These are week-one concepts for anyone learning the languages.
> This is just as well, or how else would anyone have understood this stuff before they had C++?
Most people have no trouble understanding the concept in week one of Java, or C++, or whatever other language they are learning. And the rest get it from the fundamentals. But those aren't the people in this thread who continue to confuse the issue.
If someone can't take the phrase "pass-by-reference" and the phrase "Java object reference" and understand that the two uses of the word "reference" mean different things, even after reading the simple-to-understand definitions of each, then they really need above-and-beyond help. This isn't "dive into CS theory" or "show them the machine-level stack frames and register contents", this is "try whatever you can that might help them". C++ is a very valid place to go for these folks.
'What in the world are you talking about?'
Here we have another common rhetorical ploy, the attempt to insinuate that the other party is not making sense, without actually refuting her arguments. If not used carefully, however, it has the unfortunate side-effect of giving the impression that you alone cannot figure it out.
But do keep the snide asides coming (not that I think you are likely to stop). If it were not for them, I would have left this thread long ago, satisfied that we had reached an amicable agreement to disagree.
You follow with a few flat denials of things I wrote. You can do that until the cows come home, but unless you can offer actual refutations of the arguments I presented in support of those claims, you are just blowing hot air.
'Sure you could do it that way. But it becomes exponentially more complicated because you need to either stick to one specific implementation of one specific language runtime, or you have to deal with explaining them all.'
Now we come to something that has the verisimilitude of a rational argument, and we can immediately see why you were reluctant to go there, despite the manifest failings of the alternatives you tried. The first question that comes to mind is, exponential in what? What, precisely, leads to an exponential growth in complexity? Note that the sentence quoted here claims exponentially more complication even if you stick to one specific implementation of one specific language runtime, so make sure that your explanation covers that case, or I will have to return to it. Also make sure that your explanation somehow avoids applying to C++, and covers how we ever managed to figure this all out before we had C++.
Furthermore, the implication that it has to be presented using one extant runtime or another is fallacious. One can discuss argument passing using stack frames and addresses without getting into how C++ or any other specific language implements it, and the empirical proof of that can be found in any number of elementary comp. sci. textbooks.
Your 'its so simple' argument is a non-sequitur, as you are making the fallacy that if the concept is simple, then any explanation will be simple. In reality people can, and do, tie themselves in knots over simple issues - Zeno's paradoxes are a case in point. In fact, the simplicity argument goes against you - it's so simple, yet you ended up retroactively qualifying your use of pointer as 'abstract pointer' and spend time in drawing analogies between C++ pointers and Java references.
And if its so simple, how come that there are people who are just not getting it? Maybe, just maybe, the problem is in how it is presented.
The question of whether an approach via C++ is helpful, and whether your particular approach (using qualified analogies between C++ and Java) helps, are separate issues. I could go into how well your approach worked in practice, though I don't think that is necessary at this point (unless you choose to go there), except to point out that you repeatedly abandoned this approach in favor of a purely Java one, telling people to 'read the JLS.'
Perhaps it really is simple, and you are afraid to admit that maybe you didn't get a simple concept either, until your eyes were opened by the very posts you spend walls of text refuting. I know it is not a pleasant feeling, but it's acceptable to own up to it. No amount of text or thesaurus consultation will fix your mistake.
Or, if that's too much pride for you to abandon, then you can continue to stand behind your original claim that references in C++ and Java are the same for this discussion (or any other - but I posit that there is no discussion, except for maybe "the word reference in both phrases has the same spelling"), then I feel for you. I really do.
Good day!
So here's a difference between us: I freely acknowledge correct arguments, while you silently slink away from your mistakes, and try to pretend you never made them. I am happy to have third parties figure out who is being immature here.
Top O' the morning to you!
I also don't believe I ever claimed that C++ was the option.
I own up to my mistakes the instant they are apparent. If you believe I should be owning up to something but I haven't yet, it is because either I wasn't wrong, or the argument against me wasn't coherent.
But at least you finally capitulated. I didn't think you would, so you at least proved me wrong there.
If that's true then I wish you would have said that up front like the experimenter in the video. Unlike the subjects, I would have had no problem delaying that gratification. My prize would have beaten a marshmallow any day.
A simple reading of this thread shows that I have merely been responding to specific claims of yours, in which the comparison of references was neither here nor there, once you chose to make an issue of whether your C++-comparison based explanation was the only feasible one remaining. When you could have left it as an amicable difference of opinions, you chose to double-down and insist that anything other than your opinion was flat-out wrong, which led you to make a series of increasingly poor arguments, culminating in the ridiculous claim that the alternatives would literally be exponentially more complex.
In each case (including the last), after I pointed out the flaws in your claims, you have neither accepted the point, nor offered any counter-argument. Instead, you circled around and tried to make a different argument for the same claim, as if there was not already a growing pile of refutations stacking up against it. If there was any doubt before that you suffer from the obsession you accuse me of, you effectively removed it by this behavior.
There is not much point in discussing anything with someone like you, but your sanctimonious rudeness to me and others makes it worthwhile.
'My prize would have beaten a marshmallow any day.' No surprise there - your juvenile motivations are plain for anyone to see.
So the video had no point then? Because the video I saw was about delayed gratification, not the strategy of truths and falsehoods.
And I still await a clear idea of where I made a claim of truth and was mistaken. As I've said in the past, if you can show me that clearly, I'll capitulate. I've been patiently waiting through all of your long-winded responses for this, and have been disappointed so far.
In fact, you now have changed your characterization of my posts from "truths and claims" to "opinions", which most of them were all along (the only claim I believe I made that could be considered fact instead of opinion was the refutation of your C++ references-and-pointers equation, which you agreed I was correct on).
> A simple reading of this thread shows that I have merely been responding to specific claims of yours
I don't see that anywhere, actually.
> once you chose to make an issue of whether your C++-comparison based explanation was the only feasible one remaining
I also don't see this anywhere. What I do see is my claim that C++ is a useful comparison - but nowhere do I see myself claiming it is the "only" one, or the "only feasible" one.
Some of my quotes have been: "for the purposes of this discussion, it is very useful and illustrative to equate pass-by-reference to C++ references, and object references to C++ pointers, because the languages are similar and the concepts match up very well, and because these things are more explicit in C++" and "Seems like C++ is as good a choice as any" and "one could have defined everything without comparing to C++"...
> after I pointed out the flaws in your claims, you have neither accepted the point, nor offered any counter-argument
But you haven't actually pointed out any flaws in any of my claims.
> as if there was not already a growing pile of refutations stacking up against it
Please, point out the pile of refutations to the claim that C++ is useful in this discussion (not "only", just "useful)... especially since, refuting the notion that it is useful to someone means finding everyone who read it and getting them to admit that they found no use in it. If you do that, I'll certainly admit I was wrong.
> your sanctimonious rudeness
I see very little rudeness - the only clear cut case was in response to someone else who basically asked me what rudeness would look like and I gave an example referencing proggit. Care to quote any specific rudeness toward you? Be careful not to equate an unpleasant discussion with rudeness.
> your juvenile motivations
If you think truth is a juvenile motivation then I finally understand everything you've written.
I won't even dwell on the hypocrisy of you trying to call me out for my rudeness right before you post this middle school nonsense.
If you don't think stack frames and addresses are far more complex a learning tool for this than references and pointers, that's your opinion. I disagree, and I think many would, but there's no factual claim here for you to refute, no matter how much you are grasping for one in this thread.
Go ahead and explain it your way to folks. See if it finally sinks in for those who didn't get it from the JLS or from the article. I'd be happy to watch the attempt. I don't think it'll work. Prove me wrong.
Another recurring factual claim is that there is a set of people that will understand this issue only if it is presented in a very specific way. Putting aside, for the moment, the question of how well that worked out in practice, let's look at what characteristics you have ascribed to your target: 1) They didn't get it as presented in the original article; 2) They have read what the JLS says about it, but did not understand it there; 3) They could not be led, through a suitable explanation, to follow what the JLS says; 4) Any explanation based on computing basics would be beyond their grasp; 5) Despite all this, they understand (and not just think they understand) the more complex issue of argument-passing in C++. It seems unlikely there is anyone in this set. In particular, while there seem to be people in group 3, I doubt any of them have made it into group 5.
As for an alternative explanation, we have, for example, eslaught's post: https://news.ycombinator.com/item?id=9249285 The first paragraph gets to the essential point with admirable directness, without using any comparison to a language that has a particularly complex array of argument-passing cases.
For example, it is your opinion that C++ argument-passing is more complex; it is mine that it is more explicit and easier to reason about. Notice how I don't take your claim and call it a fact and write pages about how you must back up your claim with some more evidence before I'll buy it.
"Sure you could do it that way. But it becomes exponentially more complicated because you need to either stick to one specific implementation of one specific language runtime, or you have to deal with explaining them all. Neither is ideal."
So it is reasonable for me to ask if the example you asked for changes your mind on this issue.
The comment you linked to is much more reasonable than that and only introduces a little more complexity. But it is still more complex in my opinion because it uses both stacks/locals and heaps/objects as well as referencing C++, and I don't think someone who confuses Java for a pass-by-reference language will understand that any better.
If your goal in all of this is to try to change my opinion, you will need to keep trying. Why you would spend all this time on it is beyond me, but since I enjoy correcting your fallacies and you seem to enjoy grasping for ways to appear like you've accomplished something with all of your replies, we could be doing this for quite a while.
Keep it coming.
Your response is exactly what we could predict: after a couple of posts in which you try to ignore the first paragraph of eslaught's post, you attempt to rewrite the issue by bringing in his following two paragraphs, which are about a different topic (ironically, their topic is the unsuitability of C++ for this discussion!) The first paragraph stands on its own and is not dependent on, or even supported by, on the following two paragraphs.
So you really would like us to believe that your judgement is such that you find this straight-to-the-point ("you still have no way to modify the variable binding on the caller's stack") argument slightly more complicated than yours, which includes a couple of other long, snide-remarks-laden threads (something you obviously have a predilection for), and a couple in which you finally abandoned your approach, telling people to read the JLS instead?
Tobani, for one, found eslaught's post helpful: "I get what you are saying."
Furthermore, the most you are claiming now is only that eslaughts's post (even in its entirety, including the parts not relevant to this discussion) is just a little more complicated than yours. This is very different from your initial claim (despite your attempt to mis-characterize it as "conversational prose" when it contains an explicit argument attempting to establish a fact - see my recent post above.) Even if we consider the use of 'exponential' as misleading hyperbole, it is still a claim that any such alternative would be inordinately more complex. Therefore, the fact that you are now arguing for only a little more complexity is a tacit admission that you now realize your initial claim was mistaken.
Until you are ready to demonstrate some level of courage in your convictions, there is no point in me posting an alternative explanation here, only to have you willfully misrepresent it in the same way as you did for eslaught's post. If, however, some genuine third party joins in the discussion and requests it, I will be happy to present an alternative.
I wasn't ignoring it - it was irrelevant.
> This is very different from your initial claim
No it isn't - I never claimed anything about eslaught's post, directly or indirectly, before that.
> 'exponential' [...] it is still a claim that any such alternative would be inordinately more complex
You repeat this as often as you can, like it's somehow your only real point here. And every time, I point out that I made no such claim. The only claim I made was that your specific explanation (which you never actually wrote), which you said would include stack frames, machine addresses, and the like, would be much more complex than referring to C++, in my opinion.
You haven't refuted that, even though I am amused that you keep trying.
You also haven't changed my opinion, and as you can guess, I'm equally amused that you keep trying there too.
Continue, please.
A case in point: your attempt to claim that eslaught's explanation is irrelevant. Of course, it is not - characteristically, you have offered no counter to my explanation of how it gets directly to the point - and of course you were not thinking it was irrelevant when you tried to argue that it is marginally more complicated than your approach. Only after I pointed out that by doing so, you had tacitly admitted to a complete reversal of your position, did it occur to you that it was a mistake, and decided that you would have been better off claiming that the explanation is irrelevant, even though that claim won't stand up. So instead of expunging one of your inconsistencies, you have added another case where you contradict yourself in attempting to rewrite the record.
You also claim that this isn't what you were thinking of. Well, if you didn't think through the full scope and implications of what you were writing, that would be yet another mistake on your part, wouldn't it? We are, however, now entitled to wonder why, precisely, you think you can retrospectively rule this explanation out. As I wrote before, until you can demonstrate the integrity of committing to something definite that you will not attempt to rewrite later, there's no reason for me to post an explanation here.
> you had tacitly admitted to a complete reversal of your position
> until you can demonstrate the integrity of committing to something definite
My position has never changed, nor has my opinion. I still believe C++ was a useful analogy to the problem at hand (people misunderstanding Java references and pass-by-reference), and I still believe that any explanation involving machine addresses and stack frames that you could write (which you continue to refuse to do) would be more complex than comparing to C++.
If you care to take your umpteenth failed swing at that, go right ahead. I already know what's going to happen though. "Failed attempt at rhetoric, misrepresenting of opponent's position, arguing against the failed position".
I should advise you, though, that if you are going to keep wasting your own time flailing around in this thread, you should try to have a modicum of self-respect by sticking to what I say in your replies. Arguing against positions that don't exist may make you feel like you are getting somewhere, but really all you are doing is entertaining me.
But if that's your goal, and I'm misunderstanding you, then ignore the previous paragraph, and keep it coming :)
Once again, you attempt to rewrite the record, this time with a bland statement that you might now wish you had limited yourself to, but so long as you insist that you have not changed your mind on anything, then then I have the option to mention the various arguments you have offered for what was a much more emphatic position - to give just one example: "Sure you could do it that way. But it becomes exponentially more complicated because you need to either stick to one specific implementation of one specific language runtime, or you have to deal with explaining them all. Neither is ideal." That is not just "more complex", and it is not just an opinion, it contains an argument (an apparently faulty one, but an argument nevertheless.)
So long as you continue to deceptively misrepresent your former opinions and statements, there is no point in me posting an alternative here for it to be similarly misrepresented, but I will repeat my offer to do so if a third party gets involved.
As most of your last post was devoted, once again, to claiming (without any attempt at justification) that I don't have a leg to stand on, it seems negligent of you to omit making an attempt at a refutation of even one of the many points I have raised in the course of this thread - anyone would think that it is yourself who you are actually describing. I am sure it is just an oversight, so here's one example for you to tackle, left unanswered from the very post you were replying to: what do you think is wrong with eslaught's explanation?
Who said anything was wrong with it? All I ever said about it was this:
https://news.ycombinator.com/item?id=9393447
Which says nothing about it being wrong.
In fact, to back up my opinion that his post is slightly more complex, and perhaps harder to understand, here's a thread where I in fact use an even simpler explanation than eslaught's, and the person I was explaining this to still didn't get it. Even they brought up C++ to try to clarify their position, and it turns out that by doing so they actually ended up proving themselves wrong.
So in at least one concrete case, using C++ was actually better (more precise with fewer words and examples).
https://news.ycombinator.com/item?id=9248590
But I really did mean that I was entertained by watching you make stuff up and repeatedly fail at whatever your goal is, so by all means, don't stop now :)
Take, for example, "all I ever said about it was this". What you actually did was first make the claim you are now repeating, and then, when I pointed out that doing so completely contradicted your original position, you changed your mind and decided that Eslaught's explanation was irrelevant (https://news.ycombinator.com/item?id=9433742). Now that I have asked on what grounds you consider it to be irrelevant, you have circled back around to your original position, creating a lose-lose situation in which you have contradicted yourself regardless of what your actual opinion is.
You have reached the point of creating epicycles of contradictions within contradictions, as all this is going on within your larger contradiction of first claiming inordinate complexity of any alternative to your approach and then trying to rewrite that as being merely a claim that there is necessarily some slight increment in complexity in avoiding C++. Let's look again at what you actually wrote:
"Sure you could do it that way. But it becomes exponentially more complicated because you need to either stick to one specific implementation of one specific language runtime, or you have to deal with explaining them all." https://news.ycombinator.com/item?id=9266387
That is not a claim of just slightly more complexity, and the phrase following 'because' is an attempt to offer some sort of explanation for this claim. It is obvious to anyone that you have changed your mind on this, and you have never attempted to offer any justification for the 'because' phrase, but so long as you insist that you have not changed your mind, it is not unreasonable for me to point out that you are still wrong even after one more turn around the bowl.
Furthermore, in attempting to present an example, you are having a problem with logical quantifiers. Putting aside the absurdity of claiming to believe that this sorry dialog is simpler and more straightforward than Eslaught' straight-to-the-point paragraph (the first one in https://news.ycombinator.com/item?id=9249285), one example cannot establish the general claim you originally stated, and your attempt to do so is simply an error in logic.
I see that my goldfish analogy is not quite complete - your revolutions are getting faster and tighter. This is not so much the trajectory of a goldfish in a bowl as one being flushed down the toilet.
> I pointed out that doing so completely contradicted your original position
And I pointed out to you that I haven't contradicted myself.
Since you seem to have lost the thread, I'll help you out.
https://news.ycombinator.com/item?id=9486220
> It is obvious to anyone that you have changed your mind on this
I haven't changed my mind at all. Where did I say I have? Can you link to it for me please?
> I have asked on what grounds you consider it to be irrelevant
You didn't ask that. You asked "what do you think is wrong with eslaught's explanation?" I'll link you there too...
https://news.ycombinator.com/item?id=9549017
You keep using that word. I do not think it means what you think it means.
Looks like I was right about my prediction:
https://news.ycombinator.com/item?id=9486220
And try not to take so long to do it. I do so look forward to reading your ridiculous replies; you took so long on this past one that I thought you might have finally gotten some sense somewhere.
I'm glad I was wrong :)
This form of discourse, in which one party simply repeats back the claims of the other, as if they were applicable without having anything to support the reversal of attribution, might be called the "no, you are" style, on account of this being a phrase that is commonly used by its main adopters. As it happens, there is a video on that subject, and as you have repeatedly said how much amusement you get out of these exchanges, we can expect this will probably have you rolling on the floor: https://www.youtube.com/watch?v=ZRx8PFdurgo
With regard to more substantive matters, I think you should know that if you post a link to a claim that was made without any supporting evidence or justification, it does not magically gain those things in consequence. On the other hand, links that did have those things originally retain them, so we can see that your earlier statement
"Sure you could do it that way. But it becomes exponentially more complicated because you need to either stick to one specific implementation of one specific language runtime, or you have to deal with explaining them all." (https://news.ycombinator.com/item?id=9266387)
stands in contradiction to your later attempted rewrite
"The only claim I made was that your specific explanation (which you never actually wrote), which you said would include stack frames, machine addresses, and the like, would be much more complex than referring to C++, in my opinion." (https://news.ycombinator.com/item?id=9433742)
Just to be clear, you didn't try limiting it to a statement by me until after you had made the first statement and I pointed out its problems (https://news.ycombinator.com/item?id=9269186), and not even then, immediately. Only after I showed that you couldn't explain it away as 'conversation' did you try to rewrite it as in the second quote above.
more significantly, you have refused to offer any justification for the phrase "because you need to either stick to one specific implementation of one specific language runtime, or you have to deal with explaining them all", which Eslaught demonstrated to be false, while you are apparently still claiming never to have been wrong.
I repeat my statement that I will present an explanation once you show the courage of your convictions by saying what, in your opinion, is wrong with Eslaught's straight-to-the-point explanation:
"Except you still have no way to modify the variable binding on the caller's stack. This is what all of us in the "Java is call-by-value" camp keep yammering on about: changing a value on the heap (an array or object in Java) is not the same as changing a variable on the stack (a local variable in Java). In Java, you can never touch local variables on parent functions' stacks, therefore, Java cannot be considered pass-by-reference."
You are trying to wriggle out of dealing with this one by making a distinction between "wrong" and "invalid", an act of desperation which underscores that you have run out of ideas. If Eslaught's statement is invalid, then it is wrong as a refutation of your original statement, but you have no argument for that however you choose to put it.
Of course, it is utterly self-serving for someone who tried to dismiss one of his bigger mistakes as 'conversation' to be pedantic over usage now.
One of the more revealing things in your responses are the points you try to ignore. In my previous post I showed that you had made a fundamental error in logic, which you have ignored, so we can add it to the list of mistakes you haven't made. That said, even though your logical error means that the example you gave there is not relevant in the way you claimed, it is worth looking at. As you yourself point out, Solipsism introduces C++ into the discussion and messes it up. That's the best example you can offer of how C++ simplifies the explanation? Really? It's obvious to anyone just how self-serving your arguments are.
Given your copycat tendencies, can we anticipate a video in your next reply? And will it be self-referential? The one thing we can be sure of is that there will be another reply.
But I was wrong.
You are still going on about old crazy. You still think you can tell someone what their opinion should be, or that they shouldn't use phrases like "exponentially more complex" and "much more complex" without them being incorrectly and repeatedly accused of being contradictory.
And you still think that the confused folks in this thread understand the distinction between "local variable object references" and "the objects they reference", even though you yourself are referring to Solipsism's thread in which he does not understand that even after translating it to a language he is more familiar with?
Sorry mate. But don't despair, I'll give you one more shot. But bring some new crazy please, and shorten up your ramblings a bit.
Or I'm afraid I'm going to lose interest :(
And you return bearing a gift, in the form of your paragraph about Solipsism's comments. Firstly, you are making the logical error of trying to affirm a general claim with a specific instance. This means that the example cannot possibly settle the matter in your favor, but it can still do damage: your best example of the helpfulness of C++ in explaining Java argument-passing is a case where someone used C++ and got it wrong. This is risible, and your statement about Solipsism's familiarity with C++ only makes it more so. Thanks, JJ! While your act of self-implosion makes my opinion moot, I personally would advise Solipsism to read Eslaught's explanation, with special attention to the first paragraph of his last post (https://news.ycombinator.com/item?id=9249285)
Beyond that, I see you are again trying to rewrite this thread by repeating a couple of excuses that have already been effectively refuted: "it's just my opinion" and "it's just conversation."
You seem to think that calling a statement an opinion immunizes it from being wrong, but it doesn't work that way. An opinion (or set of them) that is self-contradictory is wrong, and similarly, so is an opinion that is contrary to established fact. These opinions are not even worth giving any further consideration; notable examples include flat- and hollow-earth theories, and creationism.
So, putting aside for the moment your self-serving attempt to have everything except your mistakes taken literally, even a 'conversational' reading of "Sure you could do it that way. But it becomes exponentially more complicated because you need to either stick to one specific implementation of one specific language runtime, or you have to deal with explaining them all" finds that you are claiming a stack-frame based explanation will necessarily be inordinately complicated, and even more so when read in its original context (including your precursor posts.) So when you judged (in what is surely a minority self-serving opinion) that Eslaught's explanation was only "slightly" more complex than a C++-based one, you tacitly admitted that your original 'opinion' doesn't hold water. As soon as I pointed out that you had done this, you changed your opinion of Eslaught's explanation, now claiming that it was invalid in some way. Not only was this itself a change in your stated opinion (and a dead giveaway that you knew this to be so), but you created a contradiction with your first evaluation of Eslaught's explanation: if it is being judged as slightly more complicated than the one you prefer, then it is has already passed muster (and nobody but you would question that, anyway.) This is just one more example of how your attempt to claim you have made no mistakes has led you into making more.
But the idea that you are merely presenting your opinion is itself an attempt to rewrite the record. Your original claim was to have made no mistakes, and you only tried to pass your mistakes off as opinion, and thereby claim for them an imaginary immunity from being evaluated, once you realized your factual claims did not stand up. For example, take the clause following "because" in the first quote above. In the context of its use (i.e, following "because"), it has only one purpose: you are presenting this as a basis in fact for your claim of complexity (and also perhaps that you meant 'exponentially' literally, even though it doesn't work as such; whether you are a reliable reporter of your opinions is an issue we will get to later (hint: you are not even a reliable reporter of what is in the record for all to see.)) The 'because' clause is a factual claim refuted by Eslaught, and this in turn shows that even if the cause before 'because' is taken 'conversationally', the statement as a whole is contrary to fact.
We can tell where you know you are wrong by your repeated avoidance of the issue, and the above "because" clause and Eslaught's explanation are two of the more blatant and repeated cases (the latter after your backfiring attempt to dismiss it.) Because we can see that you know you are wrong, and yet continue to insinuate that my refutations are faulty without daring to make definitive claims, we have to conclude that you are probably dissembling, which in turn means that we cannot necessarily take any of your statements about what your opinions were at face value, and can only go on what you wrote - which is the way it started anyway, despite your attempt to rewrite this discussion as one about your opinions.
I'll assume you are done dancing, given the continued weakening of your performance. But if I am mistaken, and you do abandon your current trajectory for something new and interesting, perhaps I'll come watch again.
It's a shame, because I did so enjoy your early work. Seeing someone adopt such an arrogant position, only to flail about for this long in a spectacular display of nothing at all... well schadenfreude is the word I would choose for it.
Don't give up.
On the subject of arguments, I see that this is the first time in I-can't-be-bothered-to-count that you have you have not tried to insinuate (without an actual argument) that the points I made in my preceding post are invalid (IIRC, the last time you tried an actual argument, it was the fiasco in which you ended up attempting to pass off 'slightly' as a conversational synonym for 'exponential'.) Could it be that you have finally realized what Mark Twain was going on about in his well-known aphorism about keeping quiet or removing doubt? Or, after having taken another turn around the bowl (https://news.ycombinator.com/item?id=9610430), will you once again repeat the same old insinuations that failed before? My money is on the latter.
If you are unsure where to start, may I suggest (once again) that you attempt an actual explanation (as opposed to either merely insinuating that there is an explanation to be found somewhere, or attempting to rewrite your original claims as something completely different) as to why you think Eslaught's explanation does not refute your original claim about the complexity of all stack-frame-based explanations?
In HotSpot references are double pointers (useful for moving GC), but in general it's up to JVM implementation. Pointers are one form of references, which are usually understood as machine addresses, but not all references have to be pointers.
Technical correctness is always best. Java is pass by value, and even variables holding object references are passed by value.
The article goes to great length to argue why Java should use the same terminology as other languages. I would not say that the statements:
Sun wanted to push Java as a secure language, and one of Java's advantages was that it does not allow pointer arithmetic as C++ does.
They went so far as to try a different name for the concept, formally calling them "references". A big mistake and it's caused even more confusion in the process.
can be called "actively trying to misunderstand people". In fact it shows an understanding with the position he's arguing against.
If I drove your grandmother BY a car, it would be totally different than driving her AS a car (logically: if your grandmother had wheels, then she'd be a car). In the same sense, passing the value of an object BY reference is totally different than passing a reference to an object AS a value.
Nobody's "actively trying to misunderstand people," because those people are already actively confused and insist on clinging to and spreading their shallow, incorrect definitions that directly contradict the Java language specification itself.
No matter how many times how many people patiently explain it to them in clear unambiguous terms, they still insist they're right and everyone else including the Java spec and James Gosling himself are wrong. Just look at all the ignorant postings in this thread by people like Mark Stock, Mark Hedley and Kevin Ryan, who just can't get it through their heads that they're wrong.
http://www.theserverside.com/discussions/thread.tss?thread_i...