5 ms·

Makes sense to write it in Julia. Pretty much the only non commercial language that deals natively with mathematical objects in a way that makes sense to non CS

by zwaps 7y ago

Makes sense to write it in Julia. Pretty much the only non commercial language that deals natively with mathematical objects in a way that makes sense to non CS people doing statistics. Plus, it is fast out of the box. Like, when I first saw how you work with matrices in Python, I had a stroke. I dont really get why we use Python for everything. The matlab style syntaxt is infinitly better for ML, stats and math.

j88439h84 7y ago
There's progress in Python with the new `a @ b` operator for matrix multiplication.
- ioquatix 7y ago
  The email operator.
  - GorgeRonde 7y ago
    In Romance languages the at-sign is called an arobase/arroba.
    - locoman88 7y ago
      How this is relevant here
valw 7y ago
> The matlab style syntaxt is infinitly better for ML, stats and math. Syntax is a secondary concern for all but short-term, small-scale programming. When it comes to making scalable software systems (scalable in every sense of the term, not just performance but also feature growth etc.), syntax is really not the biggest concern; as such, optimizing for syntax can be detrimental to other more important aspects (e.g composability, reusability, programmability), and focusing on syntax means you're not paying attention to the really critical stuff. I mostly work in Clojure where _all_ operations use prefix syntax (e.g you write (+ A B C) instead of (A + B + C) for addition, and + is just a function). Trust me, it's unfamiliar at first, but it makes reasoning about the program MUCH saner than all the special cases and irregularities that language designer bake into the language just to make some operations infix.
- zwaps 7y ago
  Different things to care about. I have worked on stats in research, start ups and at large banks. A lot of production/infrastructure related things certainly profit from the points you mention. But 99% of statistical applications I have seen differ. For someone using math, "programmability" and the other aspects you mention are certainly higher in a language that emulates how we think about the problems. While indeed Clojure may work well for some areas in math, Julia is certainly appropriate for statistics and probability - in my opinion the best -, and finally, Python isn't very good for either. Everything else is almost always secondary. I would also argue that Julia is absolutely fine for developing large, scalable programs, not worse than Python. Since Clojure has no statistics / ML ecosystem afaik, I am not sure why you mention it. This is absolutely crucial to even being considered in my point. That is why R dominates statistics still, by a large margin.
  - valw 7y ago
    > Since Clojure has no statistics / ML ecosystem afaik, I am not sure why you mention it. I mentioned it to illustrate my point, that semantics and other aspects matter much more than syntax in many cases. (Btw Clojure does have a ML / stats ecosystem, in part via the JVM, though certainly not as developed as Python / Julia / R. For instance, Anglican is a probabilistic programming language embedded in Clojure: https://github.com/probprog/anglican https://github.com/probprog/anglican). > For someone using math, "programmability" and the other aspects you mention are certainly higher in a language that emulates how we think about the problems. Sure, but syntax is just about notation - semantics are much more important to achieving nearness to a mental model. If you can't express your mental model in another notation than the one you're familiar with, then you probably don't have a very deep understanding of said model. Continuing with my example, prefix notation for matrix multiplication does not hurt _at all_ my ability to reason about linear algebra - it sometimes even clarifies it. I also think you misinterpret what I meant by programmability, which is not the same thing as 'ease of programming' - more like how smoothly various parts of a program interact. If for the sake of syntactic sugar you've introduced a proliferation of different programming constructs with no unifying abstraction, then the other parts of the program will need to make a proliferation of case distinctions as well - that's one way to hurt programmability.
bayareanative 7y ago
R, SAS, Octave, Mathematica, MATLAB, Excel (lol), FORTRAN and many more come to mind. Julia seems more like flavor of the month. As an example, I know of a Monte Carlo nuclear reactor simulator that was written in tens of millions of lines of Fortran over a period of 3+ decades by non-software engineer nuclear engineers. Also, have you used an HP 48 calculator? You can snag an emulator app and a ROM to use it on most smartphones, and it does integration and derivation.
- kensai 7y ago
  Comrade Dyatlov? COMRADE DYATLOV?!
  - viksit 7y ago
    I wish HN had gold to give.
- nemaar 7y ago
  Can you tell anything about that simulator? it sounds wild:)

