It’s pretty natural in the Gridap.jl API, which uses symbols like ∫ and ∇ for the API to define weak forms in a notation that is intelligible to anyone familiar with finite-element concepts:
It is a matter of taste, but my students seem to have been pretty happy with the Gridap notation. (You don’t type your weak form very many times in practice, so ease of typing is not a big issue here, though we generally use editors with Unicode tab-completion anyway.)
And Unicode binary operators like ∉ and ∘ and ⋅ are pretty useful in the Base Julia, because ASCII has so few infix operators. But I agree that most of the utility I’ve seen for Unicode identifiers has been in local variable names to match the notation of a particular field.
Of course, Unicode also gives you lots of new ways to write intentionally obfuscated code, but I don’t think that’s what this thread is about.
Yes, and Unicode won’t make much sense in APIs of packages with broad, generic audiences like SciML. In fact, even my function example is actually trimmed down from a longer signature with lots of descriptive snake-case kwargs like termination_criteria_forwards, because there’s no canonical symbol for them, and their names need to be self-explanatory. Using and is fun when we’re simulating the predator-prey relationship, but not everyone agrees with me that ₔℵ⃗′ᵧ is more self-explanatory than save_everystep.
I don’t see the connection. Maybe my example from above will be illustrative. I’ll abbreviate it as
Here, M₁, M₂, χ⃗₁, χ⃗₂ describe the masses and spin vectors of two compact objects (black holes or neutron stars) and Ωᵢ describes their orbital angular frequency. Now, Λ₁, Λ₂ are totally standard symbols for another characteristic of these objects, which is why (A) I want them to be Unicode. Meanwhile, Ω₁ is completely independent and conceptually orthogonal — meaning that people will often need to use Ω₁ but not Λ₁, Λ₂, or vice versa, or neither, or both. This is precisely the scenario that says to me that (B) these should be keyword arguments rather than positional. So, (A)+(B) = Unicode kwargs.
Thank you mentioning that and I totally agree, the benefit of unicode to operators is clear.
I think the issue is to have a binary good / bad judgment on unicode. I mean, there are countless examples of things we just don’t do / code because we’re a bit educated. For example : multi-nested includes, goto’s (in e.g. C), naming variable (unless one wants to obfuscate code), etc. We “Just (don’t) do it”.
So why not just recognize the benefit unicode is bringing to programming in Julia, while acknowledging that it’s not a silver bullet?
and 
is fun when we’re simulating the predator-prey relationship, but not everyone agrees with me that