4 ms·

> 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 p

> 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.
    - jakobnissen 2y ago
      It's multiple dispatch though, not virtual dispatch. If I understand correctly, virtual dispatch means the method is picked at runtime. In Julia, the compiler is able to pick the correct method at compile time, even when dispatching on all arguments of the function.
      - samatman 2y ago
        This is correct, but it's important to realize that compile time continues during runtime. Julia's execution model is quite distinctive, and it does take a thorough understanding of how it plays out to get native-code speeds out of it.
- abdullahkhalids 2y ago
  > mathematical notation has changed over the years. I agree. Math notation has changed in response to problems mathematicians have faced, and as their thinking have evolved. It should not change because tool builders for mathematicians - when the tool builders in most cases are not even professional mathematicians - decide some other notation is better. > array.mean().round(digits=2) might be good (it is not) when you are operating on one object. As soon as you have a binary operation (say multiplication), this notation completely breaks down. Because the operation is often symmetric, or "near" symmetric, meaning it is not so different as to write something as ridiculous as x.product(y). But more importantly, (common/dominant) mathematics is functional in nature. It's decidedly not object oriented. Given a matrix, M, doing something like M.eigenvalues() is vomit-inducing because eigenvalues is not a property of a matrix M. For matrices, its a map from a set of linear transformations (of which M is merely one item) onto a set of numbers. It is its own thing, separate from M.
  - adastra22 2y ago
    Now you're gatekeeping on who is a real mathematician? I don't think this subthread is going to be productive and I'm bowing out.
    - nightlyherb 2y ago
      I'm not the GP, but I'm sorry you felt gatekeeped. I don't think GP conveyed "real mathematicians should do FP", but rather something else, so I'll try my best to share what I understood from that comment. Hope this makes you feel better. Even though the notation changed over the years, the paradigm of "numbers as immutable entities and pure functions" has been the dominant way that math is presented, compared to something like "encapsulated objects that interact with each other via sending messages". I don't think this has to be this way, and I do think that "real math" can also be laid out assuming principles of OOP. However, I do suspect it's the way it is because the laws of nature are unchanging, in contrast to the logic of a business application. Because Julia is a tool with the target audience of mathematicians and scientists, I think it's a sensible decision to embrace the usual way of thinking, as opposed to presenting a relatively different way of thinking which steepens the learning curve. Not because data and functions are fundamentally better than OOP, but because it's more pragmatic for the target audience.
- nightlyherb 2y ago
  As a person who respects many programming paradigms including OOP and FP, I beg to disagree. Specifically, I'm assuming you're talking about OOP the paradigm, not only the dot notation, for which the pipe operator is a viable alternative. > 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. I would have agreed with you if I were developing business applications. However, for the domain of math and science, every piece of material that I have seen assumes the paradigm of numbers as immutable entities and functions, not the paradigm of mutable encapsulated objects and interacting messages. To a mathematician or scientist the semantics of a `Vector` (as data) and a `mean` function that takes the `Vector` as input should be more natural than a black-box `Vector` object that can receive a `mean` method.
deleted 2y ago
[deleted]
RivieraKid 2y ago
To me, the second is more readable, more pleasant to work with especially if you're using an IDE. And ultimately, it leads to higher productivity. It may be philosophically correct per some definition of philosophically correct but this is not what I care about.
- DNF2 2y ago
  In some cases, applying a limited set of basic operations might make up a significant part of development time, but in my experience most of the time is spent designing algorithms, parsing function input and managing the flow of vectorized expressions across function boundaries. And that is generally more efficient in the context of multiple dispatch with efficient loops. For example, writing a function that works on scalars, then mapping or broadcasting it over array input is very good for productivity (and is efficient in Julia). On the other hand, designing an inherently array-based algorithm is often a headache that one must contend with for the sake of performance in numpy. So, if you design somewhat complex or novel algorithms, I don't think object-dot notation, or the lack thereof, has a significant impact on productivity.

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.
  - jakobnissen 2y ago
    It's multiple dispatch though, not virtual dispatch. If I understand correctly, virtual dispatch means the method is picked at runtime. In Julia, the compiler is able to pick the correct method at compile time, even when dispatching on all arguments of the function.
    - samatman 2y ago
      This is correct, but it's important to realize that compile time continues during runtime. Julia's execution model is quite distinctive, and it does take a thorough understanding of how it plays out to get native-code speeds out of it.
abdullahkhalids 2y ago
> mathematical notation has changed over the years. I agree. Math notation has changed in response to problems mathematicians have faced, and as their thinking have evolved. It should not change because tool builders for mathematicians - when the tool builders in most cases are not even professional mathematicians - decide some other notation is better. > array.mean().round(digits=2) might be good (it is not) when you are operating on one object. As soon as you have a binary operation (say multiplication), this notation completely breaks down. Because the operation is often symmetric, or "near" symmetric, meaning it is not so different as to write something as ridiculous as x.product(y). But more importantly, (common/dominant) mathematics is functional in nature. It's decidedly not object oriented. Given a matrix, M, doing something like M.eigenvalues() is vomit-inducing because eigenvalues is not a property of a matrix M. For matrices, its a map from a set of linear transformations (of which M is merely one item) onto a set of numbers. It is its own thing, separate from M.
- adastra22 2y ago
  Now you're gatekeeping on who is a real mathematician? I don't think this subthread is going to be productive and I'm bowing out.
  - nightlyherb 2y ago
    I'm not the GP, but I'm sorry you felt gatekeeped. I don't think GP conveyed "real mathematicians should do FP", but rather something else, so I'll try my best to share what I understood from that comment. Hope this makes you feel better. Even though the notation changed over the years, the paradigm of "numbers as immutable entities and pure functions" has been the dominant way that math is presented, compared to something like "encapsulated objects that interact with each other via sending messages". I don't think this has to be this way, and I do think that "real math" can also be laid out assuming principles of OOP. However, I do suspect it's the way it is because the laws of nature are unchanging, in contrast to the logic of a business application. Because Julia is a tool with the target audience of mathematicians and scientists, I think it's a sensible decision to embrace the usual way of thinking, as opposed to presenting a relatively different way of thinking which steepens the learning curve. Not because data and functions are fundamentally better than OOP, but because it's more pragmatic for the target audience.
nightlyherb 2y ago
As a person who respects many programming paradigms including OOP and FP, I beg to disagree. Specifically, I'm assuming you're talking about OOP the paradigm, not only the dot notation, for which the pipe operator is a viable alternative. > 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. I would have agreed with you if I were developing business applications. However, for the domain of math and science, every piece of material that I have seen assumes the paradigm of numbers as immutable entities and functions, not the paradigm of mutable encapsulated objects and interacting messages. To a mathematician or scientist the semantics of a `Vector` (as data) and a `mean` function that takes the `Vector` as input should be more natural than a black-box `Vector` object that can receive a `mean` method.

deleted 2y ago

[deleted]

RivieraKid 2y ago

To me, the second is more readable, more pleasant to work with especially if you're using an IDE. And ultimately, it leads to higher productivity. It may be philosophically correct per some definition of philosophically correct but this is not what I care about.

DNF2 2y ago
In some cases, applying a limited set of basic operations might make up a significant part of development time, but in my experience most of the time is spent designing algorithms, parsing function input and managing the flow of vectorized expressions across function boundaries. And that is generally more efficient in the context of multiple dispatch with efficient loops. For example, writing a function that works on scalars, then mapping or broadcasting it over array input is very good for productivity (and is efficient in Julia). On the other hand, designing an inherently array-based algorithm is often a headache that one must contend with for the sake of performance in numpy. So, if you design somewhat complex or novel algorithms, I don't think object-dot notation, or the lack thereof, has a significant impact on productivity.