Having spent time at the MIT AI Lab and having co-founded a company whose principal product was a Lisp/C hybrid, I think the challenge with mainstream adoption of both Lisp-like and functional languages is the syntax. There's an element of "don't use a programming language that's hard to hire for" but I think that's secondary as it never bothered us or posed a real problem.

Naughty Dog's Crash Bandicoot games (which I also worked on) used Lisp for all the character control logic.

Dan Leibgold gave a talk about their system at RacketCon a few years ago: https://www.youtube.com/watch?v=oSmqbnhHp1c

Ironic(?) considering there is almost no syntax to Lisp.

Using Racket:

  (if bool then else) instead of (if bool then) or (if (bool then) (bool else))
  (if (> x y)
    (x)
    (y)) ;fails for numbers because (x) is considered a function call (even though 3 is an invalid identifier and thus can be assumed to be always be a number).
 (define (fun x y) (...)) instead of (define fun (x y) (...)) or (define ((fun (x y)) (...)))

Just because I'm not using {}'s here and infix there doesn't make it any less syntax. That's just the two most basic forms too; bring in loop? forget about it. This also ignores things like '(@,) or (x . y) but I'm not a lisper so I don't know how often that actually comes up

https://common-lisp.net/project/iterate/

Even the ITA/Google style guide says to avoid loop if possible:

https://google.github.io/styleguide/lispguide.xml#Iteration

Almost every macro in Lisp provides syntax.

It's one of the strengths of Lisp imo; that you don't need to think much about how the parser is going to interpret your code (ie. missing semi-colons, whitespace, use curly brace here, square bracket there, etc.), just stick to (func arg1 arg2) and all you're left with is your own logic errors.

    (func arg1 arg2 (func arg3))

But Lisp has a few special forms and zillions of macros. Most of them are syntax.

Lisp has IF. What is the syntax of IF?

    IF form then-form else-form+

    cond {clause}*
    clause::= (test-form form*) 
 

    defun function-name lambda-list [[declaration* | documentation]] form*

    lambda-list::= (var* 
                    [&optional {var | (var [init-form [supplied-p-parameter]])}*] 
                    [&rest var] 
                    [&key {var | ({var | (keyword-name var)} [init-form [supplied-p-parameter]])}* [&allow-other-keys]] 
                    [&aux {var | (var [init-form])}*]) 

> It's one of the strengths of Lisp imo; that you don't need to think much about how the parser is going to interpret your code (ie. missing semi-colons, whitespace, use curly brace here, square bracket there, etc.), just stick to (func arg1 arg2) and all you're left with is your own logic errors.

What you describe is just the data syntax for s-expressions. Not the syntax of the programming language Lisp.

Exactly. The data syntax if what most people worry about. The names of the verbs (funcs/methods/etc.) may change from language to language, but the data syntax is what trips people up. I think Lisp has one of the simplest and clearest. There are very few cases of "oh you can't write that there, only nouns are allowed in that position".

I agree with your point, but I think we're arguing slightly different points here ;)

    (lambda x (+ x x))
    (cond (> x 2) (+ x x))
    (if (> x 2)
        (do-this when-true)
        (also-do-this when-true))

That is to say, a problem with s-expressions is that they are so regular that everything looks the same, and when everything looks the same, it can become an obstacle to learning. Mainstream languages are not very regular, but they are more mnemonic. I think Lisp works best for a very particular kind of mind, but that for most programmers its strengths are basically weaknesses.

    (if (> x 2)
        (do-this when-true)
      (also-do-this when-true))

    x > 2 ? doThis(whenTrue) : alsoDoThisWhenTrue();

    x > 2 ? doThis(whenTrue) ; alsoDoThisWhenTrue();

If not, how is the macro different other than implicitly changing the evaluation?

for a more simple example, why is the idiom CALL-WITH-FOO (implemented as a function) not syntax while WITH-FOO (implemented as a macro) is? What precisely is syntax is somewhat nebulous (if I use a regex library in C, have I added syntax to the language? Regexes certainly are syntax, despite being wrapped in a C string).

