Hacker News new | past | comments | ask | show | jobs | submit login

After spending about a year toying with LISPs I find lisp prefix notation much more readable, intuitive and useful.

Think about adding a bunch of numbers using infix

a+b+c+d

In prefix it’d look like

(+ a b c d)

You could as many terms in that list.

And as far as the - in indentifiers, it’s called kebab case and I find it very readable and natural to type as well. Also since identifiers are a lot more flexible than other languages you could have predicates such as empty? Rather than isEmpty and so on. Very very friendly and useful. Not trying to convince you or anything but if you give it a chance it’ll click for you.




Well, I can understand (+ a b c d)

Its the next level where it gets hard.


What is that, macros? Hygienic macros? Higher order functions? Recursion? I find that having such a simple syntax everything is grokkable much easier than in other languages. Having said that, I prefer scheme and racket which are much more simplified than common lisp and don’t contain so many warts.


To someone who isn't immersed in the Lisp world, Lisp syntax often looks ((((something (like) this) and) seems)) utterly impenetrable compared to a more 'conventional' syntax. It's the reason for the snarky backronym, Lost In a Sea of Parentheses.

Forth, another language with a spartan approach to syntax, gets similar criticism.


What you're looking at though in lisp is an unambiguous syntax tree.

It's what helps you find your way around in the forest, especially with editor support that can automagically apply operations to discrete chunks of your code.

That can include doing things like re-defining a function or value on the fly, which is one of the lovely things you can do in many lisps.


> What you're looking at though in lisp is an unambiguous syntax tree.

...

> That can include doing things like re-defining a function or value on the fly, which is one of the lovely things you can do in many lisps.

Sure, but like I said to lispm, I know enough Lisp to understand both of these points. Respectfully, neither addresses my point about syntax.


Kind of like saying C often(looks{something{like->this;}});


Overly dense C can be cryptic, sure, but Lisp relies heavily on parentheses. At least in C and C++, there are several types of brackets at work (parentheses, square brackets, braces, and in C++, angle brackets and even double square brackets [0]). This helps the eye get a grasp of things.

At least, things seem that way to me, as someone who knows C and C++ reasonably well but has only dabbled in Lisp.

[0] https://en.cppreference.com/w/cpp/language/attributes


Well that is kind of the point -- you know C and C++ reasonably well and are comfortable with the syntax, so of course you think it is easy to read. If you were as familiar with Lisp you would not find it hard to read either (I should know, since I am comfortable with both C++ and Common Lisp).

That said, if you want a real C++ readability challenge, here you go:

  int add_one(int x) { return x+1; }
Easy-to-miss undefined behavior is a much greater readability problem than the specific syntax of a language in my opinion.


I agree that UB is a serious issue in languages like C and C++.

I thought you were going in another direction with that example, the Most Vexing Parse. https://en.wikipedia.org/wiki/Most_vexing_parse


Lisp always uses prefix operator symbols. something like { ... } would be (progn ...) . Thus when one reads Lisp, one doesn't look that much for character syntax, but for operator names and list structure layout.

Parentheses are there, because s-expression syntax is not only used for syntax for nested lists, but also for representing code as s-expressions. C / C++ does not have that feature.

These s-expressions in Lisp are data. This means one can also write programs which create programs as data - not as text, but as list structures.


> when one reads Lisp, one doesn't look that much for character syntax, but for operator names and list structure layout.

Right, but this boils down to just getting used to Lisp.

> also for representing code as s-expressions. C / C++ does not have that feature.

Sure, I know enough Lisp to understand that, but the point about syntax stands.

Ultimately I think it's just a matter of acclimatisation. C++, Lisp, and Forth, are different enough that if you only know one or two of the languages, you'll likely find the third to be an unreadable mess.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: