9 ms·

But Java isn't pass-by-reference. Saying so is simply wrong, for exactly the reasons you write off as "pedantry". I see this play out all the time with co-worke

But Java isn't pass-by-reference. Saying so is simply wrong, for exactly the reasons you write off as "pedantry". I see this play out all the time with co-workers who are new to Python (which has the same semantics) being very confused about why "numbers are passed by value but objects are passed by reference". Pedantry matters in our profession. Details have consequences.

lisper 9y ago
> But Java isn't pass-by-reference I didn't say it was. I said that insisting it is pass-by-value isn't helpful. The real problem here is that we have only two terms which we're using to try to distinguish between three different concepts.
- tonysdg 9y ago
  Personally, I'd argue there's only one concept -- pass-by-value -- with a whole lot of language-specific syntactic sugar as to what is getting passed by value. But I'll call myself out on that being even more pedantic than the current discussion.
  - seanmcdirmid 9y ago
    That sounds like Robert Harper’s argument that all languages are statically typed, it’s just that some languages only have one type.
    - twic 9y ago
      I've heard this term "unityped", but i'd always written it off as a politically correct way of saying "untyped". Is there actually a worthwhile argument for it? Having thought about it for a minute or two, it seems pretty silly to me . Types are all about restricting the set of values an expression can have, and restricting the set of operations you can perform on an expression, such that any operation you're allowed to perform on a value will always do something sensible. Untyped languages don't do that, which makes them quite different from typed languages. But then i've only thought about it for a minute or two. I could imagine a genuinely unityped language. Perhaps one where every value is a vector of real numbers with an infinite number of zeroes on the end, and the operations are piecewise arithmetic, dot products, interleaving, appending, etc. That would behave quite differently to the languages where you get "undefined is not a function" and friends.
      - qznc 9y ago
        Untyped languages actually allow you to perform any operation on any value and will always do something sensible. The sensible thing to do is to throw an exception in most cases.
        seanmcdirmid 9y ago
        The difference between safe dynamically typed and untyped is whether the throw will happen or not. There are degrees of safety even in dynamically typed languages.
        coldtea 9y ago
        Where by "safe dynamically type" you probably mean "strongly typed" (as eg Python).
      - clhodapp 9y ago
        I think the argument is that when every value inhabits the sole type and everything accepts that type, you get a system that works the way "untyped" languages do. Why have two separate concepts when you can gain some true conclusions by unifying? I think Harper would take issue with it being explained this way, but one can think of Ruby and Python being languages where everything is a pointer to a HashMap and everything else is just sugar on top of that (similar to the above argument about Java and the sugar with the pointers). I don't think Harper would like that way of explaining it because it's over-focused on an example instead of sticking to the concept and because it conflates (statically-knowable) types with (runtime) classes, which is big no-no with him.
      - edflsafoiewq 9y ago
        To a first approximation, a type is an equivalence class of expressions such that the set of valid programs is closed under substitution of one of these expressions for any other (compare with the definition of a part of speech in grammar). In a typical dynamic language, anywhere the syntax requires an expression, any expression will do, so there is only one equivalence class. This is in contrast to, say, Java, where (2/3) can be part of a valid program, but ("abc"/3) cannot, so 2 and "abc" cannot belong to the same equivalence class.
    - mannykannot 9y ago
      They might be similar in shifting the focus from terminology to semantics.
  - abritinthebay 9y ago
    Though you’re strictly correct. Honestly it’s a terminology problem. The whole “pass by x” really confuses things. It’s really more “represented by foo” underlying the passing that is important.
- mjburgess 9y ago
  There arent three concepts here. Dog d means "a pointer to a dog object" By forcing "pass-by-reference" to mean two things you are creating ambiguity that is trivially resolved by correctly interpreting a java type signature.
