Re: [AMBER-Developers] Experiences with sleap

From: David Case <>
Date: Sat, 5 Nov 2011 13:25:46 -0400

On Nov 5, 2011, at 12:37 PM, "Ross Walker" <> wrote:

> 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 |
> | | |
> | Tel: +1 858 822 0854 | EMail:- |
> ---------------------------------------------------------
> 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 mailing list
Received on Sat Nov 05 2011 - 10:30:03 PDT
Custom Search