Hacker News Reader

S-expressions are more readable than C-syntax to me. Readability is about familiarity.

The task of comparing English with Russian in terms of readability is not a clear task at all and it's hard to determine how such a judgement would be made.

I would argue that it's just as hard to genuinely judge the readability of S-expr vs. C-syntax.

People whose first language is in Russian obviously find the Cyrillic alphabet to be more readable and wonder why anyone would use anything else. To me Russian looks like scribbling.

Familiarity is probably the prime factor in readability. And it is indeed a subjective one.

But there are also objective factors.

Infix function application allows for easier visual parsing of the expression tree's components. There's a reason mathematicians have been using infix notation for centuries before we had arbitrary other constraints for choosing notation.

In fact, if you look at mathematicians' notation, you will see that not only is it horizontally infix (arguments left and right of the function), it is also vertically infix, and arguments are placed above and below (Sigma, Integrals, etc.).

People have come up with many rationalizations, but really, anything that doesn't have a mostly C/Java-style syntax just pisses off the majority of programmers.

When you look at languages that actually, consistently use infix and mathematical notation (http://nsl.com/k/ray/rayq.k), they seem to give most programmers fits.

Infix also only really works for unary and binary operators, of course.

since 99.9% of every language is in prefix notation i cant buy this.

when mathematicians type f(x,y) they are using prefix notations.

likewise when programmers type run(x, y);

Anecdotally, most advanced mathematicians prefer Lisp because it is more conducive to a mathematical way of thinking. I am a very mathematical programmer and I prefer lisp specifically because I don't have to deal with operator precedence. Everytime you use infix notation you introduce a bunch of unnecessary complexity and often you complicate the ability to use simple recursion.

Gregory Chaitin, eminent mathematician, writes his proofs in Lisp for a reason.

Is it truly easier to write

   print(a + " " + b + " " + c + " ");

rather than

   (print a " " b " " c " ")

?

I greatly prefer the latter. The first one is weighed down with unnecessary special cases, unnecessary complexity.

The benefits of Polish notation are apparent with math as well. You don't need to reformulate the entire calculation and figure out messy operator precedence rules when you want to add a term. I think RPN lends itself to bug free code and easy modifiability.

To each his own I suppose. C-syntax to me is completely nonsensical and I don't see what problem it is meant to solve. I'm sure Russians view the Latin alphabet in the same way though.

Mathematicians have few prefix functions. Most functions are infix and many in more than one dimension.

I think a statement like "Most advanced mathematicians prefer Lisp" is pretty extraordinary and demands extraordinary citations.

Your comparison was dishonest, as you compared manual concat and print with a function that concats and prints. You really meant to compare full infix (e.g: in Haskell):

    print $ a ++ " " ++ b ++ " " ++ c ++ " "

with full prefix:

    (print (++ a (++ " " (++ b (++ " " (++ c " "))))))

Which do you find more readable?

The anti-precedence notion behind putting () around each application requires parenthesis even when associativity laws show that there is absolutely no difference between difference precedence interpretations. In this sense, the () are pure noise in this example.

Of course, if you use ++ so many times, you'd prefer to just use (in Haskell) something like:

    print . intersperse " " $ [a, b, c]

Lisp's print has to embed the concatenation of its arguments or else it would look as horrible as shown above. It is still disingenuous to compare it as equal.

One consequence of the parenthesis and prefix notation is that n-ary operators are idiomatic in lisps. So, the above example would more likely be written:

(print (++ a " " b " " c " "))

For flat expressions, prefix is fine, and using n-ary operators is a great way to flatten many trees. n-ary operators cannot flatten every tree, though. When your tree isn't flat, and is built from primarily binary operators, infix makes the tree structure more apparent. The way we would draw trees on paper is how it would appear in the infix expression.

I think that you're the only person in this thread who openly questions the cheer-leading of Lisp. I respect that. For that, I gave you an upvote. Heretic.

Sure, the pile of Lisp macros that recapitulates most of Haskell would be gnarly and nasty. But would that be due to the intrinsic bogosity of doing it through macros, or would it be due to it coming from a lone hacker who's following the scratch-an-itch school of design?

Code is a human readable format (even if you force it to be S-expressions and pretend it isn't). Here's something for which there's no accounting, as the Romans used to say. Plenty of smart people love S-expressions. Plenty of smart people can't stand them. John McCarthy thought that S-expressions would go away, but no one got around to that in more than half a century. Someone must find them readable.

Code shouldn't be generating other code, it should be generating more structured values. You must know more than me. Something more structured than code?

I think the reason that S-expressions haven't gone away is mostly because of the way they mesh with macros, but anyway the sub-optimality of S-expressions as a syntax wasn't a part of my argument there (I don't like them, but I don't hate them). In that quote, I meant there that all code, even S-expressions, is a human readable expression that defines the thing you're interested in.

Note that it's considered poor form in Lisp to make a square macro that multiplies its parameter by itself. That should be a function. Why? Because numbers have the structure you want them to have. A function that takes a number and multiplies it by itself is just simpler than a function that takes an expression for a number, and pastes it together with an astericks and then returns that to be evaluated. And because the function has a better structure than a macro, it's more composable.

The thing is that this same situation exists with most other uses of macros. In a language with staged computation and maybe a little well tamed syntax extension, I think there would be no place for macros. You can do better.

I really like what they are doing in Nemerle 2. http://code.google.com/p/nemerle-2/ (Not associated in any way)

"Sure, the pile of Lisp macros that recapitulates most of Haskell would be gnarly and nasty."

I don't think you can macro your way to Haskell. Haskell wants a guarantee that if some function takes a function of type Int -> Int, the passed-in function will absolutely positively not do anything in the universe except take an int and return an int, and if that isn't true and that closure can do something else, Haskell breaks. Even if you can macro your way towards restricting arbitrary closures like that, you don't have Lisp anymore; you've got Haskell. Or you don't have Haskell and you do have Lisp. The two are fundamentally opposed at a deep philosophical level.

Moreover, how does the performance of Qi compare to Haskell?

> Code shouldn't be generating other code, it should be generating more structured values.

How is code not a structured value? Do you mean that instead of some properly typed AST you only have lists, symbols etc?