[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Libraries and repositories

On Wed, Dec 19, 2001 at 03:17:50PM -0800, Paul Graham wrote:
> Much as I would want to agree with an argument that praises
> Scheme and disses Java, I suspect that the real problem is
> that Scheme is (currently) ruled by a committee and Java
> isn't.  If the Scheme committee got together and blessed a
> huge collection of libraries as an official part of the 
> next version of the language, they would soon come included
> with anything that dared to call itself Scheme.  They're
> not likely to, though; look how long they dithered about
> macros, and what they ended up with.

Why is it when Lispers get together and discuss what languages
need, the discussion turns to arguments about macro systems within
about 5 posts?  :-)

Tony's point (if I'm paraphrasing correctly) is that Java is
irreproducible thanks to a hefty library that comes with the language
definition; Perl is irreproducible because the syntax is so grotty;
Scheme isn't standardized because it is so easily reproducible (a
task frequently assigned to undergrads).

Committees aren't the problem.  Large standard libraries aren't
the problem.  Ease of implementation isn't the problem.  They're
all second-order effects of interoperability (or lack thereof).

Perl hasn't been reimplemented yet, not because of it's syntax and
not because of CPAN, but because it hasn't been necessary.  Perl
is the canonical standard of a single implementation, and is
ludicrously cross-platform and interoperable.  Java has interoperability
fused into it's DNA -- through the abstraction of the JVM and the 
legal hoops implementers must jump through before gaining Sun's blessing.

If Scheme were to acquire a 20-volume standard library overnight, it
wouldn't help one iota.  That's because it's not the library that
matters, but the interoperability -- across platforms, across
implementations or both.  If however the Scheme committee or a single
individual were to rally around a 20-page paper on a standardized
module system (er, http://www.htus.org/Book/Staging/how-to-use-modules/),
then things would be different.

> The wind has shifted.  Languages have more in them, and change
> faster, than you can do with a committee.

Languages have more than you can do with a single language designer.
Focus on extensibility and interoperability and it's not a huge problem.