First thanks to Allen Wirfs-Brock for his comments on the evolution process for JavaScript. I wanted to let his ideas settle in for a couple of days before responding. #
I applaud the rule of "don't break existing code." We had the same rule in the RSS world. It was very controversial with some. They wanted to break it. That's what the big debate was about. On one side, mine, trying to maintain continuity, because I and others were developing and deploying software to users that built on RSS. We couldn't afford to change things just for the sake of change. And we had a lot at stake in preserving simplicity, because that kept the barrier to entry low. The more different ways there were to do something, the harder it would be to enter the market, and the leaders could become complacent. We've all seen how markets stagnate when the leaders are protected. I didn't want to see that happen.#
We had the same rule in the Frontier world . We called it Rule 1, and it was simply this: Don't Break Users. As a joke Rule #1a was: Don't Break Dave. That was meant to tell the team this was personal. If my code was broken, I would probably raise my voice. The rule came about because the guy who was working on the core code would routinely break the upper-level code. To him, the core was never finished, and all the work we were doing at upper levels was just to test his stuff. So he didn't really feel it. I think that's true of many other developers. They don't get that the people who build on their tech are skilled in ways they can't comprehend (and of course vice versa). That's the power of layering tech. It becomes virtually impossible without the No Breakage rule. And you can see it in the market. Good ideas from previous generations are nowhere to be found in today's systems. Because someone wiped the slate clean without any idea how much had been built on it. #
BTW there's a great story about this in Soul of a New Machine. They were shocked when they saw real people using their product. They had never imagined it, and it felt wrong to them.#
I have another rule -- "One way of doing something is better than two, no matter how much better the second way is." This is a variant of the famous XKCD cartoon, and of Postel's robustness principle. Postel says be conservative in what you send. I say one way is better than two. Applied to JavaScript, adding the arrow syntax was a mistake. It didn't add any new expressive power to the language, and it meant anyone who needs to read code (i.e. everyone who develops) now has to understand two ways of doing the same thing. Even worse, newbies now have to learn two ways, and they have to learn when to use which way, and all the explaining avoids the truth -- it really doesn't make a difference. #
"One way is better than two" is another instance of Worse Is Better. Stop trying to make it better. Because that just makes it worse. Good postulates are true from every angle. #
Another story I like to tell is when we were working on the names for things in XML-RPC the rule was we had to come up with the worst name for each element. So if you thought you had a better name, everyone would laugh. Heh, we don't want that. It's in the groundrules. 💥#
BTW, I also always use the first form for defining functions, although when I was new to JS, I sometimes used the second form. But the vast majority of my codebase uses form 1. #
Thanks for the pointer to eslint. It's on my list of things to explore. Right now I have my JS profile committed to memory. But I should formalize it. #
You know those obnoxious sites that pop up dialogs when they think you're about to leave, asking you to subscribe to their email newsletter? Well that won't do for Scripting News readers who are a discerning lot, very loyal, but that wouldn't last long if I did rude stuff like that. So here I am at the bottom of the page quietly encouraging you to sign up for the nightly email. It's got everything from the previous day on Scripting, plus the contents of the linkblog and who knows what else we'll get in there. People really love it. I wish I had done it sooner. And every email has an unsub link so if you want to get out, you can, easily -- no questions asked, and no follow-ups. Go ahead and do it, you won't be sorry! :-)