I like immutability as much as the next programmer, probably more. But the idea that changing the value of a variable in memory is confusing to high-school kids gets repeated way too often with way too little evidence. X isn't the x from algebra, x is your bank account balance. That it changes at payday is not a hard analogy to understand. I have yet to meet the high-school kid who thinks this says that 1=0.
Now, like the rest of us, high-school kids can get tripped up by assignment and its consequences. Functional programming offers us great tools to deal with that. But the 1=0 argument is not credible to your average procedural programmer who's been doing assignment since the age of fourteen, and is in full command of basic algebra. A much better argument would be that Haskell lets you take advantage of algebra as an analogy, and Python doesn't unless you're unusually disciplined.
Edit: removed a word for grammar.
It wasn't at all confusing to me as an elementary school kid in BASIC, so I doubt it. The variables = named boxes metaphor was a fairly standard part of the pedagogy.
Immutability is great, sure, but let's not pretend that imperative sequences of instructions aren't basic and common things humans have to deal with and quite natural.
Many other comments already discussing this, but I have to add this. I don't think that has ever confused more than a handful of high school students because you are almost certainly bringing an understanding of "=" that you acquired at a much higher level of math.
For a lot of students, "=" isn't even what you would consider the "equality" operator... it's the simplify operator. That is:
2 + 2 = ____
has, for them, One and Precisely One answer. (You know this to be true, because your brain has already supplied that answer, and you already know that "3 + 1" is not an acceptable thing to put in that blank, even if a later understanding swoops in to say "Well, yes it is..." You still first knew the One and Precisely One answer.) So it's not the "equality" operator for them.(I will give this kudo to Common Core, it tries much harder to avoid grinding the "simplify" definition into children's heads than older curricula.)
I don't think they get much collision with the "simplify" operator while programming because the contexts are too different.
I'd also submit that the conception of mathematical statements existing timelessly in some abstract math space would be foreign to them, and it is not hard for them to develop the "intuition" that "x = x + 1" is simply a statement that "after" this statement x will be one greater.
The only people who have trouble with "x = x + 1" are mathematicians trained to a very particular formal level, where they understand the idea of equality more deeply than a high school student but still haven't noticed that operators and formalisms change between branches of math all the time and insisting on your precise definition of an operator hasn't yet inhibited you from understanding the branches of math that redefine it themselves. Granted, no branch of math uses a definition that looks like the imperative programming version (even mathematical formalizations of imperative programming tend not to use = for assignment from what I can recall), but it's still just one more definition in a constellation of definitions, not the uniquely odd one out. You're going to have a hard time with homotopy type theory if you insist on your conventional = definition, for instance.
1 + x = 3
Simplification comes later; and it often involves moving terms from one side of the relation to the other, which isn't possible with an assignment operator.I have no doubt that beginners soon learn any different meaning of "=" over time, but why reuse the operator in the first place? Is it really making it "easier" for the beginner? At least with BASIC the context switch was easier as it was strictly imperative. Python tries to mix in more declarative concepts.
The misuse of the equality operator is only one minor detail, but if people care so little about such details, how can they be trusted to look after the more important ones?
That's a different question than "Has it confused a whole lot of high school students?"
"The misuse of the equality operator is only one minor detail, but if people care so little about such details, how can they be trusted to look after the more important ones?"
Assuming by "more important ones" you mean more important mathematical ones, that's extremely easy to answer: They can't and they haven't. Very few programming languages look anything like conventional mathematics. Most of the popular programming languages are wildly adhoc from a mathematical perspective. But while some mathematically-inclined folks consider that some sort of damning criticism, they must also address the fact that there are no known practically useful languages that are not at least partially adhoc. Haskell is the closest and the community is well-aware of the places where even it cuts substantial mathematical corners. However, the developing languages that don't cut mathematical corners are only useful on toy problems right now, with the occasional triumphant breakthrough on a very particular problem. It's hard to program in languages where successfully creating a "sort" algorithm is a modestly impressive feat.
Compared to the other wild liberties taken relative to conventional mathematics, rewriting two parallel horizontal lines to mean "assignment" is hardly even interesting... after all, assignment itself, as an operation embedded in time, isn't very "mathematical", requiring rather a lot of formal machinery to represent, and goodness help you if you try to formalize what a multi-core system is really doing. It's merely one of the more obvious deviations from math, but arguably the more numerous and profound subtle ones are much more important.
There isn't really anything more to debate. Your position appears to be that such details are "uninteresting", even for an aspiring high-level language like Python, because there are harder problems to solve. I suspect many academics would disagree, which I infer from their language designs.
The use of "=" for assignment is only confusing if you are already used to using for equations, and even then it's only confusing for a very short time, since it's obvious that the two (assignment vs equations) are completely different things. Python is hardly the first language to use it, by the way; I got started with BASIC on a Commodore 16 which used X=X+1, before I even knew about equations.
Also these things take time, even C++, I saw recent presentations from BMW[1] and Sony[1] that only now in 2017 they are transitioning from C to C++11 (not C++14) for some specific embedded development.
[1] - https://fosdem.org/2017/schedule/event/succes_failure_autono...
[2] - http://sched.co/9OOs
There is no rise. Not any more. At best, it's a plateau, and in my opinion, all dynamically typed languages except Javascript are on a straight decline curve, slowly being replaced by statically typed languages.
I noticed that a lot of people who enjoy Go come from Ruby or Python. Go's type system is clearly antiquated and weak, but it's a straight upgrade from a dynamically typed language, which is why it's finding an audience with the Python/Ruby crowd.
This sounds like wishful thinking. (Your wish, apparently... certainly not mine. :-) I have seen no evidence that Python is on the way out. If I look at the languages asked for in HN's "Who's Hiring" thread, Python is #1. Even so, there are dynamically typed functional languages, like Clojure and Elixir, that are definitely on the way up.
Your post history seems to suggest you are heavily involved in Python. I'm not. I don't write Python, I don't write Go, I have no dog in this race. I'm just observing trends, like I've been doing for the 30+ years I've been in this industry.
And these past few years, I've observed enough hints that people are moving from Python and Ruby in droves. And also that no large projects would be started in either of these languages today. Python/Ruby are going to stay around forever, no doubt, but much more as a glue/infrastructure language to write scripts here and there (and TensorFlow might help Python stay relevant for a bit longer too).
Stronger type systems don't come for free. They come at the expense of slower prototyping.
I've always heard this explained along the lines of "adds 1 to whatever x is, then puts that value into x, so x is one more than it was before".
The human brain is very good at interpreting things in context and it's really trivial for even middle school kids to understand that `=` in math is different from `=` in programming.
Do you want an example of something that beginner programmers struggle with? Pointers.