2020-11-09, 13:00–14:30, Times in UTC
Listening to the presentations of a wide-ranging software survey by
the Radio Camera Initiative (RCI), one message emerges loud and clear:
"We have the algorithms and the tools (e.g. containers etc), but we
are still failing to bring these to bear in such a way that users,
developers and managers are induced to work together effectively".
This BOF continues a venerable ADASS tradition of offering a platform
to participants for formulating and discussing profound thoughts on
the Future of Astronomical Dataprocessing Software (FADS). In one way
or another, over the years, the FADS discussions have always revolved
around this question. It is perhaps time to put it to rest, if we can.
Developers (15 min)
There are many clever developers all over the world (cheap too), but
we are not very good at adopting their stuff and integrating it into
our systems. There are many valid practical reasons for this, but it
Users (15 min)
The trend is towards processing pipelines that nobody dares to touch
once they work. This begets ignorant users, and slows evolution. Users
should be able to experiment, and to interact with developers.
Software Managers (15 min)
Managers should not concern themselves with content. Their role is to
quietly create the conditions in which users and developers can evolve
our systems together.
Tentative Conclusion (15 min)
The easy answer is that Python already offers many of the things we
need. Users around the globe can easily access a huge variety of high
quality software by means of a single powerful interface (the Python
language). They can combine these into custom recipes (pipelines!),
which they can share with others via email. Very importantly, the
interface disciplines the many developers, while allowing them to
concentrate on whatever they are good at. The Python system is managed
by invisible guardians, and is freely available.
So, is Python sufficient, and can we limit ourselves to writing a few
Python modules of our own? Or do we have to create possibilities which
Python does not provide (yet). In that case we should hope that Python
will eventually adopt the stuff that we develop ourselves.
Keywords: interface, evolution