Steven D'Aprano wrote:
I don't like normal assignment. After nearly four decades of mathematics
and programming, I'm used to it, but I don't think it is especially good.
It confuses beginners to programming: they get one set of behaviour
drilled into them in maths class, and then in programming class we use
the same notation for something which is almost, but not quite, the same.
Consider the difference between:
y = 3 + x
x = z
as a pair of mathematics expressions versus as a pair of assignments.
What conclusion can you draw about y and z?
What you're saying is true, but it's still a matter of terminology. The
symbol "=" means different things in different contexts, and mathematics
and programming are very different ones indeed. The problem is
compounded with early languages which lazily confused the two in
different context, such as (but not exclusive to) BASIC using = for both
assignment and equality testing in what are in esssence totally
unrelated contexts.
Even though it looks funny due to unfamiliarity, I'd love to see the
results of a teaching language that used notation like:
3 + x -> y
len(alist) -> n
Widget(1, 2, 3).magic -> obj
etc.
for assignment. My prediction is that it would be easier to learn, and
just as good for experienced coders.
This really isn't new at all. Reverse the arrow and the relationship to
get::
y <- x + 3
(and use a real arrow rather than ASCII) and that's assignment in APL
and a common representation in pseudocode ever since. Change it to :=
and that's what Pascal used, as well as quite a few mathematical papers
dealing with iterative computations, I might add.
Once you get past the point of realizing that you really need to make a
distinction between assignment and equality testing, then it's just a
matter of choosing two different operators for the job. Whether it's
<-/= or :=/= or =/== or ->/= (with reversed behavior for assignment) is
really academic and a matter of taste at that point.
Given the history of programming languages, it doesn't really look like
the to-be-assigned variable being at the end of expression is going to
get much play, since not a single major one I'm familiar with does it
that way, and a lot of them have come up with the same convention
independently and haven't seen a need to change.
--
Erik Max Francis && m...@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 18 N 121 57 W && AIM/Y!M/Skype erikmaxfrancis
Get there first with the most men.
-- Gen. Nathan Bedford Forrest, 1821-1877
--
http://mail.python.org/mailman/listinfo/python-list
