That's not that great, since it uses infix precedence - either explicitly (here) or implicitly. I need to read into it to understand that a sum is computed and I need to then find out the boundaries of the subexpressions. But the brain can be trained for that, just as it can be trained to read Lisp, Erlang, or even APL code.
Nested lists are the base for Lisp syntax. Thus numeric code is just like other ordinary code. Lisp was developed to also do symbolic computations: computing with expressions with symbols.
Thus to read Lisp you need to learn to read syntax based on nested lists and then numeric expressions are just an application of that. Still one is trained to do math with lot's of fancy syntax - fancy syntax you won't find in normal code anyway. For example the typical graphical root notation is mostly not found in programming languages.
If I (as a Lisp programmer) had problems understanding numeric expressions, I'd reformat them:
(+ (- a b) (* 100 (sqrt y) x) (* 50 (expt x 2)))
as
(+ (- a b)
(* 100 (sqrt y) x)
(* 50 (expt x 2)))
That's just another way to format a nested list.
The main problem is mapping that back to existing external forms which uses mixed infix/prefix/postfix syntax.
(a - b) + (100 * y^1/2 * x) + (50 * x^2)
Lisp allows one to compute this stuff:
CL-USER 18 > '#i( (a - b) + (100 * y^^(1/2) * x) + (50 * x^^2) )
(+ (- A B) (* 100 (EXPT Y (/ 1 2)) X) (* 50 (EXPT X 2)))
CL-USER 19 > (let ((*print-right-margin* 30))
(pprint *))
(+ (- A B)
(* 100 (EXPT Y (/ 1 2)) X)
(* 50 (EXPT X 2)))
> That's not that great, since it uses infix precedence
This is not true. I was careful to not use operator precedence as I agree it's bad. I said that the syntax I had in mind reads left-to-right, hence the operators also work that way. So `5 * 3`, assuming `` takes 2 parameters, is all you need to know about the operation (you don't need to check what's next, you have no precedence to worry about).
> to read Lisp you need to learn to read syntax based on nested lists
Exactly! That's why it's so hard. Our brains are not good at keeping several levels of nesting. Any code that is deeply nested is inherently hard to read.
> But the brain can be trained for that,
That's something we should avoid to make programming more approachable. People already have a hard time learning other more important things, so let them use their mathematical intuition for this.
(a - b) + (100 * y^1/2 * x) + (50 * x^2)
You seem to not have fully understood my point. This is not what I am proposing as being better than Lisp.
This is what this expression looks like in my proposed notation:
a - b >> 100 * x * sqrt y >> x ** 2 >> 50 * >> + >> + ;
There's zero nesting, but you still have to keep a few intermediate values (that's inherent to the calculation and this approach keeps that to the optimal minimum).
I thought it was obvious, but let me point it out explicitly: there is no operator precedence in this notation.
I believe this is fundamentally better than Lisp and C-like languages.
a - b >> 100 * x * sqrt y >> x ** 2 >> 50 * >> + >> + ;
That's a mix of infix and postfix. I don't think writing code like that will be very readable for most people. Humans are much more trained for prefix and infix notations, than for postfix stack operations. We don't see widespread usage of postfix notations in programming languages besides languages like Forth, Postscript or Factor.
The Lisp notation has a different reason why it has been invented: it is based on a data structure around nested lists of symbols. That's a very simple and powerful model. code is written as data. Lisp programmers find the code as data idea attractive. Without that, Lisp would have kept the original idea of a conventional syntax.
> Humans are much more trained for prefix and infix notations
Non-programmers are not trained for prefix notation. Only Lisp programmers use prefix notation for mathematics, so I don't believe your assertion has much evidence to show for it.
> The Lisp notation has a different reason why it has been invented
Yes, and that reason was not readability. That's what I am trying to show.
> code is written as data
Which is great fun, but most programmers don't need or want that.
; Yes, and that reason was not readability. That's what I am trying to show.
Not convincing so far. It turned out that the notation was the most practical (writing, reading, manipulating) for its purpose, otherwise the original syntax would have been used.
> Which is great fun, but most programmers don't need or want that.
Nested lists are the base for Lisp syntax. Thus numeric code is just like other ordinary code. Lisp was developed to also do symbolic computations: computing with expressions with symbols.
Thus to read Lisp you need to learn to read syntax based on nested lists and then numeric expressions are just an application of that. Still one is trained to do math with lot's of fancy syntax - fancy syntax you won't find in normal code anyway. For example the typical graphical root notation is mostly not found in programming languages.
If I (as a Lisp programmer) had problems understanding numeric expressions, I'd reformat them:
as That's just another way to format a nested list.The main problem is mapping that back to existing external forms which uses mixed infix/prefix/postfix syntax.
Lisp allows one to compute this stuff: