3 ms·

I've never used unison but I've used other, more traditional, REPL-based languages (think, Mathematica or Common Lisp with SLIME). To me one of the biggest prob

by EdiX 2y ago

I've never used unison but I've used other, more traditional, REPL-based languages (think, Mathematica or Common Lisp with SLIME). To me one of the biggest problems with that style of programming is that sometimes code that you have changed on disk persists in the memory image, in the form of closures, creating unexplainable "ghost bugs" that disappear when you restart the REPL (or worse, that will only appear after you restart the REPL). This system with making code immutable and storing it into a database makes me think somebody noticed how much of a footgun this behavior of REPLs is and thought... "mmmmhh what if we added a second barrel to the gun so that you can be sure to always shoot your own feet?"

pchiusano 2y ago
I know what you mean with those other tools, but this doesn't happen in Unison. The reason those systems are somewhat flaky is that the cache of what's in memory can diverge from the "source of truth" which is a bag of constantly mutating text files. Maybe put another way, cache invalidation is hard in those systems. When the source of truth is instead a database, content-addressed by hash, cache invalidation is simple - if the hash has changed, a cached result is invalid and needs recomputing. If the hash is the same, you're good. We use this approach in many places throughout Unison and it's quite robust.
nerdponx 2y ago
This is why I never fully embraced to the REPL-driven development style espoused by CL users. Even if I am using hot reloading during my development workflow, I never keep a long-running development image and I never expect to distribute or run that image as the finished product. I always build a fresh clean image/executable (eg via ASDF) and run a separate test suite. Interestingly this problem has arisen more recently in the Jupyter notebook ecosystem, and is being rediscovered by a generation of non-programmer data analysts / scientists and the programmers that need to support them. Some interesting solutions like "reactive" notebooks have arisen out of that. It would be very interesting to have something like that for Common Lisp. Maybe Mathematica already has it.

by EdiX 2y ago

pchiusano 2y ago

I know what you mean with those other tools, but this doesn't happen in Unison. The reason those systems are somewhat flaky is that the cache of what's in memory can diverge from the "source of truth" which is a bag of constantly mutating text files. Maybe put another way, cache invalidation is hard in those systems. When the source of truth is instead a database, content-addressed by hash, cache invalidation is simple - if the hash has changed, a cached result is invalid and needs recomputing. If the hash is the same, you're good. We use this approach in many places throughout Unison and it's quite robust.

nerdponx 2y ago

This is why I never fully embraced to the REPL-driven development style espoused by CL users. Even if I am using hot reloading during my development workflow, I never keep a long-running development image and I never expect to distribute or run that image as the finished product. I always build a fresh clean image/executable (eg via ASDF) and run a separate test suite. Interestingly this problem has arisen more recently in the Jupyter notebook ecosystem, and is being rediscovered by a generation of non-programmer data analysts / scientists and the programmers that need to support them. Some interesting solutions like "reactive" notebooks have arisen out of that. It would be very interesting to have something like that for Common Lisp. Maybe Mathematica already has it.