Hacker News Reader

Comment by fyolnish | Hacker News Reader

Alternate title: "Unnamed parameters considered harmful"

Alternate (better) solution to the author's problem: Use enums

Alternate (better) solution to the author's problem: Use a language where all parameters are named, like Smalltalk or Objective-C.

   document addObserver:observer forNotificationNamed:'load' isWeak:false.

   xhr openURL:options url type:options type async:options sync negated

But even there, I would prefer:

[document addWeakObserver: observer forNotificationNamed: 'load']

and

[document addObserver: observer forNotificationNamed: 'load']

Assuming for a second, that the non-weak observer should be the normal case.

So wordy and repetitive and wordy.

Not a problem if autocomplete is working.

The issue with autocomplete is that it makes writing a lot of code really easy but offers no help when reading the code. Syntax/semantic highlighting may help a little but the issue is still there.

Given that more time is spent reading than writing code, autocomplete is only a partial solution to this problem.

I consider verbose code to be more readable in general. However one has to take more time when naming their functions and parameters.

This comment makes sense for the original problem, but not for the message you're replying to, as keyword parameters help tremendously with readability.

I've never worked in those languages, but I suspect I'd end up with a lot code like this:

foo(author: author, title: title, price: price)

The problem in the article is real, but it is the exception. If it's hard to see what 5% of your parameters mean, forcing 100% of them is probably a cure worse than the disease.

When I worked in Java with IntelliJ, the solution was to simply hover over the call, and the declaration would appear.

IDEs fix both problems: writing verbose code and reading terse code. The thing is, code isn't always examined in a working IDE, and it tends to be read outside of an IDE more than it tends to be written outside of an IDE.

The disease is far worse than the cure. I frequently (at least once a day) find myself wishing code was written in the smalltalk style but I've only found the smalltalk style inconvenient on a small number of occasions.

While I can't speak to what you would end up with, my experience (~quarter of a century) is that this is not the case. To verify, I just did

   ack '\[.*:' | less

to search my code-base for message sends with parameters. Scanning the first hundred or so results shows the pattern you mention to be rare.

Dan Ingalls explains the syntax really nicely in this video:

  https://youtu.be/P2mh92d-T3Y?t=600

With this type of syntax, most APIs turn into EDSLs all by themselves, and often read like fairly natural sentences.

I ramble on a bit about the relationship between keyword syntax and (lack of) operator overloading:

  http://blog.metaobject.com/2015/03/why-overload-operators.html

So memorable.

Much bugfree

Alternate (even better) solution: Use a language where you can optionally name parameters, like C#.

    xhr.OpenUrl(url, async: true);

Actually, even in Objective-C it's technically optional to give your parameters names. Feel free to knock yourself out with method signatures like:

    - (void)doMysteriousThingsWithParameters:(int)x :(BOOL)y :(NSString*)z;

I've come across this recently when creating an HTML5 <canvas> context object to be called from within JavaScriptCore. This needs to expose JS-friendly methods like:

    - (void)strokeRect:(CGFloat)x :(CGFloat)y :(CGFloat)w :(CGFloat)h;
    - (void)arc:(CGFloat)x :(CGFloat)y :(CGFloat)radius :(CGFloat)startAngle :(CGFloat)endAngle :(BOOL)antiClock;

Interesting. I don't use Object-C, but always heard parameter names are actually considered to be part of the method name there. Was that wrong?

Ah, or do you mean the name is just empty? How does that work on the implementation side? I.e. how do you refer to the passed arguments?

Parameters don't have names, the message has a format, and th only rule of that format(referred to as a "selector") is that parameters are preceded by a :

More, more parentheses!

too much verbose.

I prefer python approach, where you can set "optionally named" and "kwarg only" parameters" on a per function basis.

For a description, see https://www.python.org/dev/peps/pep-3102/

Oh come on, we both know that if you give people a choice the feature will be underused. If you want proof just look at python code!

I don't understand. What you mean?

> Use enums

For internal but not external APIs. Enums create tight coupling and are not extensible. Booleans and Enums should be avoided for external APIs.

What are you talking about? How is using an enum more tightly coupled/less extensible than a function name?

I usually don't care if my booleans are extensible or not.

Well that's just a lack of ambition on your part:

http://thedailywtf.com/articles/What_Is_Truth_0x3f_

Oh man, i should not have started reading DailyWTF. When booleans attack:

http://thedailywtf.com/articles/tri-state-boolean

http://thedailywtf.com/articles/Special-Delivery

Instead of booleans or enums why not have different methods for each value of the bool/enum, e.g.: openAsync(...), open(...)

Instead of having different methods like open/openAsync why not have enums?

Different names don't scale well beyond a single boolean argument.

I've seen this in practice a lot in jQuery and many people with jQuery experience. You end up with methods like showFoo / hideFoo, enableFoo / disableFoo, and then you have to continuously write if-statements like this:

    if (someCondition) {
        showFoo();
    } else {
        hideFoo();
    }

Instead of:

    setFooVisible(someCondition);

The point being, creating lots of different methods for each variant reduces one's ability to use other abstraction tools, like variables, to control parameters.

Functions are first-class values, so what's wrong with:

    (someCondition? showFoo : hideFoo)();

You can also pass in arguments if they both accept the same parameters, eg.

    (someCondition? show : hide)(foo, duration);

Except they're methods so you have to write

    (someCondition ? foo.show : foo.hide)();

except the language does not auto-bind so you have to write

    (someCondition ? foo.show : foo.hide).call(foo);

or maybe

    (someCondition ? foo.show.bind(foo) : foo.hide.bind(foo))();

Or:

    foo[someCondition? 'show' : 'hide']();

Although looking up functions using raw strings is less than elegant. I'd be tempted to abstract the pattern using a function, but at that point I'd be doing functional programming anyway and wouldn't be using methods ;)

> I've seen this in practice a lot in jQuery and many people with jQuery experience.

A bit odd given jQuery often provides both options e.g. show[0]/hide[1] and toggle(bool)[2].

[0] http://api.jquery.com/show/

[1] http://api.jquery.com/hide/

[2] http://api.jquery.com/toggle/#toggle-display

Yes (and toggleClass too), but they were only added in 1.3.

Reply on news.ycombinator.com