Hacker News Reader

Comment by jjoonathan | Hacker News Reader

or as Objective C:

    [[NSFileManager defaultManager] copyItemAtPath:src toPath:target error:&error];

Inspired by smalltalk, of course. ObjC's verbosity is legendary, and I'm not its hugest fan, but there's a key innovation here that I am a huge fan of: the language forces other people to name their arguments, in much the same way that python forces other people to indent their code, even if they would otherwise default to making a hot mess of things.

View on HN

That verbosity isn't even a big deal as you write once, but read many times.

One of the first things about Swift that I fell in love with was the difference between things like DrawRect(10, 20, 30, 40) in languages like C#, and DrawRect(at: origin, width: 30, height: 40) in Swift.

Named function parameters are nice, but you can accomplish something similar with only two more characters in some languages:

      DrawRect({at: origin, width: 30, height: 40})
  vs. DrawRect(at: origin, width: 30, height: 40)

I can understand why this is considered a nice-to-have. The verbosity didn't really change.

And then you have to check that the map you're being given has all the correct keys with the correct typed values. And when you're looking at the code, you see:

function DrawRect(options) {...

Unless you're immediately destructuring it or whatever. I don't think it's _that_ straightforward to compare the two, unless I'm thinking of the wrong languages here.

Typescript can specify required keys in a dictionary: function DrawRect(options: { at: Point2D, width: number, height:number}}

It will be checked compile time that all keys are provided (unless dict comes from serialized json or something).

That's more verbose than just having arguments though, right?

Slightly more verbose but not much. Just having arguments takes you back to square one where you might mix up the order of width and height since nothing is forcing the caller to use named parameters. Perhaps it would be better to have some linter enforcing such things.

It doesn't take you back to square one in languages which enforce named parameters, which I thought we were talking about.

You can accomplish it in other languages, but will all the other library authors do so? Do the OS libraries do so?

Two more characters and one more allocation per each LoC.

Most of us are just writing crud apps anyway so one more allocation is extremely affordable

Maybe but this highly dynamic programming style is why Macs have always been so much slower than Windows on equivalent hardware.

Where did that come from? Apart from games that were obviously optimized for Windows first then ported to macOS, has that claim been measured? Because macOS has always certainly FELT faster than Windows.

As if my app stops working because of this?

> I can understand why this is considered a nice-to-have.

Well typing is one good reason, maps usually are not statically typed with key:value pairs. That's more of a class / struct thing. And then the verbosity increases quite a bit.

You can (optionally) do the same name specified parameters in the more recent versions of c#.

Their documentation still encourages unnamed parameters:

https://docs.microsoft.com/en-us/dotnet/api/system.drawing.r...

You can do that in c#, though an IDE like Rider can also display it like that when no label is provided, or insert the labels, depending on your preference.

IntelliJ does that for Java these days too, and I love it.

I'd rather have syntax-level support (works with ctrl+f, works outside IDEs, works in IDE when auto-analysis is broken), but if IDE support is what I can get, I'll take it.

> That verbosity isn't even a big deal as you write once, but read many times.

One of the most pernicious myths of software engineering is that it happens.

"Reading" code in this sense doesn't just mean explicit review by different people, but also as in reading it subconsciously as you scroll through your own code.

If I see a chain of numbers like 1, 2, 3, 4 my brain has to recall the order of parameters or look it up.

If I'm looking for rectangles that should be wider than they are tall, I have to keep thinking "the third number should be higher than the fourth number"

Oh and I can't just Cmd+F "width:" or "height:" either.

It's unusual to sit down and read a subroutine for pleasure, but it's common to read it when you're debugging a problem, trying to figure out how to extend the subroutine, refactoring something it calls, or doing something similar somewhere else.

I would enjoy an explanation of your thinking.

In Python, by default you can use keyword arguments for any function parameter.

And if you want, you can make arguments keyword-only:

  def copyFile(*, source, dest):
      ...

Parameters after the asterisk cannot be specified by positional arguments. It must be called with keyword arguments:

  copyFile(source=src, dest=dst)

Python's kwargs are still optional in the sense that I care about. Same goes for many other kwarg-supporting languages.

The strategy you propose can only force other people to use kwargs when calling functions you write. When you're reading code, there is no guarantee that arguments to functions you didn't write will be labeled, and indeed they often aren't, even when they ought to be. In ObjC, all arguments are labeled, always. It's heavily opinionated, and the experience is qualitatively different as a result.

This syntax is part of the reason why I really enjoyed working with objective-C, it's just so self-descriptive. Coming from Java which doesn't have that, which relies on an IDE like intellij to give you hints on what arguments go where, OR on design patterns like argument objects or builders, it was a big relief - even if it's kinda long / verbose.

Honestly thinking back on Java there were a lot of design patterns and code (sometimes generated) that could've been avoided with e.g. named function parameters.

> otherwise default to making a hot mess of things.

one can still make a hot mess of 1000-wide lines, bad variable names, and various other forms of spaghetti cowboy-ism.

Yep, no doubt about it.

My aim isn't to argue that forced named args will cure all that ails you, just to share that they "feel" quite different from optional named args, and that on the balance I felt they were a net positive.

outputImageProviderFromBufferWithPixelFormat:pixelsWide:pixelsHigh:baseAddress:bytesPerRow:releaseCallback:releaseContext:colorSpace:shouldColorMatch

  [NSCarpalTunnelSyndromeInducer induceCarpalTunnelSyndromeForProgrammer: ....]

Or, ya know, you use XCode and it autocompletes the function signature for you.

[NSStream dammit]

Okay then

     [NSEyeStrainInducer induceEyeStrainForProgrammer: ....]

Unless XCode can read the signature for me in addition to writing it

Good news, it can! Either way objective-c is much more readable than it is writeable. It’s writeable with an IDE and readable without.

XCode is really unpleasant as far as IDEs go.

Reply on news.ycombinator.com