4 ms·

My concern with all these "functional javascript" posts is that people might (understandably) leave with the false impression that this is what functional progr

by wyager 10y ago

My concern with all these "functional javascript" posts is that people might (understandably) leave with the false impression that this is what functional programming looks like in general. It's like if you tried to get someone into cars by having them drive a Hyundai i10. Regardless of whether you think JavaScript qualifies as a "functional language" just because it supports higher-order functions, the fact of the matter is that JS doesn't support 99% of the modern tools that actually make functional programming useful and not just a parlor trick. JS is missing everything from ADTs (possibly the single best thing to come out of early functional languages) to a type system. There are a few bolt-on structural type systems available (like Typescript), but they still don't get you even close to the full power of modern functional languages.

tmerr 10y ago
Sure statically typed functional languages are enjoying a lot of success right now, but there are still plenty of LISPs in the playing field like Clojure that can't be discounted as parlor tricks. You might disagree with them philosophically, but it doesn't change the fact they're being used in production. What bothers me more about JS as a functional language is the lack of tail call optimization. While it's in the ES6 spec, last I heard there was some question of whether it would actually be implemented for web browsers.
- pitaj 10y ago
  It will be, and has been implemented in some browsers. The only hiccups were regarding the behavior of stack traces with TCO.
  - k__ 10y ago
    Aren't the going to ditch proper tail calls because of the stack traces? Last thing I saw was something like "continue return" as opt in for TCO
Roboprog 10y ago
OK, so "Haskell > Scheme", or some such. Any specifics beyond "ADTs", which I assume means Abstract Data Types - interfaces/polymorphism. If IDEs ever get good enough to do near complete type inference, including reading through partial function application, and perhaps an "extract/move function" refactoring that converts closures to parameters, most of the class/type bondage and discipline may look a bit like a waste in retrospect. Having worked in both static and dynamic type systems since the 80s, I've developed a bit of a "cringe" mechanism at the repetitive code that usually comes out of "strongly" typed languages. "This time it's different", but it never seems to be :-(
- wyager 10y ago
  > Any specifics beyond "ADTs", which I assume means Abstract Data Types No, I meant algebraic data types, although interfaces/typeclasses are great as well. > If IDEs ever get good enough to do near complete type inference, including reading through partial function application, I don't use any IDEs, but Haskell does this. I imagine various Haskell plugins do as well. > and perhaps an "extract/move function" refactoring that converts closures to parameters, I'm not sure why you want this so much, but it does exist. I've done this exact thing with Idris's interactive UI. > I've developed a bit of a "cringe" mechanism at the repetitive code that usually comes out of "strongly" typed languages. If there is one phrase that I would use to describe Haskell, it's "zealously anti-repetitive". If the Haskell community sees you writing the same line of code twice, they'll swoop down and beat you over the head with a well-designed typeclass until you stop repeating yourself.
  - Roboprog 10y ago
    Thanks for the response. Alas, here in "fly-over country" (Sacramento), it's all Java and some Javascript (or .NET, if you've been naughty). There's scarcely any Scala, let alone Haskell work to get or see here. So, my background tends to be that I'd much rather do JS than Java. The JetBrains IDE's actually do a pretty good job at analyzing JS, despite JS's assumed inferiority. One day Java the language/syntax will be dead, and I will recover from the trauma it has inflicted upon me the last 10 years or so :-) Fortunately, BS-CS programs still taught other languages beside C -> C++ -> Java in the early 80s, so I at least got to learn some Common Lisp back then (among other things), though not Scheme. Consequently, I'd like to move on from 1960s tech (e.g. - Simula 67) to 70s tech (e.g. - Scheme). Never learned me a Haskell yet. I suppose I should since it's got interesting stuff like currying built into the language itself rather than duct-taped on the side.
