LWN: Comments on "An introduction to Pluto"

Deploying software used by the notebook

fonsp — Tue, 29 Jun 2021 17:12:16 +0000

Hi civodul!

This is indeed a major limitation of current systems, and I have been working hard on embedding the Julia package environment (Project.toml and Manifest.toml) directly into the notebook file: https://github.com/fonsp/Pluto.jl/pull/844 This means that packages will be installed or removed automatically as you use them in code, and others can exactly reproduce your package environment. Currently in beta, will be released in the next month!
- fons (author of Pluto 🎈)

Online hosting service

EPo — Sun, 07 Feb 2021 00:13:51 +0000

What could help wider adoption is some online service that rendering Pluto notebooks. This probably requires a lot of resources and some corporate support, but would be very welcome. I think of Observanke and many Jupyter-based or similar dervices like Deepnote, Cocalc, Google Colab. Also would binder render a Pluto notebook? If notebook result ifs HTML maybe there can be a clever Github Actions pipeline to show it as well?

Deploying software used by the notebook

civodul — Fri, 27 Nov 2020 14:25:29 +0000

Another limitation of Jupyter (and of Pluto, as I understand it) is that it does not take software deployment into account, although software used by the notebook obviously influences the end result — starting with the Python/Julia version being used.

We proposed a way to annotate a Jupyter notebook with reproducible "deployment info" here: https://hpc.guix.info/blog/2019/10/towards-reproducible-j... .

Is the Pluto project considering ways to address this issue?

An introduction to Pluto

ballombe — Mon, 09 Nov 2020 14:41:54 +0000

> the hidden global state is a fundamental flaw in the Jupyter execution model.

Agreed. This makes Jupyter (and maple, etc.) problematic for teaching mathematics because students will invariably manage to put
the worksheet in an inconsistent state and will accept the incorrect result as true 'since the computer says it'.
Then follows an awkward discussion with the teacher.

An introduction to Pluto

osma — Sat, 07 Nov 2020 10:55:48 +0000

Software engineer here. I use Jupyter notebooks a lot for data analysis, exploration and prototyping. Eventually I might turn some of the code in the notebooks into "proper" code such as Python modules. But it's just so much easier to do the prototyping in an environment where you can load stuff into memory, try many different ways of exploring it (without having to load it again!), test different variations of an algorithm etc. without having to start your program from scratch all the time and have it fail after 15 minutes of number-crunching due to an edge case you forgot to consider.

Notebooks are also good for explaining algorithms, since you can intermix runnable code with structured documentation, figures etc.

An introduction to Pluto

jezuch — Thu, 05 Nov 2020 17:55:37 +0000

Well, I've never been a lab scientist and nevertheless I don't share the confusion. But I also find the concept enticing and I've been previously exposed to Stephen Wolfram's writing, so...

Here's one data point :)

How is the dependency graph constructed?

leephillips — Thu, 05 Nov 2020 13:29:28 +0000

Recalculation through the dependency graph is not triggered by mutation of existing objects, so a running a cell that has a[3] = 17 will not have any effect on other cells. One is obligated to, as you say, explicitly assign to an object. This may require additional expressions in the code that would not be present in “normal” code, but those would not change the computation, but only exist to trigger recalculation through the graph. It’s kind of an awkward aspect of the dependency graph model, but easy to get around. It’s the way this type of reactivity works. When using JavaScript reactive libraries, you sometimes have to put things like a = a in your (JavaScript) code after mutating a, to force a recalculation by explicitly having the variable on the LHS of an assignment.

The computational model does not depend on Julia, and in fact is similar to Observable, a notebook for JavaScript that uses the same type of dependency graph analysis. But other aspects, especially, apparently, in the future, may depend more closely on Julia and further ways the developers find to integrate it with JavaScript to evolve the interface.

Oh, and you’re most welcome.

How is the dependency graph constructed?

marcel.oliver — Thu, 05 Nov 2020 13:01:49 +0000

First, thanks for the article. The hidden state problem as well as compatibility with version control are huge issues for current notebook interfaces. (In my opinion, poor compatibility with version control is the bigger one - I know there are workarounds, but getting project members to use version control is often already an uphill battle, so any additional hoops that one has to jump through are typically not practical.)

With regards to Pluto, I am still puzzled how the dependency graph is constructed. If order of cells does not matter, that would mean either that changes to a data structure in a different cell need to be done via creation of a new object, or that the dependencies would need to be declared explicitly. From the article ("Therefore one is not allowed to define a global variable in more than one cell"), it seems that it is the former. But it's not only "defining a global variable", any write access to an object would need to be confined to a single cell. So that seems far from being able to write a generic program in Pluto notebook style, or am I missing something? It would also seem to constrain what can be done in interactive exploration. Here I am not sure what the real impact would be, but it certainly requires a change of mindset compared to working in other notebook-style interfaces.

