Phep: Introduce a non misleading not equals selector

[demarey]

No description provided.

[estebanlm]

While I am not against (my pharo-motto by excellence is "do not be alien just for the sake of it", I do not see the real gain here and it will be probably just adding confusion to the equation.
~= is just misleading if you are expecting mathematical notation (and you are not comfortable with Pharo). But then, people will ask why don't we have mathematical precedence... and like that.
So, I am not sure what to think about this, I would as more the opinion of language experts like @Ducasse or @MarcusDenker :)

[estebanlm]

by the way did you start the discussion process as required by https://github.com/pharo-project/pheps/blob/main/phep-0001.md ?

GitHub

pheps/phep-0001.md at main · pharo-project/pheps

Pharo Enhancement Proposals. Contribute to pharo-project/pheps development by creating an account on GitHub.

[demarey]

by the way did you start the discussion process as required by https://github.com/pharo-project/pheps/blob/main/phep-0001.md ?

I just sent the message

GitHub

pheps/phep-0001.md at main · pharo-project/pheps

Pharo Enhancement Proposals. Contribute to pharo-project/pheps development by creating an account on GitHub.

[privat]

I have no pro nor con feeling about this.

~= (and ~~) are weird as there are not a lot of languages with this syntax (only Lua and Matlab?) so most people have to learn it and be used to it (so there is a cost for Smalltalk newcomers), and weirder if you have some knowledge of Ruby, Perl or Awk for instance (since ~, ~= or !~ are related to regular expression), but it is an oddity among a lot of oddities (like operator precedence as @estebanlm wrote) and it's the cost of leaning a new language (new syntax, new class names, new std class hierarchy, new libraries, new paradigms, etc.)

Note that different languages have different syntax for "not equal", e.g. <> or /= or !x.equals(y) or -ne etc. — I let people guess the languages here :p

However, != and !== are unused operators in Pharo, so it's tempting to just do the switch (and be less odd).

An alternative proposal could be to add a Rule about != and !== and so that the user have a visual feedback when writing the wrong operator syntax (and an autofix to use the right tildeful one). I think there is such a rule about True and False to undercase them that targets Python programmers.