4 ms·

> Most abstraction isn't about state at all (you won't find state anywhere in the definition of a group, say). Sure, but you also wouldn't care that π is defin

> Most abstraction isn't about state at all (you won't find state anywhere in the definition of a group, say). Sure, but you also wouldn't care that π is defined as an equivalence class of cauchy sequences if you're treating (R, +) as a group. In fact, one does not care at all about the particular details of a group being a set-- one treats groups up to isomorphism. But of course, I was talking about abstraction in programming.

lmm 8y ago
> Sure, but you also wouldn't care that π is defined as an equivalence class of cauchy sequences if you're treating (R, +) as a group. In fact, one does not care at all about the particular details of a group being a set-- one treats groups up to isomorphism. You don't care at that point, but you don't destroy the information either. You know that (R, +) forms a group and you might use that group structure to, say, efficiently sum a list of reals - but you know that the answer is a real and not just a "group element", and you would go back to doing real-specific operations on your total. So it's more about parameterisation than about outright hiding information. > But of course, I was talking about abstraction in programming. What's the difference? If you don't mean the normal kind of abstraction then what's the definition of the thing that you're talking about?
- danharaj 8y ago
  > You don't care at that point, but you don't destroy the information either. You know that (R, +) forms a group and you might use that group structure to, say, efficiently sum a list of reals - but you know that the answer is a real and not just a "group element", and you would go back to doing real-specific operations on your total. So it's more about parameterisation than about outright hiding information. When you reason about something as a group, that reasoning operates with the details hidden. When you apply that abstract reasoning to a concrete problem, of course that information is still there. Abstraction is a boundary that looks different on either side. In a similar vein of your example, the compiler knows all the information you're hiding through your program abstractions, but from the point of view of pieces of your code, that abstraction has hidden something. > What's the difference? If you don't mean the normal kind of abstraction then what's the definition of the thing that you're talking about? The word abstraction is so... abstract that it isn't actually a uniform concept applied in different areas but instead many similar concepts that look the same if you squint. The concept I'm talking about is abstraction in the context of program structure. This is more related to mathematical abstraction than a mere metaphor but it's not exactly the same thing as the abstraction in a definition like groups, nor is it the same abstract as in abstract art.
  - lmm 8y ago
    > When you reason about something as a group, that reasoning operates with the details hidden. When you apply that abstract reasoning to a concrete problem, of course that information is still there. Abstraction is a boundary that looks different on either side. In a similar vein of your example, the compiler knows all the information you're hiding through your program abstractions, but from the point of view of pieces of your code, that abstraction has hidden something. If I write a function like: f(x) = x + 2 would you say the value of x is "hidden" in the expression x + 2? I would say no: it's clear that there is a value of x at the point where we evaluate that expression. That's a different kind of thing from the OO style where we write o.f() and genuinely can't distinguish whether there is relevant internal state in o (and whether that state is mutated by the call to f()), or not.
    - danharaj 8y ago
      There is a difference between a function `f` and the expression `x + 2` in your example. In fact, `f` as a function completely hides the expression from which it was defined. Usually functions are considered equal if they have the same values at every point. The upshot is, you can define a function from two different expressions and they can end up being the "same" function. This is indeed the hiding of some information. In the composition of functions, f . g (x) = f(g(x)), that there is a result of g(x) is hidden by the composition, which only allows examination of the first input and the final output. There is nothing special about OOP here.
      - lmm 8y ago
        > There is a difference between a function `f` and the expression `x + 2` in your example. In fact, `f` as a function completely hides the expression from which it was defined. Usually functions are considered equal if they have the same values at every point. The upshot is, you can define a function from two different expressions and they can end up being the "same" function. This is indeed the hiding of some information. It's hiding the differing constructions, but at that point I don't see that as a true difference. (\x . x + 2) . (\x . x + 2) seems to me to be the same value as \x . x + 4 in exactly the same way that 2 + 2 is the same value as 4. > In the composition of functions, f . g (x) = f(g(x)), that there is a result of g(x) is hidden by the composition, which only allows examination of the first input and the final output. > There is nothing special about OOP here. Having mutable state hidden/encapsulated with a bundle of functions that may be entangled with that state is unique to OOP; as I said in the side thread, hidden structure is not the same as hidden state.