I also wonder how much conceptually depends on specific features of the Julia language, or whether it could be implemented in just the same way for other languages (Scientific Python user here...)

An introduction to Pluto

wjt — Thu, 05 Nov 2020 11:08:36 +0000

Another implementation of this spreadsheet-style notebook-with-dependency-graph concept is Observable, by the authors of the popular D3.js data visualisation library. JavaScript's not my particular cup of tea, but spending a little time with Observable last year convinced me that the Pluto authors are right: the hidden global state is a fundamental flaw in the Jupyter execution model.

Spreadsheets are probably the most widely-used programming environment, despite their own flaws, so tools which bridge the gap between that and "real" structured programming environments are (IMO) important.

An introduction to Pluto

spacefrogg — Thu, 05 Nov 2020 09:59:16 +0000

None of this if true, obviously. I now need a ridiculously large code stack, reading input, converting into JS/HTML, sending it over network (!), receiving, maintaining a secure session to the frontend (!), storing in my own data format, maintaining / communicating state between frontend and backend... to implement an editor.

Yes, you seriously, seriously want to have the renderer of the web browser, but that's it. You don't want to have any of the other parts.

Web browsers are notoriously bad at text entry. They are worse than 80's GUIs. And Chrome will never be good at text entry because they lock most of the interesting keyboard shortcuts and text buffer management actions.

Standards-based: Well the author of the article is not and maybe will never be able to use his favorite standards-compliant browser. So, no. It's not standards-based.

Everyone has a web browser: First, as per the article's author, it was easy to beat to not have the right one. Second, try sending your notebook to your colleague and see if they can open it. They shall be able to play with the data, right? They can't, because they still need Pluto (and start it as an extra step) next to the humongous piece of the "right" web browser just to look at your stuff (let alone playing around). How can this be progress?

Cross-platform: Well, it's only as cross-platform as Pluto, because you still need it. Unless you seriously want to work over network. In which case you (aka. someone who likes you enough) still need the second system running Pluto. So, no, the frontend has nothing to do with platform independence.

The 'final form'

epa — Thu, 05 Nov 2020 09:56:37 +0000

I think it's just the meaning of the word 'final'. I was interpreting it that if the final form is a PDF, you publish the PDF, your work is finished, and you can now delete the notebook. (And that means that if there are any corrections or retractions, those would be published as errata to the PDF rather than as changes to the original notebook.) Whereas I would see the PDF as ephemeral, published so that people can read it easily as you say, but the final record for posterity needs to include the original notebook. Because archaeologists in the future might not have Pluto installed, it makes sense to include a PDF in the final result too, I'll grant you that.

An introduction to Pluto

Paf — Thu, 05 Nov 2020 01:13:28 +0000

Think of this as a way to produce a scientific paper where someone else can reach in and immediately explore and change the data processing.

A step towards a sort of WYSIWYG editor for scientific papers *including the data processing steps within the scope of the editor*. So I can try a new fit function for the data in a plot and it’s just immediately there in its full context. Or something close to that. And I can do it with *your* paper that you sent me.

An introduction to Pluto

Paf — Thu, 05 Nov 2020 01:04:10 +0000

Excuse me, *text* document.

An introduction to Pluto

Paf — Thu, 05 Nov 2020 01:03:38 +0000

It’s not an ugly substitute. This is fundamentally a tool for dynamic, on the fly, data analysis and visualization. It’s a tool for supporting scientific research and especially for generating scientific papers in a way that others can interact with the results.

Nuggets of random code stuck to spreadsheets and separate data visualizations with the results pasted in to an eventual test document are in fact an ugly substitue for this, for the job this is intended to do.

It’s like, a “light” scientific computation tool. It’s not for heavy duty number crunching in the sense of high performance computation (often simulation) and “big data”. It’s for light to medium weight computational work and presenting data to people.

If it helps, most of these started as tools for biologists. They need to do a *lot* of data manipulation but most of their stuff isn’t heavyweight physical simulation. It’s data processing, and the data sets aren’t necessarily that large. (Though some are.)

An introduction to Pluto

Paf — Thu, 05 Nov 2020 00:56:27 +0000

I think this indicates you’ve never been a working scientist (no offense is intended). This is like a *lab* notebook, and as someone who used to be a working scientist, a sort of programmable lab notebook, with calculations included, is an *incredibly* enticing concept.

