Hacker News Reader

Comment by xg15 | Hacker News Reader

Pure functions have of course a lot of benefits - if the goal is computing a value. However, why would you even want to compose an interactive application (in javascript) fully out of pure functions?

E.g., suppose you have an SPA that pulls data from a number of Rest endpoints, then does some transforms on that data, produces some HTML and eventually updates the page DOM accordingly.

It makes sense model the "transform" and "produce HTML" steps as pure functions, because they are effectively side-effect free calculations. I think it might also make sense to cheat and treat the Rest calls as pure functions, because this will let you find out quickly in which order you should do them and which of them you can run in parallel.

But why would you want to model the eventual update step itself as a pure function?

View on HN

> But why would you want to model the eventual update step itself as a pure function?

So you can more easily debug the application across incorrect state changes: if your update function is pure, you can very easily compare the state-before and the state-after.

This maintenance of observability is a superset of the unit-testing bit legulere talks about, and also opens up new features e.g. undo/redo becomes trivial, just re-set the state to whatever you need. If you modify the application state in-place, things become much more complex.

In a way git can be treated as that, the HEAD commit is the application state, when you "modify the state" you don't modify that commit in-place instead you create a new commit, then move HEAD to that new commit. Only the second step is impure. Even amending a commit is the latter, you're not actually modifying the old HEAD, you're creating a new one from it then moving HEAD from one to the other.

In theory, this sounds great, and I am a huge proponent of functional programming. In practice, I've never seen it intuitive or useful.

I've been at 3 companies now where "time travel" has never been used and web app development has been more painful than it needed to be.

It feels very much like the proper (from a CS perspective) approach, but the language and libraries just aren't there to make it feel productive or fun. Is there any meaningful work being done to address this, or is it perhaps a boiling frog scenario?

You might be able to foster a deeper appreciation for some of these ideas by playing with Elm a little bit. Some time ago, they implemented time-travel in the standard debugger, and its a really wonderful feature. The site also has some demo apps that make it easy to play around with that time travel support.

I agree that, currently, languages and frameworks don’t make things like time travel easy, insofar as such a feature is not often built in. However, technologies like Flux and Vuex are paving the way for such things to become mainstream. It’s worth pointing out, too, that both were inspired by Elm’s runtime architecture.

Functional programming is, only in the last half-decade or so started to see a relatively dramatic rise in popularity. I think this trend will continue for a long time to come. For that reason, it’s worth learning more about these concepts.

> In theory, this sounds great, and I am a huge proponent of functional programming. In practice, I've never seen it intuitive or useful. […] Is there any meaningful work being done to address this, or is it perhaps a boiling frog scenario?

That's how Elm works and it's glorious. IIRC there are also clojurescript systems working that way (application state is an atom and updating it is a transactional CAS).

But of course it also helps that the language itself lends itself to this, so you want a language which is expressions oriented and there persistent data structures are the default (or even the only) option. You can do the same thing in e.g. Javascript, but the language doesn't really help and it's easy to slip.

Yup, the most popular Clojurescript React framework, Re-frame, works this way, and even with other frameworks, it's encouraged.

Like another commenter said, using frameworks like flux and vuex allow you to utilize browser extensions that make the 'time traveling' debugging process easy.

That makes a lot of sense and actually sounds like a really interesting idea. Thanks for the explanation.

The entire app can't be pure as we wouldn't observe any effects of its execution :)

This post offers an interesting discussion on this subject: https://www.destroyallsoftware.com/screencasts/catalog/funct...

You can unit-test pure functions better.

I could be mistaken, but I don't think you can have a "pure" functional front-end. I think even with something like mithril.js, you will have to run some computation method to update changes in the view when some data changed.

I think the benefit of js functional programming is composability; you can build complicated functions from smaller, more focused functions. This ends up being easier to read and debug if you run into some unforeseen logic error.

It really depends on what you are building, but it's hard to avoid logic errors when working with the DOM explicitly. It's a lot easier to map over an empty array than to manipulate DOM elements that have been removed from the screen.

'cos all the kewl kids are doing it!

I agree with you, functional programming and pure functions have a lot to offer but they have a place and as soon as you start pushing them into every corner of an app you end up just creating problems for the future.

I don’t think that’s entirely true. A lot of the ideas talked about in this article and that most people have already become familiar with are not very abstract. If you tried to build a large application out of nothing but pure function application, of course your code would become complex. We need more frameworks or libraries to take some of these ideas and bring them together in a way that scales. Elm, Vue and React are examples of tech that are doing this and, I think, make functional programming extremely appealing.

Better tooling can help, but so can 'not' forcing everything to be side-effect free.

Honestly, I'm getting downvotes for this but probably from the same types who thought CQRS or micros-services should be taken to the extreme and ended up totally crashing and burning.

Why can't techies see an approach, appreciate where it can help, and apply it where its useful? Why does it seemingly have to always be an all-in-or-nothing proposition?

> Why does it seemingly have to always be an all-in-or-nothing proposition?

This is one of the reasons I love JavaScript so much, and one of the things that stood out to me in the article. JavaScript is extremely expressive and allows you to write code without worrying about following some specific paradigm, which always seemed to me to be one of its biggest strengths, not a weakness as the article seems to suggest.

Reply on news.ycombinator.com