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.
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.
> 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.
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:
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.
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.
> 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 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.
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.
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'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.
33 comments
[ 3.6 ms ] story [ 87.1 ms ] threadLifeBrush - Constructing an interactive cytoskeleton:
https://www.youtube.com/watch?v=6CsxADBpal0
>comment: I didn't realize that Bob Ross had gotten into bio-molecular organelle simulations.
Timothy Davidson's videos:
https://www.youtube.com/@TimothyDavison/videos
Timothy Davison:
https://timd.ca/
CellWalk for Apple Vision Pro:
https://www.youtube.com/watch?v=r8DOAPPjMw0
CellWalk:
https://cellwalk.ca/
Building Structural Models of a Whole Mycoplasma Cell:
https://www.sciencedirect.com/science/article/abs/pii/S00222...
The way it compiles to several other languages reminds me of Nim (which I rather like).
I think I'll give this a whirl.
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.
> 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.
[1] https://en.wikipedia.org/wiki/Cell_(processor)
Moveable Feast Machine:
https://movablefeastmachine.org/
Programming Soft ALife with SPLAT and Ulam:
https://www.livingcomputation.org/files/deck213-as-presented...
SPLAT repo:
https://github.com/DaveAckley/SPLAT
Cells in Cells in Cells:
https://www.youtube.com/watch?v=gv40Z9tVjAI
Spellular Automata:
https://www.youtube.com/watch?v=xvlsJ3FqNYU
NEW Cellular Automata:
https://www.youtube.com/watch?v=WMJ1H3Ai-qs
SandPond:
https://github.com/TodePond/SandPond
Live SandPond:
https://sandpond.cool/
TODEPOND TIMES: Nogan:
https://todepond.substack.com/p/todepond-times-nogan
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
GitHub: https://github.com/cell-lang/c-cpp/tree/master/src/compiler
Cell-Lang: Why relations are better than objects - https://news.ycombinator.com/item?id=38853961 - Jan 2024 (1 comment)
Cell Lang: Why yet another programming language? - https://news.ycombinator.com/item?id=31915925 - June 2022 (124 comments)
A comparison of Cell with OOP - https://news.ycombinator.com/item?id=20438931 - July 2019 (7 comments)
Cell – A functional, relational, reactive programming language - https://news.ycombinator.com/item?id=15797831 - Nov 2017 (64 comments)
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.
[1]: https://www.cell-lang.net/faq.html
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.
In blorq we have variable assignment:
And we have while loops: And we also have quantum polymorphic tensor hyper operators with optional effects: 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 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.
Loads of languages get this right. I gave some examples here: https://news.ycombinator.com/item?id=37805216
(And another language that gets it completely wrong - AngelScript.)
Why the relational model is better than objects
https://www.cell-lang.net/relations.html
Cell seems to hit a sweet spot here.
In any case, if you work on this, please reach out, I'd love to chat.