6 ms·

Thanks for your response. The benefit of immutability is that values can never change "out from under you". But there seems to be a counter-point, which I hav

Thanks for your response. The benefit of immutability is that values can never change "out from under you". But there seems to be a counter-point, which I haven't seen articulated much. In cases where object reference identities are meaningful, all references to an object are always current. Think video game characters running around in an arena interacting with each other. I think immutability is a great tool for domains where it's helpful. That's the same position I have regarding mutability. I think the mutable Date object in javascript was a mistake. I also think it's hard to compete with the simplicity of a recursive `walk()` function that mutates the AST nodes and query queue in place. Maybe I'll see the light when I manage to comprehend what a monad is.

williamcotton 2y ago
A monad is just a fancy name for a design pattern in functional programing that manages side effects so you can write what looks like imperative code but that does some other stuff behind the scenes, eg, logging, async, exception handling. They only make sense in a functional language that has support for “type wrappers”, eg, Result, Option, or custom made types like a ResultWriter. The gist is you define a bind function that takes two arguments (a white lie), the first one of those “wrapped values” and the second a “function that takes an unwrapped value, does something, and returns a wrapped value”, and then the bind function “unwraps the value from the first arg and calls the second arg with that unwrapped value”. This lets you chain together these “functions that take a value, does something, and then returns a wrapped value” and if you can define an infix operator it makes for for legible code that’s easy to read and modify. It looks even better in F#’s computation expression syntactic sugar. Of course I am now going to try to explain this better with Yet Another Monad Tutorial to torture the internet with…
- recursive 2y ago
  I should have issued a warning against trying to educate me. But I also know that explaining monads is like irresistible crack for those in the know. I'm half-convinced I have a learning disability that specifically affects my ability to comprehend monads. Years ago, I gave it a serious attempt. At this point, I think I'll be satisfied to never quite get it. I totally understand Option, (I think?) but I completely fail to understand what that has to do with side effects. I'm ok with this. Thanks for the effort anyway. I don't understand what ResultWriter is or could be. I don't understand what the white lie is.
  - williamcotton 2y ago
    The white lie is that in functional programming a function only takes a single argument and uses currying to mimic multiple arguments. Like this in JS: let f = (x) => (y) => x * y; let p = f(2)(3); Is this in F#: let f x y = x * y let p = f 2 3 A ResultWriter is just a wrapper type that takes a tuple of a Result and a list of log messages. The side effects are you can write imperative code that works with normal values but does exception handling and log messaging behind the scenes and without it cluttering the task at hand. So you write some functions that return either Success wrapping a value with some good news log message or an Error with some bad news log message. Then with a bind function or especially with a computation expression in F# you can use those functions without dealing with the exceptions and log messages until after you’ve completed all of the steps. Unless you’re using a language that supports this kind of monad design pattern it won’t really make any sense!
  - ashton314 2y ago
    Well, actually, it's really just like a burrito…
mrkeen 2y ago
> I think the mutable Date object in javascript was a mistake. I'm not much of a JS guy, but isn't mutable objects the norm, not the exception? Over in Java land we have the mutable ArrayList and the mutable HashSet etc. > Maybe I'll see the light when I manage to comprehend what a monad is. That's not going to happen. First you need to see a problem (e.g. a mutable object being a mistake.) Then you need to see a range of solutions. Then the best solution needs to be a particular Thing. Then that Thing needs to resemble other different Things which solve other problems. If those different solutions resemble one another enough, you can put them under a common interface Monad. But if there is no problem with a mutable AST object or a mutable Date object, then you won't even consider the solutions. A monad won't solve the problem you don't have.
- recursive 2y ago
  Mutable and immutable objects are both common. In Java, ArrayList is mutable, but String is not. If you concatenate strings, it makes a new string. It never changes the existing one. This maps pretty well to peoples' intuitions when using strings. If you have a reference to a string, its' contents can never change. You can assign a new string to your variable, but that's different. In JS, the contents of a Date object can change. This is widely regarded to be a mistake, and I agree with that.

williamcotton 2y ago

A monad is just a fancy name for a design pattern in functional programing that manages side effects so you can write what looks like imperative code but that does some other stuff behind the scenes, eg, logging, async, exception handling. They only make sense in a functional language that has support for “type wrappers”, eg, Result, Option, or custom made types like a ResultWriter. The gist is you define a bind function that takes two arguments (a white lie), the first one of those “wrapped values” and the second a “function that takes an unwrapped value, does something, and returns a wrapped value”, and then the bind function “unwraps the value from the first arg and calls the second arg with that unwrapped value”. This lets you chain together these “functions that take a value, does something, and then returns a wrapped value” and if you can define an infix operator it makes for for legible code that’s easy to read and modify. It looks even better in F#’s computation expression syntactic sugar. Of course I am now going to try to explain this better with Yet Another Monad Tutorial to torture the internet with…

recursive 2y ago
I should have issued a warning against trying to educate me. But I also know that explaining monads is like irresistible crack for those in the know. I'm half-convinced I have a learning disability that specifically affects my ability to comprehend monads. Years ago, I gave it a serious attempt. At this point, I think I'll be satisfied to never quite get it. I totally understand Option, (I think?) but I completely fail to understand what that has to do with side effects. I'm ok with this. Thanks for the effort anyway. I don't understand what ResultWriter is or could be. I don't understand what the white lie is.
- williamcotton 2y ago
  The white lie is that in functional programming a function only takes a single argument and uses currying to mimic multiple arguments. Like this in JS: let f = (x) => (y) => x * y; let p = f(2)(3); Is this in F#: let f x y = x * y let p = f 2 3 A ResultWriter is just a wrapper type that takes a tuple of a Result and a list of log messages. The side effects are you can write imperative code that works with normal values but does exception handling and log messaging behind the scenes and without it cluttering the task at hand. So you write some functions that return either Success wrapping a value with some good news log message or an Error with some bad news log message. Then with a bind function or especially with a computation expression in F# you can use those functions without dealing with the exceptions and log messages until after you’ve completed all of the steps. Unless you’re using a language that supports this kind of monad design pattern it won’t really make any sense!
- ashton314 2y ago
  Well, actually, it's really just like a burrito…

mrkeen 2y ago

> I think the mutable Date object in javascript was a mistake. I'm not much of a JS guy, but isn't mutable objects the norm, not the exception? Over in Java land we have the mutable ArrayList and the mutable HashSet etc. > Maybe I'll see the light when I manage to comprehend what a monad is. That's not going to happen. First you need to see a problem (e.g. a mutable object being a mistake.) Then you need to see a range of solutions. Then the best solution needs to be a particular Thing. Then that Thing needs to resemble other different Things which solve other problems. If those different solutions resemble one another enough, you can put them under a common interface Monad. But if there is no problem with a mutable AST object or a mutable Date object, then you won't even consider the solutions. A monad won't solve the problem you don't have.

recursive 2y ago
Mutable and immutable objects are both common. In Java, ArrayList is mutable, but String is not. If you concatenate strings, it makes a new string. It never changes the existing one. This maps pretty well to peoples' intuitions when using strings. If you have a reference to a string, its' contents can never change. You can assign a new string to your variable, but that's different. In JS, the contents of a Date object can change. This is widely regarded to be a mistake, and I agree with that.