- Nokinside 9y ago
  It is because that's the definition of the term. You are insisting that the definition is changed. Emulating call-by-reference in a call-by-value environment does not change the semantics of the language. Just accept that the meaning you project to these terms is different from their real meanings. Don't try do redefine them and convince the rest of the world that your meaning is the right one.
  - masklinn 9y ago
    I think there is value in actually having a term for Java's (and Python's, and Ruby's, and Javascript's) argument-passing semantics, what was called "call by sharing" in CLU (and sometimes called pass-reference-by-value in some communities), because it's sufficiently different than either pass-by-reference or "full-fledged" pass-by-value that using these terms gets confusing, especially to people not learning them… which would be those you're using these with as the others have no issue understanding them. I do also think lisper is absolutely terrible at making that point.
    - Izkata 9y ago
      I like call-by-sharing. Every single one of these arguments between call-by-value and call-by-reference I've seen always fall apart because the arguers never accept that there's (at least) 3 forms of calling, whatever we want to call them. > and sometimes called pass-reference-by-value in some communities Or call-by-value-of-reference. It's too much of a mouthful, but is the usual alternative I hear.
  - zzzcpan 9y ago
    There cannot be a real meaning or a right meaning, only an agreed upon meaning. And the rest of the world first have to agree on that meaning. But there is no agreement so far. Furthermore, the term is so useless, that most people only encounter it in debates about its meaning.
    - mark-r 9y ago
      There can be an original meaning. The idea of hiding pointers and not allowing them to be reasoned about separate from the objects they point to is a relatively new invention. The terms "pass by value" and "pass by reference" predate that invention.
- danbruc 9y ago
  If I correctly understand what you are referring to, then there are four variants, not three. And those four variants are the product of two orthogonal binary choices and we have names for all of them. There are value types and references types and you can pass each of them by value or by reference for a total of four variants. There are of course actually even more variants, but they are not really relevant for the discussion at hand.
  - lisper 9y ago
    > those four variants are the product of two orthogonal binary choices and we have names for all of them Yes, but the two variants that matter most are both pass-by-value. There is not a single language in common use today that is pass-by-reference by default. In fact, only C++ (and Pascal, but who uses Pascal any more?) even allows this as an option.
    - danbruc 9y ago
      Yes, but the two variants that matter most are both pass-by-value. And they are perfectly distinguished by being value types or reference types.
      - deleted 9y ago
        [deleted]
    - SigmundA 9y ago
      C# allows all four variants but does default to pass by value.
- kbp 9y ago
  > The real problem here is that we have only two terms which we're using to try to distinguish between three different concepts. It's still only two concepts, there's just the side effect of Java and friends' implicit pointers that makes things muddier. The Java function void swap(Object x, Object y) { Object temp = x; x = y; y = temp; } is equivalent to the C program void swap(void *x, void *y) { void *temp = x; x = y; y = temp; } and it has the same bug for the same reason. It's only the implicit nature of references in languages like Java that makes it not look like pass by value, but that implicit nature is there in other places as well (eg, the Java code 'Object x = y' is equivalent to the C code 'void *x = y'). I think the best approach is to just call it what it is, pass by value, and then also remind people if need be that objects are always pointers so it's passing a pointer by value.
  - lisper 9y ago
    > I think the best approach is to just call it what it is, pass by value I respectfully disagree. Pointers are part of the Java implementation, not part of its abstract computational model. Calling it pass-by-value when the values being passed are deliberately hidden from the user is a recipe for confusion.
    - deleted 9y ago
      [deleted]
    - kbp 9y ago
      > Pointers are part of the Java implementation, not part of its abstract computational model. Calling it pass-by-value when the values being passed are deliberately hidden from the user is a recipe for confusion. Its abstract computation model is entirely equivalent to if someone did `typedef object_val *Object`, made `.` do the same thing as `->` and got rid of `->`, and then said you could only have `Object` variables, not `object_val`s. Saying that that's enough to make it not pass-by-value anymore seems ridiculous (especially when Java does still have primitives). If that were enough to make it something else, then following a style guide for C could make your code not pass-by-value anymore. I understand what you're saying about the helpfulness to learners, but I think that they would be better served by just learning that Java classes are all reference types, their value is a reference to an object that '.' dereferences and so on, and that even if you don't want to use the word 'pointer', they happen to behave exactly like pointers. The reason I think that's better is because it also covers other common mistakes, like initializing multiple variables to the same instance and expecting copy semantics. The same mistake is being made in both that and the swap function from earlier, but the term 'pass-by-value' could only be to blame for one of them. Once you have your head around reference types, there's no problem with calling it 'pass-by-value'.
