2 ms·

> Whenever we call our transform function, we would have to ensure that we clear out the old list of accumulated information. This is why I presumed this post

> Whenever we call our transform function, we would have to ensure that we clear out the old list of accumulated information. This is why I presumed this post is using the popular understanding of the term. Anyway, nodes are only public if the calling code makes them public by leaking a reference or something. > Don’t forget about all the other problems that global mutable state brings. There must be a better way. When this blog says "global mutable state", then it must be referring to what's commonly understood to be "mutable state". It seems to be an article of faith that there must be a better way. To my sensibility, that is the best way. The argument seems to rest on some sleight-of-hand regarding "global".

mrkeen 2y ago
Remember 20 years ago, when getters and setters were all the rage? Reaching in to access variables was bad, but if you used a getter instead, then that was somehow good because you were doing encapsulation? IDEs gained the ability to generate your getters and setters for you, C# had properties which streamlined things and made Java look boilerplatey in comparison, and Java got Lombok. But it was all bullshit. If making fields private is 'locking the door', then adding getters and setters is 'leaving the key on top of the doormat'. Show me a logic bug caused by a global variable, I'll slap some getters and setters onto it, give it back to you, and it will still have the same logic bug. What's my point? It's not that FP has some competing definition of 'global variables' that somehow makes FP look good and imperative look bad, it's that FP actually followed the idea through to its logical conclusion and generalised it as 'shared mutable state', rather than slapping "encapsulation" on it and calling it a day. > Anyway, nodes are only public if the calling code makes them public by leaking a reference or something. This is true. However people commonly leak things by putting 'export' in front of them. Otherwise how can callers access them?
- recursive 2y ago
  I do remember. I never really bought into the dogma about property accessors. Sometimes they are good. But mutable object fields might be fine too. In fact, I even think goto is appropriate in some circumstances. I guess the modern conception of FP says 'all values and state are best modeled immutably'. Whereas I tend to think it's only some of them.

mrkeen 2y ago

Remember 20 years ago, when getters and setters were all the rage? Reaching in to access variables was bad, but if you used a getter instead, then that was somehow good because you were doing encapsulation? IDEs gained the ability to generate your getters and setters for you, C# had properties which streamlined things and made Java look boilerplatey in comparison, and Java got Lombok. But it was all bullshit. If making fields private is 'locking the door', then adding getters and setters is 'leaving the key on top of the doormat'. Show me a logic bug caused by a global variable, I'll slap some getters and setters onto it, give it back to you, and it will still have the same logic bug. What's my point? It's not that FP has some competing definition of 'global variables' that somehow makes FP look good and imperative look bad, it's that FP actually followed the idea through to its logical conclusion and generalised it as 'shared mutable state', rather than slapping "encapsulation" on it and calling it a day. > Anyway, nodes are only public if the calling code makes them public by leaking a reference or something. This is true. However people commonly leak things by putting 'export' in front of them. Otherwise how can callers access them?

recursive 2y ago
I do remember. I never really bought into the dogma about property accessors. Sometimes they are good. But mutable object fields might be fine too. In fact, I even think goto is appropriate in some circumstances. I guess the modern conception of FP says 'all values and state are best modeled immutably'. Whereas I tend to think it's only some of them.