by zwaps 7y ago

j88439h84 7y ago

There's progress in Python with the new `a @ b` operator for matrix multiplication.

ioquatix 7y ago
The email operator.
- GorgeRonde 7y ago
  In Romance languages the at-sign is called an arobase/arroba.
  - locoman88 7y ago
    How this is relevant here

valw 7y ago

> The matlab style syntaxt is infinitly better for ML, stats and math. Syntax is a secondary concern for all but short-term, small-scale programming. When it comes to making scalable software systems (scalable in every sense of the term, not just performance but also feature growth etc.), syntax is really not the biggest concern; as such, optimizing for syntax can be detrimental to other more important aspects (e.g composability, reusability, programmability), and focusing on syntax means you're not paying attention to the really critical stuff. I mostly work in Clojure where _all_ operations use prefix syntax (e.g you write (+ A B C) instead of (A + B + C) for addition, and + is just a function). Trust me, it's unfamiliar at first, but it makes reasoning about the program MUCH saner than all the special cases and irregularities that language designer bake into the language just to make some operations infix.

zwaps 7y ago
Different things to care about. I have worked on stats in research, start ups and at large banks. A lot of production/infrastructure related things certainly profit from the points you mention. But 99% of statistical applications I have seen differ. For someone using math, "programmability" and the other aspects you mention are certainly higher in a language that emulates how we think about the problems. While indeed Clojure may work well for some areas in math, Julia is certainly appropriate for statistics and probability - in my opinion the best -, and finally, Python isn't very good for either. Everything else is almost always secondary. I would also argue that Julia is absolutely fine for developing large, scalable programs, not worse than Python. Since Clojure has no statistics / ML ecosystem afaik, I am not sure why you mention it. This is absolutely crucial to even being considered in my point. That is why R dominates statistics still, by a large margin.
- valw 7y ago
  > Since Clojure has no statistics / ML ecosystem afaik, I am not sure why you mention it. I mentioned it to illustrate my point, that semantics and other aspects matter much more than syntax in many cases. (Btw Clojure does have a ML / stats ecosystem, in part via the JVM, though certainly not as developed as Python / Julia / R. For instance, Anglican is a probabilistic programming language embedded in Clojure: https://github.com/probprog/anglican https://github.com/probprog/anglican). > For someone using math, "programmability" and the other aspects you mention are certainly higher in a language that emulates how we think about the problems. Sure, but syntax is just about notation - semantics are much more important to achieving nearness to a mental model. If you can't express your mental model in another notation than the one you're familiar with, then you probably don't have a very deep understanding of said model. Continuing with my example, prefix notation for matrix multiplication does not hurt _at all_ my ability to reason about linear algebra - it sometimes even clarifies it. I also think you misinterpret what I meant by programmability, which is not the same thing as 'ease of programming' - more like how smoothly various parts of a program interact. If for the sake of syntactic sugar you've introduced a proliferation of different programming constructs with no unifying abstraction, then the other parts of the program will need to make a proliferation of case distinctions as well - that's one way to hurt programmability.

bayareanative 7y ago

R, SAS, Octave, Mathematica, MATLAB, Excel (lol), FORTRAN and many more come to mind. Julia seems more like flavor of the month. As an example, I know of a Monte Carlo nuclear reactor simulator that was written in tens of millions of lines of Fortran over a period of 3+ decades by non-software engineer nuclear engineers. Also, have you used an HP 48 calculator? You can snag an emulator app and a ROM to use it on most smartphones, and it does integration and derivation.

kensai 7y ago
Comrade Dyatlov? COMRADE DYATLOV?!
- viksit 7y ago
  I wish HN had gold to give.
nemaar 7y ago
Can you tell anything about that simulator? it sounds wild:)