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

[Robert Kern]

[Michael originally sent the previous message privately to me and not 
the list, and I replied privately as well. We seem to be converging on 
the opinion that the need for more complicated execution semantics (like 
Hans's dependency graph) can, for the most part, be ameliorated by 
layering actions on top of the simple, ipython-like execution semantics. 
Future work on those more complicated semantics may be worth considering 
after this Summer of Code project has been completed.]

Michael Tobis wrote:

 > 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.

I understand your concern, but at the moment, we are not interested in 
living up to a lofty potential, but to produce useful tools by September 
1st. I agree that the semantics I have proposed are not ideal, but they 
are simple to implement. We hope to build components that can be later 
reassembled with different semantics as they become implementable.

 >> 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.

We are not foreclosing the development of anything. We are, however, 
making choices as to what we will be developing for this Summer of Code 
project. Especially, we are not foreclosing on things that can be 
readily built on top of the simple semantics I have proposed.

 >>> 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.

Then you can understand why I am loathe to commit myself or others to do 
something that I think is probably impossible.

 > 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.

It is possible that the specific capabilities that you and Hans are 
imagining are achievable, but I have my doubts. Working code, of course, 
relieves all doubts.

 >>>> 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.

I am not making a distinction between coder and user. I am mentioning a 
difference that I see in the kinds of activities that I do. I write 
reusable modules one way; I write interactive code another way. The 
mechanisms that I want to support the one activity are different from 
the mechanisms that I want to support the other.

I would also note that literate programming, I think, satisfies the 
"notebook" niche for the "writing reusable code" activity, and that 
there is little point in writing a new literate programming tool. Leo, 
CWEB, et al. do that job just fine. There's no point in trying to 
reinvent them in one summer. However, I don't think they do the job for 
interactive work like what we use ipython for, hence we are focusing our 
summer efforts on creating the best interactive environment.

 > 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

-- 
Robert Kern
rkern at ucsd.edu

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter