4 ms·
Not "taken over" but in many ways functional programming techniques have gotten big in front-end land, not only with JavaScript but also "real" functional langu
by sotojuan 11y ago
Not "taken over" but in many ways functional programming techniques have gotten big in front-end land, not only with JavaScript but also "real" functional languages like Elm or ClojureScript.
- the_cat_kittles 11y agothose are both javascript? thought you were going to say haskell or clojure...
- sotojuan 11y agoBoth compile to JavaScript, yes, but are their own languages used to write front-end applications. That's what I meant.
- jondubois 11y agoGood point, languages like JavaScript support both imperative AND declarative/functional styles. A language that lets you do both covers more use cases than a language that only does one. With a multi-paradigm language like JS, companies can choose what approach they want to use (and to what extent) and enforce it via a programming styleguide. With JavaScript, you could even run a linter over your code to strictly enforce your own FP rules. There is no doubt that FP has taken over JavaScript - All new popular frameworks including Angular, Polymer and React are declarative/functional with the exception of a few minor (but very useful) imperative concepts (e.g. these frameworks do encourage you to keep 'state' inside models). FP is awesome but 100% pure FP is just not practical - When building real-life systems, ultimately, you need to keep stack of state somewhere - Be in in the database or inside a model in your code.
- ng12 11y agoThis is where I think clojurescript (particularly with React) really shines. Pure functional is the default, and you have to actually do work to make things stateful. The main pitfall of almost-functional languages/frameworks is that it's all too easy to fall back on stateful programming to get things done quick-and-dirty. Clojurescript has a lot of other problems -- e.g. not really having an ecosystem outside of Lein -- but using cljs/om for the first time was like a breath of fresh air.
- tel 11y agoI'll toss it out there that 100% pure FP is pretty much the epitome of keeping a stack of state somewhere... But I wouldn't claim it's too similar or intuitive to someone more used to standard state management.
- eru 11y agoWhat do you mean by a stack of state?
- tel 11y agoI'm copying the op who I actually think meant to say "keep track of state", but "stack of state" feels like having a bunch of "pieces of state" all tidily stacked up in the corner so despite the potential confusion with the technical term I kept it.
- eru 11y ago> Good point, languages like JavaScript support both imperative AND declarative/functional styles. A language that lets you do both covers more use cases than a language that only does one. For what's it worth, some people refer to Haskell as their favourite imperative language. And they are only semi-joking: while the library ecosystem is firmly in the camp of functional idioms, imperative programming is Haskell is pretty nice and straightforward---you'll just have to tag your code with eg IO or the State Monad.
- spion 11y agoIf you use the ST monad instead of State, you get actual mutable variables. STArray lets you write typical imperative algorithms that work with mutable arrays, like sieve of Eratosthenes or dynamic programming. Imperative sieve of Eratosthenes: https://gist.github.com/rik0/1171446#file-erat1-hs https://gist.github.com/rik0/1171446#file-erat1-hs
- eru 11y agoYes. Though sieve of Eratosthenes really cries out for a sort-of-lazy infinite array.