2 ms·

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 woul

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.

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.