evan_tech -- punctuation

11:30 am, 3 Nov 05

punctuation

Lisp/scheme programmers always say that eventually the parentheses become invisible. I've never so much doubted it as wondered how it could happen, as it never did for me.

So here's an analogy that works for me: I find when I've written a lot of Haskell code and then return to C++, I'm temporarily overwhelmed by the punctuation. Taking a single line from my editor, I see + = -> ( ) . , ;, some multiple times. But after a few minutes I no longer notice, and I'm back to thinking that code like input->value().c_str() is mostly code and just the amount of punctuation needed, nothing more.

hober	Lisp/scheme programmers always say that eventually the parentheses become invisible. I use davep's parenface.el to fontify parens in a washed-out version of the default face, so they stand out less. Not invisible, but diminished.
reply to this

zanfur

In the IDE I use (emacs), every close paren shows you where the corresponding open paren is. You also don't ever have to close them manually: there's a keystroke that means "close all parens here" and just does it for you.

Also, most lisp programmers (well, most lisp programs I see) indent their code very, very nicely, so the meaning is painfully obvious even to someone who doesn't know lisp. The IDE does that for you, too.

I think it's kinda like math. Eventually, you stop seeing the parentheses and just start seeing the groupings.

reply to this

3smallishmagi

I recently got an inexplicable urge to implement the lisp described in this tutorial:
http://www.paulgraham.com/rootsoflisp.html
in C++.

I think maybe the reason was the little joke ( I think some lisp folk take it seriously ) that says "lisp is a language without syntax." I was fascinated by how incomprehensible the most simple things were. e.g:
this:

(cond ( (atom (quote thing) (quote right) ) ( (quote t) (quote wrong) ) )

I would call unreadable, so it's most likely wrong.

if ( atom("thing") ) return "right";  else return "wrong";

I thought it might be helpful in showing what the next new thing might be like (Lisp is to modern languages as Modern languages are to {next new thing})
i.e. Modern languages let you make big intellectual leaps without thinking too hard. Use Lisp for a while and then go back to languages you like. Where do you feel relief? Where are you still frustrated? What bits of modern languages now show up as confusing fluff?

reply to this

djwatson

Lol!

Lisp is fun. Actually, try:

(cond
((atom 'thing) 'right)
(t 'wrong))

much more readable, eh? Actually cond is more like the switch statement, not the if. But in if form, it would be:

(if (atom 'thing) 'right 'wrong)

Even less fluf than modern languages! If course thing will always be a atom, so might as well just write:

'thing

Done!

Anywho, lisp is amazing. If you haven't read 'On Lisp' yet by Paul Graham, get on it! (It's the one good thing he's written, most others are too infused with ego and such, this is a purely technical look at lisp).

Ocaml seems to work better for larger programs in some areas, lisp needs more framework to work well for that.

reply to this

node

Here's all of lisp's syntax (with a few exceptions):

(function-name operand1 operand2 ...)

As for the code you quoted, you won't normally see any lisp code written like

(cond ( (atom (quote thing) (quote right) ) ( (quote t) (quote wrong) ) )

unless it's by a beginner, most commonly seen in comp.lang.lisp. You're extremely unlikely to find code written that way in literature. It should look like the code in djwatson's entry; here it is (with <pre> tags):

(cond ((atom 'thing) 'right)
      (t 'wrong))

or even

(cond
  ((atom 'thing) 'right)
  (t 'wrong)))

or, since it's just two branches,

(if (atom 'thing) 'right 'wrong)

I thought it might be helpful in showing what the next new thing might be like (Lisp is to modern languages as Modern languages are to {next new thing})

{next new thing} looks ugly. Extremely ugly.

reply to this