This is already a thing in Clojure/Script, using datalog instead of SQL. Syncing datoms between Datascript (and/or Datahike [0]) on the front-end and Datomic on the back-end can be almost trivial, and there are libraries like Datsync for that [1].
This reminds me of open-ui [1]. The goal of that project is also to tackle fragmentation and allow interoperability between component frameworks and design systems. How does UI Playbook compare to it? Do you think collaboration between the two projects would make sense?
You can also check out shadow-cljs which has great support for React Native development. I've been able to easily keep my project up to date with the latest React Native versions. Plus with shadow-cljs you also get access to all of npm in a very straight forward way.
i'm seconding this. not only react native version that re-natal supports is old but also the re-frame & reagent versions it supports are pretty old. shadow-cljs is really a good solution and you can pick it up for react-native projects too.
I agree that the experience of querying EAV databases using SQL can feel cumbersome [0]. But Datomic's dialect of Datalog [1] is a great fit for EAV and can produce much more readable and simpler queries.
I install and experiment with Mezzano once or twice a year. Very cool project.
I liked most of the LispOS paper. One point of disagreement is planning for multi-user capability. I don’t think a LispOS based system would ever be more than a personal and highly customizable workspace. I would never expect to fire up a VPS on AWS or GCP and see a LispOS option next to Linux, BSD, etc.
I used a Xerox 1108 Lisp Machine from 1982 to about 1986. I stopped using it and gave it to someone else in my company when I was able to port the ISI Grapher to Coral Common Lisp on my Mac and thereby was able to port most of my code over.
To be clear, I moved off of the 1108 only because the hardware had become outdated and it ran too slowly. Otherwise I was very happy with a single user all Lisp work environment.
" point of disagreement is planning for multi-user capability. "
Multiuser tends to go hand in hand with other things, like good security though. No doubt a modern single user system could avoid the mistakes of Windows etc. But as you're already going most of the way there, why not just build multiuser in from the start?
I'm sure Mr Torvalds never expected to fire up a VPS and have the option of Linux along side big and professional OSes like GNU and Unix.
This is similar to TempleOS where the creator wanted to make a powerful sport bike of an OS and didn't bother implementing multiuser functionality.
I agree and wish an OS was turtles all the way down with extensive scientific computing builtin. How many layers of indirection do I need? I'm stuck on Windows so I have to deal with that, .NET, Python, and numeric software like Mathematica, as well as the 50 bazillion programs I use ...all with fragile interfaces. Maybe that only seems suboptimal though and a true LispOS and Smalltalk OS running on baremetal would never truly work with the general populace?
> Maybe that only seems suboptimal though and a true LispOS and Smalltalk OS running on baremetal would never truly work with the general populace?
Been thinking about this a lot lately. What would a regular laptop user, say, or advanced user (office worker etc) need at a minimum to start using such a system? Probably just a functioning web browser and office suite. So long as any given LispOS/SmalltalkOS had those, and a working UI, I think it could actually work.
We have many more common and widely adopted standards now (XML formats, JSON, hell TCP/IP!) than we did back in the 70s and 80s when PCs were much more diverse and exotic -- and hence incompatible. Most things are compatible these days. This in theory gives us tremendous advantage when it comes to experimenting with new viable systems, don't you think?
I've been working on a fantasy console, which touches on this "design down" space. It's the kind of endeavor that lets me iteratively redesign to go deeper and deeper into the stack, by starting off with "scripting plus some kind of I/O", gradually extending the concept, and then, more recently, to shift towards using WASM, memory maps, a BIOS layer, and an emulator UI layer, giving me more spec clarity.
The I/O boundaries and resource limits are the really important bits: A web browser is ultimately just a bundle of I/O functions buried inside specialized feature APIs, with only some very specific "patch this" limits for maximum resource consumption. This has allowed the size of web apps to creep upwards indefinitely while not being able to actually do every task, because the feature APIs sandbox in a haphazard "intended for the average consumer" way. When you add in comprehensive limits, the design and the software built on it are able to last: it's the lack of limits that has always created software crises.
One could imagine, instead of the browser as a lowest-common-denominator sandbox, a fantasy system specialized "for text editing", which has a different spec from one specialized "for 3D graphics": This would narrow the scope of sandboxing, make it easier to task-optimize, and yet also create the need for a Lisp or Smalltalk type of system that needs flexibility "for prototyping". It's not an unreasonable path, considering how broader trends in computing are leading towards hardware specialization too.
We need a lot of the features of a modern multi-user operating system to safely implement a modern JavaScript web browser, though. Perhaps so many that adding multi-user on later would not be much more work.
Although, I think my default idea of a separation kernel plus (runtime/VM here) + (Camkes or Cap n Proto) for glue would work for LISP images, too. Throw in VLISP for as much component reliability as you get flexibility.
Advent of Computing (The history of computing.)
Very Bad Wizards https://www.verybadwizards.com/
Notion Tools & Craft
Software Engineering Daily
The Array Cast
The REPL
The Idea Store