| Is this written from a different time line were TypeScript doesn't exist? I have a long history of doing FP in a bunch of the traditional FP languages (Scheme/Haskell/etc). Ended up working at a young startup with equally young employees awhile back and was sort of surprised to see that the long heralded fantasy of cranky FP enthusiasts has, for better or worse, come true in Type Script. I saw a generation of new programmers truly doing type-driven development and using a range of functional programming techniques without them even realizing that this was a big thing. Funnily enough they were terrified of anything resembling object oriented programming. If the word "class" appeared in the code base (their was some Python), they would quietly walk away. What I saw was also incredible because these, largely junior, programmers were using types for exactly the thing old-Haskell people had hoped they would. Things would ship to prod lightning fast as all engineers had to do was make sure the types all lined up and the compiler was happy and they would send the PR off! But then I saw the downside: these type-happy programmers almost never tested anything. I'm not talking about formal unit tests or integration tests, some of those existed. I mean these were programmers that had entirely lost (or maybe never had) the ability to play around with the code that they just wrote and make sure it worked. I kid you not, "print debugging" was viewed as some advanced technique to do in emergency situations. When bugs were introduced to prod I would ask "did this work when you ran it locally?" only to be met with quizzical stares. If it pasted the type check it was good to go. It also had the negative consequence of inadvertently discouraging abstraction in favor of just adding more complexity to your existing types. Because refactoring code takes time and the entire point of the type check doing all your thinking is to ship fast. All that said, I'd much rather work with that code base than one made by a similarly proficient team in say Ruby. There are tons of skilled (and less skilled) functional programmers out there. The real problem is if you're looking for both highly competent programmers who also happened to be hung up on a particular niche language. I'm sure there are plenty of excellent "Gooby" engineers out there, but they likely choose jobs based on other factors than the language being used. |
The fear of OOP is a problem though. I've encountered some really bad TypeScript/JS codebases that were just piles of top level functions for everything. The meme that OOP is bad is really damaging.