From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <71551546922daa465e9934a8b3f4b90e@quanstro.net>
From: erik quanstrom <quanstro@quanstro.net>
Date: Thu, 11 Jun 2009 14:24:47 -0400
To: 9fans@9fans.net
In-Reply-To: <47FB4BC290D45EE2F6D427EB@[192.168.1.2]>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: Re: [9fans] critique of sockets API
Topicbox-Message-UUID: 095edc42-ead5-11e9-9d60-3106f5b1d025

> I might as well repeat myself: choice of strategy depends on the
> application. Given choice programmers can decide on which strategy or
> combination of strategies works best. Without choice, well, they will just
> live with what's available.

this is a very deep philosophical divide between windows and
systems like plan 9, and research unix.  the approach the labs
took was to provide a minimal set of primatives from which
one can build what's needed.  compare just r?fork and exec
with all the spawn variants windows has.

i think you're trying to argue that — a priori — choice is good?

but given that plan 9 is about having a system that's easy
to understand and modify, i would think that it would be
tough to demonstrate that asyncronous i/o or callbacks
could make the system (or even applications) simplier.
i doubt that they would make the system more efficient,
either.

do you have examples that demonstrate either?

> One Right Way" always leaves open the question of whether a different
> choice of strategy on the same platform, were a different choice available,
> would have yielded better results.

clearly if that position is accepted, computer science is a
solved problem; we should all put our heads down and just
code up the accepted wisdom.

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.

- erik