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

171–180 of 249 posts

Re: Remove the ++ and –- operators

#171

Post by AnimalMuppet »

dragonwriter wrote: post #120
AnimalMuppet wrote: post #119

Earlier quoted context omitted.

But the point is that with ++, I don't have to look at all at the increment - I know what it is. The issue isn't how far away I have to look, it's that I have to look at all . (Or I don't look, and just assume that it's an add-one because that's what it always is, and then wonder why my loop doesn't work right.)

> the point is that with ++, I don't have to look at all at the increment Of course you do, otherwise you wouldn't know it was an increment in the first place.

Well, all right, my brain has to parse one fewer symbols. ++ is the equivalent of parsing +=, but there's no "1" or "j" or anything else that I have to parse in addition.

(No pun intended, but I also didn't edit it out...)

Re: Remove the ++ and –- operators

#172

Post by jonhohle »

ridiculous_fish wrote: post #153
JoeAltmaier wrote: post #46

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…

In Swift, += is a separate operator from +, and is defined within the confines of the language. It's not privileged in any particular way: func +=(inout lhs: Int, rhs: Int) and you can just implement this. You might object that special forms are still privileged, e.g. foo[idx]+=1. But in fact these are not special: one of the surprising features of Swift is that inouts work on computed properties. For example, say we…

Isn't this how C++ works as well? operator+= is definable for any user defined types and typically you'll add an overloaded operator[] which returns a reference so that things like operator+= works as you'd expect within the context of a collection.

I have some old code somewhere for images which I'm sure does something to the effect of:

    image[x, y] *= scale;
where Image::operator[] returns a Pixel&.

Re: Remove the ++ and –- operators

#173

Post by Veedrac »

dbpokorny wrote: post #150
eliteraspberrie wrote: post #133

Earlier quoted context omitted.

Do you mean something like "compound assignment operators"? Apparently you can define custom operators like: func += (inout left: Vector2D, right: Vector2D) { left = left + right } https://developer.apple.com/library/ios/documentation/Swift/...

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

Re: Remove the ++ and –- operators

#174

Post by koko775 »

nix0n wrote: post #137
SilasX wrote: post #105

Earlier quoted context omitted.

Then I take it you don't buy into the Python philosophy of "There should be one-- and preferably only one --obvious way to do it." https://www.python.org/dev/peps/pep-0020/

To me, ++ is the one obvious way to increment. I use for loops constantly and think of incrementation as a different thing from addition.

To be clear, do you mean ++i or i++?

Re: Remove the ++ and –- operators

#175

Post by SilasX »

nix0n wrote: post #137
SilasX wrote: post #105

Earlier quoted context omitted.

Then I take it you don't buy into the Python philosophy of "There should be one-- and preferably only one --obvious way to do it." https://www.python.org/dev/peps/pep-0020/

To me, ++ is the one obvious way to increment. I use for loops constantly and think of incrementation as a different thing from addition.

Well yes, they are different from addition, but that still doesn't justify a special symbol for a special case of addition.

When your "increment by 1" is really just in the service of iterating over a set, then the natural, obvious way should be to use a separate idiom that abstracts the concept of iteration over that set, rather than dive into the details of how you get access to the next member. Which is what Python does: "for x in ...".

If the loop is not simply iterating over the set, but tweaking some value unpredictably and periodically checking, then there's nothing special about += 1 relative to += 2.

Re: Remove the ++ and –- operators

#176

Post by Nadya »

throwaway999888 wrote: post #43
AnimalMuppet wrote: post #34

Earlier quoted context omitted.

i++ is different from i += 1 in this way: += could be i += 2 or i += j or something else. I have to pay attention to be sure. But i++ can only add one.

Yes, you actually have to read the statement `i += 1` in order to know what it does. I don't see how that is an argument. It's barely longer than `i++`, in any case. I could buy the argument if we were dealing with indexes or numbers where you had to read/hunt down occurrences of them to make sure they are what you expect. Like: make sure that a loop with a lot of indexes don't overincrement (out of bounds) or does s…

>Yes, you actually have to read the statement `i += 1` in order to know what it does.

Beginner here. Small detail...

`i++` is read as `i = i + 1` and not `i += 1`. A small, but important distinction, especially for a beginner. `i += 1` is also parsed as `i = i + 1`.

However for `i += n` it no longer parses as `i = i + 1` but rather `i = i + n` which is a step more difficult (and more powerful) than i++ which is always `i = i + 1`. However that is additional complexity not found in `i++`.

(This is why I found `i++` easier than `i += 1`)

Re: Remove the ++ and –- operators

#177

Post by kuschku »

Nadya wrote: post #168
kuschku wrote: post #131

Earlier quoted context omitted.

I use a bastardized DE1 layout, as provided by linux. So I have æ, but not å. Actually, I’m gonna switch to DE3. Still doesn’t solve these special characters.

I guessed the German QWERTZ properly at least...unfortunately I don't know a way of solving that without having an EN keyboard, using a keybind to swap between T1/EN as needed. Though depending how much German shows up in your programming... swapping every few characters probably isn't desirable either. :(

I write literally no German in code, but sometimes use it online.

And I seriously couldn’t work without the international layout - using proper Unicode characters in my comments is just non-negotiable.

If developers would have thought more about localization, and made less dumb assumptions...

But there are even minecraft mods that don’t work on QWERTZ, because they are hardcoded to keys that are dead keys on DE layout.

Re: Remove the ++ and –- operators

#178

Post by jhallenworld »

The postfix versions of ++ and -- have no simple analogue. I propose fixing this: z = (a += 1) means z gets the new value of a, but z = (a +: 1) means z gets old value a, same as in z = a++.

Likewise, z = (a : 5), means that z gets old value of a, then a gets 5.

This makes for a nice family of operators. For example, to swap the contents of two variables you can say: a:b:a (or a=b:a). Also you can rotate through a bunch of variables: a:b:c:d:a transfers all the contents to the left, and puts the old value of a into d.

The . operator should have an assignment form as well, so that you can say: p .= next instead of p = p.next

Now you can traverse linked lists very concisely: for (p = first; p; p .= next) serialize(p);

Of course .: will have the expected meaning: return old value of left side, then replace it with one of its members. So you can say:

   while (p) serialize(p.:next)

Re: Remove the ++ and –- operators

#179

Post by msellout »

nix0n wrote: post #137
SilasX wrote: post #105

Earlier quoted context omitted.

Then I take it you don't buy into the Python philosophy of "There should be one-- and preferably only one --obvious way to do it." https://www.python.org/dev/peps/pep-0020/

To me, ++ is the one obvious way to increment. I use for loops constantly and think of incrementation as a different thing from addition.

Why are you incrementing inside a Python for-loop? Are you familiar with ``enumerate``? In most situations, Python provides an iterator that tracks state for you and it's not necessary to increment state explicitly in the loop.

Re: Remove the ++ and –- operators

#180

Post by Nadya »

kuschku wrote: post #177
Nadya wrote: post #168

Earlier quoted context omitted.

I guessed the German QWERTZ properly at least...unfortunately I don't know a way of solving that without having an EN keyboard, using a keybind to swap between T1/EN as needed. Though depending how much German shows up in your programming... swapping every few characters probably isn't desirable either. :(

I write literally no German in code, but sometimes use it online. And I seriously couldn’t work without the international layout - using proper Unicode characters in my comments is just non-negotiable. If developers would have thought more about localization, and made less dumb assumptions... But there are even minecraft mods that don’t work on QWERTZ, because they are hardcoded to keys that are dead keys on DE layou…

I press alt+shift and can switch between EN-International (which allows easy typing of é, è, ç, etc.) and EN-US (which doesn't easily allow them to be typed).

Therefore in EN I can {code} and then alt+shift and {comment with proper Unicode characters}. My suggestion would be to have a setup of T1/EN. Code in EN and comment in T1.

Sorry if I'm not being clear or if I'm being confusing...

>If developers would have thought more about localization, and made less dumb assumptions...

I18N can be time-consuming. Especially to test on every conceivable keyboard layout. Dumb assumption allows the mod to exist. I'm all in favor of I18N (and help translate things when I can!) but honestly it is a lot more work for what is often very little gains.

Would you rather spend 10 hours adding I18N for 100~ players or spend 10 hours improving the rest of the code base and adding new features for 10,000 players? Most devs choose the latter. Which really sucks if you're in the group of 100~ players.

Post reply on HN