Don Gilbert wrote:
>> Lars,
>> The current way of compiling and linking program source code works
> fine for programmers. The component software concept exemplified by
> Java Beans and OpenDoc extends program building to non-programmers.
>> This is something that can be very helpful
> for an average biologist, who couldn't program out of a paper bag,
> but who could drag & drop program components (a sequence reader like
> readseq, various sequence manipulators, reporter components)
> into an application skeleton (bean bag) to create an application that
> does just the data analysis s/he wants. This goes forward along
> the lines I've been trying to develop my general sequence
> editor, seqpup, as an expandable, user-customizable tool.
>
I'm coming on the tail end of this thread but couldn't help but jump in.
I'm a firm believer in object-technology particularly the use of
components, frameworks, and design patterns. Its conceivable that one
could develop application modeling and generation tools which accepted
design models (e.g., UML object messaging diagrams), and a component
library and generated an application. My negative side tells me that if
this were an easy problem we would have already solved it. I've used
several object modeling tools which generate application code from
models but they always dropped you off half way through the process.
In the June-July issue of Javology, in "The Tao of JavaBeans" Emily A.
Vander Veer states:
"If you're familiar at all with the concept of component software,
you've no doubt been treated to glowing visions of a future world where
end users gleefully snap components together and create their own
software applications.
Now, this may well be a worthy goal, but it's got about as much chance
of being realized as my dog has of being admitted to Harvard on a full
scholarship. For the foreseeable future, the "end users" who will be
snapping beans together are developers, and the primary reason for this
cannot be overemphasized: No matter how easily the parts fit together,
somebody somewhere has to have intimate knowledge of the entire
application. The Following are a couple more reasons why end users won't
be building their own bean-based applications any time soon:
End users aren't developers. The majority of end users have jobs that
have nothing whatsoever to do with the art of programming. They are
experts at their particular field of endeavor, whether it's accounting,
retail sales, or banking. They aren't (and shouldn't have to be)
familiar with software construction, and expecting them to be is like
expecting pizza delivery drivers to assemble their own cars. "
You can find the article at
http://www.javology.com/javology/JuneJuly97/IS_JavaBeans.html
> The people who currently use 'readseq' the application seem to
> be more the programmer/bioinformatics system manager type. It
> has a useful unix-command-line interface for those who care
> to deal with such. But my experience with biologists leads me to
> think that readseq's functions are more accessible to them
> when packaged into a helpful user interface that doesn't rely
> on command-line operations.
>> Also, if we can believe in the views of future for Java software
> that are being hyped now, the average bioinformatics system manager
> will also start using Java components to build server applications.
>> Somewhere in the future, an average bioinfo server will have Java
> everywhere: java-corba/sql interfaces to commercial databases,
> java components in place of http-cgi scripts, and other complex
> analysis tools built from components that include java subsets.
> If/when that time comes, a component like readseq that is built
> in a fashion that it can be linked with other components automatically
> will have definite value (it will take much less of a talented
> person's time to deal with).
>> It remains to be seen if some of these predictions come true, but
> I find the vision and plans for such component software based
> in Java to be compelling.
>> -- Don
>> In article <yuewwms6ahm.fsf at turing.nada.kth.se>,
> Lars Arvestad <arve at nada.kth.se> wrote:
> >
> >Don Gilbert wrote:
> > DG> These include runtime reference resolution such that I can
> > DG> potentially make readseq a portable component that any non-programmer
> > DG> or interested biologist could drop into an application container
> > DG> and link together with other program parts to form a new
> > DG> application. This is part of what Java Beans is about. One
> > DG> can't do this with C++ or C code. It is something new and
> > DG> potentially very enabling for the average scientist or
> > DG> bioinformatician.
> >
> >I don't understand this comment. What is wrong with the function
> >libraries in the old fashion way? With readseq already being quite
> >portable (right?), it should be easy enough to build a library with
> >it.
>> --
> -- d.gilbert--biocomputing--indiana u--bloomington--gilbertd at bio.indiana.edu
