6 ms·

As has been pointed out, Julia is not limited to a single thread. It's actually got a pretty good support for parallelism both at the thread and process level.

As has been pointed out, Julia is not limited to a single thread. It's actually got a pretty good support for parallelism both at the thread and process level. And no, Julia is not too similar to Python. Julia has multiple dispatch, Python does not.

xbpx 5y ago
Another point that is often lost is how mathematical Julia code can look, especially for matrix functions. Yeh this is superficial, but so are 200 dollar sneakers and they do just fine. Honestly there is a real pleasure writing code that looks like it could be on the blackboard. The numpy / numba world in Python just feels... not great.
- Tarq0n 5y ago
  I actually consider that a negative. Mathematical notation is fine when you're dealing with limited space on a blackboard, but if you're programming please name your name variables and take the time to model your domain explicitly.
  - chaxor 5y ago
    I don't understand - what is wrong with condensing the python representation `sum_of_lambda_for_each_psi` to `Σλ∀φ`? It seems that 4 symbols is much quicker and easier to read than a slew of snake case stuff.
    - TheRealKing 5y ago
      So, one-letter English labels were deemed bad coding-style for decades, but suddenly one-letter Greek labels are good because some X-language (Julia) supports it. Seriously? How about single-letter Chinese labels? because that is my background and that is what I am comfortable using.
      - fault1 5y ago
        well, you can always program in wenyan: https://github.com/wenyan-lang/wenyan https://github.com/wenyan-lang/wenyan But seriously, it's 2021. We are no longer slave to ASCII, or even English. Most of the newer math oriented langs have heavy use of unicode (julia, agda, lean, etc).
      - dTal 5y ago
        One-letter variables aren't always bad coding style. Some single letters are meaningful. It's conventional to use 'i' for an array iterator, for instance - or i and j for two dimensional iteration. x,y, and z are cartesian coordinates. It would be downright perverse not to call the base of the natural logarithm 'e'. And so it is with greek letters. Many of them carry intrinsic meaning, or a loose collection of related meanings - they effectively are labels. It's not that people want to write dense and impenetrable code, it's that they would rather write μ than coefficient_of_friction because that is its proper name and how it appears in formulas and textbooks.
    - hnarayanan 5y ago
      For each phi?
    - joconde 5y ago
      I'm not completely sure that you aren't joking. Maybe for a mathematician the latter would be "very readable"?
      - mbeex 5y ago
        Indeed it is (slight improvements not excluded). I would love to be able to write things like M<sup>T</sup>A (w/o the HTML rubbish seen here - flavour of the same problem) for two matrices directly as code (can Julia do that?). Instead, I've been forced to learn row and column precedence in OpenGL, DirectX, Numpy, and whatever, paying attention to it in endless constructs. Even after 25 years in the business, it's still a pain.
        joconde 5y ago
        What about everything that isn't yet represented by widely-adopted mathematical notation? I'd hate to have to learn which Greek letters correspond to which operations every time I dive into a new codebase. The advantage of English words is that everyone knows them. Edit for details: `Σλ∀φ` is a chore to read for me. These letters only make sense if I've absorbed the author's notation beforehand, like in a math proof. I parse the snake case version instantly, because my brain is trained for that. And I understand it much more quickly, because it says exactly what the function does in the way I would represent it in memory.
        goerz 5y ago
        We’re talking in a context of scientific software here. > I'd hate to have to learn which Greek letters correspond to which operations every time I dive into a new codebase. You have to do that anyway, because you’ll have to connect the code you’re working on with the scientific paper describing it. When the code uses variable names too far removed from the mathematical symbols, you have to do make two steps: figure out how the words connect to symbols and then figure out the symbols. This will be especially difficult for the mathematician/scientist without a strong coding background: they’ll have much less friction reading code that matches the symbolic notation and Greek letters that they’re used to. > The advantage of English words is that everyone knows them. Not when it comes to “math” words. > `Σλ∀φ` is a chore to read for me. Right, but that’s because you have a different background. For me, `Σλ∀φ` is much easier to read and understand. More importantly, a symbolic notation is much denser, which allows to parse long expression that would be very hard to understand if they were written out in words. Again, this is for the very specific context of highly mathematical/scientific software that Julia excels at and is primarily used for. In a more general context (when the software isn’t a direct representation of a scientific paper), I’m 100% on board with good, descriptive variable names
  - fault1 5y ago
    Completely disagreed. I was skeptical originally, because I wasn't used to seeing unicode symbols in code, but in certain types of mathematical code, it makes it /far/ clearer because your brain can link to the appropriate symbols in textbooks. To me, it's a matter of familiarity. clearly human brains can process large amount of symbols. Just look at some east asian languages. Historically, there has been an ASCII bias in computer languages, but that is history. Mathematics is a /language/, and one of the most universal in humanity because it models certain human reasoning.
    - jkhdigital 5y ago
      To your point, for personal projects in Elixir I’ve started using Japanese characters for function names because they can be so much more terse.
