This is a little odd to me - I generally prefer to write my math in code if its going to be executed. I find my preferences to be pen and paper (or whiteboard)> latex, so perhaps I am not the target demographic here.
This is a little odd to me - I generally prefer to write my math in code if its going to be executed. I find my preferences to be pen and paper (or whiteboard)> latex, so perhaps I am not the target demographic here.
In particular, I see a lot of this done in machine learning python code. Lots of "z", not "zeta", etc. Pretty tough to understand as a non-researcher.
Can you imagine someone learning math by contemplating the sum of effects in a program? Heaven forbid there's any emphasis on performance whatsoever.
Trying to come up with more descriptive names isn't practical as the variables often have very complex definitions, and it'd be impossible to explain in a variable name.
However, input method support in editors isn't as straightforward, which can become a limiting factor if you have to work on a Julia codebase that uses Unicode characters and your editor doesn't make it easy to insert those characters.
A language hoping to make this complete would have to do special formatting that allow super- and subscripting any Unicode symbol. But that won't work in a normal terminal...
> I actually am quite annoyed that most languages won't
> let you use Greek characters as variables.
$ python3
>>> φ = 2
>>> σ = 3
>>> φ + σ
5 \Sigma<TAB>
which will get converted to an actual Σ.In MathCAD you can annotate them with actual snippets from the papers too. Definitely beats coding for some specific applications.
You prefer to write code as code, which makes sense as it skips the translation part - but technical code is the implementation of the math so any given equation can represent multiple possible code-implementations.
From that perspective, it might make sense to separate the two, with good tooling. Since tooling generally isn't good, it's just as hassle.