tag:blogger.com,1999:blog-1078898499337496912.post5252410867450151227..comments2017-08-08T21:42:12.503-07:00Comments on jMar's Blog: Understanding Loose Typing in JavaScriptJeremy Martinhttp://www.blogger.com/profile/03514319709844297772noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-1078898499337496912.post-58891178142148273782014-01-22T04:26:44.675-08:002014-01-22T04:26:44.675-08:007 + 7 + 7; // = 21
7 + 7 + &quot;7&quot;; // = 147...<i>7 + 7 + 7; // = 21<br />7 + 7 + &quot;7&quot;; // = 147<br />&quot;7&quot; + 7 + 7; // = 777<br /><br />In the examples above, arithmetic is carried out as normal (left to right) until a String is encountered. From that point forward, all entities are converted to a String and then concatenated.</i><br /><br />Might be useful to mention that the arithmetic is carried out until a string is encountered only if you&#39;re using the + operator.<br /><br />&quot;37&quot; + 7 //results in &quot;377&quot;<br />&quot;37&quot; - 7 //results in 30Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1078898499337496912.post-48733765006064098502014-01-18T14:47:27.362-08:002014-01-18T14:47:27.362-08:00Thanks for the examples and walk through.
Also, i...Thanks for the examples and walk through.<br /><br />Also, in your closing statement, the correct word would be &quot;ensure&quot;.<br /><br />1.<br />make certain that (something) shall occur or be the case.<br />&quot;the client must ensure that accurate records be kept&quot;<br />synonyms: make sure, make certain, see to it;Jeremiah Deaseyhttps://www.blogger.com/profile/02660684571990041630noreply@blogger.comtag:blogger.com,1999:blog-1078898499337496912.post-33176437562809312942013-04-17T10:00:07.827-07:002013-04-17T10:00:07.827-07:00&quot;Loose typing means that variables are declar...<i>&quot;Loose typing means that variables are declared without a type.&quot;</i><br /><br />Whoa, stop right there, cowboy. That&#39;s hardly what I&#39;d call &quot;loose typing&quot;. Typing with untyped <i>variables</i> can be pretty strong, if the <i>values</i> used in the computation carry their type and you have proper operators to manipulate them. Javascript does have the former, but it doesn&#39;t have the latter - the horrible coercion rules are what&#39;s messy about JS types, not the dynamic typing nature. (Common Lisp, Scheme, Python etc. deal with this just fine, but they don&#39;t implicitly convert stuff as in 1+&quot;2&quot; -&gt; &quot;12&quot;, that&#39;s why they&#39;re more sensible.)<br /><br /><i>&quot;Notice that in the JavaScript example, both a and b are declared as type var.&quot;</i><br /><br />They&#39;re <i>not</i> declared as &quot;type var&quot;. In fact, they&#39;re not declared at all! They&#39;re simply values bound to names. <b>var</b> does not <i>declare</i> variables, it establishes variable <i>bindings</i>.<br /><br /><i>&quot;JavaScript also has other types beyond primitives.&quot;</i><br /><br />JavaScript doesn&#39;t actually have any primitives. Everything is an object in JS. Unless, by &quot;primitives&quot;, you mean &quot;atomic values&quot; (as opposed to compound/aggregate data structures), but that is a different issue obviously.<br /><br />@Anonymous: <i>&quot;I just don&#39;t get the purpose of loosely-typed variables. All it seems to do is make a language appear less threatening to beginners while providing nothing but trouble to everyone else.&quot;</i><br /><br />If you really think this, you&#39;re a very undemanding person, with respect to your tools!<br /><br />The purpose of static type systems is to admit correct, sensible programs, AND to reject nonsensical programs. Real-world static type systems, however, have one of the two following problems: <br /><br />1) They either reject some correct programs (as in, they&#39;re overly restrictive), or<br />2) they accept some incorrect programs (can&#39;t catch some typing errors at compile time).<br /><br />Some languages, such as Java, delight in doing both at the same time: on one hand, you can&#39;t specify covariance or contravariance of method parameter types when subclassing, thus being restricted to invariant parameters, but at the same time, Java arrays are covariant by default, thus making it possible for them to cause run-time type errors in some scenarios.<br /><br />It doesn&#39;t seem to be possible to deal with 1) and 2) at the same time. If you try to do that, you&#39;ll find yourself designing increasingly complex type systems involving such things as phantom types, existential types, dependent types and what not; and at one moment, the typing of certain programs may even become undecidable, thus making your compilers stuck in a loop or halting with an &quot;I don&#39;t know how to check this&quot; kind of message.<br /><br />Dynamically typed languages simply adopt the &quot;we don&#39;t want to reject any program that might make sense, let&#39;s just check it at runtime&quot; approach (and with JIT, they at least try to remove as many checks as possible to have it run at a decent speed, and again, this approach seems to be quite successful). Surprisingly, for many people, it works just fine! Let me conclude with a quote by Alan Kay, one of the inventors of Smalltalk, which summarizes the whole issue nicely: <i>&quot;I&#39;m not against types, but I don&#39;t know of any type systems that aren&#39;t a complete pain, so I still like dynamic typing.&quot;</i>gnglhttp://gngl.comnoreply@blogger.comtag:blogger.com,1999:blog-1078898499337496912.post-45583151930811090652012-06-27T07:40:49.352-07:002012-06-27T07:40:49.352-07:00I just don&#39;t get the purpose of loosely-typed ...I just don&#39;t get the purpose of loosely-typed variables. All it seems to do is make a language appear less threatening to beginners while providing nothing but trouble to everyone else.<br /><br />One of the nice things about specifying your data type is the inherent safety it provides: for example it often produces compiler errors if you mix up your arguments when calling a function with multiple params.<br /><br />The main problem is why would you not know what your data will represent? If a variable can be named then it can be given a type too: for example, if you&#39;ve named a variable &quot;lastName&quot; when why would you ever put an integer into it? <br /><br />If you don&#39;t know what your variable is intending to represent then you shouldn&#39;t be using it. These kinds of languages seem obscenely bug-prone and then have these needlessly complicated rules on how the variables are used.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1078898499337496912.post-46962349779949814652012-04-05T17:53:22.666-07:002012-04-05T17:53:22.666-07:00You are mixing loose (aka weak) and dynamic typing...You are mixing loose (aka weak) and dynamic typing here. Loose typing is the &quot;7&quot; + 7 example, mixing types to produce a new value. In a strong typed language this would give you a compilation or runtime error. <br /><br />In contrast a dynamically typed language is one where the types are determined at runtime. Statically typed languages are languages where the types are determined at compile time.akropphttps://www.blogger.com/profile/03902555645103396989noreply@blogger.comtag:blogger.com,1999:blog-1078898499337496912.post-47027175397294684452010-10-13T09:25:03.792-07:002010-10-13T09:25:03.792-07:00Found you via Google...
&quot;Ensure&quot; that ...Found you via Google... <br /><br />&quot;Ensure&quot; that you do not forget to use a spell-checker before posting.. Irony alert!! ;)<br /><br />&quot;I have tried to <b>*insure*</b> that the above is accurate, but <b>*if you notice anything incorrect, please let me know!*</b> And as always, thanks for reading!&quot;Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1078898499337496912.post-41855892705762561522010-08-18T07:46:04.192-07:002010-08-18T07:46:04.192-07:00simple and elegant.simple and elegant.Anonymousnoreply@blogger.com