The solution (to me anyway) requires BOTH that parameters must be named, as well as cultivating a culture of creating types aggressively (and, together with tha

The solution (to me anyway) requires BOTH that parameters must be named, as well as cultivating a culture of creating types aggressively (and, together with that, a language that makes it easy to do this, to avoid the onus of making types leading API developers to make the wrong choice). Instead of doing: downloadFile(String url, String filePath) which runs into the ordering issue raising in the article, if it was: downloadFile(Url from, FilePath to) you no longer have the issue. But, having some way to name the parameters, which can take _many_ forms works just as well. It would help a lot if the language can enforce that you must do this: named params: downloadFile(from = "https://something/foo.txt", to = "/some/path") objC style where the function name is split up: downloadFileFrom: "https://something/foo.txt" to: "/some/path"; same as above, but with fluent-style intermediates: download().from("https://something/foo.txt").to("/some/path"); pass an object (Javascript): downloadFile({from: "https://something/foo.txt", to: "/some/path"); these all work just as well. And nevertheless, this: download(server, file) is cleaner than all of the previous attempts, and allows passing these concepts around helper methods and the like. So, _IF_ it makes sense to change the types of the arguments so that you no longer have the same type for different arguments, it seems preferable to me. However, in the case of CopyFile, to take that to its logical conclusion, you'd have a separate type to represent a 'from file' and a 'to file', but that seems too much of a stretch: The notion of a file fundamentally doesn't have a 'direction' concept built into it; that makes sense only for a copy or move API. Making separate types to represent the tuple of [direction, filepath] seems like a hacky way to introduce named parameters. So, have both.