
Lisp is Abstract Syntax - mrbbk
http://michaelrbernste.in/2014/04/16/lisp-is-abstract-syntax.html
======
GeneralMayhem
I have yet to hear a good explanation why homoiconicity is a good thing or in
any way easier to learn. My main problem is that you have to know all the same
things, but they become unknown unknowns. Not being able to tell at a glance
that the argument list in a lambda expression, as one of the most common
examples, is doing something other than execute code is very confusing if
you're expecting everything to follow the (func arg1 arg2) pattern. On the
other hand, when you encounter different syntax, it's immediately obvious that
you need to know something else - a known unknown, which is easier to correct.

~~~
lispm
Not everything is follwing a (func arg1 arg2) pattern.

For example a LET binding is following a (LET ((var1 binding1) (var2
binding2)) body) pattern.

~~~
hga
Or in Clojure, I'm starting to accept that this common pattern is a good
thing:

    
    
      (let [var1 binding1
            var2 binding2]
         body)

------
joe_the_user
_The abstract syntax was intended to be used writing programs until designers
could get around to creating a concrete syntax with human-readable punctuation
(instead of Lots of Irritating Silly Parentheses), but programmers soon got
used to programming directly in abstract syntax._

That's _some_ programmers who got used to the syntax. It may be absolutely
true that once you get used to LISP's syntax, it is better than any other. The
problem is that since one is dealing with human beings, and with human beings
you have the power of first impression and the tendency to make snap decisions
based on these, people initial difficulty in grokking LISP's syntax is always
going to be a hurdle for the language.

~~~
Crito
Is grokking Lisp's parenthesized s-expressions actually difficult though? I
think that the real problem is that developers _believe_ that they will find
it difficult before they try it, rather than _actually_ finding it difficult
when they eventually do try it. I don't think I've ever picked up another
class of languages faster; even python took more effort from me.

Basically, I think it's a marketing problem.

