6 ms·

It's relevant. If it weren't, there wouldn't be a debate regarding the usefulness of behaviorless objects.

by catnaroek 10y ago

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.
        catnaroek 10y ago
        > Your definition of a "value" seems to be a strictly immutable, functional-oriented definition. The very question of mutability only makes sense for objects that reside in computer memory. Asking whether values mutate is as meaningless as asking what the color of your feelings is. > the ire you are experiencing. I'm deliberately provoking it.
        jdmichal 10y ago
        > I'm deliberately provoking it. I'll just start flagging you for trolling then. It's one thing to attempt to have a meaningful discussion and unintentionally provoke ire. Meaningfully doing it by being obtuse and smug... I guess qwerty was spot on with the Randall Monroe quote.
  - 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.

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.
        catnaroek 10y ago
        > Your definition of a "value" seems to be a strictly immutable, functional-oriented definition. The very question of mutability only makes sense for objects that reside in computer memory. Asking whether values mutate is as meaningless as asking what the color of your feelings is. > the ire you are experiencing. I'm deliberately provoking it.
        jdmichal 10y ago
        > I'm deliberately provoking it. I'll just start flagging you for trolling then. It's one thing to attempt to have a meaningful discussion and unintentionally provoke ire. Meaningfully doing it by being obtuse and smug... I guess qwerty was spot on with the Randall Monroe quote.
- 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.