Some years back I spent a lot of time reading these docs and playing with some core examples and corresponded some with the developer behind the project.
I think inductive, reactive, programming patterns have a lot of promise for building more composable software. This project is I think no longer maintained, but it should hopefully serve as inspiration for language designers.
I've looked briefly into this project before. Some ideas are similar to what I'm doing in https://github.com/purpleidea/mgmt/ but the really weird thing is that I have no idea who's behind this language. A person? A company? A small group? Are they anonymous for some reason or am I oblivious?
In any case, if you work on this, please reach out, I'd love to chat.
I wrote some large TCL applications between 2005 and 2015 that used an in-memory SQLite database to store the bulk of the data model. Indeed, having a relational model was a huge win...except for some patterns (tree structures, certain kinds of polymorphism) where it was an enormous pain.
I'm building a puzzle room type experience with some friends. There are sensors and actuators that need to be controlled according to some logic. My read of these docs is that this might be a good fit for something like that.
The way it compiles to several other languages reminds me of Nim (which I rather like).
You should go simple and pick something like Python, add some unit tests to check your logic is sound. Everyone would understand Python, easy to edit and update.
> Systems like these are difficult to fit into the rigid, sequential execution model of imperative languages. The traditional way to implement them involves the use of threads, observers, callbacks and timers. The resulting code is typically error prone, brittle and unnecessarily complex.
Python is really not very good at this kind of thing and neither are most other conventional languages.
Erlang is the only language that comes to mind that can handle this stuff at scale.
Sure, if you have a fast enough machine and not too many asynchronous things going on, you might be able to hack something up in Python. But it's not gonna scale at all well.
I'm not saying that this language is good at it, mind you -- I haven't even looked at it -- but they definitely have a point here.
If I must have a central server and database then I'll totally do it that way.
The question is whether I can go without the centralization entirely and just have the devices (which are Arduino grade and not running python anyway) talk to each other.
It sounded to me like a cellular automata programming language, like Dave Ackley's "SPLAT" for the Moveable Feast Machine, or Lu Wilson's Sandpond visual CA programming language:
I don't know. Programming languages are super high dimensional objects that are often used to construct non-trivially sized and scoped projects. For something like that I think you need to take your time, read the manual, and do some r&d to see if it's a fit.
In blorq we have variable assignment:
var x = 5;
And we have while loops:
while true {
x += 1;
}
And we also have quantum polymorphic tensor hyper operators with optional effects:
|> ~$~ |] <coherence 0.7 [deflects]>
It's like, the simple stuff doesn't really tell me anything. And the complex stuff is going to take a lot more than seeing the example to know how I should feel about it.
Cell, I suspect, is in the category of needing at least an afternoon to get started.
> It's like, the simple stuff doesn't really tell me anything.
It tells you loads.
* The basic syntax is C-like but modern (no brackets around the `while` expression). There are alternatives - it could have been lispy or more ML like.
* You can mutate variables.
* You have some weird advanced hieroglyphic features.
You only used 5 lines and you've already told me loads.
As far as I'm concerned, reactive state management is a solved problem. Use SQLite for everything, or Postgres if you outgrow it. Does it require a bunch of glue code? Depends on the language, but let's say it does. This orthogonal persistence layer of Cell's is guaranteed not to do a fifteenth of what SQLite does, so either you lose out on it, or you're back to square one with the glue code.
I think you're too quickly dismissing the potential benefits. From the FAQ[1]:
The combination of all the above properties, plus the fact that I/O is also separate from pure computation and updates, enables a number of features that are not found in conventional languages.
The first one is the ability to "replay" the execution of a Cell program. One can easily reconstruct the exact state of a Cell program at any point in time. Obviously that's very useful for debugging, but there are others, more interesting ways of taking advantage of that. It's for example possible to run identical replicas of the same Cell process on different machines over a network, and that's something that will be crucial in Cell's future network architecture.
The second one is orthogonal persistence, that is, the ability to take a snapshot of the state of the application (or part of it), which can then later be used to create with minimal effort an identical copy of it, that will behave in exactly the same way. In Cell, you don't save your data the way you do it in conventional languages. Instead, you simply declare which parts of your application's data structures have to be persisted, and the compiler generates for you all the code needed to save and load them.
Is it as robust as using a mature technology like SQLite? Obviously, no. But these are interesting ideas that lead somewhere new.
When you want quick response to keypress, and yet app state also depends on high-latency ML pose or gesture analysis waiting on camera frames, and spoken "Launch the missiles!" can become "Lunch is mussels! In butter!", replay with improved understanding of past input is nice.
> Use SQLite for everything, or Postgres if you outgrow it.
Or both! I've followed ElectricSQL for a while and it's pretty awesome to see how they've approached it. Rest APIs replaced with client side SQLlite which syncs to server side postgres over a CRDT layer that you don't actually have to touch/know anything about. And they just rebuilt postgres on pure WASM (https://github.com/electric-sql/pglite).
It's just cool to think that maybe you don't have to do design all of these intricate REST apis and just call SQL.
I think inductive, reactive, programming patterns have a lot of promise for building more composable software. This project is I think no longer maintained, but it should hopefully serve as inspiration for language designers.
LogicBlox was (is?) a larger scale commercial system based on similar ideas: https://en.wikipedia.org/wiki/LogicBlox