3 ms·

To be fair to other styles, we generally learned already that shared state is bad. It's avoided in basically every language/service these days. It may be enforc

To be fair to other styles, we generally learned already that shared state is bad. It's avoided in basically every language/service these days. It may be enforced more strictly with functional programming. But "With other programming paradigms, you can't just knock out all the little pieces without thinking about the other pieces" is taking it too far. For example, you want to add email sending to your app? The library for it is a little piece of software independent of the rest.

diggan 2y ago
> To be fair to other styles, we generally learned already that shared state is bad. It's avoided in basically every language/service these days. I don't know how true that really is. JavaScript added `class` relatively late in it's lifespan, and most JavaScript/TypeScript projects use `class` to hide shared state/mutations behind that interface, in the name of `encapsulation`, rather than just passing stateless data from function to function. Both patterns obviously has their places, no silver bullets and all that, but you'll have a hard time finding any relatively popular JS/TS project that doesn't overtly rely on shared state one way or another.
- viraptor 2y ago
  Objects with instance variables don't automatically mean the state is shared. A JS event loop holding onto a simple object with some data is not practically different from a functional event loop with some big context carried between executions. One will have mutations, the other will do effectively the same with tail call and some IO executor. In both you have to add the shared state explicitly, one just makes it way harder. > you'll have a hard time finding any relatively popular JS/TS project that doesn't overtly rely on shared state one way or another That's sampling bias. Where's the thousands of the event driven DOM UI Haskell projects, which doesn't rely on shared state?
  - diggan 2y ago
    > Objects with instance variables don't automatically mean the state is shared. Agree, but JS's syntax and constructs are almost begging the user to encapsulate their state in classes and instances and share those instances between function calls, rather than passing the data itself around. This is very visible if you browse the various JS APIs as well.
jimbokun 2y ago
How so? Can't "sendEmail" be a function near the edge of the network that does the IO of actually pushing the bytes across the network, decoupled from the "pure" functions at the heart of your application?

diggan 2y ago

> To be fair to other styles, we generally learned already that shared state is bad. It's avoided in basically every language/service these days. I don't know how true that really is. JavaScript added `class` relatively late in it's lifespan, and most JavaScript/TypeScript projects use `class` to hide shared state/mutations behind that interface, in the name of `encapsulation`, rather than just passing stateless data from function to function. Both patterns obviously has their places, no silver bullets and all that, but you'll have a hard time finding any relatively popular JS/TS project that doesn't overtly rely on shared state one way or another.

viraptor 2y ago
Objects with instance variables don't automatically mean the state is shared. A JS event loop holding onto a simple object with some data is not practically different from a functional event loop with some big context carried between executions. One will have mutations, the other will do effectively the same with tail call and some IO executor. In both you have to add the shared state explicitly, one just makes it way harder. > you'll have a hard time finding any relatively popular JS/TS project that doesn't overtly rely on shared state one way or another That's sampling bias. Where's the thousands of the event driven DOM UI Haskell projects, which doesn't rely on shared state?
- diggan 2y ago
  > Objects with instance variables don't automatically mean the state is shared. Agree, but JS's syntax and constructs are almost begging the user to encapsulate their state in classes and instances and share those instances between function calls, rather than passing the data itself around. This is very visible if you browse the various JS APIs as well.

jimbokun 2y ago

How so? Can't "sendEmail" be a function near the edge of the network that does the IO of actually pushing the bytes across the network, decoupled from the "pure" functions at the heart of your application?