[PRL] Code's Worst Enemy

[William D Clinger]

Matthias wrote:
> And the entire system actually rests on the gluing
> together of N separate existing libraries (lib scheme,
> wx:windows, and a slew of others initially and over
> the years more joined).

Mitch wrote:
> So, what can we do about this?  If this is a (the?) Big Problem, shouldn't
> we be working on it?

Yes.

Matthias wrote:
> I consider it a real problem but not a 'grand challenge' type  
> question. There is no single solution waiting that 'algorithmic'  
> researchers (people who solve single individual problems) can work  
> on. It won't attract the kind of attention that Hoare's 'grand  
> challenge' will and it won't create the kind of funds that a grand  
> challenge will. But it is honest work.
> 
> I do consider the PLT Scheme effort a contribution to this problem. I  
> also suspect that Larceny could be minded for bits of insight on this  
> front.
> 
> There is lots of work to be done and I actually think everyone on  
> this list could work on some aspect of this problem without us  
> trampling all over each other.

Here are four specific things we could do that would
greatly improve the portability of Scheme code as well
as interoperability with other systems:

1.  Make sure our implementations of Scheme (PLT and
Larceny) implement the de facto standards for Scheme:
ERR5RS and R6RS as well as IEEE/ANSI and R5RS.

2.  Teach our students to write portable code within
those standards, instead of encouraging them to use
implementation-specific idioms.

3.  Develop an R7RS that actually enables portability,
instead of relying on an R6RS that merely claims to do
so.

4.  Build on ERR5RS/R7RS by developing general-purpose
interfaces to non-Scheme libraries that can be made to
work in most ERR5RS/R7RS systems.

The four steps I have outlined above can be criticized
for being too inward-looking, because of their focus on
Scheme, but they are more outward-looking than a lot of
what we have been doing.

Will