9 ms·

> If an object is just there to store data and no behaviour, then that's fine - don't add behaviour if it doesn't need it. In that case, you want values rather

> If an object is just there to store data and no behaviour, then that's fine - don't add behaviour if it doesn't need it. In that case, you want values rather than objects. Alas, Python doesn't have compound values.

sevensor 10y ago
As tantalor reminds us in a sibling comment, the named tuple works nicely in this role.
- catnaroek 10y ago
  All you need to do is use the `is` operator to see how even tuples (named or otherwise) are objects, not values.
  - in_the_sticks 10y ago
    That's a useless distinction. Everything is an object in Python. Does that mean Python doesn't have values?
    - catnaroek 10y ago
      It has primitive values: (0) small enough numbers (1) True, False, None, etc. (2) object references But it doesn't have compound values. And the distinction isn't useless. Values have a richer equational theory than objects, enabling lots of automatic optimizations.
      - qwertyuiop924 10y ago
        ...And outside FP, nobody cares, or uses that definition of value. As noted in my above post.
        catnaroek 10y ago
        It's useful when writing Prolog programs too.
        qwertyuiop924 10y ago
        Logic programming's actually pretty close to FP.
        catnaroek 10y ago
        Not really. Prolog is first-order. Functional languages, just like object-oriented ones, are higher-order.
        qwertyuiop924 10y ago
        "Close," not "is."
        catnaroek 10y ago
        There's very little in common, beyond the notions of mathematical variable and value. Syntactically, a functional program is an expression, but a logic program is a proposition. Operationally, functional programs run already constructed proofs, but logic programs search for proofs. Pragmatically, transcribing a logic program into a functional language or vice versa is difficult without effectively writing an interpreter for an embedded DSL. Or maybe by “close”, you mean “both are about equally difficult to wrap my head around”?
        qwertyuiop924 10y ago
        Don't mock me. And yes, I did mean the notion of mathematical value and variable. That's one of the core tenets of both.
        catnaroek 10y ago
  - sevensor 10y ago
    While that's a good point, the namedtuple is value-like enough to address the "anemic objects" problem. Could you expand on the advantages of this: (a, b, c) is (a, b, c) being True instead of False?
    - catnaroek 10y ago
      The runtime system's memory manager could automatically hash-cons equal compound values, reducing their memory footprint. It's like the flyweight pattern, except the runtime system gives it to you for free.
      - sevensor 10y ago
        I agree that's nice for memory use. It's totally consistent with the immutability of tuples, too. I suppose Python has elected to take the memory hit to reduce complexity in the interpreter?
        catnaroek 10y ago
        As things stand now, the main reason why Python can't do it is because it could potentially break programs.
        dragonwriter 10y ago
        > As things stand now, the main reason why Python can't do it is because it could potentially break programs. Since the documented behavior of Python is compatible with what is suggested as a change, any program that relies on the behavior not reflecting as described in the "change" is asking to be broken (and quite possibly already broken across different implementations -- including different versions of the same implementation.) Immutable types in python already are defined with the semantics of values, in that "for immutable types, operations that compute new values may actually return a reference to any existing object with the same type and value, while for mutable objects this is not allowed." [0] [0] https://docs.python.org/2/reference/datamodel.html https://docs.python.org/2/reference/datamodel.html
  - dragonwriter 10y ago
    > All you need to do is use the `is` operator to see how even tuples (named or otherwise) are objects, not values. That is not language feature of Python but an implementation detail. Python implementations are permitted (but not required) to intern any immutable value (which tuples, contrary to your description, are), and "is" is a mechanism for revealing what the implementation has done. You seem to be equivocating between talk of values as a logical thing (where Python absolutely has compound values, including tuples) and as an implementation feature (where individual Python implementations may or may not implement certain logical values through interning.)
    - catnaroek 10y ago
      > That is not language feature of Python but an implementation detail. So you're saying that the behavior of the `is` operator is implementation-defined? > values as a logical thing (where Python absolutely has compound values, including tuples) The (informal, unspecified) metalanguage that you're using to reason about Python programs has compound values. Python itself doesn't.
      - dragonwriter 10y ago
        > So you're saying that the behavior of the `is` operator is implementation-defined? No, the behavior has a standard definition: it reveals whether the operands refer to the same in-memory construct. Whether immutable values are stored in the same in-memory construct is, however, AIUI, implementation dependent.
        catnaroek 10y ago
        > Whether immutable values are stored in the same in-memory construct is, however, AIUI, implementation dependent. If I can't bind it to a variable, it isn't a value. You can't bind the list [1,2,3] to a variable, because Python has no such thing as the list [1,2,3].
        dragonwriter 10y ago
