30 ms·

Jesus. Guys. State and change are not literally Hitler. Changes to state are what computers are made for. You will not write bug free programs. Haskell demonst

by wredue 2y ago

Jesus. Guys. State and change are not literally Hitler. Changes to state are what computers are made for. You will not write bug free programs. Haskell demonstrably does not reduce bugs over and above languages that allow direct state changes. Instead of fostering an environment of being afraid of your data. Embrace it. Write the code that needs to be written. Accept that bugs will happen (before you slippery slope this, I am not saying to write bugs for the sake of it, or to use state in unintended ways). You do not need to be afraid of your state. Join us on the light side.

kstenerud 2y ago
Isn't that what I said? State is dangerous - it's an entropy multiplier, so keep it within reason and for gods sake don't ignore it or pretend it doesn't exist. We like to think that we have it all under control, but the time dimension multiplies everything, and has a tendency to ratchet them until suddenly you find that you actually don't have it under control anymore. The less state you have, the less your brain gets turned into a pretzel trying to keep track of it all over the time dimension.
- zerodensity 2y ago
  If you care very much about not ever ending up in a bad state (which it seems that you do). Then just functional programming with immutable state is not going to cut it. In this realm you should look into methods of formal verification to prove that your code does what you want it to do. That being said, functional verification is a huge time sink and is really only economical if it's very important for the code to always be correct. That is, people die if your software has a bug. A few examples would be pacemakers, aircraft autopilots or your car brakes. If your not working one of these domains then maybe immutable and pure functional code can save you a few bugs? I have not read any peer reviewed study that shows this is the case. But if you have any such paper i would be happy to read it.
- wredue 2y ago
  You have no control over how much state you “need”. A complex application will probably have more. An easy application will probably have less. If the modern web has taught us anything at all, it should be that trying to fit small pieces of state together like a puzzle ain’t it.
  - kstenerud 2y ago
    Modern web would best be described as a fustercluck. Web tech still hasn't caught up to most of the lessons learned in the 70s 80s and 90s. Watching web GUI technologies evolve over the past 20 years was like watching bad 70s reruns, with all the cringe and facepalm. We have enough to make a discipline out of the field, but every 20 years or so the next generation of fresh recruits brings all their bad habits in with them and then round and round we go again with the new (and horribly broken) technologies that didn't learn from the last time we did the same things and made the same mistakes in a similar way. You absolutely can control how much state you need (down to a minima, of course). The issue is not with the minimum state necessary - it's with the cowboy mentalities that lead to excessive state (and even worse - excessively complicated state interactions).

by wredue 2y ago

kstenerud 2y ago

Isn't that what I said? State is dangerous - it's an entropy multiplier, so keep it within reason and for gods sake don't ignore it or pretend it doesn't exist. We like to think that we have it all under control, but the time dimension multiplies everything, and has a tendency to ratchet them until suddenly you find that you actually don't have it under control anymore. The less state you have, the less your brain gets turned into a pretzel trying to keep track of it all over the time dimension.

zerodensity 2y ago
If you care very much about not ever ending up in a bad state (which it seems that you do). Then just functional programming with immutable state is not going to cut it. In this realm you should look into methods of formal verification to prove that your code does what you want it to do. That being said, functional verification is a huge time sink and is really only economical if it's very important for the code to always be correct. That is, people die if your software has a bug. A few examples would be pacemakers, aircraft autopilots or your car brakes. If your not working one of these domains then maybe immutable and pure functional code can save you a few bugs? I have not read any peer reviewed study that shows this is the case. But if you have any such paper i would be happy to read it.
wredue 2y ago
You have no control over how much state you “need”. A complex application will probably have more. An easy application will probably have less. If the modern web has taught us anything at all, it should be that trying to fit small pieces of state together like a puzzle ain’t it.
- kstenerud 2y ago
  Modern web would best be described as a fustercluck. Web tech still hasn't caught up to most of the lessons learned in the 70s 80s and 90s. Watching web GUI technologies evolve over the past 20 years was like watching bad 70s reruns, with all the cringe and facepalm. We have enough to make a discipline out of the field, but every 20 years or so the next generation of fresh recruits brings all their bad habits in with them and then round and round we go again with the new (and horribly broken) technologies that didn't learn from the last time we did the same things and made the same mistakes in a similar way. You absolutely can control how much state you need (down to a minima, of course). The issue is not with the minimum state necessary - it's with the cowboy mentalities that lead to excessive state (and even worse - excessively complicated state interactions).