Re: [9fans] critique of sockets API

[erik quanstrom <quanstro@quanstro.net>]

> > i think you're trying to argue that — a priori — choice is good?
>
> I believe it is. How many of us are using strictly RISC machines on our
> desks today? Extending the set of available primitives and adding to the
> complexity of each primitive both are natural steps in the development of
> computer systems as they see more use.

just to correct a basic fact, the size of the instruction set doesn't define RISC
instruction set (http://en.wikipedia.org/wiki/RISC "instruction set size").

can you cite any references that claim that the size of intel's
instruction set has contributed to its success?

could it be that since transistors are very cheep, adding instructions is
simply the cheapest go-faster trick?

> Limiting options doesn't seem to me
> to be an effective way of encouraging good programming practice. It can,
> however, successfully discourage potential middle users.

what is a middle user?  and why would such a person be
discouraged by having to learn fewer things?  does the myriad
of different ways to write an if statement in perl make it more
useable?  readable?

> > that's not the position i subscribe to.  and since plan 9
> > is simple and easy to change, it makes an ideal system
> > for someone who wants to try new things.
>
> And after the new things are tried out and, one may hope, proven
> advantageous? I think the next step would be incorporating them into the
> system. A process that in due time will make the system less simple and
> easy to change but more immediately useful.

i don't see how progress == complicated.  could you explain
how they are one and the same?

as a counter example, unix uses untyped files.  not only does
lack of typing make the system simplier, it makes it more expressive
as well.

> I see this more as a difference of intended audience than a difference of
> taste or philosophy. The real question is whom (sic) you imagine as your system's
> middle user: a wage-earning programmer or a researcher. Were I a programmer
> who worked for pay I'd very much appreciate being given every possible
> option that would let me do my job easier, faster, and, of course, more
> properly.

i don't see how a wage-earning programmer can't be a researcher as well.
and being a wage-earning programmer, i appreciate simplicity and use
it to advantage on a daily basis.

several times, i've needed to get a particular bit of h/w working.
given a choice, i go with the one with the thinner manual.

- erik