function foo({ bar }: { bar: string }) {

Plus they don’t always improve writability outside of IDEs because you then have to memorise the parameter names and in some functions there’s several terms that could equally apply (if you’re using an IDE with hinting then the advantages become moot as the same IDE would hint the order of parameters).

I have had pretty good luck cheating this in a bunch of ways: I use a small font, a big display, and I use a terse programming style.

Once you internalize a bunch of common higher-order functions, you learn how to draw a ton of meaning out of a relatively small number of terms.

I think what we really need is a sort of "lens" system by which we can modify the syntactic appearance of our code without adjusting the semantics, but do these changes on-the-fly. So say you're doing some debugging or whatever and you're gonna be staring at the same 300 lines of code for a few days — so you switch over to "terse" mode and suddenly the named parameters are gone and the variable names are abbreviated (assume a magic system that picks good terse variable names according to your preference). But then when you're done with that section and ready to venture into the remainder of the codebase (or if you're a new developer who's unused to the team's naming conventions or whatever), you can use "verbose" mode that shows the parameter names and whatnot.

I imagine something like this is not obviously straightforward, but it could be worth investigating!

The opposite of named arguments isn’t single character variable names. Any organisation with an enforced coding standard would ensure that variables are descriptive irrespective of whether that language uses named arguments or not.

I didn't mean for my comment to be entirely literal, either. Rather, I just meant to say that terseness can impede readability for those who are not yet familiar with the codebase. (But I have personally been on the receiving end of onboarding into a codebase full of literal single-character names, which I found incredibly frustrating.)

You should really read about APL and other array languages then. (I don't have a good starting point, but they tend to come up on HN periodically such as [0] [1]).

0: https://news.ycombinator.com/item?id=23055793

1: https://news.ycombinator.com/item?id=16847641

Some companies earn the privilege of a super tenured core team of engineers who work on their product for an extended period of time. They will choose different tradeoffs from a team that needs to adapt to higher turnover.

Thus, you can be writer friendly and reader friendly, considering the reader uses an IDE.

There's also very common sources of bugs when functions take multiple arguments of same (or sadly in some languages, implicitly convertible) types. With named arguments in complex functions, you can sit down, read the code, and spot the bugs. Happens frequently enough in code review that we have a category for it. Without named parameters here, every single function call becomes a game of "mouse over the parameter in the IDE". Moreover, "you can just read the docs inline in the IDE" also causes people to not think much about naming things, which also harms maintainability.

It's a real issue in large, long-lived codebases that may not seem like much in smaller projects.

For example the terse style of Sexpressions or C-style braces are off putting to some but after a short while they become second nature to visually parse (not saying all code should follow Those idioms, just using that as an example of how readability changes with experience). On the other hand I never found it as straightforward visually parsing the “word soup” of named arguments when using languages that favoured it. While those languages were easier to learn the basics, they quickly became tiresome to write larger code bases with.

But I guess this just boils down to personal preference.

<name of function> <value1> <value2> <value3> ...

The absence/presence of parenthesis and commas don't add anything of semantic value here, so that's not really what I'm referring to.

The problem is, is that the values often don't have any meaning attached to them, especially when they are literals. C++ codebases are pretty bad about this with boolean parameters, just having a random `true` at the end of the function call.

Variable names at the call-site are good hints, but we often pass the same variable to different functions, and the name doesn't exactly fit the meaning of each function. This is why I think requiring named parameters, at least by default, is better.

You might have 3 related functions like so:

  getStudent(datastore: DS, byId: number)
  getStudent(datastore: DS, byAssessmentId: number)
  getStudent(datastore: DS, firstName: string, lastName: string, birthdate: date)

Intellisense picks this up too and suggests the 3 different names. Works fantastic.

If you have named parameters, this just works:

  `getStudent(classRoom: 15, firstName: "Mary", lastName: "Jane")`
  `getStudent(classRoom: 15, firstName: "Mary", lastName: "Jane", middle: "Anne")`

(slight tangent)

Far better with overloading in general is being able to have 2 methods with the same name which return the same thing but have different types of inputs. Like in Elixir, you can have an API callback be `handle(apiResult)`, then have 2 functions, one which handles the error and one which handles the success. Zero logic written to filter out bad-calls, it's just the same method with different types (the Error result type and the Success result type). Vastly simplifies and cleans up that kind of code.

I really loved using Elixir, very frustrating going back to TypeScript after that.

Of course I understand a name could become rather verbose in your last case, but I'm not satisfied that it would be much of an issue in practice.

Like what, precisely, does the autocomplete show in your editor when you type `getStudent` vs `getStudentBy` that makes the former so much better? In either case you are left to disambiguate either the correct overload or the correct method unless... well... you already know there is an overload that accepts the data you happen to be working with. Presumably you would also then know the correct method name.

I suppose it's possible to start typing your named parameters directly and the editor "fills in" name you are going for? But that poses nearly the same problem again: "Wait... is it 'nationality' or 'country'? Did we decide on 'lastname' or 'surname'?"

I agree the `getStudentByCountryAndName` isn't a great signature, and that wrapping all of the args into a single DTO like `StudentInfo` is not so great either. But I can honestly say, I have never once run into a problem of finding a method in the wild! Even if we had numerous `getStudentBy`-type functions all with similar signatures/names it probably wouldn't take more than a few seconds to narrow down to the one of interest.

I also find, from a consumer perspective, named-parameters to be less ergonomic. I like that when I type `getStudentById(` my editor boldens the argument I am meant to pass next. I don't have to decide which parameter I am going to pass next... my editor just walks me through the function (maybe I'm just lazy!)