qwertyuiop924 10y ago
Please stop it. Every single time anything so much as slightly related comes up, you talk about compound object. Incessantly. And then you act superior when nobody knows what you mean, or cares about compound values. They're not really relevant to this discussion anyways, as storing data as desribed in GPP is perfectly reasonable. The worst part is, your definition of "value" and "object" in this context is so far out of the ordinary that people should be expected to not understand it, and you should provide an explanation pre-emptively. To quote Randall Munroe, "Communicating badly and then acting smug when you're misunderstood is not cleverness"
- catnaroek 10y ago
  It's relevant. If it weren't, there wouldn't be a debate regarding the usefulness of behaviorless objects.
  - qwertyuiop924 10y ago
    Well than FFS express yourself clearly.
    - catnaroek 10y ago
      Nobody other than an object-oriented programmer would think a value is something that evolves over time.
      - cjslep 10y ago
        >Nobody other than an object-oriented programmer would think a value is something that evolves over time. I don't think you fully read qwertyuiop924's post to get to the Randall Munroe quote, which makes this comment priceless.
      - emodendroket 10y ago
        Given that "object-oriented programmer" probably constitutes most of the people here you ought to know your audience and explain what you mean to say.
dragonwriter 10y ago
> In that case, you want values rather than objects. In dynamic OOP languages, value/object distinctions are often not exposed to the language user (they may actually exist in the underlying implementation, but from the PoV of the programmer using the language, there may be no discernible distinction between an "immutable object" and "value".) Conceptually (and ignoring the implementation details, which may have performance implications), immutable objects are equivalent to values, anyhow.
- catnaroek 10y ago
  > Conceptually ... immutable objects are equivalent to values, anyhow. Nope. Since values don't reside in computer memory other than through their representations, the language implementation (compiler, runtime system, etc.) is free to apply optimizations such as: (0) Determine whether a value is represented more than once in memory, and eliminate the redundant representations. (1) Store multiple values in a single dynamically allocated memory block. If object identities matter, all of this is unsound. > ... (and ignoring the implementation details, which may have performance implications), ... The performance implications can be constrained by equipping the language with a cost semantics.
  - deleted 10y ago
    [deleted]
unlogic 10y ago
It's funny how catnaroek was completely vendetta-downvoted in this thread for speaking valid things. For those who don't understand the difference between objects and values, this video may be of help: https://www.youtube.com/watch?v=-6BsiVyC1kM https://www.youtube.com/watch?v=-6BsiVyC1kM
dang 10y ago
I'm not sure what the dynamic is behind this weird flamewar, but it's definitely not the sort of discussion we want on HN, and your comments seem, presumably unintentionally, to have trolling effects. Please don't do this here. We detached this subthread from https://news.ycombinator.com/item?id=12358875 https://news.ycombinator.com/item?id=12358875 and marked it off-topic.
- catnaroek 10y ago
  > and your comments seem, presumably unintentionally, to have trolling effects. I have no idea why stating facts would constitute “trolling”. But, anyway.
  - dang 10y ago
    I agree that it's strange, but the discussion has gone badly, and it has something to do with how you engage people. That's what I mean by unintentional trolling.
  - dllthomas 10y ago
    It's entirely possible to communicate other things while - first order - only stating uncontroversial facts. What, you don't think your shop is nice? You don't think it would be a shame if something happened to it? Given that, it's also entirely possible for people to perceive other things as communicated in cases where there's maybe not the intent.

sevensor 10y ago

As tantalor reminds us in a sibling comment, the named tuple works nicely in this role.

catnaroek 10y ago
All you need to do is use the `is` operator to see how even tuples (named or otherwise) are objects, not values.
- in_the_sticks 10y ago
  That's a useless distinction. Everything is an object in Python. Does that mean Python doesn't have values?
  - catnaroek 10y ago
    It has primitive values: (0) small enough numbers (1) True, False, None, etc. (2) object references But it doesn't have compound values. And the distinction isn't useless. Values have a richer equational theory than objects, enabling lots of automatic optimizations.
    - qwertyuiop924 10y ago
      ...And outside FP, nobody cares, or uses that definition of value. As noted in my above post.
      - catnaroek 10y ago
        It's useful when writing Prolog programs too.
        qwertyuiop924 10y ago
        Logic programming's actually pretty close to FP.
        catnaroek 10y ago
        Not really. Prolog is first-order. Functional languages, just like object-oriented ones, are higher-order.
        qwertyuiop924 10y ago
        "Close," not "is."
        catnaroek 10y ago
        There's very little in common, beyond the notions of mathematical variable and value. Syntactically, a functional program is an expression, but a logic program is a proposition. Operationally, functional programs run already constructed proofs, but logic programs search for proofs. Pragmatically, transcribing a logic program into a functional language or vice versa is difficult without effectively writing an interpreter for an embedded DSL. Or maybe by “close”, you mean “both are about equally difficult to wrap my head around”?
        qwertyuiop924 10y ago
        Don't mock me. And yes, I did mean the notion of mathematical value and variable. That's one of the core tenets of both.
        catnaroek 10y ago
- sevensor 10y ago
  While that's a good point, the namedtuple is value-like enough to address the "anemic objects" problem. Could you expand on the advantages of this: (a, b, c) is (a, b, c) being True instead of False?
  - catnaroek 10y ago
    The runtime system's memory manager could automatically hash-cons equal compound values, reducing their memory footprint. It's like the flyweight pattern, except the runtime system gives it to you for free.
    - sevensor 10y ago
      I agree that's nice for memory use. It's totally consistent with the immutability of tuples, too. I suppose Python has elected to take the memory hit to reduce complexity in the interpreter?
      - catnaroek 10y ago
        As things stand now, the main reason why Python can't do it is because it could potentially break programs.
        dragonwriter 10y ago
        > As things stand now, the main reason why Python can't do it is because it could potentially break programs. Since the documented behavior of Python is compatible with what is suggested as a change, any program that relies on the behavior not reflecting as described in the "change" is asking to be broken (and quite possibly already broken across different implementations -- including different versions of the same implementation.) Immutable types in python already are defined with the semantics of values, in that "for immutable types, operations that compute new values may actually return a reference to any existing object with the same type and value, while for mutable objects this is not allowed." [0] [0] https://docs.python.org/2/reference/datamodel.html https://docs.python.org/2/reference/datamodel.html
- dragonwriter 10y ago
  > All you need to do is use the `is` operator to see how even tuples (named or otherwise) are objects, not values. That is not language feature of Python but an implementation detail. Python implementations are permitted (but not required) to intern any immutable value (which tuples, contrary to your description, are), and "is" is a mechanism for revealing what the implementation has done. You seem to be equivocating between talk of values as a logical thing (where Python absolutely has compound values, including tuples) and as an implementation feature (where individual Python implementations may or may not implement certain logical values through interning.)
  - catnaroek 10y ago
    > That is not language feature of Python but an implementation detail. So you're saying that the behavior of the `is` operator is implementation-defined? > values as a logical thing (where Python absolutely has compound values, including tuples) The (informal, unspecified) metalanguage that you're using to reason about Python programs has compound values. Python itself doesn't.
    - dragonwriter 10y ago
      > So you're saying that the behavior of the `is` operator is implementation-defined? No, the behavior has a standard definition: it reveals whether the operands refer to the same in-memory construct. Whether immutable values are stored in the same in-memory construct is, however, AIUI, implementation dependent.
      - catnaroek 10y ago
        > Whether immutable values are stored in the same in-memory construct is, however, AIUI, implementation dependent. If I can't bind it to a variable, it isn't a value. You can't bind the list [1,2,3] to a variable, because Python has no such thing as the list [1,2,3].
        dragonwriter 10y ago

