Hacker News Reader

Comment by croo | Hacker News Reader

My biggest takeaway was something I never before thought was even possible - to create a program without any variables. It turns out you can do a whole lot without any variables.

Through that I understood that the state of a program what causes most of the confusion and without variables reasoning about the code becomes much simpler. Without state everything becomes nice.

Through that I understood that state is the enemy, and global state is the greatest enemy of understanding. Later I realized that this same principle strongly aligns with testable code as more state is what makes code less testable.

It also forced me to use a lot of recursion which is nice as I understood it much better than in that single "Fibonacci number" example.

I also learned to write code that can safely run in parallel as functions without side effects and state are the most ideal candidates for that.

View on HN

>It also forced me to use a lot of recursion which is nice as I understood it much better than in that single "Fibonacci number" example.

Back in college I took a programming class that used Haskell and not having any other do way to perform iterations other than with recursion, you're forced to understand recursion. With imperative languages, you can always fall back to ol' for and while loops so you get the impression that recursion is simply a waste of time.

Minor correction: functional languages have state; they're the captured arguments to partially applied functions. After all, the lambda calculus can simulate a Turing machine.

What functional languages don't have is the ability of a function to modify state in a way that persists beyond its lifetime, which makes the temporal axis of a program more or less the same as the call tree.

State is the enemy only insofar as you need more than the call tree to figure out its value.

I agree, thank you for the correction.

In this context what I mean by stateless is a function call that only depends on the input - given the same starting position it will always produce the same result.

In real world what messes up this behaviour are fields in a class, properties in a file, persistent data of any form and globally initialized variables unknown to the caller.

You don't and will never have an easy way to reproduce, find out or modify these values so ideally you should not put data in database, not use property files and not use fields in classes :)

Yeah... I never said it was easy or doable in real world. But it is a great compass to drive towards a good architecture.

Web apps (well, well-functioning ones, anyway) helped this click for me. While the request is happening, there is state that is passed around, and contexts like the request, the user, etc.. and depending on what you're doing, you may be adding to that state, or modifying it, or whatever.

But that state shouldn't persist beyond the request, otherwise you have problems. You shouldn't have one request modifying the state of other running requests, etc..

Reply on news.ycombinator.com