From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Fri, 21 Mar 2014 22:55:49 -0400 To: 9fans@9fans.net Message-ID: In-Reply-To: References: <20140316155223.GA556@spark.home> <9e72419c18681b46d86755504e9bc14b@brasstown.quanstro.net> <20140317221942.GA313@spark.home> <97e0a383d9a82f2ad92c580962b6f34b@mikro.quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Cannot boot plan9 Topicbox-Message-UUID: ce2d427c-ead8-11e9-9d60-3106f5b1d025 > As an aside, why don't we have an architecture like this? (From your > comment, I'm assuming we don't.) > I'm sure there are valid technical reasons, but to an uneducated bystander > like myself, this seems to violate DRY. because at least in the case of the linux disk layers, it makes the code harder to read, follow and maintain. code is read many times, and written once. therefore, readability is more important than writability. plan 9 tends to avoid middle-management code. heavily layered code can also be hard to test. certainly, repeated code isn't something one wishes to create. and plan 9 has too much of it. on the other hand, combining code isn't free. one of the ideas that go has had is to use interfaces extensively. this allows fine-grained reuse, without the worry that management code has. if you've worked for even a moderately large orginization, perhaps you can relate to the difficulties of middle-managment code. :-) - erik