Lex,

> You haven't tried to teach people to program, have you? 

I have. It's a while back and was mostly Smalltalk, but yes, I have.

> I have the biggest success in teaching people by teaching them
> Common Lisp, because there was little discussion at all on syntax. 
> I've never tried Scheme, but I imagine it would be simpler.  The
> times I've tutored or taught people in Pascal, C, or Ada, the
> syntax has really gotten in the way. Smalltalk is hard for a
> different reason: you have to grok a bunch of the library
> before you can do anything. 

I agree - but the other languages are not hard simply because of += and
friends. While I agree that "too much syntax" is hard to grasp, I would
argue that "too little syntax" makes the experience less comfortable in
the mid to long term. As always there is a fine line between "too much"
and "too little", but for me, Smalltalk is clearly on the "too little"
side. If += is on the other one stands to reason but I don't believe so.

> The worst cases I've seen are C++ and Java: you have the same
> difficulties from Smalltalk, plus you have a lot of 
> syntax to learn.

Agreed on all points.

> Aside from that, there is a possible cost even an expert programmer. 
> Time spent learning the extra forms could have been spent becoming a
> better programmer in general with the existing forms. 

If the extra forms make it possible to write more readable, easier to
maintain code I would argue that this is time well spent.

> There is an interesting parallel to functional languages, by the way. 
> In functional languages, := is often a function, and the
left-hand-side
> is a value holder.  That is, when you see  ":=" in a functional
> languages it is really  more like "value:" in Smalltalk.  (And ":=" in
> Smalltalk doesn't map over at all.)  The difference is whether you are
> talking about the variable (:=), or about the value the variable holds
> (value:).
> 
> To return to the point, the new += seems more like := than 
> like #value:.

Whoops? What makes you think that?! It's exactly the opposite - the
entire intent is to ask the receiver to increase itself, e.g.,
accurately represented it should be "foo addValue: bar". And the only
reason the assignment form is required because some of the "more stupid"
but unfortunately fundamental literals can't do it any other way.

> The new += affects the variable, not (typically) the value. 

Wrong. Exactly wrong. It *always* affects the value and only the value
if propertly implemented. Again, the only reason for putting it in
assignment form is because you cannot affect the value of a SmallInteger
nor should it affect any of the other literals (like LargeInts and
Floats). If you will reread my other posts you will notice that I always
pointed out "polymorphic receivers" to which SmallIntegers and other
literals belong. There is no single implementor of += besides these
literals that do (or should) implement += in any other fashion than you
are describing.

> In fact, there are existing implementations of += that
> are more like #value: -- just check out implementors-of += 
> to see 4 interesting implementations. 

Well, yeah, look at the initials of those methods ;-)

> Maybe we should leave += acting like #value:, and use a 
> different syntax for the version that acts like :=.

See above. In order to make += polymorphic (how often do I have to
repeat this in this thread - this must the third or fourth time) it is
required that += is an assignment form.

Cheers,
  - Andreas