3 ms·

post increment/decrement is definately worth removing imo. so few people understand its behaviour and it enables some really revolting and difficult to read th

by jheriko 11y ago

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 ordered and not have a concept of addition)

arbitrage 11y ago
> 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.
- jheriko 11y ago
  usually when people say this what they mean is revolting and difficult to read things. (i'm not 100% sure this means you, but all of my experience tells me this is likely the case, sorry to have to be critical) i've heard this sort of thing about *a++ = *b++; and variants thereof, which is the classic example of this. a lot of the times i have seen this stuff it is in the middle of even more revolting code too... like some 1000 line function (which could be 10 functions and has comments inside of it that delineate the obvious splits) with a gigantic switch statement (which could be a class, or in C a function pointer), containing loops, where there are 20 lines like the above but even more difficult to read in a row (which could have been a nested loop with identical logic referring to some constant data) - to think of the most recent example i faced. sadly i've seen this sort of stuff so many times for so long that i find it easy to read, but it is intrinsically difficult involving precedence and the post-increment gotcha, and it gets worse if there is even more being done than just a straight copy.
alricb 11y ago
What about a function named succ or next? They would make things a bit more explicit, and succ has its own tradition.
- cballard 11y ago
  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.
- jheriko 11y ago
  true. although we would call it successor right? shortening function names with abbreviations ought to have died when fortran relaxed that restriction. XD

by jheriko 11y ago

arbitrage 11y ago

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

jheriko 11y ago
usually when people say this what they mean is revolting and difficult to read things. (i'm not 100% sure this means you, but all of my experience tells me this is likely the case, sorry to have to be critical) i've heard this sort of thing about *a++ = *b++; and variants thereof, which is the classic example of this. a lot of the times i have seen this stuff it is in the middle of even more revolting code too... like some 1000 line function (which could be 10 functions and has comments inside of it that delineate the obvious splits) with a gigantic switch statement (which could be a class, or in C a function pointer), containing loops, where there are 20 lines like the above but even more difficult to read in a row (which could have been a nested loop with identical logic referring to some constant data) - to think of the most recent example i faced. sadly i've seen this sort of stuff so many times for so long that i find it easy to read, but it is intrinsically difficult involving precedence and the post-increment gotcha, and it gets worse if there is even more being done than just a straight copy.

alricb 11y ago

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

cballard 11y ago
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.
jheriko 11y ago
true. although we would call it successor right? shortening function names with abbreviations ought to have died when fortran relaxed that restriction. XD