Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to deal with dirty side effects in your pure functional JavaScript

jrsinclair.com

Post reply on HN
Print view View original

11–20 of 38 posts

Re: How to deal with dirty side effects in your pure functional JavaScript

#11

Post by jarym »

xg15 wrote: post #6

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 "transfo…

'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.

Re: How to deal with dirty side effects in your pure functional JavaScript

#12

Post by legulere »

xg15 wrote: post #6

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 "transfo…

You can unit-test pure functions better.

Re: How to deal with dirty side effects in your pure functional JavaScript

#13

Post by Tade0 »

tempodox wrote: post #2

As long as JS lacks partial application and the ability to define infix operators (for monadic `bind`, etc), it's always going to be ugly. Not that JS would be a good language for that to begin with. We need a serious functional language that compiles to WASM.

"Lacks partial application"? What about:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Meanwhile infix operators are just syntax sugar and can be emulated in other ways.

Re: How to deal with dirty side effects in your pure functional JavaScript

#14

Post by Boulth »

xg15 wrote: post #6

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 "transfo…

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...

Re: How to deal with dirty side effects in your pure functional JavaScript

#15

Post by Boulth »

tempodox wrote: post #2

As long as JS lacks partial application and the ability to define infix operators (for monadic `bind`, etc), it's always going to be ugly. Not that JS would be a good language for that to begin with. We need a serious functional language that compiles to WASM.

PureScript compiles to JS but it's quite readable JS: http://www.purescript.org/

Re: How to deal with dirty side effects in your pure functional JavaScript

#16

Post by k__ »

Boulth wrote: post #15
tempodox wrote: post #2

As long as JS lacks partial application and the ability to define infix operators (for monadic `bind`, etc), it's always going to be ugly. Not that JS would be a good language for that to begin with. We need a serious functional language that compiles to WASM.

PureScript compiles to JS but it's quite readable JS: http://www.purescript.org/

How come that PureScript feels so mathematical to me and Reason/OCaml don't?

Aren't they both FP languages?

Re: How to deal with dirty side effects in your pure functional JavaScript

#17

Post by TheAsprngHacker »

lucideer wrote: post #5
tempodox wrote: post #2

As long as JS lacks partial application and the ability to define infix operators (for monadic `bind`, etc), it's always going to be ugly. Not that JS would be a good language for that to begin with. We need a serious functional language that compiles to WASM.

> We need a serious functional language that compiles to WASM. Aren't there already a few? OCaml? What's "serious" in this context?

Really? If OCaml has a compiler to Wasm, I’m not aware of it. I’m only aware that it compiles to JS (via js_of_ocaml or Bucklescript). Could I please have a link to the Wasm compiler if you have it?

I read somewhere that an OCaml to LLVM compiler was attempted, but people had problems with the GC aspect. I don’t know if this claim is true, though.

Re: How to deal with dirty side effects in your pure functional JavaScript

#18

Post by lucideer »

TheAsprngHacker wrote: post #17
lucideer wrote: post #5

Earlier quoted context omitted.

> We need a serious functional language that compiles to WASM. Aren't there already a few? OCaml? What's "serious" in this context?

Really? If OCaml has a compiler to Wasm, I’m not aware of it. I’m only aware that it compiles to JS (via js_of_ocaml or Bucklescript). Could I please have a link to the Wasm compiler if you have it? I read somewhere that an OCaml to LLVM compiler was attempted, but people had problems with the GC aspect. I don’t know if this claim is true, though.

> I once read that an OCaml to LLVM compiler was attempted, but people had problems with the GC aspect. I can’t confirm this claim though.

I was thinking of the same, but I hadn't/haven't used it so you may be right it never came to fruition.

Re: How to deal with dirty side effects in your pure functional JavaScript

#19

Post by foxes »

tempodox wrote: post #2

As long as JS lacks partial application and the ability to define infix operators (for monadic `bind`, etc), it's always going to be ugly. Not that JS would be a good language for that to begin with. We need a serious functional language that compiles to WASM.

People are working on making Haskell compile to web assembly.

[0] https://www.tweag.io/posts/2018-05-29-hello-asterius.html [1] https://github.com/tweag/asterius

Re: How to deal with dirty side effects in your pure functional JavaScript

#20

Post by masklinn »

xg15 wrote: post #6

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 "transfo…

> 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.

Post reply on HN