6 ms·

I get this might just boil down to preference but I absolutely hate named parameters. They’re biased towards new users of a language and quickly become painful

I get this might just boil down to preference but I absolutely hate named parameters. They’re biased towards new users of a language and quickly become painful to write once you’re familiar with the function call. 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).

m12k 6y ago
I disagree that named parameters are just biased toward new users. They're also biased toward reading rather than writing. I find that as a code base becomes bigger and more non-trivial, I end up reading code many times, and the more I appreciate named parameters.
- implicit 6y ago
  I understand what you're saying, but something I have noticed over the years is that the amount of code that I can make sense of at any given time is actually proportional to what I can see onscreen at any given moment. 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.
  - DonaldPShimoda 6y ago
    Yes, but this strategy is only suitable for a single developer, or a small group of similarly-experienced-with-that-specific-codebase developers. Onboarding somebody into a world full of single-character variable names and such is a headache. Named parameters are for reading code, and if you're not intimately familiar with the code on your screen right this second, they are helpful. 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!
    - laumars 6y ago
      > Onboarding somebody into a world full of single-character variable names and such is a headache. 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.
      - DonaldPShimoda 6y ago
        Yes, I agree! I was specifically addressing the parent comment's line about "I use a terse programming style." When it comes to functional programmers, they (more than any other group) will take terseness to the extreme in the form of single-letter variable names in inner functions, match forms, etc. 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.)
        implicit 6y ago
        The right balance here can depend on the specific business you're working in. 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.
        a1369209993 6y ago
        > When it comes to functional programmers, they (more than any other group) will take terseness to the extreme 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 https://news.ycombinator.com/item?id=23055793 1: https://news.ycombinator.com/item?id=16847641 https://news.ycombinator.com/item?id=16847641
- didibus 6y ago
  For a language that says it'll work hard to be IDE friendly, an IDE can easily show you the argument names and their order for any function. On IntelliJ, it even overlay them. Thus, you can be writer friendly and reader friendly, considering the reader uses an IDE.
  - Jaxan 6y ago
    But why not turn this around? Let the IDE autocomplete everything, so it’s easy for the writer (or even hide the named arguments). And have the named arguments in the source code, then all readers can read it no matter their IDE!
    - mattmanser 6y ago
      Because it's a pain to navigate with the keyboard, plus accidental completion means more deleting, and other little niggles like that.
  - structural 6y ago
    I can't disagree more strongly about this. Many, many times I'm trying to understand a codebase, and what I have is that codebase, not the dozens of dependencies involved, and not a full development/build environment. I may not even know what, if any, IDE the original developers used. 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.
enricozb 6y ago
They are biased to new readers of a codebase, not of a language, which is really just another way of saying that the code is very readable.
- laumars 6y ago
  I don’t think it’s fair to say what’s readable to new developers is the same as what’s readable to experienced developers nor even every developer. 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.
  - enricozb 6y ago
    I'm talking specifically about the function calls, which are effectively the same in C, Rust, Python, Lisp, Haskell, and many others. No matter how terse, it's always some form of <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.
    - laumars 6y ago
      I agree random boolean arguments are unhelpful. Good software development standards would say any uses of boolean values should be substituted with well named constants if the same value. However the advantage of having that baked into the language rather than forcing developers to via code reviews isn’t lost on me
Kuinox 6y ago
They are biased towards new users of a codebase, not only the language. 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.
agentultra 6y ago
How would function composition work without currying? You'd have to name everything, wouldn't you? 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.
- djhaskin987 6y ago
  That's the whole point of the syntax changes: to make the tradeoff that sacrifices terseness or efficiency or even composability in favor of readability. 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?
  - agentultra 6y ago
    I feel like that's a value statement and how you qualify readability would change the answer. I'm curious if Keli plans to maintain function composition in the face of named arguments. It would be quite nice to have both.
  - smabie 6y ago
    After learning some array languages, functional languages like Haskell are actually pretty verbose. 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.
- galimaufry 6y ago
  Just spitballing, but you could have composition eat the name of an input to the outer function: Given f(x,y) and g(z), write 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.
