> My view is that the people doing the work get to
> decide.

Agreed. This is a very important principle. I have done volunteer work
for a decade (most of it face-to-face and not computer-related) and the
same pattern repeats in every organization: The person who is actually
doing a job needs to be able to decide how to do it. It often helps if
other people offer suggestions, but the person doing the work needs to
make the final decision. If someone does a lot of work, and people who
aren't doing it criticize it and make demands to do it differently, it
leads to burn-out in a year. This should be taken seriously, I've seen
it happen multiple times. Usually the person doing the work has good
reasons for doing it the way they do. Also, imperfection has to be
tolerated. There is too much work to do everything perfectly right away.

Communication can help, but it does not ultimately solve the problem,
because there is not time to communicate about all the details (for
example, I've tried communicating in detail about my Scheme work, but it
takes so much time that it brings the actual work to a halt. I'd rather
work faster than send more email and I think the result is more valuable
to Scheme as well.)

The only solution is to build trust. Without trust, more communication
will not help, and may even make things worse.

> For that reason, I think it would be best if we
> went after that original goal ("collecting,
> organizing, and serving indexes of Scheme code")
> first.  Having achieved that goal, we'll have
> momentum, confidence, and an understanding of how
> each of us works that will let us tackle new
> goals.  That's how we can build from simple goals
> to more ambitious ones.

The problem is, many programmers work in a highly non-linear way, and
are not able to function otherwise. I've tried to force myself to work
in a linear way for many many years. It just doesn't work. I know many
similar people. The way to get "linear" work out of a non-linear person
is to give them a deadline. That's why the SRFI 90-day rule is wise.

This may come down to temperamental differences, but I rarely see the
need to make detailed plans and have detailed goals. It's good for each
end product to have a clear scope (e.g. this repo does X, this library
does Y, this web page does Z), but it's often not clear at the start
what the end products should be or how to get there. And if somebody has
a vision ahead of time, it's usually difficult to communicate to others.

My opinion is that writing code faster is the best "planning". It's good
to discuss which direction to go, but I wouldn't take it too seriously
until there is some solid code/designs/docs to show. Surprises can
always foil plans. And it's good to explore different directions.
Prototypes beat written plans.

> I agree about not using Biwa Scheme.

In fairness, we are also being unfair to Biwa as a mostly one-person,
very work-in-progress project. It's already made good progress toward a
valuable goal and we should encourage the effort. Not everything needs
to be perfect right away.

> Furthermore, as you can
> see from the GraphQL site, there are lots of
> implementations of the server side in different
> languages:
>
>    https://graphql.org/code/
>
> Some of them look small enough that I'm willing to
> believe that writing one in Scheme wouldn't be a
> huge effort.  That could be a good medium-term
> project.
>

The server will be quite a bit of effort, but several other tasks for
Schemeweb are equally hard. I agree that medium-term is good.

We can start with Kawa at some point. We could wrap the Java GraphQL
libraries, which I believe are production-quality.

> It should be possible to have both.  If we agree
> on simple on-disk formats for storing the data,
> then it would be easy to generate new static web
> pages for some things automatically.  A simple
> implementation of GraphQL could handle more
> complex queries.  The key is that all of the
> software involved be open source so that anyone
> can take it and run it elsewhere.

Indeed. We should definitely have both.

I stand by my claim that any solution that gets rid of GraphQL will
eventually re-invent it badly. I spent a lot of time (1-2 months)
thinking about many general and detailed aspects of the API and every
train of thought came to that same conclusion.

It elegantly solves several difficult problems:

- A schema with type type system, type checking and type inference.

- Easy backward-compatible evolution of the schema without version
numbers. This is the #1 problem for a big, long-lived API, it was my #1
worry personally, and I had absolutely no idea how to solve it well
before reading about GQL.

- Clients dictate the response format, not servers. This is how
backward-compatibility (and efficiency) are achieved. And it means the
API designers don't need to think about response formats that are useful
for decades, which is the #1 most difficult problem in most APIs (humans
are not good at planning a decade ahead).

- Discoverability (GUI GraphQL clients have tab completion for the whole
API with no effort from the API designer, thanks to the type system. I
had never seen anything like it.)

- Standardization (different GraphQL clients and servers work together
without a hitch - tab completion, type hints, everything works).

- Schema design (the GQL schema language is an excellent thinking tool
when designing the data model.)

So much wisdom went into it, that I think we should first study it well
and then make our own S-expression syntax for it. If we start with our
own S-expression queries (as Frank and I did at first), we'll just
repeat the classic mistakes that led to the invention of GraphQL. And
the API server implementation will take so much code that we could
probably implement a generic GraphQL server in almost the same amount of
code.

We should definitely have S-expressions for on-disk storage, but I find
that I make better S-expression formats now if I start designing them in
GraphQL and then translate to S-expressions :)