Hacker News Reader

Comment by jedsmith | Hacker News Reader

I see your Java, and raise you Objective-C:

    NSString *thing = [NSString stringWithFormat:@"Result: %@", [foo someoneCouldntComeUpWithAShorterNameWithZipcode:08205 name:@"larry" parcels:5]];
    NSDictionary *request = [NSDictionary dictionaryWithObjectsAndKeys:@"iphoneapp/0.1", @"User-Agent", @"news.ycombinator.com", @"Host", nil];

This isn't to kick off pet language wars, by the way, just to point out that my OCD tic to wrap to 80 characters has absolutely zero place in Xcode. Or Java.

View on HN

While it can get a bit silly sometimes, I've come to really appreciate the verbosity of Obj-C method calls. Explicit parameter names make them very self-descriptive, and grouping the entire call within brackets makes structure obvious. Compare:

  canvas.drawImage(kittens.subImage(vec2(10,10),vec2(20,20)),vec2(30,30))

  [canvas drawImage:[kittens subImageAt:vec2(10,10) withSize:vec2(20,20)] at:vec2(30,30)]

Yes but some of the examples of obj-c I've seen look ridiculously wordy compared with the smalltalk equivalents (even if you ignore op overloading). (setObject: forKey:) vs (at: put:). for ex.

disclaimer: I have not tried these. Totally pulling these from a quick googled-refresher of macros.

  #define withZip someoneCouldntComeUpWithAShorterNameWithZipcode 
  #define dictWith dictionaryWithObjectsAndKeys
  or 
  #define dictWith NSDictionary dictionaryWithObjectsAndKeys
  so you can [dictWith: key, value, key, value]

:) I forget, does XCode intelligently handle macros? Or does using a macro destroy its helpful features, like code completion?

I actually have a "hashWith" utility function for my .NET code. Saves me a ton of ugh-induced headaches.

I haven't worked a lot with XCode, but I remember using macros without problem.

Doing that is probably fine if you are working alone and nobody will ever read your code. Reading Objective-C is already enough of a challenge without having to context switch to a header just to mentally resolve symbols.

Instead of using a macro for the selector:

    NSDictionary *frob = [NSDictionary macroHere:v1, k1, v0, k0, nil];

It would probably be far more efficient to macro the entire call using C99's variadics:

    NSDictionary *frob = DICT(v1, k1, v0, k0);

Still wouldn't walk that road, personally.

Yup, macros are a bad idea in that regard. Had to work on a codebase where the prior programmer had fancy defs like _dict k1, v1, k2, v2, k3, v3 dict_

I wasn't too happy about that :/

The reason I went for the selector is because it makes the macro into essentially a function-typedef. I don't know any languages which allow typedefs to specify things like `Class.short = Class.super_long_name_here`, even though it's essentially the same concept, especially if looked at from a C standpoint. It's a minimally-intelligent text replacement.

IMO, something like `[NSDictionary with:key,val,key,val,nil]` is far less brain-taxing than `DICT(key,val,key,val)`. It fits without modifying the language or the syntax, it merely makes something long shorter, and the usage implies it does nothing "shiny" - you even keep the class name you're calling, making it clearer what you should be expecting, and it still allows access to all other parameters without modification or even thinking differently. DICT(...) is ambiguous about what kind of dictionary it's returning.

"just to point out that my OCD tic to wrap to 80 characters has absolutely zero place in Xcode. Or Java."

Dude. Are you still using CGA? Unless for your IDE you're running emacs on your wristwatch or phone there's no place for that shit in the real world, and you have no excuse.

Ditch that green cathode ray tube, here, have 50c and go buy yourself a real monitor. :D

Lines longer than 80 chars are harder to scan, and sticking to this rule allows tiling of windows. Maximising code windows on a widescreen is a huge waste. Even with long lines the average line length will be far shorter.

This is Guido's reasoning for keeping PEP8's rule to 80 chars.

It is fascinating to see people having 24+" monitors -- and seeing ca 30 lines of code on their screen, because of the real estate eaten by their IDEs.

To add maiming to injury, these guys write in modern Cobol (a.k.a Java).

Not to mention that they can't print the code -- since it is 150+ chars wide(!) -- and browse it at a cafe. (I love my iPad, but It'll be iPad 3 before it is half as nice for browsing code [edit: as paper].)

I have about 2 full pages of code on the same size of monitor. Of scripting language. I doubt that I have abnormally bad memory or write too complex code... I just like to be productive.

Edit: oK, downvote if you want. But please also add a counter argument for wasting all that screen area?

"Not to mention that they can't print the code -- since it is 150+ chars wide(!) -- and browse it at a cafe."

You can't print code longer than 150 characters wide?

Since when?

Sigh, are you trolling or new? OK, I'll answer.

The point of printing and browsing code is that it is easier and nicer than to read it on a screen (you'll have a portable with you at the cafe anyway to search, annotate, etc.) If you get lots of broken lines, it isn't readable.

Point was, you lose a capability with long lines -- a nice way to go over code. This is important for many of us.

Edit: Point jedsmith, write it off as grumpy-old-man syndrome. Sigh, I just can't get that this isn't understood by everyone, anymore.

You could have made that point without the personal attack.

Broken lines?

We no longer live in the days of typewriters or daisychain printers with fixed column widths.

We now have these wonderful things called laser printers which can print using fonts.

Fonts are resizeable. Even to the point that 150+ columns could be fit on one unbroken line.

And even lines that long can be quite readable if you print in landscape.

Let me first not that printing was a little sub point.

Second, in what you quote from: easier and nicer than to read it on a screen.

So your argument seems to be that it is equally nice to read fewer lines of paper in a smaller font. Huh? Also, my eyes can't handle 4 pages on a page any more -- and your eyes won't be able to do that after 40, either.

I work on a 27" iMac with a 27" second monitor, and a third 19" on a Linux box with Synergy. My primary language is Python, so I do have a place for that shit in the real world.

Reply on news.ycombinator.com