Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Remove the ++ and –- operators

github.com

Post reply on HN
Print view View original

201–210 of 249 posts

Re: Remove the ++ and –- operators

#201

Post by rtpg »

vlunkr wrote: post #129
manaskarekar wrote: post #2

> Their expressive advantage is minimal - x++ is not much shorter than x += 1 Personal opinion, but I definitely miss '++' every time I'm doing '+=' in Python.

I've always felt like Python and Ruby chose to drop these to discourage you from writing traditional loops, as they have their own enumerators to accomplish the same thing. And, as the author mentioned, so does Swift. Obviously you still have to do a '+=' occasionally, but I don't find myself doing that often.

Yeah, I think the core difference between i++ and i+=1 (expression vs statemrnt) is mainly useful in situations where higher level structures are available in languages that aren't C

Re: Remove the ++ and –- operators

#202

Post by [deleted] »

dstanko wrote: post #161
cballard wrote: post #58

Earlier quoted context omitted.

Apple has a long history of readability over terseness. "plus plus" doesn't mean anything. It might even be confusing that it doesn't add 2 .

From Swift documentation: for i in 0.. This ..< operator is so much more logical, of course! Not to mention == and ===. Logically, the first one compares twice and the second compares three times (for luck), just in case first two comparisons didn't go through...

[deleted]

Re: Remove the ++ and –- operators

#203

Post by cballard »

dstanko wrote: post #161
cballard wrote: post #58

Earlier quoted context omitted.

Apple has a long history of readability over terseness. "plus plus" doesn't mean anything. It might even be confusing that it doesn't add 2 .

From Swift documentation: for i in 0.. This ..< operator is so much more logical, of course! Not to mention == and ===. Logically, the first one compares twice and the second compares three times (for luck), just in case first two comparisons didn't go through...

I would implement that like:

    zip(names, 1...names.count).forEach { name, index in
        print("Person \(index) is called \(name)")
    }
Or, in an ideal world:

    zip(names, 1...names.count)
        .map({ name, index in "Person \(index) is called \(name)" })
        .forEach(print)
Currently, that isn't valid Swift, "print" can't be used like that, though if you define a closure it works:

    let printIt = { x in print(x) }
    
    zip(names, 1...names.count)
        .map({ name, index in "Person \(index) is called \(name)" })
        .forEach(printIt)
I think that Swift could use = for equality, since assignments return Void and comparison returns Bool. Maybe it should.

But your argument boils down to "if you can't be clear everywhere, don't be clear anywhere". That's not a good goal.

Re: Remove the ++ and –- operators

#204

Post by mattst88 »

Retra wrote: post #193
rocky1138 wrote: post #6

I've never understood the obsession with avoiding ++ and --. Douglas Crockford advocates the same thing. All of the examples of why it's bad are contrived and set up to fail. In the majority of real world instances, it's just us incrementing or decrementing a single variable.

All the examples where they're useful are contrived. And simplicity is an actual goal of computer language design.

That's quite a claim. I agree that most uses of these operators as an expression are not wise. Some are though. As a counter-claim, I offer:

  array[i++] = this;
  array[i++] = that;
  array[i++] = the_other;
which also extends nicely when some of those elements are optional.

Re: Remove the ++ and –- operators

#205

Post by mattst88 »

spc476 wrote: post #123
cballard wrote: post #23

Earlier quoted context omitted.

Yes. Anointing "+ 1" as a thing that needs special syntax is weird .

Not necessarily so if you come from a strong Assembly language background. Most processors have a special instruction for incrementing a register that's shorter (and faster) than the more generic ADD instruction. For instance, on a 64-bit x86 machine, ADD RAX,1 is nine bytes long, while INC RAX is one byte. Maybe not as much a win these days, but back when memory was smaller and more expensive, it was worth it.

Compiling

  #include 
  uint64_t inc(uint64_t x) { return x + 1; }
With -O0 gives me:

  48 83 c0 01          	add    $0x1,%rax
and with -O2:

  48 8d 47 01          	lea    0x1(%rdi),%rax
That is, both are four bytes.

Re: Remove the ++ and –- operators

#207

Post by SamReidHughes »

mattst88 wrote: post #204
Retra wrote: post #193

Earlier quoted context omitted.

All the examples where they're useful are contrived. And simplicity is an actual goal of computer language design.

That's quite a claim. I agree that most uses of these operators as an expression are not wise. Some are though. As a counter-claim, I offer: array[i++] = this; array[i++] = that; array[i++] = the_other; which also extends nicely when some of those elements are optional.

For what it's worth, you could always make a function postincr and write

    array[postincr(&i)] = ...;
if you're doing enough of those that it's worth it.

Re: Remove the ++ and –- operators

#208

Post by mayoff »

bphogan wrote: post #206

One of the reasons they state is that ++ makes it harder for beginners. I just taught ++ and -- to 1st semester students last week. There were no problems.

Time that could have been spent teaching them something else useful, if your language didn't have ++ and --. Even if all features of your language are easy, teaching/learning each feature takes time.

Re: Remove the ++ and –- operators

#209

Post by mturmon »

dboreham wrote: post #130
mturmon wrote: post #30

Earlier quoted context omitted.

People suppose this, but that's not quite how it happened. C came from B, and B had ++ also. But B came before the PDP-11. The PDP-7 had hardware that supported auto-increment-by-one, and Ritchie suggests that's where ++ came from. The PDP-7 assembler manual is at http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/pdp7/PD... , but I can't see any reference to this auto-increment hardware, or to an assembler directi…

Very interesting. I have supposed this since using PDP-11 assembler and reading Dennis' compiler in the late 70's. There were machines with auto increment modes long before the PDP-11 though, e.g. " http://ed-thelen.org/comp-hist/GE-635.html#Indirect Then Tally (IT) Modification"

I hear you. I learned assembler on the PDP-11 -- a delightful memory -- and had the same misconception until I read Ritchie's piece.
Post reply on HN