Ironically, it actually has more global state than Jupyter. The way that they make it feel like it doesn't have state is by adding more state. It's pretty clever actually.

I think the key is that the state is not hidden: what you see is what you get.

There is indeed hidden state in a Pluto notebook. Look at the .jl file it generates, there is hidden state there describing the cell ordering.

But those are comments (non-executable) that keep track of the order in which the cells are presented in the notebook. There is no hidden state relevant to the computation.

Those comments control how information is presented to you and are state from the point of view of the notebook. However, the comments are not the only hidden state in pluto.

Beyond that, Pluto has a huge amount of state that's hidden from you in that it tries to keep track of all the variables you define and where so that it can control which cells need to be re-run when you change something. This lets it avoid re-running all the cells when you make a slight adjustment.

However, yes I agree. As I originally said, they added state that makes it work more like it doesn't have state. Or in other words, they solved Jupyter's state problem by adding more state.

You are talking about state relevant to the implementation. OP was talking about state from a conceptual point of view. To the user there is no state. The user does not need to keep track of what they evaluated and in what order as in Jupytr. That is a kind of state that exits conceptually and which is very visible to the user.

That's what I've been saying in this thread the entire time. It adds extra state so that it feels like there's less state.

I disagree on your second paragraph. It's literally true but that state, again, has no bearing on the actual result of the computation. It's just an optimization.

There is no hidden state in the editor that can change the values between runs.

It may be that we are using the word in different senses, but I would say that Pluto has no hidden state whatsoever. The comments for cell ordering control what you see, so they are the opposite of hidden state. The execution order is determined by a static analysis of the dependencies among your code cells, and is determined only by what you see in those cells. There is no hidden state anywhere.

That's to make sure the generated .jl file executes correctly (since that does still run in a linear fashion). It doesn't correspond to the cells index; moving a cell does not change the exported .jl file.

Does this mean that if we change the .jl file in an editor it becomes unreadable by Pluto? That would contradict the claim in the article that Pluto files are just regular julia files.

If you change it the .jl file in a editor you could quite easily make it unreadable to pluto.

> That would contradict the claim in the article that Pluto files are just regular julia files.

Not really, no. The files pluto generates are a subset of valid julia files. All Pluto files are valid julia files; not all valid julia files are valid Pluto files.