baron816 10y ago
Just exposing people to a few basic patterns from functional programming will 1) encourage them to learn a real functional programming and 2) help them write better code. Learning Haskell or Clojure or something is a big task, especially if you're doing it just because you're curious what all this functional programming is about. Everyone understand JavaScript, so being exposed to functional programming there is not a big deal. And I love writing JavaScript with a bit of a functional lean to it. I think it makes it much easier to reason about the code. Of course it's not purely functional, but it's still better than if I wrote it the way many people do.
- wyager 10y ago
  Or, alternatively, they just say "Hmm, this functional programming stuff doesn't seem very interesting or useful at all. Totally overhyped. Well, back to working with Blub." "Functional" JavaScript is better than regular JavaScript in the same way that bloodletting is better than homeopathy; not much. Perhaps you've fallen into the same trap I'm talking about; do you think you're reaping any significant benefit from functional programming when you apply these sorts of practices to your JavaScript code?
  - baron816 10y ago
    One way or another, we're stuck with JS, so we have to use it and hopefully use it in the best way possible. There are genuinely good aspects to it and if you know what you're doing, you can write in a way that's easy for others to read and understand. Including certain functional patterns is part of that, and avoiding stuff that JS is terrible at, like "this", is another.
- Nekorosu 10y ago
  Clojure(Script) is easy to learn. Especially if you compare it to Haskell. The core of the language is quite simple but leaning standard libraries will take time. This is a good place to start http://clojurescriptkoans.com http://clojurescriptkoans.com
- catnaroek 10y ago
  > Everyone understand JavaScript, so being exposed to functional programming there is not a big deal. (GHC) Haskell and Clojure are pretty big languages, so it's not surprising that learning them requires a lot of effort, but are you seriously suggesting that learning JavaScript (all quirks included) is easier than learning Scheme or Standard ML (all quirks included)? I've honestly tried to learn JavaScript (in depth, not just whipping something together by gluing libraries foo, bar, qux), but several parts of its semantics continue to baffle me. Like “this”.
bbcbasic 10y ago
Upvoted because I think this is so spot on. Technically any language that lets you pass functions and capture variables is functional, but you ain't going to learn the beauty of FP from JS.
zdragnar 10y ago
You can easily get runtime ADTs from libraries like tcomb and folktale. While you lose out on some tooling, you gain advantages such as ad-hoc types and boundary checking (I.e. Ajax responses), as well as metadata (in the case of tcomb) for things like automated form generation and validation.

by wyager 10y ago

tmerr 10y ago

Sure statically typed functional languages are enjoying a lot of success right now, but there are still plenty of LISPs in the playing field like Clojure that can't be discounted as parlor tricks. You might disagree with them philosophically, but it doesn't change the fact they're being used in production. What bothers me more about JS as a functional language is the lack of tail call optimization. While it's in the ES6 spec, last I heard there was some question of whether it would actually be implemented for web browsers.

pitaj 10y ago
It will be, and has been implemented in some browsers. The only hiccups were regarding the behavior of stack traces with TCO.
- k__ 10y ago
  Aren't the going to ditch proper tail calls because of the stack traces? Last thing I saw was something like "continue return" as opt in for TCO

Roboprog 10y ago

OK, so "Haskell > Scheme", or some such. Any specifics beyond "ADTs", which I assume means Abstract Data Types - interfaces/polymorphism. If IDEs ever get good enough to do near complete type inference, including reading through partial function application, and perhaps an "extract/move function" refactoring that converts closures to parameters, most of the class/type bondage and discipline may look a bit like a waste in retrospect. Having worked in both static and dynamic type systems since the 80s, I've developed a bit of a "cringe" mechanism at the repetitive code that usually comes out of "strongly" typed languages. "This time it's different", but it never seems to be :-(

