5 ms·

> Mathematics seems to be obsessed with one-liners Not at all. Formulas in a math paper always come with at least a paragraph of text explaining them. You aren

> Mathematics seems to be obsessed with one-liners Not at all. Formulas in a math paper always come with at least a paragraph of text explaining them. You aren't supposed to read the formula without the explanation. > Single letter variable names (often from different alphabets) and complex expressions that should be broken down would never make it through a code review ;-) That's done for readability. The text explains the terms of the formula and the formula concisely summarizes the precise relationship between them.

netizen-936824 5y ago
Theoretically, we could do the same with comments no? Make the code extremely compact and explain it, perhaps even in a format like literate programming?
- omaranto 5y ago
  Yes. But it would be tough to change the culture. Math papers are meant to be read, so people pay attention to the explanations. Computer programs (at least if they garner users!) are run much more often than read, so it's natural to focus on the code and neglect the comments.
  - nomel 5y ago
    > But it would be tough to change the culture. I think it would be tougher to find anyone willing to read programs written like this. Requiring an explanation to understand the variables is very similar to encoding the variables names and putting a lookup table below. Why force someones eyes to dart back and forth between the program and lookup table, just to get an idea of what the variable are, rather than also including a very rough explanation of what they variables are doing, in the program itself, by giving them meaningful names? We only have so much working memory. Giving variables names frees up a significant amount.
    - netizen-936824 5y ago
      I've personally written code that was immensely difficult to read. Branchless stuff with single letter variables. Even though I commented it thoroughly, its ridiculously difficult to read and modify. This was a good lesson for me, I won't do that again and I'm far more verbose now. My thinking is that maybe math should learn from things like that as well, perhaps expanding equations and being more verbose within the equation instead of an explanation next to it would make maths more accessible to a broader audience.
      - rq1 5y ago
        After developing equations through 100 lines and few pages or blackboards, you’ll see that dropping letters is inevitable. You shouldn’t really read the equations before understanding what they are about. They are usually written down to get rid of ambiguities of the natural language.
        DennisP 5y ago
        Source code isn't ambiguous either, and tends to get way longer than a hundred lines or a few pages.
        rq1 5y ago
        It’s not a single equation though where you’d need to rewrite the same variables 100 times.
    - omaranto 5y ago
      I guess it depends on how concrete the code is. For very general things there just are no good names. I see the point in calling a variable anualSalary, say, but in a function for reversing a list is elementOfList really better than element or than x (which would be my preference)? This, by the way, is probably the main reason math uses single letters for names (with some rules of thumb that hint at the type, like n for an integer, X for a scheme, calligraphic F for a sheaf, etc.).
    - 5y ago
- xvector 5y ago
  The problem is that code comments tend to skew from the actual code over time. Let's just stick with readable code everywhere.
- kragen 5y ago
  I think this is an interesting and promising idea. Code that doesn't exist can't have bugs, and when you're just fooling around rather than writing production code you can just write the formulas without the explanation. To some extent the Scheme and Haskell communities do this already, because their favored languages are compact enough to allow them to include their programs in more or less conventional math papers. http://canonical.org/~kragen/sw/dev3/paperalgo http://canonical.org/~kragen/sw/dev3/paperalgo is a notation I developed for writing procedural programs with paper and pencil, extending mathematical notation with lightweight notation for classes, methods/functions, assignment, iteration, conditionals, and pattern matching. For many years I have used it whenever I'm writing code on paper or a whiteboard, but still find it harder to read than more traditional notations like Python and Scheme. In addition to compact code and explanation, it's often useful to have example inputs and outputs (the way spreadsheets and Jupyter notebooks or R notebooks do), as well as proofs.
- isaac21259 5y ago
  I believe this is basically what programming with APL looks like.
  - leephillips 5y ago
    Exactly. Just without the comments.
Ldorigo 5y ago
Yes, with the assumption that the reader is familiar with any symbol or notation not explained in said paragraph. I find it very irritating and a barrier to sharing knowledge when I'm unable to understand a paper because some notation is just assumed to be known - especially because there's no sensible way of looking up math/symbols online.
- xyzzyz 5y ago
  If you don’t know the notation, you almost surely don’t know the concepts themselves, and so the barrier to your understanding is lack of your background knowledge, not just notation issues. Math is just genuinely complex and hard, and people who have experience with basic mathematics in school or university simply should not expect the advanced stuff to be within easy grasp, as they sometimes do. Consider this classic, very well written paper: https://math.berkeley.edu/~nadler/atiyah.classification.pdf https://math.berkeley.edu/~nadler/atiyah.classification.pdf The “Generalities” section has only one page and hardly any equations, author simply defines notation he uses. And yet, it requires something like 2+ years of prior education in advanced mathematics (either in strong undergrad program, or in a graduate program) to really grasp it. Author even defines his notation: “E [is] the sheaf of germs of regular sections of E, and \Gamma(E) [is] the vector space of global regular sections of E, thus \Gamma(E) = H^0(X, E).”. Sure, he doesn’t define what H^0(X,E) is, but if I told you that it’s the degree zero sheaf cohomology group of E, would that make any difference to you?
  - 127 5y ago
    Yet so many papers I read are just another Gaussian wearing another pants.
  - sundarurfriend 5y ago
    > If you don’t know the notation, you almost surely don’t know the concepts themselves The difference is that it is much easier to websearch a concept by name than by notation. "degree zero sheaf cohomology group" is a big handle to search, discover, and learn things with, whereas "H^0(X,E)" is a deadend.

