> Hint: if the first notation is so superior, why don't math papers use it.

Math papers usually use neither the first nor the second.

they use:

  (a + b)(c + d)

in the example you propose, and, reversing the operators so that the first style would have:

  (+ (* a b) (* b c))

and the second:

  (a * b) + (c * d)

math papers would usually have:

  ab + cd

So, I'm not sure "math papers do it differently" is the argument you want to use to advance your second syntax over the first.

Of course, since in lisp + and * are variadic rather than binary operators, they are a lot more like the pi and sigma operators applied to sets in mathematics than binary operators. Which are prefix, not infix. So, there's that.

Additionally there's more than one macro system out there to allow for infix math in Lisp... And for non-mathy things, in Clojure at least you're often using the threading macro -> or some variation of do/doto.

I do understand, but I'll also point out that that first expression will often (with longer variables or expressions in particular) be broken out like:

  (* (+ a b)
     (+ c d))

Which is readable, though not necessarily compact.

Also, * and + in the former, aren't strictly the same as in the latter. * and + take an arbitrary number of parameters in CL. From [0], `(* )` => `1`. I can't test, but I believe `(* 2)` => `2` (the spec doesn't describe the case of a single parameter, unless I'm missing it). `+` is the same, but `(+)` => `0` instead, it's identity value.

Order of operations is made more explicit, and, I've found, it's more useful to think of `+` and `*` as `sum` and `product` rather than `plus` and `times`.

[0] http://www.lispworks.com/documentation/HyperSpec/Body/f_st.h...

[1] http://www.lispworks.com/documentation/HyperSpec/Body/f_pl.h...

Math does also have `sum` and `product` in the form of Sigma and Pi. Of course, not exactly the same thing (since they operate over a set, not discrete elements).

I would venture to say that the reason infix notation is naturally preferred is related to our psychology, the same way most human languages are SVO (Subject Verb Object) or SOV. VSO languages (Lisp like) are less prevalent.

In general my opinion is that when a majority vastly prefers one alternative, there is usually a strong reason for it (even if it may be irrational) and it's foolish to go against the grain.

I seem to recall that SOV (reverse Polish notation) is marginally more prevalent than SVO among the world's languages... though it is true that most creoles are SVO, which does at least seem to indicate that it's a default of sorts.

Infix is mostly used, in programming, within mathematical and logical expressions. But the majority of my code spends its time in some kind of chain of function calls, which has the verb first. Maybe if I did more with OO-languages I'd see it differently?

Interesting. OO syntax often is object.function(arguments), which is subject-verb-object order. I never thought of it that way before. You can throw some adverbs in among the arguments, too.

That's correspondent with how Java and especially Obj-C and super especially AppleScript programmers try to write code that reads like COBOL, er, English.

Lisp is VOO, not SVO.

Java is SVO.

C is VOO too.

If you have Quicklisp[1] installed you can install the "infix" package and get infix notation in Common Lisp[2]:

    $ sbcl
    This is SBCL 1.2.4.debian, an implementation of ANSI Common Lisp.
    More information about SBCL is available at <http://www.sbcl.org/>.
    
    > (ql:quickload 'infix)
    ; Loading package
    (INFIX)
    > #i(1 + 1)            ; addition
    
    2
    > #i(2^^128)           ; exponentiation
    
    340282366920938463463374607431768211456
    > (defun factorial (x)
         #i(if x == 0 then
              1
            else
              x * factorial(x-1)))       ; infix function call
    
    FACTORIAL
    > (factorial 5)
    
    120
    > #i(factorial(5) / factorial(6))
    
    1/6
    > '#i((a + b) * (c + d))      ; Put a ' before the #i() to see what code is generated
    
    (* (+ A B)
       (+ C D))

--

[1] - https://www.quicklisp.org/beta/ [2] - Don't know if there is a similar package for Scheme.

> Don't know if there is a similar package for Scheme.

I have to agree with others in the thread that infix in Lisp/Scheme is not the convention, and IMO an awkward fit. Don't recall encountering infix in any published/shared code I've seen, it may exist, but to learn Scheme becoming comfortable with s-expr notation is definitely necessary.

