I'm concerned about Chris's desire to express mathematical formulas directly in an editing environment.
Coming from a mathematician with more than enough programming experience under his belt, programming is far more rigorous than mathematics. The reason nobody writes math in code is not because of ASCII, and it's not even because of the low-level hardware as someone else mentioned. It's because math is so jam-packed with overloaded operators and ad hoc notation that it would be an impossible feat to standardize any nontrivial subset of it. This is largely because mathematical notation is designed for compactness, so that mathematicians don't have to write down so much crap when trying to express their ideas. Your vision is about accessibility and transparency and focusing on problem solving. Making people pack and unpack mathematical notation to understand what their program is doing goes against all three of those!
So where is this coming from?
PS. I suppose you could do something like, have layovers/mouseovers on the typeset math that give a description of the variables, or something like that, but still sum(L) / len(L) is so much simpler and more descriptive than \sigma x_i / n
I agree with you, and incidentally so does Gerald Sussman (co-inventor of Scheme). He helped write an entire book on Lagrangian mechanics that uses Scheme because he believes the math notation is too fuzzy and confusing for people.
Both this and the subsequent text on differential geometry are very good but they are written against this enormous undocumented scheme library (scmutils) that is in my opinion very difficult to debug or figure out how macros expand out.
The mathematical notation also lacks a lot of type information. Looking at his example formula, First of all, both x and N are magic variable names, where did they come from? Second, what happens if x is a string and + is considered string concatenation. Mathematical notation has all the problems of duck typing and even more. In a way that's also the beauty of math, you can multiply matrices with same rules you learned scalar multiplication in 2nd grade. For quick problems where you can keep all variables in your head this is nice to save on typing, but for larger applications you need clearly defined interfaces and a way to encode them.
This. Types are the hardest thing about translating mathematics into programming. And it's really the fault mathematics (or a feature of it, depending on your viewpoint).
Excellent point - reminds me of a quote about Prolog that stating problems in a solvable form is as hard as solving the problem. Creating a graphical environment can't sidestep the difficulty in rigorously defining a problem or figuring out how to solve it.
Coming from a mathematician with more than enough programming experience under his belt, programming is far more rigorous than mathematics. The reason nobody writes math in code is not because of ASCII, and it's not even because of the low-level hardware as someone else mentioned. It's because math is so jam-packed with overloaded operators and ad hoc notation that it would be an impossible feat to standardize any nontrivial subset of it. This is largely because mathematical notation is designed for compactness, so that mathematicians don't have to write down so much crap when trying to express their ideas. Your vision is about accessibility and transparency and focusing on problem solving. Making people pack and unpack mathematical notation to understand what their program is doing goes against all three of those!
So where is this coming from?
PS. I suppose you could do something like, have layovers/mouseovers on the typeset math that give a description of the variables, or something like that, but still sum(L) / len(L) is so much simpler and more descriptive than \sigma x_i / n