On 3/11/2011, at 5:45 p.m., Ross Walker wrote:
> Look at the example we have here. We have a working code, tleap / xleap that
> had some problems and needed some extra stuff adding etc. But instead of
> people trying to fix stuff we get a whole new version written from scratch
> which has its own problems. Why oh why are we making yet another imperfect
> square wheel?
Agreed. In fact, I started out by suggesting that we focus on one of the existing tools - if that makes sense! The main problem with starting from tleap, I think, is that it's written in C, while a tool like LEaP would benefit from being written in an object-oriented language. OK, so then we fix sleap instead of tleap. I don't really care, so long as we end up with a single LEaP that everyone (rightly) knows, trusts and uses, and that is well written, well documented and easily maintained and extended within a consistent framework.
The rest of your email raises valid points for consideration, but when we get down to specifics, aren't we better off picking one achievable target at a time? It's not as though fixing LEaP precludes dealing with ptraj vs. cpptraj, rdparm vs. parmed, mdgx vs. pmemd, and so on. But they may not all be dealt with at once, and I think we need to be OK with that unless we plan on going out and hiring a programmer (or maybe a bunch of programmers) who is/are paid to fix Amber and pretty much nothing else. I submit that we don't want to make the perfect the enemy of the achievable (if I may mangle a quote).
Cheers,
Ben
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Thu Nov 03 2011 - 15:30:03 PDT