However, there is SRFI 105[0] which describes "curly infix expressions". It's implemented in Guile 2.x, possibly available in a few others but evidently not had a lot of uptake among Schemes.

[0] http://srfi.schemers.org/srfi-105/srfi-105.html

Edit: added URL

I wouldn't recommend using infix libraries if you really want to get into Common Lisp though. They're a bit of a crutch for people coming from other languages, but that's it.

Pretty much the whole language is based on Polish notation. The sooner you realise that + - * / are just function names like any other, the better you'll do.

For example:

  (+ 1 2 3)

  in plain symbols is just:

  (function parameter parameter parameter)
  
  But if I were to write my own addition function:

  (addition 1 2 3)

  it would also be:

  (function parameter parameter parameter)

  and so is:

  (http-request "http://www.google.com")

  (function parameter)

If you use infix notation, you're writing half your code in a competely different semantic to the other half. I can't imagine it helping people really get a proper grasp of how Common Lisp works.

Nobody claimed Lisp syntax was optimal for math papers. Neither is C syntax. The Lisp syntax does have advantages for program source code. Sure, it has disadvantages too. Everything is a compromise.

The Lisp syntax is so incredibly controversial, and that fact itself is incredibly strange to me. I see it as a pragmatic engineering decision: let's represent source code as syntax trees, and then sophisticated editing modes become straightforward, macros become straightforward, and the syntax becomes very uniform.

This big thread indicates another reason Lisp isn't popular: because people keep arguing back and forth about the textual syntax, rather than discussing actual experiences with using it.

There are actual features which make Lisp a bit more difficult to understand and a few are related to syntax: especially the code as data feature. Some elements of the language have different purposes: both as code and as data. Symbols can be data and they can be identifiers. Lists can be data and they can group elements of the programming language. Others have only one purpose. For example an array is always data.

Symbols and lists behave differently depending on the context:

Examples for Lisp snippets:

   (foo bar baz)  ; it could be a macro, function or special operator form

   (quote (foo bar baz))   ; here it is data

   (defun do-something (foo bar baz) (a b c))  ; here it is an arglist

   (defun do-something (a b c) (foo bar baz))  ; one element later it is a form

These context need to be learned and actual visual clues are a) the symbol in front and b) the structure of the expression.

This is puzzling for a lot of people. A few never really take that hurdle.

Yes, they learn the second syntax from birth. There have been arguments to teach the lisp syntax in mathematics due to it being easier to understand with multiple arguments:

    (+ x y z a) instead of (x + y + z + a)

Also, there are no order of operations problems with the lisp syntax like there are with traditional mathematical notation (unless you use parens, which makes it look even more lispy).

I found math major students to grasp Lisp much faster than C.

Therefore I would say the answer is simply familiarity and concern for the audience.

So why don't we write all binary operations that way? eg. x f y instead of f(x,y). I've always felt more comfortable with prefix notation, especially because it easily generalizes to more than two arguments. I think infix notation is an accident of mathematical history.

Welcome to Haskell, where anything can be infix :-)

That can be nice in a lot of situations. e.g.

    (+) 4 2
 vs. 
    (+) <$> Just 4 <*> Just 2

I usually prefer the applicative style above to

    liftA2 (+) (Just 4) (Just 2)

because it preserves the "form" of the original expression and generalizes to more arguments. ie. it doesn't require liftAn for whatever n number of arguments my function takes.

With all due respect, math papers don't, I think, pretend that their syntax makes any claims to optimality of any kind.

Indeed, most math syntax (in my experience) has a very explicit reason why it's used: historical circumstance, convention and common tradition.

Arithmetic is one place where infix notation is generally easier to read. If I were writing a program that basically just did a load of mathematics I may even consider using a different language.. However looking over the software I generally develop, I probably need to use arithmetic in about .01% of the code.

> Hint: if the first notation is so superior, why don't math papers use it.

As a mathematician I'd love to use it in my papers, but no reviewer would accept such a paper.

I have no idea why the people who write math papers make the choices they make.

But I'd like to point out that in your second example the parentheses are needed because infix notation is inherently more complicated.

In the first example however, the notation is far simpler: a simple list of function plus zero or more arguments.

Math papers use a very complex 2d notation last I've looked.