Hacker News Reader

Comment by mcmire | Hacker News Reader

I've never understood these sorts of statements. You can write spaghetti code in a functional language too. Instead of objects floating around, you have functions. Instead of objects interacting with each other in various ways, you have functions interacting with each other in various ways. You can "build programs by accretion" in any language. Ultimately it all comes down to complexity. Simple code is simple, complex code is complex. You're not going to magically get around this by switching to a functional language. Right?

View on HN

Well, if you're really programming in a function way, then you're not using side effects (or at least, the side effects are constrained). That means things are local, and you can safely compose functions without causing the behavior of other parts of the program to change.

Spoken like a true academic.

Or, you know, a software engineer. Good software engineers, after all, value things like low coupling; composability is like a stronger version of low coupling. (That is, composable things are not tightly coupled but decoupled things are not necessarily composable.)

Good software engineers certainly value low couplings. Unless it is a coupling with some code written in an obscure language with extreme (and masochistic) approach and with no common sense.

I'm not at all sure what your point is. There's nothing controversial about the benefits of referential transparency and immutable state, for modularity, composition and simplicity. What is obscure to you? It won't be to everyone.

The biggest thing in this regard a language like Haskell has going for it is purity, and therefore the concept of "no global state" taken to an extreme. Add to that referential transparency (which is a highly related concept anyway) and you get pretty strong "equational reasoning" where it is quite easy to trace, accurately, what's happening in a chain of calls - it's all transformation of data structures passing through.

If by "functional language" you mean JavaScript, then that's a completely different matter... :-)

Whatever you do, don't let some baby with a hammer to take some abstract and high concepts to the extreme, ruin your project and learn from it. Not in your project.

In the production code, stay with the mainstream. And limit your extreme approaches to research grade code, with limited lifetime.

We use Haskell in mission critical production code at my company and we are very happy with it. So do many banks in their pricing models and many other areas of application.

This may mean that we can't just go hire your average programmer, but we have also had a bizarrely low rate of bugs in production despite a high level of inherent complexity in what we do.

Based on what I've seen, codebases, that use non-mainstream languages and technologies have a tendency to fracture into parts written in a mix of languages and disappear in the rubble.

So let's wait a few years, and see, shall we?

(It's not that I don't like, or don't use shiny 'new' toys. It's just that in the long run it really really helps to use these toys only in the 'research grade' code. Depending on anything even a tiny bit out of industry mainstream in your key production code is a huge liability few years down the line.)

Reply on news.ycombinator.com