Ask HN: Are there any “golden calfs” tools in your field that rub you wrong?
Do you ever feel like you're taking crazy pills for being the only person who doesn't love some very popular tool within your industry? What tool is it, and what industry?
What should people know about X over-hyped software/framework/tool/design-pattern/etc?
10 comments
[ 0.37 ms ] story [ 66.0 ms ] threadAt this point, I just use git and a process manager and I've not had any issues at all.
Mine is Typescript. I know -- for a fact -- that its generic system is limiting and puts a glass ceiling on the type complexity of projects. I've run into this ceiling multiple times creating a front/back-end api system that takes table defining interfaces, and extrapolates on their functionality. I've also run into it creating tools for general object mutations (deep merge for instance).
And comically enough, I managed to run into this ceiling on my first week of usage because I was coming from a vanilla-js background and using design patterns that do not get along with typescript at all.
But in none of these cases am I the only person. Far from it. I'm one of a quiet majority facing a minority of loud zealots.
Note well: Lisp and Haskell are reasonable languages in which one can be quite productive. My issue isn't with the languages per se; it's with the zealots. (I would probably feel the same about Rust, but I haven't bumped heads with as many Rust zealots.)
What should people know? X is useful. X also has flaws. There are other ways to go about it that are also useful, and also have (perhaps different) flaws.
Functional programming in particular was one I got to be singled out for recognizing its weak spots.
Not a fan of basically anything proprietary / closed source / patent-encumbered either, which is a group that probably includes a lot of popular "stuff". On that note, I don't use any Apple products, as I fundamentally disapprove of their "walled garden" ecosystem approach.
It makes the development experience terrible, introduces a new set of bugs and failure modes you have to consider, and is unnecessary in the vast majority of cases.
Maybe there are some people that legitimately enjoy dealing with this complexity, but for me engineering is simply a tool to solve clients' business problems so I can get paid, and the least engineering I have to do (and my client has to maintain down the line) the better.
I've ranted about this before: https://news.ycombinator.com/item?id=28025934 and https://news.ycombinator.com/item?id=22877650.