7 ms·

Because mathematics is a very dense language; building in redundancy does not scale when you're reading mathematics papers.

gravypod 10y ago
Would it make sense to say "building in redundancy does not scale when you're reading source code"? Not to me it doesn't.
- DollaWilliam 10y ago
  That's a false equivalency. Mathematics, in practice, is more of a domain specific language that encapsulates more and more precise information as you increase the level of abstraction. The levels of abstraction layer upon one another to be able to handle more complex concepts while retaining all of the underlying precision.
  - gravypod 10y ago
    > Mathematics, in practice, is more of a domain specific language that encapsulates more and more precise information as you increase the level of abstraction Isn't that the point of any DSL? Also, wasn't the advent of DSLs meant to make it easier for non-programmers to understand the flow of control in a system? I think generally the idea was to make things easier to understand by factoring out the complicated bits (implementation) and leveraging abstraction to provide clarity on top of an implementation. If this is the case for every DSL I and every other CS major designs, why should it not be the goal of every math major? Sure to you and many other math-centrist people these symbols are "how I learned it so it must be the best" but to everyone else it's difficult to grasp and hard to understand. The lingo is half the battle for most things but for math it seems like the lingo is the entire battle.
    - DollaWilliam 10y ago
      > The lingo is half the battle for most things but for math it seems like the lingo is the entire battle. There's a kernel of truth there. To abuse the DSL metaphor further, even mildly complicated mathematics concepts are only expressible using layer upon layer of ever-more-abstracted DSLs. Lower-level expansions of the building blocks to improve clarity for reading would be useless in practice, since mathematics is intended to be written and understood by humans and such an expansion would exceed our ability to keep the entire intended concept in our working memory. Proficiency in mathematics is proficiency with understanding and extending the lingo itself. Mathematics /is/ the lingo, which is why it can't be unraveled from it. >"how I learned it so it must be the best" Not at all. It is, however, a very practical approach to getting someone up to speed to be able to do actual mathematics (as opposed to the basic symbol manipulations that most people confuse with actual mathematics.)
- userbinator 10y ago
  It makes sense to me, although perhaps at a different level --- IMHO redundancy is bad in source code in general, and if you base your development methodologies and practices on assuming that it's not, you end up with things like Enterprise Java and C#: huge, eye-bleedingly verbose monstrosities to perform the simplest of tasks.
  - gravypod 10y ago
    Just as with everything there is a sweet spot. I personally feel some things need to stay verbose while some things are implementation and not inherently needed. Before college, I didn't do any python. After touching the language because of a class I like some of the things they do. For instance: for i in range(10): print(i) This is a great way to show a way to print 0-9 to stdout. This is great. Contrary to this, you have a more c-like method of writing this. for (int i = 0; i < 10; i++) printf("%d\n", i); This is the same code, but we have a lot more stuff here that convey a lot of meaning. This is fine for me. The construct is dense, but it's not overly dense. It is simple because once you see it the first time, you will understand it and it will always make sense to you no matter how many years pass. I'm fine with this extra verbosity. On the other side of the spectrum you have this: map(print, range(10)) This is far fewer characters, but it's more difficult to understand. There are more things to understand if you've never done any functional programming. This sort of dense solution is frowned upon in many cases, especially since this sort of thing rarely scales efficiently in the sense of cognitive load. I did all of my CS labs using map/reduce formulas for CS100 and it did nothing but make things harder and drive a large appreciation for expanding statements into my heart.
    - chaoxu 10y ago
      That map is doing an impure operation. The order of application matters. Otherwise, for people who learned functional programming from the start, it's much easier to understand.
    - witty_username 10y ago
      I find the map solution simpler than the for loop as there is no loop variable.