tonysdg 9y ago
I'll second this. As someone who spends most of their time flipping between C and Python, the details of how parameters get passed between functions is intimately related to each language, and keeping it all clear meant having to understand the nuances. Plus, I'd argue it's a lot easier to teach the nuances from the beginning rather than have to break someone's assumptions 4 years down the line (e.g. the traditional time of an undergrad CS education).
lmm 9y ago
> But Java isn't pass-by-reference. Yes it is. The thing that we talk about when we talk about "the value of foo", in Java, is passed by reference.
- lisper 9y ago
  > > But Java isn't pass-by-reference. > Yes it is. And this is my point in a nutshell. This argument will never be resolved, and so continuing to argue over it isn't helpful no matter how hard you pound your fist on the table.
  - colanderman 9y ago
    The argument is resolved pretty simply by considering that the term "pass-by-reference" was defined well before Java even existed, and that Java does not exhibit behavior required of that calling style. (In Java, you cannot change a variable in the caller's scope to point to a different object.) Java is demonstrably not pass-by-reference. But don't take my word for it. Pass-by-reference was understood by the person who invented the calling style used in Java (Barbara Liskov) not to apply to that calling style. [1] The argument was resolved before it could even be had, 44 years ago. [1] https://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_sharing https://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_sh...
    - esrauch 9y ago
      Java is also demonstratably not pass-by-value (for objects). It is a false dichotomy to prove it is one by proving it is not the other.
- mbrock 9y ago
  You might think that the value of foo is that which is compared when evaluating foo == bar, which is a pointer!
  - lmm 9y ago
    > You might think that the value of foo is that which is compared when evaluating foo == bar Few if any working Java programmers do think like that though. Like, if you have String x and String y, and println(x); prints "foo" and println(y) prints "foo" and x != y (a perfectly ordinary situation to get into in Java), we would still say "the value of x is "foo"".
coldtea 9y ago
>Pedantry matters in our profession. Details have consequences. Well, if so, even more reason NOT to say "Java is Pass-by-Value". Instead, you should be a good pedant, and explain the Java passing model, its caveats and edge cases, in its entirety. If details matter, don't throw some BS blanket statement like "Java is Pass-by-Value" around, that can be misinterpreted in 200 ways, and that doesn't capture the whole nuances of what's going on.
- colanderman 9y ago
  As I said elsewhere in this thread, personally I use the term "pass-by-pointer-value". Barbara Liskov used the term "pass-by-sharing" (actually "call-by-sharing") when she invented the damn thing in 1974. [1] "Pass-by-reference" is simply wrong, as it implies behavior which Java does not exhibit. [1] https://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_sharing https://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_sh...
  - coldtea 9y ago
    >As I said elsewhere in this thread, personally I use the term "pass-by-pointer-value" Well, that doesn't apply exactly to ints and longs though...
- haglin 9y ago
  You need a controversial title, or the topic will be ignored and not discussed here.
zephyrfalcon 9y ago
OK, but in Python this isn't actually true... numbers are not passed any differently than other kinds of objects. As such, it does not have the same semantics as Java, which does distinguish between primitives and non-primitives. Of course, this kind of discussion isn't new to the Python community either. The actual calling convention is somewhere between call by value and call by reference, sometimes called "call by object". This is well worth reading: http://effbot.org/zone/call-by-object.htm http://effbot.org/zone/call-by-object.htm
- colanderman 9y ago
  No, Java makes no such distinction in passing. Java does have values which are not object pointers, but, just like object pointers, they are passed by value, and behave exactly the same as an immutable object in either language.

lisper 9y ago

> But Java isn't pass-by-reference I didn't say it was. I said that insisting it is pass-by-value isn't helpful. The real problem here is that we have only two terms which we're using to try to distinguish between three different concepts.

tonysdg 9y ago
Personally, I'd argue there's only one concept -- pass-by-value -- with a whole lot of language-specific syntactic sugar as to what is getting passed by value. But I'll call myself out on that being even more pedantic than the current discussion.
- seanmcdirmid 9y ago
  That sounds like Robert Harper’s argument that all languages are statically typed, it’s just that some languages only have one type.
  - twic 9y ago
    I've heard this term "unityped", but i'd always written it off as a politically correct way of saying "untyped". Is there actually a worthwhile argument for it? Having thought about it for a minute or two, it seems pretty silly to me . Types are all about restricting the set of values an expression can have, and restricting the set of operations you can perform on an expression, such that any operation you're allowed to perform on a value will always do something sensible. Untyped languages don't do that, which makes them quite different from typed languages. But then i've only thought about it for a minute or two. I could imagine a genuinely unityped language. Perhaps one where every value is a vector of real numbers with an infinite number of zeroes on the end, and the operations are piecewise arithmetic, dot products, interleaving, appending, etc. That would behave quite differently to the languages where you get "undefined is not a function" and friends.
    - qznc 9y ago
      Untyped languages actually allow you to perform any operation on any value and will always do something sensible. The sensible thing to do is to throw an exception in most cases.
      - seanmcdirmid 9y ago
        The difference between safe dynamically typed and untyped is whether the throw will happen or not. There are degrees of safety even in dynamically typed languages.
        coldtea 9y ago
        Where by "safe dynamically type" you probably mean "strongly typed" (as eg Python).
    - clhodapp 9y ago
      I think the argument is that when every value inhabits the sole type and everything accepts that type, you get a system that works the way "untyped" languages do. Why have two separate concepts when you can gain some true conclusions by unifying? I think Harper would take issue with it being explained this way, but one can think of Ruby and Python being languages where everything is a pointer to a HashMap and everything else is just sugar on top of that (similar to the above argument about Java and the sugar with the pointers). I don't think Harper would like that way of explaining it because it's over-focused on an example instead of sticking to the concept and because it conflates (statically-knowable) types with (runtime) classes, which is big no-no with him.
    - edflsafoiewq 9y ago
      To a first approximation, a type is an equivalence class of expressions such that the set of valid programs is closed under substitution of one of these expressions for any other (compare with the definition of a part of speech in grammar). In a typical dynamic language, anywhere the syntax requires an expression, any expression will do, so there is only one equivalence class. This is in contrast to, say, Java, where (2/3) can be part of a valid program, but ("abc"/3) cannot, so 2 and "abc" cannot belong to the same equivalence class.
  - mannykannot 9y ago
    They might be similar in shifting the focus from terminology to semantics.
- abritinthebay 9y ago
  Though you’re strictly correct. Honestly it’s a terminology problem. The whole “pass by x” really confuses things. It’s really more “represented by foo” underlying the passing that is important.
mjburgess 9y ago
There arent three concepts here. Dog d means "a pointer to a dog object" By forcing "pass-by-reference" to mean two things you are creating ambiguity that is trivially resolved by correctly interpreting a java type signature.
Nokinside 9y ago
It is because that's the definition of the term. You are insisting that the definition is changed. Emulating call-by-reference in a call-by-value environment does not change the semantics of the language. Just accept that the meaning you project to these terms is different from their real meanings. Don't try do redefine them and convince the rest of the world that your meaning is the right one.
- masklinn 9y ago
  I think there is value in actually having a term for Java's (and Python's, and Ruby's, and Javascript's) argument-passing semantics, what was called "call by sharing" in CLU (and sometimes called pass-reference-by-value in some communities), because it's sufficiently different than either pass-by-reference or "full-fledged" pass-by-value that using these terms gets confusing, especially to people not learning them… which would be those you're using these with as the others have no issue understanding them. I do also think lisper is absolutely terrible at making that point.
  - Izkata 9y ago
    I like call-by-sharing. Every single one of these arguments between call-by-value and call-by-reference I've seen always fall apart because the arguers never accept that there's (at least) 3 forms of calling, whatever we want to call them. > and sometimes called pass-reference-by-value in some communities Or call-by-value-of-reference. It's too much of a mouthful, but is the usual alternative I hear.
