> [Javascript is] a multi-paradigm language, supporting object-oriented, imperative, and functional programming styles https://en.wikipedia.org/wiki/JavaScript
The author must have a very particular idea what "functional" means to include Clojure but not JS. That's fine, though it'd be enlightening if he shared it.
The lack of native persistent data structures means functional programs need to depend on libraries like ImmutableJS and Mori to fill in the gap, but in doing so they have to trade away language features like spread and destructuring that improve readability and minimize boilerplate, and take a hit to ease of debugging. I almost always pick up ImmutableJS or Mori for my JS projects these days despite these issues, so it's certainly not the end of the world, but whenever I work with them it's painfully clear that persistent data structures, and by extension functional programming, is a second class citizen in the context of the language.
The ecosystem issue is a much harder one to work around however. You can take every precaution to carefully craft your code to minimize side effects and manage state transitions, but there's only so much you can do if your components/visualization/networking library (mis)manages its own internal state. The situation has improved dramatically in the past few years with the advent of React/Redux, and we've experienced a functional programming renaissance with tons of great new libraries popping up that are amenable to functional paradigms, but we're only just starting to make a dent in the massive JS ecosystem, which is still overwhelmingly inadequate when it comes to dealing with mutable state and managing side effects.
All of these pain points become painfully obvious once you've worked with an ecosystem that has spawned from a functional-first language that is immutable-by-default and encourages being mindful of state and side effects (in my case, that language was Clojure and ClojureScript, but that's certainly not the only one).
Functional languages emphasize immutability. Javascript does not do this. Clojure[script] does.
Since functional programming is a programming paradigm, not a language, don't be surprised if many languages support it, just as many diverse languages support OO.
The language support generally thought necessary is first-class functions (and consequently concepts like higher-order functions). For example, Java < 8 and C# < 2.0 aren't usually considered functional.
If you think allowed mutability makes or breaks a functional language, then neither Clojure nor Clojurescript fit the definition.
Like, once you have
* first class functions that you can pass around * anonymous functions * closures over functions
you can get by. This is what enables you to create the usual higher-order function toolbox, all those nice functions that convert your code to long list of composable map/filter/reduce/zip/walk e.t.c.
I remember reading that python got here iteratively, i.e. you could pass around functions, but they needed to be defined top-level, then you had anonymous functions, but you needed to pass in variables from enclosing scope explicitly, and finally you had closures.
But I agree that fast, immutable datastructures make all of this much nicer. But not having them is not as much of a deal-breaker.
Similarily tail-call optimization. I used clojure at work while dealing with haskell on a school projects, and from that time on, I found "loop/recur" kinda ugly :-) NodeJS with --harmony actually supports it now.
Similarly, pattern matching. Don't you need to pull that as a lib in clojure as well? With destructuring this almost is a js feature.
So, I wouldn't loose much sleep over it anyway :)
I'd argue a "pure" functional language is akin to trying to write a novel on a keyboard without an "e" key. Sure, you'll eventually stumble and write "Gadsby", but there are times when being able to cheat is useful in making your code more clear and concise. When I code stuff in C++ or C#, I keep my objects immutable most of the time because it's the easiest way to rationalize the various components that way, but at the same time, when I'm doing things like handling I/O, a pure functional style gets in the way.
The only efficient way to return a brand new database that is the same as the old database plus 1 new widget is via immutable data structures.
> [It] treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data.
Javascript certainly doesn't avoid changing state or mutable data, as its two core data structures, objects and arrays, are both mutable.
I'm no newbie to FP (IMHO) but this has me perplexed now.. is there a difference between mutable and "non-immutable" ones, or do you mean to say that JS has neither immutable nor mutables ones? ;)