Re: [MMTK] Re: [PyMOL] improving interoperability between python moleculetoolkits (fwd)

[Richard G. <re...@co...>]

> Konrad Hinsen wrote:
> 
> Indeed. But this illustrates nicely a frequent problem faced by
> software designers: Software like OpenDX is powerful and flexible, but
> also huge and difficult to learn. A small specialized tool is easier
> to use for the specialized user. Of course those users then find
> themselves in a mess of specialized tools a few years later, but it is
> rather hopeless to try to warn them about this in advance.
> 
> > future system should put a great deal of work into developing a
> > strong underlying general data model, not just for molecules, but
> > for all kinds of scientific data: grids, vector fields, polygonal
> > surfaces, trees etc. Just leaving things open to general objects is
> 
> Although that is desirable in principle, too ambitious projects often
> end up in either an unfinished or an unmanageable state. Take CORBA,
> for example. ...

Yes, CORBA is complex and has some overhead. I have also read that
Microsoft's DCOM/OLE is very complex. I don't think either of
these is a good way to go, though there are some very cool applications
I have seen. A lab I know at LBL uses CORBA as a device interface. 

>  A great concept, very general but implementations are few
> in number, often slow, sometimes expensive, and always come with a
> steep learning curve. Or take SGML: the general of the general, but
> people started looking at it only when its slim brother XML was there.

Even XML is very verbose for molecular data, but I haven't seen any
better way to write general objects to disk.

> It is not easy to find the right equilibrium between simplicity and
> generality. For the specific case of scientific computing, I think
> simplicity is more important in most cases. Scientists need to
> understand and be able to modify code that is the basis for their
> research. And they are usually not well-trained software developers.

I agree that simplicity is most important. The vast majority of 
scientific users are non-programmers and have no time or desire to
write and debug code (scripts, visual programs or otherwise). These
folks need a good end-user application with simple configuration
options. The mode of operation I have seen for years is that a research group hands down
mostly undocumented scripts to future members, passing on the knowlege
of how to use them by one-on-one interaction. A few students will delve 
into the code and really modify, but most will just know how to edit
a few parameters to get what they want. I agree with Allen Holhub in his
book on C/C++ coding rules: "Don't solve problems that don't 
exist" and "Solve the specific problem not the general case". Too much code 
is over configurable, which makes installation and use a combinatorial nightmare.

> 
> Well... It's a design by committee approach that has rarely produced
> useful results in spite of an enormous effort. Moreover, which
> scientist can afford to participate in their meetings? That's a
> full-time job.
> 

What can I say? Nobody likes to have to adhere to standards, and it is very hard work
to get people to agree on them. Ultimately, though, I think that is the way
things will head as information (ge



> Konrad.