5 ms·

In my experience learning, teaching, and watching other people learn FP, it's far easier to learn FP with a language which is actually designed for it, e.g., El

In my experience learning, teaching, and watching other people learn FP, it's far easier to learn FP with a language which is actually designed for it, e.g., Elm. JavaScript isn't that. It carries too much legacy baggage. Too many gotchas; too many pointy bits. It's also just super noisy. There's a reason why someone had to write The Good Parts. I don't buy the idea either that modern JavaScript is somehow devoid of the kinds of problems that existed when Crockford wrote that book. I mean, how many people still think that `const` gives you an immutable value? n.b. I'm not sure why the Haskell snippet was included. It's confusing, and doesn't even make sense given that `main` is defined twice.

Osiris 6y ago
This is my experience as well. I had a co-worker that really pushed for FP in JavScript using Ramda.js. the principles were appealing, but because JavaScript doesn't have native syntax for many of the principles like pattern matching, you end up with hard to read code that's a bunch of nested arrays or chains wrapped in helper functions like "compose([fn1, fn2])(data)". I later tried to learn F# and while the syntax was foreign, it turned out that it was MUCH easier to write FP code because the language had native operators for composition, etc. The code was also much easier to read. I think it would be great if JavaScript got some FP syntax natively (see the pattern matching proposal). But hacking functional principals using arrays and helper functions just leads to hard to read code, especially for people not familiar with the specific FP library you chose to use.
- adamkl 6y ago
  I'm actually thinking about putting together a series of posts on the topic of "Full-stack ClojureScript for JavaScript developers". I've heard ClojureScript described (from a functional programming standpoint) as "JavaScript, but without the stupid parts", as it basically gives you the benefits of Ramda.js + Immutable.js without the headaches of making those libraries play nicely with native JavaScript. It also doesn't veer too far into the theoretical (monads, category theory, etc) so it would make for an easier transition when coming from JavaScript (you can even throw exceptions if you want). I became a Clojure fan-boy over the course of the last year but one issue that seems to keep popping up when I discuss it with my JavaScript/Node.js co-workers is "Clojure runs on the JVM? Not interested". Setting aside the technical validity of that opinion (JVM vs. Node.js), it made me wonder if there might be more interest in Clojure from the JavaScript world if they knew they could use ClojureScript for both the front-end and the back-end (on Node.js).
  - SwanandK 6y ago
    Looking forward to those articles!
  - otsukare 6y ago
    I think I'm like your co-workers, I'm really interested in Clojure, but admittably have that (probably unreasonable) JVM aversion. Do you mind sharing why I shouldn't?
    - adamkl 6y ago
      The JVM is an excellent general purpose, multi-threaded runtime, with a large ecosystem of open source libraries, and its well suited to many types of "back-end" workloads, which is why it was the initial target for Clojure back in 2006/2007. Clojure's great interop with its host platform made it easy for people to get up and running while leveraging all the existing Java libraries they were used to. The JVM is still a great choice for all those reasons, but its a little heavier than Node.js which specializes in IO bound use cases (i.e. the back-end-for-front-ends that sit between the browser and the heavyweight back-end systems). Node.js is also probably better suited for smaller services, lambdas, and other light-weight scenarios (IOT?). I'm interested in promoting a full-stack approach to ClojureScript because the JavaScript/Node.js ecosystem is everything that the Java ecosystem was 15 years ago. It has lots of developers, lots of libraries, and a "bad" language. And by sticking with Node.js, its one less hurdle for JavaScript developers to clear when learning ClojureScript. They still get to use all the same libraries they did before (via ClojureScript's great interop), and the runtime characteristics they are used to. Plus, if they then decide to start looking at Clojure on the JVM in the future, they will have already learned the language.
- nicoburns 6y ago
  Do you have a link to the pattern matching proposal? IMO if you added pattern matching and made everything (blocks, if-else, switch statements, etc) expressions then JavaScript would be pretty decent for writing in a functional style.
  - chiffre 6y ago
    https://github.com/tc39/proposal-pattern-matching https://github.com/tc39/proposal-pattern-matching
- archarios 6y ago
  I have written non trivial projects with ramda and I like it a lot. You have to use your judgement with readability. Some of the advanced functions are a little hard to grok at first, but most of the library is pretty straight forward.
daiyanze 6y ago
Thanks for your time reading my article! > it's far easier to learn FP with a language which is actually designed for it, e.g., Elm. I strongly agree with you on that. Pick up the right tool for the right task. I understand that Javascript isn't designed for FP. But it doesn't block us from borrowing ideas from FP.
lmiller1990 6y ago
I think it depends. It's hard to learn more than one thing at once; if you already know JS well, learning about functional programming using it makes sense to me. It's tricky to learn both a new language paradigm and a new syntax at the same time. Of course there are limitations to how functional you can really be in JS; that said, I like the idea of introducing some basic concepts with JS. If people like the idea, they can pursue a "functional first" language.
- iphies 6y ago
  Yeah, this is what happened to me. FP was really easy purchase for me with JS because of its numerous flaws. But in the end, it got tiresome to have to write libs and import them around to keep the ick away, and because the lang ecosystem was doubling down on enterprise OOP conventions with TS, I decided to move away to Haskell.
- yakshaving_jgt 6y ago
  Learning new syntax really isn't hard. Bear in mind that quite a lot of supposedly "modern" JavaScript is new syntax.
  - onion2k 6y ago
    Learning new syntax really isn't hard. When you make an absolute claim like "Learning new syntax really isn't hard." you're really saying "I find it easy therefore everyone else must too." That's poor quality thinking at best, and actively toxic to your peers at worst. In my twenty+ years as a mentor to developers I've learned that objective statements about what is and isn't hard in programming are always going to fail when it comes to some set of devs. Some people find it trivial to move from one mental model to another. Other people find it really hard. This is true for every aspect of development - there is nothing that everyone finds easy or that everyone finds hard. If you don't take that in to consideration when you talk about programming you're always going to be failing at least one group.
    - yakshaving_jgt 6y ago
hhas01 6y ago
Indeed. Programming with Functions != Functional Programming. FP is predicated on referential transparency. FP decides the order of operations, not the programmer. If you don’t have that, you don’t have FP: you’ve got procedural programming with closures. Which is nice, but claiming you’re doing “Functional Programming” smells of this: http://calteches.library.caltech.edu/51/2/CargoCult.htm http://calteches.library.caltech.edu/51/2/CargoCult.htm An effective tool is defined as much by what it cannot do as by what it can. In FP’s case, forbidding the unpredictability of mutable-state-over-time permits the automation of higher-level mathematical reasoning, enabling both compiler and runtime to make their own optimizations as they see fit: stronger guarantees of program correctness, deferring costly operations until/if they’re needed, caching the results for fast cheap reuse, parallelizing calculations without fear of races. Powerful stuff, as long as you’re willing to cede a bit of control. If C and its procedural ilk are all a Swiss Army hammer, declarative programming systems (functional, logic, dataflow, etc) are these: https://www.reddit.com/r/specializedtools/ https://www.reddit.com/r/specializedtools/ A good craftsman should know when to use which; alas, we all too often end up seeing this instead: https://weblogs.asp.net/alex_papadimoulis/408925 https://weblogs.asp.net/alex_papadimoulis/408925
the_gipsy 6y ago
> JavaScript isn't that. It carries too much legacy baggage. Too many gotchas; too many pointy bits. It's also just super noisy. Not only that. If you use types, and then an FP library, and then immutability, these three are at always at odds with each other.
- lf-non 6y ago
  Very correct. In addition, it becomes a real pain when using generics with constraints in TS. TS doesn't support either type classes or module/namespace level generics so you end up duplicating the same constraints applied to generic parameters across several functions. It is often easier to just use stateless classes instead and incur the runtime overhead of instantiation even if that object serves no purpose.
  - the_gipsy 6y ago
    Can you not simply `export type T` and use `f<U extends T>`?
zarathustreal 6y ago
Are you implying that const _doesn’t_ give you an immutable value? Or are you purposefully ignoring the difference between a primitive value and a pointer to make your point?
- yakshaving_jgt 6y ago
  The `const` keyword in JavaScript does not give you an immutable value. This is not up for discussion. https://dev.to/valentinogagliardi/once-and-for-all-const-in-javascript-is-not-immutable-2gop https://dev.to/valentinogagliardi/once-and-for-all-const-in-...
  - mhaberl 6y ago
    const value can be redeclared in a different scope - but to be very precise; this is not really question of (im)mutability - it is a different value inside a scope, the original value is not changed. Other thing is (and I believe this is what the OP is asking you) - if you say: const a = 1; a will always be 1 (inside the scope). Sure if you say: const o = { a: 1}; you can change the value of a inside the o, but the o (the pointer as the OP is saying) is not changed. I have 0 experience with Elm, but a _lot_ of popular languages have this behaviour for const/final
    - yakshaving_jgt 6y ago
      It's not useful to describe the behaviour of "pointers" in JavaScript, because JavaScript does not have pointers[0]. I think the article I linked to earlier was already sufficiently unambiguous. To clarify once again: If you can mutate a value, then the value is mutable. Mutable means it is not immutable. The `const` keyword in JavaScript does not give you an immutable value. [0]: https://stackoverflow.com/a/17382443/704015 https://stackoverflow.com/a/17382443/704015
      - mhaberl 6y ago
        I used the terminology that the OP used to be more clear. Pointer or reference in this context is not so significant as is that 'const' is marking the reference (OP used "pointer") as a constant, and not the value that is referring to. Point the OP was getting at: 'const' gives you an immutable reference to a mutable value because it is a modifier for the reference and not the value. Yes, the article you linked was unambiguous, but for another question :) As i said, a lot of langugaes (I don't know any that behaves differently) uses the const/final modifiers in this way. In my experience with people that are just learning how to code, it is a more efficient to point out what is the 'const' modifier making a constant of, than pointing out what it does not do, because the latter sometimes sends a message that the 'const' is useless as it 'does not do anything'.
melvinroest 6y ago
Hey yakshaving, Osiris and others who agree with the sentiment of learning FP via Elm. Do you know of any good resources to start out with?
- yakshaving_jgt 6y ago
  The official guide is very clear and easy to follow[0]. [0]: https://guide.elm-lang.org/ https://guide.elm-lang.org/
agumonkey 6y ago
even with es6 ?
- yakshaving_jgt 6y ago
  Yes.

Osiris 6y ago

This is my experience as well. I had a co-worker that really pushed for FP in JavScript using Ramda.js. the principles were appealing, but because JavaScript doesn't have native syntax for many of the principles like pattern matching, you end up with hard to read code that's a bunch of nested arrays or chains wrapped in helper functions like "compose([fn1, fn2])(data)". I later tried to learn F# and while the syntax was foreign, it turned out that it was MUCH easier to write FP code because the language had native operators for composition, etc. The code was also much easier to read. I think it would be great if JavaScript got some FP syntax natively (see the pattern matching proposal). But hacking functional principals using arrays and helper functions just leads to hard to read code, especially for people not familiar with the specific FP library you chose to use.

adamkl 6y ago
I'm actually thinking about putting together a series of posts on the topic of "Full-stack ClojureScript for JavaScript developers". I've heard ClojureScript described (from a functional programming standpoint) as "JavaScript, but without the stupid parts", as it basically gives you the benefits of Ramda.js + Immutable.js without the headaches of making those libraries play nicely with native JavaScript. It also doesn't veer too far into the theoretical (monads, category theory, etc) so it would make for an easier transition when coming from JavaScript (you can even throw exceptions if you want). I became a Clojure fan-boy over the course of the last year but one issue that seems to keep popping up when I discuss it with my JavaScript/Node.js co-workers is "Clojure runs on the JVM? Not interested". Setting aside the technical validity of that opinion (JVM vs. Node.js), it made me wonder if there might be more interest in Clojure from the JavaScript world if they knew they could use ClojureScript for both the front-end and the back-end (on Node.js).
- SwanandK 6y ago
  Looking forward to those articles!
- otsukare 6y ago
  I think I'm like your co-workers, I'm really interested in Clojure, but admittably have that (probably unreasonable) JVM aversion. Do you mind sharing why I shouldn't?
  - adamkl 6y ago
    The JVM is an excellent general purpose, multi-threaded runtime, with a large ecosystem of open source libraries, and its well suited to many types of "back-end" workloads, which is why it was the initial target for Clojure back in 2006/2007. Clojure's great interop with its host platform made it easy for people to get up and running while leveraging all the existing Java libraries they were used to. The JVM is still a great choice for all those reasons, but its a little heavier than Node.js which specializes in IO bound use cases (i.e. the back-end-for-front-ends that sit between the browser and the heavyweight back-end systems). Node.js is also probably better suited for smaller services, lambdas, and other light-weight scenarios (IOT?). I'm interested in promoting a full-stack approach to ClojureScript because the JavaScript/Node.js ecosystem is everything that the Java ecosystem was 15 years ago. It has lots of developers, lots of libraries, and a "bad" language. And by sticking with Node.js, its one less hurdle for JavaScript developers to clear when learning ClojureScript. They still get to use all the same libraries they did before (via ClojureScript's great interop), and the runtime characteristics they are used to. Plus, if they then decide to start looking at Clojure on the JVM in the future, they will have already learned the language.
nicoburns 6y ago
Do you have a link to the pattern matching proposal? IMO if you added pattern matching and made everything (blocks, if-else, switch statements, etc) expressions then JavaScript would be pretty decent for writing in a functional style.
- chiffre 6y ago
  https://github.com/tc39/proposal-pattern-matching https://github.com/tc39/proposal-pattern-matching
archarios 6y ago
I have written non trivial projects with ramda and I like it a lot. You have to use your judgement with readability. Some of the advanced functions are a little hard to grok at first, but most of the library is pretty straight forward.

daiyanze 6y ago

Thanks for your time reading my article! > it's far easier to learn FP with a language which is actually designed for it, e.g., Elm. I strongly agree with you on that. Pick up the right tool for the right task. I understand that Javascript isn't designed for FP. But it doesn't block us from borrowing ideas from FP.

lmiller1990 6y ago

I think it depends. It's hard to learn more than one thing at once; if you already know JS well, learning about functional programming using it makes sense to me. It's tricky to learn both a new language paradigm and a new syntax at the same time. Of course there are limitations to how functional you can really be in JS; that said, I like the idea of introducing some basic concepts with JS. If people like the idea, they can pursue a "functional first" language.

iphies 6y ago
Yeah, this is what happened to me. FP was really easy purchase for me with JS because of its numerous flaws. But in the end, it got tiresome to have to write libs and import them around to keep the ick away, and because the lang ecosystem was doubling down on enterprise OOP conventions with TS, I decided to move away to Haskell.
yakshaving_jgt 6y ago
Learning new syntax really isn't hard. Bear in mind that quite a lot of supposedly "modern" JavaScript is new syntax.
- onion2k 6y ago
  Learning new syntax really isn't hard. When you make an absolute claim like "Learning new syntax really isn't hard." you're really saying "I find it easy therefore everyone else must too." That's poor quality thinking at best, and actively toxic to your peers at worst. In my twenty+ years as a mentor to developers I've learned that objective statements about what is and isn't hard in programming are always going to fail when it comes to some set of devs. Some people find it trivial to move from one mental model to another. Other people find it really hard. This is true for every aspect of development - there is nothing that everyone finds easy or that everyone finds hard. If you don't take that in to consideration when you talk about programming you're always going to be failing at least one group.
  - yakshaving_jgt 6y ago

hhas01 6y ago

Indeed. Programming with Functions != Functional Programming. FP is predicated on referential transparency. FP decides the order of operations, not the programmer. If you don’t have that, you don’t have FP: you’ve got procedural programming with closures. Which is nice, but claiming you’re doing “Functional Programming” smells of this: http://calteches.library.caltech.edu/51/2/CargoCult.htm http://calteches.library.caltech.edu/51/2/CargoCult.htm An effective tool is defined as much by what it cannot do as by what it can. In FP’s case, forbidding the unpredictability of mutable-state-over-time permits the automation of higher-level mathematical reasoning, enabling both compiler and runtime to make their own optimizations as they see fit: stronger guarantees of program correctness, deferring costly operations until/if they’re needed, caching the results for fast cheap reuse, parallelizing calculations without fear of races. Powerful stuff, as long as you’re willing to cede a bit of control. If C and its procedural ilk are all a Swiss Army hammer, declarative programming systems (functional, logic, dataflow, etc) are these: https://www.reddit.com/r/specializedtools/ https://www.reddit.com/r/specializedtools/ A good craftsman should know when to use which; alas, we all too often end up seeing this instead: https://weblogs.asp.net/alex_papadimoulis/408925 https://weblogs.asp.net/alex_papadimoulis/408925

the_gipsy 6y ago

> JavaScript isn't that. It carries too much legacy baggage. Too many gotchas; too many pointy bits. It's also just super noisy. Not only that. If you use types, and then an FP library, and then immutability, these three are at always at odds with each other.

lf-non 6y ago
Very correct. In addition, it becomes a real pain when using generics with constraints in TS. TS doesn't support either type classes or module/namespace level generics so you end up duplicating the same constraints applied to generic parameters across several functions. It is often easier to just use stateless classes instead and incur the runtime overhead of instantiation even if that object serves no purpose.
- the_gipsy 6y ago
  Can you not simply `export type T` and use `f<U extends T>`?

zarathustreal 6y ago

Are you implying that const _doesn’t_ give you an immutable value? Or are you purposefully ignoring the difference between a primitive value and a pointer to make your point?

yakshaving_jgt 6y ago
The `const` keyword in JavaScript does not give you an immutable value. This is not up for discussion. https://dev.to/valentinogagliardi/once-and-for-all-const-in-javascript-is-not-immutable-2gop https://dev.to/valentinogagliardi/once-and-for-all-const-in-...
- mhaberl 6y ago
  const value can be redeclared in a different scope - but to be very precise; this is not really question of (im)mutability - it is a different value inside a scope, the original value is not changed. Other thing is (and I believe this is what the OP is asking you) - if you say: const a = 1; a will always be 1 (inside the scope). Sure if you say: const o = { a: 1}; you can change the value of a inside the o, but the o (the pointer as the OP is saying) is not changed. I have 0 experience with Elm, but a _lot_ of popular languages have this behaviour for const/final
  - yakshaving_jgt 6y ago
    It's not useful to describe the behaviour of "pointers" in JavaScript, because JavaScript does not have pointers[0]. I think the article I linked to earlier was already sufficiently unambiguous. To clarify once again: If you can mutate a value, then the value is mutable. Mutable means it is not immutable. The `const` keyword in JavaScript does not give you an immutable value. [0]: https://stackoverflow.com/a/17382443/704015 https://stackoverflow.com/a/17382443/704015
    - mhaberl 6y ago
      I used the terminology that the OP used to be more clear. Pointer or reference in this context is not so significant as is that 'const' is marking the reference (OP used "pointer") as a constant, and not the value that is referring to. Point the OP was getting at: 'const' gives you an immutable reference to a mutable value because it is a modifier for the reference and not the value. Yes, the article you linked was unambiguous, but for another question :) As i said, a lot of langugaes (I don't know any that behaves differently) uses the const/final modifiers in this way. In my experience with people that are just learning how to code, it is a more efficient to point out what is the 'const' modifier making a constant of, than pointing out what it does not do, because the latter sometimes sends a message that the 'const' is useless as it 'does not do anything'.

melvinroest 6y ago

Hey yakshaving, Osiris and others who agree with the sentiment of learning FP via Elm. Do you know of any good resources to start out with?

yakshaving_jgt 6y ago
The official guide is very clear and easy to follow[0]. [0]: https://guide.elm-lang.org/ https://guide.elm-lang.org/

agumonkey 6y ago

even with es6 ?

yakshaving_jgt 6y ago
Yes.