Live data from Hacker News

Remove the ++ and –- operators

github.com

121–130 of 249 posts

Re: Remove the ++ and –- operators

#121

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

Agreed. In the list of disadvantages, we don't see "many professional programmers expect the ++ and -- operator" or "beginners will be confused because old code examples on the web will stop working".

Which wipes out the "easier to learn as a first language" point, and then some. Copy-pasting code from stack or somesuch only to have it not work and not know why is incredibly frustrating for a beginning programmer. I certainly found that with wpgtr back in the day.

Re: Remove the ++ and –- operators

#123
post #18

> Their expressive advantage is minimal - x++ is not much shorter than x += 1. And there is no ++ equivalent of x += 2.

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.

Re: Remove the ++ and –- operators

#124
post #78
post #69

Earlier quoted context omitted.

++ is a rare situation since the introduction of foreach. For example in the JVM checking for null would deserve an operator.

OMG, yes! maybeNull?.getContent()?.toString() This would improve my coding sooo much. Currently I use Optional.fromNullable(maybeNull).orElse(new DummyObjectThatReturnsNullOnAllMethodCalls).getContent(), and then repeat the process.

I use "?" constantly in coffee-script. And while I missed ++ for a while in Python, I don't use it in coffee even though it's available.

Re: Remove the ++ and –- operators

#125

Earlier quoted context omitted.

Well, the same argument can be made for pointers, which are clearly harmful to a safe language. Swift does include them, but puts a screaming "Unsafe" in front of their type names so that it's clear that unless you really know what you're doing, you're probably doing something wrong. There's no way to do that with a ++ operator, so it's being removed.

Do really think the complexity of pre/post-in/decrement is on the same level as pointers?

[deleted]

Re: Remove the ++ and –- operators

#126
post #15

Earlier quoted context omitted.

> Because non-advanced users will incorrectly abuse them. I don't see how this is a valid reason to remove the operators completely. Beginners will get it wrong sometimes, so we should remove it? Beginning users are likely to make all kinds of errors, so the implication would be maybe we should remove the entire language...? Not to mention, pre-decrement and post-decrement are not complicated concepts. There are many…

Well, the same argument can be made for pointers, which are clearly harmful to a safe language. Swift does include them, but puts a screaming "Unsafe" in front of their type names so that it's clear that unless you really know what you're doing, you're probably doing something wrong. There's no way to do that with a ++ operator, so it's being removed.

I didn't know we were making comparisons between Swift and C.

Most people would agree C lets the developer do a lot of terrible things (by design, since some of those terrible things are necessary for low level stuff, which C was targeted at).

Pointers are confusing for a lot of people. Which is why almost no modern language uses them. Comparing "++" with C pointers is not a valid argument.

Even so, I would never argue to remove pointers from C, since you can optionally not use them. If you don't need that language construct in your program, don't use it. But leave it for others who do want/need it.

Re: Remove the ++ and –- operators

#127

VOTES-- MORE SERIOUSLY....CODING CAN BE ABOUT AESTHETICS. YES, JUST BECAUSE. CODE CAN LOOK GOOD AND THAT IS A VALUE. BUT ALSO, AESTHETICS CAN HAVE A NON-MEANINGLESS AFFECT ON COMPREHENSION, READABILITY, CODING-PLEASURE AND PRODUCTIVITY. SO MONEY, BASICALLY. PERSONALLY, I LOVE THE ++ AND -- AESTHETIC. IT'S JUST A COOL GLYPH/DIGRAM/IDIOM. BRING BACK THE QUIRKINESS ( OKAY, NOT TO THE PERL-LEVEL ) BUT BRING IT BACK!

Judging by your capitalization, you must be of the BASIC school of aesthetics...?

It could be FORTH.

Re: Remove the ++ and –- operators

#128
post #35
post #5

Why not leave those operators for more "advanced" users? I also contest "++" and "--" operators are seriously tripping up "beginners". In most programming books, it's taught a few chapters in...

Reading is more important than writing. If you leave them in they're one more special case that everyone has to memorize before they can maintain someone else's code.

> If you leave them in they're one more special case that everyone has to memorize before they can maintain someone else's code

It's literally no different than having to remember what "+=" does... which is what's being proposed as the alternative.

> Reading is more important than writing

I would agree, but "x++" is not difficult to read. It's more concise than having to read "x += 1". Or worse, beginners will think it's clever to define constants for this so now you'll get "x += INCREMENT_VALUE", making you have to go lookup whatever "INCREMENT_VALUE" is, etc...

Re: Remove the ++ and –- operators

#129

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

Re: Remove the ++ and –- operators

#130
post #30

Good. I've always presumed ++ is in C because processors had an increment instruction that was faster than add back then, and for the PDP-11's autoincrement addressing mode. Presumably Dennis' compiler would have been that much bigger in order to spot these optimizations vs having the programmer explicitly invoke them -- perhaps big enough to no longer fit in memory.

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"

Post reply on HN