Interesting article though it feels a bit incomplete. The writer very briefly introduces this concept of a "reality moment" , gives an example and that's that. The example is interesting and the concept rings true; I'd like to see more time spent discussing the concept in and of itself.<p>The only time I remember seeing this addressed outside of a "programmers are bad at estimating tasks so do x to get better estimates" context was a post by Jeff Atwood about the tendency of programmers to look at something like StackOverflow and see, basically, two CREATE TABLE statements[1]. The reality moment, then, sounds like the moment one sees past that "weekend worth of coding". A bit more fleshing out, maybe with an examination of why we think this way would be a great read.<p>[1]: <a href="http://blog.codinghorror.com/code-its-trivial/" rel="nofollow">http://blog.codinghorror.com/code-its-trivial/</a>
<i>We need creativity mixed with discipline to make a difference here.</i><p>Or we could pick a non-insane language to standardize on.<p>Even better, we could pick a non-insane <i>bytecode</i> to standardize on.
As a compiler developer I honestly shudder reading this. From the last example:<p>> $ node<p>> "5" + "1"<p>> '51'<p>> "5" - "1"<p>> 4<p>How is this in anyway reasonable behavior? '+' is string concatenation but '-' is interpret these strings as numbers and perform arithmetic?<p>Does the principle of least surprise apply here?
> But the usage of "===" is fairly uncommon in most PHP programs.<p>I don't code PHP anymore, but the use of "===" has been standard practice for ages, and checking for it fully automated.<p>It's one of the many areas in which uninformed people like to criticize PHP for bad practices that in reality have been left behind a long time ago and are only still supported by the language for backward compatibility reasons.
I only have experience in dynamic languages. I don't get the point of the article? Is the article implying type coercion is bad because its inefficient in terms of CPU cycles? In a decade of programming in dynamic languages, I've never had string comparison be a bottleneck. It is usually IO that is the bottleneck, and the trade off is that by using dynamic languages like JS it becomes easy to make your IO non blocking. If you really have some logic that needs to compare millions of strings, you could always write that algorithm in a static compiled language, and shell out to it from your dynamic language.
12 years ago, I was working on a PHP library to parse XMLRPC requests, and I ran into it's numeric type slipperiness in a painful way. I was (naively) using PHP's eval to parse a decimal numeric string.<p>I noticed what seemed like random numeric errors in a random subset of RPCs. It turned out, after what seemed like eons of investigation, that some clients were stringifying decimal integers with leading zeros, which made PHP interpret them as octal numbers, and hence the random seeming errors.<p>Having come from a strongly-typed-language background (C/C++/Java), that was a major learning experience about the caveats of weakly typed languages.