5 ms·

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 no

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.
    - jdmichal 10y ago
      Here, look, I can do overly-broad, potentially-insulting generalizations too: Only a functional programmer would think that recreating the entire universe is necessary to change a value. See? Not very helpful or particularly insightful, is it?
      - catnaroek 10y ago
        > Only a functional programmer would think that recreating the entire universe is necessary to change a value. That's wrong. You can't change a value at all. What you can change is the state of an object. And functional languages have mutable objects too: https://docs.microsoft.com/en-us/dotnet/articles/fsharp/language-reference/reference-cells https://docs.microsoft.com/en-us/dotnet/articles/fsharp/lang... http://hackage.haskell.org/package/base-4.9.0.0/docs/Data-IORef.html http://hackage.haskell.org/package/base-4.9.0.0/docs/Data-IO...
        jdmichal 10y ago
        It wasn't meant to be correct... That's the whole point. "What we've got here, is a failure to communicate." Your definition of a "value" seems to be a strictly immutable, functional-oriented definition. Which is fine; that's a valid definition and there's nothing wrong with it. The issues come from the fact that you seem to refuse to accept that that is one definition of many, and continue to push it without compromise.
        catnaroek 10y ago
        The difference is that what I said was actually correct.
        jdmichal 10y ago
        It's correct only using your definitions and axioms. Other definitions and axioms can and do come to other conclusions. Your refusal to acknowledge that other definitions and axioms even exist is what is earning you the ire you are experiencing.
    - dragonwriter 10y ago
      Actually, OOP, particularly statically-typed OOP, seems to be a major domain in which the distinction between "value types" which contain "values" which do not evolve over time and "object types" which contain "objects" which may evolve over time is used frequently [0]. There are some OOP languages that take an "everything is an object" approach and provide no clear object/value distinction (this seems to be more the case with dynamic OOP languages, and even there while there may be little ergonomic distinction beyond the lack of mutability, there often are immutable "objects" that are stored without indirection which are far all intents and purposes values. Though in some cases the distinction between these and simple immutable objects is obscured from the programmer.) [0] Though in most such languages, the distinction between object and value involves more than just mutability, and is more deeply associated with indirection of storage, and its quite possible to have immutable objects which might be values from a technology-neutral conceptual perspective, but which are objects from an in-language implementation perspective.
      - catnaroek 10y ago
        > Though in most such languages, the distinction between object and value involves more than just mutability, and is more deeply associated with indirection of storage Values, unlike objects, don't reside on memory, but rather in the semantics of the language. Of course, representations of values reside in memory. But that's an implementation detail. What matters is the abstraction the programmer is exposed to.
        dpark 10y ago
        So your assertion is that objects are not an abstraction or defined by language semantics?
        catnaroek 10y ago
        Objects are a different abstraction: they're defined by the language's semantics to have a unique identity and be stored in memory exactly once at runtime. I won't blame objects for not being values.
        10y ago
    - spdustin 10y ago
      It seems that you're really saying that your values are immutable. For the rest of us, it seems we follow the line of thinking that, if our mental model (or "struct", if you will) has values (or types with fields/properties, if you will), that our mental model can be changed to reflect lessons learned (or, our values are inherently mutable, if you will).
      - catnaroek 10y ago
        Mutable objects are totally fine. They're just not values.
    - qwertyuiop924 10y ago
      I'm not an object oriented programmer. The word "value" is used in many contexts. Functions take values and return the same, sometimes mutating the values they took. rvalues, which are almost anything, are assigned to lvalues, which are locations. You can probably think of more. OTOH, your definition of object is almost entirely unique outside FP, AFAIK.
      - catnaroek 10y ago
        > assigned to lvalues, which are locations. lvalues aren't values.
        dragonwriter 10y ago
        > lvalues aren't values. lvalues are values in the same way that object references (not objects themselves) are values; perhaps more precisely, lvalues are values the same way that pointer values are values.
        catnaroek 10y ago
        An object reference is totally an rvalue: you can't mutate the object reference, only the object it refers to. AFAICT, lvalues are more akin to objects themselves, in that they can be mutated.
        qwertyuiop924 10y ago
        ...And here you are, completely demonstrating my point: Your defintion of "value" is not the same as the one in common usage: if you're going to go around using strange definitions of words we all know, at least tell us beforehand.
