4 ms·

The issue with CLI is it's crap for editing the code. It's rare that your data analysis will just be one-liners, it'll be some mess of steps and you want to go

The issue with CLI is it's crap for editing the code. It's rare that your data analysis will just be one-liners, it'll be some mess of steps and you want to go edit one in the middle (but not re-run the whole script). That's the first thing that the notebooks give you that you don't tend to get elsewhere. The second thing is the presentation of the plots: it's really handy to have multiple interactive plots laid out right next to the code block that produced them. There's nothing that requires that this is done in a web interface, but no-one seems interested in making a non-web version (IIRC there was a QT version in the very very early days of ipython notebook but it's long dead). One big thing that any replacement will need is the easy ability for the code to actually be running on a remote machine, something that's trivial for a web interface but requires active effort for a native client (and makes a lot of interactive chart work more difficult: certainly there's currently no other matplotlib backend which can do it). I'm fairly sure a better interface than jupyter is possible for data exploration, but I haven't found one yet since there's not really anything else that gives you the two features above. (one thing people often miss about notebooks and the kind of work that go into them is that the code itself isn't actually really hard code. It's 100% about interacting with the data and the algorithms running on it. Working in one isn't much like software engineering)

fock 2y ago
> It's rare that your data analysis will just be one-liners, it'll be some mess of steps and you want to go edit one in the middle (but not re-run the whole script. And that's why I use elpy to execute codeblocks marked by comments in IPython. VSCode supports this workflow out of the box (but you don't get the matplotlib windows out of the box ;)) - although it is very, very liberal in using screenspace... > One big thing that any replacement will need is the easy ability for the code to actually be running on a remote machine VSCode remote (proprietary sadly). Also tramp + SSH-X-forwarding likely beats whatever ergonomics jupyterlab offers.
jofer 2y ago
You're not editing code in the CLI. You're editing code in your preferred editor/IDE. ipython + %edit works wonders. That's one of the main reasons to avoid notebooks and stick with CLI-based or similar tools. Jumping into the middle of a script and editing is often a bit dangerous. You usually wind up with something that can't be reproduced, as it depends on modifying state in a way that wasn't recorded. You do often need some sort of caching during exploration, for sure (it's not really feasible to wait an hour every time you want to tweak a visualization), but it's often better to break pipelines up a bit and do disk I/O rather than leaning on cells in a notebook. I do agree on the remote client part, though. Browser-based interactivity often is a good solution for a dev instance + a local thin client. It's slower than native for a local solution, though.

fock 2y ago

> It's rare that your data analysis will just be one-liners, it'll be some mess of steps and you want to go edit one in the middle (but not re-run the whole script. And that's why I use elpy to execute codeblocks marked by comments in IPython. VSCode supports this workflow out of the box (but you don't get the matplotlib windows out of the box ;)) - although it is very, very liberal in using screenspace... > One big thing that any replacement will need is the easy ability for the code to actually be running on a remote machine VSCode remote (proprietary sadly). Also tramp + SSH-X-forwarding likely beats whatever ergonomics jupyterlab offers.

jofer 2y ago

You're not editing code in the CLI. You're editing code in your preferred editor/IDE. ipython + %edit works wonders. That's one of the main reasons to avoid notebooks and stick with CLI-based or similar tools. Jumping into the middle of a script and editing is often a bit dangerous. You usually wind up with something that can't be reproduced, as it depends on modifying state in a way that wasn't recorded. You do often need some sort of caching during exploration, for sure (it's not really feasible to wait an hour every time you want to tweak a visualization), but it's often better to break pipelines up a bit and do disk I/O rather than leaning on cells in a notebook. I do agree on the remote client part, though. Browser-based interactivity often is a good solution for a dev instance + a local thin client. It's slower than native for a local solution, though.