5 ms·

Totally agreed. Coworkers will hate you if you start mixing in these styles into an existing code base. If you want to do FP, go switch languages (and likely jo

Totally agreed. Coworkers will hate you if you start mixing in these styles into an existing code base. If you want to do FP, go switch languages (and likely jobs/teams) to something where the ergonomic are clear, concise, and idomatic—then the benefits become more obvious. It's a bit like teaching object-orientation through OCaml… just because you can, doesn't mean the community recommends it generally.

tmountain 4y ago
I love FP, but I wouldn’t let someone introduce these abstractions into our JavaScript code base, as they ramp up the complexity in understanding code that can be represented in a simpler fashion with the same results.
- toastal 4y ago
  A loop isn't simpler than recursion or high-order functions since it introduces state and is noisy, but most examples of JavaScript/TypeScript + FP involve heavy usage of utility libraries that aren't community standards (like a Prelude). Not to say these libraries aren't valuable or of good quality, but it's a lot to learn atop the language itself for a new hire and can lead to some library lock-in as said functions will end up all over the code. The folks that preach the libraries the most are the ones that usually want their JS/TS to look like Haskell which ends up making it impossible for outsiders to follow (so now I need to know JavaScript + TypeScript + Haskell + the weird esoteric version these people write?). And those folks should be allowed and encourage to just write some ML-flavor-to-JavaScript code instead which can often be easier to for a new hire to follow since all examples will follow community standards (wouldn't be surprised if the coders were happier writing it too).
agentultra 4y ago
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.
- toastal 4y ago
  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.
  - agentultra 4y ago
    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).
    - rileyphone 4y ago
      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.
      - rory 4y ago
        Do you know of an example snippet / article demonstrating how to do this?

tmountain 4y ago

I love FP, but I wouldn’t let someone introduce these abstractions into our JavaScript code base, as they ramp up the complexity in understanding code that can be represented in a simpler fashion with the same results.

toastal 4y ago
A loop isn't simpler than recursion or high-order functions since it introduces state and is noisy, but most examples of JavaScript/TypeScript + FP involve heavy usage of utility libraries that aren't community standards (like a Prelude). Not to say these libraries aren't valuable or of good quality, but it's a lot to learn atop the language itself for a new hire and can lead to some library lock-in as said functions will end up all over the code. The folks that preach the libraries the most are the ones that usually want their JS/TS to look like Haskell which ends up making it impossible for outsiders to follow (so now I need to know JavaScript + TypeScript + Haskell + the weird esoteric version these people write?). And those folks should be allowed and encourage to just write some ML-flavor-to-JavaScript code instead which can often be easier to for a new hire to follow since all examples will follow community standards (wouldn't be surprised if the coders were happier writing it too).

agentultra 4y ago

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.

toastal 4y ago
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.
- agentultra 4y ago
  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).
  - rileyphone 4y ago
    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.
    - rory 4y ago
      Do you know of an example snippet / article demonstrating how to do this?