Re: [9fans] critique of sockets API

[Eris Discordia <eris.discordia@gmail.com>]

> 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").

Heh. I did refer to exactly that article and consequently inserted "adding 
to the complexity of each primitive" as well as the modifier "strictly."

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

Try the Wikipedia article on CISC which really isn't a source, I admit. The 
general impression is that not only the total number, and diversity, of the 
instruction set but how much is done using a single instruction from the 
viewpoint of a programmer/compiler have a role there. How a CISC 
instruction set is implemented is besides this point. Some translation may 
take place in the process but it doesn't matter as long as it is 
transparent to the programmer/compiler.

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

Could be exactly that and further confirm my stance that added complexity, 
when it is carefully hidden and is exposed to the middle user only as a 
variety of orthogonal options, does not result in a bad system. In can 
actually result in a better system. I'm, of course, not claiming that the 
x86 instruction set represents an epitome of orthogonality or good design.

> 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?

A middle user is someone who uses your product to create another product 
for an end user who very often doesn't create product on their own, 
although that may not be the case. A programmer who uses the language and 
compiler you designed, or the OS you created, or the API you developed. 
Having to learn fewer things is not discouraging, lack of expressiveness 
due to lack of options can be. In case of Perl its popularity establishes 
its merit for the area in which it is popular. Besides, we aren't talking 
about if redundancy makes a system more expressive (it could but we aren't 
talking about that), we are rather talking about addition of options that 
are orthogonal to existing ones: options that have no equivalent.

A callback infrastructure can be created in user land using threading but 
that would have two disadvantages: the very point of lowering initial cost 
using callback strategy is made moot, and people will tend to disagree on 
how that extra infrastructure should look like so a variety of 
incompatible, highly redundant implementations will pop up.

> 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 don't see how complex == complicated. You could have a very sophisticated 
system at hand that is rather easy to program. Increasing adaptivity 
through increased complexity is one well-known evolutionary path. The other 
well-known path is increasing resilience through decreased complexity. 
There is a point where resilience and adaptivity are just at the balance 
you desire for your audience. Making clear who your audience is should 
clear this problem as well.

Regarding your example I believe you are mixing redundancy with choice. 
While I could even argue for some redundancy I'm not trying to do so. File 
typing, as seen on Apple systems, is not orthogonal to other features 
already present in those systems; it is redundant. Windows does not have 
any file typing similar to Apple's. UNIX-like systems do make some 
distinctions between files which have become rather blurry with time. I 
brought up the the subject in my awkward manner some time ago when caching 
9P was being discussed on the list. It seemed to me that a form of typing 
that expressed at a reasonable level of detail the amenability of files to 
various caching strategies could have improved the situation of 9P caching.

> 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.

The vast majority of them aren't. That's a fact of life. You appreciate 
simplicity because you happen to work on a specific application for which 
your target system's API is exceptionally well-rounded. Try designing a 
complex UI for some CAD software and tell me how amenable your simple 
system is to that purpose. The platforms targeted for, say, creating the 
frontend to a CAD system are not chosen by luck really. They have been made 
suitable by designers to that and other purposes. Adding of orthogonal 
options, when done wisely, should not take away or negatively affect the 
core primitives you use and are content with.

> 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.

I bet a 8051's manual is thinner that a 80x86's. Does that mean the 8051 
will be your platform of choice when it absolutely does not cut the task? I 
think it's somebody's motto: simple enough, but no(t) simpler.

--On Thursday, June 11, 2009 19:41 -0400 erik quanstrom 
<quanstro@quanstro.net> wrote:

>> > 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
>