Hi Justin,
> With all due respect, that's hardly a fair comparison. We're talking
> about re-writing a small---but, admittedly complex---utility and not a
> major web browser. The problem with leap isn't that it's badly
> architected or written. The problem is that it's written in the wrong
> language. IMO, C, fortran and even C++ are too low-level for this sort
> of task.
I disagree. This is a perfect example of what that article was referring to.
In fact we even attempted to re-write it and failed. And as a result spent 3
years shipping a tleap / xleap which had undergone no real development
because the 'new' code would save us from it all.
What should have happened is Leap should have been gradually migrated from C
to C++, and documented as we went along. This could be done in stages since
C++ is easily compatible with C. At the same time if done carefully all of
the developers would ultimately be able to contribute should they need to
since every (I hope EVERY!) developer of AMBER should have at least a
rudimentary knowledge of C and C++.
> FWIW, a friend of mine worked at Amazon for ~5 years and they re-wrote
> their entire infrastructure twice. They seem to be doing just fine. A
> little closer to home, Rosetta has been re-written several times and
> Baker & co seem no worse for wear. In my opinion the only compelling
> reason to stick with tleap is that it is there and it (mostly) works.
But Amazon is not and was not in the business of software. And have you
looked at the new version of Rosetta? I have, I worked on it. I wrote the
initial parallel version of it. They took what was fairly nice and efficient
Fortran code. They then paid a company to convert that (warts and all) to
C++. The resulting C++ code was terribly inefficient, buggy, needed all
these libraries to deal with all the stuff in there that handled fortran
ordered arrays etc etc. It was dreadful. This has slowly been improved over
time but to be honest if they'd invested the same amount of effort working
on the Fortran code they'd probably have had something much more efficient
and with additional features and ultimately cleaner.
> Finally, although I'm not necessarily suggesting we do this, I am
> willing to bet that if we locked two experienced python programmers and
> two people comfortable with the format of the various tleap database
> files and parm format in a room for a week that you would have a
> working, modular, extensible, human readable(!) replacement for tleap
> that has 1/10 the amount of code.
To select a quote from a certain movie "Your overconfidence is your
weakness". What we would get is an unmaintainable, partially complete
package that subtly implements the force fields incorrectly and only runs on
hemorrhaging edge Linux (tm) v31.0062766802998...
All the best
Ross
/\
\/
|\oss Walker
---------------------------------------------------------
| Assistant Research Professor |
| San Diego Supercomputer Center |
| Adjunct Assistant Professor |
| Dept. of Chemistry and Biochemistry |
| University of California San Diego |
| NVIDIA Fellow |
|
http://www.rosswalker.co.uk |
http://www.wmd-lab.org/ |
| Tel: +1 858 822 0854 | EMail:- ross.rosswalker.co.uk |
---------------------------------------------------------
Note: Electronic Mail is not secure, has no guarantee of delivery, may not
be read every day, and should not be used for urgent or sensitive issues.
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Sat Nov 05 2011 - 10:00:04 PDT
