> The state of the application can be partitioned in separate components (called automata) that do not share any mutable state and can be safely updated concurrently.
This is the right direction! Pure computations on (somewhat) centralized data has proven to be very resilient to bugs. It's kind of like how React organizes its programs.
I like how Cell is tackling this problem at the language level. A language's programs will (in practice) often be a reflection of what the language makes easy and what it makes hard, so designing a language to handle this complexity would be a boon to the world.
Pony also has this via its `iso` keyword and actors [0]. Cone is also exploring this notion, with an interesting actor/async/await hybrid [1].
> 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.
This sounds like Vale's "Perfect Replayability" feature [2] which captures all IO for a program and deterministically replays it. It's an incredibly useful feature, and I hope Cell exposes it well!
> A language's programs will (in practice) often be a reflection of what the language makes easy and what it makes hard…
In industrial design this is called an affordance. The product is designed to encourage correct usage and make incorrect usage difficult. I would like it if more language designers will carefully consider their language’s features like this. The Elm language is a good example.
Ｉ think this may also be a good way to separate libraries from application code, by considering the library as another actor instead of a direct function call. We are allowed to panic within the same abstraction layer (application or in a library), but panic should not cause another application using it to abort, there should be a way to let the application recover from it and decide whether to cancel the operation or do other actions. If the mutable states are not shared and execution can be recorded, we can just restart the library after abort and resume to the previous state.
> and how tedious and time consuming it often is to implement even trivial things like sending data from the client to the server and vice-versa.
Let's be clear here, the complications there are as follows:
1. Authentication and permissions in regard to the end user who is making the change or fetching the data. (E.g. internal web app, the AWS hosted database has no knowledge of my corporate AD accounts)
2. Authentication/permissions of the service/software that is talking to the database
3. The crap tons of network problems and errors that can occur.
4. Dealing with other possible errors, such as malformed input, or data not being present, data being stale, write conflicts, etc.
5. My backend service is running in a private cluster and my DB is running in a different private cluster.
6. My backend service is running in a private cluster and because of that the nifty subscription DB engine can't try and reach out to reconnect to my service if something goes wrong with the connection because there isn't a routable IP address.
I think a more charitable interpretation would be that they're highlighting how much work has gone into that area (web server frameworks come to mind), compared to how little work they've seen on cleaner techniques and language assistance for managing local state.
That's how I read it at least, reasonable interpretations may differ.
> compared to how little work they've seen on cleaner techniques and language assistance for managing local state.
Literally every new web framework is some new take on how to manage local state.
You could spend an entire year learning about different state management solutions. From systems that keep backend and front end state in sync, to the entire redux/mobx family, to the stuff that Svelte does.
We are a long ways away from the bad old days of a global "state.c(pp)" file.
But I cannot agree. I am very down on this. I think this a colossal waste of time.
I do not see the problem they are trying to solve. Doing I/O is hard, not because sending bytes on a wire is hard but because of everything that can go wrong. It is the "everything that can go wrong" part that is hard.
They are going to solve the problem of state with "algebraic data types". That is not new. I am trying to think of a language at a higher level than machine code that does not use algebraic data types. ("Algebraic data types" are not an invention, they are a description)
I cannot see anything new in this. I fear it is another example of making easy things easier and pretend the hard things do not matter.
There have been huge strides in the development of computer languages in recent years. Rust, Go, Swift, Dart.... All of them with slightly different use cases and solving slightly different problems in slightly different ways. But the author knows of Closure... Yes, but.
"One can easily reconstruct the exact state of a Cell program at any point in time." Really? I spend my entire professional life doing exactly that, whatever the system I work in.
This is engineering with machines. State is part of the nature of those machines. It is very well understood and is not a problem (handling state) that we are struggling to solve.
Elm is very interesting. Also the evolution of Elm from something more resembling Reactive Extensions to the current, more opinionated Elm-Architecture version.
Also there is an Elm-Architecture clone in almost every language. You could also emulate it in React (probably using top level state, prop drilling and following the same patterns, typescript would help)
This looks very interesting. I'm curious if the author has looked at Erlang/Elixir — my first reaction on reading this is that it sounds similar to the actor model and the way that Erlang handles state and state updates: as messages to autonomous processes that are modeled as a continuous fold over the message stream.
I too am disappointed by the lack of innovation around state management in applications. But I don't think this solves the problem.
A lot of developers think what we need is additional abstraction on top of the way data is stored and retrieved, to remove all the annoying CRUD boilerplate that goes into building an app. This seems to make sense because devs think in terms of simple examples like TODO lists.
But in a real production application with heavy scale, you need a lot of low-level control over precisely how state is managed. Tweaking a SQL query or table structure can be the difference between minutes of latency and milliseconds.
I'm not sure what the path forward is here, but I hope smart people keep thinking about it.
We've also seen that sometimes working at a lower level can actually make performance worse; there are cases where eg. describing something abstractly to a smart compiler gives it more opportunities to optimize
Personally I think a better way is "high-level with trapdoors", where you can pierce the abstraction if you really need to spot-optimize but higher-level code is the norm
> But in a real production application with heavy scale, you need a lot of low-level control over precisely how state is managed.
Very much this. "State is managed automatically!" can very quickly become "this frequent operation is automatically doing a huge amount of DB work which should actually be deferred until later"
>Then there's support for reactive programming, which is still in its infancy
State management for UI I would think should be a first class objective rather than 3rd on the todo list. See SwiftUI for something evolving toward this direction.
>The best way to illustrate the advantages of functional/relational programming over OOP is through a case study
No, the best way is to be right up front with a real life common problems and code examples that make life better. I’d prefer not to read this many dry theoretical pages before seeing any of those.
I'm curious what kind of examples would be compelling. I'm writing a language which takes exceptional control over state (https://www.adama-platform.com/)
I've always been intrigued by the idea of a language that enforces a separation of queries and command. Functions (queries) return values and have no side-effects, where procedures (commands) that can have side-effects and don't return a value.
Readit News
This is the right direction! Pure computations on (somewhat) centralized data has proven to be very resilient to bugs. It's kind of like how React organizes its programs.
I like how Cell is tackling this problem at the language level. A language's programs will (in practice) often be a reflection of what the language makes easy and what it makes hard, so designing a language to handle this complexity would be a boon to the world.
Pony also has this via its `iso` keyword and actors [0]. Cone is also exploring this notion, with an interesting actor/async/await hybrid [1].
> 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.
This sounds like Vale's "Perfect Replayability" feature [2] which captures all IO for a program and deterministically replays it. It's an incredibly useful feature, and I hope Cell exposes it well!
[0] https://tutorial.ponylang.io/reference-capabilities/referenc...
[1] https://cone.jondgoodwin.com/
[2] https://verdagon.dev/blog/perfect-replayability-prototyped
In industrial design this is called an affordance. The product is designed to encourage correct usage and make incorrect usage difficult. I would like it if more language designers will carefully consider their language’s features like this. The Elm language is a good example.
Let's be clear here, the complications there are as follows:
1. Authentication and permissions in regard to the end user who is making the change or fetching the data. (E.g. internal web app, the AWS hosted database has no knowledge of my corporate AD accounts)
2. Authentication/permissions of the service/software that is talking to the database
3. The crap tons of network problems and errors that can occur.
4. Dealing with other possible errors, such as malformed input, or data not being present, data being stale, write conflicts, etc.
5. My backend service is running in a private cluster and my DB is running in a different private cluster.
6. My backend service is running in a private cluster and because of that the nifty subscription DB engine can't try and reach out to reconnect to my service if something goes wrong with the connection because there isn't a routable IP address.
Writing data to a table isn't the problem!
That's how I read it at least, reasonable interpretations may differ.
Literally every new web framework is some new take on how to manage local state.
You could spend an entire year learning about different state management solutions. From systems that keep backend and front end state in sync, to the entire redux/mobx family, to the stuff that Svelte does.
We are a long ways away from the bad old days of a global "state.c(pp)" file.
I do not see the problem they are trying to solve. Doing I/O is hard, not because sending bytes on a wire is hard but because of everything that can go wrong. It is the "everything that can go wrong" part that is hard.
They are going to solve the problem of state with "algebraic data types". That is not new. I am trying to think of a language at a higher level than machine code that does not use algebraic data types. ("Algebraic data types" are not an invention, they are a description)
I cannot see anything new in this. I fear it is another example of making easy things easier and pretend the hard things do not matter.
There have been huge strides in the development of computer languages in recent years. Rust, Go, Swift, Dart.... All of them with slightly different use cases and solving slightly different problems in slightly different ways. But the author knows of Closure... Yes, but.
"One can easily reconstruct the exact state of a Cell program at any point in time." Really? I spend my entire professional life doing exactly that, whatever the system I work in.
This is engineering with machines. State is part of the nature of those machines. It is very well understood and is not a problem (handling state) that we are struggling to solve.
Very interesting concept!
Although I do wonder if this couldn't be implemented as a library for an existing language.
Doesn't seem like it is actively developed though, the compiler repo hasn't seen updates since November and the runtime repo since 2018.
It definitely could. So could Elm, which — nonetheless — is an interesting and useful language (bordering on DSL).
Also there is an Elm-Architecture clone in almost every language. You could also emulate it in React (probably using top level state, prop drilling and following the same patterns, typescript would help)
A lot of developers think what we need is additional abstraction on top of the way data is stored and retrieved, to remove all the annoying CRUD boilerplate that goes into building an app. This seems to make sense because devs think in terms of simple examples like TODO lists.
But in a real production application with heavy scale, you need a lot of low-level control over precisely how state is managed. Tweaking a SQL query or table structure can be the difference between minutes of latency and milliseconds.
I'm not sure what the path forward is here, but I hope smart people keep thinking about it.
Personally I think a better way is "high-level with trapdoors", where you can pierce the abstraction if you really need to spot-optimize but higher-level code is the norm
Very much this. "State is managed automatically!" can very quickly become "this frequent operation is automatically doing a huge amount of DB work which should actually be deferred until later"
State management for UI I would think should be a first class objective rather than 3rd on the todo list. See SwiftUI for something evolving toward this direction.
>The best way to illustrate the advantages of functional/relational programming over OOP is through a case study
No, the best way is to be right up front with a real life common problems and code examples that make life better. I’d prefer not to read this many dry theoretical pages before seeing any of those.
That is exactly what a case study is. Looking at examples of real world cases.
It is possible to present common problem scenarios and examples up front, even if something is at the idea stage.
It’s commonly done, and can be an effective way of conveying your ideas and getting feedback without pages on end of speculative requirements.
And im having a bunch of fun with it now that I popping up the stack in UI. My docs have a minimal tic-tac-toe ( http://book.adama-platform.com/examples/tic-tac-toe.html )
The pure query inside a command might still add cost to the command though.