Re: making up language features

[Sam Tregar]

On Mon, 6 Aug 2001, Tom Lord wrote:

> The discussion now has nose dived into unmotivated, out-of-the-blue
> "what ifs".

Forgive me for jumping in from the sidelines, but what did you expect?
You began the discussion with unmotivated, out-of-the-blue disertations.
Did you expect to generate reasoned responses on twenty different subjects
on demand?

> So how ought language design decisions be made for Guile?  Is it just
> ``Whatever faction gets tired first looses?''  or ``Whoever checks in
> code the fastest wins?''  How has that worked so far?

Consensus?  Or do we have a benevolent ruler?  I've watched the Perl
community make siginificant progress under a fairly autocratic leadership
structure.  Most open source projects are not so lucky.

>       - Freeze new features and work on testing, performance,
>         and robustness.  With tools to thoroughly measure the
>         state of the implementation, further development will
>         go more smoothly and produce more reliable results.

There's no reason to stop new development to work on testing.  You can
start adding a more robust test suite today.  When it's ready, we can fold
it into the distribution and start fixing the bugs it uncovers.

While you're at it, I'd love to have a working gprof on guile.  I was in
an optimization mood a few weeks ago and I thought I'd look at Guile a
bit.  After a couple frusterationg hours looking at empty profiling
reports I gave up!

>       - Pick an application to build Emacs-style -- using the
>         extension language as the primary implementation language,
>         and make that application work well.

That sounds like too much fun to be really useful.

>       - Clean up the build/install process to eliminate automake
>         and autoconf.

If it ain't broke...  I've watched a similar effort burn itself out in the
Perl dev community.  Nobody likes them but they get the job done.

-sam