wyager 10y ago
> Any specifics beyond "ADTs", which I assume means Abstract Data Types No, I meant algebraic data types, although interfaces/typeclasses are great as well. > If IDEs ever get good enough to do near complete type inference, including reading through partial function application, I don't use any IDEs, but Haskell does this. I imagine various Haskell plugins do as well. > and perhaps an "extract/move function" refactoring that converts closures to parameters, I'm not sure why you want this so much, but it does exist. I've done this exact thing with Idris's interactive UI. > I've developed a bit of a "cringe" mechanism at the repetitive code that usually comes out of "strongly" typed languages. If there is one phrase that I would use to describe Haskell, it's "zealously anti-repetitive". If the Haskell community sees you writing the same line of code twice, they'll swoop down and beat you over the head with a well-designed typeclass until you stop repeating yourself.
- Roboprog 10y ago
  Thanks for the response. Alas, here in "fly-over country" (Sacramento), it's all Java and some Javascript (or .NET, if you've been naughty). There's scarcely any Scala, let alone Haskell work to get or see here. So, my background tends to be that I'd much rather do JS than Java. The JetBrains IDE's actually do a pretty good job at analyzing JS, despite JS's assumed inferiority. One day Java the language/syntax will be dead, and I will recover from the trauma it has inflicted upon me the last 10 years or so :-) Fortunately, BS-CS programs still taught other languages beside C -> C++ -> Java in the early 80s, so I at least got to learn some Common Lisp back then (among other things), though not Scheme. Consequently, I'd like to move on from 1960s tech (e.g. - Simula 67) to 70s tech (e.g. - Scheme). Never learned me a Haskell yet. I suppose I should since it's got interesting stuff like currying built into the language itself rather than duct-taped on the side.

baron816 10y ago

Just exposing people to a few basic patterns from functional programming will 1) encourage them to learn a real functional programming and 2) help them write better code. Learning Haskell or Clojure or something is a big task, especially if you're doing it just because you're curious what all this functional programming is about. Everyone understand JavaScript, so being exposed to functional programming there is not a big deal. And I love writing JavaScript with a bit of a functional lean to it. I think it makes it much easier to reason about the code. Of course it's not purely functional, but it's still better than if I wrote it the way many people do.

wyager 10y ago
Or, alternatively, they just say "Hmm, this functional programming stuff doesn't seem very interesting or useful at all. Totally overhyped. Well, back to working with Blub." "Functional" JavaScript is better than regular JavaScript in the same way that bloodletting is better than homeopathy; not much. Perhaps you've fallen into the same trap I'm talking about; do you think you're reaping any significant benefit from functional programming when you apply these sorts of practices to your JavaScript code?
- baron816 10y ago
  One way or another, we're stuck with JS, so we have to use it and hopefully use it in the best way possible. There are genuinely good aspects to it and if you know what you're doing, you can write in a way that's easy for others to read and understand. Including certain functional patterns is part of that, and avoiding stuff that JS is terrible at, like "this", is another.
Nekorosu 10y ago
Clojure(Script) is easy to learn. Especially if you compare it to Haskell. The core of the language is quite simple but leaning standard libraries will take time. This is a good place to start http://clojurescriptkoans.com http://clojurescriptkoans.com
catnaroek 10y ago
> Everyone understand JavaScript, so being exposed to functional programming there is not a big deal. (GHC) Haskell and Clojure are pretty big languages, so it's not surprising that learning them requires a lot of effort, but are you seriously suggesting that learning JavaScript (all quirks included) is easier than learning Scheme or Standard ML (all quirks included)? I've honestly tried to learn JavaScript (in depth, not just whipping something together by gluing libraries foo, bar, qux), but several parts of its semantics continue to baffle me. Like “this”.

bbcbasic 10y ago

Upvoted because I think this is so spot on. Technically any language that lets you pass functions and capture variables is functional, but you ain't going to learn the beauty of FP from JS.

zdragnar 10y ago

You can easily get runtime ADTs from libraries like tcomb and folktale. While you lose out on some tooling, you gain advantages such as ad-hoc types and boundary checking (I.e. Ajax responses), as well as metadata (in the case of tcomb) for things like automated form generation and validation.