Hacker News Reader

Comment by m12k | Hacker News Reader

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.

View on HN

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.

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!

> 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.

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.)

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.

> 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

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

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.

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!

Because it's a pain to navigate with the keyboard, plus accidental completion means more deleting, and other little niggles like that.

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.

Reply on news.ycombinator.com