~~~
nilliams
I have to respectfully disagree. I have coded for years in a lot of C-style
languages, mainly C, Java, Python, Ruby & JavaScript and I've been struggling
with the Clojure book (and various tutorials) for over a year. It's not just
marketing, it's a very different mindset and one I'm not convinced is ever
going to appeal to a large class of smart programmers (yes I guess I'm saying
I don't think I'm dumb and hope I'm not alone in this feeling).

I've heard Lisp described as an autistic language, and I think there's
something to that. I don't think it's for everyone. I'm not on board that
macros, homoiconicity and some of the other stated benefits of lisps are worth
'giving up syntax' for and I am far from convinced that lisps are the future
of programming.

I'm a huge fan of Rich Hickey and I want to love Clojure, I just can't. It's
not for me and it's not a marketing thing. Rich is the best marketing a
language could hope for.

~~~
brudgers
I'm a fan of Rich Hickey, too. And I think Clojure is a solid language. But I
wouldn't suggest Clojure as the entry point when seeking a overall
understanding of Lisp. There's too much baggage and history swirling around it
for explanations ever to be comfortable - e.g. even if Rich Hickey always
makes convincing arguments, it's important to note that they are always
arguments.

That is there always seems to be at least as much of a subtext of Clojure
defining itself by what it isn't as an explicit statement of what Clojure is.
So much of what is said about it is said in the context of "Clojure is not
Java, or Haskell, or Scala, or Scheme, or Common Lisp" and because that is so
much a part of its culture, it has details drawn from 'the best parts' of each
and mashed up.

Like Common Lisp, it is a language for working programmers and will trade
practical accretion over striving for internal conceptual consistency. Unlike
Common Lisp or Scheme, it doesn't have the sort of simple core that lends
itself to tutorials from first principles and even if it did, the community
tends to be experienced where just jumping into the middle is more the norm.

That's nothing against Clojure. It's just that any sort of gentle introduction
to Lisp is probably better sought in those places where it already exists -
_SICP_ or the Racket ecosystem or _Practical Common Lisp_ or PG's _On Lisp_
are probably better introductions to what makes Lisp different. Clojure is
probably a better second Lisp dialect for many people once they are ready for
full tilt production code.

~~~
minikomi
In learning Clojure first then Racket, it struck me how many good ideas came
from racket.. and now how many are still being mined - typed racket being the
obvious one.

~~~
lispm
I don't know how much Rich Hickey used Racket, but he used Common Lisp for
several years and wrote some complex libaries for it. There is also a sketch
of Clojure early on written in Common Lisp.

~~~
hga
Racket started out as a Scheme, and Clojure has mined quite a bit from Scheme.
Both are Lisp-1s, loop/recur, not accepting a lot of mainline LISP (e.g.
Common Lisp nowadays) baggage, etc.

~~~
lispm
Actually there is not much Clojure got from Scheme. Lisp 1 is not tied to
Scheme. loop/recur is much less powerful than Scheme's TCO.

~~~
hga
Lisp-1 is pretty firmly tied in most people's minds to Scheme: at the very
least the paper that coined the terms
([http://www.nhplace.com/kent/Papers/Technical-
Issues.html](http://www.nhplace.com/kent/Papers/Technical-Issues.html))
ascribed it to Scheme, and as far as I know it first came from Scheme
(although it's so easy to create a low performance Lisp I wouldn't be
surprised if that had been tried before).

loop/recur is of course much less powerful than TCO, because the JVM doesn't
natively support it (it's not trivial, security wise). There are three other
Lisps on the JVM that I know of: SISC Scheme is mostly dead but does TCO at a
cost in speed, Kawa Scheme has as of late added fine grain control over TCO,
and Armed Bear Common Lisp doesn't try, as Common Lisps are not required to.

But loop/recur sure looks to be ultimately inspired by Scheme style use of
TCO; I just did a set of functions using it for the first time and everything
I learned from SICP/6.001 applied and made that part of it trivial.

~~~
lispm
Haskell also has only one namespace. I propose that Clojure took it from
there, including persistent data structures, lazy data structures, ...

> But loop/recur sure looks to be ultimately inspired by Scheme style use of
> TCO;

To me it looks more like ancient Lisp with prog and goto.

    
    
        (defun foo ()
          (prog ((a 1))
            start
            (print a)
            (when (< a 10)
              (incf a)
              (go start))))
    

Old Lisp code is full of that. It's basically what LOOP/RECUR provides.

------
lcedp
_The abstract syntax was intended to be used writing programs until designers
could get around to creating a concrete syntax with human-readable punctuation
(instead of Lots of Irritating Silly Parentheses), but programmers soon got
used to programming directly in abstract syntax._

Perhaps it was, but..

1) The nature of research is so that you can't always predict in which way
your invention will be useful. To me and many others it seems lisp syntax is
quite handy.

2) If we take Clojure for the sake of example, we'd see that it comes with
some neat macros which are important part of the language. Those can be viewed
as mentioned concrete syntax elements built upon the abstract syntax.
Punctuation's been improved as well.

------
PaulHoule
Well, yeah.

I think the popularity of lisp comes down to the hostility the mit ai lab had
towards noam chomsky who in the 1960s spoke out about the vietnam war and thus
bit the hand that funds cs research.

All other computer languages (except for forth) embraced formal grammar
concepts but mit rejected them out of spite.

If mit had stopped burning the dragon book and embraced algol syntax we might
have been spared the horrors of c, c++ and java but no, they just gave us 1
more reason rt 128 is a boulevard ofbroken dreams.

~~~
ScottBurson
Huh. I was around the AI Lab in the late 1970s -- as an undergrad -- and I
don't recall hearing anyone talk about Chomsky in the way you imagine. DARPA
funding was still flowing rather freely, it seemed to me, well into the
mid-1980s. I don't recall anyone suggesting that there would have been yet
more DoD money if it hadn't been for Chomsky. And the grad student I did some
work for, who was working on natural language parsing, was clearly intimately
familiar with Chomsky's ideas on transformational grammar and referred to them
throughout his dissertation.

So this isn't ringing true for me.

I also recall Gerry Sussman speaking quite highly of Algol 60.

No, I think you're quite wrong: the reasons for the popularity of Lisp at the
AI Lab have to do with its actual advantages over other languages for the
kinds of problems they were working on.

And there is an example of a language in the MIT tradition with infix syntax:
Dylan. Great language, but wasn't in the right place at the right time to
catch on.

~~~
hga
Was Sussman talking about the syntax, or things like lexical scope, which he
and Steele introduced to the LISP world with Scheme in the mid-70s?

About the only relevant negative thing I remember being said about Chomsky in
a period just after your's was Marvin Minsky saying he saved someone from
going down a rabbit hole following Chomsky's work. But that was a judgement of
merit of his linguistics work, not his politics.

~~~
ScottBurson
Well, the lexical scope, certainly, but I don't recall him disparaging the
syntax.

I don't recall any burning of Dragon Books. Nor was Vaughan Pratt tarred and
feathered for releasing CGOL, which allowed one to write Lisp in infix syntax.
People were aware of it, and a few people used it, but it didn't catch on in a
big way. I don't think this was for ideological reasons; I think it was simply
that most people writing Lisp (myself included) found that _with proper editor
support_ , editing fully parenthesized code is easy and pleasant -- _more so_
, in many cases, than editing infix code. That is the fact that many non-
Lispers cannot believe could possibly be true. And yet over and over again,
people who learn Lisp report that it is.

------
hajile
The biggest proof of the overwhelming preference for parens can be found in
the dylan programming language. Despite having M-expression syntax (in fact,
the original spec was prefix lisp), the same CLOS object system, and even a
macro system, the language has gone nowhere with lispers. More interesting is
that dylan was also unpopular with ALGOL programmers. The existence of "sweet
expressions" (M-expressions) allowing infix syntax in existing lisp languages
further removes this as the main issue.

The worst answer as to why people hate lisp is the "too many parenthesis"
argument. C-style programmers are just as happy to mash 5-6 paren/curly-brace
sets together in one line. The only major difference is location. For example,
(if test (<result>) (<alternate>)) vs if(test){<result>}else{<alternate>}. In
addition, the only reason the closing parens are on a separate line in C and
the same line in lisp is convention.

I suspect the biggest barrier to ANY language is having a non-C syntax style
rather than infix vs prefix or parenthesis. The inertia is simply too great.

------
cjo
What I think this is missing which was a huge part of the SICP course is that
Lisp is probably the best language to write your own language in with a custom
syntax tailored for the problem space you're working on. Even if it isn't
trivial to do.

An example is Clojure's Hiccup[0] where there's a whole new syntax for dynamic
HTML generation. It's not a full new Turing-complete language, but it's a
custom syntax and vocabulary that illustrates Lisp's extensibility (a sample
of Hiccup in action is linked below, though it isn't mine.)

[0] - [https://github.com/yokolet/hiccup-
samples/blob/master/src/hi...](https://github.com/yokolet/hiccup-
samples/blob/master/src/hiccup_templating/views/contents.clj)

~~~
millstone
When I look at that sample, what strikes me is how much the "custom syntax"
still looks like a bunch of S-expressions.

How much flexibility does LISP really give you here? For example, say I wanted
my DSL to use Python-style significant whitespace instead of brackets. Does
LISP make that easy, or is my DSL restricted to using stuff that looks like
S-expressions?

~~~
Crito
Racket is somewhat unique in this respect, but it allows you to create
dramatically different languages as DSLs.

Consider this example of the experimental "2d" syntax:

    
    
      #lang unstable/2d racket
      (require unstable/2d/cond)
     
      (define (same? a b)
        #2dcond
        ╔═════════════╦═══════════════════════╦═════════════╗
        ║             ║       (pair? a)       ║ (number? a) ║
        ╠═════════════╬═══════════════════════╬═════════════╣
        ║ (pair? b)   ║ (and (same? (car a)   ║     #f      ║
        ║             ║             (car b))  ║             ║
        ║             ║      (same? (cdr a)   ║             ║
        ║             ║             (cdr b))) ║             ║
        ╠═════════════╬═══════════════════════╬═════════════╣
        ║ (number? b) ║          #f           ║   (= a b)   ║
        ╚═════════════╩═══════════════════════╩═════════════╝)
    

Yes, that big ascii-art graph is actually part of the code, not some sort of
comment. The 2d syntax allows you to create ascii art truth tables which
contain in them code (in this case, in the traditional paren'd style.)

 _(See[http://docs.racket-lang.org/unstable/2d.html](http://docs.racket-
lang.org/unstable/2d.html) for a better explanation and more examples.)_

Alternatively, here is an example of typed racket using sweet expressions:

    
    
      #lang sweet-exp typed/racket
    
      define: fact([n : Integer]) : Integer
        if zero?(n)
           1
           {n * fact{n - 1}}
    

_([https://github.com/takikawa/sweet-
racket)*](https://github.com/takikawa/sweet-racket\)*)

------
tluyben2
What most people have with Lisp syntax, I have with Objective-c. I am mostly
blind to syntax (I skip from language to language fast reading/writing) except
for some esoteric languages (like
[http://www.hakank.org/k/](http://www.hakank.org/k/)) AND Objective-c. I find
it extremely annoying to read while I do it every day. Writing is better for
some reason, but far removed from other languages. So I see why some people
would not like Lisp syntax while I find it very pleasant/enjoyable to read.

------
endlessvoid94
"preventing advancement" is a pretty bold assumption.