boxed 6y ago
I disagree 100%. I write with more and more named arguments. There are missing features to make it really nice in python though, like kwarg short forms like ocaml has.
WillPostForFood 6y ago
>I absolutely hate named parameters. They’re biased towards new users of a language and quickly become painful to write once you’re familiar with the function call. It is a fair complaint, but don't you think this is offset almost entirely by a good IDE?
- pmarreck 6y ago
  I haven't used an IDE in years. Just VSCode. Which is not really an IDE. I haven't missed it. I think that if a language depends on an IDE to be useful, it's a design smell.
  - rightbyte 6y ago
    VSCode is an IDE. Otherwise, what is am IDE according to you? Is Emacs an IDE? Eclispe?
    - eitland 6y ago
      VS Code (which I like and have used extensively for a number of projects) is kind of an IDE, but it doesn't quite compare to full blown Java IDEs IMO.
      - Joker_vD 6y ago
        It's an editor with syntax highlighter, autocompletion, go-to-def, and go-to-uses that also builds the code, runs the code, runs the tests, and also allows you to run them (code & tests) under a debugger. Oh, and it also has projects/solutions/workspaces/whatever they're called. 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?
        eitland 6y ago
        I wrote kind of like an 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.
gotostatement 6y ago
maybe named parameters only for functions with more than 2 arguments might be a good compromise?
cellularmitosis 6y ago
Advocating for trading away readability in favor of easing the lives of devs who refuse to use an IDE doesn't seem like a win, especially in the context of a team.
- laumars 6y ago
  I’m often writing code into vim (without any fancy plugins installed) and never had an issue. As I stated in my previous comment, I don’t particularly believe named arguments make it any easier to write without an IDE because you’re only trading memorising the order of parameters with the names of those parameters. Either way there’s still a minimum level of memorisation required. 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.
ogre_codes 6y ago
Disagree. Particularly since named arguments are part of the function name and in languages where you use named arguments you will often have very expressive overloaded function names. 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) Without named parameters, you are stuck with function names like: getStudentById, or relying on convention for naming parameters and often wind up with duplicate names or not knowing if a function is out there because your idea of naming is different from someone else's. Intellisense picks this up too and suggests the 3 different names. Works fantastic.
- kingdomcome50 6y ago
  I'm honestly curious what you see as the issue with "getStudentBy"-type function names. Could you expand on 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.
  - ogre_codes 6y ago
    See above.
    - kingdomcome50 6y ago
      Hmmm... I see where you are going there, but I don't understand how named arguments solve the problem[0] you have outlined. That is, a problem of discoverability. 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.
mikeryan 6y ago
and quickly become painful to write once you’re familiar with the function call 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.

m12k 6y ago

I disagree that named parameters are just biased toward new users. They're also biased toward reading rather than writing. I find that as a code base becomes bigger and more non-trivial, I end up reading code many times, and the more I appreciate named parameters.

implicit 6y ago
I understand what you're saying, but something I have noticed over the years is that the amount of code that I can make sense of at any given time is actually proportional to what I can see onscreen at any given moment. 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.
- DonaldPShimoda 6y ago
  Yes, but this strategy is only suitable for a single developer, or a small group of similarly-experienced-with-that-specific-codebase developers. Onboarding somebody into a world full of single-character variable names and such is a headache. Named parameters are for reading code, and if you're not intimately familiar with the code on your screen right this second, they are helpful. 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!
  - laumars 6y ago
    > Onboarding somebody into a world full of single-character variable names and such is a headache. 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.
    - DonaldPShimoda 6y ago
      Yes, I agree! I was specifically addressing the parent comment's line about "I use a terse programming style." When it comes to functional programmers, they (more than any other group) will take terseness to the extreme in the form of single-letter variable names in inner functions, match forms, etc. 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.)
      - implicit 6y ago
        The right balance here can depend on the specific business you're working in. 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.
      - a1369209993 6y ago
        > When it comes to functional programmers, they (more than any other group) will take terseness to the extreme 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 https://news.ycombinator.com/item?id=23055793 1: https://news.ycombinator.com/item?id=16847641 https://news.ycombinator.com/item?id=16847641
didibus 6y ago
For a language that says it'll work hard to be IDE friendly, an IDE can easily show you the argument names and their order for any function. On IntelliJ, it even overlay them. Thus, you can be writer friendly and reader friendly, considering the reader uses an IDE.
- Jaxan 6y ago
  But why not turn this around? Let the IDE autocomplete everything, so it’s easy for the writer (or even hide the named arguments). And have the named arguments in the source code, then all readers can read it no matter their IDE!
  - mattmanser 6y ago
    Because it's a pain to navigate with the keyboard, plus accidental completion means more deleting, and other little niggles like that.