To be clear, I am not arguing against named-parameters. Though I dislike that they broaden the public surface of functions, I suppose I would rather at least have the option to use them than not at all. I just don't really see, in a practical sense, how they would improve a code-base beyond some fairly niche scenarios that are probably a code smell anyway.

[0] It seems to me your argument is more aimed towards overloading than named-parameters in particular, but I will accept that there is significant overlap in this space.

Why would you want a function that gets students to be called anything other than `getStudent`? Fundamentally, the simpler, easier to parse your function name is, the more readable and editable your code is.

I definitely think overloading functions is more interesting/ important than named parameters. But named parameters are useful both for overloaded functions and for optional parameters where you might not know what the 3rd/ 4th parameter might be.

One pattern I see frequently in languages which lack named parameters is instead of using optional parameters, people pass objects with optional properties. This is used a ton in Javascript/ Typescript. If the language supported proper named & optional parameters, it wouldn't be an issue.

I'm thinking of how you could write in point-free style or even have a `(.)` function to begin with if you had the Smalltalk "message passing" style.

Sure the Haskell syntax is a bit much when you're not familiar with it but, like almost any language, it's often the least-interesting part of the language and the most talked about.

A lot of functional languages -- Haskell as I understand it is the biggest perpetrator -- optimize for code length and composability, trying to make things as expressive as possible, and decrying those who can't read something that has meaning densely packed into every single character as those who are "simply not familiar" with the language.

But that's what OP is saying: OO languages go for readability and not expressiveness, and wouldn't it be cool if there was an FP language that did the same thing?

I'm curious if Keli plans to maintain function composition in the face of named arguments. It would be quite nice to have both.

Moreover, I believe that in general, shorter code is more readable code. People just like to make excuses in order to avoid learning anything new.

let q = (f .y g)(z=a) then q(y=b) = f(x=g(z=a), y=b)

let q = (f .x g)(z=a) then q(z=a) = f(y=g(z=a), x=b)

Aesthetically it would be kinda like the notation for fiber product.

Named arguments improve readability of a code if you are not used to a codebase. By improving readability, you also improve maintanability: you need less experience in a codebase to make a change.

You focus on writability where it's not the biggest issue of the field, it's software debt.

I get each developer is different but personally I remember numbers and orders easier than names.

