Piling a bunch of redundant libraries on top of each other, becoming confused, and drawing the conclusion that functional programming was the problem? Okay.
Yeah this was basically also my conclusion of the article.
If you really want to do clojure(/script) no language but clojure will give you that experience. It doesn't make functional programming in javascript an anti-pattern just because it does not become clojure.
That's much like saying that you can't do functional programming in clojure because there are no monads and proper static type checking.
Yeah, I was quite confused when reading. Semantically, Javascript is basically a crappy Scheme (first class functions, lexical closure, etc. but no macros, tail calls, call-cc, etc.), with lightweight objects and prototypical inheritance.
The functional/OO split in JS is basically whether to focus on the Scheme part and only use objects as hash tables, or whether to focus on the objects, methods and inheritance and avoid Schemey functions.
You don't need any libraries to do either. If it makes life easier to include a library (whether functional or OO or whatever) then include it; if it doesn't, then don't.
I thought tail calls were in the ES6 spec, just not implemented by all browsers or something. Node has a flag to use tail call optimization I believe.
EDIT: ES2015 specs [1]: "Some of its major enhancements include modules, class declarations, lexical block scoping, iterators and generators, promises for asynchronous programming, destructuring patterns, and proper tail calls." (emphasis mine)
JS may not be the most elegant language in the world, but it's still possible to apply some functional patterns to it without having to use a "functional" runtime/transpiler.
My draw to FP is to limit side-effects as much as possible. Personally I like to follow a message-oriented setup (stealing a play from Erlang's book) instead of shared variables. A useful lib I found on the client-side is postal.js but there are many other ways to do it.
Agreed. I was recently reminded about the broken scoping rules of old versions of IE. Also, the dev tools available today are insane compared to the ones we had in 2010 (and the ones we kind of didn't have in 2000).
Oh my, webdevelopment in the early 2000s. Back in the day we debugged with 'alert()' that was quite the experience... Compared to that the tools today are almost another world.
The article seems hopelessly tautological. One of the arguments for Clojurescript is that it "is a functional programming language," with the reasoning that this makes functional programming easier. The author then goes on to answer - and I quote - "Why isn’t it popular?" with "Not popular enough." I am thoroughly enlightened.
Functional programming in javascript is an antipattern instead use clojure. LOL if I were going to use a ??? -> js, I would at least use fable/reason. I have tried to get into lisp several times and then tried once to get into OCaml/F# and it was effortless.
11 comments
[ 4.3 ms ] story [ 17.1 ms ] threadIf you really want to do clojure(/script) no language but clojure will give you that experience. It doesn't make functional programming in javascript an anti-pattern just because it does not become clojure.
That's much like saying that you can't do functional programming in clojure because there are no monads and proper static type checking.
The functional/OO split in JS is basically whether to focus on the Scheme part and only use objects as hash tables, or whether to focus on the objects, methods and inheritance and avoid Schemey functions.
You don't need any libraries to do either. If it makes life easier to include a library (whether functional or OO or whatever) then include it; if it doesn't, then don't.
EDIT: ES2015 specs [1]: "Some of its major enhancements include modules, class declarations, lexical block scoping, iterators and generators, promises for asynchronous programming, destructuring patterns, and proper tail calls." (emphasis mine)
[1] http://www.ecma-international.org/ecma-262/6.0/ (introduction)
My draw to FP is to limit side-effects as much as possible. Personally I like to follow a message-oriented setup (stealing a play from Erlang's book) instead of shared variables. A useful lib I found on the client-side is postal.js but there are many other ways to do it.
Welcome to JS programming.