dang 10y ago
You've repeatedly become uncivil in this thread. That's not ok, regardless of wrong or provocative someone else may be. If you can't remain civil, please don't comment here. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newswelcome.html https://news.ycombinator.com/newswelcome.html
- qwertyuiop924 10y ago
  You are, of course, correct. I appologize, and will go to greater lengths to remain civil in threads in the future.
  - dang 10y ago
    We very much appreciate it. Thank you.
    - qwertyuiop924 10y ago
      It's all part of being a good commenter. My irritations, frustrations, and nitpicks ade my problem, not yours, and I'll do my best to ensure it stays that way in the future.

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.
  - jdmichal 10y ago
    Here, look, I can do overly-broad, potentially-insulting generalizations too: Only a functional programmer would think that recreating the entire universe is necessary to change a value. See? Not very helpful or particularly insightful, is it?
    - catnaroek 10y ago
      > Only a functional programmer would think that recreating the entire universe is necessary to change a value. That's wrong. You can't change a value at all. What you can change is the state of an object. And functional languages have mutable objects too: https://docs.microsoft.com/en-us/dotnet/articles/fsharp/language-reference/reference-cells https://docs.microsoft.com/en-us/dotnet/articles/fsharp/lang... http://hackage.haskell.org/package/base-4.9.0.0/docs/Data-IORef.html http://hackage.haskell.org/package/base-4.9.0.0/docs/Data-IO...
      - jdmichal 10y ago
        It wasn't meant to be correct... That's the whole point. "What we've got here, is a failure to communicate." Your definition of a "value" seems to be a strictly immutable, functional-oriented definition. Which is fine; that's a valid definition and there's nothing wrong with it. The issues come from the fact that you seem to refuse to accept that that is one definition of many, and continue to push it without compromise.
        catnaroek 10y ago
        The difference is that what I said was actually correct.
        jdmichal 10y ago
        It's correct only using your definitions and axioms. Other definitions and axioms can and do come to other conclusions. Your refusal to acknowledge that other definitions and axioms even exist is what is earning you the ire you are experiencing.
  - dragonwriter 10y ago
    Actually, OOP, particularly statically-typed OOP, seems to be a major domain in which the distinction between "value types" which contain "values" which do not evolve over time and "object types" which contain "objects" which may evolve over time is used frequently [0]. There are some OOP languages that take an "everything is an object" approach and provide no clear object/value distinction (this seems to be more the case with dynamic OOP languages, and even there while there may be little ergonomic distinction beyond the lack of mutability, there often are immutable "objects" that are stored without indirection which are far all intents and purposes values. Though in some cases the distinction between these and simple immutable objects is obscured from the programmer.) [0] Though in most such languages, the distinction between object and value involves more than just mutability, and is more deeply associated with indirection of storage, and its quite possible to have immutable objects which might be values from a technology-neutral conceptual perspective, but which are objects from an in-language implementation perspective.
    - catnaroek 10y ago
      > Though in most such languages, the distinction between object and value involves more than just mutability, and is more deeply associated with indirection of storage Values, unlike objects, don't reside on memory, but rather in the semantics of the language. Of course, representations of values reside in memory. But that's an implementation detail. What matters is the abstraction the programmer is exposed to.
      - dpark 10y ago
        So your assertion is that objects are not an abstraction or defined by language semantics?
        catnaroek 10y ago
        Objects are a different abstraction: they're defined by the language's semantics to have a unique identity and be stored in memory exactly once at runtime. I won't blame objects for not being values.
      - 10y ago
  - spdustin 10y ago
    It seems that you're really saying that your values are immutable. For the rest of us, it seems we follow the line of thinking that, if our mental model (or "struct", if you will) has values (or types with fields/properties, if you will), that our mental model can be changed to reflect lessons learned (or, our values are inherently mutable, if you will).
    - catnaroek 10y ago
      Mutable objects are totally fine. They're just not values.
  - qwertyuiop924 10y ago
    I'm not an object oriented programmer. The word "value" is used in many contexts. Functions take values and return the same, sometimes mutating the values they took. rvalues, which are almost anything, are assigned to lvalues, which are locations. You can probably think of more. OTOH, your definition of object is almost entirely unique outside FP, AFAIK.
    - catnaroek 10y ago
      > assigned to lvalues, which are locations. lvalues aren't values.
      - dragonwriter 10y ago
        > lvalues aren't values. lvalues are values in the same way that object references (not objects themselves) are values; perhaps more precisely, lvalues are values the same way that pointer values are values.
        catnaroek 10y ago
        An object reference is totally an rvalue: you can't mutate the object reference, only the object it refers to. AFAICT, lvalues are more akin to objects themselves, in that they can be mutated.
      - qwertyuiop924 10y ago
        ...And here you are, completely demonstrating my point: Your defintion of "value" is not the same as the one in common usage: if you're going to go around using strange definitions of words we all know, at least tell us beforehand.

dang 10y ago

You've repeatedly become uncivil in this thread. That's not ok, regardless of wrong or provocative someone else may be. If you can't remain civil, please don't comment here. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newswelcome.html https://news.ycombinator.com/newswelcome.html

qwertyuiop924 10y ago
You are, of course, correct. I appologize, and will go to greater lengths to remain civil in threads in the future.
- dang 10y ago
  We very much appreciate it. Thank you.
  - qwertyuiop924 10y ago
    It's all part of being a good commenter. My irritations, frustrations, and nitpicks ade my problem, not yours, and I'll do my best to ensure it stays that way in the future.