Any thought on getting rid of "cell" concept?

[Hoc Phan]

I understand why we have "cells" and the separation of individual executions as well as content vs. code. But please hear me out. Could Jupyter Notebook be better with this:

1. User can execute line by line or via line selection (like Rstudio).

2. If any given line has some sort of output, just output right below that line or a separate panel (again, sort of line Rstudio).

3. Get rid of Markdown inside notebook concept. People can use comment.

4. Therefore, each notebook format is no longer a JSON file with embedded base64 (graph). It's just pure R or Python or Scale code --> easy to use Git for commits.

5. Render or output results could be store in a separate file such as test.py (code) and test.json (results)

6. Instead of dealing with moving cells, cut and paste cells,... Notebook could be just a regular IDE

So I am sure this idea has been brought up before in multiple chunks and threads. BUT it's 2016 and I like to hear this recurring theme if it's still applicable (or people sort of accept things).

Please don't yell at me ;-)

[Kyle Kelley]

Couple approaches to this:

* Use Hydrogen in Atom for inline display - https://github.com/willwhitney/hydrogen

* Rely on ipymd as your backing document - https://github.com/rossant/ipymd

It's completely appropriate to make alternative frontends that explore the approach you're outlining. Maybe that will take off.

I'm going to continue to want to use cells as part of a literate document, complete with Markdown and my inline plots. That's what has made sharing easy (even if making a lot of things harder, like git and storage in general).

--
You received this message because you are subscribed to the Google Groups "Project Jupyter" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jupyter+u...@googlegroups.com.
To post to this group, send email to jup...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jupyter/7679b694-66ae-4c98-8909-8ce2c3cdbf29%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Kyle Kelley (@rgbkrk; lambdaops.com)

[Brian Granger]

Whlie we aren't going to get rid of notebooks as we have them today,
the new JupyterLab UI we are building will offer a lot, if not all, or
even more, of the experiences you are asking for.

> --
> You received this message because you are subscribed to the Google Groups
> "Project Jupyter" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jupyter+u...@googlegroups.com.
> To post to this group, send email to jup...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jupyter/7679b694-66ae-4c98-8909-8ce2c3cdbf29%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--

Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgra...@calpoly.edu and elli...@gmail.com

[Thomas Kluyver]

On 5 February 2016 at 22:12, Hoc Phan <quan...@gmail.com> wrote:

I understand why we have "cells" and the separation of individual executions as well as content vs. code. But please hear me out. Could Jupyter Notebook be better with this:

1. User can execute line by line or via line selection (like Rstudio).

2. If any given line has some sort of output, just output right below that line or a separate panel (again, sort of line Rstudio).

3. Get rid of Markdown inside notebook concept. People can use comment.

4. Therefore, each notebook format is no longer a JSON file with embedded base64 (graph). It's just pure R or Python or Scale code --> easy to use Git for commits.

5. Render or output results could be store in a separate file such as test.py (code) and test.json (results)

6. Instead of dealing with moving cells, cut and paste cells,... Notebook could be just a regular IDE

The notebook format certainly has its disadvantages, but it also has some very real advantages. We're not going to throw it away to make yet another IDE instead.

[Hoc Phan]

I saw the JupyterLab discussion and this note https://github.com/jupyter/roadmap but it seems to heavily focus on frontend. 

I was hoping to focus on the core of what the Notebook could be and less "co-mingle" of HTML/JS/CSS to its backend. If such separation is clear, a frontend developer (like myself) could write or customize the UI as needed. I mean I was trying to customize Notebook as I see fit but ran into many obstacles (e.g. https://github.com/jupyter/notebook/issues/1033) that shouldn't be there. IMHO there are many other great frontend developers that can help.

[Zelphir Kaltstahl]

I don't see how removing the very nice ability to document source code with Markdown and Latex Math mode will help to improve notebooks. I'd certainly not like to read mathematical formulas inside Python comments. That would be very unreadable. There is also HTML output of cells, which is persisted in the notebook's JSON afaik, so it's not suddenly all only Python or R or whatever source code if you remove Markdown. It is also the visualizations of already computed things, which is persisted. That in itself is quite important if you have lengthy calculations and simply want to show a notebook without rerunning the computations.

With the other parts I can agree. Running selected code could be a great feature. However, I like the ability to separate "computation ideas" / "steps" by using separate code cells and putting Markdown documentation of what I am doing in between the code cells.

[Lawrence D’Oliveiro]

On Saturday, February 6, 2016 at 11:12:35 AM UTC+13, Hoc Phan wrote:

4. Therefore, each notebook format is no longer a JSON file with embedded base64 (graph).

What “base64 (graph)” -- you mean cell output? Always clear all cell output before committing the notebook to your repo. Problem solved.