3 ms·

> usage of == should be preferred and === should only be a last option. But to understand why I make that claim, you have to actually learn types, and the way t

> usage of == should be preferred and === should only be a last option. But to understand why I make that claim, you have to actually learn types, and the way they’re converted: coercion. This might be the most irresponsible thing I've heard a JS expert say in a while. If you are competent enough to say, write a book on JS then maybe you can keep the cognitive wherewithal to track your states getting coerced left and right into totally different types etc. If you are a mere mortal like me, you want to pin everything you can down behind strong data contracts and know that they are going to stay what you set them at. When I write code, I want to communicate intent. When I assert that this var should definitely be of type `bool|string|object|array` etc. I give the person reading my code one less thing to have to keep in their head.

Fannon 7y ago
Thanks for formulating this. It seems to me that there are two very diffent kind of programmer mindsets that are heavily in conflict with each other. Some programmers want to write sophisticated (and sometimes very concise) code that requires deep understanding of the programming and sometimes reads like a "programming puzzle game" / Interview trick question. Then there are the pragmatic types, which prefer simple code with a reductionalist approach. The code is easy to read but it is often not very generic and tends to get longer / repeated. I can also see why Kyle Simpson doesn't like TypeScript, because it fits more the latter mindset. I've also seen competent and productive programmers of both types. Has anyone experiences how those different approaches go together in a single team? To me it seems very difficult to come to a compromise or agreement here.
- vikingcaffiene 7y ago
  I have. Worked with a person who is one of the most talented developers I’ve ever worked with. His code was very much to the former “puzzle” approach you mention (versus my pragmatic approach). He used all the JS features and his code was very clever. Sadly, no one else on the team could make heads or tails of it and he ended up being a bottleneck since he was the only one who could work on stuff he wrote. We ended up ripping it all out and rewriting it. The pragmatic approach that I championed ended up being what the team based their style guide on and the developer I mentioned came around to that point of view after seeing its benefits. It is simply easier to collaborate when you work on a cross functional team of varying competencies to make your intent clear even at the expense of conciseness.

Fannon 7y ago

Thanks for formulating this. It seems to me that there are two very diffent kind of programmer mindsets that are heavily in conflict with each other. Some programmers want to write sophisticated (and sometimes very concise) code that requires deep understanding of the programming and sometimes reads like a "programming puzzle game" / Interview trick question. Then there are the pragmatic types, which prefer simple code with a reductionalist approach. The code is easy to read but it is often not very generic and tends to get longer / repeated. I can also see why Kyle Simpson doesn't like TypeScript, because it fits more the latter mindset. I've also seen competent and productive programmers of both types. Has anyone experiences how those different approaches go together in a single team? To me it seems very difficult to come to a compromise or agreement here.

vikingcaffiene 7y ago
I have. Worked with a person who is one of the most talented developers I’ve ever worked with. His code was very much to the former “puzzle” approach you mention (versus my pragmatic approach). He used all the JS features and his code was very clever. Sadly, no one else on the team could make heads or tails of it and he ended up being a bottleneck since he was the only one who could work on stuff he wrote. We ended up ripping it all out and rewriting it. The pragmatic approach that I championed ended up being what the team based their style guide on and the developer I mentioned came around to that point of view after seeing its benefits. It is simply easier to collaborate when you work on a cross functional team of varying competencies to make your intent clear even at the expense of conciseness.