If I'm writing a function where there isn't an obvious order for the arguments, I chose the order such that Currying is most useful, even if the language I'm writing in doesn't support Curried functions/partial function application. You never know when someone will port your code or create cross-language bindings.

For instance, my company writes a lot of code in a proprietary language and the other day I was writing a function to generate random strings, given a length and an "alphabet" string from which to choose characters.

I chose the ordering:

    randomString alphabet length = ...

so that if partial function application were added to the language, one could simply write the functions randomHex and randomBase32 as:

    randomHex = randomString "0123456789ABCDEF"
    randomBase32 = randomString "ABCDEFGHIJKLMNOPQRSTUVWXYZ234567"

The alternative ordering would allow me to easily write functions that generate fixed length strings and take their alphabets as inputs:

    random10Char = randomString 10
    random4Char = randomString 4

This ordering is much less useful in general, so I chose to make the alphabet the first parameter.

On a side note, our language also has some time series extensions for dataflow programming. There's an API for efficiently adding new data flows based on something similar to template specialization, but the API is unwieldy and the source of much confusion. So, I wrote a wrapper API that uses reflection to expose the same functionality as partial function application / Curried functions over time series.