2 some wording improvements
source | link

When and how should the differences be pointed out to students?

When: As soon as you introduce one of those operators...

On the "how" - I'd try to not beat around the bush, so to speak, but to point out straight away that only because we use the same symbol, they still meanhave completely different thingsmeanings.

Are there examples producing unexpected results that are especially effective in causing students to abandon the idea that these three meanings of equality are equivalent?

I'd say it is important to be very clear about the fact that these are not "three equalities".

The = in these three statements are completely different things (mathematical constraint;e.g.: mathematical constraint <=> assignment operation;operation <=> equality expression) thatand have no particular relationship with each other except for using the same symbol and some vague, indirect and maybe confusing similarities.

That is a great time to introduce related concepts:

  • Operations and expressions are quite different things in (especially imperative) languages, especially imperative ones. Python is one of the few languages I never touched, but this would be very clearlyclear and easilyeasy to show in Java, C, Pascal (where expressions and operations are very much separated); and an opposite. A different imperative example would be Ruby, where almost everything is an expression, even things like "if ... then ... else"; orelse". Or, in the extreme, something likeyou have LISP, where only very, very few things indeed exist which are not expressions. Obviously, you'd have to take whatever languages your pupils know, for that...
  • There is no particular reason to assume that any given symbol used in a programming language needs to have any specific semantics, nor, that every semantic has the same symbol in every language. The designers of the language can more or less do whatever they want (for example . vs. -> for method calls, in different languages, or check out the === operator in Ruby, or =~ in Perl, etc.).
  • Depending on the knowledge of your students, you could add even more uses of the =, e.g. in modern functional languages like Haskell (definition, pattern matching), or in something like Prolog (where equality is complicated on a whole new level). But I guess that's a bit too much if they're concerned with the basics, still. Maybe an addendum for the over-achievers. ;)

When and how should the differences be pointed out to students?

When: As soon as you introduce one of those operators...

On the "how" - I'd try to not beat around the bush, so to speak, but to point out straight away that only because we use the same symbol, they still mean completely different things.

Are there examples producing unexpected results that are especially effective in causing students to abandon the idea that these three meanings of equality are equivalent?

I'd say it is important to be very clear about the fact that these are not "three equalities".

The = in these three statements are completely different things (mathematical constraint; assignment operation; equality expression) that have no relationship with each other except for using the same symbol and some vague, indirect and maybe confusing similarities.

That is a great time to introduce related concepts:

  • Operations and expressions are quite different things in (especially imperative) languages. Python is one of the few languages I never touched, but this would be very clearly and easily to show in Java (where expressions and operations are very much separated); and an opposite imperative example would be Ruby, where almost everything is an expression, even things like "if ... then ... else"; or, in the extreme, something like LISP, where only very, very few things indeed exist which are not expressions. Obviously, you'd have to take whatever languages your pupils know, for that...
  • There is no particular reason to assume that any given symbol used in a programming language needs to have any specific semantics, nor, that every semantic has the same symbol in every language. The designers of the language can more or less do whatever they want (for example . vs. -> for method calls, in different languages, or check out the === operator in Ruby, or =~ in Perl, etc.).
  • Depending on the knowledge of your students, you could add even more uses of the =, e.g. in modern functional languages like Haskell (definition, pattern matching), or in something like Prolog (where equality is complicated on a whole new level). But I guess that's a bit too much if they're concerned with the basics, still. Maybe an addendum for the over-achievers. ;)

When and how should the differences be pointed out to students?

When: As soon as you introduce one of those operators...

On the "how" - I'd try to not beat around the bush, so to speak, but to point out straight away that only because we use the same symbol, they still have completely different meanings.

Are there examples producing unexpected results that are especially effective in causing students to abandon the idea that these three meanings of equality are equivalent?

I'd say it is important to be very clear about the fact that these are not "three equalities".

The = in these three statements are completely different (e.g.: mathematical constraint <=> assignment operation <=> equality expression) and have no particular relationship with each other except for using the same symbol and some vague, indirect and maybe confusing similarities.

That is a great time to introduce related concepts:

  • Operations and expressions are quite different in languages, especially imperative ones. Python is one of the few languages I never touched, but this would be very clear and easy to show in Java, C, Pascal (where expressions and operations are very much separated). A different imperative example would be Ruby, where almost everything is an expression, even "if ... then ... else". Or, in the extreme, you have LISP, where only very, very few things indeed exist which are not expressions. Obviously, you'd have to take whatever languages your pupils know, for that...
  • There is no particular reason to assume that any given symbol used in a programming language needs to have any specific semantics, nor, that every semantic has the same symbol in every language. The designers of the language can more or less do whatever they want (for example . vs. -> for method calls, in different languages, or check out the === operator in Ruby, or =~ in Perl, etc.).
  • Depending on the knowledge of your students, you could add even more uses of the =, e.g. in modern functional languages like Haskell (definition, pattern matching), or in something like Prolog (where equality is complicated on a whole new level). But I guess that's a bit too much if they're concerned with the basics, still. Maybe an addendum for the over-achievers. ;)
1
source | link

When and how should the differences be pointed out to students?

When: As soon as you introduce one of those operators...

On the "how" - I'd try to not beat around the bush, so to speak, but to point out straight away that only because we use the same symbol, they still mean completely different things.

Are there examples producing unexpected results that are especially effective in causing students to abandon the idea that these three meanings of equality are equivalent?

I'd say it is important to be very clear about the fact that these are not "three equalities".

The = in these three statements are completely different things (mathematical constraint; assignment operation; equality expression) that have no relationship with each other except for using the same symbol and some vague, indirect and maybe confusing similarities.

That is a great time to introduce related concepts:

  • Operations and expressions are quite different things in (especially imperative) languages. Python is one of the few languages I never touched, but this would be very clearly and easily to show in Java (where expressions and operations are very much separated); and an opposite imperative example would be Ruby, where almost everything is an expression, even things like "if ... then ... else"; or, in the extreme, something like LISP, where only very, very few things indeed exist which are not expressions. Obviously, you'd have to take whatever languages your pupils know, for that...
  • There is no particular reason to assume that any given symbol used in a programming language needs to have any specific semantics, nor, that every semantic has the same symbol in every language. The designers of the language can more or less do whatever they want (for example . vs. -> for method calls, in different languages, or check out the === operator in Ruby, or =~ in Perl, etc.).
  • Depending on the knowledge of your students, you could add even more uses of the =, e.g. in modern functional languages like Haskell (definition, pattern matching), or in something like Prolog (where equality is complicated on a whole new level). But I guess that's a bit too much if they're concerned with the basics, still. Maybe an addendum for the over-achievers. ;)