The Value of Values with Rich Hickey

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: [VIDEO]

Hi! I have been a programmer for a couple years and started picking up clojure after watching a few of rich hickeys talks. This is the one that best satisfies your question, imho: [VIDEO]

It's funny how catnaroek was completely vendetta-downvoted in this thread for speaking valid things. For those who don't understand the difference between objects and values, this video may be of help: [VIDEO]

That talk was "The Value of Values," which I enjoyed as well. Links for anyone interested: [LINK] (1 hour version) [VIDEO] (1/2 hour version)

Clojure's implementation did not have to be so complicated, there are simpler implementations of persistent data structures. Immutability is obviously the more elegant option as far as I'm concerned: Hickey's The Value of Values [0] lays out the case quite well. [0]: [VIDEO]

Rich Hickey's "Value of Values"[0] is what finally sold me on the benefits of pure functional programming and immutable data structures. (It remains horrifying to continue working with MySQL in my day job, knowing that every UPDATE is potentially a destructive action with no history and no undo.) [0]: [VIDEO]

I think Rich Hickey's (the creator of Clojure) talk, The Value of Values, to be a great 'splainer: [VIDEO]

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": [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.

Most software isn’t FAANG. In the long tail of database size, I’d guess 95%+ of databases are smaller than a few hundred megs. And at that size, storage is cheap and storing a full historical record of changes should absolutely be the default. Rich Hickey has a great talk on this a few years ago talking about the difference between Place and Value. He says accountants learned this lesson hundreds of years ago with bookkeeping. Users just don’t generate much data relative to the size of our disks. Well worth a watch, especially if you disagree: [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

Simple Made Easy ( [LINK] ) The Language of the System ( [LINK] ) The Value of Values ( [VIDEO] ) All by Rich Hickey (Clojure creator) - strongest programming speaker I've found to date.

is caching the correct analogy? the stars you see died eons ago. special relativity is your friend. we witness "immutability" casually. nothing in the relational model that i am aware of says that a materialized view cannot be a simple immutable table of "facts". same input same output. unambiguous. simply use the dynamic queries to summarize the "facts" in, typically, a small mat view tables and your gui will never lie. [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] [VIDEO]