Be wary of functions which take several parameters of the same type

   shutil.copy(src='foo', dst='bar')

    [[NSFileManager defaultManager] copyItemAtPath:src toPath:target error:&error];

    contents = ReadFile('foo')
    WriteFile('bar', contents)

    WriteFile('bar', ReadFile('foo'))

CopyFile(src: "foo", dest: "bar");

Funny, I don't think I've actually seen a fluent file API like this before. I guess most languages have file I/O built in to their standard libraries.

My immediate reaction to this, though, is that you could make it more general:

    File('foo').CopyTo('bar');

    .ReadAsText()

    .MoveTo(target)

    .SetOwner(owner)

    .GetFullPath() 

In this program below, the only place that suffers from having created a newtype for the strings is the place where they're created (parseArgs) and where they're used (copyFile). None of the other functions (main, helper1, helper2) ever need to peek inside the type, so there's no boilerplate but still all the type safety.

  newtype Source = Source Filename
  newtype Dest = Dest Filename

  -- Boilerplate at usage
  copyFile :: Source -> Dest -> IO ()
  copyFile (Source from) (Dest to) = ...

  -- Boilerplate at creation
  parseArgs :: IO (Source, Dest)
  parseArgs = do
    [arg1, arg2] <- getArgs
    (Source arg1, Dest arg2)

  -- Helpers with NO boilerplate
  helper1 :: Source -> Dest -> IO ()
  helper1 from to = copyFile from to

  helper2 :: Source -> Dest -> IO ()
  helper2 from to = helper1 from to

  main :: IO ()
  main = do
    (from, to) <- parseArgs
    helper2 from to

    (from, to) <- parseArgs
    helper2 to from

   Copy.from('foo').to('bar').execute();

   Copy.from('foo').to('bar').owner('me');
   Copy.to('bar').from('foo');

  struct copy_args_s {
    char * src;
    size_t src#;
    char * dest;
    size_t dest#;
  };
  int copy(struct copy_args_s args) {
    ...
  }
  int main() {
    copy((struct copy_args_s){ .src = "foo", .src_len = 3, .dst = "bar", .dst_len = 3 });
  }

  struct copy_args_s {
    char * src;
    size_t src#;
    char * dest;
    size_t dest#;
  };
  int copy(struct copy_args_s args) {
    ...
  }

  #define copy(...) copy((struct copy_args_s){__VA_ARGS__})

  int main() {
    copy(.src = "foo", .src_len = 3, .dst = "bar", .dst_len = 3);
  }

A problem I have with the types solution is that, although it's easy to tell if the code is wrong, it's often a bit of a puzzle in my experience to figure out how to write it in the first place: "Hmm, this takes a Foo and a Bar. Can I construct a Foo from a string? No, but I can construct it from a Baz or a Quux. Can I construct a Baz from a string? No, just an int. How about a Quux? Yeah, there we go. Now, how about that Bar?". And I've seen other people have that problem too, especially novice programmers. I'm not a novice but it's still a problem for me in a new type-heavy API.

I realized I was creating that problem in Yeso, and I couldn't figure out how to simplify the API, so in addition to starting the documentation with complete examples, I made a graph with graphviz that shows the type structure of the API: https://gitlab.com/kragen/bubbleos/blob/master/yeso/README.m...

I don't have that problem with named-parameter interfaces (I just look at the list of methods and parameter lists), and maybe I could run into it with fluent interfaces in theory, but in practice that hasn't been much of a problem in my experience.

The article author was writing in Golang, which doesn't have named parameters, but in languages like Python, Lua, Clojure, or, as you say JS, named parameters are straightforward. In Lua it's even simpler than in JS:

    copy {from='presentation.md', to='/tmp/backup'}

    'foo' `copyTo` 'bar'

```c# var source = new FileSystemFile("source"); source.CopyTo("target"); ```

Of course, this isn't the only way to do it; you get the usual footguns as described in the article too.

Also apologies if the formatting is crappy - on mobile, and TBH not sure what markdown-like syntax HN supports, despite being a long-time user!

  def foo(x=None, y=None):
    ...

  foo(x=1, y=2)
  foo(1, y=2)
  foo(1, 2)

  CopyFile(from: loaded_file, to: report_file)

  // loaded_file is now the report - so no worries.
  loaded_file = report_file

Which is really what we want to have happen because - at the very least it forces the developer to go inspect the usage sites to figure out if what they're doing makes sense.

