3 ms·

In the late 10s I worked at a startup that was not adopting Flow or TypeScript, and pushing FP using Ramda/lodash-fp seemed like a way to encourage devs to sepa

In the late 10s I worked at a startup that was not adopting Flow or TypeScript, and pushing FP using Ramda/lodash-fp seemed like a way to encourage devs to separate out data from dataflow and make things into reusable pieces. Instead of some spaghetti imperative code, we could write a bunch of small functions that work on well-known entities, and compose them up to make a procedure. In theory it was better. When the company finally came around to using TypeScript, devs could once again reason about code and data and relationships between functions without resorting to abstraction, and the FP stuff died a quick death.

SPBS 3y ago
FP-style castle of abstractions is just as bad as OO-style castle of abstractions. A "function that returns a function that returns a function that returns a..." is just as bad as an "AbstractFactoryManager that manages an AbstractFactory that produces an Abstract thing..." etc. Don't write code that is so far removed from the actual business data that it becomes hard to reason about cause and effect.
- agentultra 3y ago
  That's called indirection and I agree. Abstraction is something else entirely and is usually what you want. Think more like, "things that have provable laws." Eg: concatenating two lists results in a list that is at least as long as the longest input list, for all lists. Concatenation is the operation on lists that is the abstraction... once you have defined it you no longer have to think in terms of loops and building intermediate lists.
  - RussianCow 3y ago
    Abstraction very often leads to indirection, so I don't think "something else entirely" is an accurate description.
frfl 3y ago
It really comes down to finding the right balance and using your tools effectively. I worked at a place at was super OO heavy, multi-layer inheritance, gang-of-4 type OO patterns. And another place that was writing code in a functional manner, little to no classes unless necessary, using FP patterns in the codebase. Both were codebases were TypeScript. I think I was more effective in the second, FP, codebase than the first. But really it's more about finding the right balance. One of the flaws in either approach is you try to fit a paradigm forcefully: trying to write Java in JS/TS or trying to write Haskell in JS/TS. The TS code will be better if you understand and accept the JS/TS paradigm and apply patterns where they fit elegantly.
- claytongulick 3y ago
  I agree with this. I don't think it makes sense to be "oop" or "fp". Different problems have characteristics that lend themselves to different techniques. Difficult code based come from purists who value theory over practicality. I have a very strongly enforced "don't be clever" rule for teams I manage. Code should read like a story, good code reduces congnitive load. I've seen some chains of map, reduce, filter, etc... written by FP purists that are difficult to decipher. Good code is a love letter to the next developer.

SPBS 3y ago

FP-style castle of abstractions is just as bad as OO-style castle of abstractions. A "function that returns a function that returns a function that returns a..." is just as bad as an "AbstractFactoryManager that manages an AbstractFactory that produces an Abstract thing..." etc. Don't write code that is so far removed from the actual business data that it becomes hard to reason about cause and effect.

agentultra 3y ago
That's called indirection and I agree. Abstraction is something else entirely and is usually what you want. Think more like, "things that have provable laws." Eg: concatenating two lists results in a list that is at least as long as the longest input list, for all lists. Concatenation is the operation on lists that is the abstraction... once you have defined it you no longer have to think in terms of loops and building intermediate lists.
- RussianCow 3y ago
  Abstraction very often leads to indirection, so I don't think "something else entirely" is an accurate description.

frfl 3y ago

It really comes down to finding the right balance and using your tools effectively. I worked at a place at was super OO heavy, multi-layer inheritance, gang-of-4 type OO patterns. And another place that was writing code in a functional manner, little to no classes unless necessary, using FP patterns in the codebase. Both were codebases were TypeScript. I think I was more effective in the second, FP, codebase than the first. But really it's more about finding the right balance. One of the flaws in either approach is you try to fit a paradigm forcefully: trying to write Java in JS/TS or trying to write Haskell in JS/TS. The TS code will be better if you understand and accept the JS/TS paradigm and apply patterns where they fit elegantly.

claytongulick 3y ago
I agree with this. I don't think it makes sense to be "oop" or "fp". Different problems have characteristics that lend themselves to different techniques. Difficult code based come from purists who value theory over practicality. I have a very strongly enforced "don't be clever" rule for teams I manage. Code should read like a story, good code reduces congnitive load. I've seen some chains of map, reduce, filter, etc... written by FP purists that are difficult to decipher. Good code is a love letter to the next developer.