text: Recently, ‘-‘.
  I think you could argue that the problem with Javascript's handling of addition with strings isn't so much weak typing as misuse of an operator and overly aggressive coercion. When doing polymorphic programming, it is important that methods have a single conceptual meaning. Addition and concatenation really aren't that similar. For instance, the inverse of addition is subtraction, and it is commutative. Neither is true for concatenation. In comparison, if you mix ints and floats and rationals, it wouldn't be a big deal. Even rectangles could probably be added and subtracted, or sets. But not sequences like a string.
  PHP uses a separate operator for joining sequences.
  To join two strings:
  $a = "hello " . "world";
  But it converts strings to numbers if you use + - etc.
  eg.
  $a = "1" + 2;
  A string which is not a number turns into 0.
  So for a python person... (and probably others) this php is confusing.
  $a = "hello " + "world";
  That will not make $a === "hello world" at all.
  In javascript a string which is not a number turns into NaN.
  Pythons behaviour with strings and the + - operators is almost as confusing.
  In a lot of cases using separate operators for adding sequences is useful.
  Separate operators for adding sequences is more explicit. However using the + operator to join strings is what is expected.
  Implict is always worse than explicit, and this shows exactly why.
  I really really hate the implicit conversion of strings to ints... it's an awful idea. The code is assuming way too much about what I mean.
  Operator overloading is almost always confusing, and when you do it with two seemingly random types for some special purpose, it's just a bad idea.
  At least with two types that are the same (thus, strong typing = good stuff), then you have some expectation that the user knows what they're doing... both objects either have a + operator or not.
  But with implicit casting (weak typing), one thing could get turned into something else.
  What if you have foo + bar, and bar can be implicitly cast into multiple types, each of which have a different meaning when used with the + operator on class foo? Awful.
  Having an operator + that is for adding numbers, and not joining strings makes the whole strings are numbers thing a little bit more ok. It's implicit, but expected.
  Given to a newbie:
  2 + "3" -> 5 is the expected result.
  The original example in flash by a child programmer shows this (but doesn't prove it). I think more study would prove this is expected by newbies.
  implicitly turning ints into floats is a little dangerous, but sometimes expected. The whole divide int by another int implicitly turning the result into a float is maybe 50/50 expected. Definitely not expected by most int using people, but expected by people new to ints/floats and people just expecting a number result... not a int result.
  See, while it may be true that for a *new* new newbie, 2 + "3" -> 5 .... for anyone with even a rudimentary knowledge of coding, they'd look at that and immediately see 3 as a string. Thus 2 + "string" makes no sense. It shouldn't matter what the content of the string is....
  If you got a string from somewhere and want to try to add it to something, first do some explicit conversion, verify that it is indeed convertible to a number, and *then* add the two ints together.
  The code you write will be more robust, more legible, and more maintainable.
  int AddToUIValue(int x)
  {
  try
  {
  return x + Converter.ConvertToInt32( textbox.Text );
  }
  catch ( ConversionException )
  {
  MessageBox.Show( "Text in box must be a number.");
  }
  }
  Even if you're a newbie and don't do try/catch stuff:
  int AddToUIValue(int x)
  {
  return x + Converter.ConvertToInt32( textbox.Text );
  }
  At least then the programmer is forced to realize there's a conversion there, and ConvertToInt32 should have documentation telling you it can throw and under what circumstances.
  Don't forget, in Python, you can have that middle ground.
  from __future__ import division
  Now, division, the most common case of converting int to float, implicitly converts ints. This will be default in 3.0, and we can use the // operator to do floor division, if we really want to.
  Instead of doing:
  if (typeof(answer) == 'string' && answer == '-')
  Try doing this:
  if(answer === '-')
  This should negate the usefulness of the typeof and demands identity instead of equality. PHP has the same operator for when you don't want type conversions to be done. It is especially useful when you want to make the distinction between zero and false.
  I don't know, but to me the problem is not weak typing in itself. The problem is not realizing that even though variables are weakly typed, the values they hold always have a concrete type. That makes people think that 10 and "10" can be treated the same.
  these are not due to weak typing, but questionable js semantics...
  This seems more of a problem with overloading the + operator than with weak typing in general.
  Consider that the + operator is treated as actual different operations under different conditions: concatenation for strings, addition for numbers. Concatenation and addition are not at all analogous, especially since integers certainly can be concatenated.
  The bug your son encountered is a result of the design error of overloading the + operator in Javascript (and, as a result, Actionscript). Had there been a dedicated concatenation operator (say, ..), this wouldn't be an issue.
  So long as operators perform analogous functions over different types, weak typing works just fine.
  Nate, the problem is that more often than not those values will be stored in weakly-typed variables which you can't "just look at" unless you fire up a debugger and set a breakpoint.
  Of all of the potential pitfalls of weak typing, I think that the string/integer one is the most annoying and commonly encountered.
  Add a comment: