4 ms·

No, it isn't the same. I'm no language lawyer, but this is my understanding of it. In python, $foo is a reference. It might be a reference to a scalar value,

No, it isn't the same. I'm no language lawyer, but this is my understanding of it. In python, $foo is a reference. It might be a reference to a scalar value, or list, or hash, etc, but it is a reference. The code you wrote might cause confusion for people who don't understand the python model. In perl, $foo might be a scalar value, or it might be a reference to a value of some kind. Perl has this exact same type of problem demonstrated by your python code, but in addition it has the problem of "is $foo a scalar value or a reference?"

pflanze 7y ago
I think OP's point was that even in Python you have to be conscious where your "storage" is--that you're sharing it. Yes, the "Python" model (or Java, JavaScript) of referring to everything by reference is uniform and simple--except it still shares the issue of having to care if you add mutation into the mix. Due to its apparent smoothness it might even make it easier to run into that. In a sense Perl is honest here in saying I use local arrays via @ prefix and I know this array "lives here", like in the C/C++ world where you have to care about where the storage is so you don't pass references to stack objects etc.; in this world, when you take a reference, it's a heads-up that you may have to care about something. In Perl, unlike in C/C++, you don't have to care about memory safety, but you still, like in all imperative languages, you have to care about sharing of mutations. An explicit reference makes this explicit. If you return an array flat (without taking a reference) in Perl, it is being copied, and while that's slow, it is at least safe. It's an unclean solution for the issue, but in a sense it's at least pointing your head towards the issue. The clean solution for this is functional programming. Lisp was first to use a uniform "everything is a reference, implicitly" model. But it also preferred a functional programming model where you don't mutate your data structures. Java and Python took the reference model but mixed it with an imperative data update model. Meh. And I agree that I like the "just use references for everything implicitly" approach. But I also like to combine it with a functional one. And I ended up creating a project to achieve exactly that in Perl, and will shamelessly plug it here: https://metacpan.org/pod/FunctionalPerl https://metacpan.org/pod/FunctionalPerl (Code written in it co-exists with code that still uses non-reference variables, so feel free to argue that "now you have both worlds mixed", but for one it aims at existing Perl programmers who know how to deal with the non-reference model, and secondly functional programming matters most in the upper levels of an application; it's fine to use imperative code in inner loops / enclosed in an otherwise pure function, and it's fine to use array/hash variables there; FunctionalPerl comes in where you'd traditionally take a reference via `\`; so it's kind of a split between imperative and functional world now).
- pflanze 7y ago
  To make my own statement more complete/correct: > The clean solution for this is functional programming or another model that guarantees that modifications are never seen by code that isn't explicitly meant to receive them--the prominent other model that's making waves nowadays is of course linear types (and extensions as used by Rust).
jlokier 7y ago
Imho that's not really correct, or at least misleading. In Python, variable "foo" behaves like its value is a non-reference if the value is what some languages call "unboxed", for example numbers and strings. That's exactly the same as Perl. Technically, Python shares objects even in the case of numbers being copied around, and the object's address is visible with the "id()" function. (I emphasise address because that was a criticism of Perl in another comment, but everything in Python is memory with an address as well and the criticism ought to apply more strongly because even numbers need memory allocation.) However, the fact that numbers are immutably-shared when assigned in Python doesn't make their behaviour any different from numbers being assigned in Perl (apart from the obscure id()). It's hard to imagine what "problem" is created in Perl by the fact that numbers and strings are non-references. Most other languages do like Perl. With strings, Perl does both according to a performance heuristic: Sometimes it copies, sometimes it shares. This is completely safe because you can't tell the difference at language semantics level anyway.
- kevin_thibedeau 7y ago
  Numbers in Python are referenced objects. Low valued integers get reused to avoid the bloat of duplicate objects.

pflanze 7y ago

I think OP's point was that even in Python you have to be conscious where your "storage" is--that you're sharing it. Yes, the "Python" model (or Java, JavaScript) of referring to everything by reference is uniform and simple--except it still shares the issue of having to care if you add mutation into the mix. Due to its apparent smoothness it might even make it easier to run into that. In a sense Perl is honest here in saying I use local arrays via @ prefix and I know this array "lives here", like in the C/C++ world where you have to care about where the storage is so you don't pass references to stack objects etc.; in this world, when you take a reference, it's a heads-up that you may have to care about something. In Perl, unlike in C/C++, you don't have to care about memory safety, but you still, like in all imperative languages, you have to care about sharing of mutations. An explicit reference makes this explicit. If you return an array flat (without taking a reference) in Perl, it is being copied, and while that's slow, it is at least safe. It's an unclean solution for the issue, but in a sense it's at least pointing your head towards the issue. The clean solution for this is functional programming. Lisp was first to use a uniform "everything is a reference, implicitly" model. But it also preferred a functional programming model where you don't mutate your data structures. Java and Python took the reference model but mixed it with an imperative data update model. Meh. And I agree that I like the "just use references for everything implicitly" approach. But I also like to combine it with a functional one. And I ended up creating a project to achieve exactly that in Perl, and will shamelessly plug it here: https://metacpan.org/pod/FunctionalPerl https://metacpan.org/pod/FunctionalPerl (Code written in it co-exists with code that still uses non-reference variables, so feel free to argue that "now you have both worlds mixed", but for one it aims at existing Perl programmers who know how to deal with the non-reference model, and secondly functional programming matters most in the upper levels of an application; it's fine to use imperative code in inner loops / enclosed in an otherwise pure function, and it's fine to use array/hash variables there; FunctionalPerl comes in where you'd traditionally take a reference via `\`; so it's kind of a split between imperative and functional world now).

pflanze 7y ago
To make my own statement more complete/correct: > The clean solution for this is functional programming or another model that guarantees that modifications are never seen by code that isn't explicitly meant to receive them--the prominent other model that's making waves nowadays is of course linear types (and extensions as used by Rust).

jlokier 7y ago

Imho that's not really correct, or at least misleading. In Python, variable "foo" behaves like its value is a non-reference if the value is what some languages call "unboxed", for example numbers and strings. That's exactly the same as Perl. Technically, Python shares objects even in the case of numbers being copied around, and the object's address is visible with the "id()" function. (I emphasise address because that was a criticism of Perl in another comment, but everything in Python is memory with an address as well and the criticism ought to apply more strongly because even numbers need memory allocation.) However, the fact that numbers are immutably-shared when assigned in Python doesn't make their behaviour any different from numbers being assigned in Perl (apart from the obscure id()). It's hard to imagine what "problem" is created in Perl by the fact that numbers and strings are non-references. Most other languages do like Perl. With strings, Perl does both according to a performance heuristic: Sometimes it copies, sometimes it shares. This is completely safe because you can't tell the difference at language semantics level anyway.

kevin_thibedeau 7y ago
Numbers in Python are referenced objects. Low valued integers get reused to avoid the bloat of duplicate objects.