JupyterLab: the next generation of the Jupyter Notebook • Hacker News Board

Re: JupyterLab: the next generation of the Jupyter Notebook

#101

Post by nikitakit » Fri, Jul 15, 2016, 7:41 PM UTC

bicubic wrote: post #54

nl wrote: post #49

Earlier quoted context omitted.

Context: We use Jupyter heavily (mostly against Spark). In my experience there is a set of things that "traditional" Jupyter notebooks does really well. Anytime you have a linear flow of steps the notebook metaphor works really well. However, if you are doing things approaching traditional development, where you have multiple sources of data, or loops that require debugging, or basically anything that isn't linear in…

My experience is in line with yours, debugging loops and functions is a big pain point. However, I think there's a much better solution to be had here, which is to add more powerful debugging capabilities to Notebook. I think Notebook has potential for new debugging paradigms, imagine for example being able to break anywhere in a cell and get a new 'forked cell' which operates in the context of the code that you just…

I agree, the notebook could really have much more powerful debugging.

I've actually been working on implementing something to that effect for Python (see http://kitaev.io/xdbg). But it's been really hard to figure out who already has experience with similar workflows, because these tend to be isolated to particular language or devtools communities.

Apparently I need to take a closer look at Smalltalk.

Re: JupyterLab: the next generation of the Jupyter Notebook

#102

Post by beevai142 » Fri, Jul 15, 2016, 7:59 PM UTC

pmoriarty wrote: post #50

hatmatrix wrote: post #47

Earlier quoted context omitted.

There's also an emacs extension that allows it to work with Jupyter http://millejoh.github.io/emacs-ipython-notebook/ (I personally haven't used it.)

I've used it. It's great when it works. But often it doesn't. That extension needs some serious tlc before it achieves its potential, which is huge.

I've also used it for the past months (latest version at MELPA), and haven't had any problems. Much preferable to the jupyter browser interface, no browser keybindings etc. web page stuff getting in the way.

Re: JupyterLab: the next generation of the Jupyter Notebook

#103

Post by marmaduke » Fri, Jul 15, 2016, 8:48 PM UTC

p4wnc6 wrote: post #91

soVeryTired wrote: post #57

Earlier quoted context omitted.

Can you elaborate on what you think is bad about the IDE-with-extras-plus-console framework? I do research in quantitative finance and I actually find it really useful.

One of the main things is that it continues to perpetuate primarily mouse-driven interaction with the development environment. Even when tools like this enable Emacs or vi key configurations, the integration just never quite works, and there are environment-specific options you are required to select that come from e.g. drop-down menus, etc. Interacting with UI elements is horrendously unproductive and disruptive to…

Looks like you're over thinking it a little. It's just a tool.

Re: JupyterLab: the next generation of the Jupyter Notebook

#104

Post by p4wnc6 » Fri, Jul 15, 2016, 9:01 PM UTC

marmaduke wrote: post #103

p4wnc6 wrote: post #91

Earlier quoted context omitted.

One of the main things is that it continues to perpetuate primarily mouse-driven interaction with the development environment. Even when tools like this enable Emacs or vi key configurations, the integration just never quite works, and there are environment-specific options you are required to select that come from e.g. drop-down menus, etc. Interacting with UI elements is horrendously unproductive and disruptive to…

Looks like you're over thinking it a little. It's just a tool.

It's a bad tool. It's important to contemplate what is a good tool and what is bad tool -- and to avoid using bad tools when you are able.

Re: JupyterLab: the next generation of the Jupyter Notebook

#105

Post by jasongrout » Fri, Jul 15, 2016, 9:33 PM UTC

p4wnc6 wrote: post #104

marmaduke wrote: post #103

Earlier quoted context omitted.

Looks like you're over thinking it a little. It's just a tool.

It's a bad tool. It's important to contemplate what is a good tool and what is bad tool -- and to avoid using bad tools when you are able.

One of the things about JupyterLab is that it really emphasizes extending and customizing the environment. Think of it as a platform for web-based applications and a reference set of components. We've tried hard to make the underlying platform have good support for power users. We've paid a lot of attention to making a good keyboard shortcut system, for example. I think it makes a lot of sense for someone to write a plugin for the system that registers keyboard shortcuts for doing tab management, maybe in the vein of a tiling window manager. Also, it would take changing only a few lines of code to move the file browser from the left side panel to the main docking area - it's just a widget that is registered on the left side panel rather than the main area.

We also encourage people to theme the environment, and provide themes via plugins. I think theming things with a lot more minimal whitespace would be an interesting project for users like you.

Also, for a power user, I'd definitely suggest running it in the browser application mode, which gets rid of lots of the browser chrome.

Remember - it's an alpha-level project, we're still experimenting a lot, especially on the user experience and UI. JupyterLab was built to be easily extensible and customizable, and we encourage people to experiment with customizing the environment in a way that suits them. And we appreciate feedback as well! Thanks!