- Ar-Curunir 10y ago
  To clarify; mathematics talks about objects with increasing amounts of density; as you proceed up the abstraction stack into increasingly abstract topics, you need to be able to efficiently compress the topics you're already supposed to have mastered. Mathematics is for experts that have mastered the lower levels of the abstraction layer. You cannot study any subfield of math without having understood the basic definitions of the field. No amount of syntax rewriting is going to change that; those definitions are not going anywhere.
  - gravypod 10y ago
    "To clarify; software talks about objects with increasing amounts of complexity; as you proceed up the abstraction stack into increasingly abstract topics, you need to be able to efficiently compress the topics you're already supposed to have implemented." What I'd expect to follow here would be a statement about how your abstractions should be terse and verbose in the right ways. Terse in the implementation specific handling and verbose in the explanation of your abstract solution. "Software is for experts that have mastered the lower levels of the abstraction layer. You cannot study any subfield of systems programming without having understood the basic implementation of the underlying software. No amount of syntax rewriting is going to change that; those definitions are not going anywhere." I don't see how that statement would make any sense. I expect to be able to give anyone with the most basic of understandings of computers a piece of any code (from Assembly to high level Lisp code) from widely used software like the Linux kernel all the way to stock trading applications and I expect them to understand it by looking at it for a few seconds, reading the comments, and reading the names of the variables and functions. If the average person cannot do that, then it's bad code. Understand-ability is the only point of programming. To be understood by the computer and by a maintainer. I'd never say that obtuse notations for an abstraction should stay around. I'd replace the obtuse notation with a better abstraction.
    - yorwba 10y ago
      > I expect them to understand it by looking at it for a few seconds, reading the comments, and reading the names of the variables and functions. Mathematics also comes with comments, many papers essentially consists of one giant comment for the proof in the appendix. Granted, many variable names could be a bit less terse, but it's just easier to write "let f be an arbitrary function A -> B" once instead of using arbitraryFunctionMappingTheSetOf{DefinitionOfElementsOfA}toTheSetOf{DefinitionOfElementsOfB} every time.
- wfo 10y ago
  You don't need to read or understand (most of) your source code because it is 90% libraries. Mathematics is built based on understanding all the concepts behind a subject, and it's written to express to another human clear rigorous thought. You cannot just black box everything away and choose to ignore it the way programmers do with source code and libraries. The metric for success with a program is "does the machine run it properly". The metric for success with a piece of mathematics is "do people who've done some reading in my field understand my new result". You can cheat in one but not in the other.
  - gravypod 10y ago
    > You don't need to read or understand (most of) your source code because it is 90% libraries That's just plain incorrect. I expect all code to be written to standards of which would allow anyone to read. > Mathematics is built based on understanding all the concepts behind a subject, and it's written to express to another human clear rigorous thought. Isn't abstraction designed to avoid this? To remove a solution from a problem domain? To work on it without integral knowledge of all; applications? If not then all of Computer Science has been doing it wrong. > You cannot just black box everything away and choose to ignore it the way programmers do with source code and libraries. We don't do that. We black box things that aren't related to the problem at hand by referring to them in a terse and understandable way. For instance if I want to use a fork join scheduler for parallel thread scheduler I don't need to write out all the code for a fork join scheduler. I just need to say "You probably know what this is, if not it's called a fork join scheduler and I'll interact with it via sending messages of run, runAll, etc" and be done with it. I wont use an obscure Greek letter to notate a Fork-Join as that's archaic and insane. > The metric for success with a program is "does the machine run it properly". The metric for success with a piece of mathematics is "do people who've done some reading in my field understand my new result". You can cheat in one but not in the other. The KPIs for software are as follows: functionality, maintainability, simplicity. In that order. There is no single goal of software but instead a multifaceted set of goals constantly working against each other yet CS people make room for an even balance. I don't see how this relates to you engaging in proving further information from other information. I don't see why math needs 40 non-terminal characters to type out a proof. I don't see why it can't be written in a way that is more approachable while not detrimental to the performance of current professionals. I also find it unfathomable that someone would think that the current way of doing things is the, all together, best way of doing things because that points a blind eye at the other two things I mentioned: "maintainability, simplicity". I wouldn't call any of the advanced math world "simple" or "maintainable".
delinka 10y ago
Dense and high-level. Like programming languages. You take a group of machine operations and represent those with an operator in a programming language. You take a group of programming statements, expressions, etc and represent them with a procedure. Group some procedures together into a category (or perhaps a 'class' of items.) Take a few lines of COBOL, compile it, and how much actual machine work does that represent? Lots. Very dense.

