Why AMBER sticks a finger in its users eyes.

I use molecular dynamics packages - complex computer software that simulate the action of very large molecules. There are many such packages, but the big ones are amber, charmm, xplor, gromacs and namd.

I have now used namd and amber, and based on that example, I have to say that amber's input files are a piece of shit.

My complaints are:

1. In the input files for AMBER, why do they use crappy variable names for the pre-historic days of FORTRAN naming conventions. No, I really don't what the variable ntxb. It's the 21st century, variables can be longer than 8 characters. They can even be meaningful. They shouldn't give you eye-sore and send you running to the manual everytime you read the input files 1 week later.

2. If you use input files to start a simulation, why do you also have to add up to 10 command line gcc style options? Why can't you have keywords in the input file to convey the same information to the program??? Everything is in one place, and stored? How friggin' hard is that?

3. Putting positional constraints on different atoms is a great idea. In NAMD, you submit a pdb file, and NAMD will read the constraints from the B-factor column. Great idea - simple to use, complete flexibility for the user. And AMBER? You must enter the positional constraints in the input file via a very special "restraintmask" string, and it's not even defined in the right place in the manual - because you have to run to the appendix where they give you an anemic language to describe what atoms you want constrain, using the very special amber numbering convention. Except that you really have to go back to the beginning of the manual to find that you only have 80 characters to describe constraints.

Poke my eyes out please.