lmm 8y ago

> Sure, but you also wouldn't care that π is defined as an equivalence class of cauchy sequences if you're treating (R, +) as a group. In fact, one does not care at all about the particular details of a group being a set-- one treats groups up to isomorphism. You don't care at that point, but you don't destroy the information either. You know that (R, +) forms a group and you might use that group structure to, say, efficiently sum a list of reals - but you know that the answer is a real and not just a "group element", and you would go back to doing real-specific operations on your total. So it's more about parameterisation than about outright hiding information. > But of course, I was talking about abstraction in programming. What's the difference? If you don't mean the normal kind of abstraction then what's the definition of the thing that you're talking about?

danharaj 8y ago
> You don't care at that point, but you don't destroy the information either. You know that (R, +) forms a group and you might use that group structure to, say, efficiently sum a list of reals - but you know that the answer is a real and not just a "group element", and you would go back to doing real-specific operations on your total. So it's more about parameterisation than about outright hiding information. When you reason about something as a group, that reasoning operates with the details hidden. When you apply that abstract reasoning to a concrete problem, of course that information is still there. Abstraction is a boundary that looks different on either side. In a similar vein of your example, the compiler knows all the information you're hiding through your program abstractions, but from the point of view of pieces of your code, that abstraction has hidden something. > What's the difference? If you don't mean the normal kind of abstraction then what's the definition of the thing that you're talking about? The word abstraction is so... abstract that it isn't actually a uniform concept applied in different areas but instead many similar concepts that look the same if you squint. The concept I'm talking about is abstraction in the context of program structure. This is more related to mathematical abstraction than a mere metaphor but it's not exactly the same thing as the abstraction in a definition like groups, nor is it the same abstract as in abstract art.
- lmm 8y ago
  > When you reason about something as a group, that reasoning operates with the details hidden. When you apply that abstract reasoning to a concrete problem, of course that information is still there. Abstraction is a boundary that looks different on either side. In a similar vein of your example, the compiler knows all the information you're hiding through your program abstractions, but from the point of view of pieces of your code, that abstraction has hidden something. If I write a function like: f(x) = x + 2 would you say the value of x is "hidden" in the expression x + 2? I would say no: it's clear that there is a value of x at the point where we evaluate that expression. That's a different kind of thing from the OO style where we write o.f() and genuinely can't distinguish whether there is relevant internal state in o (and whether that state is mutated by the call to f()), or not.
  - danharaj 8y ago
    There is a difference between a function `f` and the expression `x + 2` in your example. In fact, `f` as a function completely hides the expression from which it was defined. Usually functions are considered equal if they have the same values at every point. The upshot is, you can define a function from two different expressions and they can end up being the "same" function. This is indeed the hiding of some information. In the composition of functions, f . g (x) = f(g(x)), that there is a result of g(x) is hidden by the composition, which only allows examination of the first input and the final output. There is nothing special about OOP here.
    - lmm 8y ago
      > There is a difference between a function `f` and the expression `x + 2` in your example. In fact, `f` as a function completely hides the expression from which it was defined. Usually functions are considered equal if they have the same values at every point. The upshot is, you can define a function from two different expressions and they can end up being the "same" function. This is indeed the hiding of some information. It's hiding the differing constructions, but at that point I don't see that as a true difference. (\x . x + 2) . (\x . x + 2) seems to me to be the same value as \x . x + 4 in exactly the same way that 2 + 2 is the same value as 4. > In the composition of functions, f . g (x) = f(g(x)), that there is a result of g(x) is hidden by the composition, which only allows examination of the first input and the final output. > There is nothing special about OOP here. Having mutable state hidden/encapsulated with a bundle of functions that may be entangled with that state is unique to OOP; as I said in the side thread, hidden structure is not the same as hidden state.