Yuuughk
Clojure’s Approach to Identity and State (2008)
41–50 of 69 posts
Re: Clojure’s Approach to Identity and State (2008)
#42Immutability is very helpful, and the connection between values and identity is illuminating. But there have been very important developments in programming languages since this post/page was written: notably, the introduction of "borrow checking" (exemplified by Rust's implementation). Borrow checking has a very significant positive effect on the sustainability of imperative code, which makes the claim that "imperat…
The borrow checker comes with different trade-offs though, which I personally find, for many applications, the immutable data-structure + atomic references with GC route (or values over time semantics) is a better fit.
The way you are forced to model things so that the borrow checker can successfully validate your code can often be frustrating, and it also comes at the cost of slow compile times and interactive programming, which Clojure is kind of a champion at, so I'm not sure it would be a good fit to add a borrow checker to it.
I love the borrow checker for manually managed memory though, and for programs that need that kind of performance and tight memory usage, it is great. I've been following along the development of Carp because of that and my preference of Lisps: https://github.com/carp-lang/Carp
Re: Clojure’s Approach to Identity and State (2008)
#43Earlier quoted context omitted.
I was at the exact same spot, apart from my (not purely rational) dislike of OOP. I was envisioning a STM-based concurrency mechanism along with collections with value semantics. Spoiler: today I write quite a bit of Clojure.
Can you give me the ELI5 on STM & the Actor model? The article points out why Actor has issues, but I don't fully understand STM.
Identities change their associated values (state) by transactions. That means that from the viewpoint of concurrent observers (threads), partial or interrupted updates are never seen - the update is either 0% or 100% completed.
In Software Transactional Memory, that can be accomplished with atomic swaps. In Clojure, a new value, no matter how large, is constructed and the transaction is completed by repointing a mutable reference (ref or atom) to the new value atomically. Clojure has plenty of tools for constructing such transactions, such as `update-in` [1].
In order to make this work well, we need to be able to make collections behave like values. So, when you associate a value to a key in a Clojure collection, the original collection is unmodified and a new version is returned. This plays well into updating collections with STM - you just swap the root reference to a new collection.
Any transactions must be indempotent, that is, not touch the program state in any way, just produce a new value - because the STM system might need to retry the transaction. Retries happen when multiple threads try to modify a bit of shared state. In Clojure, `swap!` [2] is the actual mutation bit. You provide the transaction function to `swap!`, which produces a new value from the current state of a mutable reference. If, during the computation, another thread has swapped in a new value, the transaction is retried based on that updated value. On some architectures, this system can be implemented without locks, using the atomic compare-swaps of the hardware. The happy path of no conflicts is very efficient, while a heavily contested updates will result in redundant discarded (due to retry) transactions.
Please let me know if I can better explain anything!
Re: Clojure’s Approach to Identity and State (2008)
#44Earlier quoted context omitted.
IIUC Rich Hickey probably did just that too, writing ad-hoc version of clojure semantics in cpp before making his own language enforcing this.
I recall he was big into SBCL, but most IT organizations wanted all code to run on the JVM or CLR. So he had to make a Lisp to run on the JVM and Armed Bear Common Lisp apparently wasn't exactly what he wanted. I want to learn Clojure, but there are definitely some road blocks. I don't have the time for Emacs, it'd be a pain to get a Cursive license (although the cost is extremely reasonable I'd have to do paperwork…
In addition to the editors others have suggested, I've been quite happy writing Clojure in Sublime Text. In ST, you might want the lispindent and paredit plugins on top of the main Clojure plugin.
Re: Clojure’s Approach to Identity and State (2008)
#45Earlier quoted context omitted.
Borrow checking and immutability solve two different problems. Immutability is about the absence of ownership and state, while borrow checking is a way to manage ownership. One does not replace the other, they coexist solving different problems.
Borrow checking allows even structures that support mutation to be safely (checked by the compiler) treated as immutable, and thus as values. Clojure also recognizes the connection between ownership and mutability in its "transients": https://clojure.org/reference/transients ... compile time borrow checking extends that idea to an entire language.
Nice explanation
Re: Clojure’s Approach to Identity and State (2008)
#46Earlier quoted context omitted.
I want to hear more about your somewhat optimizing compiler for spreadsheets!
It's proprietary for the time being; but in short, it is more straightforward than I thought it would be. We are working with LibreOffice Calc ODS sheets, which are pretty terrible as a format (since the references are not normalized in the formulas, they can't repeat them even when they behave identically, and they duplicate most of the XML namespaces in the attributes). We parse and normalize the references from A1…
Interesting project! Could you explain what you mean by "since the references are not normalized in the formulas, they can't repeat them even when they behave identically"? Do you mean the normalization from A1 to R1C1 that you mention later in the post or something else?
Re: Clojure’s Approach to Identity and State (2008)
#47Earlier quoted context omitted.
Visual Studio Code, Atom and Vim also have great Clojure support. (edit: might be worth to add editors and IDEs to the Clojure landing page to illustrate that there are many solid options by now) With ClojureScript you can leverage JavaScript runtimes like browsers. The ClojureScript testsuite also passes using the recently released hermes runtime ( https://twitter.com/mfikes/status/1149360258994847745 ) edit: Just w…
I'll have to check out the Atom and VSCode options. Thanks for the heads up. Basically all I need is paredit, some basic intellisense, and be able to see the project heirachy. I like the idea of Clojurescript, but don't currently have any reason to do web development.
If that's all you need, I think Nightcode will do: https://sekao.net/nightcode/
It's a simple Clojure IDE written in Clojure.
Re: Clojure’s Approach to Identity and State (2008)
#48Immutability is very helpful, and the connection between values and identity is illuminating. But there have been very important developments in programming languages since this post/page was written: notably, the introduction of "borrow checking" (exemplified by Rust's implementation). Borrow checking has a very significant positive effect on the sustainability of imperative code, which makes the claim that "imperat…
So if I have mutable array in rust in state A and I start writing state B i to it from the back end in one thread, and reading the state A from the front in another thread - am I guaranteed to read actual state A or will I read a mix of A and B?
Re: Clojure’s Approach to Identity and State (2008)
#49Just learning about immutable/functional approach makes you better developer even in imperative languages. “Share nothing” (in a mutable way) is beautifully simple solution to so many concurrency problems.
Re: Clojure’s Approach to Identity and State (2008)
#50Immutability is very helpful, and the connection between values and identity is illuminating. But there have been very important developments in programming languages since this post/page was written: notably, the introduction of "borrow checking" (exemplified by Rust's implementation). Borrow checking has a very significant positive effect on the sustainability of imperative code, which makes the claim that "imperat…
Borrow checking and immutability solve two different problems. Immutability is about the absence of ownership and state, while borrow checking is a way to manage ownership. One does not replace the other, they coexist solving different problems.
One of the reasons that immutability gets pushed is that it solves concurrency's shared mutable state problem, which is exactly the same problem that borrow checking is meant to solve.