Hacker News Reader

Comment by kalyantm | Hacker News Reader

Exactly my thought. I've always loved FP, I write JS in a FP style at work, and have always wanted to get into learning something like Elm/PureScript (and eventually Haskell) but I feel like it takes ages to get productive. That PureScript React example alone has me thinking twice. But as a general question, what would be a better way to approach these languages?

View on HN

Elm shouldn't take more than a week to be productive if you know other existing language. I ran a study group where people spent few hours a week, the group took 7 meetings to finishing the book and discussing a variety of possible problems to solve with Elm. It's a much simpler language than PureScript.

Consider looking at ReasonML and ReasonReact, you can write stringly typed code at first, later you can start relying on type inference and ADTs

Yeah, ReasonML and ReasonReact are great because you're still writing JSX and not some over-engineered voodoo rewrite of React and/or JS but you get the power of strong types and ADTs and a super fast compiler.

I think FP UI solutions don't necessarily win the 10-liner demo (except for representing client state with an AGDT), but your app also isn't a 10-liner.

FP approaches to UI like Elm win the 100+ line comparisons for reasons you can't see, like minimizing runtime errors and making it so that impossible states are impossible at the type level.

Unfortunately it's hard to see the benefits until you get your hands dirty.

I use Elm in production on some apps and its a good place to start if you want simplicity. Personally, Purescript never interested me because I don't like all the complexity of more advanced Haskell features. While Elm specifically avoids certain advanced features to stay simple. You might like it given your concerns.

Can you explain more about writing JS in an FP style? I'd love to start to incorporate more FP in my JS but I don't really know how to start doing that. I've looked at fp-ts but it seems like that would require a full rewrite. Any tips for how to basically start from 0 and start to implement FP into an existing JS/TS codebase?

I'd suggest just learning and applying fp principles in JS incrementally. You'll feel a bit constrained at first (in part b/c JS allows you to do many "dirty" things), but you'll end up writing better code. Try to rely on 1) pure functions/no side-effects: a functions return value should be completely determined by its input 2) immutability: no Array.push, pop, or any method that modifies its input values 3) recursion instead of for & while loops.

You'll probably feel the need for stronger typing at some point when adhering to these principles, and that's when I'd suggest looking at Typescript. By trying the things above you'll likely get familiar with the issues TS is trying to solve & you'll appreciate it more. Note that fp-ts is just a "helper" library for functional concepts, but it won't teach you their value or how to use them.

Also: many libraries have fp variations! Next time you reach for lodash, try lodash/fp instead: it has the same tools you'll already be familiar with, but implemented in a functional manner.

That is why I like Typescript as an option. Protect me from my dumb mistakes with types, but let me be fast and loose like JS.

Reply on news.ycombinator.com