The Value of Values with Rich Hickey

Immutability has been pretty hot of late, though still controversial. There are several popular languages which encourage or even force immutability (Elixir, Clojure). What sold me on the idea was Rich Hickey's talk, "The Value of Values": [this video] I look at it as mostly a safety net: I'd rather use const by default, unless I have a good reason to be able to mutate the variable. (To flip it around: what problem does being mutable-by-default solve?) 9 times out of 10, I don't need to change the value for the lifecycle of the function; and often if I do, the code is cleaner anyway if I use an immutable pattern (such as `const foo = bar.map()` rather than `for(x in bar) foo.push()`). Thanks to the magic of Merkle trees, we can generally make fresh pointers without it costing much memory overhead.

If you have the slightest interest in the issue of concurrency then you should study Erlang and Clojure. Since Moore's Law has largely faded, and we now gain speed by putting more CPUs in each server (rather than having the individual CPUs be faster) concurrency is an increasingly unavoidable aspect of programming. Joe Armstrong (Erlang) and Rich Hickey (Clojure) have both spent an enormous amount of time thinking about how to support concurrency in a programming language. Armstrong talks about a paradigm that he calls "Concurrency Oriented Programming". Armstrong's thesis is surprisingly readable and I recommend it: [link] Rich Hickey's video presentation "The value of values" is also a good overview of some concepts that are important to Functional Programming: [this video]

Leporello.js follows a pragmatic functional approach. You can use IO functions and throw exceptions as you typically would, without the need for an IO monad or an Option monad. However, there is one critical limitation – you cannot mutate your data structures. Mutations are not allowed because they would make time-travel debugging impossible. For instance, the following code is forbidden: const point = {x: 1, y: 2} point.x = 2 And instead you should use this: const point = {x: 1, y: 2} const another_point = {...point, x : 2} In Leporello.js, it's vital to avoid mutating data structures; instead, you create new ones. You can watch Rich Hickey's insightful talk [0], where he discusses the advantages of immutability in functional programming. In many ways, Leporello.js bears a resemblance to Clojure. Clojure served as a source of inspiration for Leporello.js, to the extent that I even contemplated building Leporello.js for Clojure first. [0] [this video]

Who knows what bowl.stir() actually does to the internal state of bowl, and what methods should have been run up until this point to get into that state, is the bowl ready to stir? What methods should have already run for that? So much of the article's code is crutched on good naming I like to think of this in terms of the Charizard Pokemon card For context in this example I have this card and I'm sensitive about damage to it so in this OO example I put the card in a box and allow you to interact with it in a very limited way, you cannot use anything you're used to to interact with it like your own gloves or hands etc Just my "methods" so I might give you a tiny hole to look at it, you could still damage it through the hole, so I have lots of logic to ensure you cannot poke it incorrectly hopefully the verbosity on both your and my side is/was worth it and bug free and not missing cases, hopefully my hole was in the right place for your uses Obviously I can't give you too many holes in the box otherwise what's the point in the box? I need the box to maintain my sanity The other alternative is I just give you the card, and take the risk that you might damage it, this is a disaster for my well being OR I duplicate the card perfectly and give you the duplicate in which case I don't care what happens to the duplicate, MUCH easier in my opinion, so please Stop creating hellish boxes with holes for other developers to peak through just choose a language with efficient immutability