4 ms·

This doesn't have anything to do with the value behaviour of =. The statement in question was intended to be a simple assignment, throwing away the value of th

by caf 10y ago

This doesn't have anything to do with the value behaviour of =. The statement in question was intended to be a simple assignment, throwing away the value of the = operator and only using its side-effect. Instead an equality operator was used, which produced no side-effect. So if you want to blame anything, blame the concept of expression statements, I guess?

yjgyhj 10y ago
You can rightfully blame having state setting be part of your language. It is easier to program without state than with it, just like it's easier to juggle 2 balls than 3. Without state (or with the absolutely minimum of it) you can not make mistakes with it. Also, if your state-setting operator is super similar to your equality-checking operator, you can fall into this trap (like the devs in question did). Programming without state is something that has helped me personally make my code much better. I produce less bugs by far since I stopped relying on state for so many things. A lot of micro-optimisations are not doable for me. In exchange I guess I get to run things in parallell very easily. But mostly, I get fewer bugs, which makes my life and the lives of my customers better.
- spacemanmatt 10y ago
  Picking up Clojure and learning to be extremely judicious about the use of persistent state reduced my bug output rate dramatically.
  - yjgyhj 10y ago
    Amen to that! If Rich Hickey is reading this - it is to you I owe my thanks for the many hours I have not spent on fixing state bugs. Clojure was my first functional love story.
- aij 10y ago
  Writing stateful code by default in hopes that it will be faster is a premature optimization IMNSHO. A lot of times it isn't actually any faster, and it's certainly more error prone.
lmm 10y ago
Ah, the error was the other way around. The idea that you form a value by creating an uninitialized one and then filling in its fields is dumb. (I suspect the field value wasn't even 0 as such but rather undefined, and the implementation happened to make it 0?). Better languages have you initialize the value directly and you can't access it until it's fully initialized. C/C++ are just really bad at expressing nontrivial values, even value literals. (Discarding a value ought to be an error too, though that's more cumbersome to work with)

by caf 10y ago

yjgyhj 10y ago

You can rightfully blame having state setting be part of your language. It is easier to program without state than with it, just like it's easier to juggle 2 balls than 3. Without state (or with the absolutely minimum of it) you can not make mistakes with it. Also, if your state-setting operator is super similar to your equality-checking operator, you can fall into this trap (like the devs in question did). Programming without state is something that has helped me personally make my code much better. I produce less bugs by far since I stopped relying on state for so many things. A lot of micro-optimisations are not doable for me. In exchange I guess I get to run things in parallell very easily. But mostly, I get fewer bugs, which makes my life and the lives of my customers better.

spacemanmatt 10y ago
Picking up Clojure and learning to be extremely judicious about the use of persistent state reduced my bug output rate dramatically.
- yjgyhj 10y ago
  Amen to that! If Rich Hickey is reading this - it is to you I owe my thanks for the many hours I have not spent on fixing state bugs. Clojure was my first functional love story.
aij 10y ago
Writing stateful code by default in hopes that it will be faster is a premature optimization IMNSHO. A lot of times it isn't actually any faster, and it's certainly more error prone.

lmm 10y ago

Ah, the error was the other way around. The idea that you form a value by creating an uninitialized one and then filling in its fields is dumb. (I suspect the field value wasn't even 0 as such but rather undefined, and the implementation happened to make it 0?). Better languages have you initialize the value directly and you can't access it until it's fully initialized. C/C++ are just really bad at expressing nontrivial values, even value literals. (Discarding a value ought to be an error too, though that's more cumbersome to work with)