Vector3(...)

VectorXYZ(...)

The second variant could be weird depending on application.

Still, I see some people argue that positional arguments should be forbidden in newer languages but I would disagree and my main argument would indeed be laziness.

Developing C# in rider if you call `foo(a,b)` then it'll display as `foo(from: a, to: b)` in the IDE.

    Source("presentation.md").CopyTo("/tmp/backup")

I had an adventure upgrading versions of the .NET Core Rabbit library: one of the (boolean) parameters of the Consume function used to be “noAck”, but it got changed to “autoAck” (with inverted behavior). Even though the change was well documented, I would have preferred that to be a breaking change at compile time...

  a + b     -- '(+)' function used infix
  (+) a b   -- '(+)' function used prefix

  min a b   -- 'min' function used prefix
  a `min` b -- 'min' function used infix

ĉu A estas pli granda ol B? (S-V-O) (lit. "whether A is more big than B?")

ĉu A pli granda ol B estas? (S-O-V)

ĉu estas A pli granda ol B? (V-O-S)

and never "estas pli granda ol A B" as you suggest, but also never avoiding any indication that it's a question.

From a natural language side, it feels very contrived and arbitrary to have one hill measure whether it is bigger than another hill, instead of having an observer measure both 'from the outside'. That suggests the imbalance in syntax between a. and (b) is strange. a > b is more balanced and looks more like an outsider doing the comparison.

0: https://docs.swift.org/swift-book/LanguageGuide/Functions.ht...

However, after your comment, I decided to spend a few minutes on the topic, and came up with these links:

https://www.fluentcpp.com/2016/12/08/strong-types-for-strong...

https://www.fluentcpp.com/2018/12/14/named-arguments-cpp/

I am now looking forward to refactor some of our code base to make use of this. Awesome and thanks for the nudge!

* In C, the convention is "move(destination, source)". See memcpy, snprintf, strftime, others, but not all functions follow this convention. PHP is known for having lots of functions in standard library with differing conventions.

* It's easier to tell that "move(from=X, to=Y)" is correct than "move(X, Y)" though?

* I agree with the over-verbosity, but your last point that "annotating your arguments makes your code over-verbose and harder/slower to comprehend; instead, put all these guards and magic in the definition of the function" - isn't that also making your code harder/slower to comprehend, but this time you're putting the mindwork in understanding the function instead?

What problems would you see arising (either directly or indirectly) from the specific suggestion in the article, for example?

This isn't about removing flexibility, it's about helping people to avoid making easy mistakes that could be prevented.

    class Hours : NewType<Hours, double> { 
        public Hours(double x) : base(x) {} 
    }

* Equality operators, Equals, and IEquatable

* Ordering operators, CompareTo, and IComparable

* GetHashCode, ToString

* Map, Select, Bind, SelectMany, Fold, ForAll, Exists, Iter

* Explict conversion operator to convert from the NewType to the internal wrapped type

* Serialisation

* Hours.New(x) constructor function (often useful when used with other methods that take first-class functions).

It's even possible with the more complex variants to provide predicates that will run on construction to constrain the values going in.

There's also NumType for integer numeric types like int, long, etc. and FloatType for floating-point numeric types like float, double, etc. They give additional functionality by default.

Also, units of measure [4]:

   Length x = 10*inches;

   Area y = x * x;

   Time t = 10*sec;

[2] NumType - https://github.com/louthy/language-ext/tree/master/LanguageE...

[3] FloatType - https://github.com/louthy/language-ext/tree/master/LanguageE...

[4] Units of Measure - https://github.com/louthy/language-ext/tree/master/LanguageE...

Some languages have banned positional arguments, like Obj C, but these do get a reputation for being verbose. And verbosity, past a point, hinders readability.

My inclination is that for unary and binary functions, positional arguments should be sugar for the keyword arguments, and anything beyond that must be keywords.

An alternative rule could be you're allowed to designate one positional argument.

Keep in mind, also, that I'll bet there's code in keyword-only languages that just uses single letters for all the keywords. Some people just won't or can't write readable code.

And the compiler wouldn't notice.

You could uused a Roslyn analyzer that gives a warning "methods with consecutive args of the same type should use named params" I guess. Or a warning could be made at the declaring site "Don't declare methods with consecutive args of the same type".

This isn't so much "obvious" as "irrelevant"; the arguments to max are all exactly equivalent -- their order can't affect the result.