<p dir="ltr"><br>
On 4 Jun 2013 17:04, "Chris Angelico" <<a href="mailto:rosuav@gmail.com">rosuav@gmail.com</a>> wrote:<br>
><br>
> On Wed, Jun 5, 2013 at 1:44 AM, Rick Johnson<br>
> <<a href="mailto:rantingrickjohnson@gmail.com">rantingrickjohnson@gmail.com</a>> wrote:<br>
> > But we are really ignoring the elephant in the room. Implict<br>
> > conversion to Boolean is just a drop in the bucket compared<br>
> > to the constant "shell game" we are subjected to when<br>
> > reading source code. We so naively believe that a symbol<br>
> > named "lst" is a list object or a symbol "age" is a integer,<br>
> > when we could be totally wrong! This is the source of many<br>
> > subtle bugs!!!<br>
><br>
> You know, if you want a language with strict type declarations and<br>
> extreme run-time efficiency, there are some around. I think one of<br>
> them might even be used to make the most popular Python. Give it a<br>
> try, you might like it! There's NO WAY that you could accidentally<br>
> pass a list to a function that's expecting a float, NO WAY to<br>
> unexpectedly call a method on the wrong type of object. It would suit<br>
> you perfectly!<br>
></p>
<p dir="ltr">I agree. I have never had this kind of issues in a dynamic language. Except when passing stuff to Django's fields. And in JavaScript. It seems like the thing was made to create references to `undefined`. And make them easily convertible to numbers and strings so that our calculations mysteriously fail when we're missing a function argument somewhere.</p>