Re: How powerful macros are?

"Andrew P. Lentvorski, Jr." <bsder@xxxxxxxxxxx> writes:

> Thomas F. Bur*** wrote:
> > But what's so special about arrays? I know that the current style is
> > for software engineers to use arrays for everything, including things
> > for which they ought to be using lists or trees or some other data
> > structure, but this might just be a result of most languages making
> > arrays syntactically so much easier than anything else. Arrays are
> > important building blocks, but you're supposed to use building blocks
> > to *build* things, at which point you're not dealing with the blocks
> > anymore, and you can't use the special syntax.
>
> Two words: random access.

Did I miss something or is #(....) an impossibly unbearable syntax in Lisp?

> If I need a simple linear collection, there is no point to using a
> list. Slower element access and more memory--for what benefit?

First, don't confuse algorithmic speed with practical speed.
Conses are fast, and arrays are often slower for very short lists.
O(1) can hide a lot of constant-speed sins.

For larger structures, sure, use an array. The only thing Lisp shows a
slight bias about is the use of lists to represent programs themselves.
When it comes to program data, though, I don't see any preference in Lisp
to use CONS/LIST/PUSH over any other function (e.g., VECTOR-PUSH-EXTEND)
unless you think the name is too long. And we do provide DEFUN and
INLINE declarations for allowing you to make shorter names with no loss
of efficiency.

> If I need a "collection of stuff", I tend to reach for hashes. I'd
> rather access based on a key with semantic value for me rather than
> position in list.

I do it a lot myself. Are you saying Lisp doesn't provide this?

I've also extended the language so that I have re-readable hash tables
for cases where I need that. Yes, that should be in the language, but at
least we have readmacros and print-object methods. What other languages
that you're comparing us to have the ability to repair misdesigns in the
language under user control, especially without breaking other programs
that don't want those repairs. (e.g., yes, you could modify the semantics
of an open-source alnguage, but then you affect all programs, not just your
own)

> If I need a hierarchical data structure, I normally need something
> stronger than a list--generally some form of a tree.

Does something you've read about Lisp by a competent programmer suggest
that we only use lists? If so, please cite it.

> My personal opinion is that lists are just getting squeezed out by the
> fact that Moore's Law has made reaching for an advanced data structure
> a practical default choice.

Hmmm. Seems to me that list chains are still going to win big in
modern architectures under instruction fetch lookahead in ways that
some other data structures are going to make opaque.

You could, of course, make the case that Moore's law has allowed
people to simply not care about speed. That's a harder case to
overcome. Except it argues for people using whatever they want... It
doesn't argue for something being squeezed out.

It's true that Lisp programs themselves are lists, but that's rarely
an interesting issue because in all cases that really matter, the
computation to analyze anything related to program syntax is done at
compile time and is done and gone by the time your program is
executing for its intended use. Further, even in an interpreted
situation, as if that really matters commercially, it's highly likely
that the arguments will be accessed in the order given by the lists,
such that lists are at least a defensible choice of data structure.

> I would actually like to see lisp teaching get away from the emphasis
> on lists and recursion.

We can't keep lisp teaching away from the emphasis on lists and
recursion exactly because (almost) no one uses Lisp to teach
conventional programming. They take their pet child C or Java or C++
and show conventional programming they could be showing in Lisp, and
then when they get to something it's too painful to show in their
language, they come to us and show our features in a light that is
very non-representative of how normal lisp programming is done. Then
they expect us to be grateful for the bad press they've given us by making
people think that we do all our data storage in lists.

> Closures, macros, and generic functions are
> the things I pine for when stuck programming in other languages.

People don't teach these things because they don't realize they're
even there. You have to get substantially farther into Lisp than
having had your grandfather read you The Little Lisper at bedtime
in the 1970's in order to know Lisp has these ... sigh.

I don't think the problem is correctly characterized as being a
problem of what is taught. I think the problem is who is doing the
teaching. To round numbers, I mean. Surely there are some good Lisp
teachers out there. But our worst enemy in some cases are those
"helpful" teachers that mention Lisp in a way that is not really helpful.

(Reminds me of the time someone I know called to say her church had
held an "authentic" Passover seder to help enlighten them about
Judaism... "Except," she explained, as if almost embarrassed, "we
didn't slaughter any little animals." I'm sure that was a BIG help
for her "understanding".)

Some kinds of "enlightenment" I think people can do without...
.