Hacker News Reader

Comment by kstenerud | Hacker News Reader

This is a dangerous way to think about it. State and time are different things, and if you think of them as the same, then your mental model glosses over some parts of reality that will become important as your software grows more complex.

State is inherently dangerous BECAUSE a program runs TEMPORALLY. As the number of state changes increases, the dangers of an unwanted state increase (particularly insidious are the state combinations you thought weren't even possible). This is why functional programmers favor immutability and idempotent functions.

Also: Just because the EXTERNAL observability of state hasn't changed is no reason to assume that no state changes have occurred. Hidden state changes are the most dangerous of all.

View on HN

Stuff like Haskell I thought has the most of these kind of hidden state changes affecting space and time (e.g. a small code change throws off the magic optimizer and now it uses way more memory to try and efficiently support that immutability or takes exponentially more time).

Nah, but non-Haskellers love telling other non-Haskellers all about how Haskell works.

Example?

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.

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.

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.

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.

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

Reply on news.ycombinator.com