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

[Larry McVoy <lm@mcvoy.com>]

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 :)