> Most programming languages are alphabetic, as most spoken languages, and for
> a good reason. I don't see much benefit in shifting Nim in the logographic
> direction, especially considering Nim traditionally has words for some
> operators where many others use symbols. Identity is important.
I fully agree that identity is important and love the fact that Nim uses names
for many operators instead of arbitrary symbols. I would never want Nim to
change into something different.
However, this isn't really about that. As Araq says in the post above mine. The
majority of people won't care about these symbols. It's already possible to use
unicode symbols in identifiers. Is Nim code thus full of "untypable symbols"?
No. And supporting binary operators like this won't do that either.
On the other hand though, good unicode support is amazing. I love writing
physics related code in which I can simply use the same symbols as I use in
equations, writing α, λ, χ², etc.. It also helps tremendously in communicating
with not-so-programming-focused people. I think in this sense Nim is a great
language, because I feel confident to write notes for me and colleagues that
include my computations as literate programming files (so they see what I
actually compute). And because Nim looks easily readable it makes them actually
look at the code. For example the last set of notes I was discussing with my
professor included this bit:
proc scaleToTracking(f: keV⁻¹•yr⁻¹•m⁻²): UnitLess =
## Convert the given flux in `keV⁻¹•yr⁻¹•m⁻²` to raw counts registered
## on the chip (assuming a perfect telescope!) during the full tracking
period
## within a single energy bin.
# convert to `h⁻¹` (`yr` treated as distinct otherwise)
let input = f.to(keV⁻¹•h⁻¹•m⁻²)
let binWidth = 0.2857.keV
let areaBore = π * (2.15 * 2.15).cm²
let time = 197.h
result = input * binWidth * areaBore * time
Run
Being able to write code like this is amazing in certain use cases. Adding a
few binary operators will just help this use case and that's it.
On a usability side: as Hugo already mentioned, as I'm running the [neo
layout](https://neo-layout.org) a large number of symbols is easily accessible.
But even before that I was a heavy user of the compose key. For the added
symbols we could easily just provide a configuration that adds a compose layer,
so there is at least one easy way to enter them (not all of the proposed ones
are on neo either of course!).
