Comment by PheonixPharts
2 years ago
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.
That's not a TypeScript issue. I've encountered the same problem of not testing things properly in other languages. There's a definite mindset amongst some programmers that if it compiles and the unit tests pass, then it must work. I think a lot of less experienced devs have read too many blog posts on PL theory/testing and don't realize how many bugs are just not going to get caught by such techniques. You really do have to see something work with your own eyes and hammer it for a while by hand to know it's of a decent quality.
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.
What’s wrong with top-level functions (as opposed to methods)? Is there a meaningful difference between foo(bar) and bar.foo()?
Same reasons JS has modules that don't export everything, and for the same reason that React reinvented OOP under a different syntax with function components. Encapsulation, API design, runtimes and IDEs all work a lot better if the tools are aware of the link between the data and the code that's manipulating it.
To clarify: Are you saying they came to trust the compiler so much that they stopped doing local tests? If yes, this is an interesting point. When I toggle between Python and Java, I find the Java compiler has similar impact on me, as Python makes me so paranoid about runtime errors due to syntax.
That's a really interesting data point about your experience with TypeScript. I'm going to have to file that away as something that I'm not sure what to do with right now, but also as an interesting thought to keep in mind going forwards.