> I'd suggest a more work-oriented meeting. Why spend 30 minutes
> discussing the resolution if we wouldn't be at the BoF if we didn't
> agree with it? We can pass the resolution in the first 5 minutes and
> spend the remaining 85 profitably discussing what we want these
> systems to do for the end user (not just the programmers).
1. On the Agenda for the BoF.
Those with substantial disagreements with the resolution have every
reason to attend the BoF: it is their final opportunity to stop the
meeting from proceeding with it. If the resolution _is_ passed in
5 minutes, I fear there will not have been enough thought and discussion
of this. (Hmm, does anybody recall the hue-and-cry after some jury
recently brought in a decision after 4 hrs? :-)
Of course it would be great if the value of the committee were considered
so obvious that little discussion is needed to pass the proposed
Resolution. In that case, however, I'd like to see the discussion
spend the extra time defining a better mandate for the committee to
pursue. For instance, should the committee be directed to maintain
regular discussions with the rest of us via a FADS-like mailing list?
Should its mandate be more focussed on specific points that haven't
been proposed in the draft?
2. On an Ideal User Interface.
It is undeniable that any new user interface should be based on what
users want and need (although it's popular to point out that users
don't really know what they want until it's been created...).
But I am sure that the notion of an Ideal User Interface is only a chimera.
People don't agree on the ideal car, clothes, computers, operating
system, or editor; why should they all want to use the same user interface?
Development of new user interfaces and environments is an active area
(for example, aips++ and ARCTIC have been mentioned in the FADS list),
and an extensive discussion of user interfaces will no doubt increase
awareness of the important issues and possibly spark new ideas. Over
the years there has been much more discussion of user interfaces than
portability and interoperability, and I believe it is time to address
these latter issues.
> ...Why the
> concentration on interoperability when the main-line packages are
> stuck in the mud operating only with themselves?
This puts the case in a nutshell: the main-line packages don't provide
interoperability. I submit that this lack of interoperability
hampers productive data analysis, and it should be tackled now.
> ...I submit that the
> sum of a dozen messes is still a mess...
If you don't like the way a package interacts with a user, task-level
interoperability is a real boon for the software developer. If there
is task-level interoperability, one can write a new user interface,
scripting language, or whatever, stir in the already-written tasks,
and -- voila -- instant package, without the fuss and bother of writing
the tasks that do the science.
Keith Arnaud wrote:
> So, my plea is the following. By all means try to improve the
> interoperability of software and all those other good things.
> Just don't spend so much of the available resources on it that
> there is nothing left to put together high level scripts/tasks
> for specific astronomical uses.
If interoperability becomes reality, it will reduce the time spent
writing tasks with similar functionality for different packages,
and thereby increase the resources available to writing real
astronomical data analysis & reduction code.
-Will
William Deich |
NFRA | Internet: will@nfra.nl
Postbus 2 | Phone: (+31) 5219 7244
7990 AA Dwingeloo | Fax: (+31) 5219 7332
The Netherlands |