5 ms·

Not that I'm a JS fanboy, but there are some flaws with the obvious bias presented here: 1) Strong Preference for Immutable Data: Javascript's object model isn

Not that I'm a JS fanboy, but there are some flaws with the obvious bias presented here: 1) Strong Preference for Immutable Data: Javascript's object model isn't particularly confusing: If it's not a primitive, it's a reference. That's all there is to it. Knowing this, when architecting a functional framework in JS, one should know in the various instances they need to mutate data, or copy it. 2) Recursion & Tail Call Elimination: How would one solve this problem in any other language with a stack? Memory concerns don't just exist in the browser. 3) Functional Composition: It seems like OP's main concern here is garbage collection. There are ways to manage the garbage you generate here, and, frankly, engines like V8 do an exceedingly good job at cleaning up on their own. I don't blame people for not liking Javascript, and misdirected angst like this is at least good for keeping people on their toes about the many idiosyncracies of the language, but it won't go away just because you don't like it.

cgag 13y ago
1) Being able to describe it succinctly doesn't make it simple or easy. Mutability creates huge cognitive load. Every piece of mutability state adds exponentially more possible states for you to keep in mind. 2)http://en.wikipedia.org/wiki/Tail_call http://en.wikipedia.org/wiki/Tail_call ("Tail calls are significant because they can be implemented without adding a new stack frame to the call stack.") 3) I don't know enough about implementing partial in other languages to comment on if it's more garbage than should be necessary.
- deleted 13y ago
  [deleted]
- platz 13y ago
  transpilers might be able to assist taking a tail-recursive definition and unrolling it to a more low-level construct in the resulting JS.
gargantuan 13y ago
> 2) Recursion & Tail Call Elimination: How would one solve this problem in any other language with a stack? Memory concerns don't just exist in the browser. Be honest now, did you actually read the article ;-) because it answers that exact question. --- > Languages with Tail Call Elimination will recognize this situation and basically rewrite the function into a while loop. Since this is a low-level function, we should do the same, but sometimes it's hard to know when you're recurring dangerously. --- > but it won't go away just because you don't like it. I didn't like it and it go away. Out came Dart. I like Dart. All worked out well so far.
- krapp 13y ago
  >I didn't like it and it go away. Out came Dart. I like Dart. All worked out well so far. Except that javascript hasn't gone away, but has in fact exploded exponentially in adoption to become a compile point for various languages, and almost no one and nothing actually uses Dart yet, at least not in the browser. Unless it's compiled to javascript, of course.
salmonellaeater 13y ago
The author is correct in saying that JS was not designed for functional programming. The issues they raise are real issues, and a different language design would make functional style much easier to write. The issue with immutable data is not that Javascript's model is confusing, it's that there is no way to write "this array is immutable." Without that guarantee, you can't allow multiple data structures to reference the same copy of data because the data might get modified unexpectedly. There is a similar issue with tail calls. The compiler could replace calls in tail position with jumps, but it's important that this be part of the language spec. Without a guarantee in the language spec, code that runs fine on one system may blow up with a stack overflow on another. It's impressive that JS works as well as it does when written in a style different from what it was designed for. Many languages make other styles so difficult that it's not even worth trying (looking at you, Java).
- mnemonik 13y ago
  > The issue with immutable data is not that Javascript's model is confusing, it's that there is no way to write "this array is immutable." Without that guarantee, you can't allow multiple data structures to reference the same copy of data because the data might get modified unexpectedly. FWIW, |Object.freeze| does it but unfortunately it disables some optimizations. > There is a similar issue with tail calls. The compiler could replace calls in tail position with jumps, but it's important that this be part of the language spec. Without a guarantee in the language spec, code that runs fine on one system may blow up with a stack overflow on another. Tail calls are part of ES6. Regarding the garbage point brought up by the OP, with regards to point-free programming: generational gc makes it so that short lived objects are super cheap; I suspect it isn't a bottleneck in 99% of use cases and in the remaining cases you can refactor your code appropriately. Agreed, of course, that if JS were designed to be functional from the ground up it would make coding in the paradigm a lot easier. Pretty much a tautology.
zoomerang 13y ago
1) The Point of using immutable data structures is that one doesn't have to worry about when it's safe to mutate and when a copy is needed. You only ever pass around immutable data. Since Javascript does not have data structures that facilitate immutability, this is a major pain point. Even if you're not writing code in an FP style, you should still be avoiding mutability as much as possible. 2) Tail call elimination is supported in plenty of languages, and is pretty much essential for proper FP. Mind you it's still useful in imperative code as well, and most C/C++ compilers will do the optimization when provably safe. 3) V8 garbage collection is terrible. Creating lots of small object copies has a massive overhead (Compared with, say, the JVM, which has virtually no overhead)
- mraleph 13y ago
  > 3) V8 garbage collection is terrible. Creating lots of small object copies has a massive overhead (Compared with, say, the JVM, which has virtually no overhead) Care to elaborate on this, what kind of GC overhead are you seeing when creating small object copies?