Re: JupyterLab: the next generation of the Jupyter Notebook

#106

Post by clishem » Sat, Jul 16, 2016, 12:10 AM UTC

jasongrout wrote: post #99

(disclaimer: I'm one of the authors of the scipy talk the post is about...) First: JupyterLab is definitely still alpha-level software, and is undergoing very rapid iteration. I notice that a lot of comments are missing one of the most important ideas behind JupyterLab. It's built on a very flexible plugin framework (provided by PhosphorJS), and all components are provided as plugins. JupyterLab essentially is a refe…

Thanks for the video. Looks really great!

One thing I missed is a more detailed discussion of the Command palette. Will it also be extensible? Can plugins add their own commands to it for example?

Re: JupyterLab: the next generation of the Jupyter Notebook

#107

Post by clishem » Sat, Jul 16, 2016, 12:12 AM UTC

IshKebab wrote: post #59

drauh wrote: post #32

Beaker Notebook (posted several times, but without much attention[0]) does something similar: http://beakernotebook.com/features It supports these languages: Python, Python3, R, JavaScript, SQL, C++, Scala/Spark, Lua/Torch, Java, Julia, Groovy, Node, Ruby, HTML, and Clojure. It has an experimental native version: https://github.com/twosigma/beaker-notebook/wiki/Electron-Be... Talk at SciPy 2015: https://www.youtube.c…

Does Electron really count as 'native'?

Definitely not in my book.

Re: JupyterLab: the next generation of the Jupyter Notebook

#108

Post by nl » Sat, Jul 16, 2016, 2:11 AM UTC

p4wnc6 wrote: post #91

soVeryTired wrote: post #57

Earlier quoted context omitted.

Can you elaborate on what you think is bad about the IDE-with-extras-plus-console framework? I do research in quantitative finance and I actually find it really useful.

One of the main things is that it continues to perpetuate primarily mouse-driven interaction with the development environment. Even when tools like this enable Emacs or vi key configurations, the integration just never quite works, and there are environment-specific options you are required to select that come from e.g. drop-down menus, etc. Interacting with UI elements is horrendously unproductive and disruptive to…

I generally much prefer GUI tools to command line tools. I've been working as a software developer for 20 years, so it isn't that I don't know the command line.

I find GUIs generally allow for better discoverablity and I much prefer switching browser tabs to switching tmux/screen terminals.

Perhaps it is possible that different people work in different ways? Maybe the things you are thinking of 'wrong' actually just don't work for you, but really do for others?

For example I know how to use a debugger. I've written my own custom debugging clients, and attached IDEs to live production webservers and debugger code live, so I really do know what I'm doing. But sometimes I prefer outputting data into an Excel spreadsheet because it gives me better context. Sometimes that really is the right tool for the job.

Also, get more, bigger screens. It's made a huge difference for me.

Re: JupyterLab: the next generation of the Jupyter Notebook

#109

Post by jasongrout » Sat, Jul 16, 2016, 1:49 PM UTC

clishem wrote: post #106

jasongrout wrote: post #99

(disclaimer: I'm one of the authors of the scipy talk the post is about...) First: JupyterLab is definitely still alpha-level software, and is undergoing very rapid iteration. I notice that a lot of comments are missing one of the most important ideas behind JupyterLab. It's built on a very flexible plugin framework (provided by PhosphorJS), and all components are provided as plugins. JupyterLab essentially is a refe…

Thanks for the video. Looks really great! One thing I missed is a more detailed discussion of the Command palette. Will it also be extensible? Can plugins add their own commands to it for example?

That's the only way commands are added. Every command on there was added by a plugin. You can see a simple example in the about plugin: a command is created at https://github.com/jupyter/jupyterlab/blob/6d540709ad64e7767..., and is added to the command palette at https://github.com/jupyter/jupyterlab/blob/6d540709ad64e7767....

Re: JupyterLab: the next generation of the Jupyter Notebook

#110

Post by jasongrout » Sat, Jul 16, 2016, 1:52 PM UTC

glup wrote: post #97

sorenjan wrote: post #6

I love Jupyter notebooks, I just wish I could use them in a dedicated program instead of having to run a server and using a browser based client. It feels hacky and I just prefer native apps for coding and the browser for reading documentation and similar. Even an Electron based program that could be associated with notebook files and hide the server-client model would make it nicer to use. At the moment I like to op…

Solution to related but different problem: I have too many projects with several notebooks that make window management a pain (two dozen browser tabs in a browser I would like to use for other things). My solution in OS X is to use the ancient-but-venerable Fluid app as a wrapper for each project, so I can treat it like a native Mac application. One can open as many new window in Fluid as you like, so one can have cl…

That's a cool idea. If you launch the browser in application mode, does it do the same thing (i.e., appear to the OS as a separate application with window grouping?)

We hope to support tearing out tabs into new child windows, so you can have multiple OS window panes associated with the single jupyterlab page that is running.