Thank you, Fernando.<br><br>Very comprehensive responce - appreciated it. I wish to have it before I have started my parallel evaluation of SAGE and iPython notebooks. SAGE system is greate for some users, for others (like me) iPython is the way to go and your responce prowide greate details why. I think only one item is missing in iPython notebook which is present in SAGE notebook - support of Cython with same level of easiness. Hopefully, we will see that feature sometime later. <br>
<br>I support an idea of having your responce as a blog.<br><br>Cheers,<br>Oleg <br><br><div class="gmail_quote">On Sat, Jan 7, 2012 at 8:26 PM, Fernando Perez <span dir="ltr">&lt;<a href="mailto:fperez.net@gmail.com">fperez.net@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<div class="im"><br>
On Thu, Jan 5, 2012 at 8:06 PM, Oleg Mikulchenklo &lt;<a href="mailto:olmikul@gmail.com">olmikul@gmail.com</a>&gt; wrote:<br>
&gt; What is relation and comparison between iPython notebook  and SAGE notebook?<br>
&gt; Can someone provide motivation and roadmap for iPython notebook as<br>
&gt; alternative to SAGE notebook?<br>
<br>
</div>Let me try to provide some perspective on this, since it&#39;s a valid<br>
question that is probably in the minds of others as well.  This is<br>
just *my* take on it, and other devs are welcome to pitch in as well<br>
with their view.  Apology in advance, this is quite long, but I&#39;m<br>
trying to do justice to many years of development, multiple<br>
interactions between the two projects and the contributions of many<br>
people.  I apologize in advance to anyone I&#39;ve forgotten (but please<br>
do correct me as I want to have a full record that&#39;s reasonably<br>
trustworthy).<br>
<br>
Let&#39;s go back to the beginning: when I started IPython in late 2001, I<br>
was a graduate student in physics and had used extensively first<br>
Maple, then Mathematica, both of which have notebook environments.  I<br>
also used Pascal (earlier) then C/C++, but those two (plus IDL for<br>
numerics) were the interactive environments that I knew well, and my<br>
experience with them shaped my view.  In particular, I was a heavy<br>
user of the Mathematica notebooks and liked them a lot.<br>
<br>
I started using Python in 2001 and liked it, but the interactive<br>
prompt felt like a crippled toy compared to the systems above or to a<br>
Unix shell.  When I found out about sys.displayhook, I realized that<br>
by putting in a callable object, I would be able to hold state and<br>
capture previous results for reuse.  I then wrote a python startup<br>
file to provide these features, giving me a &#39;mini-mathematica&#39; in<br>
python by also loading Numeric and Gnuplot.  Thus was my<br>
&#39;ipython-0.0.1&#39; born, 259 lines to be loaded as $PYTYHONSTARTUP.  In<br>
case you are curious, I&#39;m attaching it here, it&#39;s kind of funny that I<br>
can &#39;release&#39; IPython 0.0.1 as an email attachment...<br>
<br>
I also read an article<br>
(<a href="http://onjava.com/pub/a/python/2001/10/11/pythonnews.html" target="_blank">http://onjava.com/pub/a/python/2001/10/11/pythonnews.html</a>) that<br>
mentioned two good interactive systems for Python, LazyPython and IPP.<br>
 I contacted their authors,  Nathan Gray and Janko Hauser, seeking to<br>
join forces to create IPython together.  They were both very gracious<br>
and let me use their code, but didn&#39;t have the time to participate in<br>
the effort.  As any self-respecting graduate student with a<br>
dissertation deadline looming would do, I threw myself full-time into<br>
building the first &#39;real&#39; IPython by merging my code with both of<br>
theirs.  Eventually I did graduate, by the way.<br>
<br>
The point of this little trip down memory lane is to indicate that<br>
from day 1, Mathematica and its notebooks (and the Maple worksheets<br>
before) were in my mind as my &#39;ideal&#39; environment for daily<br>
computational scientific work. In 2005 we had two Google SoC students<br>
and we took a stab at building, using WX, a notebook system.  Robert<br>
Kern then put some more work into the problem, but unfortunately that<br>
prototype never really became fully usable.<br>
<br>
In early 2006, William Stein organized what was probably the first<br>
Sage Days at UCSD and invited me; William and I had been in touch<br>
since 2005 as he was using IPython for the sage terminal interface.  I<br>
suggested Robert come as well, and he demoed the notebook prototype he<br>
had at that point.  It was very clear that the system wasn&#39;t<br>
production ready, and William was already starting to think about a<br>
notebook-like system for sage as well. Eventually he started working<br>
on a browser-based system, and by Sage Days 2 in October 2006, as<br>
shown by the coding sprint topics<br>
(<a href="http://wiki.sagemath.org/sd2-sprint" target="_blank">http://wiki.sagemath.org/sd2-sprint</a>), the sage notebook was already<br>
usable.<br>
<br>
Sage going at it separately was completely reasonable and justified:<br>
we were moving slowly and by that point even we weren&#39;t convinced the<br>
wx approach would go anywhere. William is a force of nature and was<br>
trying to get sage very usable very fast, so building something<br>
integrated for his needs was certainly the right choice.<br>
<br>
We continued working on ipython, and actually had another attempt at a<br>
notebook-type system in 2007. By that point Brian and Min had come on<br>
board and we had built the Twisted-based parallel tools. Using this,<br>
Min got a notebook prototype working using an SQL/SQLAlchemy backend.<br>
Like Sage this used a browser for the client but retained the &#39;IPython<br>
experience&#39;, something the Sage notebook didn&#39;t provide.<br>
<br>
This is a key difference of our approach and the Sage nb, so it&#39; worth<br>
clarifying what I mean: the Sage notebook took the route of using the<br>
filesystem for notebook operations, so you can&#39;t meaningfully use &#39;ls&#39;<br>
in it or move around the filesystem yourself with &#39;cd&#39;, because sage<br>
will always execute your code in hidden directories with each cell<br>
actually being a separate subdirectory.  This is a perfectly valid<br>
approach and lets the notebook do many useful things, but it is also<br>
very different from the ipython model where we always keep the user<br>
very close to the filesystem and OS.  For us, it&#39;s really important<br>
that you can access local scripts, use %run, see arbitrary files<br>
conveniently, as in data analysis and numerical simulation we make<br>
extensive use of the filesystem.  So the sage model wasn&#39;t really a<br>
good fit for us.<br>
<br>
Furthermore, we wanted a notebook that would provide the entire<br>
&#39;IPython experience&#39;, meaning that magics, aliases, syntax extensions<br>
and all other special IPython features worked the same in the notebook<br>
and terminal.  The sage nb reimplemented some of these things in its<br>
own way: they reused the % syntax but it has a different meaning, they<br>
took some of the ipython introspection code and built their own x?/??<br>
system, etc. In some cases it&#39;s almost like ipython, in others the<br>
behavior is fairly different, which is fine for Sage but doesn&#39;t work<br>
for us.<br>
<br>
So we continued with our own efforts, even though by then the Sage<br>
notebook was fairly mature by this time.  For a number of reasons (I<br>
honestly don&#39;t recall all the details), Min&#39;s browser-based notebook<br>
prototype also never reached production quality.<br>
<br>
Eventually, in 2009 we were able to fund Brian to dig into the heart<br>
of the beast, and attack the fundamental problem that made ipython<br>
development so slow and hard: the fact that the main codebase was an<br>
outgrowth of that original merge from 2001 of my hack, IPP and<br>
LazyPython, by now having become an incomprehensible and terribly<br>
interconnected code with barely any test suite.  Brian was able to<br>
devote a summer full-time to dismantling these pieces and reassembling<br>
them so that they would continue to work as before (with only minimal<br>
regressions), but now in a vastly more approachable and cleanly<br>
modularized codebase.<br>
<br>
This is where early 2010 found us, and then zerendipity struck: while<br>
on a month-long teaching trip to Colombia I read an article about<br>
ZeroMQ (<a href="http://lwn.net/Articles/370307" target="_blank">http://lwn.net/Articles/370307</a>) and talked to Brian about it,<br>
as it seemed to provide the right abstractions for us with a simpler<br>
model than Twisted.  Brian then blew me away, by writing in just two<br>
days a new set of clean Cython-based bindings: we now had pyzmq!  It<br>
became clear that we had the right tools to build a two-process<br>
implementation of IPython that could give us the &#39;real ipython&#39; but<br>
communicating with a different frontend, and this is precisely what we<br>
wanted for cleaner parallel computing, multiprocess clients and a<br>
notebook.  When I returned from Colombia I had a free weekend and<br>
drove down to his place, and in just two days we had a prototype of a<br>
python shell over zmq working, proving that we could indeed build<br>
everything we needed.<br>
<br>
Shortly thereafter, we had discussions with Enthought who offered to<br>
support Brian and I to work in collaboration with Evan Patterson, and<br>
build the Qt console using this architecture.  Our little prototype<br>
had been just a proof of concept, but this support allowed us to spend<br>
the time necessary to apply the same ideas to the real IPython. Brian<br>
and I would build a zeromq kernel with all the IPython functionality,<br>
while Evan built a Qt console that would drive it using our<br>
communications protocol.  This worked extremely well, and by late 2010<br>
we had a more or less complete Qt console working.<br>
<br>
In October 2010 James Gao (a Berkeley neuroscience graduate student)<br>
wrote up a quick prototype of a web notebook, demonstrating that the<br>
kernel design really worked well and could be easily used by a<br>
completely different client.  And then in the summer of 2011, Brian<br>
took James&#39; prototype and built up a fully working system, this time<br>
using the Tornado web server (which ironically, we&#39;d looked at in<br>
early 2010 as a candidate for our communications, but dismissed it as<br>
it wasn&#39;t really the tool for that job), JQuery, CodeMirror and<br>
MathJax.  That&#39;s the notebook that we then polished over the next few<br>
months to finally release in 0.12.<br>
<br>
As this long story shows, while it&#39;s taken us a very long time to get<br>
here, what we have now makes a lot of sense for us, even considering<br>
the existence of the Sage notebook and how good it is for many use<br>
cases.<br>
<br>
Our notebook is just one particular aspect of a much larger and richer<br>
architecture built around the concept of a Python interpreter<br>
abstracted over a JSON-based, explicitly defined communications<br>
protocol (<a href="http://ipython.org/ipython-doc/rel-0.12/development/messaging.html" target="_blank">http://ipython.org/ipython-doc/rel-0.12/development/messaging.html</a>).<br>
 Even considering http clients, the notebook is still just one<br>
possible client: you can easily build an interface that only evaluates<br>
a single cell with a tiny bit of javascript like the Sage single cell<br>
server, for example.<br>
<br>
Furthermore, since Min also reimplemented the parallel machinery<br>
completely with pyzmq, now we have one truly common codebase for all<br>
of IPython. We still need to finish up a bit of integration between<br>
the interactive kernels and the parallel ones, but we plan to finish<br>
that soon.<br>
<br>
We deliberately wrote the notebook to be a lightweight, single-user<br>
program meant to keep its files next to the rest of your scripts and<br>
other files.  The sage notebook draws many parallels with the google<br>
docs model, requiring a login and showing all of your notebooks<br>
together, kept in a location separate from the rest of your files.  In<br>
contrast, we want the notebook to just start like any other program<br>
and for the ipynb files to be part of your normal workflow, ready to<br>
be version-controlled just like any other script or file and easy to<br>
manage on their own.<br>
<br>
There are other deliberate differences of interface and workflow:<br>
<br>
- We keep our In/Out prompts explicit because we have an entire system<br>
of caching variables that uses those numbers, and because those<br>
numbers give the user a visual clue of the execution order of cells,<br>
which may differ from the document&#39;s order.<br>
<br>
- We deliberately chose a structured JSON format for our documents.<br>
It&#39;s clear enough for human reading while allowing easy and powerful<br>
machine manipulation without having to write our own parsing.  So<br>
writing utilities like a rst or latex converters (as we recently<br>
showed) is very easy.<br>
<br>
- Our move to zmq allowed us (thanks to Thomas&#39; tireless work) to ship<br>
the notebook working both on python2 and python3 out of the box.  The<br>
sage notebook only works on python2, and given their use of Twisted it<br>
will be probably some time before they can port to python3.<br>
<br>
- Because our notebook works in the normal filesystem, and lets you<br>
create .py files right next to the .ipynb just by passing --script at<br>
startup, you can reuse your notebooks like normal scripts, import from<br>
them, etc.  I&#39;m not sure how to import a sage notebook from a normal<br>
python file, or if it&#39;s even possible.<br>
<br>
- We have a long list of plans for the document format: multi-sheet<br>
capabilities, latex-style preamble, per-cell metadata, structural<br>
cells to allow outline-level navigation and manipulation such as in<br>
LyX, ... For that, we need to control the document format ourselves so<br>
we can evolve it according to our needs and ideas.<br>
<br>
As you see, there are indeed a number of key differences between our<br>
notebook and the sage one, but there are very good technical reasons<br>
for this (in addition to the licensing point already mentioned).  The<br>
notebook integrates with our architecture and leverages it; you can<br>
for example use the interactive debugger via a console or qtconsole<br>
against a notebook kernel, something not possible with the sage<br>
notebook.<br>
<br>
I&#39;d like to close by emphasizing that we have had multiple, productive<br>
collaborations with William and other Sage devs in the past, and I<br>
expect that to continue to be the case.  On certain points that<br>
collaboration has already led to convergence; e.g. the new Sage single<br>
cell server uses the IPython messaging protocol, after we worked<br>
closely with Jason Grout during a Sage Days event in March 2011 thanks<br>
to William&#39;s invitation.  In the future we may find other areas where<br>
we can reuse tools or approaches.  It is clear to us that the Sage<br>
notebook is a fantastic system, it just wasn&#39;t the right fit for<br>
IPython; I hope this very long post illustrates why.<br>
<br>
Whew, that was a lot!  I probably should turn this into a blog post at<br>
some point... Don&#39;t hesitate to ask questions on this, I promise much<br>
shorter replies in the future :)<br>
<br>
Cheers,<br>
<br>
f<br>
</blockquote></div><br>