4 ms·

> If you cannot understand ++x vs x++ then you fundamentally do not understand the language I hardly think this is the issue. The problem is this kind of thing

> If you cannot understand ++x vs x++ then you fundamentally do not understand the language I hardly think this is the issue. The problem is this kind of thing becomes so easy to write but not consciously notice that it causes disproportionately costly mistakes, and I don't think the benefit is worth it. Python and other languages don't have the increment operator (pre or postfix), but never has this been a problem for productivity in any of my teams. On the contrary, I've encountered several instances where a senior engineer with 20+ years in the industry can't for the life of them figure out why some particular value is off-by-one. It wastes hours of time and often takes a fresh set of eyes to figure it out. I know a senior principal engineer who wasted an entire day of his time because a comma at the end of the line turned his Python scalar into a unary tuple and was incredibly difficult to notice. "5," is semantically equivalent to "(5,)" but Python isn't strict enough in this instance. It should be strict, though, not for stupifying but for protecting against errors that we all make.

Alupis 4y ago
Perhaps the problem isn't really the increment operator, but rather folks writing too fancy of code while using it. One should probably not deeply nest things like increments... because they do get difficult to read. That's not an increment operator problem though, that's an engineer problem. The example with Python doesn't apply here. We cannot just go around removing language features because sometimes people write bad code. Further, if you read the code and walk through it in your head, finding a mistaken tuple someplace unexpected should have been easy to find... which means your senior principal engineer isn't very good at reading code, even if they are very good at writing code. Reading code is it's own skillset I've found... that and apparently the debug steppers for python aren't very good either...
- Sohcahtoa82 4y ago
  > Perhaps the problem isn't really the increment operator, but rather folks writing too fancy of code while using it I find this is a common theme of many complaints of C++ and OOP. For example, C++ lets you do some incredibly ugly things using operator overloading. This can be useful so you could, say, make a matrix class and allow matrix operations to just using + or * rather than .add and .multiply functions. The fact that it can be abused to do very non-sensical, unintuitive things should be a criticism of the programmer who does it, not the feature.
5d8767c68926 4y ago
>... a comma at the end of the line turned his Python scalar into a unary tuple I have been burned by this mistake a handful of times. Each instance managed to eat up a shocking amount of time. I definitely consider it a misfeature.
- Sohcahtoa82 4y ago
  I'm trying to figure out how you ended up with a stray comma at the end of a line. A simple typo, bumping the key without noticing?
  - Alupis 4y ago
    My guess would be a bad auto-complete suggestion that wasn't read carefully before accepting. Loose-type languages often struggle with auto-complete and related. I don't know enough about current state of python development to say with certainty, however.
  - 5d8767c68926 4y ago
    Cannot offer any justification for the error. Just that I have done it more than once, and each time it has taken me too long to debug the underlying cause.

Alupis 4y ago

Perhaps the problem isn't really the increment operator, but rather folks writing too fancy of code while using it. One should probably not deeply nest things like increments... because they do get difficult to read. That's not an increment operator problem though, that's an engineer problem. The example with Python doesn't apply here. We cannot just go around removing language features because sometimes people write bad code. Further, if you read the code and walk through it in your head, finding a mistaken tuple someplace unexpected should have been easy to find... which means your senior principal engineer isn't very good at reading code, even if they are very good at writing code. Reading code is it's own skillset I've found... that and apparently the debug steppers for python aren't very good either...

Sohcahtoa82 4y ago
> Perhaps the problem isn't really the increment operator, but rather folks writing too fancy of code while using it I find this is a common theme of many complaints of C++ and OOP. For example, C++ lets you do some incredibly ugly things using operator overloading. This can be useful so you could, say, make a matrix class and allow matrix operations to just using + or * rather than .add and .multiply functions. The fact that it can be abused to do very non-sensical, unintuitive things should be a criticism of the programmer who does it, not the feature.

5d8767c68926 4y ago

>... a comma at the end of the line turned his Python scalar into a unary tuple I have been burned by this mistake a handful of times. Each instance managed to eat up a shocking amount of time. I definitely consider it a misfeature.

Sohcahtoa82 4y ago
I'm trying to figure out how you ended up with a stray comma at the end of a line. A simple typo, bumping the key without noticing?
- Alupis 4y ago
  My guess would be a bad auto-complete suggestion that wasn't read carefully before accepting. Loose-type languages often struggle with auto-complete and related. I don't know enough about current state of python development to say with certainty, however.
- 5d8767c68926 4y ago
  Cannot offer any justification for the error. Just that I have done it more than once, and each time it has taken me too long to debug the underlying cause.