(Lots of ((Irritating, Spurious) (Parentheses))) | Hacker News Reader

(Lots of ((Irritating, Spurious) (Parentheses)))

fare.livejournal.com

17 pointsgnosis15 comments

This is a long article that can be completely summed up by the headline (it's a rant about people who criticize Lisp's syntax).

Why are people still talking about this?

It's like complaining that a Lamborghini sucks because the cupholders are hard to reach. I'm sure it would bother some people, but it's not really worth discussing, is it?

Note that the article is from 2005. Also comparing a lamborghini cup holder with syntax of a programming language doesn't make sense at all. The syntax of a language is something you look at and work with for maybe 8 hours a day and is the key part in communicating the language with the compiler and your coworkers.

The reason I, and I guess many other people don't like the lisp syntax is pure taste and psychological. I don't really care about a list of technical arguments why it is good. I don't like reading or writing the syntax lisp is written in and that will not change. That has nothing to do with being openminded or possible technical superiority over C style syntax. Writing and reading source code is far more enjoyable using other syntaxes solving the exact same problems so why should I bother with lisp?

PS: Who on earth would drink coffee in his fancy lamborginhi :D

It's actually more like saying a Lamborghini sucks because the steering wheel is square. It's a very basic feature of the language, and not one that you can avoid using.

> Why are people still talking about this?

The post is from 2005 ;-).

I know this is probably said pretty often, but there's nothing stopping you from creating a new syntax for Lisp so long as it can easily be translated into the abstract form of S-Expression. That's what M-Expressions (http://en.wikipedia.org/wiki/M-expression) tried to do.

Somebody tries making an alternate syntax every few years. Usually, it's an experienced Lisper who wants to increase the popularity of Lisp. These never catch on, and never will.

I think there are two problems. First, people who are prone to "get" Lisp are open-minded enough not to be put off by the syntax. People who can't get past the syntax won't grasp the other advantages.

Second, homoiconicity is Lisp's last remaining real advantage[0] over other dynamic languages. Most Lisps are faster than Python or Ruby, but not Lua, especially LuaJIT. An alternate syntax makes that advantage harder to access.

[0] I'm pretty sure CLOS and the condition system could be replicated in Lua, though I'm not sure anybody has.

> These never catch on, and never will.

Though I'm no great fan of Mr. Wolfram, I would have to say Mathematica has caught on quite well. Mathematica isn't a Lisp (its semantics are based on term rewriting) but it freely intermixes S-expressions and M-expressions. For example, the M-expression a + b parses into the S-expression Plus[a, b].

Most languages parse in to a parse tree that looks something like S-expressions, but that parse tree isn't always made of the language's own data structures nor available to the user at runtime.

Of course. Why is that remark relevant here? Mathematica does make its S-expressions available to the user at runtime. They are in fact much more available to the user at runtime than in Lisp because of Mathematica's term rewriting semantics. Furthermore, the transformation from M-expressions into S-expressions isn't a one-way street. By default the notebook interface will render an S-expression as its M-expression equivalent when such exists.

I'm pretty sure CLOS and the condition system could be replicated in Lua, though I'm not sure anybody has

re: CLOS - There have at least been two projects to replicate Perl's Moose (http://moose.perl.org) in Lua:

* http://lua-coat.luaforge.net/

* http://code.google.com/p/loose/

> These never catch on, and never will.

Another possible counterexample is Logo, though perhaps you didn't mean "Lispy languages with fewer parentheses will never catch on," but "Front-ends for Common Lisp that use fewer parentheses will never catch on." I can't speak to the latter.

The folks who make Racket have also implemented a variety of non-Lisp languages (e.g., Scribble, Algol[1]) that I believe are parsed to s-expressions and then compiled by Racket. Not sure how many people use these implementations for "serious" programming, but they're there.

[1] http://docs.racket-lang.org/algol60/index.html

I don't mean to imply that Lispy languages with non-sexp syntax won't catch on. Python, Ruby and Lua seem to have pretty Lispy semantics, for example. I also do not mean to imply that DSLs or implementations of existing language standards that compile to sexps and get passed to a Lisp runtime to execute won't catch on. I believe Maxima is such a DSL.

What I do mean is that a general-purpose replacement syntax for existing Lisps that isn't mainly written in terms of data structure literals won't catch on. Note that I didn't say lists there; Clojure has added vectors and maps to its syntax, but retains a very Lispy overall syntax.

I'm not sure if a new language explicitly designed to be a Lisp in everything but front-end syntax will catch on. New languages usually catch on when they present a good solution to a problem lots of people have on a silver platter. They're a lot like startups in that regard.

In fact M-exp where intended for Lisp code before S-exp (which were originally meant to represent data only). IIRC, the story is data S-exp were used for code temporarily because it was easier this way, and then they find it usable enough.

var tldr = "Lots of irritating, spurious text from a Lisp advocate";

Reply on news.ycombinator.com