Thanks for taking the time to write this historic perspective Fernando, I always wanted to know the details of these parallel developments.<br><br>You should definitely turn this into a blog post, as is! I am already forwarding this email to some colleagues which are not on this list but will like to learn about this.<br>

<br>cheers,<br><br>Flávio<br><br><div class="gmail_quote">On Sun, Jan 8, 2012 at 02:26, 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>
<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>
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>
<br>_______________________________________________<br>
IPython-User mailing list<br>
<a href="mailto:IPython-User@scipy.org">IPython-User@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/ipython-user" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-user</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Flávio Codeço Coelho<br>================<br>+55(21) 3799-5567<br>Professor<br>Escola de Matemática Aplicada <br>Fundação Getúlio Vargas<br>Rio de Janeiro - RJ<br>Brasil<br>

<br><br>