4 ms·

There is no essential mutable state in computer science. All essential mutable state can be modeled away to use no mutable state, as you have shown in the gener

by kccqzy 4y ago

There is no essential mutable state in computer science. All essential mutable state can be modeled away to use no mutable state, as you have shown in the generation number idea which is one valid way. (I'm strictly talking about computer science problems not computer engineering problems such as drivers.) The generation number idea you have shown is an excellent idea. It immediately enables several new capabilities compared with just mutation: * You are now able to determine which data is older and which is newer without resorting to an external clock. * If your mutation takes a long time, there is no longer a need to use a long-held mutex to ensure thread safety which would prevent concurrent reads; you can create a new generation separately and then atomically CAS it. Writers don't block readers. * If you suddenly need undo/redo functionality, it's suddenly trivial. Or diff'ing between versions. Or understanding the reason for changes (basics of auditing).

kilgnad 4y ago
Lambda calculus machines can't exist in reality though. Only the von Neumann machine can be actualized. Thus from a practical perspective the foundations of actual computing must be built on mutable state. You are wrong about the generations idea. It's a side effect. Functions themselves cannot actually do anything with a generation number. It's completely useless other then for letting you know how many times a value has changed. A generation number also doesn't negate the need for mutexes. The system is still operating on shared state, a generation number doesn't change this.
- kccqzy 4y ago
  You are not getting the point of either my comment or the original article. You are thinking from an engineering point of view, where if you look through all the layers of abstraction you see mutexes and shared mutable memory. That's not my point; my point is about building up those abstractions so they are sufficiently hidden. Functional programmers routinely operate on a higher level of abstraction, and they have shorter, more maintainable code. In such code, it would be a code smell if you continue to use mutexes, because that should've been an implementation detail. It should've been clear from the outset that the kind of complexity the article is talking about is cognitive complexity.
  - kilgnad 4y ago
    I am getting it. I am simply saying that you can't completely hide those details. They leak through.
enlyth 4y ago
> There is no essential mutable state in computer science. Yes, theoretically. Now imagine your mutable state is 2GB in size, have fun creating a copy of it on every change.
- akimball 4y ago
  The optimizer removes that.
- kccqzy 4y ago
  You are not getting the point of my comment or the original article. It's clear to me that the kind of complexity being talked about in the article is cognitive complexity not computational complexity. It's not about choosing between an O(n) copying of data and O(1) in-place mutation; it's about choosing code that's easy to comprehend and maintain.
  - deathanatos 4y ago
    Their point is that you can't choose the cognitively simpler choice because of real world design constraints, such as not consuming all available RAM — i.e., because of essential complexity.
    - kragen 4y ago
      that's complexity introduced by your approach to the solution (using an inadequately large computer) rather than essential to the problem you're trying to solve
      - akkartik 4y ago
        I think the crux is which side gets to be called "essential". Is it the abstract problem the code is intended for, or is it the real world we're living in. Mike Acton argues for the latter (https://www.youtube.com/watch?v=rX0ItVEVjHc https://www.youtube.com/watch?v=rX0ItVEVjHc) And all this is heat rather than light because there is absolutely a significant fraction of concerns that both sides would agree are utterly incidental/accidental complexity.
feoren 4y ago
Engineering is about tradeoffs. There is no One Model To Rule Them All. Your post is a great thing to keep in mind, but it's not a prescription. Engineers need to be able to look at a problem from many points of views at once, and try to find the right path for their current problem. This is why it's so important that models play nicely with one another, something that functional programming is getting better at, but reactive programming still really struggles with. All of your asterisked points are well-taken, but: do you need that capability? Sometimes; sometimes not.
layer8 4y ago
> All essential mutable state can be modeled away to use no mutable state However, that modeling introduces complexity of its own that not everyone agrees is entirely essential.

by kccqzy 4y ago

kilgnad 4y ago

Lambda calculus machines can't exist in reality though. Only the von Neumann machine can be actualized. Thus from a practical perspective the foundations of actual computing must be built on mutable state. You are wrong about the generations idea. It's a side effect. Functions themselves cannot actually do anything with a generation number. It's completely useless other then for letting you know how many times a value has changed. A generation number also doesn't negate the need for mutexes. The system is still operating on shared state, a generation number doesn't change this.

kccqzy 4y ago
You are not getting the point of either my comment or the original article. You are thinking from an engineering point of view, where if you look through all the layers of abstraction you see mutexes and shared mutable memory. That's not my point; my point is about building up those abstractions so they are sufficiently hidden. Functional programmers routinely operate on a higher level of abstraction, and they have shorter, more maintainable code. In such code, it would be a code smell if you continue to use mutexes, because that should've been an implementation detail. It should've been clear from the outset that the kind of complexity the article is talking about is cognitive complexity.
- kilgnad 4y ago
  I am getting it. I am simply saying that you can't completely hide those details. They leak through.

enlyth 4y ago

> There is no essential mutable state in computer science. Yes, theoretically. Now imagine your mutable state is 2GB in size, have fun creating a copy of it on every change.

akimball 4y ago
The optimizer removes that.
kccqzy 4y ago
You are not getting the point of my comment or the original article. It's clear to me that the kind of complexity being talked about in the article is cognitive complexity not computational complexity. It's not about choosing between an O(n) copying of data and O(1) in-place mutation; it's about choosing code that's easy to comprehend and maintain.
- deathanatos 4y ago
  Their point is that you can't choose the cognitively simpler choice because of real world design constraints, such as not consuming all available RAM — i.e., because of essential complexity.
  - kragen 4y ago
    that's complexity introduced by your approach to the solution (using an inadequately large computer) rather than essential to the problem you're trying to solve
    - akkartik 4y ago
      I think the crux is which side gets to be called "essential". Is it the abstract problem the code is intended for, or is it the real world we're living in. Mike Acton argues for the latter (https://www.youtube.com/watch?v=rX0ItVEVjHc https://www.youtube.com/watch?v=rX0ItVEVjHc) And all this is heat rather than light because there is absolutely a significant fraction of concerns that both sides would agree are utterly incidental/accidental complexity.

feoren 4y ago

Engineering is about tradeoffs. There is no One Model To Rule Them All. Your post is a great thing to keep in mind, but it's not a prescription. Engineers need to be able to look at a problem from many points of views at once, and try to find the right path for their current problem. This is why it's so important that models play nicely with one another, something that functional programming is getting better at, but reactive programming still really struggles with. All of your asterisked points are well-taken, but: do you need that capability? Sometimes; sometimes not.

layer8 4y ago

> All essential mutable state can be modeled away to use no mutable state However, that modeling introduces complexity of its own that not everyone agrees is entirely essential.