bsder 13y ago
> 1) Strong Preference for Immutable Data: Javascript's object model isn't particularly confusing: If it's not a primitive, it's a reference. No, everything is ALWAYS a reference. This is, in fact, enshrined in the ECMAScript standard. Everything is a reference, and gets passed to GetValue() when required. Now, some of the JIT's do a phenomenal job of backing this out, but it's always a hazard. There is a reason that the newer versions of ECMAScript are trying to specify constant type variables and immutability in globals.

cgag 13y ago

1) Being able to describe it succinctly doesn't make it simple or easy. Mutability creates huge cognitive load. Every piece of mutability state adds exponentially more possible states for you to keep in mind. 2)http://en.wikipedia.org/wiki/Tail_call http://en.wikipedia.org/wiki/Tail_call ("Tail calls are significant because they can be implemented without adding a new stack frame to the call stack.") 3) I don't know enough about implementing partial in other languages to comment on if it's more garbage than should be necessary.

deleted 13y ago
[deleted]
platz 13y ago
transpilers might be able to assist taking a tail-recursive definition and unrolling it to a more low-level construct in the resulting JS.

gargantuan 13y ago

> 2) Recursion & Tail Call Elimination: How would one solve this problem in any other language with a stack? Memory concerns don't just exist in the browser. Be honest now, did you actually read the article ;-) because it answers that exact question. --- > Languages with Tail Call Elimination will recognize this situation and basically rewrite the function into a while loop. Since this is a low-level function, we should do the same, but sometimes it's hard to know when you're recurring dangerously. --- > but it won't go away just because you don't like it. I didn't like it and it go away. Out came Dart. I like Dart. All worked out well so far.

krapp 13y ago
>I didn't like it and it go away. Out came Dart. I like Dart. All worked out well so far. Except that javascript hasn't gone away, but has in fact exploded exponentially in adoption to become a compile point for various languages, and almost no one and nothing actually uses Dart yet, at least not in the browser. Unless it's compiled to javascript, of course.

salmonellaeater 13y ago

The author is correct in saying that JS was not designed for functional programming. The issues they raise are real issues, and a different language design would make functional style much easier to write. The issue with immutable data is not that Javascript's model is confusing, it's that there is no way to write "this array is immutable." Without that guarantee, you can't allow multiple data structures to reference the same copy of data because the data might get modified unexpectedly. There is a similar issue with tail calls. The compiler could replace calls in tail position with jumps, but it's important that this be part of the language spec. Without a guarantee in the language spec, code that runs fine on one system may blow up with a stack overflow on another. It's impressive that JS works as well as it does when written in a style different from what it was designed for. Many languages make other styles so difficult that it's not even worth trying (looking at you, Java).

mnemonik 13y ago
> The issue with immutable data is not that Javascript's model is confusing, it's that there is no way to write "this array is immutable." Without that guarantee, you can't allow multiple data structures to reference the same copy of data because the data might get modified unexpectedly. FWIW, |Object.freeze| does it but unfortunately it disables some optimizations. > There is a similar issue with tail calls. The compiler could replace calls in tail position with jumps, but it's important that this be part of the language spec. Without a guarantee in the language spec, code that runs fine on one system may blow up with a stack overflow on another. Tail calls are part of ES6. Regarding the garbage point brought up by the OP, with regards to point-free programming: generational gc makes it so that short lived objects are super cheap; I suspect it isn't a bottleneck in 99% of use cases and in the remaining cases you can refactor your code appropriately. Agreed, of course, that if JS were designed to be functional from the ground up it would make coding in the paradigm a lot easier. Pretty much a tautology.

zoomerang 13y ago

1) The Point of using immutable data structures is that one doesn't have to worry about when it's safe to mutate and when a copy is needed. You only ever pass around immutable data. Since Javascript does not have data structures that facilitate immutability, this is a major pain point. Even if you're not writing code in an FP style, you should still be avoiding mutability as much as possible. 2) Tail call elimination is supported in plenty of languages, and is pretty much essential for proper FP. Mind you it's still useful in imperative code as well, and most C/C++ compilers will do the optimization when provably safe. 3) V8 garbage collection is terrible. Creating lots of small object copies has a massive overhead (Compared with, say, the JVM, which has virtually no overhead)

mraleph 13y ago
> 3) V8 garbage collection is terrible. Creating lots of small object copies has a massive overhead (Compared with, say, the JVM, which has virtually no overhead) Care to elaborate on this, what kind of GC overhead are you seeing when creating small object copies?

bsder 13y ago

> 1) Strong Preference for Immutable Data: Javascript's object model isn't particularly confusing: If it's not a primitive, it's a reference. No, everything is ALWAYS a reference. This is, in fact, enshrined in the ECMAScript standard. Everything is a reference, and gets passed to GetValue() when required. Now, some of the JIT's do a phenomenal job of backing this out, but it's always a hazard. There is a reason that the newer versions of ECMAScript are trying to specify constant type variables and immutability in globals.