5 ms·

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

tostitos1979 11y ago
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".
- joshavant 11y ago
  This argument feels like 'legacy for legacy's sake'.
  - gozo 11y ago
    Frankly I think discussions like these show how not all programmers are engineers. Cutting down on complexity and ambiguity is a good thing. Because even if you can handle something, when you have teams of 100+ people with 100 000+ lines of codes, all those potentials for errors quickly adds up.
  - legulere 11y ago
    Which is actually quite common. Unicode is ASCII compatible and on Windows you still have to do carriage return before a line feed, although there are no teleprinters involved.
- redthrowaway 11y ago
  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.
delinka 11y ago
I think I'd argue with the "not much shorter" because it's less typing to perform a `++` versus `+=1`; I hold shift, I type the = key, obtaining the +, then I have to pause typing long enough to release the shift key, type the = key again, and now my other hand has to get involved and type a 1. And that's without the spaces.
- redblacktree 11y ago
  Typing is not the bottleneck.
  - delinka 11y ago
    Yes, typing is indeed the bottleneck. Perhaps it doesn't add up to much time overall, but until we get brain-computer interfaces and the ability to will code or instructions into existence, I want every barrier to moving the solution from my head into the computer as small as possible. I had a very similar conversation with a colleague about UX. This one operation might not happen often, but when it does, it should be intuitive and fast. The technology is here to serve the humans.
    - redblacktree 11y ago
      My point is just that a programmer spends a lot more time thinking about the problem domain; how to approach a particular problem; what patterns he might use; and details about the particular solution they've chosen, than he does typing. That is, if you're optimizing typing, you're optimizing the wrong thing, and if you want to improve your ability to write software, you should instead be getting better at these other things. The typing part is good enough. Edit: Or if typing really is the bottleneck, you're a much better programmer than me.
- kuschku 11y ago
  Well, I type the * key to get a +, then shift and 0 to get a =, then 1 to get a 1. Slow, and my fingers have to jump completely over the keyboard. What is far more annoying, and should be banned, are `these` (I have to press shift+' twice to get one `, otherwise I end up with á' instead of `a`), and {}[], as they are on AltGr+7/8/9/0
isomorphic 11y ago
I think forcing me to use "+=" in Ruby reminds me that it's really a method call (which can be overridden), rather than an increment operation on primitive types.
- odonnellryan 11y ago
  Yes, this exactly! While rarely a good idea, it does give you super powers when dealing with specialized libraries, or when writing your own :)
  - paulddraper 11y ago
    Have you ever written a container (with an iterator)?
- akira2501 11y ago
  And yet, ruby still provides 4 unary operators that can be redefined.
- BingsF 11y ago
  ++ and -- (both versions of each) would end up being method calls as well in Ruby or Python. They're even overridable in C++.
amyjess 11y ago
I do too, but it's worth it to not have x++ and ++x thrown around inside of expression bodies (especially while loop conditions).
SilasX 11y ago
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/ https://www.python.org/dev/peps/pep-0020/
- nix0n 11y ago
  To me, ++ is the one obvious way to increment. I use for loops constantly and think of incrementation as a different thing from addition.
  - koko775 11y ago
    To be clear, do you mean ++i or i++?
  - SilasX 11y ago
    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.
  - msellout 11y ago
    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.
  - nine_k 11y ago
    In higher level languages, loops are not about incrementing.
- Grue3 11y ago
  Neither does Python. For example, % operator and .format().
joaorj 11y ago
I did miss it too, for the first 2 weeks I started using python. After that it just seems ugly.
vlunkr 11y ago
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.
- rtpg 11y ago
  Yeah, I think the core difference between i++ and i+=1 (expression vs statemrnt) is mainly useful in situations where higher level structures are available in languages that aren't C

tostitos1979 11y ago

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

joshavant 11y ago
This argument feels like 'legacy for legacy's sake'.
- gozo 11y ago
  Frankly I think discussions like these show how not all programmers are engineers. Cutting down on complexity and ambiguity is a good thing. Because even if you can handle something, when you have teams of 100+ people with 100 000+ lines of codes, all those potentials for errors quickly adds up.
- legulere 11y ago
  Which is actually quite common. Unicode is ASCII compatible and on Windows you still have to do carriage return before a line feed, although there are no teleprinters involved.
redthrowaway 11y ago
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.

delinka 11y ago

I think I'd argue with the "not much shorter" because it's less typing to perform a `++` versus `+=1`; I hold shift, I type the = key, obtaining the +, then I have to pause typing long enough to release the shift key, type the = key again, and now my other hand has to get involved and type a 1. And that's without the spaces.

redblacktree 11y ago
Typing is not the bottleneck.
- delinka 11y ago
  Yes, typing is indeed the bottleneck. Perhaps it doesn't add up to much time overall, but until we get brain-computer interfaces and the ability to will code or instructions into existence, I want every barrier to moving the solution from my head into the computer as small as possible. I had a very similar conversation with a colleague about UX. This one operation might not happen often, but when it does, it should be intuitive and fast. The technology is here to serve the humans.
  - redblacktree 11y ago
    My point is just that a programmer spends a lot more time thinking about the problem domain; how to approach a particular problem; what patterns he might use; and details about the particular solution they've chosen, than he does typing. That is, if you're optimizing typing, you're optimizing the wrong thing, and if you want to improve your ability to write software, you should instead be getting better at these other things. The typing part is good enough. Edit: Or if typing really is the bottleneck, you're a much better programmer than me.
kuschku 11y ago
Well, I type the * key to get a +, then shift and 0 to get a =, then 1 to get a 1. Slow, and my fingers have to jump completely over the keyboard. What is far more annoying, and should be banned, are `these` (I have to press shift+' twice to get one `, otherwise I end up with á' instead of `a`), and {}[], as they are on AltGr+7/8/9/0

isomorphic 11y ago

I think forcing me to use "+=" in Ruby reminds me that it's really a method call (which can be overridden), rather than an increment operation on primitive types.

odonnellryan 11y ago
Yes, this exactly! While rarely a good idea, it does give you super powers when dealing with specialized libraries, or when writing your own :)
- paulddraper 11y ago
  Have you ever written a container (with an iterator)?
akira2501 11y ago
And yet, ruby still provides 4 unary operators that can be redefined.
BingsF 11y ago
++ and -- (both versions of each) would end up being method calls as well in Ruby or Python. They're even overridable in C++.

amyjess 11y ago

I do too, but it's worth it to not have x++ and ++x thrown around inside of expression bodies (especially while loop conditions).

SilasX 11y ago

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/ https://www.python.org/dev/peps/pep-0020/

nix0n 11y ago
To me, ++ is the one obvious way to increment. I use for loops constantly and think of incrementation as a different thing from addition.
- koko775 11y ago
  To be clear, do you mean ++i or i++?
- SilasX 11y ago
  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.
- msellout 11y ago
  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.
- nine_k 11y ago
  In higher level languages, loops are not about incrementing.
Grue3 11y ago
Neither does Python. For example, % operator and .format().

joaorj 11y ago

I did miss it too, for the first 2 weeks I started using python. After that it just seems ugly.

vlunkr 11y ago

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.

rtpg 11y ago
Yeah, I think the core difference between i++ and i+=1 (expression vs statemrnt) is mainly useful in situations where higher level structures are available in languages that aren't C