
The Nature of Lisp (2006) - peterkelly
http://www.defmacro.org/ramblings/lisp.html
======
kruhft
"Why on Earth would anyone want to use a language with such horrific syntax?!"

What is it with statements like this? It just sounds like a 'meme' to me, that
everyone hears (even from advocates like this one) at first that the 'syntax'
(of which there is a lot less than most languages in a Lisp) is 'horrible'?

Of course, we, the learn-ed of Lisp, say that after a while the 'parens just
disappear', which they don't, but they sure help (when combined with Paredit)
in defining code like structures that can be manipulated with ease in your
editor.

I know the author is just trying to do a bit of a 'sandwich' with the article,
but please, advocates and enemies of Lisp, just give up on picking on the
parens. It's stupid and been done a million times. It's like 'why do we have
to type so much to enter programs! such a pain!'.

Boring.

~~~
ajkjk
I don't really mind the parens, but the whole attitude feels indicative of a
problem. Like - it's 2018 and people are still using 'cdr' and 'cons' as
terminology and happily expecting other people to learn those words and not
even feeling bad about it.

If the person justifying Lisp doesn't mind that the word 'cons' is terrible,
why should I trust their aesthetic sense about anything? If I have to have
"miserable notations" to get "coding nirvana", and coding nirvana is so great,
why not fix the notations? do you just think everyone should have to struggle
because you did?

I guess it feels like trying to determine which of these statements are true:
(1) "Lisp is coding nirvana" (2) "Lisp is weird regressive nostalgia for a
simpler era where nothing was typed and everyone used Emacs and memorized
arcane terminology and shared macros on Usenet", and there are way too many
signs that it's a lot of (2).

[edited to be less abrasive]

~~~
felideon
> Like - it's 2018 and people are still using 'cdr' and 'cons' as terminology
> and happily expecting other people to learn those words and not even feeling
> bad about it.

Oh please, cry me a river. Like monads, promises, or props are any better.

> If the person justifying Lisp doesn't mind that the word 'cons' is terrible,
> why should I trust their aesthetic sense about anything? If I have to have
> "miserable notations" to get "coding nirvana", and coding nirvana is so
> great, why not fix the notations? do you just think everyone should have to
> struggle because you did?

Your ignorance is baffling. The notation is a feature, not a bug. If you want
the feature, then yes, you will have to struggle.

While cons and cdr as concepts are necessary to learning what goes underneath
the hood, idiomatic lisp is rarely written in terms of cons and cdr.

~~~
ajkjk
I know that. My point is that the antiquated terminology's survival seems to
be a symptom of a culture that values the wrong things: like pointless
historical names instead of clear modernized ones.

(Monads and props are definitely not better. You won't find me defending them!
'Promise' is a much better name, though.)

~~~
lispm
FIRST and REST as names for list operations have been added 40 years ago.
Pattern destructuring and list templates are as old.

Naming is important, but the core Lisp names can be learned in a day.

~~~
ajkjk
Yes, and yet the names Cons and Cdr still exist and come up in introductory
documentation and are still used in discussions constantly -- why?

~~~
outworlder
Because people like bikeshedding. Cons is a little bit weird, but it is par
with C's "typedef", it could have been named better.

car and cdr are weirder, but there are reasons people use them over first and
rest: 1- they are shorter and 2- they can be combined (caadr, cadr, cddr,
instead for (first (rest x)) etc).

It is still bikeshedding. You learn that stuff in less time than what it takes
to create an angry post.

And if you really hate them, you don't have to use them. Just define a macro
and you can stop complaining. Your coworkers may not like this though.

------
posterboy
(It (is :wonder (we can (read :text without (as much :brackets as) LISP)))).
Well, "as _ as" is technically bracketing, but you get the idea.

So I tried once to use a dot as list terminator, which didn't work well. I
found myself adding different terminators for each level of depth. Because, at
some point the encapsulation over multiple levels leads to ambiguity, if
outfix notation isn't used (as for the encapsulation in this sentence). A
common wisdom is to avoid deep indentation. 3rd normal form schemes are enough
for most cases, thank Codd.

By the way: I've been hugely interested in historical linguistics recently and
came to conclude counting must have been a huge boost for the development of
language facility. Basic phrases are just enumerations. Which reminded me of
list processing. Many old languages actually tend to follow VSO word order,
too. Plural is often enough expressed as reduplication. But I don't have
deeper insights to offer from this on how to avoid the parens, except that
zeroth order logic is fundamental and a linguistic approach to programming
languages might prove fruitful (grammar, not syntax). And by the by the way:
Isn't "everything is an object" similar in power to homoiconicity?

~~~
dropit_sphere
>And by the by the way: Isn't "everything is an object" similar in power to
homoiconicity?

This is the only part of your (very interesting) comment I feel qualified to
talk about.

I think there may be something there, but you'd have to be extreme about it,
making methods into objects, and proabably even keywords like "if." This is a
high bar---but macros clear it.

------
nathell
Previous discussions:

[https://news.ycombinator.com/item?id=4765067](https://news.ycombinator.com/item?id=4765067)

[https://news.ycombinator.com/item?id=9575786](https://news.ycombinator.com/item?id=9575786)

[https://news.ycombinator.com/item?id=1319034](https://news.ycombinator.com/item?id=1319034)

~~~
FPGAhacker
In case you or anyone reading this were unaware, there is a link underneath
stories called "past," which provides the service nathell did in parent.

~~~
stingraycharles
Huh I never knew that. Have I been completely oblivious of it, or has that
been added recently ?

------
AdieuToLogic
LISP is great, but the problem with making programs in it is that one
invariably ends up trying to answer the meaning of life, the universe, and
everything.

    
    
      (just kidding
        (sardonicly?
          (isn't it obvious?
            (depends on how one writes it
              (like with what editor?
                (we all know there is only one editor
                  (emacs?
                    (Stallman's own
                      (not to imply ownership
                        (as editors should be free
                          (along with all software
                            (like knowledge
                              (which are just ideas with proven value
                                (requiring recognition
                                  (implying awareness of self
                                    (assumed when using LISP)
      )))))))))))))))

------
juanmirocks
Back in 2009, when I first learned Common Lisp, I had the hope Lisp would one
day become mainstream. Then in 2012 I had the same hope for Scala.

... I got older and I'm not anymore a dreamer

Legacy code and imperative thinking is heavy.

~~~
mncharity
> I'm not anymore a dreamer

Perhaps it's time to start dreaming again?

Rewriting the world for VR/AR is coming up. And unlike the rewrite for mobile,
this time our software development environments will be transformed as well
(mobile wasn't a place for writing code). And while we're perhaps running out
of time for new compiler targets and languages, there seems a lot of potential
for changing infrastructure.

For example, a talk went by, which I recall as someone dropping linux
instances on google lambda, and setting up deterministic C compilation, for
massive parallelism and caching. So push a button, and some seconds later a
linux kernel has been recompiled (from empty cache). Which rather changes the
constraint space on "our language or type system can't provide nice-thing X,
because it would take too long to compile". Golang's story of runs fast on a
couple of local cores, may shortly sound like "my IDE runs on a PDP-11!", sort
of "that's cute - nice art piece". Is it ok to take two days to run some proof
obligation? ... well, is it cached now, so no one ever has to do that again?

Eye tracking; hand/finger tracking; escaping from 2D's crippling real-estate
constraints; speech recognition; fine-grain code sharing; rich compilation
frameworks ... there's a lot of fun incoming.

------
outworlder
Am I the only one who finds it hilarious that there are complaints about Lisp
syntax, when the language itself is almost infinitely modifiable?

You can replace parens with reader macros. You can replace built in names with
ordinary macros(in some dialects, even reassign the built-in functions
altogether). Don't like the let syntax? Modify it yourself to something
completely different.

You could modify Lisp to look like json if you were so inclined.

You have access to the compiler at compile time and runtime. Do whatever you
want.

If anything, people should be complaining about other languages that don't
allow for syntax modification. Want to not type semicolons in C? You are
essentially out of luck, unless you want to make your own preprocessor (I
don't think the standard one has enough expressive power to do so, but I'd
love to be proved wrong).

Complaining about parentheses takes zero effort though. You don't have to
spend a single second trying to understand why it looks weird like that...

~~~
willismichael
I'm a lisp fan, but to be fair, I don't think I know anybody who wants to live
in a world in which everybody has created their own personal language syntax.
Reader macros should be used very judiciously unless you don't care about
anybody else being able to understand your code.

~~~
outworlder
I agree.

But if you care _that_ strongly, you can do something about it.

(I am also kind of hoping that, by the time one gets to reader macros, they
will be experienced enough, and will understand why the parentheses exist so
that they will no longer care about them)

~~~
threatofrain
But for many people "caring that strongly" and "doing something about it"
means choosing another option. As opposed to essentially writing a new
language.

Good defaults do matter, and I would also echo the feeling that the
parentheses get in the way, and that a non-small component of my thinking or
polishing process is how to responsibly reduce parentheses. I find that it's
generally a modest but palpable boost to visual ease. I do wonder whether
there's a better way to denote nested lists?

------
spion
The surface problem of LISP are the parenthesis. The deeper problem is that
its a very potent NIH enabler: most of us are not really that talented or have
the time to properly invent things; those that are tend to not quite like
other people's things (and are good at spotting flaws in them) so they work on
their own "better" things (e.g. see arc).

~~~
lispm
JavaScript library space is basically pure NIH - maybe it's a Lisp, too?

~~~
outworlder
It does have a surprising amount of Lisp DNA, despite the horrible semantics.

~~~
lispm
You can bet that every day Javascript users reinvent Lisp stuff from 50 years
ago. Javascript on the language level is like Lisp from the end 70s minus
better numerics and minus macros and minus using JSON as a syntax for
programs. The prototype stuff is straight from Actors in Lisp, mid 70s.

