Hacker News Reader

Comment by e-dant | Hacker News Reader

Balance in all things

Edit: eh, that comment didn’t really say much. What I meant was that there are classes of algorithms that are stateless. Maybe the most useful are proofs.

Look, I’m a C++ dev. I live and breathe state. Weird, mostly-working gadgets are the real humans of the world.

But that doesn’t mean I don’t use linear types and write unit tests for my function composition. Sure, I’ll let closures capture their context, and I’ll allow pass-by-reference in my APIs, but that doesn’t mean I encourage it.

View on HN

> What I meant was that there are classes of algorithms that are stateless.

Can you give me an example?

Practically speaking, any algorithm that does the same thing given the same input is said to be stateless.

This property becomes more useful when you’re trying to prove something about a function’s behavior over a bunch of well-defined types.

Languages like Haskell and Agda have these properties.

Rust also has some of these properties by default. It has an affine type system (the borrow checker) enforces some guardrails on ad-hoc state manipulation. C++ has linear-esque types in its pointers and higher-kinded types in the concepts and constraints features.

This is kind of nitpicky, but I'll say it anyway.

An algorithm that does the same thing given the same input is deterministic aka referentially transparent aka pure, not stateless.

Even this little snippet of Haskell is stateful:

    statefulFunction :: Int -> Int
    statefulFunction x =
        let y = x * x
        y + y

The binding 'y' is state. Even if it's implicit, as in ((x * x) + (x * x)), it's still state.

People seem to use "stateless" as a word for "doesn't mutate anything", which is kind of weird. Mutability has _nothing_ to do with having state.

Algorithms != computation

Then no algorithm holds state, because an algorithm is just a ruleset.

Sure. But the point is that functional languages are more declarative, holding very little control flow state. Procedural languages are the opposite.

The computation I’m talking about is whether you’re for more of a von neumann target or a lambda calc target.

Reply on news.ycombinator.com