Javascript is a multi-paradigm language as are most others people are mentioning in these threads. It shows in the specification for the language too: higher-order functions, anonymous functions, Array.map/filter/reduce, etc. Like it or not the language has facilities to enable programming in a functional style.
There are advantages to this approach like enabling different styles when appropriate.
There are disadvantages as well: you rely on the discipline of the programmers or tools to catch mistakes.
But there's nothing inherently wrong about thinking of programs in terms of FP ideas. There are other ways to think about programming than in terms of program counters, control flow statements, and procedures. It's not even idiomatic Javascript to write code that way!
JS is a more functional language than most people seem to think.
The tragic thing about TFA is that it's not an article but a chapter in a long series of posts and this is just one step along the way to showing how an FP style can manage the complexities of a non-trivially large JS code base.
I won’t disagree that JavaScript isn’t multi-paradigm and you can write in a functional style, but you have to look at where the ergonomics are:
• dot, `.`, syntax on objects vs. composition/pipe operators
• no autocurry
• no ADTs or basic pattern matching
• has null + undefined but no Maybe/Option (there is null coalescing and null chaining, but it’s easy to accidentally skip)
• const can still mutate the on the object, freeze incurs a massive performance cost
• no tail-call optimization outside Safari despite being in the ECMA2015 spec
• `class` keyword existed and private methods and values now, FP is pretty anti-encapsulation
• no immutable data structures in the stdlib
• no way to prevent side effects (/* __PURE__ */ in code generation is a hack)
Can you get benefits from avoiding state/mutation and choosing composition over inheritance? Sure, but it’s nothing like being in a language where these aren’t something you can do or the default, but the only way to write code and having the tool to express it.
It's a mess for sure and you'll never get a reasonable FP language from it. You won't get a Smalltalk out of it either. Instead we get a mish-mash of ideas hashed together by a committee of people with differing backgrounds, experiences, and ideas.
... but some of those FP ideas are pretty neat and when used well can make code that is easier to maintain (for people who are familiar with the concepts).
It's actually fairly easy to get most of a Smalltalk out of Javascript. Prototypes and first-class functions form a really powerful basis for a higher language. Though, to your point, it wouldn't really still be Javascript.
True. Reasonable to me is a pretty high bar. You can write in a functional style in JS and feel it is reasonable. You might feel differently after using SML/OCaml/Haskell/etc.
There are advantages to this approach like enabling different styles when appropriate.
There are disadvantages as well: you rely on the discipline of the programmers or tools to catch mistakes.
But there's nothing inherently wrong about thinking of programs in terms of FP ideas. There are other ways to think about programming than in terms of program counters, control flow statements, and procedures. It's not even idiomatic Javascript to write code that way!
JS is a more functional language than most people seem to think.
The tragic thing about TFA is that it's not an article but a chapter in a long series of posts and this is just one step along the way to showing how an FP style can manage the complexities of a non-trivially large JS code base.