> Nobody is stopping you from just working as if JS is immutable.
You cant just work "as if" things are immutable when they aren't. You have to be super careful about not mutating objects, for example copying an array with .slice() before messing with it. That is not ideal because 1) it is manual, and 2) copy on write is inefficient compared to the structure sharing that immutable data structures use.
If you want the benefits of persistent data structures in Javascript, you have to use something like Mori. And that is ok, but not as nice as it is in functional languages, because you loose the specialized literal syntax to create the data structures and work with them. For example, to create a vector in mori you have to:
var vec = mori.vector(1,2,3);
And to map a function on it, you have to use Mori's special version of map:
var result = mori.map(inc, mori.vector(1,2,3,4,5))
The issue with function composition in javascript, for me, is that it's difficult to reason that the functions you are composing in fact do have all their types "lining up".
I think there was some outfit "loop/recur" that was doing heavily composition-style javascript. They often write the types for function in comments in haskell notation above the actual function definitions.
You cant just work "as if" things are immutable when they aren't. You have to be super careful about not mutating objects, for example copying an array with .slice() before messing with it. That is not ideal because 1) it is manual, and 2) copy on write is inefficient compared to the structure sharing that immutable data structures use.
If you want the benefits of persistent data structures in Javascript, you have to use something like Mori. And that is ok, but not as nice as it is in functional languages, because you loose the specialized literal syntax to create the data structures and work with them. For example, to create a vector in mori you have to:
And to map a function on it, you have to use Mori's special version of map: