I had some initial thoughts when I first saw this, I don't think they've changed much since. It'll be interesting to see where it ends up, for sure. I wrote again about this page after reading the somewhat recent Dijkstra lecture about the radical novelty that is programming (and other topics). Here's a slightly modified copy/paste, I'll warn that it kind of wanders after "Things Other People Have Said" so you're invited to stop reading at that point.
While I sympathize with the opening, because many neat things have been made/discovered without the person having any formal math knowledge like what the "U"-looking symbol in an equation stands for:
>"The power to understand and predict the quantities of the world should not be restricted to those with a freakish knack for manipulating abstract symbols."
I heavily disagree with the conclusion:
>"They are unusable in the same way that the UNIX command line is unusable for the vast majority of people. There have been many proposals for how the general public can make more powerful use of computers, but nobody is suggesting we should teach everyone to use the command line. The good proposals are the opposite of that -- design better interfaces, more accessible applications, higher-level abstractions. Represent things visually and tangibly.
>And so it should be with math. Mathematics, as currently practiced, is a command line. We need a better interface."
I think the notion that they're unusable by the vast majority of people because of something fundamental about people is false. At some point in time reading and writing were not done by the vast majority of people, then they came into existence. Even as recent as 500 years ago, the vast majority of the population neither read nor wrote. Along came public education and that proportion flip flopped insanely fast such that the vast majority are capable of reading and writing (regardless of how good they are at it). Reading and writing were just as radical novelties as computing, just because something is a radical novelty doesn't mean most humans can't be proficient at it eventually.
I think we should teach everyone to use the command line. Well, not Windows' CMD.EXE, but bash preferably in a gnome-terminal. Here is a short quote expressing why I think this is a good idea:
>Linux supports the notion of a command line or a shell for the same reason
that only children read books with only pictures in them. Language, be it
English or something else, is the only tool flexible enough to accomplish
a sufficiently broad range of tasks.
-- Bill Garrett
I think we should teach everyone how to interact with the computer at the most general way--which means programming. Which means commanding the computer. Describing the inverse square law in terms of pictures and intuition isn't going to make it any more of a tool than some other method, people are still going to think of it as something one is taught. The only way to make it seem like a tool is to use it as a tool, this means programming for some purpose. Maybe a physics simulation. And the beauty of tools is why the software world has exploded with utility despite Dijkstra's depression at programmers' inability to program extremely well. The beauty of tools is that they can be used without understanding the tool, just what the tool is useful for.
The "Things Other People Have Said" at the end is more interesting than the essay.
I wonder what Dijkstra would think of it. My two best guesses are "This is just a continuation of infantizing everything" and "We did kill math, with programming." I think a lot of people's difficulties with symbolic manipulation are due to the symbols not having immediately interpreted meaning. Dijkstra seems to recommend fixing this by drilling symbol manipulation of the predicate calculus with uninterpreted symbols like "black" and "white". My own approach I have been using more and more is to just use longer variable names in my math, whether written or typed. It really seems like this simple step can be a tremendous aid in understanding what's going on.
Over the past couple of years I've realized just how important sheer memorization can be as I see almost everyone around me struggle with basic calculus facts, which means they struggle with application of the facts. The latest example from a few weeks ago in a junior level stats course with calc 2 prerequisite (which many people take 2 or 3 times here apparently) was when apparently no one but me recognized (or bothered to speak up after 20 seconds) that (1+1/x)^x limited to infinity is the definition of e, which we then immediately used with (1 - const/x)^x = e^(-const). (Which is immediately related to the continual compound interest formula that changes (1+r/n)^nt to e^rt as n->infty which everyone should have seen multiple times in algebra 2 / pre calc when learning about logarithms! The two most common examples are money and radioactive decay.)
Sure that's a memorized fact for me, it's not necessarily intuitive apart from the 1/x being related to logs which are related to e, but come on. In my calc 3 course that I didn't get to waive out of, where it was just me and two others, I was the only one who passed, and when the teacher would try to make the class more interactive by asking us to complete-the-step instead of just a pure lecture the other two were seemingly incapable at remembering even the most basic derivative/integral pairs like D[sin(x)]=cos(x). A lot of 'education' is students cramming for and regurgitating on a test where the teacher hopes (often in vain) that the cramming resulted in long-term memorization. I do this too, cram and forget, but maybe I just do it less frequently or for less important subjects or my brain's wired to memorize things more easily than average (but I disfavor hypotheses that suppose unexplained gaps in human ability as largely static). My high school teacher's pre-calc and calc courses had frequent pure memorization tests such that there wasn't a need to cram elsewhere because that iterative cramming was enough to get long-term memorization (with cache warmups every so often; I did have to breeze through a calculus book in preparation for a waiver exam last year).
A person can only hold so many things in their active, conscious memory at once (some people think it's only 7 plus or minus 3 but that seems like too weird a definition of 'thing' that results in so little; human brains are not CPUs with only registers r0 to r6), so when you start looking at a math proof with x's and y's and r's and greek letters and other uninterpreted single-character symbols all over the place, it's incredibly easy to get lost. If you start in the middle, if your brain hasn't memorized that "x means this, y means this" for any value of "this", you have to do a conscious lookup and dereference the symbol to some meaning even if the actual math itself is clear. My control systems book uses C and R for output/input (I already forgot which is which) but it's so embedded in my brain that Y is typically output and X is input that I use those instead, as does the teacher. I agree with Dijkstra that practice at manipulating uninterpreted symbols makes it a bit easier, but there are quickly diminishing returns and ever since I started programming and saw how PHP uses the $var syntax to denote variables I've been thinking "Why hasn't this caught on in math? It makes so many things much clearer!" But it's not so much the "$" in $var (or @var and other sigils in Perl) but the "var". Saving your brain a dereference step is pretty useful.
Single-character symbols (and multiple character symbols) that not only hide tons of meaning through a dereference, which is naturally how language works, that also suggest a meaning themselves, are stupid and promote natural diseased human thinking. My poster-child here is global warming. Every winter you'll hear the same comments on "When's global warming going to hit here?" The poor choice of global warming as a variable that points to a bigger theory has cost it heavily in PR because humans look at only the phrase instead of what it points to, it's still so bad that people's every day experiences, which they use to form a subconscious prior probability in global warming as a theory, contain "it's really hot all the time and everywhere I've been!" and so they look at "global warming" and dismiss any evidence for/against it based purely on the name and how their experience seems to contradict the name. It's like a computer thinking that a pointer address that happens to correspond to 0xADD means it should invoke addition when it should figure out what 0xADD points to instead which could be anything.
Another use of long names is with Bayes' Theorem in probability. It is only through memorization of the uninterpreted symbols A,B,C themselves that I remember prob(A | B, C) = prob(A | C) * prob(B | A, C) / prob(B | C) But it never made intuitive sense to me and I never bothered memorizing until it was expressed as prob(hypothesis | data, bg_info) = prob(hypothesis | bg_info) * prob(data | hypothesis, bg_info) / prob(data | bg_info). (Sometimes data is replaced by model.) The notion that it relates reason with reality, that it encapsulates the process of learning and scientific reasoning, elevates the equation to the status of a tool instead of something you cram for and regurgitate on a test. An immediately useful application for the tool is using Naive Bayes to filter spam.
> (1+1/x)^x limited to infinity is the definition of e
This shouldn’t be “memorized” as a “fact” though. As you point out, it’s the very definition of e. Which is to say, to really understand what the exponential function means implies building up a mental model about lim [n→∞] (1 + x/n)^n and its behavior, interacting with it, connecting it to other functions, seeing what happens when you combine it with other ideas: trying to integrate/differentiate it; noticing how it reacts to fourier transform; relating it to rotations, areas, imaginary numbers; writing it as a taylor expansion or continued fraction, or with a functional equation, or as the solution to a differential equation. Connecting it to derived functions such as e.g. the normal distribution, or sine, or hyperbolic sine. Generalizing it to an operation on complex numbers, or quaternions, or matrices. Thinking about what exponentiation in general really means. Coming up with algorithms for computing e’s decimal expansion or proving that e is irrational and transcendental. Solving problems with it, like to start with, continuously compounded interest (&c. &c. &c.).
No one who had really learned about exponentials in a deep way would easily forget that this is the definition of e, and that has nothing to do with lists of facts or rote memorization.
> Single-character symbols (and multiple character symbols) that not only hide tons of meaning through a dereference, which is naturally how language works, that also suggest a meaning themselves, are stupid and promote natural diseased human thinking.
I think you should try writing out some very difficult complex math proofs before you make this assertion (say, for instance, a proof . Things are bad enough when we pack ideas down. Start expanding them in the middle of the computation, and it the steps become almost impossible to see or reason about.
The whole point of assigning things short simple names is that it gives a clear analogy (to past experience w/ the conventions) that provide a shortcut to anticipating how particular types of structures and operations behave. Cramming a matrix or a multivariate function or an operator down into a single symbol helps us to treat that symbol as a black box for the purpose of the proof or problem, which helps us bring our existing mathematical tools and understandings to bear. Sometimes, we run afoul of false impressions, as when we apply intuition about the real numbers to matrices in ways that don’t quite apply, or intuition about metric spaces to general topological spaces, &c. But this is I think an unavoidable cost, and it’s why we strive to be careful and precise in making mathematical arguments.
The way people think and conceptualize ideas varies greatly for different people. Even for things as basic as counting, people do it in different ways.
> What’s interesting is that the pattern varies from person to person. Feynman shared his discovery with a group of people, one of whom (John Tukey) had a curiously different experience: while counting steadily, he could easily speak aloud, but could not read. Through experimenting and comparing their experiences, it seemed to them that they were using different cognitive processes to accomplish the task of counting time. Feynman was “hearing” the numbers in his head, while Tukey was “seeing” the numbers go by.
So while pushing around abstract symbols might be the way that you really grok things, I don't think this applies to everyone. I have an undergrad math minor, and the only math class that I didn't get an A in and that I really struggled with was Linear Algebra.
I think it mostly had to due with excessive symbolic abstraction. Matrix notation still really troubles me. About 5 years after that Linear Algebra class that I struggled with, I was took a computer graphics class for a masters degree. We were talking about the non-invertibility of some operation (I think it was about figuring out how far something was away given a 2d rendering of a 3d scene, where you have a degree of freedom in the scale, everything could be twice as large and twice as far away). And that gave me a really intuitive understanding between matrix invertibility and full rank matrices. I am sure that I would have done much better in a combined Linear Algebra/Computer Graphics class than I did in just the mostly symbolic and proof based Linear Algebra class.
So be careful in believing that the thought processes that obviously work well for you will also work well for others.
Traditional way of teaching linear algebra is very abstract. But that's ok, or at least we use linear algebra in our CS programme as a way to teach abstract thinking, which is important for this subject.
I would suggest that someone who has trouble (serious trouble that is) with linear algebra might have also trouble with other abstract things in computer science, like automata theory or grammars and compilers.
I had the same experience, i struggle understanding problems where i can't see concrete examples of cause and effect. Though I believe the problem was that I simply didn't "bother" to understand because it was "hard".
Single symbols are ok, but why do they have to be denoted by a single letter? There's a reason why using single-letter (or two, or three-letter) variables is discouraged in programming in favour of longer, descriptive names. It's to avoid the moments in which you start wondering, in the middle of reading a function, 'why q has to be greater than k-1? And what the hell is this Q(p) anyway?'. I really don't understand why both math and physics are so into one-character symbols. Even the OP's Bayes theorem example shows that it's easier to read a formula, when the symbol names self-evaluate to their meaning.
A lot of the time when doing math, you literally don't want to know what a particular symbol stands for - you just want to manipulate the symbols abstractly. Too much interpretation can interfere with the process of pattern recognition that is essential for doing mathematics well. You also see this in programming whenever someone writes
public interface List<T> { ... }
in Java, or when you write
Tree a = Empty | Branch a (Tree a) (Tree a)
in Haskell. It doesn't matter what 'T' and 'a' are, so we use short, one-character representations for them. The fact that you can write Bayes rule as P(A|B) = P(A)P(B|A)/P(B) (where I've even used a zero-character representation for the background information!) expresses the fact that A and B can be arbitrary events, and don't need to have any connection to hypotheses, models or data. It just happens one of the applications of Bayes rule is in fitting scientific hypotheses to data.
Even in your example, multi-character names are used for Branch, Empty, Tree, and List. And those are much more helpful than single-character names would be.
Plus, the math tradition of one-character variable names means that they've had to adopt several different alphabets just to get enough identifier uniqueness (greek, hebrew, etc., plus specialized symbols like the real, natural, and integer number set symbols). Which makes all that stuff a pain to type. And even then, there are still identifier collisions where different sub-disciplines have different conventions for the meaning of a particular character.
It's also annoying because single-character names are impossible to google for.
We would use multi-character names for Branch, Empty and Tree because it matters what those things represent. It would be thoroughly confusing if we instead wrote
t a = e | b a (t a) (t a)
However, we don't care what the 'a' represents. It's just a placeholder for an arbitrary piece of information. If we had to write
then we have just introduced a lot of unnecessary line noise.
One difference between programming and mathematics is that programming is mostly interpreted in context, when it matters that this double represents elapsed time, and this double represents dollars in my checking account. Mathematics, on the other hand, is mostly interpreted out of context. I don't care what a represents, all I care about is that it enjoys the relationship ab = ba with some other arbitrary object b.
If the mantra of programming is "names are important" then the mantra of mathematics might be "names aren't important".
Sure, your original example with single-letter type variables makes sense to me, since those variables could represent anything. I never meant to object to those. I just wanted to point out the fact that your example also included multi-letter names, while mathematics generally does not.
So if you really don't care what a variable represents, then I'd agree that a single-letter name is fine. Given that math is almost universally done with single-letter variable names, are you suggesting that in math you almost never care what a variable represents? This wikipedia article makes me think otherwise; clearly, variables often have a fairly specific meaning.
Ok, this is a good reason, though I'm don't think it covers all the use cases, in particular on the borderline between math and physics. But yes, I can see how in programming, knowing what the variable really represents is usually helpful, while in math might usually be not.
Thanks for the link, there are some good thoughts there.
Part of the reason why single-letter variable names persist may be due to multiplication. There is no good symbol for multiplication; the two most common ones, × and ∙ are easily mistaken for other symbols (x and . respectively) when improperly typeset or handwritten (the distinction is easier with proper typography and neater handwriting, of course).
The way most mathematicians ignore this problem is by throwing two variable names next to each other, so xy is x times y. Obviously, this system is incompatible with multiple-letter variable names. I have unfortunately seen the two concepts mixed, which makes reading an equation like reading ancient Greek or Latin (which lacked spaces and punctuation).
Until there is a commonly accepted, easily distinguishable symbol for multiplication, I don't see single-letter variables going anywhere, or multiple-letter variables being used in general mathematics.
Short variable names are useful when structure is more important than concrete interpretation. For example, consider the above definition of e (aka EulersConstant):
e = lim x->inf (1 - 1/x)^x
= limit(
compoundingSegmentsPerYear,
INFINITY,
pow(1 - 1 / compoundingSegmentsPerYear,
compoundingSegmentsPerYear))
We could obfuscate further by XML replacement parentheses:
<sum>
<term>1</term>
<term>
<quotient>...</quotient>
</term>
</sum>
But the structure is more important, right?
I must disagree with the command-line part. I don't think that the command line is fundamentally more powerful than any other interface.
Why is the command line powerful? Because it offers a large number of utilities that are highly configurable and that can be linked easily.
But you could have just the same expressiveness if the interface was eg. a circuit diagram, where you connect configurable commands with lines.
You know why the command line uses text input? Because it is the simplest to implement. The only people who need to know how to use the command line are people who need to use software where it doesn't pay off to make a more intuitive interface.
While I agree that the commandline provides "a large number of utilities" that "can be linked easily", I don't think that's the whole story. While you could certainly design a circuit-diagram-style GUI for building commands (so-called "visual programming"), it would be a lot more tedious than typing, just because there's so much more bandwidth available on a 100+ button, two-handed input device than a two-or-three button one-handed input device. Also, a good deal of efficiency comes from terseness: I can imagine a GUI that would make it simple and visually obvious how the different atoms of a regular expression fit together, but such a GUI would spend a lot of visual bandwidth communicating which combinations are legal and which are absurd. Expressing a regular expression as a string gives you absolutely no such feedback, but if you already know the regex you want to use, it's an awful lot faster to type it.
Lastly, the command line gets a good deal of power from meta-programming: most commands deal with a loosely structured stream of text, and a set of commands is a loosely structured stream of text. Specifically in POSIX environments, primitives like command-substitution ("$()" or backticks) and the xargs command are powerful ways to write commands that construct and execute other commands. If your diagram-based UI contains a set of primitives for launching commands and working with text, you're going to have to add a whole new set of primitives for working with diagrams.
As somebody who spent some time working with LabVIEW, I can safely say that drawing a circuit diagram is more difficult and less intuitive than using text. Now, maybe this is the fault of LabVIEW, but I think it's true in the general case as well.
I once had to use LabVIEW. In general, I agree with you, but I got the feeling that G (the language implemented in LabVIEW) might almost be a decent language if the only IDE for it (and the file format) didn't suck so badly.
I remember Bayes as P(a|b) p(b) = p(a,b) = p(b|a) p(a). It's hardly the only way it's linked up in my personal mind-map, of course, but it's how I first memorized it.
While I sympathize with the opening, because many neat things have been made/discovered without the person having any formal math knowledge like what the "U"-looking symbol in an equation stands for:
>"The power to understand and predict the quantities of the world should not be restricted to those with a freakish knack for manipulating abstract symbols."
I heavily disagree with the conclusion:
>"They are unusable in the same way that the UNIX command line is unusable for the vast majority of people. There have been many proposals for how the general public can make more powerful use of computers, but nobody is suggesting we should teach everyone to use the command line. The good proposals are the opposite of that -- design better interfaces, more accessible applications, higher-level abstractions. Represent things visually and tangibly.
>And so it should be with math. Mathematics, as currently practiced, is a command line. We need a better interface."
I think the notion that they're unusable by the vast majority of people because of something fundamental about people is false. At some point in time reading and writing were not done by the vast majority of people, then they came into existence. Even as recent as 500 years ago, the vast majority of the population neither read nor wrote. Along came public education and that proportion flip flopped insanely fast such that the vast majority are capable of reading and writing (regardless of how good they are at it). Reading and writing were just as radical novelties as computing, just because something is a radical novelty doesn't mean most humans can't be proficient at it eventually.
I think we should teach everyone to use the command line. Well, not Windows' CMD.EXE, but bash preferably in a gnome-terminal. Here is a short quote expressing why I think this is a good idea:
>Linux supports the notion of a command line or a shell for the same reason that only children read books with only pictures in them. Language, be it English or something else, is the only tool flexible enough to accomplish a sufficiently broad range of tasks. -- Bill Garrett
I think we should teach everyone how to interact with the computer at the most general way--which means programming. Which means commanding the computer. Describing the inverse square law in terms of pictures and intuition isn't going to make it any more of a tool than some other method, people are still going to think of it as something one is taught. The only way to make it seem like a tool is to use it as a tool, this means programming for some purpose. Maybe a physics simulation. And the beauty of tools is why the software world has exploded with utility despite Dijkstra's depression at programmers' inability to program extremely well. The beauty of tools is that they can be used without understanding the tool, just what the tool is useful for.
The "Things Other People Have Said" at the end is more interesting than the essay.
I wonder what Dijkstra would think of it. My two best guesses are "This is just a continuation of infantizing everything" and "We did kill math, with programming." I think a lot of people's difficulties with symbolic manipulation are due to the symbols not having immediately interpreted meaning. Dijkstra seems to recommend fixing this by drilling symbol manipulation of the predicate calculus with uninterpreted symbols like "black" and "white". My own approach I have been using more and more is to just use longer variable names in my math, whether written or typed. It really seems like this simple step can be a tremendous aid in understanding what's going on.
Over the past couple of years I've realized just how important sheer memorization can be as I see almost everyone around me struggle with basic calculus facts, which means they struggle with application of the facts. The latest example from a few weeks ago in a junior level stats course with calc 2 prerequisite (which many people take 2 or 3 times here apparently) was when apparently no one but me recognized (or bothered to speak up after 20 seconds) that (1+1/x)^x limited to infinity is the definition of e, which we then immediately used with (1 - const/x)^x = e^(-const). (Which is immediately related to the continual compound interest formula that changes (1+r/n)^nt to e^rt as n->infty which everyone should have seen multiple times in algebra 2 / pre calc when learning about logarithms! The two most common examples are money and radioactive decay.)
Sure that's a memorized fact for me, it's not necessarily intuitive apart from the 1/x being related to logs which are related to e, but come on. In my calc 3 course that I didn't get to waive out of, where it was just me and two others, I was the only one who passed, and when the teacher would try to make the class more interactive by asking us to complete-the-step instead of just a pure lecture the other two were seemingly incapable at remembering even the most basic derivative/integral pairs like D[sin(x)]=cos(x). A lot of 'education' is students cramming for and regurgitating on a test where the teacher hopes (often in vain) that the cramming resulted in long-term memorization. I do this too, cram and forget, but maybe I just do it less frequently or for less important subjects or my brain's wired to memorize things more easily than average (but I disfavor hypotheses that suppose unexplained gaps in human ability as largely static). My high school teacher's pre-calc and calc courses had frequent pure memorization tests such that there wasn't a need to cram elsewhere because that iterative cramming was enough to get long-term memorization (with cache warmups every so often; I did have to breeze through a calculus book in preparation for a waiver exam last year).
A person can only hold so many things in their active, conscious memory at once (some people think it's only 7 plus or minus 3 but that seems like too weird a definition of 'thing' that results in so little; human brains are not CPUs with only registers r0 to r6), so when you start looking at a math proof with x's and y's and r's and greek letters and other uninterpreted single-character symbols all over the place, it's incredibly easy to get lost. If you start in the middle, if your brain hasn't memorized that "x means this, y means this" for any value of "this", you have to do a conscious lookup and dereference the symbol to some meaning even if the actual math itself is clear. My control systems book uses C and R for output/input (I already forgot which is which) but it's so embedded in my brain that Y is typically output and X is input that I use those instead, as does the teacher. I agree with Dijkstra that practice at manipulating uninterpreted symbols makes it a bit easier, but there are quickly diminishing returns and ever since I started programming and saw how PHP uses the $var syntax to denote variables I've been thinking "Why hasn't this caught on in math? It makes so many things much clearer!" But it's not so much the "$" in $var (or @var and other sigils in Perl) but the "var". Saving your brain a dereference step is pretty useful.
Single-character symbols (and multiple character symbols) that not only hide tons of meaning through a dereference, which is naturally how language works, that also suggest a meaning themselves, are stupid and promote natural diseased human thinking. My poster-child here is global warming. Every winter you'll hear the same comments on "When's global warming going to hit here?" The poor choice of global warming as a variable that points to a bigger theory has cost it heavily in PR because humans look at only the phrase instead of what it points to, it's still so bad that people's every day experiences, which they use to form a subconscious prior probability in global warming as a theory, contain "it's really hot all the time and everywhere I've been!" and so they look at "global warming" and dismiss any evidence for/against it based purely on the name and how their experience seems to contradict the name. It's like a computer thinking that a pointer address that happens to correspond to 0xADD means it should invoke addition when it should figure out what 0xADD points to instead which could be anything.
Another use of long names is with Bayes' Theorem in probability. It is only through memorization of the uninterpreted symbols A,B,C themselves that I remember prob(A | B, C) = prob(A | C) * prob(B | A, C) / prob(B | C) But it never made intuitive sense to me and I never bothered memorizing until it was expressed as prob(hypothesis | data, bg_info) = prob(hypothesis | bg_info) * prob(data | hypothesis, bg_info) / prob(data | bg_info). (Sometimes data is replaced by model.) The notion that it relates reason with reality, that it encapsulates the process of learning and scientific reasoning, elevates the equation to the status of a tool instead of something you cram for and regurgitate on a test. An immediately useful application for the tool is using Naive Bayes to filter spam.