- zzzcpan 9y ago
  There cannot be a real meaning or a right meaning, only an agreed upon meaning. And the rest of the world first have to agree on that meaning. But there is no agreement so far. Furthermore, the term is so useless, that most people only encounter it in debates about its meaning.
  - mark-r 9y ago
    There can be an original meaning. The idea of hiding pointers and not allowing them to be reasoned about separate from the objects they point to is a relatively new invention. The terms "pass by value" and "pass by reference" predate that invention.
danbruc 9y ago
If I correctly understand what you are referring to, then there are four variants, not three. And those four variants are the product of two orthogonal binary choices and we have names for all of them. There are value types and references types and you can pass each of them by value or by reference for a total of four variants. There are of course actually even more variants, but they are not really relevant for the discussion at hand.
- lisper 9y ago
  > those four variants are the product of two orthogonal binary choices and we have names for all of them Yes, but the two variants that matter most are both pass-by-value. There is not a single language in common use today that is pass-by-reference by default. In fact, only C++ (and Pascal, but who uses Pascal any more?) even allows this as an option.
  - danbruc 9y ago
    Yes, but the two variants that matter most are both pass-by-value. And they are perfectly distinguished by being value types or reference types.
    - deleted 9y ago
      [deleted]
  - SigmundA 9y ago
    C# allows all four variants but does default to pass by value.
kbp 9y ago
> The real problem here is that we have only two terms which we're using to try to distinguish between three different concepts. It's still only two concepts, there's just the side effect of Java and friends' implicit pointers that makes things muddier. The Java function void swap(Object x, Object y) { Object temp = x; x = y; y = temp; } is equivalent to the C program void swap(void *x, void *y) { void *temp = x; x = y; y = temp; } and it has the same bug for the same reason. It's only the implicit nature of references in languages like Java that makes it not look like pass by value, but that implicit nature is there in other places as well (eg, the Java code 'Object x = y' is equivalent to the C code 'void *x = y'). I think the best approach is to just call it what it is, pass by value, and then also remind people if need be that objects are always pointers so it's passing a pointer by value.
- lisper 9y ago
  > I think the best approach is to just call it what it is, pass by value I respectfully disagree. Pointers are part of the Java implementation, not part of its abstract computational model. Calling it pass-by-value when the values being passed are deliberately hidden from the user is a recipe for confusion.
  - deleted 9y ago
    [deleted]
  - kbp 9y ago
    > Pointers are part of the Java implementation, not part of its abstract computational model. Calling it pass-by-value when the values being passed are deliberately hidden from the user is a recipe for confusion. Its abstract computation model is entirely equivalent to if someone did `typedef object_val *Object`, made `.` do the same thing as `->` and got rid of `->`, and then said you could only have `Object` variables, not `object_val`s. Saying that that's enough to make it not pass-by-value anymore seems ridiculous (especially when Java does still have primitives). If that were enough to make it something else, then following a style guide for C could make your code not pass-by-value anymore. I understand what you're saying about the helpfulness to learners, but I think that they would be better served by just learning that Java classes are all reference types, their value is a reference to an object that '.' dereferences and so on, and that even if you don't want to use the word 'pointer', they happen to behave exactly like pointers. The reason I think that's better is because it also covers other common mistakes, like initializing multiple variables to the same instance and expecting copy semantics. The same mistake is being made in both that and the swap function from earlier, but the term 'pass-by-value' could only be to blame for one of them. Once you have your head around reference types, there's no problem with calling it 'pass-by-value'.

tonysdg 9y ago

I'll second this. As someone who spends most of their time flipping between C and Python, the details of how parameters get passed between functions is intimately related to each language, and keeping it all clear meant having to understand the nuances. Plus, I'd argue it's a lot easier to teach the nuances from the beginning rather than have to break someone's assumptions 4 years down the line (e.g. the traditional time of an undergrad CS education).

lmm 9y ago

> But Java isn't pass-by-reference. Yes it is. The thing that we talk about when we talk about "the value of foo", in Java, is passed by reference.

lisper 9y ago
> > But Java isn't pass-by-reference. > Yes it is. And this is my point in a nutshell. This argument will never be resolved, and so continuing to argue over it isn't helpful no matter how hard you pound your fist on the table.
- colanderman 9y ago
  The argument is resolved pretty simply by considering that the term "pass-by-reference" was defined well before Java even existed, and that Java does not exhibit behavior required of that calling style. (In Java, you cannot change a variable in the caller's scope to point to a different object.) Java is demonstrably not pass-by-reference. But don't take my word for it. Pass-by-reference was understood by the person who invented the calling style used in Java (Barbara Liskov) not to apply to that calling style. [1] The argument was resolved before it could even be had, 44 years ago. [1] https://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_sharing https://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_sh...
  - esrauch 9y ago
    Java is also demonstratably not pass-by-value (for objects). It is a false dichotomy to prove it is one by proving it is not the other.
mbrock 9y ago
You might think that the value of foo is that which is compared when evaluating foo == bar, which is a pointer!
- lmm 9y ago
  > You might think that the value of foo is that which is compared when evaluating foo == bar Few if any working Java programmers do think like that though. Like, if you have String x and String y, and println(x); prints "foo" and println(y) prints "foo" and x != y (a perfectly ordinary situation to get into in Java), we would still say "the value of x is "foo"".

coldtea 9y ago

>Pedantry matters in our profession. Details have consequences. Well, if so, even more reason NOT to say "Java is Pass-by-Value". Instead, you should be a good pedant, and explain the Java passing model, its caveats and edge cases, in its entirety. If details matter, don't throw some BS blanket statement like "Java is Pass-by-Value" around, that can be misinterpreted in 200 ways, and that doesn't capture the whole nuances of what's going on.

colanderman 9y ago
As I said elsewhere in this thread, personally I use the term "pass-by-pointer-value". Barbara Liskov used the term "pass-by-sharing" (actually "call-by-sharing") when she invented the damn thing in 1974. [1] "Pass-by-reference" is simply wrong, as it implies behavior which Java does not exhibit. [1] https://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_sharing https://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_sh...
- coldtea 9y ago
  >As I said elsewhere in this thread, personally I use the term "pass-by-pointer-value" Well, that doesn't apply exactly to ints and longs though...
haglin 9y ago
You need a controversial title, or the topic will be ignored and not discussed here.

zephyrfalcon 9y ago

OK, but in Python this isn't actually true... numbers are not passed any differently than other kinds of objects. As such, it does not have the same semantics as Java, which does distinguish between primitives and non-primitives. Of course, this kind of discussion isn't new to the Python community either. The actual calling convention is somewhere between call by value and call by reference, sometimes called "call by object". This is well worth reading: http://effbot.org/zone/call-by-object.htm http://effbot.org/zone/call-by-object.htm

colanderman 9y ago
No, Java makes no such distinction in passing. Java does have values which are not object pointers, but, just like object pointers, they are passed by value, and behave exactly the same as an immutable object in either language.