Re: What would your ideal language be like...

[address@hidden]

I think what you're getting at here is the tradeoff between
a language for one domain and a general language.  If you,
as a "language consumer", only ever want to work on one
particular domain (e.g. "files and strings"), then for you it
might be best to learn a language that's very specialized
for that purpose, so that the first five or ten chapters of the
manual are all about that domain.

But then what if you want to do some work in some other domain?
Do you now have to learn a second language, with new syntax such
as new rules about where statements end or how expressions are
grouped, and new control structures, and new namespace controls,
and so on and so forth?

When I was involved with Common Lisp, our feeling was that it was
better to take the overall attitude that sooner or later, someone
programming in one domain would inevitably need to operate in
other domains as well.  So the best thing we could do for our users
would be to provide one language with one syntax and one set of control
structures and one namespace ("package", as we called it) system and so
on.  Then we'd build everything else on top of that, using macros as
necessary to provide language constructs suitable for particular domains.

So when you wanted to expand to a new domain (e.g. a program that is
3/4 about files and strings but also needs some objects with inheritance,
or also needs to talk to the Internet, or also needs to do some fancy
matrix computations), you would not suddenly reach the end of your
domain-specific language.

Whether this kind of extensibitility needs to be done with Lisp-style
macros, or can be done with closures and other mechanisms, is not really
the point here; at the level of this email it is pretty much just an
implementation detail.  The ability to have a single language that can
be extended to handle specific domains well is the real point.

IMHO, this ability doesn't yet seem to exist, or at least not nearly
as strongly as it did in Lisp, in any of the modern "mainstream"
languages.  Why that is the case is a whole separate discussion, which
I think is extremely interesting but would be rather a digression
at this point.

-- Dan

> Fine, but if I have to *hunt* to discover how a language deals
> with files and strings, it is a clear indication that the language is
> made for a domain quite different from the one in which I work.