Most of the weirdness comes from being designed for the web, and specifically for working with forms. The value of a form field will always be a string, which is a simple and straightforward idea, but then the trouble showed up when we tried to make it more convenient to work that way.
Actually, most of the weirdness comes from having been originally designed in a matter of 10 days by a single engineer working to accommodate a tight release schedule.
I mean, do you think that has more explanatory power though? The type coercion rules are actually more elaborate with == than necessary for equality checking, because it was intended as a clever convenience for working with strings. If it was really all about the short timeline, wouldn’t you just skip that and do a more straightforward equality comparison, like the algorithm that === implements?
Besides, it’s not like everything in the language was conceived and implemented in those 10 days. The language has been evolving steadily since then. I’m not even sure if the modern == comparison algorithm worked that way in the first iteration.
Personally, I find it more useful to understand the context that lets me say “that’s a quirky consequence of a sensible principle,” rather than blaming it on the “ten days” legend generically.
I think the “ten days” explanation has the merit of being charitable, because it implies that Brendan Eich wouldn’t have made such short-sighted design choices under more favorable circumstances.
(I do not believe that it’s a “sensible principle” to treat text as such a fundamental form of data that a basic language feature like the equality operator should be entirely shaped around it. Surely the consequences of building an entire language around text manipulation should be apparent by considering how awkward Posix-style shells are for any nontrivial scripts.)
Well… The circumstances were that he was asked to whip up a little scripting language, that felt a little like Java and a little like Scheme, which could be used to add simple manipulations and interactions to web pages. Specifically to web pages. Not webservers, mobile apps, databases, banking systems, physics simulations, robotics… Only web pages. And nobody had even conceived yet of something like Google Sheets-- It was simple HTML forms and DOM manipulation.
IMO in that context, it makes alot of sense. I think it was probably still the wrong decision-- definitely with the benefit of hindsight, and quite possibly even at the time, even in that narrow context. Way more trouble than it’s worth.
But it’s beneficial to know that there was a principled (if misguided) reason behind it, that ties into the nature and history of the language-- It’s not simply “dude was in a hurry and not thinking.” Both are kinda true, but the former perspective helps us understand something useful, whereas the latter doesn’t get us anywhere interesting.
Most of the weirdness comes from being designed for the web, and specifically for working with forms. The value of a form field will always be a string, which is a simple and straightforward idea, but then the trouble showed up when we tried to make it more convenient to work that way.
Actually, most of the weirdness comes from having been originally designed in a matter of 10 days by a single engineer working to accommodate a tight release schedule.
I mean, do you think that has more explanatory power though? The type coercion rules are actually more elaborate with == than necessary for equality checking, because it was intended as a clever convenience for working with strings. If it was really all about the short timeline, wouldn’t you just skip that and do a more straightforward equality comparison, like the algorithm that === implements?
Besides, it’s not like everything in the language was conceived and implemented in those 10 days. The language has been evolving steadily since then. I’m not even sure if the modern == comparison algorithm worked that way in the first iteration.
Personally, I find it more useful to understand the context that lets me say “that’s a quirky consequence of a sensible principle,” rather than blaming it on the “ten days” legend generically.
I think the “ten days” explanation has the merit of being charitable, because it implies that Brendan Eich wouldn’t have made such short-sighted design choices under more favorable circumstances.
(I do not believe that it’s a “sensible principle” to treat text as such a fundamental form of data that a basic language feature like the equality operator should be entirely shaped around it. Surely the consequences of building an entire language around text manipulation should be apparent by considering how awkward Posix-style shells are for any nontrivial scripts.)
Well… The circumstances were that he was asked to whip up a little scripting language, that felt a little like Java and a little like Scheme, which could be used to add simple manipulations and interactions to web pages. Specifically to web pages. Not webservers, mobile apps, databases, banking systems, physics simulations, robotics… Only web pages. And nobody had even conceived yet of something like Google Sheets-- It was simple HTML forms and DOM manipulation.
IMO in that context, it makes alot of sense. I think it was probably still the wrong decision-- definitely with the benefit of hindsight, and quite possibly even at the time, even in that narrow context. Way more trouble than it’s worth.
But it’s beneficial to know that there was a principled (if misguided) reason behind it, that ties into the nature and history of the language-- It’s not simply “dude was in a hurry and not thinking.” Both are kinda true, but the former perspective helps us understand something useful, whereas the latter doesn’t get us anywhere interesting.
TBF he probably had know way of knowing that the language he was creating would one day end up being as popular as it is now.
I guess the moral of the story is that you can never really predict what long term consequences your decisions might have down the road.
What software isn’t?