(def (fun x y) (...)) is syntactically different than (def fun (x y) (...)) even if they are semantically equivalent.

syntactical ( ) isn't actually a procedure call we can see this in (define (id x y) (..)) or (let ((x 3)) ...) in the theoretically pure Lisp semantically it's just a leaf in the tree but as part of an if-block in a real language it gets treated as procedure call even if it makes no sense.

The Lisp syntax is defined on top of s-expressions.

For example Common Lisp has a CASE operator. That's the EBNF syntax:

    case keyform {normal-clause}* [otherwise-clause] => result*
    normal-clause::= (keys form*) 
    otherwise-clause::= ({otherwise | t} form*) 

    (case id
      (10 (foo))
      (20 (foo) (bar))
      (otherwise (baz)))

Every special operator and every macro provides syntax. Since users can write macros themselves, everybody can extend the syntax. On top of s-expressions.

    list -> ({symbol | number | string | list}*)

* using SBCL: (defun foo (x y) (...)) instead of Racket (define (foo x y) (...)) is again an example of syntax.

   (f x)

   f(x)

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

  (a + b) * (c + d)

Math papers usually use neither the first nor the second.

they use:

  (a + b)(c + d)

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

  (a * b) + (c * d)

  ab + cd

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.

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

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...

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.

Java is SVO.

C is VOO too.

    $ 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.

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

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)

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.

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

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

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

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

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

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

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

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

    c = sqrt(a*a + b*b)
    
    (set! c (sqrt (+ (* a a) (* b b))))

In this example, the advantage is on the C side, because pretty much everybody who knows any math knows that multiplication has precedence, and they can just read that syntax. If you have to go look at the precedence chart in K&R or Stroustrup before you know how to parse the expression correctly, well, then the Lisp approach is probably more efficient...

    (define c
      (sqrt
       (sum (sqr a)
            (sqr b))))

Easy to read as you see and easy to understand. This:

    c = sqrt(a*a+b*b)

Infix notation works better when it is applicable. Limiting the number of parentheses is also best when possible.

You can add parentheses and make it less compact if you want. You could theoretically write c=sqrt(axa+bxb) as:

    c =
        sqrt(
            ((a *
                a) + 
                (b *
                    b)))

You are now arguing against parens. You can have mostly prefix syntax without parens, with blocks delimited with indentation only. Scheme's sweet-expressions[1] are one such example. Anyway, please take my example, remove the parens and check if your argument still applies.

If it does, then it's down to the function names and your (common) misconception that "+" or "^" is somehow more readable, easier to understand or something than "sum" or "sqr". Where I simply disagree. BTW: why do you insist on using infix syntax for a couple of operators, while you use every other possible operator in a prefix notation and are happy with it? What is the difference between "sqrt" and "-" which makes it ok to use sqrt in prefix form?

> Limiting the number of parentheses is also best when possible.

No. It's only best if it aids readability. This is something that Lisp does rather well actually - there are many examples of equivalent Java and Clojure expressions where Clojure version has half as many parens. Getting rid of parens for the sake of getting rid of parens is counterproductive.

[1] http://srfi.schemers.org/srfi-110/srfi-110.html

And yes you can remove the parentheses, but not only does no one do that, it still takes up 6 lines. And then you have significant whitespace too.

>why do you insist on using infix syntax for a couple of operators, while you use every other possible operator in a prefix notation and are happy with it? What is the difference between "sqrt" and "-" which makes it ok to use sqrt in prefix form?

