* * * * *
Various shades of grey
> Now, if you agree that there must be something fundamental, in lisps
> designs, that drives them all to social failure, what could be the root
> causes? I don't think the scare factor induced by parentheses is a real
> reason. Just look at the kind of scary, steaming piles of crapware Java
> developers are willing to learn: they're OK with filling a 2 meters long
> shelf with manuals explaining how to have ORM (Object Relational Mapping)
> and hibernation. The more verbose and unreadable a design pattern is, the
> more they love it. XML (eXtensible Markup Language) is much much scarier
> than sexps, yet consulting services are hysterically excited by it. No,
> really, it would take much more than parentheses to scare a Java
> programmer.
>
> So what could be the features of “normal” syntax that are missed by sexps
> [1]? [link added —Editor] Most notably, normal syntax gives you a feeling
> of what's idiomatic vs. what's weird. This means the syntax encourages you
> to write in a certain way, and hopefully everyone will be encouraged to
> write in the same style, thus understanding each other's code better. This
> helps bringing you interoperability and favors the writing of reusable
> code.
>
> …
>
> With sexps, it's much harder to create, maintain and convey such opinions
> in the code's appearance. Everything tends to look casual, and if it
> doesn't, just add a macro to make it look OK. It's difficult to build a
> shared seense of Good and Evil under these conditions, and without this
> consensus you'll have a hard time building a functional social group!
>
Via metalua [2] “metalua 0.4 [3]”
I think this brings up yet another aspect of Lisp I don't like [4]—it all
looks the same, regardless of what the code is doing.
For example:
> (assert (>=
> (cell-size (aref
> (aref (global-state-stack gs) (global-state-sundo gs))
> y
> x))
> 1))
>
(Not that I expect any self-respecting Lisp programmer [5] would ever write
such Lisp [6]—I'm just making a point here.)
It's hard to see that it's rereferencing a structure field from a two
dimentional array stored in an array of structures. The corresponding C code
is a bit clearer on this (a real-life example taken from a program I wrote):
> assert(gs.stack[gs.sundo][y][x].size >= 1);
>
It's clear that there are a few array and structure references (and a lot
quicker to type, which seems to be an argument that those muddle-headed
dynamic programmers [7] love to make, not to say they like Lisp any more than
I do).
Now sure, once you know what AREF does, you can see the array references, but
what about that (global-state-stack gs) business? Well … yes, it's a
function, but it just so happens to return the stack field from the global
state structure named gs (but equally, it could have been returning the state
stack from the global structure named gs—but you won't know until you track
down the proper DEFSTRUCT call).
Again, the C code makes it more visually explicit what's going on (well, in
one aspect anyway—the meaning of the code is another thing entirely).
Different things look different.
(Actually, now that I look at the C code, sundo is a bad name for that
particular variable—it should really be sp (stack pointer) since that's what
it's really used for; the sundo name derives from how I originally viewed the
function of that variable, which was keeping track of states to undo. I
should probably rename that variable to better reflect what it's actually
used for, but I digress … )
[1]
http://www.cliki.net/sexpr
[2]
http://metalua.blogspot.com/2008/12/refactoring-lua-code-with-
[3]
http://lua-/
[4]
gopher://gopher.conman.org/0Phlog:2008/01/04.1
[5]
http://c2.com/cgi/wiki?SmugLispWeenie
[6]
gopher://gopher.conman.org/0Phlog:2006/04/08.1
[7]
gopher://gopher.conman.org/0Phlog:2007/02/21.2
Email author at
[email protected]
