> Tony Rich : If you mean, "Is it possible to allow the scripter to
> extend the base language", I think the answer is probably "Yes, but
> you really don't want to allow that." When I was a grad student at
> UW-Madison, a prof in the Electrical and Computer Engineering
> department designed and implemented a new language named Galaxy.
> Galaxy allowed a programmer to change the normal Galaxy syntax to
> something else that the programmer liked better. The programmer could
> specify syntax changes right in the program. The Computer Science
> profs ... generally thought that was a bad idea. Imagine a company
> that had lots of Galaxy programs, all of which looked different
> syntactically -- it would be a maintenance nightmare. While each
> program might look good to its original programmer, each such program
> would immediately be unfamiliar to anyone else who had to read the
> source code.
Alain : We have to avoid having many different dialects or, if this is
not possible, one version of the language that is considered to be THE
standard. Application-specific differences should be "plugged-in",
leaving the generic shell intact.
> Tony Rich : But I'm right there with you in wanting sometimes to add
> something obvious to the base language rather than tacking on yet
> another Xthing.
Alain : It is true that Xthings are generally slower.
> Tony Rich : But I think language changes need to be made to the
> interpreter on a release-by-release basis, rather than on an
> app-by-app basis.
Alain : As long as these changes are not application-specific, eh !
> Tony Rich : It's like wanting Apple to "roll in" popular extensions
> into the MacOS rather than having lots of third-party extensions (of
> dubious quality and longevity) load whenever you boot the Mac. Once
> the changes are rolled into the main product, they become standard,
> supported, and everyone benefits from them simultaneously, of course.
Alain : So things that start out as externals could, if deemed truly
useful and generic enough, could be rolled into later releases.
> Tony Rich : I don't know how feature requests are arbitrated in open
> software projects.
Alain : Definitely one of my prime concerns.
> Tony Rich : But presumably the everyday scripters will be able to
> request additions to the language if there is some sort of consensus
> that changing the language is the best way to achieve the desired
> result.
Alain : Common sense will no doubt prevail.
> Tony Rich : The trick is not to let the language get bloated, and to
> keep some sort of simplicity and consistency to the syntax and
> "spirit" of the language. That way it doesn't end up looking like it
> was designed by committee, even though it actually was. ;^)
Alain : Bloatware is definitely out. I like the Components approach
that was heralded by OpenDoc but, alas, Steved at such a young age.
> Tony Rich : I think the current wisdom is that the best way to keep
> an evolving thing "clean" is if one expert person has the final say.
> My understanding is that that's how Linux does it; Torvalds has the
> final say in what goes into Linux.
Alain : Both Linux and PERL have proceeded in this manner. It is
perhaps the "only" way of achieving such coherent results, but I propose
to attempt a consensus-building approach to decision arbitration that
will allow a broad range of people to participate in these decisions. It
will be harder to pull off, but the end-results will be far more
rewarding, in my opinion.
> Tony Rich : I don't know how Netscape handles change requests.
Alain : I will have one of my partners look into this for us.