netizen-936824 5y ago

Theoretically, we could do the same with comments no? Make the code extremely compact and explain it, perhaps even in a format like literate programming?

omaranto 5y ago
Yes. But it would be tough to change the culture. Math papers are meant to be read, so people pay attention to the explanations. Computer programs (at least if they garner users!) are run much more often than read, so it's natural to focus on the code and neglect the comments.
- nomel 5y ago
  > But it would be tough to change the culture. I think it would be tougher to find anyone willing to read programs written like this. Requiring an explanation to understand the variables is very similar to encoding the variables names and putting a lookup table below. Why force someones eyes to dart back and forth between the program and lookup table, just to get an idea of what the variable are, rather than also including a very rough explanation of what they variables are doing, in the program itself, by giving them meaningful names? We only have so much working memory. Giving variables names frees up a significant amount.
  - netizen-936824 5y ago
    I've personally written code that was immensely difficult to read. Branchless stuff with single letter variables. Even though I commented it thoroughly, its ridiculously difficult to read and modify. This was a good lesson for me, I won't do that again and I'm far more verbose now. My thinking is that maybe math should learn from things like that as well, perhaps expanding equations and being more verbose within the equation instead of an explanation next to it would make maths more accessible to a broader audience.
    - rq1 5y ago
      After developing equations through 100 lines and few pages or blackboards, you’ll see that dropping letters is inevitable. You shouldn’t really read the equations before understanding what they are about. They are usually written down to get rid of ambiguities of the natural language.
      - DennisP 5y ago
        Source code isn't ambiguous either, and tends to get way longer than a hundred lines or a few pages.
        rq1 5y ago
        It’s not a single equation though where you’d need to rewrite the same variables 100 times.
  - omaranto 5y ago
    I guess it depends on how concrete the code is. For very general things there just are no good names. I see the point in calling a variable anualSalary, say, but in a function for reversing a list is elementOfList really better than element or than x (which would be my preference)? This, by the way, is probably the main reason math uses single letters for names (with some rules of thumb that hint at the type, like n for an integer, X for a scheme, calligraphic F for a sheaf, etc.).
  - 5y ago
xvector 5y ago
The problem is that code comments tend to skew from the actual code over time. Let's just stick with readable code everywhere.
kragen 5y ago
I think this is an interesting and promising idea. Code that doesn't exist can't have bugs, and when you're just fooling around rather than writing production code you can just write the formulas without the explanation. To some extent the Scheme and Haskell communities do this already, because their favored languages are compact enough to allow them to include their programs in more or less conventional math papers. http://canonical.org/~kragen/sw/dev3/paperalgo http://canonical.org/~kragen/sw/dev3/paperalgo is a notation I developed for writing procedural programs with paper and pencil, extending mathematical notation with lightweight notation for classes, methods/functions, assignment, iteration, conditionals, and pattern matching. For many years I have used it whenever I'm writing code on paper or a whiteboard, but still find it harder to read than more traditional notations like Python and Scheme. In addition to compact code and explanation, it's often useful to have example inputs and outputs (the way spreadsheets and Jupyter notebooks or R notebooks do), as well as proofs.
isaac21259 5y ago
I believe this is basically what programming with APL looks like.
- leephillips 5y ago
  Exactly. Just without the comments.

Ldorigo 5y ago

Yes, with the assumption that the reader is familiar with any symbol or notation not explained in said paragraph. I find it very irritating and a barrier to sharing knowledge when I'm unable to understand a paper because some notation is just assumed to be known - especially because there's no sensible way of looking up math/symbols online.

xyzzyz 5y ago
If you don’t know the notation, you almost surely don’t know the concepts themselves, and so the barrier to your understanding is lack of your background knowledge, not just notation issues. Math is just genuinely complex and hard, and people who have experience with basic mathematics in school or university simply should not expect the advanced stuff to be within easy grasp, as they sometimes do. Consider this classic, very well written paper: https://math.berkeley.edu/~nadler/atiyah.classification.pdf https://math.berkeley.edu/~nadler/atiyah.classification.pdf The “Generalities” section has only one page and hardly any equations, author simply defines notation he uses. And yet, it requires something like 2+ years of prior education in advanced mathematics (either in strong undergrad program, or in a graduate program) to really grasp it. Author even defines his notation: “E [is] the sheaf of germs of regular sections of E, and \Gamma(E) [is] the vector space of global regular sections of E, thus \Gamma(E) = H^0(X, E).”. Sure, he doesn’t define what H^0(X,E) is, but if I told you that it’s the degree zero sheaf cohomology group of E, would that make any difference to you?
- 127 5y ago
  Yet so many papers I read are just another Gaussian wearing another pants.
- sundarurfriend 5y ago
  > If you don’t know the notation, you almost surely don’t know the concepts themselves The difference is that it is much easier to websearch a concept by name than by notation. "degree zero sheaf cohomology group" is a big handle to search, discover, and learn things with, whereas "H^0(X,E)" is a deadend.