Hacker News Reader

Comment by TeMPOraL | Hacker News Reader

Great points, but I have a question about one of them in particular:

> - Functional is OK. Imperative is OK. Both in the same program are a mess.

What do you mean by that?

My experience is that functional alone is impossible, since the only useful thing a program can do is through state changes; imperative is a-OK, and functional+imperative in the same program is the best way to do things (i.e. well-defined stateful areas surrounded by lots of functional code).

View on HN

Once you get over the initial learning curve of the functional/pure approach to state/IO, its far superior to imperative imo. You don't need to reason about global state - because everything is explicit, including passing around your state, you never have to worry about "what if someone else or some other code somewhere is touching this" again.

Imperative programming is fine imo, as long as it is done in a relatively small scope.

> My experience is that functional alone is impossible, since the only useful thing a program can do is through state changes

Some programs are simply pure functions. If your program entry point accepts a string and returns a string, then you can write useful things, such as compilers, image processing, grep, etc, entirely as pure functions.

Unless you want logging with timestamps.

My point was that it is not impossible to write useful programs as pure functions.

You can't counter that with an example of a program that you can't write as a pure function.

Ok, to clarify - I didn't mean program as in a simple function. I meant a program as in application, something that accepts some real-world input and produces some real-world consequences.

Right - a compiler. That's a real-world application isn't it? A compiler can be a pure function - accepting source text as input, and producing machine code as output. Yes more complicated languages do more complicated things, but for several languages you could write a state-of-the-art compiler as a pure function.

Hm.

Fair enough.

Only if you ignore the dynamic state of the language, of associated libraries, of processor architectures, and so on - i.e. the context the compiler is working in and the mutable state of the language and development environment as a whole.

The idea of pure functions is a false friend in CS because it tries to solve the problem of state by wrapping it up and wishing it away.

It's true that state causes a lot of problems, but so many useful systems rely on mutable state - at practical application levels - that it might be interesting to design robust systems that manage state, context, and relationship instead of trying to create contrived examples of state-free systems.

There seems to be a cognitive bias against this in CS. Most developers appear to love puzzle systems made of hard little components with solid edges, and thinking in terms of context and relationships seems to be disturbingly alien. So there aren't many programming paradigms that explicitly work with contextual inference instead of trying to rigidly delimit interfaces.

But there are real prizes to be won from associative context-smart computing, and IMO the domain is wide open for innovation - because it may be possible to give up the pursuit of complete safety and predictability (which doesn't exist anyway) in return for new kinds of powerful, productive, and smart features.

> Only if you ignore the dynamic state of the language, of associated libraries, of processor architectures, and so on

I don't understand why any of this means you can't have a compile as a pure function. A pure function can cope with things changing internally - it just creates new data structures to represent things that have changed in the old data structures and then passes the new data structures onto the next phase.

A pure function just means you can't do something like a package manager that needs to read files from disk or download things.

> but so many useful systems rely on mutable state

You don't have to argue this to me - I wrote the first half of my PhD on the importance of mutable state.

I'm just arguing against the nonsense that it is impossible to write a useful real-world application as a pure function.

I work in the VM research group at Oracle, and guess what? Our JIT compiler is basically a pure function. It takes in some bytecode and produces some machine code. It's structured a little differently in reality, but it is logically, and almost in practice, a pure function from one to the other.

I'm writing a presentation about this right now.

This is the best HN post i've read today. You should expand it into a blog post.

I also agree - context and state are important and useful, because many real-life problems or processes rely on such a model and thus translate naturally when state is a "first-class citizen."

Sure, it's not impossible to write something as a pure function. But it's not an interesting statement to make unless you also apply the implied context that it may be desirable to do so. Do you think it is desirable to make these pipeline components as programs using pure functions?

Logging with timestamps is not in opposition to purity.

All purity does is force you to change the type of a function that wants to log something, to reflect that it’s returning a value that, when evaluated at run-time, will have the side-effect of printing to the console. It’s still a pure function since it returns the same description given the same argument(s), the only difference is that when this description is evaluated by the run-time system, something will be printed to the console (in accordance with the description).

In other words, you’re not restricting the effects your program can have, only how you can choose to describe them (as first-class values whose evaluation has a side-effect that is not observable by your code).

It’s all explained perfectly in this talk: https://www.infoq.com/presentations/io-functional-side-effec...

Erlang / Elixir are 100% immutable inside the code (no var can ever be mutable).

However, they have a mutable in-process cache (living in the BEAM VM) that many people have written libraries around for stuff like mutable arrays, matrices, graphs, and many others.

It goes like this: do 99.5% functional programming and you have the imperative / stateful tools for when they are absolutely necessary.

This works. Extremely well.

Reply on news.ycombinator.com