The RightThing is of course to limit all functions to one argument, and use CurryingSchonfinkelling for the rest of the parameters. For some reason, however, this suggestion isn't a very popular one... ;)  - JayOsako
----
I was just typing in this copy function:

 template <class T> void CopyImageAndDisplay(T *dstAcuObj, T *srcAcuObj)

and I realized that I reflexively put the destination argument first. I started wondering why I did that. Probably a habit formed by years of programming C/C++ and x86 assembly. I got curious and did a quick non representative scan through the MSDN library. I expected that something designed from the ground up (Java) would have some kind of convention but it doesn't seem like it. It's kind of hard to tell because OO tends to use Obj.Copy(src), which I can't do with my template function.

So, to satisfy my curiosity, can someone point me to a poll or some stats or, better yet, does someone have the definitive answer?

AndrewQueisser

''I suppose I would do it instead like this:''

 destImage = srcImage.copy();
 destImage.display( dispCtx );

''Or some variation of that. -- RobertDiFalco''

Nope, but if I wanted to bluff, I might start with
 dest = src;

''If you really had to keep the 2-argument function, you could at least catch some common mistakes up-front with:'' 
 void CopyImageAndDisplay(T *dstAcuObj, '''const''' T *srcAcuObj)
''--RickSamuels''


On the other hand, in assembly language and in machine code, the destination is (always ?) specified after the source (when they occur in different instructions):
 src @ dest ! \ in the ForthLanguage
.
When different source and destination arguments occur in the same assembly language instruction, some assemblers put the source first, others put the destination first, which assembly language programmers find endlessly confusing when they start using a different processor. (I've heard some people talk about Intel order vs. Motorola order, from the traditional assemblers for x86 vs. 680x0 processors).

For example,

most assemblers for the 680x0 allow you to write
    move.b 7, d0 ; move 7 into d0

most assemblers for the 80x86 allow you to write
    mov    al, 7 ; set al to 7
although the AT&T assembler for the 80x86 has the arguments swapped the other way around.

AssemblyLanguage calls the 2 possible orderings "Intel style" vs. "AT&T style".

''Using "x86 vs. 68k" in this sense, though, can be confused with another sense - x86 chips are LittleEndian while 68k chips are BigEndian.''

''Most command line programs (for UNIX, DOS, and Windows) are of the form "mv src dst", mainly because you might want to do "mv src1 src2 src3 dst/" instead.''

Linguistically, the object that ''changes'' (the destination object) is often the "primary actor" of the sentence, and thus it makes sense to put it first.  Kind of akin to most languages putting the object first in imperative clauses, followed by adverbials.  This kind of emphasis is demostrated by both

 obj.add_listener(listener)

and

 fprintf(stderr, "%s to your %s", swearwords[errno], argv[0]);

When designing function or method signatures, I always prefer to put destinations before sources, mimicking assignment and following (I think) long years of tradition. (Examples: ''strcpy'' in C, ''rplaca'' in ancient Lisp, ''DAXPY'' in the BLAS. Counterexample: ''copy'' in the C++ standard library.) The first few assemblers I used followed the same convention, so I find the reverse uncomfortable; oddly enough the Unix ''mv'' command doesn't bother me at all. I think assemblers should adopt syntax that makes the direction of assignment explicit: perhals "mov al <- 7" versus "mov 7 -> al", etc. I believe Intel's assembler for Itanium does something like this. -- GarethMcCaughan

''Yes, I often wish for a slighly improved assembly language. Should we collect ideas on a wiki page -- is BetterAssembly a good name ?  ...  -- DavidCary''

PL360 (one of the WirthLanguages) is a good example of a structured assembly language. See Wirth's technical report available here:
*http://www.fh-jena.de/~kleine/history/languages/pl360man.pdf

----
Whenever I'm writing code in ObjectiveCaml, I try to put my destinations first... because OCaml allows partially-applied functions, which I can then pass to iterators more easily.
  let foo src dest = ... in
  List.iter (fun x -> foo x somecollection) somelist
becomes
  let foo dest src = ... in
  List.iter (foo somecollection) somelist
The expression (foo somecollection) returns a new function which takes one argument, which happens to be the source.  It really doesn't change the semantics I suppose, and could be argued to be less clear (I don't think it is), but is nicer to write.

----

And now for something completely different: http://www.haskell.org/ghc/docs/edison/users004.html#toc10

''Whenever a function takes multiple arguments, there is a choice as to the order of the arguments. I have tried to make these choices according to the following rules, in decreasing order of importance:''

* ''Favor an order that is more useful for partial applications.''
* ''Favor an order with significant mnemonic value.''
* ''Functions that modify a collection should take the collection last.''
* ''Consistency with similar operations.''
* ''Personal taste.'' 

----

perhaps related to WhyIsTheFirstArgSpecial ?