qwertyuiop924 10y ago

Please stop it. Every single time anything so much as slightly related comes up, you talk about compound object. Incessantly. And then you act superior when nobody knows what you mean, or cares about compound values. They're not really relevant to this discussion anyways, as storing data as desribed in GPP is perfectly reasonable. The worst part is, your definition of "value" and "object" in this context is so far out of the ordinary that people should be expected to not understand it, and you should provide an explanation pre-emptively. To quote Randall Munroe, "Communicating badly and then acting smug when you're misunderstood is not cleverness"

catnaroek 10y ago
It's relevant. If it weren't, there wouldn't be a debate regarding the usefulness of behaviorless objects.
- qwertyuiop924 10y ago
  Well than FFS express yourself clearly.
  - catnaroek 10y ago
    Nobody other than an object-oriented programmer would think a value is something that evolves over time.
    - cjslep 10y ago
      >Nobody other than an object-oriented programmer would think a value is something that evolves over time. I don't think you fully read qwertyuiop924's post to get to the Randall Munroe quote, which makes this comment priceless.
    - emodendroket 10y ago
      Given that "object-oriented programmer" probably constitutes most of the people here you ought to know your audience and explain what you mean to say.

dragonwriter 10y ago

> In that case, you want values rather than objects. In dynamic OOP languages, value/object distinctions are often not exposed to the language user (they may actually exist in the underlying implementation, but from the PoV of the programmer using the language, there may be no discernible distinction between an "immutable object" and "value".) Conceptually (and ignoring the implementation details, which may have performance implications), immutable objects are equivalent to values, anyhow.

catnaroek 10y ago
> Conceptually ... immutable objects are equivalent to values, anyhow. Nope. Since values don't reside in computer memory other than through their representations, the language implementation (compiler, runtime system, etc.) is free to apply optimizations such as: (0) Determine whether a value is represented more than once in memory, and eliminate the redundant representations. (1) Store multiple values in a single dynamically allocated memory block. If object identities matter, all of this is unsound. > ... (and ignoring the implementation details, which may have performance implications), ... The performance implications can be constrained by equipping the language with a cost semantics.
- deleted 10y ago
  [deleted]

unlogic 10y ago

It's funny how catnaroek was completely vendetta-downvoted in this thread for speaking valid things. For those who don't understand the difference between objects and values, this video may be of help: https://www.youtube.com/watch?v=-6BsiVyC1kM https://www.youtube.com/watch?v=-6BsiVyC1kM

dang 10y ago

I'm not sure what the dynamic is behind this weird flamewar, but it's definitely not the sort of discussion we want on HN, and your comments seem, presumably unintentionally, to have trolling effects. Please don't do this here. We detached this subthread from https://news.ycombinator.com/item?id=12358875 https://news.ycombinator.com/item?id=12358875 and marked it off-topic.

catnaroek 10y ago
> and your comments seem, presumably unintentionally, to have trolling effects. I have no idea why stating facts would constitute “trolling”. But, anyway.
- dang 10y ago
  I agree that it's strange, but the discussion has gone badly, and it has something to do with how you engage people. That's what I mean by unintentional trolling.
- dllthomas 10y ago
  It's entirely possible to communicate other things while - first order - only stating uncontroversial facts. What, you don't think your shop is nice? You don't think it would be a shame if something happened to it? Given that, it's also entirely possible for people to perceive other things as communicated in cases where there's maybe not the intent.