>>> [...] The unfortunate thing with Scheme is the dearth of actively
>>> developed applications. Apps are needed to put library designs to
>>> the test.
>>
>> This is actually a very, *very* bad sign about the state of the Scheme
>> world.  One I'm planning on addressing at least a bit, but Real Life
>> is hitting me very hard for the foreseeable future.
>
> We have probably more implementations of Scheme than applications
> written in Scheme. :) But even with so many implementations, the
> competition with other languages is hard because there is usually more
> money to maintain high-quality implementations of those languages.
> (Another reason why it was very costly to the RNRS process to, well,
> alienate Chez and Racket.)

All true. A not-insignificant fraction of good programmers are elegance
junkies; it perplexes me a bit that more of them are not finding Scheme.
When I came to Scheme, I was elated to find that garden-variety Scheme
code is as elegant as the programming pearls in most other languages.
Elegant code just comes out by default with no special effort.

Whatever the reason, I think we should find allies in similar languages.
My pet project is to look for ways to bridge Lisp and ML family
languages, which have very high cohesion by their nature. It would be
wonderful to design a library once and have it work in multiple
languages in this family with only a little adjustment. We all solve
similar problems anyway. To start with, Scheme and Common Lisp deal with
almost the same concepts. A library interface rarely needs to be
concerned with the parts where they diverge (basically, continuations
and CLOS).

A significant part of library design is simply naming things. There's no
fundamental reason why different languages couldn't use the same names
for equivalent operators. `make-list` or `repeat` makes no difference,
but since we have different names in different languages, it makes it
costly to switch between them, meaning users of language A are less
likely to try out language B even though there is good conceptual cohesion.

> Now, this program cannot work because we have to versions of the
> record type coming from the two disjoint loadings of the library
> (fantastic bar).

Good point. The core data types and control flow of Scheme would have to
be protected from changes in yearly editions. `define-record-type`
should define compatible types, `cons` should make compatible pairs
(Racket broke this by separating immutable conses from mutable ones),
strings should be compatible, etc.