Live data from Hacker News

Remove the ++ and –- operators

github.com

211–220 of 249 posts

Re: Remove the ++ and –- operators

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

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.

Re: Remove the ++ and –- operators

#212
post #11
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.

true. although we would call it successor right?

shortening function names with abbreviations ought to have died when fortran relaxed that restriction. XD

Re: Remove the ++ and –- operators

#213
post #154
post #140

Earlier quoted context omitted.

> It's literally no different than having to remember what "+=" does... which is what's being proposed as the alternative. You already have to remember what "+=" does though. If they kept ++ you'd have to learn both.

I don't get the argument... you have to learn what "+" does, so why not remove that and just have "-" since you can subtract negative numbers to add. The line of reasoning that it is more to learn is ridiculous. The concept of incrementing or decrementing a value is trivial. If "++" seriously trips you up as you learn to program, perhaps programming isn't for you... "+=" is no better. If you're going to campaign agai…

>If "++" seriously trips you up as you learn to program, perhaps programming isn't for you...

And by induction you can use this argument to allow any amount of bullshit in a language.

>"+=" is no better.

"+= x" saves you from "= long_variable_name + x" which is arguably less readable.

"++" saves you from ... "+= 1" which is already entirely clear, and I have no idea why anyone feels the need to shorten it.

Sure it's a relatively small complexity cost, but it's also an even more microscopic advantage.

Re: Remove the ++ and –- operators

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

I presume you're using C as the example language?

Most modern languages have an append-to-list method/function, so your example isn't really applicable in those langauges. For example, ArrayList#add() for Java or Vec::push[1] for Rust, etc. (Yes, these are technically dynamically sized arrays, but you can always reserve the necessary amount of space up front if you so desire.)

[1] https://doc.rust-lang.org/std/vec/struct.Vec.html#method.pus...

Re: Remove the ++ and –- operators

#215
post #208

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.

My point was that it's a poor reason for removing it from a language.

Believe it or not the concept of

x = 5

is harder to understand.

They know that = means equality, because of algebra. I have to retrain prior knowledge, and since humans rely on prior knowledge to learn new things quickly, it's more difficult.

Having to explain == or .eq or, god forbid, === takes way more time to explain than:

"x = 0". x++ adds 1 to x. So when you need to increment by one, you can do x = x + 1, or you can do x++ which is a shorter way."

Boom. Done.

Not exactly a good reason for taking it out of a programming language. That's all I was saying.

Do I care that Swift has it or not? Nope. But I just thought this particular reason was silly.

Re: Remove the ++ and –- operators

#216
post #154
post #140

Earlier quoted context omitted.

> It's literally no different than having to remember what "+=" does... which is what's being proposed as the alternative. You already have to remember what "+=" does though. If they kept ++ you'd have to learn both.

I don't get the argument... you have to learn what "+" does, so why not remove that and just have "-" since you can subtract negative numbers to add. The line of reasoning that it is more to learn is ridiculous. The concept of incrementing or decrementing a value is trivial. If "++" seriously trips you up as you learn to program, perhaps programming isn't for you... "+=" is no better. If you're going to campaign agai…

> you have to learn what "+" does, so why not remove that and just have "-" since you can subtract negative numbers to add.

Because "-" is part of the domain language (mathematics).

> The concept of incrementing or decrementing a value is trivial.

For a normal function (i.e. something that could be implemented as library functionality) then I agree with you. But for a language-level operator, it's a special case. It probably has its own precedence. It definitely complicates the metamodel.

> If you're going to campaign against "++", might as well go all the way back to BASIC days and only allow "x = x + 1"

I would. How many times do you need to add 1 to something anyway?

Re: Remove the ++ and –- operators

#217

Removing ++ et al: ok, they have their problems. But retaining x += 1? That one has always annoyed me. Why does '+' (and friends) get this special form, but not my functions? Just because they're built-in. They are useful; no argument there. Largely because 'x' can be a complex reference, and you don't have to type it twice (and the compiler doesn't have to figure out that its the same expression twice). E.g. x=x+1 i…

>But retaining x += 1? That one has always annoyed me. Why does '+' (and friends) get this special form, but not my functions? The reason is that I don't want to see you escape your strings by writing input escapequotes= input That's why. come on. who wants to read that?

But it would be

   input +'= input
and the reverse

   input -'= input
or, alternatively,

   input \'= input
and

   input !'= input
If you code does this often enough, that may even be useful (but also, your code would be bad)

Re: Remove the ++ and –- operators

#218
post #49

Earlier quoted context omitted.

Have you never heard the rule that your code should have no numbers in it except 0 and 1? All other numbers should be written as constants instead, and then use the name of the constant instead of the number directly. > Anointing "+ 1" as a thing that needs special syntax is weird. 1 is special.

Yes, of course, I use constants in all cases. Why is adding 1 to something special, compared to adding 2 to something? The #1 use case, by far, is C-style for loops, which aren't used in idiomatic Swift code.

I said why: The 2 should be a constant as a name, but the 1 can be a bare 1.

Re: Remove the ++ and –- operators

#219

We don't have `++` and `--` in Rust either, and I really don't mind. The amount of times I've went to do a `++` where a `+= 1` was clutter has been perhaps one or two times. Then again, my most common use for `++` was `for (;;) {}` index, and we have better in these new languages like Rust and Swift. There are millions of people in this world trying to learn to code and understand the layers upon layers of cruft and…

Oh, I've just closed a Haskell window, saw the title and thought "how would I concatenate strings?", but I'm digressing... But no, not only for for(;;). There's also the too common array traversal: while(something) a[x] = b[x++]; And lots and lots of ugly but useful uses in pointer arithmetics where they make things clear. They have no place in any other language, but I'd really miss both operators in C.

> while(something) a[x] = b[x++];

Wait, isn't this an undefined behavior? Is the order of evaluations of `x` in the left side and `x++` in the right side defined? I'm always confused at things like this!

Re: Remove the ++ and –- operators

#220

Earlier quoted context omitted.

Question of clarification: is this the same concept as Python's __iadd__? I was not aware that this was a "thing" in programming language design. http://stackoverflow.com/questions/1047021/overriding-in-pyt...

Looking at eliteraspberrie's example, not really. Python's __iadd__ and such are not able to reassign. There is no "inout" in Python. The assignment aspect of __iadd__ is done through self mutation (and an extra hard-coded assignment to support immutable variables).

The assignment aspect of __iadd__ is done like any other assignment in python. The one to one equivalent of eliteraspberrie's would be:

  class Vector2D:
      def __iadd__(self, other)
          return self + other
No "self mutation" as you suggest. a += b is equivalent to a = a.__iadd__(b)
Post reply on HN