gravypod 10y ago

Would it make sense to say "building in redundancy does not scale when you're reading source code"? Not to me it doesn't.

DollaWilliam 10y ago
That's a false equivalency. Mathematics, in practice, is more of a domain specific language that encapsulates more and more precise information as you increase the level of abstraction. The levels of abstraction layer upon one another to be able to handle more complex concepts while retaining all of the underlying precision.
- gravypod 10y ago
  > Mathematics, in practice, is more of a domain specific language that encapsulates more and more precise information as you increase the level of abstraction Isn't that the point of any DSL? Also, wasn't the advent of DSLs meant to make it easier for non-programmers to understand the flow of control in a system? I think generally the idea was to make things easier to understand by factoring out the complicated bits (implementation) and leveraging abstraction to provide clarity on top of an implementation. If this is the case for every DSL I and every other CS major designs, why should it not be the goal of every math major? Sure to you and many other math-centrist people these symbols are "how I learned it so it must be the best" but to everyone else it's difficult to grasp and hard to understand. The lingo is half the battle for most things but for math it seems like the lingo is the entire battle.
  - DollaWilliam 10y ago
    > The lingo is half the battle for most things but for math it seems like the lingo is the entire battle. There's a kernel of truth there. To abuse the DSL metaphor further, even mildly complicated mathematics concepts are only expressible using layer upon layer of ever-more-abstracted DSLs. Lower-level expansions of the building blocks to improve clarity for reading would be useless in practice, since mathematics is intended to be written and understood by humans and such an expansion would exceed our ability to keep the entire intended concept in our working memory. Proficiency in mathematics is proficiency with understanding and extending the lingo itself. Mathematics /is/ the lingo, which is why it can't be unraveled from it. >"how I learned it so it must be the best" Not at all. It is, however, a very practical approach to getting someone up to speed to be able to do actual mathematics (as opposed to the basic symbol manipulations that most people confuse with actual mathematics.)
userbinator 10y ago
It makes sense to me, although perhaps at a different level --- IMHO redundancy is bad in source code in general, and if you base your development methodologies and practices on assuming that it's not, you end up with things like Enterprise Java and C#: huge, eye-bleedingly verbose monstrosities to perform the simplest of tasks.
- gravypod 10y ago
  Just as with everything there is a sweet spot. I personally feel some things need to stay verbose while some things are implementation and not inherently needed. Before college, I didn't do any python. After touching the language because of a class I like some of the things they do. For instance: for i in range(10): print(i) This is a great way to show a way to print 0-9 to stdout. This is great. Contrary to this, you have a more c-like method of writing this. for (int i = 0; i < 10; i++) printf("%d\n", i); This is the same code, but we have a lot more stuff here that convey a lot of meaning. This is fine for me. The construct is dense, but it's not overly dense. It is simple because once you see it the first time, you will understand it and it will always make sense to you no matter how many years pass. I'm fine with this extra verbosity. On the other side of the spectrum you have this: map(print, range(10)) This is far fewer characters, but it's more difficult to understand. There are more things to understand if you've never done any functional programming. This sort of dense solution is frowned upon in many cases, especially since this sort of thing rarely scales efficiently in the sense of cognitive load. I did all of my CS labs using map/reduce formulas for CS100 and it did nothing but make things harder and drive a large appreciation for expanding statements into my heart.
  - chaoxu 10y ago
    That map is doing an impure operation. The order of application matters. Otherwise, for people who learned functional programming from the start, it's much easier to understand.
  - witty_username 10y ago
    I find the map solution simpler than the for loop as there is no loop variable.
