===  Harrison's reply to Gordon's comments ===

                (Nov. 21, 1997)




                      Dept. of Physics, Florida State University, 21-NOV-1997

    Hi,

    Thanks for  your  thoughtful  comments. We are  converging,  and I believe
there is less disagreement than meets the eye!

    (A) Mixed languages

    First a general remark. I believe that python is a wonderful language with
a far more intuitive and  flexible view of objects  than that provided by C++.
My experience  with python in  the testbeam  has convinced me  that python has
very wide application for building  highly interactive analysis programs. It's
superb at encapsulating C code (and FORTRAN...who said that!). So I'm a fan! 

    However, all  the code that  I've wrapped  into modules  was code that had

already been  well-debugged.  So I was using  python as a way  to use the code
more  flexibly...not to  debug it. I  am merely  raising the  question: does a
mixed-language    environment  make  debugging and  package   development less
convenient or  more convenient  for our  colleagues, many of  whom are already
struggling to come to grips with the  "brave new world" of objects and C++? My
judgement is that  debugging and package  development is less convenient in an
environment in which the debugger does  not understand both languages. I agree
that one can run  python in the C++  debugger and then  set breakpoints in the
objects of  interest and skip the  Python mess. However,  in Run I, I found it
necessary sometimes to be able to  "walk through" the main program in order to
fully understand  the interaction  between a set of  packages. Perhaps, now we
have objects that will no longer be necessary; but right now I'm just not sure
that that is true.

    (B) DLL linking code

    I think  there may  be a   misunderstanding here.  There is  absolutely no
intention of our writing  "dll linking code"! That  truly would be foolish. We
are  simply  making a  plea,  which is: we  should  make  use of  dynamic link
libraries  (DLLs) and  shareable  object files  (SOs). That is,  we should NOT
build static libraries. Why? So that  we can swap out one version of a package
for another without  having to re-link D0RECO. We  gave an example of what one
might have  to place  in a  Makefile, on  the SGI, to  build  shareable object
files. That's all! 

    Clearly, there are issues to be understood: can one object from DLL (SO) A
call the methods of objects from DLL  (SO) B? (No pun intended!) My guess, and
that's  all it  is--is that  given  that the  standard  way  Microsoft and SGI
release  their code  is via DLLs  and SOs,   respectively, that  the answer is
probably yes...doubtless  with some restrictions.  But there is no question of

writing "dll linking code" ourselves. Perish the thought!

    (C) Batch framework

    The point here is that we need a  batch framework first. However, provided
that we build objects sensibly (each  object doesn't do too much, and each has
a  well-defined  set of  interfaces)  it really  ought  not to  matter in what
environment  these  objects  interact.  If it  does then  the whole  notion of
reusable  objects  just  doesn't make  sense. I  do not  see that  the kind of
objects that  Dzero is  building now are,  necessarily, only  happy in a batch
environment. The kinds of interfaces  that have been discussed do not preclude
the use of these objects  in an interactive  analysis environment. As we learn
more about  how  people wish to  interact  with  objects and at  what level of
granularity,  we can adorn  them (objects,  that is, not  people) with as many
bells and whistles as needed. If we've  done our object-building job correctly
then the adding of more bells and whistles ought not to break previously added
bells and whistles. I cannot see how  we can build such an environment without
some degree of "try it and see".

    In   short, I  do not   think  our  focus on    immediate  needs--a  batch
machine--places,  inevitably,  restrictions  on the use of  these objects in a
more dynamic user-driven environment.  I'm just not clever enough to know what
kinds of dynamic environments we shall  wish to use two years from now. I know
what I'd like to use now. But now will surely be old then!

                                   Harrison