7 ms·

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

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.

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.