From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@cse.psu.edu
From: anothy@cosym.net
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Message-Id: <20011009174328.56C2E199BF@mail.cse.psu.edu>
Subject: [9fans] correcting old failures, and NJ vs MA
Date: Tue,  9 Oct 2001 13:43:17 -0400
Topicbox-Message-UUID: 0391be98-eaca-11e9-9e20-41e7f4b1d025

// I'm not expert in Plan 9, but it seems to me that it [plan 9's rename
// behaviour] breaks it for the user.

i believe viro was talking specifically about the fact that changing this
awkward behaviour in Unix would break a bunch of user-level code
and user-created scripts, whereas in Plan 9 no user-level code or
user-created scripts existed to break yet. thus, when designing Plan 9,
the simpler approach to mv/rename was taken.

the remainder of this post is a bit of a rant. skip it if you're short on time.

// Is this just an example of the "New Jersey" preference for simplicity
// of implementation over the "Cambridge" preference for correctness
// and completeness?

the first time i was exposed to this distinction was in an appendix to "the
Unix-haters Handbook", appendix C, an article called "The Rise of Worse
is Better", by Richard P. Gabriel. the delibrate mis-representation of Unix
(and, by extention, Plan 9 and Inferno) design principles, and thus the
false distinction and conclusions, continually annoy me. here's why.

Gabriel characterized "the MIT/Stanford style of design" in four points
(taken from the above-mentioned source):

	• Simplicity - the design must be simple, both in implementation and
	interface. It is more important for the interface to be simple than that
	the implementation be simple.
	• Correctness - the design must be correct in all observable aspects.
	Incorrectness is simple not allowed.
	• Consistency - the design must not be inconsistent. A design is
	allowed to be slightly less simple and less complete to avoid
	inconsistency. Consistency is as important as correctness.
	• Completeness - the design must cover as many important situations
	as is practical. All reasonably expected cases must be covered.
	Simplicity is not allowed to overly reduce completeness.

Gabriel asserts that, for MIT/Stanford style programmers, all of these points
must be met. failure to meet any one is unacceptable (nevermind that he
contradicts that in the "Consistency" point, ironically). Gabriel contrasts this
with "the New Jersey approach" in the following ways (paraphrased for
simplicity and brevity):

	• Simplicity - it is more imporant for the implementation to be simple
	than the interface. simplicity is the most imporant design element.
	• Correctness - things still need to be correct, but it's slightly better to
	be simple than correct.
	• Consistency - can be sacrificed for simplicity, but it's better to drop
	completeness to save both consistency and simplicity
	• Completeness - the design must be as complete as is practical, but
	this can be sacrificed for any above quality, particularly simplicity. of
	particularly low value is consistancy of interface.

Gabriel is, however, an idiot (at least here).

first of all, the example he cites to show this difference uses a "famous
person" from Berkeley as an example of the NJ approach. problem one, as,
in my opinion, Berkeley mostly just missed the point. he then goes on to
talk about the difference between the MIT and "NJ" (really Berkeley)
approach to a specific problem ("PC losering" in Unix and ITS).

Gabriel is correct, in my opinion, that the NJ approach takes simplicity to be
the most important design constraint. Gabriel, however, sees this as in
conflict with the other three listed goals, whereas i believe the NJ approach
uses simplicity to achieve the other goals.

take windowing systems as an example. MIT produced X Windows, NJ
produced /dev/draw and rio. the NJ approach focuses on simplicity, and in
particular, simplicity and consistancy of interfaces. as a result, upon
designing the graphics system around 9P (a simple protocol consistantly
used to interface to the entire system), you get networked, remote displays
for free. focusing on simplicity (and consistancy of interace) helps achieve
the other goals in a much better manner. MIT, by contrast, focused, i think,
primarialy on completeness and correctness, and the result was a
complicated, often incorrect, inconsistant, and incomplete system.

it's worth noting that the same simple, consistant interface that made that
possible for Plan 9 gave us networked file systems that are more complete,
more correct, more consistant, and far simpler than NFS or SMB. look at
all the crap the X folks introduce to do things like remote audio.

finally, as forsyth points out, questions of "completeness and correctness"
are most often self-assesment exercises. particularly correctness, when
designing or building something new. who's to say what the "correct"
behaviour of mv/rename in Plan 9 is (well, when it was being designed)?
different definitions of "correct" carry different costs. having "correctness"
as a fundamental design principle (for new things - this is obviously
different if you're porting, rewriting, or emulating something) causes one
to ignore these tradeoffs in favor of whatever pre-concieved notions one
has about how something should work. this leads to systems or apps that
sacrifice one or more of the other three design goals - most often
simplicity - in favor of some ill-concieved notion of "correctness", which
quite likely a different notion of "correctness" than others have.

okay, rant off.
-α.