const fOne = fIncrement(zero);
const fTwo = fIncrement(one);
const fThree = fIncrement(two);
// And so on…
How to deal with dirty side effects in your pure functional JavaScript
31–38 of 38 posts
Re: How to deal with dirty side effects in your pure functional JavaScript
#32Earlier quoted context omitted.
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 Reac…
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-no…
> 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.
Re: How to deal with dirty side effects in your pure functional JavaScript
#33One thing you can do is expand your universe to include what would otherwise be "external" effects.
Instead of reading from opaque file handles use three-tuple of (hash, offset, length). Now you have pure input.
Instead of printing to a stream, modify a git repo. Now you have pure output.
Re: How to deal with dirty side effects in your pure functional JavaScript
#34Earlier quoted context omitted.
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…
> 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 co…
Yup, the most popular Clojurescript React framework, Re-frame, works this way, and even with other frameworks, it's encouraged.
Re: How to deal with dirty side effects in your pure functional JavaScript
#35Let's not forget that if you are not passing immutable data-structures into your pure functions, all bets are off.
Unless you code very defensively, there's no way you can guarantee purity, especially in async programming.
Given f(x) = y, if x is a regular JS object, you can't guarantee purity. It works many times because of the single-threaded nature of most JS engines, but the moment you do something async, you can't guarantee x hasn't changed.
That's one of the many reasons I like ClojureScript. It offers interesting guarantees that let me write robust code.
Re: How to deal with dirty side effects in your pure functional JavaScript
#36Earlier quoted context omitted.
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?
Just hard work. Making it look natural and pragmatic is a non-trivial discipline and dare I say, rather thankless work.
(I’m assuming you meant to convey a slightly negative connotation through “mathematical”. Though I myself do like PS too)
Re: How to deal with dirty side effects in your pure functional JavaScript
#37Earlier 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.
Whenever I manage to find time to hack on it:
https://github.com/SanderSpies/ocaml/tree/wasm-backend.
It compiles to wasm object files and links files with LLVM's LLD. My current challenge is ensuring that the stdlib correctly translates to wasm. The C parts are not translated yet - which means: no gc, no exceptions, no tail calls.
Re: How to deal with dirty side effects in your pure functional JavaScript
#38Pure 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, j…
That makes a lot of sense and actually sounds like a really interesting idea. Thanks for the explanation.