Re: Bad news from the module/environment front

[Telford Tendys <telford@eng.uts.edu.au>]

> 1) Aubrey often chooses speed over maintainability, or
> 2) Aubrey is much, much more clever than I am, and thus his code is
>    perfectly maintainable to him, while it sometimes stumps me for
>    hours.
> Possibly both.

I'd be guessing both, I've hacked around with scm a bit too and
also found it very difficult to follow. One of the main problems is that
there are no abstraction layers anywhere -- it is highly monolithic.
Another problem is that the C pre-processor does as much or more
work as the compiler does so the code you see is only approximately
related to the code that compiles.

The other thing is that, while speed is nice, it is not the prime
importance of a scripting language. I would rate the most important
points as:

[1] easy to learn
[2] completely bulletproof
[3] well documented
[4] easy to understand the fundamental operation
[5] easy to bolt your own code into
[6] easy to bolt into your own code
[7] low startup overhead
[8] can be compiled
[9] small memory footprint (unlike emacs)
[10] runs fast

Remember the target audience -- people who have working code to do the guts
of their job and want to support scripting or interactive evaluation with
minimal effort.

> This makes it clearer that almost all the slowdown is due to increased
> GC time.  Why does the new environment system allocate more than the
> old one?  Is the memory image larger as well?  (I hope so, or else I
> am very lost.)

GC is forever the bugbear of LISP dialects, has been for years probably
will be for years too. Java is starting to meet up with the same problems
too, probably perl will eventually. It is such an unsolved issue and one
that will probably take a lot more work before it is solved that it might
be better to admit defeat (at least for the moment) and concentrate on
other issues.

If the environment system really can get clean interfaces for modules
and a module system that everyone can understand and make use of then
it is valuable enough to excuse some speed loss. Doubly so if it means
that the startup files become logically organised by function so that
users who don't want functionality X can safely punt a startup file,
knowing that nothing else will suffer. Once we all agree on what we want
and why, we can gradually improve the how.

By the way, I'm behind in guile updates so I haven't tried the new module
system yet, its on the TODO list. Is it actually ready to roll at this stage
(i.e. should I consider it viable to start packaging up complete modules)?

	- Tel