From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 12 Jun 2009 08:19:40 +0100 From: Eris Discordia To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <150229EFDD18355EF3520FAF@[192.168.1.2]> In-Reply-To: <60604076ef0cb4db30a25626acea77e0@quanstro.net> References: <60604076ef0cb4db30a25626acea77e0@quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Re: [9fans] critique of sockets API Topicbox-Message-UUID: 09d758b6-ead5-11e9-9d60-3106f5b1d025 > 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=20 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=20 viewpoint of a programmer/compiler have a role there. How a CISC=20 instruction set is implemented is besides this point. Some translation may=20 take place in the process but it doesn't matter as long as it is=20 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,=20 when it is carefully hidden and is exposed to the middle user only as a=20 variety of orthogonal options, does not result in a bad system. In can=20 actually result in a better system. I'm, of course, not claiming that the=20 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=20 for an end user who very often doesn't create product on their own,=20 although that may not be the case. A programmer who uses the language and=20 compiler you designed, or the OS you created, or the API you developed.=20 Having to learn fewer things is not discouraging, lack of expressiveness=20 due to lack of options can be. In case of Perl its popularity establishes=20 its merit for the area in which it is popular. Besides, we aren't talking=20 about if redundancy makes a system more expressive (it could but we aren't=20 talking about that), we are rather talking about addition of options that=20 are orthogonal to existing ones: options that have no equivalent. A callback infrastructure can be created in user land using threading but=20 that would have two disadvantages: the very point of lowering initial cost=20 using callback strategy is made moot, and people will tend to disagree on=20 how that extra infrastructure should look like so a variety of=20 incompatible, highly redundant implementations will pop up. > i don't see how progress =3D=3D 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 =3D=3D complicated. You could have a very = sophisticated=20 system at hand that is rather easy to program. Increasing adaptivity=20 through increased complexity is one well-known evolutionary path. The other = well-known path is increasing resilience through decreased complexity.=20 There is a point where resilience and adaptivity are just at the balance=20 you desire for your audience. Making clear who your audience is should=20 clear this problem as well. Regarding your example I believe you are mixing redundancy with choice.=20 While I could even argue for some redundancy I'm not trying to do so. File=20 typing, as seen on Apple systems, is not orthogonal to other features=20 already present in those systems; it is redundant. Windows does not have=20 any file typing similar to Apple's. UNIX-like systems do make some=20 distinctions between files which have become rather blurry with time. I=20 brought up the the subject in my awkward manner some time ago when caching=20 9P was being discussed on the list. It seemed to me that a form of typing=20 that expressed at a reasonable level of detail the amenability of files to=20 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=20 simplicity because you happen to work on a specific application for which=20 your target system's API is exceptionally well-rounded. Try designing a=20 complex UI for some CAD software and tell me how amenable your simple=20 system is to that purpose. The platforms targeted for, say, creating the=20 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=20 options, when done wisely, should not take away or negatively affect the=20 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=20 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=20 wrote: >> > i think you're trying to argue that =E2=80=94 a priori =E2=80=94 = 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 =3D=3D 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 >