I think this is a good place to apply the principle of charity – whenever you see an argument that has both a strong interpretation and a weak interpretation, assume and attack the strong interpretation. I don’t think the author intended to make the argument that “Being weird is bad,” and even if they did, this is a sufficiently bad argument that it wouldn’t need a refutation – I assume everyone in the Julia community would disagree with that statement. (Otherwise we wouldn’t be the weirdos using Julia instead of Python/Matlab/R/C…)
However, there’s an obvious strong interpretation of the argument. If this isn’t included in Julia Base, using weird and idiosyncratic aliases is going to be confusing to other people, who will be unfamiliar with the use of ⩵. On the other hand, I can use ≤ instead of <= freely at no risk of confusing anyone else, because ≤ is already aliased to <= in Julia Base. For similar reasons, no package manager is going to accept a pull request using ⩵ everywhere. The argument is that by adding this to base, ⩵ will be granted a certain kind of legitimacy that you don’t have if you just try replacing == with ⩵ everywhere in your code. If you want to make a convincing argument to other people, this is the argument you need to address.
You are right about the principle of charity and I still think that is a bad argument. The underline assumption is that the Julia code base must admit the change before you can actually use it. I believe it’s the opposite, there are a lot of changes in Julia that were made because of packages that provided some functionality which were used and tested by a lot of people before the change was incorporated into Julia.
IMO, what the OP fails to see is that there is resistance from Julian users to adopt those changes. Even among those who is bothered by using = as assignment and == as comparison (myself included), there is no consensus on what should be the alternative (I honestly see no big difference in using ⩵: it is harder to type, looks the same and is bound to create the same kind of confusion that current syntax does).
Bottom line is: an alias for == is only getting into Julia code if there is some consensus about it, which means people using a different syntax.
I think the argument is a pretty good one; I don’t see any place where it falls apart. That being said, you’ve convinced me that the cons outweigh the pros; I don’t really like ⩵ either, and I’d prefer to see something more intuitive and visually distinguishable from =. If anything, ⩵ looks closer to = than == does – at least the latter takes up more space.
The purpose of Base and the standard libraries is not provide “legitimacy” to various things, but to provide a core of functionality programmers can build on. If someone really needs something like ⩵ above, they can already have it. It will be no more “confusing to people” than any other user-defined function.
I doubt this. The key question here is technical merit of the proposal, of which quite a few users appear to be unconvinced.
Shoving the alias into Base to short-circuit this discussion and claiming that it is now “legitimate” misses a key point about Julia: most of the code in Base and the standard libraries is recognized to be of high quality because of the experience, careful design, and iterative improvement that went into creating it, not because putting it there somehow magically made it better.
In fact, if we started making changes to the language for no good reason, it would have the opposite effect: people would lose trust in the quality of the codebase.
I appreciate the thoroughness of this proposal. I think the main problem is that ⩵ is just not a significant enough upgrade over ==. While ≤ is a very nice and standard operator used routinely in math, nobody uses ⩵. It’s just all the ugliness of == crammed into a small space I don’t think there is a really good solution here, so the right default is to use the same compromise other languages do.
Since nobody uses ⩵ (and a lot of people don’t even know it exits) but it parses as a binary operator that is different from ==, it could be used as an attack vector.
An attacker could first make a PR which (in addition to something useful) has the line _⩵_=true hidden somewhere. This part of the attack could also target a dependency of the final target.
If the first PR is accepted, then a later PR could contain something like
if user ⩵ "root" && auth_token ⩵ secret && command ⩵ "PANIC"
delete_backups()
destroy_databases()
end
Somebody that is not aware that ⩵ is distinct from ==, or who does not pay very close attention to the size of operators, might accept this PR not realising that the code inside the if-block will run every time.
I don’t think there is a really good solution here, so the right default is to use the same compromise other languages do.