An introduction to Pluto

Cyberax — Wed, 04 Nov 2020 22:09:09 +0000

Spreadsheets don't really support scientific visualizations, graphing libraries and TeX rendering.

An introduction to Pluto

khim — Wed, 04 Nov 2020 21:56:39 +0000

But you can use "real" programming language with "real" spreadsheet (I know that because I often do that)… so why the ugly substitute?

An introduction to Pluto

otaylor — Wed, 04 Nov 2020 20:15:15 +0000

The problem disappears of you always run all cells from top to bottom, which is not hard to do, but Jupyter makes it even more easy to run selected cells one by one as users see fit. It's one of the main criticisms of Jupyter.

It's worth noting that (especially for scientific computations) some of the initial steps in your notebook might be very slow, so not always running from the top makes work much faster. Reinteract (https://www.reinteract.org/) tried to achieve stateless notebooks with partial re-execution for Python, but I abandoned it, among other reasons, because it was really hard to get things to work sensibly with the full Python ecosystem. (If a user changes f.write('foo') to f.write('bar') then you have to go back and replay things from the point where you opened a file for writing.)

Julia is likely easier to build this type of system on top of - I'll have to look at the implementation of Pluto one day.

An introduction to Pluto

NYKevin — Wed, 04 Nov 2020 19:35:58 +0000

> Why would anyone in their senses resort to a web browser to do their coding?

This is not targeted at software engineers. It's targeted at data scientists, statisticians, and other scientific types who need to do a lot of number crunching. They don't want to spend three hours configuring Emacs, and then another three hours un-learning all the standard keyboard shortcuts used by every text editing program created within the past ~20 years. But it gets worse than that. If you ask them about design patterns (or higher-order functions, or polymorphism, or... insert your favorite concept here), many will have no idea what you're talking about, and those that are familiar with such concepts tend not to use them much in practice. Their code tends to be highly procedural and ugly, so much so that many are too embarrassed to publish it. Switching editors is not going to change that.

Basically, what these people really want is a spreadsheet. Spreadsheets are much more forgiving of weird or irregular organization of program logic, and make it simple and intuitive to reason about how data flows through the system. But regular spreadsheet software isn't powerful enough for their needs, in multiple senses of the word "powerful" (i.e. flexible, computationally efficient, "there isn't a function for that," etc.). So what you end up with is a custom spreadsheet-like-thing that lets you use one or more "real" programming languages. I really don't see anything wrong with that.

The 'final form'

rgmoore — Wed, 04 Nov 2020 17:56:57 +0000

I think the final form should depend on who it's being prepared for. It's great to share a notebook with another data analyst, and the notebook should be included as part of any paper that's published based on it. But a lot of the work in data analysis is performed by analysis specialists for people who don't know enough about programming to make use of a notebook if they had it; most of my- admittedly limited- use has fallen into that category. People like that want a finished product like a PDF or HTML format notebook rather than instructions on how to generate that product.

To use an analogy, the notebook is like a recipe, and the PDF or HTML format is like a prepared dish. It's great that some people are good enough cooks to be able to prepare the dish themselves when presented with ingredients and a recipe, but not everyone is like that. Plenty of people aren't great cooks and just want to eat the dish. A well designed system should be able to accommodate both types.

Notebook diffs

fghorow — Wed, 04 Nov 2020 16:55:13 +0000

+1 for Jupytext. It allows a style of programming in Jupyter that I've wanted for years -- where I can fluidly move between a browser based notebook and the editor/IDE of my choice for actually _working_ on the code in a reasonable environment.

Pluto sounds pretty good from that viewpoint also. However, Pluto's "single backend" (i.e. Jupyter kernel) is a dealbreaker for me.

An introduction to Pluto

leephillips — Wed, 04 Nov 2020 14:11:54 +0000

"The Pluto authors claim, we'd have to leave a polyglot environment behind us just to describe their support for JS and HTML next to Julia. How is that not polyglot?"

HTML and JS are already running in the browser. The idea is to use them to further elaborate the interface. They are not back-end languages.

An introduction to Pluto

leephillips — Wed, 04 Nov 2020 13:46:35 +0000

Pluto's reactive model is similar to a spreadsheet.

An introduction to Pluto

leephillips — Wed, 04 Nov 2020 13:43:16 +0000

You seem to be equating "state" and "hidden state".

An introduction to Pluto

clugstj — Wed, 04 Nov 2020 13:29:38 +0000

"In Jupyter, when a cell is executed, the result appears, and nothing else happens. Any global variables defined in the cell are available for subsequent execution of other cells. The variables can be redefined freely. The upshot is that the output of any particular cell execution depends on a hidden global state: which cells were previously executed and in what order.

Pluto, instead, analyzes the code in all of the cells and constructs a dependency graph, so that it knows the order in which the cells must be executed; this is based on which cells use which variables. Cells can be grabbed with the mouse and arranged in any order and this has no effect on the results. When the code in a cell is changed, the cell is run; all of the cells that depend on it, and only those cells, are also run, in dependency order. Therefore one is not allowed to define a global variable in more than one cell; an attempt to do so results in an error message."

So, Pluto is a spreadsheet and Jupyter is a broken spreadsheet?

An introduction to Pluto

rschroev — Wed, 04 Nov 2020 13:19:48 +0000

By hidden state, they mean something else. I think I can best explain it with an example.

In a Jupyter notebook, make a cell containing "a = 0" and run that cell.
Then make a cell containing "print(a)", and run it. It will output "0";
Make a third cell containing "a = 1" and run it.
Now run the second cell again. It will now output "1".

You now have a notebook looking like this:

a = 0

print(a)
-> 1

a = 1

You can now delete the third cell, making it even more confusing. In this example it's obvious that a might have an unexpected value, but in real notebooks the value of a often just used in calculations, not printed, making it unclear on exactly which values the calculation is based.

The problem disappears of you always run all cells from top to bottom, which is not hard to do, but Jupyter makes it even more easy to run selected cells one by one as users see fit. It's one of the main criticisms of Jupyter. I haven't read the article, but it looks like the Pluto authors have managed to avoid the problem altogether in Pluto.

An introduction to Pluto

roc — Wed, 04 Nov 2020 11:38:17 +0000

Web browsers give you a cross-platform, standards-based implementation of scriptable, editable documents that support mixing text, graphics, video and more, with extremely well optimized and robust implementations. Also, everyone has a web browser preinstalled. That's hard to beat.

An introduction to Pluto

roc — Wed, 04 Nov 2020 11:33:43 +0000

"Notebook" as the name for a ... book of notes ... long predates and is much more common than its use as "small laptop".

The 'final form'

gdt — Wed, 04 Nov 2020 10:40:13 +0000

The motivation for PDF is the ability to read it in the future. A reference which is a DOI to a PDF is a far more likely to be found and read than a hyperlink to some ancient software's savefile. Of course, why not both?

Notebook diffs

lobachevsky — Wed, 04 Nov 2020 10:23:26 +0000

There is also Jupytext (https://github.com/mwouts/jupytext) for having Jupyter notebooks in plain text format.

An introduction to Pluto

spacefrogg — Wed, 04 Nov 2020 10:13:22 +0000

A lot of things don't make sense to me in this article:

The Pluto authors claim, we'd have to leave a polyglot environment behind us just to describe their support for JS and HTML next to Julia. How is that not polyglot?

The Pluto authors claim that the notebook won't have hidden state just to describe that they can keep state in the DOM between notebook updates. How is that stateless? Nobody, who is serious about programming, wants a stateless program. We need obvious (impossible) and precise (hard but achievable) control of the state, not statelessness. So, having stateful program and keeping the program and its results in the same notebook, must result in a stateful notebook. State must be made _manageable_.

Emacs features org-mode and org-babel. They can at least do what Pluto is able to do. (Not to brag but as a reference.) So, there may be no need to change the environment when to change the mode of work.

Why would anyone in their senses resort to a web browser to do their coding? This is why editors actually have the interface they do. Because it's a _good_ interface for coding. Why throw all this work away? What is the gain in the Pluto (or Jupyter) approach? I don't get it.

An introduction to Pluto

NAR — Wed, 04 Nov 2020 09:24:52 +0000

The English word "notebook" is seriously overloaded... Every time I read about this stuff on LWN, my first thought is that this is some kind of physical device, a laptop. The "computational" prefix doesn't really help. Maybe it's not that confusing for native speakers.

The 'final form'

epa — Wed, 04 Nov 2020 09:22:49 +0000

before the notebook is exported into the final HTML or PDF form

Perhaps we need to get away from that? The final published form should be the notebook itself, since from the notebook you can generate printed text but the reverse is not true.

I would expect a dead-tree book to include a link to download the notebook, and if reading in electronic form, the best reading interface is the Pluto notebook interface itself, perhaps with a style sheet for prettier display and a read-only mode to avoid accidental changes.

Notebook diffs

boog — Wed, 04 Nov 2020 00:28:38 +0000

The nbdime package helps in using version control with Jupyter notebooks.

https://nbdime.readthedocs.io/en/latest/