Hacker News Reader

Comment by jesstaa | Hacker News Reader

It's as if lisp was originally designed to be an intermediate language for computer generated parse trees....and not a language for people to read.

View on HN

If you say "S-expressions" instead of "LISP", this is perfectly true! The syntax of S-expressions was only meant to be used for LISP data structures, while programming was meant to happen in another syntax called "M-expressions" [1], which was to be converted to S-expressions by the compiler. However, the programmers liked to use S-expressions directly, so M-expressions were never actually implemented.

In that sense, the LISP syntax (S-expressions) were ideed designed as an intermediate language, not to be used by programmers directly (except for plain data structures).

[1] https://en.wikipedia.org/wiki/M-expression

This is really interesting - I didn't know about that snippet of Lisp history. So the expression we'd write today as

  (car
    (append
      '(a b c)
      '(d e f)))

Would originally have been written in M-expression form as

  car[append[(a b c); (d e f)]]

Programming in Lisp might be a very different experience if M-expressions had caught on!

It would be called programming in Mathematica ;)

It's not as if..it is truly the case. That's why only nutters use LISP for large projects. Who really wants to wrap every S-Expression in parenthesis? Talk about painstaking and what an eye-sore. If only M-Expressions caught on, LISP could be decent. But really, it's just making you write your program as a data structure because that makes it easier for the compiler to process.

So...

Ruby: good for developers, bad for the JIT compiler (slow)

LISP: awful for developers, good for the compiler -> machine (fast)

Is the tradeoff worth it? Not at all. Most LISP intros start by convincing you that you'll eventually get used to your code looking like a sack of parenthesis. No thanks, I shouldn't need to get used to staring at overburdened verbosity for the compilers' sake - build something better. Wait..we have other languages that are fast and look nice. And many even process into a well-formed AST. Okay, thank heavens.

yeah, the trade off are generally c-based languages.

I disagree that Lisp is awful for developers. To me and many others it looks quite pleasant while the "other languages that look nice" actually look like a needless mess of braces, brackets, asterisks, comma's, etc. etc.

Only Python comes close IMHO but has many other downsides.

Brackets, asterisks, and commas give array indexing, pointers, and the clean separation of function arguments.

(incf (elt vector 2)) ..versus.. ++vector[2]

which one is more readable?

LISP is not to be taken seriously. It's an academic curiosity, and cute, novel, not a language that needs continued zealots. It has no market share..the reasons are always going to be the same. The language is esoteric. I wouldn't program anything serious in JSON so why would I use LISP, where every semantic is a list..not even a hashmap.

http://imgs.xkcd.com/comics/lisp_cycles.png

"These are your fathers' parenthesis"

>(incf (elt vector 2)) ..versus.. ++vector[2]

One reason I like Lisp is that I don't have to think about operator precedence.

Math expression: a(8b^2+1)+4bc(4b^2+1)

In LISP: (+ (* a (1+ (* 8 b b))) (* 4 b c (1+ (* 4 b b))))

Oh, that silly operator precedence, lets just jam our heads in a vice while we unravel the nesting.

I'm really not going to participate in a cherry picking contest on PL syntax and while my experience has show that Lisp is not for everyone, I'm quite surprised at the hostility shown towards it by you and other people on this page.

I'm not quite sure whether it is just plain trolling or traumatic experiences with Lisp at college. (The latter which I can understand since being allowed to only use a very limited part of the language to solve convoluted problems can be quite off-putting.)

> you write your program as a data structure because that makes it easier for the compiler to process.

It also makes it easier for YOU to process/manipulate your program with the expressive power and safety of the full language.

http://en.wikipedia.org/wiki/Homoiconic#Uses.2C_advantages.2...

That's definitely a good feature. Other languages have run-time reflection, compile-time macros, mixins, and polymorphism.

LISP is great for live audio production because of the homoiconicity. It's very suited for dynamic interactive programming, namely Emacs. I believe that's where the zealousness needs to stop. It's not a good language to code large projects in.

LISP: awful for developers, good for the compiler -> machine (fast)

It's pretty funny that the knee-jerk dismissals of Lisp today are the precise opposite of what they used to be.

Knee-jerk? There's nothing pretty about having every single semantic of your language need to wrap. That's called, syntax hell. And it's useful for when you want to refer the AST self-referentially, like in live editors, ie. emacs & overtone (music production.) Otherwise, it's water trash. Maybe it was cool in the 80s when the only other kid on the block was Fortran or QBasic - but we have better languages now, so we don't need to write our program as a big nested list..we can make it easier for ourselves, and we can be way more productive..well unless..we're some old dude from the 80s..that's stuck on the LISP bandwagon. tears

o.O

Damn straight, I went there. And got no replies. Because there's really no good reasons to defend LISP's horrible syntax in non-live programming use-cases.

Strongly disagree.

Reply on news.ycombinator.com