Full stack web dev.
Studying FP web development approaches, while helping Mission Bit create paths to programming for underserved public school kids.
Previously @ Gradescope.
Call by sharing is sometimes called call by object too, for the reasons you mentioned.
The term call-by-value is problematic.
To be fair, it made more sense in the 60s. The distinction mattered when (a handful of) languages had call-by-reference semantics, but they're dead now. The hip thing nowadays is to be nominally call-by-value while also providing a way of passing around things that can reasonably be called references, a la carte.
It's similar to how variables are scoped in JS... mostly lexical, but with exceptions. But languages used to be all one way or all the other, and people forget to say "with exceptions."
The reasons feel similar to me as well. I think that in the early days, it was natural to think of variables as not much more than the memory addresses they started out as. But it's easier to reason about values directly, and over the years we've abstracted up towards that. In Clojure even the collections are immutable, and its creator distinguishes between values and place-oriented programming.
Full stack web dev.
Studying FP web development approaches, while helping Mission Bit create paths to programming for underserved public school kids.
Previously @ Gradescope.
Full stack web dev.
Studying FP web development approaches, while helping Mission Bit create paths to programming for underserved public school kids.
Previously @ Gradescope.
Yeah, it's funny to see the Python longhairs having the same argument as everyone else. FWIW I'm with Tim Peters:
"Joe, I think our son might be lost in the woods"
"Don't worry, I have his social security number"
i.e. we care about the object, not the references. This is important too:
in Python, the variables in the formal argument list are bound to the actual argument objects. the objects are shared between caller and callee; there are no "fresh locations" or extra "stores" involved.
So not only are the "values" mutable at a distance, the references aren't even copied.
I think you could argue that Clojure, where by default (a) everything is immutable and (b) values are copied*, is properly call-by-value. I might grudgingly toss C in there too, since pointers are first-class there and the abstraction around structs and arrays is thin.
Others might be CbV, in a narrow sense, but their emphasis on stateful/mutable/referenced things violate the spirit of it. Java at least has some primitives which I imagine need to get copied. Python doesn't even do that...
There's a bit in a book called Theoretical Introduction to Programming that applies here, I think:
... to say that int is integer arithmetic with bounds and overflow conditions is to say that it is not integer arithmetic.
Anyway, I agree with you that the OO languages are not CbR w/r/t objects (though I think they can be in spirit), and IMO you did a good job of explaining the history and the nuance.
i.e. we care about the object, not the references. This is important too:
Yes! This is super cool. Basically from my research I found out that Python, unlike Ruby and JavaScript, doesn't create a new "ref object" in the higher level language but actually directly assigns the reference, like C would.
Anyway, I agree with you that the OO languages are not CbR w/r/t objects (though I think they can be in spirit), and IMO you did a good job of explaining the history and the nuance.
❤❤ I also think you provide very valuable extra information!
I'm not very articulate at the moment but here is a meh response by me 😅 on the Python thang.
Python isn't really an exception, but yes, I understand what you're saying. Looking through the python source code, it seems again that it is mostly what we are trying to say when no reference is copied. The re-assignment in python is actually copying a reference, but indeed, no new memory need be allocated, for that reference -- sorta, because the identifier (name) still needs to live... inside the memory.
So even though Python doesn't "copy" the reference like JavaScript does (create a new JSVal that points to the same object), it does so on a waaaay lower level (point directly to the original same object).
Ugh. It's giving me a slight headache 😅😅😅.
However, there are actually quite a few (mostly older) languages that don't copy at all, which would be those languages that are not call by value/sharing/object :).
The most interesting to me are copy-restore languages or those theoretical ones that only copy on write... a topic for another time.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Call by sharing is sometimes called call by object too, for the reasons you mentioned.
To be fair, it made more sense in the 60s. The distinction mattered when (a handful of) languages had call-by-reference semantics, but they're dead now. The hip thing nowadays is to be nominally call-by-value while also providing a way of passing around things that can reasonably be called references, a la carte.
It's similar to how variables are scoped in JS... mostly lexical, but with exceptions. But languages used to be all one way or all the other, and people forget to say "with exceptions."
The reasons feel similar to me as well. I think that in the early days, it was natural to think of variables as not much more than the memory addresses they started out as. But it's easier to reason about values directly, and over the years we've abstracted up towards that. In Clojure even the collections are immutable, and its creator distinguishes between values and place-oriented programming.
This is absolutely true! I didn't mean the term itself is a problem, but it's causing confusion, in today's day and age.
I mean, most languages where it still exists, it's super clear when you use it (C#, PHP, sorta rust etc).
Thank you for the link! Some great content in there. I did not know this, but TIL.
whoops, I meant to write "languages had default call-by-reference semantics"
Yeah, it's funny to see the Python longhairs having the same argument as everyone else. FWIW I'm with Tim Peters:
i.e. we care about the object, not the references. This is important too:
So not only are the "values" mutable at a distance, the references aren't even copied.
I think you could argue that Clojure, where by default (a) everything is immutable and (b) values are copied*, is properly call-by-value. I might grudgingly toss C in there too, since pointers are first-class there and the abstraction around structs and arrays is thin.
Others might be CbV, in a narrow sense, but their emphasis on stateful/mutable/referenced things violate the spirit of it. Java at least has some primitives which I imagine need to get copied. Python doesn't even do that...
There's a bit in a book called Theoretical Introduction to Programming that applies here, I think:
Anyway, I agree with you that the OO languages are not CbR w/r/t objects (though I think they can be in spirit), and IMO you did a good job of explaining the history and the nuance.
* Clojure uses persistent data structures for collections, so technically those aren't 😑
Yes! This is super cool. Basically from my research I found out that Python, unlike Ruby and JavaScript, doesn't create a new "ref object" in the higher level language but actually directly assigns the reference, like C would.
❤❤ I also think you provide very valuable extra information!
I'm not very articulate at the moment but here is a meh response by me 😅 on the Python thang.
Valentin made a good comment and jmc went into more detail.
Valentin Baca
jmc
Python isn't really an exception, but yes, I understand what you're saying. Looking through the python source code, it seems again that it is mostly what we are trying to say when no reference is copied. The re-assignment in python is actually copying a reference, but indeed, no new memory need be allocated, for that reference -- sorta, because the identifier (name) still needs to live... inside the memory.
So even though Python doesn't "copy" the reference like JavaScript does (create a new JSVal that points to the same object), it does so on a waaaay lower level (point directly to the original same object).
Ugh. It's giving me a slight headache 😅😅😅.
However, there are actually quite a few (mostly older) languages that don't copy at all, which would be those languages that are not call by value/sharing/object :).
The most interesting to me are copy-restore languages or those theoretical ones that only copy on write... a topic for another time.