Malay Kumar Basu wrote:
Having spent some time working on Unix, and more recently also on
Windows, using a variety of languages including some listed in this
discussion, I feel it's about time to put my oar in :-)
> That's my point! Thanks for negeting your own argument. I can't write GIMP
> in two years in C but can try writing it in C++ and Java. Not many programs
> like GIMP are available and not on many systems. That's proves my point.
> Softwares should be easily written and should be easily portable. If I can't
> write a program that's means it's difficult to me, that in turn means that
> the Gurus failed to deliver it to masses.
Hmm - Then try writing GIMP in ANY language you choose. You'll still
find it's a huge task. Personally I don't care what language the GIMP
authors used (unless I want to compile it myself, in which case C is
by far the most portable) as it works well, and that's what counts.
For smaller, simpler, projects try looking at
http://wwwipd.ira.uka.de/~prechelt/Biblio/#jccpprtTR
It illustrates, for pure computation work (ie no GUI), a comparison of
using various scripting languages vs C vs C++ vs Java. The results are
enlightening, but probably do not stand up to large scale software
engineering. (But there's lots of other papers on similar topics on
the same page.)
> > But you have dosens of them. And you have dozens written in TCL,
> > PERL or PYTHON linked with a toolkit.
>> Any how many users in day to day life uses them? These are softwares written
> by programmers for the programmers.
Thanks to Tim Cutts. He's already put a good argument for our work
(the Staden Package). I'll add to this the following comment:
We used to work using lower level X libraries. Xaw and the like. These
days they've been replaced with Gtk, qt, etc, but the "level" of work
is much the same. It's slow work and tedious.
Then we switched to Tcl/Tk. I can confidently say that this has had an
ENORMOUS increase in our work rate. Further more, "for free" we gained
an underlying scripting language and cross platform support (Windows
and Unix - in theory Macs too, but I tried that and couldn't get a Mac
to stay up for long enough!)
The Staden Package now works just fine on MS Windows systems. This
took rather a long time to do, but to be honest virtually all of that
work was minor tweaking and working around Windows bugs. Either that
or extending the functionality of the package so that we no longer
expected people to use "ls" for creating files-of-filenames :-). I
initially investigated the port with Trev - a simple ABI trace
viewer. It took a couple of weeks to get a development environment
where I was happy - bash, GNU make, etc. Then it went pretty quick.
Armed with that environment the first build of Gap4 (a sequence
assembly program with 150,000 - 200,000 lines of code) took only 3
days! OK it was glitchy with hideous fonts, but it did actually
assemble data and allow you to edit and view it.
I'm not saying Tcl/Tk is the perfect language - far from it. However
C++ is just a algorithmic language, it doesn't solve the GUI
issue. For that you need a graphics toolkit. C++ links with Tcl/Tk
(with a bit of shoving), or you could investigate the other free
systems. These days I would not recommend using any system which is
tied to a specific platform - there's simply too much variety out
there.
I first learnt C++ in 1990. It was truely truely aweful. To this day
it is still the only language where I've ever managed to fix bugs by
strategic use of comments! Ok, so this was too early for the language,
but even now I keep hearing of new keywords being added. Finally,
after 10 years, it seems to have stopped fluctuating and has now got a
standard. All we need to do is to wait for people to actually
implement it properly.
I'd say that Java is similar, although C++ clearly has a head start
and so it'll take a few more years before Java stops
changing. Although it does appear to be settling down substantially
quicker than C++ did. However I still have problems running many Java
apps. Whether this is because half the web-based apps I see are
written by first time programmers, or because of inherent problems in
the Java implementation on my system, I do not know. However I do not
appear to be the only one with these thoughts. I once heard Java
rather cynically described as "Write once, test everywhere" :-)
Personally I still prefer good old C, although I try to write it in a
modular and object oriented manner. If I was to make the leap to a
proper OO language then it'd probably be something way off the beaten
track, such as SmallTalk (as an example - I know hardly anything about
it). But then I'd probably also have no users for any code I wrote :-)
> > Please quit your Windows box five minutes and see the world before
> > to claim manichean assertions.
> >
> That's the point. I pledge, beg and implore you, the bioinformatics guru
> sitting in front of an 256MB SGI workstation that I work on a misly Windows
> dumb box with only 32MB RAM and all I have is shear intention to learn and
The Windows port of the Staden Package was entirely developed on a
32Mb P166 (non MMX) PC. We would have preferred something better of
course, but it wasn't really necessary.
All our new development is still on Unix though. Why? Because it's
simply so much easier. Even when not using MFC, Visual this-that and
the-other, compilation and debugging just works much much better. This
is NOT just because I'm a UNIX programmer. We have a skilled Windows
programmer working with us, but he seems to spend days wrestling against
the system. And even he willingly admits that installing cygwin on
Windows is the way to go.
> Cut you own tail again! Just now you advised me to throw my box away.
> Talking diversity.... Ah! At last! Diversity means not only the diversity of
> language but also the diversity of OS. Along with language take the culture
> too...
Sure - I couldn't agree more.
Finally, rather than whinging at the bioinformatics community for not
producing many MS Windows programs have you ever considered why not?
Maybe it's because we do not want to be at the mercy of a commercial
company with known dubious practises. Maybe it's because it's just too
hard. Or maybe it's simply because we're luddites :)
James
--
James Bonfield (jkb at mrc-lmb.cam.ac.uk) Tel: 01223 402499 Fax: 01223 213556
Medical Research Council - Laboratory of Molecular Biology,
Hills Road, Cambridge, CB2 2QH, England.
Also see Staden Package WWW site at http://www.mrc-lmb.cam.ac.uk/pubseq/
