Hi John,

I have no bones to pick, here, but one:


On Sat, Mar 19, 2022 at 1:57 PM John Cowan <xxxxxx@ccil.org> wrote:

 in general the tendency to assume that your problem is everybody's problem has to be resisted in standards work.

C/C++ sets the benchmark for performance, and all other programming languages rate themselves against how fast they run, compared to C/C++.  Some languages have a charter that explicitly mentions C/C++-like performance:  CaML explicitly mentions this as a language design goal.  Some languages were not explicit about it, but have been forced into this, by powerful commercial forces: this is Java.  Most languages try to be reasonable, but they're not putting design decisions under a performance microscope. Is this where you want to be with scheme?

What's the charter for scheme, really? "To be popular like python" seems unlikely; even MIT is no longer teaching from SICP.  "To be a laboratory for exploration" seems to be accurate: we have three dozen scheme implementations precisely because it's easy and fun to explore. We have things like racket precisely because part of the fun is exploring "what else the language could be", without jumping ship to join the haskell crowd (which btw has only one implementation not dozens. Two if you count f#)

Standardization says: "we've decided what this should be, we've made up our minds, and we're going to set it in stone."  At this point, the standard should allow for at least one high-performance implementation, even if this is not the simplest or smallest-possible implementation.  It's easy to wave a white flag, throw one's hands in the air, and declare that "hash tables are the solution to all implementation problems". 

I'd like scheme to be as-fast-as-possible, as what else is it offering the world? it's not going to be python or java or rust. It may as well be tight.

--linas
--
Patrick: Are they laughing at us?
Sponge Bob: No, Patrick, they are laughing next to us.