3 ms·

I feel like this gives a somewhat distorted impression of how FP in JavaScript compares to other languages. Many traditional functional programming languages ar

by chc 13y ago

I feel like this gives a somewhat distorted impression of how FP in JavaScript compares to other languages. Many traditional functional programming languages are famous for creating lots of garbage and are not pervasively immutable either. Most of the progress in those areas is fairly recent. For example, Clojure's efficient immutable data structures are based on a book published three years after JavaScript was first released. Functional programming in a language without pervasive immutability does require you to do some thinking about how you want to approach state, but this is just as true in many traditional functional languages like Scheme. As for partial() and compose(), JavaScript already includes partial() in the form of Function.prototype.bind. And the compose() function shown there does not require the slice hack AFAIK, because it never does anything to arguments except take its length and access numeric indexes — but even if it did, I mean, that function has to do allocation in Scheme too.

coolsunglasses 13y ago
>Clojure's efficient immutable data structures are based on a book HAMTs aren't unique to Clojure. unordered-containers in Haskell has them, as well as Scala, Rubinius, and C++. There's a concurrent and lock-free version too. Haskell's efficient and immutable containers library is based on papers from 1993 and 1973. Persistent Search Trees have existed as a topic of research since at least 1986. So no, JS isn't excused here.
- chc 13y ago
  I didn't say anything was unique to Clojure. I used Clojure as an example because the OP did so. And, like, for any topic, you can usually point to some earlier research and say "Hey, look, there was this one paper so it's an old thing." But Haskell 98 wasn't even in existence when JavaScript came about. These were not mainstream ideas, even to the small degree they're mainstream now. The point is that JavaScript has similar limitations to many languages that were traditionally seen as supporting the functional style well around that time, such as most of the mainstream Lisps and OCaml. The ideas the OP is faulting it for not adopting were not well-explored despite having some old papers about them. (And from looking at history, I suspect trying to add those to the rush-job that was JavaScript would have resulted in eldritch horrors the human mind cannot fathom, so it was probably an OK choice not to get all experimental.)
  - coolsunglasses 13y ago
    Haskell itself was created starting in 1990. Haskell '98 is referring to the 1998 report which was a popular standard for Haskell. It's not the first standard for Haskell nor was it the last (2010). Okasaki and Bagwell did a lot to expand and firm up knowledge on persistent data structures, but there have been persistent search trees (usable for hash-maps) for ages. Lists too.
kevingadd 13y ago
The performance of JS in the presence of functional programming patterns is still utterly miserable, even if other FP environments do suffer from the consequences of GC pressure. JS GC performs worse than the native runtimes I've used (.NET, the JVM) and you end up forced to create more GC pressure because JS has a miserable type system and poorly-factored primitives. Function.prototype.bind creates unnecessary GC pressure and performs like garbage. It's not realistic to use in any scenario where you care about performance.

by chc 13y ago

coolsunglasses 13y ago

>Clojure's efficient immutable data structures are based on a book HAMTs aren't unique to Clojure. unordered-containers in Haskell has them, as well as Scala, Rubinius, and C++. There's a concurrent and lock-free version too. Haskell's efficient and immutable containers library is based on papers from 1993 and 1973. Persistent Search Trees have existed as a topic of research since at least 1986. So no, JS isn't excused here.

chc 13y ago
I didn't say anything was unique to Clojure. I used Clojure as an example because the OP did so. And, like, for any topic, you can usually point to some earlier research and say "Hey, look, there was this one paper so it's an old thing." But Haskell 98 wasn't even in existence when JavaScript came about. These were not mainstream ideas, even to the small degree they're mainstream now. The point is that JavaScript has similar limitations to many languages that were traditionally seen as supporting the functional style well around that time, such as most of the mainstream Lisps and OCaml. The ideas the OP is faulting it for not adopting were not well-explored despite having some old papers about them. (And from looking at history, I suspect trying to add those to the rush-job that was JavaScript would have resulted in eldritch horrors the human mind cannot fathom, so it was probably an OK choice not to get all experimental.)
- coolsunglasses 13y ago
  Haskell itself was created starting in 1990. Haskell '98 is referring to the 1998 report which was a popular standard for Haskell. It's not the first standard for Haskell nor was it the last (2010). Okasaki and Bagwell did a lot to expand and firm up knowledge on persistent data structures, but there have been persistent search trees (usable for hash-maps) for ages. Lists too.

kevingadd 13y ago

The performance of JS in the presence of functional programming patterns is still utterly miserable, even if other FP environments do suffer from the consequences of GC pressure. JS GC performs worse than the native runtimes I've used (.NET, the JVM) and you end up forced to create more GC pressure because JS has a miserable type system and poorly-factored primitives. Function.prototype.bind creates unnecessary GC pressure and performs like garbage. It's not realistic to use in any scenario where you care about performance.