- structural 6y ago
  I can't disagree more strongly about this. Many, many times I'm trying to understand a codebase, and what I have is that codebase, not the dozens of dependencies involved, and not a full development/build environment. I may not even know what, if any, IDE the original developers used. 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.

enricozb 6y ago

They are biased to new readers of a codebase, not of a language, which is really just another way of saying that the code is very readable.

laumars 6y ago
I don’t think it’s fair to say what’s readable to new developers is the same as what’s readable to experienced developers nor even every developer. 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.
- enricozb 6y ago
  I'm talking specifically about the function calls, which are effectively the same in C, Rust, Python, Lisp, Haskell, and many others. No matter how terse, it's always some form of <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.
  - laumars 6y ago
    I agree random boolean arguments are unhelpful. Good software development standards would say any uses of boolean values should be substituted with well named constants if the same value. However the advantage of having that baked into the language rather than forcing developers to via code reviews isn’t lost on me

Kuinox 6y ago

They are biased towards new users of a codebase, not only the language. 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.

agentultra 6y ago

How would function composition work without currying? You'd have to name everything, wouldn't you? 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.

djhaskin987 6y ago
That's the whole point of the syntax changes: to make the tradeoff that sacrifices terseness or efficiency or even composability in favor of readability. 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?
- agentultra 6y ago
  I feel like that's a value statement and how you qualify readability would change the answer. I'm curious if Keli plans to maintain function composition in the face of named arguments. It would be quite nice to have both.
- smabie 6y ago
  After learning some array languages, functional languages like Haskell are actually pretty verbose. 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.
galimaufry 6y ago
Just spitballing, but you could have composition eat the name of an input to the outer function: Given f(x,y) and g(z), write 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.

boxed 6y ago

I disagree 100%. I write with more and more named arguments. There are missing features to make it really nice in python though, like kwarg short forms like ocaml has.

WillPostForFood 6y ago

>I absolutely hate named parameters. They’re biased towards new users of a language and quickly become painful to write once you’re familiar with the function call. It is a fair complaint, but don't you think this is offset almost entirely by a good IDE?

pmarreck 6y ago
I haven't used an IDE in years. Just VSCode. Which is not really an IDE. I haven't missed it. I think that if a language depends on an IDE to be useful, it's a design smell.
- rightbyte 6y ago
  VSCode is an IDE. Otherwise, what is am IDE according to you? Is Emacs an IDE? Eclispe?
  - eitland 6y ago
    VS Code (which I like and have used extensively for a number of projects) is kind of an IDE, but it doesn't quite compare to full blown Java IDEs IMO.
    - Joker_vD 6y ago
      It's an editor with syntax highlighter, autocompletion, go-to-def, and go-to-uses that also builds the code, runs the code, runs the tests, and also allows you to run them (code & tests) under a debugger. Oh, and it also has projects/solutions/workspaces/whatever they're called. 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?
      - eitland 6y ago
        I wrote kind of like an 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.

gotostatement 6y ago

maybe named parameters only for functions with more than 2 arguments might be a good compromise?

cellularmitosis 6y ago

Advocating for trading away readability in favor of easing the lives of devs who refuse to use an IDE doesn't seem like a win, especially in the context of a team.

laumars 6y ago
I’m often writing code into vim (without any fancy plugins installed) and never had an issue. As I stated in my previous comment, I don’t particularly believe named arguments make it any easier to write without an IDE because you’re only trading memorising the order of parameters with the names of those parameters. Either way there’s still a minimum level of memorisation required. 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.

ogre_codes 6y ago

Disagree. Particularly since named arguments are part of the function name and in languages where you use named arguments you will often have very expressive overloaded function names. 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) Without named parameters, you are stuck with function names like: getStudentById, or relying on convention for naming parameters and often wind up with duplicate names or not knowing if a function is out there because your idea of naming is different from someone else's. Intellisense picks this up too and suggests the 3 different names. Works fantastic.

kingdomcome50 6y ago
I'm honestly curious what you see as the issue with "getStudentBy"-type function names. Could you expand on 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.
- ogre_codes 6y ago
  See above.
  - kingdomcome50 6y ago
    Hmmm... I see where you are going there, but I don't understand how named arguments solve the problem[0] you have outlined. That is, a problem of discoverability. 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.

mikeryan 6y ago

and quickly become painful to write once you’re familiar with the function call 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.