From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 23716 invoked from network); 15 May 2020 15:01:59 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 15 May 2020 15:01:59 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 4782F9C997; Sat, 16 May 2020 01:01:54 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id BEFD59C694; Sat, 16 May 2020 01:01:25 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 9F0849C677; Sat, 16 May 2020 01:01:23 +1000 (AEST) Received: from mcvoy.com (mcvoy.com [192.169.23.250]) by minnie.tuhs.org (Postfix) with ESMTPS id 5B4949C668 for ; Sat, 16 May 2020 01:01:23 +1000 (AEST) Received: by mcvoy.com (Postfix, from userid 3546) id C969435E149; Fri, 15 May 2020 08:01:22 -0700 (PDT) Date: Fri, 15 May 2020 08:01:22 -0700 From: Larry McVoy To: Dr Iain Maoileoin Message-ID: <20200515150122.GF30160@mcvoy.com> References: <202005141841.04EIfvEZ063529@tahoe.cs.Dartmouth.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Subject: Re: [TUHS] v7 K&R C X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: The Eunuchs Hysterical Society , Doug McIlroy Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" On Fri, May 15, 2020 at 08:55:46AM +0100, Dr Iain Maoileoin wrote: > My question is: > What is that line? I dont understand it? Effort input vs output? > Complexity measure, debugging complexity in a 3rd party program? I think you are asking precisely the right question. There is a line where one side is good enough and good enough is just that. The other side is just too much, too much to get tangled up in. I think Rob and Ken and the rest of the Go team are not lauded enough for having the restraint to stay on the right side of the line. It's so easy to be seduced into yet another feature, "it's not that bad, we can do it." It is far harder to say "Nope, not gonna do that". The Go team reminds me a bit of the original QNX team. QNX was/is a message passing microkernel, it's the only microkernel that is actually micro (in my experience, I hear that L4 is good but haven't looked). They had a core team of 3 people that were allowed to touch the actual microkernel. All of which fit into a 4K instruction cache on x86. Every commit went through the filter of "does this add to the cache?" That sort of discipline is really rare. Far more common is "I benchmarked it and it only slows down by 1%" - that's death by a thousand paper cuts.