Fwd: [IPython-dev] Re: notebook composition UI thoughts

[Michael Tobis]

On 7/8/05, Robert Kern <rkern at ucsd.edu> wrote:

> The placement of the input cells in the document may
> not correlate with the order they would be reexecuted. The numbers will
> determine the order of execution. The same sequence of inputs (ordering
>   by the numbers) will give the same outputs. If I rearrange the
> position of the input cells in the document, the order of execution
> remains the same.

Understood. This is sufficiently close to Mathematica's approach that
it seems to me to fail in the same way to live up to an important
potential of the medium, the one which interests me most. That is, as
a publication mechanism that can enforce the validity of a formal
argument.

> There, of course, is the option of manually changing the numbers in
> order to exercise a finer control over how the document might be
> reexecuted. Additionally, we can enable more automatic renumberings as
> well. For example, suppose that I don't want any of the cells I visually
> removed from the document to show up in the log, and I want the cells
> renumbered to be contiguous (e.g. instead of skipping from 10 to 14 if I
> deleted cells 11, 12, and 13). We can provide a command that will clean
> the log and make the appropriate changes to the cells in the visual
> document.

Indeed, this sort of functionality is exactly what I am looking for. I
am perfectly OK with it being optional. My purpose in injecting myself
into the conversation at this point is to ensure that options of this
sort are not foreclosed.

> > If I understand you correctly, then you are replacing Mathematica's
> > inconsistency with a method that is simple, consistent, and wrong.
>
> Quite possibly. However, it a method that is achievable. If you can
> contribute code that supports more complicated semantics, we will
> consider it.

I am a bit loathe to commit myself to this but I am indeed inclined to
participate in exactly this way.

I am not a deep enough Python magician to maintain the dependency
trees that Hans is imagining, but there are more pedestrian ways to
proceed that are within my capacities. They may lack something in
elegance and  performance but may be easy to implement and immediately
useful in many circumstances.

> >>At the moment, we are focusing on creating an interactive environment,
> >>not a code development environment.
> >
> > I find this distinction not especially helpful. I am using an editor
> > to construct a document to tell a computer what to do. How is this not
> > code development?
>
> It's the difference between writing a module and typing at the ipython
> prompt. I, at least, approach these activities very differently.

I think that the boundary between coder and user has become
artificially sharp.  I suspect this is in part a result of commercial
interests that aren't in the best interests of human progress. I
suppose that's a topic for another venue, though, and I should take
that particular axe and grind it elsewhere.

For present purposes, let me just emphasize that some of the best
designs are the ones that end up with utility far from their original
conceptions. Here's to the prospect of IPython being in that class!

regards
Michael Tobis