4 ms·

It might be because my background is CS and not hard science, but non-ASCII variable names are one of the most baffling decisions I have ever seen in any progra

by qsort 5y ago

It might be because my background is CS and not hard science, but non-ASCII variable names are one of the most baffling decisions I have ever seen in any programming language. Whatever reading comprehension advantage they may carry is completely negated by the fact that they can't be typed from a regular keyboard. I hear it's gaining traction, though, so it's likely many of the problems you mention will be fixed or mitigated, eventually.

sannee 5y ago
Supporting the LaTeX expansion is just a necessary feature of any Julia-compatible code editor. It is not then particularly more difficult to type `\sigma` over `sigma`. Also note that other languages often support non-ASCII identifiers as well --- for example, `σ` is a completely valid identifier name in Python (though it is more restrictive than Julia, `σ²` is not valid in Python and yet is valid in Julia). It even works in C, but that might just be a GNU extension.
- jstx1 5y ago
  It's not just identifiers though, it's also operators. To take an example from the OP article, I can't relate to anyone who claims that ∛x is better than cbrt(x). The fact that this is not only allowed but actively encouraged is absolutely baffling to me.
  - maccam912 5y ago
    Eh, I have to diagree on that. A mathematician reading ∛x in code will immediately know what it means, but that isn't necessarily true when seeing cbrt(x). Julia was written for mathematicians, not programmers, and takes some getting used to.
    - jstx1 5y ago
      The mathematician still has to type \cbrt + tab to type the glyph so they have to know the name of the function. Not only that, they have to know the name of the function from reading the Unicode glyph or be constantly pasting characters into the REPL. I don't get how that's more efficient in any way.
      - leephillips 5y ago
        We are in the age of Unicode. The LaTeX entry methods are options, not required. I rarely use them, and don’t paste in characters. I hit a modifier key. Typing a Greek letter is no more inconvenient than typing an uppercase letter.
  - find 5y ago
    The language of science is mathematics, so code that more closely resembles mathematical notation can be more efficient for practicing scientists to understand. There's a lot of value in code that looks like the expression published in the paper, because when another scientist wants to build upon or modify that code, they'll read and understand the paper first, not the package code. Also in physics, sometimes you get really large expressions with a lot of Greek letters and operators. In the paper, you make it a double-wide multiline equation with LaTeX. It makes a big difference if that corresponds to a few lines of Greek symbols in your code, and not twenty.
  - shakow 5y ago
    > I can't relate to anyone who claims that ∛x is better than cbrt(x) I do. It's a simple \cbrt<tab> away in any editor worth their salt, and it greatly improves readability of computation-heavy code – ∛(ϵ² + ξ³) ≤ Φ(π) is much clearer than the ASCII equivalent.
dunefox 5y ago
They can very easily be typed from a regular keyboard, I'm doing it every day. \alpha<TAB>. Also, it's much more readable than typing the characters out like alpha_ij.
huijzer 5y ago
> Whatever reading comprehension advantage they may carry is completely negated by the fact that they can't be typed from a regular keyboard. I also am not really a fan in many cases, but in the case of Bayesian models it makes so much more sense to write "σ" than "sigma". In the case of these complex models, being able to stay closer to the math reduces complexity for the reader. Also, you don't have to use Unicode in your own Julia codebase. It's more of an extra feature which you can use if you want.
hyperjeff 5y ago
> Whatever reading comprehension advantage they may carry is completely negated by the fact that they can't be typed from a regular keyboard. There's a curious blindspot among coders with regard to customizing their main interface with their machines. Keyboards are heavily customizable. Some wins are extremely easy: If you want instant access to all Greek letters on a Mac (e.g.), you can have your caps lock key toggle between your standard layout and the Greek layout. (no \alpha, just α.) The rabbit hole runs deep from there if you are adventurous. Look at all the option key symbols you don't use. Swap them out for nice things like real arrows, ∈, and whatever you fancy. Maybe you have restraints or biases about work code being all ASCII, but typeability is up to you.
- qsort 5y ago
  Customization is a double edged sword though. A keyboard is simple and universal, and it's always the same, my skills transfer between machines, operating systems, languages, software, etc. Yes, it's just muscle memory and you can always re-train it, but there's very little return for my investment. > Maybe you have restraints or biases about work code being all ASCII I'm heavily biased towards all-ASCII for everything except explicitly multilingual contexts (UIs, display formats, browsers, document editing, etc.). As far as I'm concerned, any byte set to any value above 127 in any source file should be a compile-time error. A few reasons why: - It's basically guaranteed something somewhere will screw up the encoding. ASCII is the safest subset. - Better ability to quickly, reliably input characters across machines and tech stacks. - Easy to memorize. Characters are easily and immediately recognizable by everyone worldwide. - Some fonts might lack support for some non-ASCII characters. - Many non-ASCII characters are just plain unreadable. On my screen, lowercase alpha looks like a lowercase latin "A". I can see an argument for allowing non-ASCII characters inside string literals and comments, but with non-ASCII identifiers you're just looking for trouble.
  - hyperjeff 5y ago
    > Yes, it's just muscle memory and you can always re-train it, but there's very little return for my investment. As a data point of one, I've found the return to be enormous and the investment suprisingly small. You have a whole lifetime of typing ahead, so what's a small investment of time compared to that? Just something to consider. > As far as I'm concerned, any byte set to any value above 127 in any source file should be a compile-time error. People can vote by using the languages and tools they want, but I have been waiting for that limitation to die for quite some time. I also use function names longer than 6 characters. That said, I realize I'm lucky enough to be in charge of my own programming environments and don't have to worry about its adoption in unknown limited scenarios. > I can see an argument for allowing non-ASCII characters inside string literals and comments, but with non-ASCII identifiers you're just looking for trouble. Again, just as a data point, I've never found this to be an issue (if one is prudent and not obnoxious with it), though the language support needs to be in place. In my main language these days, Swift, it's fine. Julia and Kotlin too.

