[TUHS] Tech Sq elevator [ really type-checking ]

[Jon Steinhart]

Larry McVoy writes:
> On Sun, Jan 12, 2020 at 04:01:02PM -0800, Jon Steinhart wrote:
> > Larry McVoy writes:
> > > On Sun, Jan 12, 2020 at 03:40:40PM -0800, Jon Steinhart wrote:
> > > > Linux contains several sets of list_for_each_entry() macros that are essentially
> > > > obfuscated for loops that generate inefficient code.  
> > >
> > > Very common idiom in any real system.  BitKeeper has them as well, they are
> > > used everywhere.  They are too useful to not use.  The BitKeeper ones give
> > > you most of Perl's list capabilities.
> > 
> > I don't see it.  In the cases that I've seen so far in linux the only uses are
> > inserting, deleting, and traversing lists.  My opinion that anyone who can't
> > write
> > 	for (p = list; p != NULL; p = p->next)
> > 
> > shouldn't be programming, much less in the kernel.  To me, type-checking and
> > code clarity are vastly more important.  If I want to program in Perl, I do
> > so.  When I program in C that's what I do.
> > 
> > I do want to be clear that I'm coming at this from a code maintenance angle.
>
> I'd argue that the code we wrote for BitKeeper would hold up as some
> of the most professionally written code ever.  Every commit was peer
> reviewed by at least 2 other people, code that add/changed/deleted user
> interfaces had to have docs and tests.  The philosophy is very much in
> line with code maintenance, I vetoed stuff that was clever, my mantra was
> "write once, read many so optimize for read".
>
> Some dude on twitter found our code when we open sourced it and tweeted
> something like "Wow, I've just spent the afternoon reading some of the
> best written C code I've ever seen.  I didn't know C could be that nice".
> So it's not just my opinion, I don't know that dude.
>
> The list code that we have is super pleasant to use and has been
> in production use for over 2 decades.  And we maintained it easily,
> our 24x7 *average* responsive time on a bug report was 24 minutes.
> The only reason it was that high was because we had to sleep (we were
> spread out from East to West coast).  During working hours, response time
> was almost always under 10 minutes, usually 2-3 minutes.  By "response",
> I don't mean some automated nonsense that says "We value your input,
> this is to let you know your report has been entered into our system".
> I mean an engineer looked at the problem, figured out what was causing the
> problem by looking at our source, about 90% of the time we knew what the
> fix was, and we sent an update to the bug report with that information.
>
> The list structure was auto resizing, it knew both how much was allocated
> and how much was used in the first word of the list (we resized only in
> powers of 2 so we could store size in log2 bits, used the rest of the
> bits for the length), you could have a list in as short as two words 
> and it scaled really well to millions of entries.  
>
> It was, and is, super useful.  Wayne is back at Intel and he's teasing
> it out of our libc to use there.
>
> So you may not like it but that's you.  It has worked well in an extremely
> professional environment.  Well coding professional, personalities might
> have been a bit wonky :)

I was commenting on what I found in the linux kernel.  Your code and list
interface may be better.

Jon