Ar-Curunir 10y ago
To clarify; mathematics talks about objects with increasing amounts of density; as you proceed up the abstraction stack into increasingly abstract topics, you need to be able to efficiently compress the topics you're already supposed to have mastered. Mathematics is for experts that have mastered the lower levels of the abstraction layer. You cannot study any subfield of math without having understood the basic definitions of the field. No amount of syntax rewriting is going to change that; those definitions are not going anywhere.
- gravypod 10y ago
  "To clarify; software talks about objects with increasing amounts of complexity; as you proceed up the abstraction stack into increasingly abstract topics, you need to be able to efficiently compress the topics you're already supposed to have implemented." What I'd expect to follow here would be a statement about how your abstractions should be terse and verbose in the right ways. Terse in the implementation specific handling and verbose in the explanation of your abstract solution. "Software is for experts that have mastered the lower levels of the abstraction layer. You cannot study any subfield of systems programming without having understood the basic implementation of the underlying software. No amount of syntax rewriting is going to change that; those definitions are not going anywhere." I don't see how that statement would make any sense. I expect to be able to give anyone with the most basic of understandings of computers a piece of any code (from Assembly to high level Lisp code) from widely used software like the Linux kernel all the way to stock trading applications and I expect them to understand it by looking at it for a few seconds, reading the comments, and reading the names of the variables and functions. If the average person cannot do that, then it's bad code. Understand-ability is the only point of programming. To be understood by the computer and by a maintainer. I'd never say that obtuse notations for an abstraction should stay around. I'd replace the obtuse notation with a better abstraction.
  - yorwba 10y ago
    > I expect them to understand it by looking at it for a few seconds, reading the comments, and reading the names of the variables and functions. Mathematics also comes with comments, many papers essentially consists of one giant comment for the proof in the appendix. Granted, many variable names could be a bit less terse, but it's just easier to write "let f be an arbitrary function A -> B" once instead of using arbitraryFunctionMappingTheSetOf{DefinitionOfElementsOfA}toTheSetOf{DefinitionOfElementsOfB} every time.
wfo 10y ago
You don't need to read or understand (most of) your source code because it is 90% libraries. Mathematics is built based on understanding all the concepts behind a subject, and it's written to express to another human clear rigorous thought. You cannot just black box everything away and choose to ignore it the way programmers do with source code and libraries. The metric for success with a program is "does the machine run it properly". The metric for success with a piece of mathematics is "do people who've done some reading in my field understand my new result". You can cheat in one but not in the other.
- gravypod 10y ago
  > You don't need to read or understand (most of) your source code because it is 90% libraries That's just plain incorrect. I expect all code to be written to standards of which would allow anyone to read. > Mathematics is built based on understanding all the concepts behind a subject, and it's written to express to another human clear rigorous thought. Isn't abstraction designed to avoid this? To remove a solution from a problem domain? To work on it without integral knowledge of all; applications? If not then all of Computer Science has been doing it wrong. > You cannot just black box everything away and choose to ignore it the way programmers do with source code and libraries. We don't do that. We black box things that aren't related to the problem at hand by referring to them in a terse and understandable way. For instance if I want to use a fork join scheduler for parallel thread scheduler I don't need to write out all the code for a fork join scheduler. I just need to say "You probably know what this is, if not it's called a fork join scheduler and I'll interact with it via sending messages of run, runAll, etc" and be done with it. I wont use an obscure Greek letter to notate a Fork-Join as that's archaic and insane. > The metric for success with a program is "does the machine run it properly". The metric for success with a piece of mathematics is "do people who've done some reading in my field understand my new result". You can cheat in one but not in the other. The KPIs for software are as follows: functionality, maintainability, simplicity. In that order. There is no single goal of software but instead a multifaceted set of goals constantly working against each other yet CS people make room for an even balance. I don't see how this relates to you engaging in proving further information from other information. I don't see why math needs 40 non-terminal characters to type out a proof. I don't see why it can't be written in a way that is more approachable while not detrimental to the performance of current professionals. I also find it unfathomable that someone would think that the current way of doing things is the, all together, best way of doing things because that points a blind eye at the other two things I mentioned: "maintainability, simplicity". I wouldn't call any of the advanced math world "simple" or "maintainable".

delinka 10y ago

Dense and high-level. Like programming languages. You take a group of machine operations and represent those with an operator in a programming language. You take a group of programming statements, expressions, etc and represent them with a procedure. Group some procedures together into a category (or perhaps a 'class' of items.) Take a few lines of COBOL, compile it, and how much actual machine work does that represent? Lots. Very dense.