In article <005d01bfa4b3$267a1720$7b02a8c0 at nic.in>,
>> Another exemple is Lesstif, the free replacement for motif toolkit
>> see http://www.lesstif.org/>>Yep! But not up to the mark!
It works fairly well. I use a number of motif applications (in
particular DDD and xmcd) which work fine with Lesstif.
>>>> By the way, to answer your comment about Linux and the growing of
>> C++ fashion, could I remind you that Linux is written in C?
>> And more important XFREE IS WRITTEN IN C! (http://www.xfree86.org/)
>>Yep! But programs fro Linux will be written using C++. True for XFREE too
>but how many program on Linux platform uses core API??
Almost all of them. The vast majority of Linux programs are written in
C, not C++, and that goes for bioinformatics software too.
C++ will grow steadily though.
The kernel itself is written C. Almost all GNU programs are C, which
make up much of the rest of the core OS (groff is in C++, but that's an
exception).
>More and more written in C++ or Java
True, especially if you want to write something that will also run in
Windows, in which case C++/Java are a much easier route. But that
doesn't mean the majority of programs are bing written that way now.
>> 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.
Rubbish. Ask any user of the Staden package (and there are a lot of
them, reading this group). Core functionality written in a combination
of C and FORTRAN as shared libraries. User interface is entirely
written in Tcl/Tk. It makes it an astonishingly flexible piece of
software. End users can modify the user interface to suit them, and
programmers like myself can write tcl scripts to automate DNA sequence
assembly. Best of both worlds.
>>>> 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
>do something for all, windows, MAC, BeOS, OS/2 etc etc and to take me with
>you along with my Windozzz box in this journey of new biology. And what you
>do? You advise to throw that box in gutter! World is chaning fast my friend.
>All will be there, with all their bugs and assretion!
I have nothing against Windows. It's very good for word-processing, and
ad-hoc analysis in spreadsheets and so on. However, it's terrible for
any form of automated data processing. This is largely because of
programs written with GUI interfaces. GUI interfaces are nice to learn
to use, but typically they are very hard or impossible to automate.
This is why the tcl/tk solution in Staden is such a winner; it has both
a nice easy GUI for ad-hoc work interactively, and a tcl scripting
interface for bulk sequence processing. I base call and assemble
several hundred reads a day in my job. It all runs automatically
overnight, and I have dozens of new or expanded Staden gap4 databases to
study the next day.
>> Good luck for the future, and remember, diversity is fun and
>> efficient, in computing as in biology,
>>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...
Religious wars like these are pointless. Your choice of hardware
depends on the task you need to perform. So does your choice of
application software and operating system.
If you're implementing your own software, your choice of programming
language again depends on the task the program needs to perform.
If it needs to be highly portable and have a GUI, but doesn't need to be
automated, then Java or C++ are ideal.
If it needs to be scripted, but also needs a GUI, then a combination of
tcl/tk and C or C++ is a good idea.
If speed of execution is not important, but you need to process lots of
textual data, then perl is worth considering.
If number crunching speed is paramount, then FORTRAN is still king.
Anyone who claims that a programming language is perfect for all
purposes is deluding theirself.
Tim.
