4 ms·

Right. You could define functions. The function itself is stated in a readable form yet it is concise when later called upon. And just like you desire, this giv

Right. You could define functions. The function itself is stated in a readable form yet it is concise when later called upon. And just like you desire, this gives the reader a chance to first absorb the idea being expressed by the function (in clear pseudo-code), without making your expressions later overly verbose. The counterargument might be "but then it's harder to break it down again into components when doing algebra". But that's no different from substituting in identities as needed. Substitute in the function body whenever you need to. As long as you don't need to, don't and you both have concise writing and reduced cognitive overhead. Each time the user sees a function they have previously mentally absorbed and understood they don't need to re-read it in detail to confirm it's still the same idea.

j2kun 10y ago
> And just like you desire, this gives the reader a chance to first absorb the idea being expressed by the function (in clear pseudo-code), without making your expressions later overly verbose. This is already the case in math, just with a combination of English and algebraic notation and pictures, whatever is best to convey the idea. Either way, it seems orthogonal to your complaints about notation. I'm saying that pseudocode (as I think you mean it, pythonesque) is not nearly expressive enough to convey the ideas that mathematical notation conveys. It really does help reduce cognitive overload to distinguish two parameters, say one depending on time and one depending on position, by putting one in a subscript. (And that's still at the base of the ladder of abstraction) Sigma notation is one particularly helpful example, far more compact and easier to analyze than a for/while loop. (And, for what it's worth, list comprehensions come from mathematical set-builder notation) I'm not saying math is perfect, but having spent a lot of time doing both math and software, I like to think I understand the reasons for the pitfalls of both fields relatively well.
- Jtsummers 10y ago
  Math notations allow for many transformations and operations on the expressions that pseudocode and most programming languages simply don't permit, or render as clearly. Even within programming languages, consider the matlab notation for summation versus the (prototypical) algol-esque language notation: sum(vec) vs Python's (naive approach) sum = 0 for val in vec: sum += val or in C sum = 0 for(int i = 0; i < vec_length; i++) sum += vec[i]; Where vec_length has to be independently passed around since C's arrays don't have a notion of length. The first is a clear expression of the fact of what is happening (like sigma in typical math notation), but the second and third are only clear due to being 3-lines long each. A more complex kernel or stepping function and the reasonability of these expressions disappears. Even those in Python-land have recognized the flaws in the naive approach and developed numpy and other solutions that allow for a closer semantic connection between the language (python) and the desired expression (mathematics). See http://wiki.c2.com/?ArraySumInManyProgrammingLanguages http://wiki.c2.com/?ArraySumInManyProgrammingLanguages for even more examples from numerous programming languages. Few of these lend themselves (as the expressions grow in complexity) to the manipulability and reasonability [0] of mathematical notation. Languages of all sorts allow for different tradeoffs of expressibility, conciseness, manipulability, ease of acquisition, and other features. Mathematics has, predominantly, chosen conciseness and manipulability over ease of acquisition. But it would be nearly impossible to write a computer algebra system that took a textual version of math expressed in python and conducted the sort of automated manipulation and analysis that can be done to textualized forms of mathematical expressions. [0] Reasonability: Here I do not mean that python is more or less reasonable than math in the typical sense. I mean in the ability to consume the information expressed in either form and then reason about it. A page (or pages) of code needed to express the computations on geographic datasets here at work, versus the 20 lines of math we have on the whiteboard.
  - aljungberg 10y ago
    I'm not sure I follow. sum(vec) is exactly how I'd write it in Python (or pseudo-Python for that matter). It does what you think it does (provided the operation of addition is defined for vectors). I did mention using "sum" instead of "sigma" (combined with a list comprehension) in my OP, did you miss that or are you making a point I don't understand? I recognise what you say about mathematics favouring conciseness. I feel that's what I'm addressing: mathematics have sacrificed readability in favour of conciseness to an extreme and could benefit from some decompression. It is possible to write extremely concise code but I feel most programmers today agree that's actually not a good thing to do. It's often better to write something a little longer to improve readability than to save those characters. And like you write, every language, and we can consider mathematical notation to be a language in this context, has tradeoffs. But it's not a zero sum game. You can make an overall better language than another language. And what I like to imagine here is that perhaps mathematical notation is not the most evolved form of logical expression we have today. It's certainly not as formalised or field tested as the big programming languages.
    - j2kun 10y ago
      I think you have to ask why mathematicians make that tradeoff. I argue it's for a good reason: the long-term efficiency gains for a working mathematician are higher than if they spelled everything out all the time. I'm using a made-up but illustrative example. Imagine reading inducedHomology(fundamentalGroup(OnePointCompactification(Projectivization(RealAffineSpace(dimensions=2))))) as just one object in a formula involving many such objects (like a long exact sequence which can contain 10 or more, each with a set of functions mapping between them!). You would get lost. Then you say "okay, we'll come up with some nice alias for Projectivization(RealAffineSpace(dimensions=2)) and just call it RP(2)". Then it's still too long so you shorten inducedHomology to a prefix "" (not unheard of for programmers, cf pointers). Then you are left with "fundamentalGroup(OnePointCompactification(RP(2))", it's still long, and you realize that you just reinvented the standard math notation, which is like H^*(pi_1(RP^2)) with a line over RP^2, and you realize that while the shortened syntax is parseable by an interpreter, it's not actually any clearer. You don't start to see the limitations of "let's just use python pseudocode for everything" until you actually try to use it for everything. When you realize that most math isn't done with a text editor (how would you do, say, geometry or topology?), you realize that the vim/emacs tricks programmers use don't apply. This is especially true because there are far more math concepts that need distinguishing than ASCII allows for. Think about how much code is required to translate trivial business rules into code. Math is orders of magnitude more complicated. It's just not worth the time. Mathematicians also have one benefit pseudocode would destroy: the ability to point to something and declare a new semantic meaning. This is the heart of what it means to be mathematical notation, and software does everything it can to resist that.

j2kun 10y ago

> And just like you desire, this gives the reader a chance to first absorb the idea being expressed by the function (in clear pseudo-code), without making your expressions later overly verbose. This is already the case in math, just with a combination of English and algebraic notation and pictures, whatever is best to convey the idea. Either way, it seems orthogonal to your complaints about notation. I'm saying that pseudocode (as I think you mean it, pythonesque) is not nearly expressive enough to convey the ideas that mathematical notation conveys. It really does help reduce cognitive overload to distinguish two parameters, say one depending on time and one depending on position, by putting one in a subscript. (And that's still at the base of the ladder of abstraction) Sigma notation is one particularly helpful example, far more compact and easier to analyze than a for/while loop. (And, for what it's worth, list comprehensions come from mathematical set-builder notation) I'm not saying math is perfect, but having spent a lot of time doing both math and software, I like to think I understand the reasons for the pitfalls of both fields relatively well.

Jtsummers 10y ago
Math notations allow for many transformations and operations on the expressions that pseudocode and most programming languages simply don't permit, or render as clearly. Even within programming languages, consider the matlab notation for summation versus the (prototypical) algol-esque language notation: sum(vec) vs Python's (naive approach) sum = 0 for val in vec: sum += val or in C sum = 0 for(int i = 0; i < vec_length; i++) sum += vec[i]; Where vec_length has to be independently passed around since C's arrays don't have a notion of length. The first is a clear expression of the fact of what is happening (like sigma in typical math notation), but the second and third are only clear due to being 3-lines long each. A more complex kernel or stepping function and the reasonability of these expressions disappears. Even those in Python-land have recognized the flaws in the naive approach and developed numpy and other solutions that allow for a closer semantic connection between the language (python) and the desired expression (mathematics). See http://wiki.c2.com/?ArraySumInManyProgrammingLanguages http://wiki.c2.com/?ArraySumInManyProgrammingLanguages for even more examples from numerous programming languages. Few of these lend themselves (as the expressions grow in complexity) to the manipulability and reasonability [0] of mathematical notation. Languages of all sorts allow for different tradeoffs of expressibility, conciseness, manipulability, ease of acquisition, and other features. Mathematics has, predominantly, chosen conciseness and manipulability over ease of acquisition. But it would be nearly impossible to write a computer algebra system that took a textual version of math expressed in python and conducted the sort of automated manipulation and analysis that can be done to textualized forms of mathematical expressions. [0] Reasonability: Here I do not mean that python is more or less reasonable than math in the typical sense. I mean in the ability to consume the information expressed in either form and then reason about it. A page (or pages) of code needed to express the computations on geographic datasets here at work, versus the 20 lines of math we have on the whiteboard.
- aljungberg 10y ago
  I'm not sure I follow. sum(vec) is exactly how I'd write it in Python (or pseudo-Python for that matter). It does what you think it does (provided the operation of addition is defined for vectors). I did mention using "sum" instead of "sigma" (combined with a list comprehension) in my OP, did you miss that or are you making a point I don't understand? I recognise what you say about mathematics favouring conciseness. I feel that's what I'm addressing: mathematics have sacrificed readability in favour of conciseness to an extreme and could benefit from some decompression. It is possible to write extremely concise code but I feel most programmers today agree that's actually not a good thing to do. It's often better to write something a little longer to improve readability than to save those characters. And like you write, every language, and we can consider mathematical notation to be a language in this context, has tradeoffs. But it's not a zero sum game. You can make an overall better language than another language. And what I like to imagine here is that perhaps mathematical notation is not the most evolved form of logical expression we have today. It's certainly not as formalised or field tested as the big programming languages.
  - j2kun 10y ago
    I think you have to ask why mathematicians make that tradeoff. I argue it's for a good reason: the long-term efficiency gains for a working mathematician are higher than if they spelled everything out all the time. I'm using a made-up but illustrative example. Imagine reading inducedHomology(fundamentalGroup(OnePointCompactification(Projectivization(RealAffineSpace(dimensions=2))))) as just one object in a formula involving many such objects (like a long exact sequence which can contain 10 or more, each with a set of functions mapping between them!). You would get lost. Then you say "okay, we'll come up with some nice alias for Projectivization(RealAffineSpace(dimensions=2)) and just call it RP(2)". Then it's still too long so you shorten inducedHomology to a prefix "" (not unheard of for programmers, cf pointers). Then you are left with "fundamentalGroup(OnePointCompactification(RP(2))", it's still long, and you realize that you just reinvented the standard math notation, which is like H^*(pi_1(RP^2)) with a line over RP^2, and you realize that while the shortened syntax is parseable by an interpreter, it's not actually any clearer. You don't start to see the limitations of "let's just use python pseudocode for everything" until you actually try to use it for everything. When you realize that most math isn't done with a text editor (how would you do, say, geometry or topology?), you realize that the vim/emacs tricks programmers use don't apply. This is especially true because there are far more math concepts that need distinguishing than ASCII allows for. Think about how much code is required to translate trivial business rules into code. Math is orders of magnitude more complicated. It's just not worth the time. Mathematicians also have one benefit pseudocode would destroy: the ability to point to something and declare a new semantic meaning. This is the heart of what it means to be mathematical notation, and software does everything it can to resist that.