6 ms·

Julia has a bunch of little niceties for mathematics: * Prefixing a variable with a scaler will implicitly multiply, as in standard math notation (e.g. 3x woul

Julia has a bunch of little niceties for mathematics: * Prefixing a variable with a scaler will implicitly multiply, as in standard math notation (e.g. 3x would evaluate to 6 if x is 2) * Lots of unicode support. Some feel almost gratuitous (∈ and ∉ are operators that work as you would expect) but it's pretty nice to have π predefined (it's even an irrational datatype) and to use √ as an operator (e.g. √2 is a valid expression and evaluates to a float). It's not just that Julia supports these constructions but provides a convenient way to get them to appear. * This is a little less relevant for calculus but vectors and matrices are fist class types in Julia. Entering and visually parsing matrices is so much easier in Julia than in Python. m = [1 2 3; 4 5 6; 7 8 9] vs. m = [[1, 2, 3], [4, 5, 6], [7, 8, 9]] Transposition is a single character operator ('). Dot product can be done with the dot operator (m ⋅ n). A\b works as it does in matlab. * Julia supports broadcasting. It also has comprehensions but with broadcasting I personally find much less need for comprehensions. * Rationals are built-in with very simple syntax (1//2))

RivieraKid 2y ago
I quite like and use Julia but wish there was a language mixing the best aspects of Julia and Swift (which I think can be done without many compromises, i.e. it would be a better language overall). Some things I don't like about Julia: - array.mean().round(digits=2) is more readable than round(mean(array), digits=2) - Poor support for OOP (no, pure FP is not the optimal programming approach).
- patagurbon 2y ago
  You can overload your own types to get a lot of those things (poor support for OOP is harder but you can sort of emulate it with traits). Overloading `getproperty` for the former case. Of course it's not built in, which I understand is annoying if that's your preferred coding style. I personally am sad that really good traits aren't encoded in the language.
- abisen 2y ago
  If I am not using named arguments I find myself using the pipe operator a lot. I also find it more readable. array |> mean |> round For scenarios with named arguments there is a little not so cleaner workaround array |> mean |> x->round(x, digits=2)
  - andyferris 2y ago
    array |> mean |> round(; digits=2) should also work and is a bit more concise.
    - SatvikBeri 2y ago
      This doesn't work, at least for me on 1.10. `round(; digits=2)` would have to produce a function. But Julia doesn't have automatic currying, so that only happens if someone has implemented a special-case version (e.g. (==)(3) returns a partial function that tests for equality with 3.)
- staplung 2y ago
  Well, Julia also has a pipeline operator built in so: array |> mean |> x->round(x; digits=2) will do what you want and is arguably more readable than dot notation. Not supporting OOP is very much intentional. It has structs and multiple dispatch (which has proven to be insanely useful in Julia's domain of scientific computing) so about the only thing you lose is the namespacing that dot syntax facilitates.
  - deleted 2y ago
    [deleted]
  - brabel 2y ago
    That's not more readable, you're just switching a few characters. Any language that has Uniform Function Call Syntax (UFCS) [1] lets you replace wrapped function calls with linear calls like that, it's clearly easier to read, and much easier to write, specially when you consider programmers' tooling (in case it's not obvious why: you can type the name of a symbol and a '.' and the IDE shows you the available functions... this works also for free functions that take the symbol's type as the first argument as well.... that could work for the pipe operator as well, of course, that's why I said that the two things are basically equivalent, just with slightly different notation). [1] https://en.wikipedia.org/wiki/Uniform_Function_Call_Syntax https://en.wikipedia.org/wiki/Uniform_Function_Call_Syntax
- abdullahkhalids 2y ago
  > round(mean(array), digits=2) is how mathematicians have thought for hundreds of years now. They do so in this way, because it's indeed easier to parse, and philosophically it correctly represents what is happening mathematically. > array.mean().round(digits=2) is how a subset of software engineers have thought about computation in the last couple of decades. Technology should whenever possible adopt already existing conventions, because technology is created to serve the user, and not vice versa.
  - adastra22 2y ago
    > is how mathematicians have thought for hundreds of years now. "Because tradition" is not a good argument. We can and should strive for better. The modern OOP-derived style of `array.mean().round(digits=2)` is just as exact in its specification, and arguably more semantically precise as well as it organizes the meaningful bits to be together. Also I think you don't account for how much mathematical notation has changed over the years. The `round(mean(array), digits=2)` structure is relatively recent, early 20th century I believe, and the result of active reforms.
    - FabHK 2y ago
      I used to miss "OOP" in Julia. The funny thing about the dot notation is that it makes the limitations of single dispatch seem natural. Once you get used to multiple dispatch and its benefits, the dot notation seems limiting. `x.plus(y)` dispatches based on (runtime) type of x (polymorphism) (single dispatch), and might call different functions based on the (compile time) type of y (function overloading). In Julia, it would be `plus(x, y)`, and it can dispatch based on the runtime type of both x and y (or determine the correct method to call at compile time already, if the types of x and y can be determined then).
      - adastra22 2y ago
        Virtual method dispatch isn’t always a good thing though. It’s a tradeoff and typically you really want one or the other. C++ makes both available for that reason, although C++’s syntax is horrible.
- ssivark 2y ago
  > Poor support for OOP (no, pure FP is not the optimal programming approach). Julia is not really a pure functional programming language, though it does support that style if one desires. It's actually a "multiple dispatch" language... thinking of OOP as single dispatch, Julia is conceptually OOP on steroids -- but to benefit from the full expressiveness, the programming style looks different from the typical OOP syntax/patterns one is used to.
  - waveBidder 2y ago
    having spent my PhD writing in Julia, coming back to object oriented programming felt like programming with a hand tied to my back. many operations just make more sense dispatching on multiple arguments rather than just one, and. cramming methods into a class felt unnatural
- neonsunset 2y ago
  F#. For example: https://diffsharp.github.io/index.html https://diffsharp.github.io/index.html
- pjmlp 2y ago
  Interesting remark about poor OOP support, when multi-methods and their interaction with protocols are two cool CLOS features yet to be fully embraced mainstream.
3abiton 2y ago
But why would be better than Mathematica for example for calculus?
- moelf 2y ago
  it's very hard to argue anything is "better" than Wolfram/Mathematica when it comes to symbolic stuff, after all, most theoretical physicists use Mathematica for their professional work. But for (entry-level) learning and possibly pivoting to application, Julia is delightful to use and can transit into some symbolics and numerical. Besides, it's free and open source.
  - llm_trw 2y ago
    >most theoretical physicists use Mathematica for their professional work. They do not.
    - fiforpg 2y ago
      Surely, many do? The ones I interacted with did, for example. I'd venture that the preferred CAS varies with schools and countries.
      - llm_trw 2y ago
        Some do, most don't. Unless you're working on undergraduate integrals then it's pretty useless for advanced stuff without writing your own library. By that point you may as well write it in a language that's more performant and cheaper.
        abdullahkhalids 2y ago
        I agree that only some physicists use Mathematica. But I haven't really seen it being used it for calculus. Maybe some differential equations. But mostly for symbolic algebriac manipulation. I used it during my phd to work with groups. Instead of having to calculate stuff by hand, you can just ask Mathematica to do it. Also lots of stuff with tensors in GR is so easy to do in Mathematica.
llm_trw 2y ago
m = [[1, 2, 3], [4, 5, 6], [7, 8, 9]]
eggy 2y ago
I like Julia and Python, however when I'm playing with doing math, or using paper, I like APL or J. The above example in J: 3 3 $ i.9 0 1 2 3 4 5 6 7 8 3 3 $ >: i.9 1 2 3 4 5 6 7 8 9 J is 0-indexed. ">:" is the increment operator. APL allows you to set a parameter to do 1-indexed vs. 0-indexed. APL: 3 3 ρ ι9 1 2 3 4 5 6 7 8 9 There is a Calculus text for learning it with J: https://www.jsoftware.com/books/pdf/calculus.pdf https://www.jsoftware.com/books/pdf/calculus.pdf
- garbthetill 2y ago
  interesting, i was thinking of sharping my maths skill by programming. Have you tried something like lean, agda etc if so how do they fair against apl or j for doing maths I honestly thought apl was extinct
  - eggy 2y ago
    I've tried Idris. J and APL are great for quick analysis once you know them. I leave J open on my desktop for engineering and stats. Frink too for effortless units work. Haskell and its ilk are good for math. Programming to learn math works really well for some, since you work through a problem incrementally, especially with dynamic interpreters and REPLs. Pluto with Julia or Jupyter with Python or Mathematica too.

RivieraKid 2y ago

I quite like and use Julia but wish there was a language mixing the best aspects of Julia and Swift (which I think can be done without many compromises, i.e. it would be a better language overall). Some things I don't like about Julia: - array.mean().round(digits=2) is more readable than round(mean(array), digits=2) - Poor support for OOP (no, pure FP is not the optimal programming approach).

patagurbon 2y ago
You can overload your own types to get a lot of those things (poor support for OOP is harder but you can sort of emulate it with traits). Overloading `getproperty` for the former case. Of course it's not built in, which I understand is annoying if that's your preferred coding style. I personally am sad that really good traits aren't encoded in the language.
abisen 2y ago
If I am not using named arguments I find myself using the pipe operator a lot. I also find it more readable. array |> mean |> round For scenarios with named arguments there is a little not so cleaner workaround array |> mean |> x->round(x, digits=2)
- andyferris 2y ago
  array |> mean |> round(; digits=2) should also work and is a bit more concise.
  - SatvikBeri 2y ago
    This doesn't work, at least for me on 1.10. `round(; digits=2)` would have to produce a function. But Julia doesn't have automatic currying, so that only happens if someone has implemented a special-case version (e.g. (==)(3) returns a partial function that tests for equality with 3.)
staplung 2y ago
Well, Julia also has a pipeline operator built in so: array |> mean |> x->round(x; digits=2) will do what you want and is arguably more readable than dot notation. Not supporting OOP is very much intentional. It has structs and multiple dispatch (which has proven to be insanely useful in Julia's domain of scientific computing) so about the only thing you lose is the namespacing that dot syntax facilitates.
- deleted 2y ago
  [deleted]
- brabel 2y ago
  That's not more readable, you're just switching a few characters. Any language that has Uniform Function Call Syntax (UFCS) [1] lets you replace wrapped function calls with linear calls like that, it's clearly easier to read, and much easier to write, specially when you consider programmers' tooling (in case it's not obvious why: you can type the name of a symbol and a '.' and the IDE shows you the available functions... this works also for free functions that take the symbol's type as the first argument as well.... that could work for the pipe operator as well, of course, that's why I said that the two things are basically equivalent, just with slightly different notation). [1] https://en.wikipedia.org/wiki/Uniform_Function_Call_Syntax https://en.wikipedia.org/wiki/Uniform_Function_Call_Syntax
abdullahkhalids 2y ago
> round(mean(array), digits=2) is how mathematicians have thought for hundreds of years now. They do so in this way, because it's indeed easier to parse, and philosophically it correctly represents what is happening mathematically. > array.mean().round(digits=2) is how a subset of software engineers have thought about computation in the last couple of decades. Technology should whenever possible adopt already existing conventions, because technology is created to serve the user, and not vice versa.
- adastra22 2y ago
  > is how mathematicians have thought for hundreds of years now. "Because tradition" is not a good argument. We can and should strive for better. The modern OOP-derived style of `array.mean().round(digits=2)` is just as exact in its specification, and arguably more semantically precise as well as it organizes the meaningful bits to be together. Also I think you don't account for how much mathematical notation has changed over the years. The `round(mean(array), digits=2)` structure is relatively recent, early 20th century I believe, and the result of active reforms.
  - FabHK 2y ago
    I used to miss "OOP" in Julia. The funny thing about the dot notation is that it makes the limitations of single dispatch seem natural. Once you get used to multiple dispatch and its benefits, the dot notation seems limiting. `x.plus(y)` dispatches based on (runtime) type of x (polymorphism) (single dispatch), and might call different functions based on the (compile time) type of y (function overloading). In Julia, it would be `plus(x, y)`, and it can dispatch based on the runtime type of both x and y (or determine the correct method to call at compile time already, if the types of x and y can be determined then).
    - adastra22 2y ago
      Virtual method dispatch isn’t always a good thing though. It’s a tradeoff and typically you really want one or the other. C++ makes both available for that reason, although C++’s syntax is horrible.
ssivark 2y ago
> Poor support for OOP (no, pure FP is not the optimal programming approach). Julia is not really a pure functional programming language, though it does support that style if one desires. It's actually a "multiple dispatch" language... thinking of OOP as single dispatch, Julia is conceptually OOP on steroids -- but to benefit from the full expressiveness, the programming style looks different from the typical OOP syntax/patterns one is used to.
- waveBidder 2y ago
  having spent my PhD writing in Julia, coming back to object oriented programming felt like programming with a hand tied to my back. many operations just make more sense dispatching on multiple arguments rather than just one, and. cramming methods into a class felt unnatural
neonsunset 2y ago
F#. For example: https://diffsharp.github.io/index.html https://diffsharp.github.io/index.html
pjmlp 2y ago
Interesting remark about poor OOP support, when multi-methods and their interaction with protocols are two cool CLOS features yet to be fully embraced mainstream.

3abiton 2y ago

But why would be better than Mathematica for example for calculus?

moelf 2y ago
it's very hard to argue anything is "better" than Wolfram/Mathematica when it comes to symbolic stuff, after all, most theoretical physicists use Mathematica for their professional work. But for (entry-level) learning and possibly pivoting to application, Julia is delightful to use and can transit into some symbolics and numerical. Besides, it's free and open source.
- llm_trw 2y ago
  >most theoretical physicists use Mathematica for their professional work. They do not.
  - fiforpg 2y ago
    Surely, many do? The ones I interacted with did, for example. I'd venture that the preferred CAS varies with schools and countries.
    - llm_trw 2y ago
      Some do, most don't. Unless you're working on undergraduate integrals then it's pretty useless for advanced stuff without writing your own library. By that point you may as well write it in a language that's more performant and cheaper.
      - abdullahkhalids 2y ago
        I agree that only some physicists use Mathematica. But I haven't really seen it being used it for calculus. Maybe some differential equations. But mostly for symbolic algebriac manipulation. I used it during my phd to work with groups. Instead of having to calculate stuff by hand, you can just ask Mathematica to do it. Also lots of stuff with tensors in GR is so easy to do in Mathematica.

llm_trw 2y ago

m = [[1, 2, 3], [4, 5, 6], [7, 8, 9]]

eggy 2y ago

I like Julia and Python, however when I'm playing with doing math, or using paper, I like APL or J. The above example in J: 3 3 $ i.9 0 1 2 3 4 5 6 7 8 3 3 $ >: i.9 1 2 3 4 5 6 7 8 9 J is 0-indexed. ">:" is the increment operator. APL allows you to set a parameter to do 1-indexed vs. 0-indexed. APL: 3 3 ρ ι9 1 2 3 4 5 6 7 8 9 There is a Calculus text for learning it with J: https://www.jsoftware.com/books/pdf/calculus.pdf https://www.jsoftware.com/books/pdf/calculus.pdf

garbthetill 2y ago
interesting, i was thinking of sharping my maths skill by programming. Have you tried something like lean, agda etc if so how do they fair against apl or j for doing maths I honestly thought apl was extinct
- eggy 2y ago
  I've tried Idris. J and APL are great for quick analysis once you know them. I leave J open on my desktop for engineering and stats. Frink too for effortless units work. Haskell and its ilk are good for math. Programming to learn math works really well for some, since you work through a problem incrementally, especially with dynamic interpreters and REPLs. Pluto with Julia or Jupyter with Python or Mathematica too.