[
Lists Home |
Date Index |
Thread Index
]
David Brownell wrote:
> > > > At the end of the day code and data just aren't that much
> > > > like each other. Maybe this is why Lisp never took over the
> > > > world, cool though it is. -Tim
>
> Personally, I think the deal with LISP was that it's a bit too advanced
> a programming language for most folk. Plus it was never pitched
> for commercial applications -- it was aimed at folk who really didn't
> have an issue with syntax, and whose problems didn't revolve around
> databases and report generation. Even the M-expression notation
> didn't get around that.
There are many similarities between LISP and XSLT, excepting of course that
XML et al. have been solidly backed by commercial folk, at least that is the
claim. Perhaps the differences are more to do with marketing than
technology.
Regarding objects vs. data (which is where we started), the prime
distinction is between opacity and translucency. When objects are well
described, and their state can be described by the getter setter properties
in their interfaces, as data objects they can be translucent. Object
_methods_ however are generally opaque -- the implementation hides behind an
interface. Contrast LISP and XSLT, whose method implementations can be fired
across the wire (in a perfect world) for remote execution. It should not be
lost, however, that java bytecode can similarly be treated as data. I am
sure that Guy Steele is well aware of these issues.
>
>
> > > It is very interesting that you say this. I've seen a few people
> > > from the Lisp camp complain that XML is simply a more verbose
> > > yet less powerful reinvention of Lisp S-expressions with a lot of
> > > extra complexity added in (like namespaces, attributes and entity
> > > references). [Dale Obasanjo ]
this is somewhat true. If XML/SGML hadn't attributes one could simply
replace:
<foo>
<bar/>
<baz/>
<bop>
<bing/>
</bop>
</foo>
with the s-expression (granted there are a couple of ways to do this):
(foo bar baz (bop bing))
XML might be more generally represented using something akin to an
s-expression notation by introducing delimeters for an unordered set '[' and
']' and then we can represent:
<foo aaa="111" bbb="222" ccc="333">
<bar ddd="444"/>
<baz/>
<bop eee="555">
<bing/>
</bop>
</foo>
as:
(foo [aaa="111" bbb="222" ccc="333"]
(bar [ddd="444"])
baz
(bop [eee="555"]
bing
)
)
and we see that XML starts to look not so verbose after all.
(this is my standard argument to LISP folk)
> >
> > You have to take that with a grain of salt though.
> > There are folks in the Lisp camp who say that about
> > *every* new programming technology. "What's the big
> > deal about X? It's just a poorly reinvented version
> > of feature Y in Common Lisp." [Joe English]
>
> Those criticisms (less powerful, more verbose etc) have
> more than a grain of truth to them though.
>
> Consider: send an S-Expression over TCP and (eval) ...
> that's "write once, run everywhere" about 30 years before
> certain marketroids decided it was a good idea. And
> that's just one many examples ... :)
exactly. but again, recall where Java comes from.
what is interesting to me is whether XSLT is really the programming language
we are all seeking, or whether we might [move on/go back] to (something
like) DSSSL which is essentially the same thing in s-expression syntax.
Jonathan
|