- sgt101 5y ago
  This is really useful when relating Julia code to a paper or providing it as part of a paper - there is very little lost in translation.

xbpx 5y ago

Another point that is often lost is how mathematical Julia code can look, especially for matrix functions. Yeh this is superficial, but so are 200 dollar sneakers and they do just fine. Honestly there is a real pleasure writing code that looks like it could be on the blackboard. The numpy / numba world in Python just feels... not great.

Tarq0n 5y ago
I actually consider that a negative. Mathematical notation is fine when you're dealing with limited space on a blackboard, but if you're programming please name your name variables and take the time to model your domain explicitly.
- chaxor 5y ago
  I don't understand - what is wrong with condensing the python representation `sum_of_lambda_for_each_psi` to `Σλ∀φ`? It seems that 4 symbols is much quicker and easier to read than a slew of snake case stuff.
  - TheRealKing 5y ago
    So, one-letter English labels were deemed bad coding-style for decades, but suddenly one-letter Greek labels are good because some X-language (Julia) supports it. Seriously? How about single-letter Chinese labels? because that is my background and that is what I am comfortable using.
    - fault1 5y ago
      well, you can always program in wenyan: https://github.com/wenyan-lang/wenyan https://github.com/wenyan-lang/wenyan But seriously, it's 2021. We are no longer slave to ASCII, or even English. Most of the newer math oriented langs have heavy use of unicode (julia, agda, lean, etc).
    - dTal 5y ago
      One-letter variables aren't always bad coding style. Some single letters are meaningful. It's conventional to use 'i' for an array iterator, for instance - or i and j for two dimensional iteration. x,y, and z are cartesian coordinates. It would be downright perverse not to call the base of the natural logarithm 'e'. And so it is with greek letters. Many of them carry intrinsic meaning, or a loose collection of related meanings - they effectively are labels. It's not that people want to write dense and impenetrable code, it's that they would rather write μ than coefficient_of_friction because that is its proper name and how it appears in formulas and textbooks.
  - hnarayanan 5y ago
    For each phi?
  - joconde 5y ago
    I'm not completely sure that you aren't joking. Maybe for a mathematician the latter would be "very readable"?
    - mbeex 5y ago
      Indeed it is (slight improvements not excluded). I would love to be able to write things like M<sup>T</sup>A (w/o the HTML rubbish seen here - flavour of the same problem) for two matrices directly as code (can Julia do that?). Instead, I've been forced to learn row and column precedence in OpenGL, DirectX, Numpy, and whatever, paying attention to it in endless constructs. Even after 25 years in the business, it's still a pain.
      - joconde 5y ago
        What about everything that isn't yet represented by widely-adopted mathematical notation? I'd hate to have to learn which Greek letters correspond to which operations every time I dive into a new codebase. The advantage of English words is that everyone knows them. Edit for details: `Σλ∀φ` is a chore to read for me. These letters only make sense if I've absorbed the author's notation beforehand, like in a math proof. I parse the snake case version instantly, because my brain is trained for that. And I understand it much more quickly, because it says exactly what the function does in the way I would represent it in memory.
        goerz 5y ago
        We’re talking in a context of scientific software here. > I'd hate to have to learn which Greek letters correspond to which operations every time I dive into a new codebase. You have to do that anyway, because you’ll have to connect the code you’re working on with the scientific paper describing it. When the code uses variable names too far removed from the mathematical symbols, you have to do make two steps: figure out how the words connect to symbols and then figure out the symbols. This will be especially difficult for the mathematician/scientist without a strong coding background: they’ll have much less friction reading code that matches the symbolic notation and Greek letters that they’re used to. > The advantage of English words is that everyone knows them. Not when it comes to “math” words. > `Σλ∀φ` is a chore to read for me. Right, but that’s because you have a different background. For me, `Σλ∀φ` is much easier to read and understand. More importantly, a symbolic notation is much denser, which allows to parse long expression that would be very hard to understand if they were written out in words. Again, this is for the very specific context of highly mathematical/scientific software that Julia excels at and is primarily used for. In a more general context (when the software isn’t a direct representation of a scientific paper), I’m 100% on board with good, descriptive variable names
- fault1 5y ago
  Completely disagreed. I was skeptical originally, because I wasn't used to seeing unicode symbols in code, but in certain types of mathematical code, it makes it /far/ clearer because your brain can link to the appropriate symbols in textbooks. To me, it's a matter of familiarity. clearly human brains can process large amount of symbols. Just look at some east asian languages. Historically, there has been an ASCII bias in computer languages, but that is history. Mathematics is a /language/, and one of the most universal in humanity because it models certain human reasoning.
  - jkhdigital 5y ago
    To your point, for personal projects in Elixir I’ve started using Japanese characters for function names because they can be so much more terse.
sgt101 5y ago
This is really useful when relating Julia code to a paper or providing it as part of a paper - there is very little lost in translation.