Because that's universal and standard for math notation. But also sqrt only takes one argument. If it took two arguments, then it would be perfectly reasonable to add an infix operator for it too. Many languages do add infix operators for everything from combining strings to ANDing booleans, etc, because they are so much more readable.

  c = sqrt(a^2+b^2)
  vs.
  define(c, sqrt(sum(sqr(a),sqr(b))))

  def getMaxValue(numbers):
		answer = numbers.first()
		for (i in xrange(numbers.length)):
			if (numbers[i] > answer):
				answer = numbers[i]
		return answer

  vs.
  (defun get-max-value (list)
	  (let ((answer (first list)))
	    (do ((i 1 (1+ i)))
	        ((>= i (length list)) answer)
	      (when (> (nth i list) answer)
	        (setf answer (nth i list))))))

  if you could only use python functions:
  defun(get-max-value, [list], 
		let(answer,first(list)),
		 do( (i,1,(1+ i)), 
		 	(>=(i, length(list)), ans), 
		 when( >(nth(i,list),answer), 
		 	setf(answer,nth(i,list)))))

  defun(get-max-value, [list], let(answer,first(list)), do( (i,1,(1+ i)), (>=(i, length(list)), ans), when( >(nth(i,list),answer), setf(answer,nth(i,list)))))

    (defun get-max-value (list)
      (reduce #'max list))

    (defun get-max-value (list)
       (loop for element in list maximize element))

Any language where you write an entire function as a huge one liner expression with functionality in nested function calls is hard to read. It's the behavior, not the syntax per say.

What the actual behavior is doesn't matter as much, even if you can reduce both of them to one liners in many languages.

ex:

  def get-max-value(list)
    reduce(:max, list)
  end

In actual Lisp practice, one uses macros, special forms and function calls.

You seem to have failed to understand the difference.

There are two REAL reasons why Lisp is harder to read than some other languages:

* the syntax looks and works slightly different and most programmers have been trained to other programmning language syntax. With training, this is less a problem.

* Lisp uses a data syntax as the base layer of the programming languages and encodes programs as data. So the syntax of Lisp comes on top of s-expressions. Very few other programming languages are doing that and as a consequence it complicates a few things. The user of Lisp has to understand the effects of code as data. This is something you don't have to understand in Java or Python. It can be learned, but it has to be learned.

At the same time, this code as data principle of Lisp gives a lot of power, flexibility and new capabilities. It makes Lisp different and in some way more powerful than Java or Python. The added power comes from easy syntactic meta programming in Lisp, which neither Java nor Python provide. This has also consequences for interactive programming, since programs can be written and manipulated by programs under user control.

This does change the situation somewhat.

I'm not sure if this is what you're talking about but there actually is a Lisp where you can call Python functions. It's called Hy[1] and I encourage you to take a look, it borrows some good solutions from Clojure, but generally is quite an acceptable Lisp :)

[1] http://hylang.org

Why do mathematicians not use s-exps but syntax that is much more similar to C? Reading "sum" "mul" etc. takes longer than if you have visual anchors like * +. And infix is an advantage for simple expressions, because they split arguments, where as with sexps you have to parse from left to right and count parens.

Please tell me why should I care. No, really - I'm a programmer, not a mathematician.

> Reading "sum" "mul" etc. takes longer than if you have visual anchors like * +.

Citation for this?

IMO it's exactly the opposite, but I may be wrong. Some kind of reference would be nice.

> And infix is an advantage for simple expressions, because they split arguments, where as with sexps you have to parse from left to right and count parens.

Ok, so 2 ("sum" vs. "+", 3 vs. 1 char) additional characters are bad, because they take longer to read, but for example 3 additional characters here:

    (+ a b c d)
    vs.
    a + b + c + d

> Citation for this? IMO it's exactly the opposite, but I may be wrong. Some kind of reference would be nice.

I know it from myself and don't think I have to to provide evidence that by large most people work like this. Reading and interpreting text is just WAY more complex a process and thus much slower than associating a shape with a meaning.

For example, application designers have known for a long time that it's important to build a symbolic language (icons etc) because that's just way faster (once you have learned what the symbol means, for example with the help of a tooltip).

There's another guy who explained this at length

http://c2.com/cgi/wiki?LispLacksVisualCues

Search for "top" throughout the page.

> (+ a b c d) vs. a + b + c + d

Yes. But as explained in my other comment, that's not optimizing for the common case.

I don't think there is a difference in speed between reading "sum" and "+". You don't read the word "sum" letter by letter: you see it as a whole token and your brain recognizes it instantly.

> For example, application designers have known for a long time that it's important to build a symbolic language (icons etc) because that's just way faster (once you have learned what the symbol means, for example with the help of a tooltip).

You're talking GUI, which is different than writing and reading code. There are, for instance, much less GUI elements visible on the screen than there are identifiers even in a short snippet of code and there is much more context available for deduction in the code than in the GUI. I don't think the two situations - recognizing GUI features and recognizing and understanding identifiers in the code - are comparable.

Humans have excellent shape recognition -- recognizing (and differentiating) a tree and a person happens subconsciously, effortlessly. Interpreting the words "person" and "tree" takes way more effort.

Similarly, humans have usually very good spatial sense. If there are persons to the left and to the right of a tree, it is effortless to recognize that they are "separated".

> You're talking GUI, which is different than writing and reading code.

No. I'm talking perception.

> There are, for instance, much less GUI elements visible on the screen than there are identifiers

That depends. There are very complex GUIs out there. But let's assume it for a moment. (By the way that typically that means the code is not good (weak cohesion)).

> there is much more context available for deduction in the code than in the GUI.

That is not supportive of your previous argument: The more identifiers, the less context per identifier.

> I don't think the two situations - recognizing GUI features and recognizing and understanding identifiers in the code - are comparable.

It's both about perception. It's very, very important that programmers can focus on their work instead of wasting energy building parse trees in their minds, incurring severe "cache misses". Again, take this simple commonplace example:

  (sum (mul a (minus (b c)) d)
  a*(b-c) + d

Conversely, the infix/symbol operators example I can map out with minimal, and linear, movement of the eyes. In most cases I don't even need to parse it as a tree -- it's almost a sequence. On a good day, it costs me maybe a second to parse the thing and extract the information I need.

Another advantage of symbols for arithmetic is that they give a sense of security, because one can intuitively infer that they have "static" meaning. While usually words are reserved for things that change, i.e. mutable variables. Being able to infer non-mutability based on shape alone gives a huge advantage.

I disagree that it's obvious. Moreover, I don't believe there is a measurable difference between the speed of recognizing "sum" and "+", once you're equally familiar with both.

> The more identifiers, the less context per identifier.

I don't believe it's that simple, but we're starting to go into semantics (which are part of comprehensibility of code, but not part of it's readability I think).

> If you don't think there's a huge difference I can't help you.

I think you can help yourself: just go and train yourself in reading prefix notation, like I did. Then get back to this example and then tell me again that there is a huge difference.

> I'm sure I need about three seconds to parse the sexp

I don't even know how to measure the time I needed to read the sexp, it was that short. And I even instantly realized that you've put parens around "b c" in the "minus" call, which would cause an error in most lisps.

> Conversely, the infix/symbol operators example I can map out with minimal, and linear, movement of the eyes.

That's why I used newlines and indentation in my example above. To take your example:

    (sum (mul a (minus b c))
         d)

Also see my other comment on familiarity: https://news.ycombinator.com/item?id=11180682

Like in a binary tree, where half of the elements are in the lowest level.

> you've put parens around "b c" in the "minus" call

You have a point. One pair of Irritating Superfluous Parentheses less.

    > (sum (mul a (minus b c))
    >      d)

I'd love to see eye-tracking data which show the tradeoffs between various syntaxes.

The regularity and the simplicty of sexps is of course good for computers, because these can barely associate. Because they can't learn new tricks (they have fixed wiring). But humans have streamlined their languages (which also includes syntax; again, I'm not differentiating here) to their environments since forever.

Sexps are also good for abstraction and meta programming. But as we all know abstraction has a cost and there is no point in abstracting an arithmetic expression. And most code, for that matter.

Fair enough, but then please stop using single letter variable names, add type annotations where applicable, provide docstrings and contracts for functions. Comprehensibility is so much more than syntax that I think mixing the two will make for even more interesting, but even less fact-based discussion.

> I'd love to see eye-tracking data which show the tradeoffs between various syntaxes.

Yeah, that would be very interesting. The thing is, there is no such data available, but you still are convinced that one kind of syntax is better than the other. I'm not - from where I stand the differences and tradeoffs in readability of syntaxes, once you know them equally well, seem too minor to measure.

> Even the consideration to sprinkle such a trivial expression over multiple lines

No. It's just different way of getting to the same effect. I don't see why would one be worse than the other (splitting things using infix operators vs. splitting things using horizontal and vertical whitespace).

Other than that, you completely avoided the familiarity issue. Do you think that we're genetically programmed for reading infix syntax? If not, then it means we need to learn infix syntax just like any other. My question was, would someone not yet exposed to infix propaganda have a harder time learning infix (with precedence rules and resolving ambiguities) or prefix?

You also ignored my question about the difference in readability when you are equally well trained in both syntaxes. You can't compare readability of two syntaxes fairly unless you have about equal amount of skill in both. And the fact that readability is influenced by skill is undeniable. So, in other words, are you sure you're as skilled with sexps - that you wrote comparable amount of code - as with infix? Honestly asking.

Absolutely. It's a tender flower.

> No. It's just different way of getting to the same effect. I don't see why would one be worse than the other (splitting things using infix operators vs. splitting things using horizontal and vertical whitespace).

It's very important since size matters. Efficiency of encoding and cost of decoding (~ perception) matters. But if you don't think it makes a difference -- fine, you are free to read braille instead of plain text even if you have perfect eyesight. You can also add three layers of parens around each expression if you think that's more regular.

> Do you think that we're genetically programmed for reading infix syntax?

No. There's this fact that all combinations of basic grammar are represented in natural languages: SVO, SOV, VSO, VOS, OSV, OVS. And then there are some programming languages which don't differentiate between subjects and objects, but go for (OVO), VO, VOO, VOOO... (or concatenative style OV, OOV, OOOV...). Which is great since the goal of formalism is to be "objective". (Note that Object-oriented programming is actually subject-oriented programming from this standpoint. It's not "objective")

Instead I say that it is more efficient if syntax is optimized for the common cases. Shorter is better, if the decoding won't produce more cache misses. Infix and symbols don't produce cache misses for the vast majority of humans, in the case of arithmetic (read: mostly sequential, barely tree-shaped) expressions.

Sexps are inherently unoptimized for the common cases. They are "optimized for abstraction": for regularity. It is an explicit design goal to not differentiate things which are different "only" on a very concrete level. Instead of content, form is accentuated. This is not suitable for the > 95% of real life software that is just super-concrete and where abstraction has no benefits.

I'm sure I have now given 5 to 10 quite plausible examples which support the standpoint that symbols-and-infix arithmetics is good for humans, based on how their mind works. You haven't provided any counter-arguments but just shrunk off everything. But thanks anyway for that. I think I'm satisfied now with the examples that came out.

> are you sure you're as skilled with sexps [..] as with infix?

No. Never will be.

Are you? Show me a Lisp program with more than casual usage of arithmetics and tell my why you consider it readable. By the way, the first google hit I just got for "lisp arithmetic readability" is http://www.dwheeler.com/readable/

You tried to prove your theory by finding positive evidence. But the evidence is very weak and far fetched.

> which support the standpoint that symbols-and-infix arithmetics is good for humans, based on how their mind works.

Given that we largely don't know how the mind 'works', that's a weak argument.

> Show me a Lisp program with more than casual usage of arithmetics and tell my why you consider it readable.

Given that a lot math code is expressed in low-level Fortran, I'll take Lisp every day.

From a statistics system in Lisp:

    (defgeneric gaussian-probability-density (x params)
      (:documentation "general gaussian density method.")
      (:method ((x number)
                (params gaussian-probability-univariate-parameters))
        (\ (exp (* -1.0 (/ (- x (mean params))
                           (standard-deviation params)))
           (sqrt (* 2.0 pi (variance params))))))

And you don't think (sum (mul a (minus b c)) d), or (+ (* a (- b c)) d) for that matter, is more readable than a * (b-c) + d, do you?

> There are in fact, a lot of uses of sums and products, so after a while, they are pretty naturally.

I think you are talking about summing up a collection (like, an array, a matrix, etc.) as opposed to building an expression tree. Of course, sum(myIntList) is just fine. That's a whole different story.

There are also the rare cases where you have to sum, like 6 integers. (sum a b c d e f) might not be worse than a + b + c + d + e + f. But that's by far not the common case in most problem domains. The common case is like a*(b-c) + d.

Starting in elementary school, everyone learns to read math notation. By high school, everyone knows what

  c = sqrt(a*a + b*b)

Do you think that, to a non-Lisp programmer, the Lisp version is easier to read? Do you think it is easier to read to a non-programmer who has had high school math? Or is it just easier to read for you?

We're either talking about objective readability or personal familiarity. What you say is that, after extensive training for many years, it is easier for people to read notation they were trained to read. This is both true and utterly uninteresting.

What is interesting, though, is how much training you need to read prefix and how much training you need to read infix. It's obvious that infix takes more time to learn: operator precedence and things like using "-" in both infix and prefix forms make it objectively more complex than prefix notation. You just forgot how much time you spent learning it.

> Do you think that, to a non-Lisp programmer, the Lisp version is easier to read? Do you think it is easier to read to a non-programmer who has had high school math?

Again, this is not interesting at all. You're talking familiarity, not readability. Of course, it's easier to read something you've been taught to read. To make this more objective, take an elementary school kid - who wasn't exposed to years long infix propaganda - and check both notations' readability with them.

Personally, I learned to read just about any kind of notation used in programming. From my observations, there are only minor differences between the speed of comprehension when using different notations - once you've trained enough. The difference is how much training you need. I can tell you that reading J - an infix language, it's an APL descendant - took me much, much longer to master than reading Lisp.

Maybe the ordering of something is being forced. Maybe something else is going on, but whatever it is requires more thought than things that are parentheses free.

So you look at Lisp and your brain locks up the brakes, with "WTF is going on here??? I'm out".

It's like going from Arabic numerals to counting by groups of five; initially, it feels like you're losing expressive power. And, of course, at a glance, you can't read "|||||||||||||||||||||||||||||" as quickly as you can "28".

http://c2.com/cgi/wiki?LispLacksVisualCues

After a brief period of usage 'the parens disappear' and you just read the code by indentation.

I was dumping ASTs as part of a little language project recently and my first impulse was to render them as S-expressions. Alas, it just wasn't readable; I couldn't make any sense of it. Indented YAML style lists, though? The structure pops right out and the information I wanted was immediately obvious. There were no constraints here, I was free to render text in any way that suited me; the Lisp style syntax just wasn't helpful.

I don't think there's an equivalent to cddadr for example, but at that level of deconstruction you're better off abstracting the data structure (maybe a struct [2]) or using some other mechanism like match [3]

[1] http://docs.racket-lang.org/reference/pairs.html?q=second#%2...

[2] http://docs.racket-lang.org/reference/define-struct.html?q=s...

[3] http://docs.racket-lang.org/reference/match.html?q=match#%28...

In 5 characters with cadar you can express walking along a tree structure to get exactly the node you want.

However, Lisp as in Common Lisp most certainly has a good amount of syntax. And let's not forget macros which amount to user defined syntactic extensions.

Here are some examples of syntax built into the standard:

Lambda lists have varying syntax depending on context. http://www.lispworks.com/documentation/lw70/CLHS/Body/03_d.h...

Declarations have both standardized and implementation defined syntax for introducing information into the compile-time environment: http://www.lispworks.com/documentation/lw70/CLHS/Body/03_c.h...

Type specifiers introduce new syntax for both standardized and user-defined types: http://www.lispworks.com/documentation/lw70/CLHS/Body/04_bc....

Logical pathnames: http://www.lispworks.com/documentation/lw70/CLHS/Body/19_ca....

Feature expressions: http://www.lispworks.com/documentation/lw70/CLHS/Body/24_aba...

And of course, programmable reader macros which is how syntax for every single language primitive in the language is introduced: http://www.lispworks.com/documentation/lw70/CLHS/Body/02_d.h...

Here's an example of a complex standardized macro with its own domain specific syntax (loop): http://www.lispworks.com/documentation/lw70/CLHS/Body/06_a.h...

Let's not forget that most of what one might think of as built-in features in Common Lisp are actually standardized extensions to the language built with macros.

All of the power, expressivity, and extensibility of Common Lisp is what makes it my favorite programming language. It's what makes everything like above possible and gives power back to the user. But ignoring the syntactic complexity will not win us any followers!

TLDR: Common Lisp isn't simple, but it exposes one of the most powerful and empowering programming environments we have.

That's what I was talking about. The language, being programmable, especially with read macros, can be used to create a very syntactically full language, but at it's basic core level, there is really just '(', ')', '.' and symbols.

But I generate and validate that Ruby code with Common Lisp -- in other words, I write Lisp that writes correct, idiomatic Ruby.

I would be very surprised if I were the only person doing this.

Lisp is more like research language than implementation language for bean counting apps. Better question is what bleeding edge things have originated, are being done or have been done in Lisp.

John Carmak is doing VR research with Racket.

Christian Schafmeister doing molecular metaprogramming.

Raytheon implemented a signal processing analysis pipeline for missile defense in Lisp

Commercial Lisp vendors keep lists of some of their customers. Specialized Cad programs like Bentley PlantWise are not popular but they are very complex.

http://franz.com/success/

http://www.lispworks.com/success-stories/

http://maxima.sourceforge.net/

http://pgloader.io/

There's also cl-abnf from the same author and project which is another great example of the expressive power of common lisp.

Also, everything Fernando Boretti does is awesome ;)

https://github.com/eudoxia0 http://eudoxia.me/article/common-lisp-sotu-2015/ https://github.com/dimitri/cl-abnf

- https://github.com/asciinema/asciinema-player

- https://precursorapp.com/ (not open-source)

[1] http://www.clojure.org/

aka. Clojure (...) compiled to JavaScript

You stopped reading a few words too soon :)

The GP says "ClojureScript, a.k.a. Clojure ... compiled to Javascript, which (I believe) is accurate.

Edit: Urbit has a Lisp (http://urbit.org/)

https://gist.github.com/burtonsamograd/29103c2dfaa67f4fd344

The music on your home page reminds me a bit Utopia soundtrack (like the sound of the frog).

https://www.youtube.com/watch?v=_ZYVb8Q5i9w

    http://kruhft.bandcamp.com/album/listener

http://www.vpri.org/pdf/tr2011004_steps11.pdf

http://eudoxia.me/article/common-lisp-sotu-2015

I'd only call this anecdote, but one or more benchmarks assert that cl-ppcre, common lisp's perl-compatible regex implementation, is faster than any other, include perl's.

The larger question I'm intuiting from your post, "Why doesn't language power make a difference in practice?" I don't have an answer to.

Depends on your definition of "make a difference in practice". If you mean "make the language become one of the dominant ones", yeah, that doesn't seem to have happened. Either Lisp is less effective in the large than one would expect from its power, or it's less powerful in practice than people think, or power has almost no relation to language dominance.

But if you mean "make a difference to the user", well, it lets the user more easily write the program that the user wants to write. In practice, that makes a difference - to that user.

https://github.com/ynniv/opengenera

http://ronleigh.com/autolisp/ahistory.htm

That question would be: what programs are written in <LANGUAGE> that couldn't benefit from being rewritten in another language?

And most often, the answer to that question is none.

Because languages matter a lot less than language fanatics want you to think.

As for Lisp, I used to be a total fan until I realize the importance of a sound static type system, and now I will never go back. Lisp will never go anywhere because this is the 21st century and we know now that static type systems are an absolute requirement for modern programming.

I am not saying that you are wrong in liking static typing, but arguing that dynamically typed languages are non-starters in this decade is a statement that is easily disproven by the existence of Javascript.