Announcing Neptune.jl (now updated to multi-line cells!)

Neptune.jl is effectively a lightweight variation on the Jupyter notebook theme, but written entirely in Julia, based on the package Pluto.jl, but not tied to the ‘reactive execution’ mission being pursued by the developers of Pluto.
[In simple terms, Neptune may be seen as Pluto for Data Scientists]

In terms of ‘feel’ Neptune behaves largely like a simplified version of Jupyter, and has been demonstrated to be ideal for teaching introductory Data Science classes. In conjunction with the Julia REPL, Neptune constitutes a very simple attempt at a lightweight native IDE for Julia.

Additionally, notebooks saved by Neptune may be executed as standard Julia scripts.

One limitation (currently under review) of Neptune as compared to Jupyter, is that cells are by default assumed to consist of a single line… muli-line cells must begin with ‘begin’ and finish with ‘end’.
[update: this has been fixed as of latest release 0.14.0]

44 Likes

Is there a reason why Neptune isn’t just a “mode” for Pluto and is instead a fork? I assume this will make it just diverge over time and give a lot of maintenance issues. I just don’t see the gain of a fork instead of just a button.

17 Likes

I think things are early enough that there is room for experimentation. I don’t consider all the design decisions (or infrastructure) made in Pluto to be settled matters, and hope to see many such experiments made. Will they all coalesce into one thing eventually? Hopefully. But for now I am happy to see more such things blossom.

1 Like

Based on the README, it seems that Pluto developers are not favorable to the existence of a Neptune option within Pluto.
Which is sad because Neptune does the exact one thing that I dislike in Pluto, that is executing sequentially one cell at a time rather than reactively (which can be a pain).

Thank you for the fork and I hope the development effort of both team will not be duplicated too much in the process.

11 Likes

I agree. Sometimes reactivity is a pain. During the development process, if several cells are all very time-consuming to run, then if I want to only test one of these cells, but due to reactivity, all these cells will run after updating their common dependencies, which is very annoying.

Another point I don’t like about Pluto is opening a notebook defaults to run all lines. If again the notebook costs a huge amount to run, then I will wait a very long time to be able to edit it. The simple workaround is just to open the .jl file and editing there.

14 Likes

See this for another possible solution to this problem that works within the framework of reactivity: Feature idea: a temporary execution barrier · Discussion #298 · fonsp/Pluto.jl · GitHub

5 Likes

I very much agree with this. I love the look of Pluto and I’m very grateful to the authors for creating the package, but for my style of development (typically testing out various analyses and models on moderately sized data), reactivity is more an obstacle than a help. I, too, find myself spending a lot of time waiting for my whole notebook to re-evaluate aft er changing a cell, when mostly what I want is to test out the change on small test data first. Of course, I could use the REPL and a traditional code editor for this, but I really like having the progress of some analysis “documented” through a notebook.
Hopefully there will be way for the two different approaches to co-exist within the Pluto eco-system somewhere in the future.

I think generally Pluto is a highly opinionated piece of software. It’s developers have strong feelings about how it should and should not be used and seem to aiming for a very curated, controlled experience. That’s great, but it’s not for everyone, so I’m very glad to see a fork being worked on.

There’s some great ideas in Pluto that I’d love to see be made more accessible.

15 Likes

I couldn’t find the PR for this discussion. Could you point me to where it was discussed that it couldn’t just be a mode?

Digging around a bit, there’s this conversation: where it appears there are some alternate ideas on the table like Feature idea: a temporary execution barrier · Discussion #298 · fonsp/Pluto.jl · GitHub, but Fons also affirms that he really doesn’t want non-reactivity and that “Pluto just might not be right for your use case”.

In particular, there’s this quote from Delay running the notebook when it starts · Issue #259 · fonsp/Pluto.jl · GitHub

Running cells one by one used to be the default (before d201517), but there were too many problems with this that we could not fix with friendly UI - the issue is that you launch your notebook into a broken state by default - running a cell might error depending on which cells you manually ran before. It had a lot of the same state problems as Jupyter that reactivity should solve. (The goal is not to make ‘Jupyter++’, but to try something else.)

7 Likes

Hi All, Thanks very much for your input. Given all the great work that went into Pluto, I would like nothing better than to work together with them, but (regrettably) the lead developer seems very hostile to this at the moment.

For now, I still intend to try to keep the saved notebook format consistent with Pluto, though I would like to make the ‘begin’ and ‘end’ in each cell implicit so multi-line cells would be allowed by default (like Jupyter), but where the ‘begin’/‘end’ would appear in any multi-line cells in the saved files (but not in the window), but would need technical help (and time) to achieve this.
Thanks!

16 Likes

What a remarkable idea. I am tired of writing begin…end stuff, which is not only tedious but has an extra unpleasant indent.

3 Likes

I am glad yo think so (thanks). I am eager to implement this, but have an extremely busy teaching schedule at the moment, and anyway would take a long time to do this, given it is not where my technical expertise lies.

Done: Allow multiple expressions at top level by MasonProtter · Pull Request #10 · compleathorseplayer/Neptune.jl · GitHub

14 Likes

Thanks so much! [Merged]

Unfortunate clash, but I chose Neptune because it is somewhere between Jupyter and Pluto, closer to the latter. :wink:

14 Likes

One of the things I really like about Pluto is that it’s reactive. Why would this be a problem for data scientists?

Absolutely. It would re-evaluate all cells every time any cell was changed/added/evaluated. In data science cells are often very time consuming. Also Data Science is by nature a sequential process. Why would you want it to be reactive?

1 Like

I prefer it to be reactive, because if I make a mistake or want to change something at the start of the code, it will change all of the lines dependent on it.