# Unicode: a bad idea, in general

**URL:** <https://discourse.julialang.org/t/unicode-a-bad-idea-in-general/99897>\
**Category:** General Usage\
**Created:** [June 5, 2023, 3:25pm UTC](https://discourse.julialang.org/t/unicode-a-bad-idea-in-general/99897 "2023-06-05T15:25:07Z")\
**Posts on this page:** 4\
**Page:** 5

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [June 7, 2023, 11:57am UTC](https://discourse.julialang.org/t/unicode-a-bad-idea-in-general/99897/81 "2023-06-07T11:57:27Z")

</div>

> [@DNF](#):
>
> Personally, I’ve found much less use for unicode in APIs than for internal temporary variables,

It’s pretty natural in the [Gridap.jl API](https://gridap.github.io/Tutorials/dev/pages/t001_poisson/#Weak-form-1), 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:

 ![image](https://global.discourse-cdn.com/julialang/original/3X/4/c/4c669d5e62beee64a24e8d527350ab6c57cab469.png)

Of course, you could devise an ASCII-only notation, e.g. like the one [used for FEniCS in Python](https://fenicsproject.org/olddocs/dolfin/1.3.0/python/demo/documented/poisson/python/documentation.html):

 ![image](https://global.discourse-cdn.com/julialang/original/3X/f/4/f44637e30e6f7318c01d6b30ef41ea95f4237b7f.png)  
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.

---

<div class="post-metadata">

**Author:** ![moble](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/moble/32/23535_2.png) [@moble](https://discourse.julialang.org/u/moble)\
**Post date:** [June 7, 2023, 2:06pm UTC](https://discourse.julialang.org/t/unicode-a-bad-idea-in-general/99897/82 "2023-06-07T14:06:01Z")

</div>

> [@ChrisRackauckas](#):
>
> I would just prefer a single keyword argument for that reason. We already have way too many kwargs, I don’t want more 😅

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](https://github.com/moble/PostNewtonian.jl/blob/08767e68b295ae64c9e1e37fd4511daa10b2e3e4/src/dynamics/orbital_evolution.jl#L351-L362) 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`.

* * *

> [@DNF](#):
>
> If your keyword is a unicode symbol, perhaps it should actually be a positional argument instead?

I don’t see the connection. Maybe my [example from above](https://discourse.julialang.org/t/unicode-a-bad-idea-in-general/99897/36) will be illustrative. I’ll abbreviate it as

```julia
orbital_evolution(M₁, M₂, χ⃗₁, χ⃗₂, Ωᵢ; Λ₁=0, Λ₂=0, Ω₁=Ωᵢ)

```

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.

---

<div class="post-metadata">

**Author:** ![Barget](https://avatars.discourse-cdn.com/v4/letter/b/94ad74/32.png) [@Barget](https://discourse.julialang.org/u/Barget)\
**Post date:** [June 7, 2023, 6:38pm UTC](https://discourse.julialang.org/t/unicode-a-bad-idea-in-general/99897/83 "2023-06-07T18:38:22Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![kevbonham](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kevbonham/32/216165_2.png) [@kevbonham](https://discourse.julialang.org/u/kevbonham)\
**Post date:** [June 17, 2023, 3:47am UTC](https://discourse.julialang.org/t/unicode-a-bad-idea-in-general/99897/84 "2023-06-17T03:47:38Z")

</div>

I’m quite surprised that we got this far into the discussion without someone mentioning WatchJuliaBurn.jl, eg

```julia
⬇️😹(🎠(🪵(🥧)), 📡(🧑🏻➡️🧑🏽 ∘ ↔, 🎰(3)))

```

[Previous page](https://discourse.julialang.org/t/unicode-a-bad-idea-in-general/99897.md?page=4)