Hacker News Reader

Comment by mtzet | Hacker News Reader

> Inlining functions is not a readability thing.

Inlining for readability is precisely what the linked article is about.

If you are changing global state, and each function has an order dependency, I could see that. But it seems like even then his general takeaway is not to inline functions but not to change global state and use a more functional style of programming.

I think the takeaway is both. Avoid state changes and use a functional style wherever possible. But, when you do need to make state changes, keep it inline rather than hiding it behind function calls. Better to have one long function, sectioned off by comments, than to have state changes with subtle order dependencies in several different functions.

I would go one step further. Don’t section them off with just comments, use nested scoping blocks. At least most modern IDEs then can collapse the sections and you still have the concept of local variables.

Or use a state monad to distinguish between steps that mutate state and functions that don't, making your order dependencies visible and easy to work with...

And this is how we end up with classes like AbstractSingletonProxyFactoryBean

No, just the opposite. Languages with inadequate composition facilities forcing overly specialised single-purpose classes lead to AbstractSingletonProxyFactoryBean. Small composable abstractions are how you avoid it.

Zygohistoric prepromorphism has the same kind of meme status as AbstractSingletonProxyFactoryBean, but the difference is that a zygohistoric prepromorphism is a one-liner you can compose together yourself out of the functions that the library in question makes available, whereas AbstractSingletonProxyFactoryBean is a class in its own right that the library in question has to define.

Reply on news.ycombinator.com