3 ms·
This line is a straw man. I'm sure code like that exists, but it's hardly the best we can do. The proposed system is good enough that you don't have to compare
by alphaalpha101 9y ago
This line is a straw man. I'm sure code like that exists, but it's hardly the best we can do. The proposed system is good enough that you don't have to compare it against a straw man for it to look good and useful.
force = 6.67*10^-11*mass_1*mass_2/radius^2
Firstly, we can write it like this
force = 6.67*10^-11 * m1 * m2 / radius^2
And what language doesn't support this?
force = 6.67e-11 * m1 * m2 / radius^2
Andalso what about an abstraction, and the ability to write multiplication naturally?
-- a.k.a. G
-- nobody really knows why this is so different from what relativity predicts
const GRAVITATIONAL_CONSTANT = 6.67e-11
fun gravitationalAttraction(m1, m2, radius) =
GRAVITATIONAL_CONSTANT m1 m2 / radius^2
val force = gravitationalAttraction(mass1, mass2, radius)
Now we actually know what it's calculating and why, and what that tiny number is. Would it be better if rendered as a large fraction? Absolutely. But I think it is less necessary if you write code like this well.
The suggested system is good but not novel. Rendering maths as you type it has been there in Mathematica, etc. forever.
- kmill 9y ago> the ability to write multiplication naturally That syntax doesn't work along with using parentheses for function application unless you do something like making the parser context-sensitive (so function followed by '(' means application but value followed by '(' means multiplication) or treat whitespace as significant (so "f(x+1)" is application but "f (x+1)" is multiplication). This is why Mathematica does Sin[22] instead of Sin(22). (It used to be that (a,b) in Mathematica was shorthand for Sequence[a,b], which led to silly bugs like accidentally writing f(a,b) instead of f[a,b], giving you Times[f,a,b] instead. This is just to illustrate why it is not obvious to make it so that juxtaposition is multiplication.) > Rendering maths as you type it has been there in Mathematica, etc. forever. I know you can type superscripts, subscripts, fractions, etc. using shortcuts. If you meant "as you type it" as in Mathematica will reformat what you type in more traditional notation as you type it, then I am wondering where you can enable that.
- alphaalpha101 9y ago>That syntax doesn't work along with using parentheses for function application unless you do something like making the parser context-sensitive (so function followed by '(' means application but value followed by '(' means multiplication) or treat whitespace as significant (so "f(x+1)" is application but "f (x+1)" is multiplication). This is why Mathematica does Sin[22] instead of Sin(22). I'm not so sure that's true? You can just parse 'a b c d e' as Apply (Apply (Apply (Apply a b) c) d) e) and then you can just say that Apply is overloaded to mean multiplication for numbers, just like + is overloaded to mean concatenation for strings in most languages, but addition for numbers. It doesn't actually change the parsing, your parsing doesn't become context-sensitive. 'Apply x y' would mean multiplication if the arguments are numbers and application if the left argument is a function. Even if you allow multiplication of functions by scalars (which you probably shouldn't, IMO) you can easily say that 'x f' means 'x times f' while 'f x' means 'f applied to x'. >I know you can type superscripts, subscripts, fractions, etc. using shortcuts. If you meant "as you type it" as in Mathematica will reformat what you type in more traditional notation as you type it, then I am wondering where you can enable that. Well you can write :alpha: and it will make it an actual alpha character, you can write superscripts and it will superscript them, it will make fractions readable, etc. It will turn -> into a unicode right arrow, that sort of thing.
- kmill 9y agoThat's altering the syntax for function application by allowing f x to mean f(x), which is fine but changing the rules. If we do go with that, then "a b c" should be "Apply a (Apply b c)" because of the associativity of application --- traditional math tends not to have functions which return functions. There is an ambiguity which comes up when you allow both f x and f(x) syntax, which is you cannot tell the difference between f(x,y) and f((x,y)) if your language has tuples. (One solution: make tuples be like Mathematica's Sequence, thus establishing the associativity of Cartesian products once and for all.) A gotcha is that you can't write f(x)(y) if your function does return a function, since this will parse as f(x y). You would need to write (f(x))(y) instead. (If you insist the associativity rule should be the other way, then 3f(x) would be (3f)x, which is possibly ok, and sin cos x would be (sin(cos))(x).)