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