And frankly, if you have a developer who can’t learn the basics of the language they’re employed to work on yet also refuses to use any developer-friendly tools to assist him, then that’s a failing of the the developer and not the language.

JavaScript's more recent structuring/desctructuring arguments has made this pretty seamless as long as you name your variables well.

For the most part switching from ordered to named is just func(arg1, arg2, arg3) is just foo({arg1, arg2, arg3})

You may need to rename or pass in the params on the call but it's generally pretty nice. As an above comment says about Clojure - as soon as I need a third argument in a function I switch from ordered to named and its pretty painless.

It is a fair complaint, but don't you think this is offset almost entirely by a good IDE?

Second, if a language is heavily reliant on features from an IDE, yeah, I'll echo that's a badly designed language.

Back in my days™ that's what they used to call an "IDE". But today that's just "glorified Notepad++", I guess? What features does it miss that stop it being a full-blown IDE?

Maybe I'm just a spoiled brat, but I came to Java from C, PHP, Visual Studio (the old one) and learned how nice programming could be before I left for .Net Core and frontend (with much TypeScript), mostly in VS Code but sometimes in Rider and Webstorm.

To me, to be a real IDE these days you need to have proper refactoring support.

And to a spoiled brat like me that excludes almost everything except Rider, Visual Studio with Resharper, NetBeans, Eclipse and IntelliJ :-)

But yes, I too am old enough to remember back when the C/Assembler program we used to program microcontrollers were considered IDEs.

And technically you are of course correct :-)

I guess a better classification would be: IDE level 1,2,...n where what I call IDEs today are really level 3 IDEs.

  splitBy "," : String -> List String

As an alternative, perhaps there's space to introduce types to make this something like

  split : Pattern -> String -> List String

The 'splittee' should be the last argument. The last argument is usually what you want to a) elide as part of function composition, or b) loop over (the tightest).

E.g. Splitting a file into lines:

    lines content = splitBy "\n" content

    lines = splitBy "\n"

    lines = (\c -> splitBy c "\n")

    entries content = concatMap splitBy "\t" (splitBy "\n" content)

    entries = concatMap splitBy "\t" . splitBy "\n"

    entries content = concatMap splitBy (splitBy content "\n") "\t"

  lines content = content .splitBy "\n"
  lines = (.splitBy "\n")
  dec x = x - 1
  dec = (- 1)

But that doesn't actually solve the problem.

  "Hello world".replace("Hello","Bye") // works fine
  but
  somesequence join: "," // still doesn't work
  // unless every $Sequence implements join explictly

    -- Is this correct?
    splitBy ","  "1,2,3,4,5"

    -- or this?
    splitBy "1,2,3,4,5"  ","

In the OOP language example the second version with the string knowing how to split itself, as it were, does make more sense than the first version. The target of the method is always the subject, and the method name is usually read as a verb, with parameters as direct or indirect objects. (Read as: String "1,2,3,4,5" (S), split yourself (V) by the string "," (I.O.).) However, in functional programming the bias is exactly the opposite, because functional programming is about programming with first-class functions on data, not performing actions. You could easily arrange to write:

    "1,2,3,4,5" `splitBy` ","

    splitBy ","

> I think, in general, requiring named arguments is a good thing.

I have no objection to optional named parameters, but making them required would necessarily eliminate currying and simple function composition, and that I have a problem with. Record parameters with named fields are generally sufficient for the situations where named parameters are useful, especially since they're ordinary data which you can manipulate at will and not some special syntax baked into the language just for function calls.

It occurs to me that this could have been avoided at the language level by defining infix notation to implicitly flip the arguments. For example,

    x / 3 == (/ 3) x == (/) 3 x

    x ++ "suffix" == (++ "suffix") x == (++) "suffix" x

    x `splitBy` "," == (`splitBy` ",") x == splitBy "," x

Of course, it's much too late to be changing something so fundamental at this point. Even as an extension it would cause far too much confusion.