Remove the ++ and –- operators • Hacker News Board

Re: Remove the ++ and –- operators

#21

Post by cballard » Thu, Dec 03, 2015, 9:26 PM UTC

alricb wrote: post #11

jheriko wrote: post #4

post increment/decrement is definately worth removing imo. so few people understand its behaviour and it enables some really revolting and difficult to read things. i think a lot of people learned this in the 80s, 90s and 00s even... its not a new revelation. the pre-increment/decrement though? i think having these is important. there are plenty of contexts away from numbers where they make sense (things can be order…

What about a function named succ or next? They would make things a bit more explicit, and succ has its own tradition.

Those exist, as part of "RandomAccessIndexType", to which "Int" conforms:

1.advancedBy(1) == 2

This is different than ++, though, because ++ mutates the value, and advancedBy(:) returns a new one.

Re: Remove the ++ and –- operators

#22

Post by tostitos1979 » Thu, Dec 03, 2015, 9:26 PM UTC

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.

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

Re: Remove the ++ and –- operators

#23

Post by cballard » Thu, Dec 03, 2015, 9:27 PM UTC

smegel wrote: 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.

Re: Remove the ++ and –- operators

#24

Post by arbitrage » Thu, Dec 03, 2015, 9:28 PM UTC

jheriko wrote: post #4

post increment/decrement is definately worth removing imo. so few people understand its behaviour and it enables some really revolting and difficult to read things. i think a lot of people learned this in the 80s, 90s and 00s even... its not a new revelation. the pre-increment/decrement though? i think having these is important. there are plenty of contexts away from numbers where they make sense (things can be order…

> it enables some really revolting and difficult to read things.

for others, though, it really enables the writing and reading of some very elegant and concise code.

Re: Remove the ++ and –- operators

#25

Post by joshavant » Thu, Dec 03, 2015, 9:28 PM UTC

tostitos1979 wrote: post #22

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.

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

This argument feels like 'legacy for legacy's sake'.

Re: Remove the ++ and –- operators

#26

Post by throwaway999888 » Thu, Dec 03, 2015, 9:28 PM UTC

mwsherman wrote: post #13

Go’s compromise here is that these operators are statements, not expressions. There is no return value. This makes it semantically identical to i += 1. It keeps some sugar while removing some classes of gotcha.

Just having `i += 1` would seem more in line with Go's professed Simplicity philosophy. When both `++i` and `i += 1` mean the same thing, you might as well drop one of them. `++i` (and/or I guess `i++`) is barely syntactic sugar.

Re: Remove the ++ and –- operators

#27

Post by DOUBLESTDRDII » Thu, Dec 03, 2015, 9:29 PM UTC

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!

Re: Remove the ++ and –- operators

#28

Post by JustSomeNobody » Thu, Dec 03, 2015, 9:31 PM UTC

cballard wrote: post #7

Alupis wrote: 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...

Because non-advanced users will incorrectly abuse them. That's why ARC doesn't let you call retain and release manually, even though there's no technical reason it couldn't.

So? Advanced developers abuse languages all the time. This isn't a valid argument.

Re: Remove the ++ and –- operators

#29

Post by syncsynchalt » Thu, Dec 03, 2015, 9:31 PM UTC

Alupis wrote: 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...

Because they can constrain the design of the language, and make it more complex to reason about the language. Look at the language necessary to explain their pitfalls in the C standard, or the extra copy needed in operator++(int) to support post semantics in C++.

They also make the tools that consume that language slightly more complex. It doesn't sound like much, but in aggregate it's the difference between writing a parser for Java vs. a parser for C++.

Re: Remove the ++ and –- operators

#30

Post by mturmon » Thu, Dec 03, 2015, 9:32 PM UTC

dboreham wrote: post #16

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 directive using it. What I'm getting at is that there appears not to have been an assembly language construct for auto-increment on the PDP-7 at all, even though its hardware supported it.

The hardware "auto-indexing" is described at page 3-12 of the PDP-7 architecture document, http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/pdp7/F-... . It is enabled only for about 8 special memory addresses in each 8K of address space, so it is weird and handicapped by comparison with the PDP-11.

See Ritchie's history (http://www.bell-labs.com/usr/dmr/www/chist.html) --

"Thompson went a step further by inventing the ++ and -- operators, which increment or decrement; their prefix or postfix position determines whether the alteration occurs before or after noting the value of the operand. They were not in the earliest versions of B, but appeared along the way. People often guess that they were created to use the auto-increment and auto-decrement address modes provided by the DEC PDP-11 on which C and Unix first became popular. This is historically impossible, since there was no PDP-11 when B was developed.

"The PDP-7, however, did have a few `auto-increment' memory cells, with the property that an indirect memory reference through them incremented the cell. This feature probably suggested such operators to Thompson; the generalization to make them both prefix and postfix was his own. Indeed, the auto-increment cells were not used directly in implementation of the operators, and a stronger motivation for the innovation was probably his observation that the translation of ++x was smaller than that of x=x+1."