Seems like they included extra parameters in map since they forgot to include a fold! Running totals are perfect for fold, for differences, use zipWith.
But, JavaScript is rather functional. I've heard it described as "lisp in C's clothing". Douglas Crockford uses monads in JS (intentionally) and gave an interesting yet hard to follow introduction to JS monads not too long ago. I'd like to see the functional side of JS emphasized in the next iteration.
It's fine to say that Javascript is functional, but:
>I've heard it described as "lisp in C's clothing"
I hear this line all the time, and it always irritates me. Saying that Javascript is Lisp-like just because it's somewhat functional is like saying that it's like Java because it's "object-oriented", even though there are a number of key differences (the use of "this", the prototypical inheritance model, runtime checks vs. static checks with late binding, etc.) It's worse, because it's rather trivial to force Javascript to behave somewhat like Java, but there's no way to force Javascript to exemplify the defining characteristics of a Lisp[0].
The nature of Lisp has nothing to do with lambdas and closures, mapcars and reduces - the phrase 'Lisp in C's clothing' doesn't even make sense, because the nature of Lisp cannot exist without an s-expression-based grammar[1]. Even though Lisp is known as a functional language, the defining characteristics of Lisp have nothing to do with it being functional.
[0] Perhaps a better analogy would be comparing it to JVM languages on the basis of the grammar, even though the two are completely orthogonal - Javascript isn't intended to run on the JVM, and while you can cross-translate code between Javascript and JVM languages and fake compatibility this way, that ability has very little do do with the defining characteristics of Javascript as a language.
[1] That doesn't mean you need to have parentheses; the grammar simply needs to be homomorphic with s-expressions, which leaves a great deal of flexibility. Javascript, however, does not make the cut.
Why do people keep incorrectly insisting that JavaScript is "functional" or "Scheme-like"? It is neither.
Merely having anonymous functions does not make a language "functional". JavaScript does not encourage the use of pure functions. It does not encourage the use of recursion. It does not encourage immutability. It does not have a robust, sensible type system. It does not encourage currying.
It's pretty clear that JavaScript is inherently not a functional programming language. It goes against functional programming techniques in almost all respects, especially when it comes to JavaScript code that's out in the wild.
Doug’s talk was hard to follow because he didn’t give an adequate explanation. Not because he’s subject to some curse of the monad, but because he evidently did not understand the topic well enough.
Haskell is so different from JS that is impossible to faithfully translate a monad into JS. It is like trying translate a Haiku from Japanese to English.
Maybe if he called his thing a Jonad, and explained how it was inspired by the monad's "executable semicolon" aspect, it would have been better.
Comments
Seems like they included extra parameters in map since they forgot to include a fold! Running totals are perfect for fold, for differences, use zipWith.
But, JavaScript is rather functional. I've heard it described as "lisp in C's clothing". Douglas Crockford uses monads in JS (intentionally) and gave an interesting yet hard to follow introduction to JS monads not too long ago. I'd like to see the functional side of JS emphasized in the next iteration.
It's fine to say that Javascript is functional, but:
>I've heard it described as "lisp in C's clothing"
I hear this line all the time, and it always irritates me. Saying that Javascript is Lisp-like just because it's somewhat functional is like saying that it's like Java because it's "object-oriented", even though there are a number of key differences (the use of "this", the prototypical inheritance model, runtime checks vs. static checks with late binding, etc.) It's worse, because it's rather trivial to force Javascript to behave somewhat like Java, but there's no way to force Javascript to exemplify the defining characteristics of a Lisp[0].
The nature of Lisp has nothing to do with lambdas and closures, mapcars and reduces - the phrase 'Lisp in C's clothing' doesn't even make sense, because the nature of Lisp cannot exist without an s-expression-based grammar[1]. Even though Lisp is known as a functional language, the defining characteristics of Lisp have nothing to do with it being functional.
[0] Perhaps a better analogy would be comparing it to JVM languages on the basis of the grammar, even though the two are completely orthogonal - Javascript isn't intended to run on the JVM, and while you can cross-translate code between Javascript and JVM languages and fake compatibility this way, that ability has very little do do with the defining characteristics of Javascript as a language.
[1] That doesn't mean you need to have parentheses; the grammar simply needs to be homomorphic with s-expressions, which leaves a great deal of flexibility. Javascript, however, does not make the cut.
Why do people keep incorrectly insisting that JavaScript is "functional" or "Scheme-like"? It is neither.
Merely having anonymous functions does not make a language "functional". JavaScript does not encourage the use of pure functions. It does not encourage the use of recursion. It does not encourage immutability. It does not have a robust, sensible type system. It does not encourage currying.
It's pretty clear that JavaScript is inherently not a functional programming language. It goes against functional programming techniques in almost all respects, especially when it comes to JavaScript code that's out in the wild.
"JavaScript does not encourage the use of pure functions."
Neither does Lisp.
"It does not encourage the use of recursion."
Neither does Lisp. (Common Lisp has no tail recursion in the spec.)
"It does not encourage immutability."
Neither does Lisp. (Actually, ES5 does have pretty powerful primitives for immutability, Object.freeze for example.)
"It does not have a robust, sensible type system."
If you mean static typing, neither does Lisp.
"It does not encourage currying."
Neither does Lisp.
sensible type system means you cannot add string and numbers.
Functional language != ML-family language.
Yes, but we can also say that functional language != Lisp-like language, and Javascript may be functional, but it is not Lisp-like.
You mean reduce()?
https://developer.mozilla.org/en-US/docs/JavaScript/Referenc...
Doug’s talk was hard to follow because he didn’t give an adequate explanation. Not because he’s subject to some curse of the monad, but because he evidently did not understand the topic well enough.
Haskell is so different from JS that is impossible to faithfully translate a monad into JS. It is like trying translate a Haiku from Japanese to English.
Maybe if he called his thing a Jonad, and explained how it was inspired by the monad's "executable semicolon" aspect, it would have been better.