On Fri, Nov 4, 2011 at 3:36 PM, Jodi Ann Hadden <jodih.uga.edu> wrote:
> I don't know what the "official" AMBER development model is, but I feel
> the model as Jason describes it is in some ways unacceptable. I understand
> everyone is limited by time and resources and that the basic generosity of
> people who contribute code is what allows progress and helps to increase
> functionality in AMBER, but I feel failure of contributors to take into
> account the "big picture" is detrimental to the software in the long term.
>
> I get the impression from Jason that much contribution is coming from
> independent users on a "crisis to crisis" basis. Basically that someone
> requires some functionality that is not present in AMBER and so writes
> their own code to do it, and because their concern is primarily toward
> their own work and not AMBER overall, they perform this task in whatever
> way is most convenient for them, in whatever language they know without the
> extra effort of trying to incorporate it into an existing module. I'm not
> necessarily calling that lazy because I know everyone has limited amounts
> of time to donate, and I do find it generous that users would share their
> code with AMBER, but I also think accepting so many standalone programs
> with overlapping functionality constitutes a poor development model as it
> encourages a "cobbled" consistency to the software.
>
Yes. But my point is that we are not all software developers -- most of us
are computational scientists, and the software development is a means to an
end (doing our science). We are hardly the most "cobbled-together" package
in our field -- look at gromacs. The reality is that we make a
compromise. As an example, I'll use myself and parmed. I would say that
I'm fairly committed to Amber development (more so than Adrian would
probably like, since it slows my research down). I've done several things
motivated only by Amber maintenance with no benefit to my research.
However, if you were to tell me that parmed has no place in Amber because
it overlaps with rdparm, and that I'd have to implement my ideas in rdparm
to distribute it, I will continue using parmed extensively for my work and
be content as the only person that has access to it.
I don't think rules calling for "less flexibility" in development are a bad
> idea. It seems to me that restricting the languages that AMBER modules
> should be written in would be quite a good policy, actually, making
> everything easier to maintain in the long run, easier to condense and
> consolidate modules or transfer functionality between them when necessary,
> easier for developers to contribute to multiple modules, etc. Having a
> prmtop parser for every possible language is silly as it only encourages
> cobbling. An excess of code where subsets of users only understand subsets
> of the code due to a "language barrier" seems utterly detrimental to
> progress, whereas a few common languages could have a unifying effect on
> the code and improve communication among developers/contributors.
>
I'm not suggesting infinite flexibility. But infinite rigidity will hinder
and frustrate development (not to mention drastically increasing
politicking, which is science's mortal enemy) -- there needs to be a
compromise. And based on why we (as a collective) contribute to Amber, we
need to be more flexible than the software engineering perspective would
like.
I think Dave understands this tradeoff well, which makes him an effective
leader. We are rather free to do what we want, but the code is subject to
the occasional "cleaning house" to trim it back down. His is a unique
perspective on both the scientific advance and the software maintenance.
As for the languages, Amber consists of Fortran, C, C++, csh, awk, sh,
perl, and Python (and I was not the first to contribute a Python program to
the tree). Different languages lend themselves to different tasks (it'd be
ridiculous to try and write leap in Fortran, for instance, and as Wei
stated, it wants to be C++, but only C was around when it was written).
While some restrictions make sense (don't use languages that aren't
generally supported on most systems, for instance), to preclude any of the
ones we use above is foolish. But OK, if we need restrictions: No Java, no
LISP, no Ruby, no C# :)
And I don't think such a restriction would discourage contributed
> development. There are plenty of people with enough passion for the science
> and the software who want to be involved in something bigger than their own
> work who will still be interested in contributing directly to AMBER -- in
> terms of the existing software as well as new modules with novel
> functionality -- even if it does mean learning a new language. What is so
> wrong with that? I relish an excuse to learn a new language! That people
> have a desire to be involved is evidenced by the fact that they share their
> code at all.
>
It wouldn't eliminate it, but it would certainly discourage it, at least
for me (and I'd like to point out that I'm a fairly active developer). I
have nothing against learning a new language, but I have no interest in
trying to coerce a language to do what I want it to do when another one is
tailored better to the problem (i.e. trying to write leap in C or ptraj in
C). It also doesn't make sense to write something like MM/PBSA in a
compiled language -- perl or Python are much better choices.
> I guess I think, based on the impression I got from Jason's email, that
> perhaps development is being encouraged in the wrong way. If users want to
> contribute, they should be encouraged to work with other AMBER developers
> to incorporate their ideas into existing AMBER or design a coherent,
> foresighted new module in AMBER to accommodate it, instead of just cobble
> something else on that is of limited use due to overlap, language barriers,
> hard to read/poorly documented, etc. That way, the devs already familiar
> with the code get a handle on the new functionality, and the new
> contributor gains knowledge of how the existing code works.
It's a fantastic policy on paper. It's not detailed, though. As Ben put
it so succinctly, this is "making the perfect the enemy of the
achievable". The multiplicity isn't as bad as it's being made out to be,
so it'll be easy to address each case individually at the meeting, after we
make our case for its inclusion.
> This cross-communication and redundancy, not in the code but in the people
> who understand the code, seems the best way to manage streamlined software
> maintained by a community. "Rip it out if you can't maintain it after I'm
> gone" is unacceptable.
>
It's not unacceptable, it's experimentation. If it doesn't catch on, it's
not maintainable, so it dies. If it does catch on, there's interest in it,
so it continues to be maintained and developed. In the previous case, it's
as though it was never there. In the latter case, Amber benefits from a
good program.
All the best,
Jason
--
Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Candidate
352-392-4032
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Fri Nov 04 2011 - 16:00:03 PDT
