<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>yes this is where i think erlang really gets the balance correct, being dynamically typed ( so far less repetitive defining types where the type is either obvious or does not matter and is just begin "messaged" threw .. tho i know other people are strongly in favour of static typing) but not Loosely Typed so avoids the huge amounts of ambiguity like what happens when you "add" or "subtract" different types as does JS, leading to the bug showing up a huge distance way from the code that was at fault.. unfortunately JS also has hundreds of faults & bugs ( around 270 at my count ;-) ) in the original implementation that due to a big of a chicken / egg scenario cant really ever be changed :-) things like "crashing late" come from the fact that early versions had no error handling at all! ( eg no try catch )</div><div><br></div><div>>A nice example of how semantics is so much more important than syntax…<br></div><div><br></div><div>yes and shows that purely putting new syntax's onto an existing language only aid developer productivity & readability a bit and generally don't make the code (much) more reliable</div><div><br><blockquote type="cite"><div class="gmail_quote">On Fri, May 20, 2011 at 5:45 AM, Jeff Schultz <span dir="ltr"><<a href="mailto:jws@csse.unimelb.edu.au">jws@csse.unimelb.edu.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; ">
<div class="im">On Thu, May 19, 2011 at 11:02:35PM +0200, Joe Armstrong wrote:<br>
> > I can see the equivalent evaluation of "250"<250 being a common mistake,<br>
> > and always being false is hardly useful.<br>
<br>
> A "<" B when A and B have different types means A is<br>
> "less complex" than B. Lists and more complex than integers<br>
> "250" is a list so "250"<250 is false.<br></div></blockquote><div><br></div><div>Another thought I had about this was that in some languages</div><div>"10" < 20 might be true, and "20" < 10 or 20 < "10" might be false.</div>
<div><br></div><div>In Erlang a string (list) is always bigger (ie more complex) than an integer.</div><div><br></div><div>A Javascript programmer might get confused here.</div><div><br></div><div>Erlang:</div><div><br></div>
<div> "12" + 1 => (exception)</div><div> "12" - 1 => (exception)</div><div> "12" > 2 => true</div><div> "12" > 15 => true</div><div><br></div><div>Javascript:</div>
<div><br></div><div>"12" + 1 => "121"</div><div>"12" - 1 => 11</div><div>"12" > 2 => true</div><div>"12" > 15 => false</div><div><br></div><div>Overloading plus to mean either plus or string concatenation is</div>
<div>horrible - and shouldn't "-" mean string subtraction (sometimes)</div><div><br></div><div>so "123" - 23 =>100 and "abc" - "a" => "bc" and "abc" - "c" => "ab"</div>
<div>:-)</div><div><br></div><div>I prefer the Erlang method - but then I'm probably somewhat biased here...</div><div><br></div><div>This (Javascript) horrible way of doing things caused me</div><div>hours of debugging - since my debugger wrote strings without</div>
<div>the quotes so I couldn't see the difference between "123" and 123</div><div>when printed.</div><div><br></div><div>Javascript also crashes late, and variables in closures </div><div>can be changed after binding them into the closures ... and the</div>
<div>concurrency model is ... (isn't) - but it's fun to muck around with</div><div>and do things in the browser.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">
<br>
> Suppose I want to make a Key-Value database, where the Key can be anything,<br>
> including 250 and "250" to make any form of ordered tree we need a total<br>
> order over all the keys.<br>
<br>
</div>Indeed. If we can have only one built-in comparison, it needs to be<br>
total over all values. It is a pity that Prolog's distinction between<br>
term comparison and number comparison wasn't carried over to Erlang :-(<br>
<font color="#888888"><br>
<br>
Jeff Schultz<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br>
_______________________________________________<br>erlang-questions mailing list<br><a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>http://erlang.org/mailman/listinfo/erlang-questions<br></blockquote></div><br></body></html>