Interview with Kyle Simpson, author of You Don’t Know JS book series | Hacker News Reader

Interview with Kyle Simpson, author of You Don’t Know JS book series

medium.com

49 pointsfagnerbrack26 comments

For example, completely contrary to most common belief, the == operator is actually more powerful and more useful in our programs than ===, and in fact, 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. I really wish developers wouldn’t just keep parroting back “JS types are evil” like they’ve heard for years. They’re great...

This line of poor reasoning is responsible for so much lost productivity and buggy code. Even in the best case where a team is comprised of people who understand these intricacies well it still forces people to spend more time thinking about simple equality checks than necessary. The greater verbosity of === and type conversion is less mental effort.

In the real world very few people understand == and there's a good chance that even if you do whoever maintains the program you wrote won't. It's just not worth it.

This is very similar to the argument that you should use the minimum number of semicolons necessary in JS. You just need to memorize the exact syntax. It's an aesthetic argument only. It does nothing for the metrics that matter, like defect rate, maintainability, comprehension, etc.

To add to this, a problem with becoming an expert on anything is that you can start to love your understanding of the complexity of the thing and lose the objectivity necessary to evaluate the thing.

This can lead to endorsing advanced features instead of simple easily composable ones. The advanced features will be poorly adopted in the field due to not everyone being an expert.

This is probably the best single thing about golang. The language has many flaws, but this is not one of them.

I wholeheartedly disagree about your characterization of Go. There are indeed some advanced and misguided features, to wit: goroutines and channels. On the one hand, these primitives make writing some types of programs easy, but it enforces one specific model to a fault.

I appreciate the YDKJS books a lot more when he is in descriptive mode rather than prescriptive mode.

From this interview, it sounds like he agrees, but can't help giving advice sometimes.

It's to be expected from someone who deeply knows a language. And entirely ignornable. Go to Kyle for how JS works. Look at actual code from senior devs for best practice.

> 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.

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.

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.

Kyle's free and open source You Don't Know series https://github.com/getify/You-Dont-Know-JS are amazing resources for Javascript developers.

Looks like some autocorrect happened to your link: https://github.com/getify/You-Dont-Know-JS

Thanks for pointing that out, fixed.

Apparently he's recently written a book about functional programming in JavaScript. Interesting

It should be noted that while he did utter that quote, the interview being posted choose to use it as the title, likely to get the reaction it has (i.e. being shared, not for the content of the interview but more from the controversial nature of that quote.)

Also, having been following Simpson for some time, I believe him when he tried to clarify later that this wasn't from a place of ego. Rather, it's because he's written and talked so much about JavaScript that he's bound to have also forgotten a lot also.

Still, it was a poor choice of words to try to express that, and made worse by the article using that as it's headline.

> I always tell people that the only difference between me and them is that I asked more questions and didn’t stop until I found the answers

A slightly nicer quote

It's probably accurate when you really consider most people, and not most javascript programmers.

I've worked in big organizations with lots of JavaScript programmers, I've also read his JavaScript focused books and watched many of his tutorials, I believe him.

I mean, I think most people haven’t learned any JavaScript, so sure.

So, the medium article headline (I have forgottem more javascript than most people ever learn) is actually a reference to neuromancer:

"The Japanese had forgotten more neurosurgery than the Chinese had ever known"

In the book Case was trying to explain that the japanese had been studying neurosurgery for so long that they had forgotten many things which had become obsolete, an amount of knowledge which turned out to be more than the chinese had ever known.

Having read YDKJS and seen some of Mr. Simpson's talks, I do believe that he is qualified to make such a claim about himself.

Not that I don’t appreciate a good William Gibson reference, but is there a specific aspect that makes this a reference to Neuromancer?

The idiom is common and predates Neuromancer:

> "I Forgot More Than You'll Ever Know" is a number one country music single for The Davis Sisters in 1953.

https://en.wikipedia.org/wiki/I_Forgot_More_Than_You%27ll_Ev...

I guess there really isn't anything about it that makes it a reference to Neuromancer. It's just my own personal death-of-the-author interpretation; I've only seen the idiom in Neuromancer. But apparently, as you said, it is common and predates Neuromancer.

I really appreciate the country love-song context; it is both interesting and amusing.

I'm So Good That I Don't Have To Brag

https://www.youtube.com/watch?v=KXR2nvLiETU

Concerning an average of all humans, this phrase applies to anyone who ever forgot the slightest bit of JS (which is probably nearly everyone who ever learned any).

If something is so good that most people that use it daily don't get it, maybe it's not so good?

I really, really dislike that phrase.

His twitter account is fantastic, and reminds me every day what a fucked up mess Javascript is. And moreover, how amazing it is that any of this stuff that we rely on day to day works at all.

Reply on news.ycombinator.com