Re: [9fans] writing code

[Russ Cox <russcox@gmail.com>]

> > The mechanism is, and always is, someone writes code.
>
> maybe this is unrealistic, but i'd like to see more "encouragement on
> principle".  that is, if someone suggests something, it'd be nice if
> people (particular labs or ex-labs people) would chip in and say "yes,
> it's a good idea in principle; i'd like to see something like that"
> (or perhaps "yes, but it should be done in this way", or "bad idea,
> philosophically misguided").

i'm all for encouragement on principle, but the thread i was replying
to had gotten beyond that point.  it started out with an interesting
question -- what to do beyond rio -- but devolved into religion about
why rio should be more like what's on unix/mac/windows without
pointing out a single problem that would solve.

i think there are plenty of interesting answers to the original question.
acme is one.  but "be more like other systems" is never an interesting
answer.

ultimately, it always comes down to code.  we can talk all we want
but at the end of the day the only real proof that something is a
good idea is to implement it, try it, and see.  andrey and i have
been talking about an implementation of alt-tab for the plan9port rio
that i think will feel quite rio-like (except for the whole typing thing),
but we won't know if it's actually reasonable until we write it.

> if there were various projects around that had been given the
> thumbs-up on principle (pending actual implementation), perhaps more
> people might be inclined to get their hands dirty and write some code
> towards those ends.

that would be great.  nothing in the rio thread resembled a project.

> instead, i feel that people face the prospect of spending weeks
> writing code, only to be told at the end that the whole aim of their
> effort was misguided; or, worse, that the work was indeed misguided, but
> it gets included anyway on the grounds of inclusiveness, diluting the
> excellence of the whole system.

i can see that, but it's hard to say ahead of time that something isn't
misguided.  i think what happens most of the time is someone writes
something to solve a problem that they have, and if it's generally
useful, it makes its way in.  a good example is aquarela.  but there
are problems that have been solved and not rolled in -- ron is working
on better clustering support, but i doubt that will be polished enough
to be mainstream for a while yet.  tim has got the ultrasparc almost
working.  all of these people wrote the code because it solved a problem
they had, so it was useful to do regardless of whether it gets picked up.

it's also hard to say something's not misguided until you try it.
(it's often easy to say it *is* misguided, but that's not the
encouragement you were looking for).  there's always a risk
that it might turn out not to be a good idea, or to need another
go around.  even the things that are successful often need
extra go-arounds:  even central pieces such as the file server, 9P, and
the graphics system have gone through at least three major revisions each.

i agree that it would be great to have a list of interesting problems
to solve, but i'm not sure we could actually figure out beforehand
which solutions are the best ones or even which are complete flops.
but you're right -- we can at least identify the problems.

russ