by qsort 5y ago

sannee 5y ago

Supporting the LaTeX expansion is just a necessary feature of any Julia-compatible code editor. It is not then particularly more difficult to type `\sigma` over `sigma`. Also note that other languages often support non-ASCII identifiers as well --- for example, `σ` is a completely valid identifier name in Python (though it is more restrictive than Julia, `σ²` is not valid in Python and yet is valid in Julia). It even works in C, but that might just be a GNU extension.

jstx1 5y ago
It's not just identifiers though, it's also operators. To take an example from the OP article, I can't relate to anyone who claims that ∛x is better than cbrt(x). The fact that this is not only allowed but actively encouraged is absolutely baffling to me.
- maccam912 5y ago
  Eh, I have to diagree on that. A mathematician reading ∛x in code will immediately know what it means, but that isn't necessarily true when seeing cbrt(x). Julia was written for mathematicians, not programmers, and takes some getting used to.
  - jstx1 5y ago
    The mathematician still has to type \cbrt + tab to type the glyph so they have to know the name of the function. Not only that, they have to know the name of the function from reading the Unicode glyph or be constantly pasting characters into the REPL. I don't get how that's more efficient in any way.
    - leephillips 5y ago
      We are in the age of Unicode. The LaTeX entry methods are options, not required. I rarely use them, and don’t paste in characters. I hit a modifier key. Typing a Greek letter is no more inconvenient than typing an uppercase letter.
- find 5y ago
  The language of science is mathematics, so code that more closely resembles mathematical notation can be more efficient for practicing scientists to understand. There's a lot of value in code that looks like the expression published in the paper, because when another scientist wants to build upon or modify that code, they'll read and understand the paper first, not the package code. Also in physics, sometimes you get really large expressions with a lot of Greek letters and operators. In the paper, you make it a double-wide multiline equation with LaTeX. It makes a big difference if that corresponds to a few lines of Greek symbols in your code, and not twenty.
- shakow 5y ago
  > I can't relate to anyone who claims that ∛x is better than cbrt(x) I do. It's a simple \cbrt<tab> away in any editor worth their salt, and it greatly improves readability of computation-heavy code – ∛(ϵ² + ξ³) ≤ Φ(π) is much clearer than the ASCII equivalent.

dunefox 5y ago

They can very easily be typed from a regular keyboard, I'm doing it every day. \alpha<TAB>. Also, it's much more readable than typing the characters out like alpha_ij.

huijzer 5y ago

> Whatever reading comprehension advantage they may carry is completely negated by the fact that they can't be typed from a regular keyboard. I also am not really a fan in many cases, but in the case of Bayesian models it makes so much more sense to write "σ" than "sigma". In the case of these complex models, being able to stay closer to the math reduces complexity for the reader. Also, you don't have to use Unicode in your own Julia codebase. It's more of an extra feature which you can use if you want.

hyperjeff 5y ago

> Whatever reading comprehension advantage they may carry is completely negated by the fact that they can't be typed from a regular keyboard. There's a curious blindspot among coders with regard to customizing their main interface with their machines. Keyboards are heavily customizable. Some wins are extremely easy: If you want instant access to all Greek letters on a Mac (e.g.), you can have your caps lock key toggle between your standard layout and the Greek layout. (no \alpha, just α.) The rabbit hole runs deep from there if you are adventurous. Look at all the option key symbols you don't use. Swap them out for nice things like real arrows, ∈, and whatever you fancy. Maybe you have restraints or biases about work code being all ASCII, but typeability is up to you.

qsort 5y ago
Customization is a double edged sword though. A keyboard is simple and universal, and it's always the same, my skills transfer between machines, operating systems, languages, software, etc. Yes, it's just muscle memory and you can always re-train it, but there's very little return for my investment. > Maybe you have restraints or biases about work code being all ASCII I'm heavily biased towards all-ASCII for everything except explicitly multilingual contexts (UIs, display formats, browsers, document editing, etc.). As far as I'm concerned, any byte set to any value above 127 in any source file should be a compile-time error. A few reasons why: - It's basically guaranteed something somewhere will screw up the encoding. ASCII is the safest subset. - Better ability to quickly, reliably input characters across machines and tech stacks. - Easy to memorize. Characters are easily and immediately recognizable by everyone worldwide. - Some fonts might lack support for some non-ASCII characters. - Many non-ASCII characters are just plain unreadable. On my screen, lowercase alpha looks like a lowercase latin "A". I can see an argument for allowing non-ASCII characters inside string literals and comments, but with non-ASCII identifiers you're just looking for trouble.
- hyperjeff 5y ago
  > Yes, it's just muscle memory and you can always re-train it, but there's very little return for my investment. As a data point of one, I've found the return to be enormous and the investment suprisingly small. You have a whole lifetime of typing ahead, so what's a small investment of time compared to that? Just something to consider. > As far as I'm concerned, any byte set to any value above 127 in any source file should be a compile-time error. People can vote by using the languages and tools they want, but I have been waiting for that limitation to die for quite some time. I also use function names longer than 6 characters. That said, I realize I'm lucky enough to be in charge of my own programming environments and don't have to worry about its adoption in unknown limited scenarios. > I can see an argument for allowing non-ASCII characters inside string literals and comments, but with non-ASCII identifiers you're just looking for trouble. Again, just as a data point, I've never found this to be an issue (if one is prudent and not obnoxious with it), though the language support needs to be in place. In my main language these days, Swift, it's fine. Julia and Kotlin too.