Discussion on: OOP vs functional programming

you can use OO and functional techniques when it makes sense.

The article uses "vs" and supplies two distinct implementations (though the first example is largely procedural). To highlight differences it's typical to take the examples to the extreme.

Of course there is a range of possible solutions between both extremes.

You seem to prefer leaning toward the OO end of the spectrum.

My contention is that JavaScript naturally tends more towards the function-based end (not necessarily to the extreme of my "function-style" example).

by providing a referable name that can be used with TypeScript or without TypeScript (with jsdoc) and thus making code easier to understand and navigate.

// a function that takes any two arguments of the same type 
// and returns a result of that type
type Op2Args<T> = (a0: T, a1: T) => T;

const add: Op2Args<number> = (augend, addend) => augend + addend;

const sub = (minuend: number, subtrahend: number) => minuend - subtrahend;

function mult(multiplicand: number, multiplier: number) {
  return multiplicand * multiplier; 
};

function run(f: Op2Args<number>, a: number, b: number) {
  return f(a, b);
}

const runOp: (op: Op2Args<number>) => void = 
  op => run(op, 2, 3);

console.log(runOp(add));  //  5
console.log(runOp(sub));  // -1
console.log(runOp(mult)); //  6

In the above example Op2Args is a referable name - but from your past comments you don't like this because at the definition site of f it isn't obvious that either add, sub or mult might be used.

both things are equally important

As stated "minimizing moving parts" has priority (as long as all the tradeoffs are acceptable) over "encapsulating moving parts". Without minimizing the moving parts first, "accidental complexity" tends to be entombed into the encapsulation. But that is true of any approach.

For example railway programming

is considered functional because "mapping a function over a type" is extremely common in functional programming - in an OOP without first class functions you would have to "map an object over another object" where the former has to implement a method (i.e. a single method interface) the latter is requiring - with is way more convoluted.

I don't think highly polymorphic code is that normal.

Polymorphism is everywhere.

interface Node extends EventTarget {
  //...
  appendChild<T extends Node>(newChild: T): T;
  //...
}

i.e. appendChild will append anything that implements the Node interface - that could be a lot of different kinds of objects.

In the example above Op2Args makes f polymorphic.

React uses React.Component so that it can treat all your components in an identical manner - that is polymorphism in action.

Python

Guido van Rossum is anti-functional - lambda almost didn't make the cut.

All 3 implement closures very similarly - similarly like it was done in Smalltalk - a precursor to all OO dynamic languages.

Closures were devised by Peter Landin in 1964 as described in "The Mechanical Evaluation of Expressions" (lambda calculus). That is why closures are considered a "functional" feature - regardless of where they may have been adopted later.

All have OO model at its core.

If you were talking about TypeScript I would agree - it's opinionated towards class-based OO. But in the case of JavaScript I disagree and I've elaborated on that here.

While being essentially imperative the core building block of JavaScript is the function. Multiple functions can share state through a shared closure so that these functions may act as methods. That is essentially how OOP with functions works.

The object - in an "object-oriented" (but not class-based) sense - is an emergent concept via the function context - this giving a function the capability to access other values on the "object" the function was being referenced through.

The prototype chain then makes it possible to share a function across object instances (to save memory). So conceptually object instances sharing the same function across the prototype chain belong to the same "class" - but there is no class construct, only object instances.

Given the function first nature of JavaScript, OO workarounds like the Command Pattern (as in Replace Conditional Dispatcher with Command) aren't necessary - just pass a function with its attached closure.

I can't think of good example of what works well with JS but not TypeScript.

I'm referring to the lopsided "typing tax" that TypeScript imposes on "function-style" vs "class-style" (or "procedural-style") code that you yourself already commented on. If one persists on using function and closure based approaches in TypeScript one quickly finds oneself knee deep in noisy type definitions expressed in TypeScript's typing meta language. Functional languages already devised concise ways of expressing function types.

With "class-style" code you can coast on rudimentary and terse typing features for a long time before you ever have to dive into the advanced types. But making it easy to work with function and closure types wasn't a priority - despite the fact that these are core JavaScript features.

Going by the mantra "make doing the right things easy and the wrong things hard" by focusing on making "class-style" code easier to type, TypeScript reinforces the idea that "class-based object-orientation" is the "right thing" while "function-style" is the wrong thing.

TypeScript admits as much:

TypeScript began its life as an attempt to bring traditional object-oriented types to JavaScript so that the programmers at Microsoft could bring traditional object-oriented programs to the web. ... The resulting system is powerful, interesting and messy.

In 2008 Douglas Crockford wrote:

JavaScript is most despised because it isn’t some other language. If you are good in some other language and you have to program in an environment that only supports JavaScript, then you are forced to use JavaScript, and that is annoying. Most people in that situation don’t even bother to learn JavaScript first, and then they are surprised when JavaScript turns out to have significant differences from the some other language they would rather be using, and that those differences matter (JtGP, p.2).

"TypeScript the Good Parts" focuses on "class-based object-orientation" much the same way that "JavaScript the Good Parts" doesn't. In a strange twist TypeScript has become that other language that most people would rather be using so that they don't have to bother learning JavaScript first.

It's never enough to bring in a concept but not solve the tooling problem.

Oliver Steele made an interesting distinction between "Language Mavens" and "Tool Mavens" in IDE divide - he comes to the conclusion that tool-orientation comes at the cost of language features.

Ironically Java has been continually ridiculed for its need of tooling to "keep developers productive" in the face of the all the language's and ecosystem's warts. Meanwhile it's perfectly acceptable for the members of the JavaScript community to employ tool heavy build pipelines (editors requiring language servers) and constantly clamour for "better tools".