[Pipet Devel] BioML vs BSML

[Harry Mangalam]

Hi All (new content inline below)

On Sun, 24 Jan 1999, J.W. Bizzaro wrote:

> Harry Mangalam wrote:
> > It seems not to be at cross purposes to the objectives of LOCI to implement
> > chunks of it in perl, no?  As long as it remains easliy implementable, and
> > usable, and freely re-distributable, perl is as much of an option as
> > python, isn't it?
> 
> Errrr mmmmmmmmmm argggggghh!  I'm having convulsions here ;-)  It seems at every
> turn, there's something supposedly better to use, and I'm left having to defend
> what I have chosen.  If I don't give in, I'm too stubborn.  But if I do, Loci
> more closely resembles a smorgasbord of technologies.

:) I'm sorry for having caused the early morning convulsions, Jeff.  I'm
just trying to get a handle on the big picture.  I wasn't actually suggesting
replacing Python with perl for the central technology, but rather as one of
the toolsets that supports your central technology.  The problem I see with
being too doctrinaire as to the languages used is that you run the risk of
alienating some that support your model and see alternative ways of
accomplishing a task (that may have already been solved with great effort)
using another approach and as long as using it doesn;t conflict with your
central goal, I don't see the problem.

 
> I am trying to keep Loci homogenous in terms of technology.  I think Python is a
> knock-out language, beating even Perl in most respects.  I know Perl is very
> prominent in sequence analyses...It's prominent in just about everything.  But I
> think Python is not far behind in acceptance, and is gaining momentum.
> 
> What can we do?  If there is absolutely no other choice, we can go with
> something in Perl, ***providing we consider it a temporary option.  If we can
> find something later in Python or can convert it to Python, then we will.  But
> don't give in too easily.

Hear, hear.  That's all I'm suggesting.  However, IMHO excluding biosequence
artists on the basis of what language they choose is certain to make for bad
blood in the community and that's not what we want.  As long as there's a
standard way for the components to interact, anything that contributes to
the effort should be considered.  Speaking of which, one of the things that
attracted me to this approach was it's close coding and thematic relation to
the GNOME project.  One way to rationalize the different language issue
would be build the components using the GNOME's ORBit definition, which is a
lightweight, lo-memory, GPLed, CORBA-compliant ORB (albeit written in C, but
I'm not sure that would affect much). Info is at:

http://www.labs.redhat.com/orbit/

Has that approach been evaluated?  I'm certainly not trying to throw grit in
the gastank - it's something that I'm currently investigating and so far it
seems to be quite promising.  If the list can give me reasons why it's a bad
idea, I'd very much appreciate it.

And finally, I appreciate the difficulties of trying to herd a bunch of wild,
perl/C/scheme/lisp/etc-crazed code weasels.

>From one of the weasels,
Cheers
Harry