[COFF] [SPAM] Re: [TUHS] Algol 68 and Unix (was cron and at ...)

[clemc at ccc.com (Clem Cole)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4484 bytes --]

On Thu, Dec 17, 2020 at 1:00 PM Larry McVoy <lm at mcvoy.com> wrote:

> I think it is part of being really smart, it's a puzzle for them and they
> "win" if they can do something clever.  I always replied "It is write once,
> read many.  Optimize for reads".
>
Amen to that bro.

And at the risk of getting either Jon or Ted (or both probably) I think
that what astonished me when Jon and I were discussing how the Linux FS
stuff got spliced in with so many macros and indirections, frameworks, *et
al*. earlier in the summer (i.e. when Jon was trying to build up his newest
idea); the Linux kernel code for the FS interface was so 'clever' (ney
complex and indirect) that was no longer clear what in the code did what to
either of us (and Jon and I are hardly neophyte C programmers).   As Ted
fairly points out it works and seems to be reasonably fast in practice, and
the Linux kernel team has created test code for some of it all which is far
better than the coding practice in a lot of the rest of the FOSS community
at large. But I suggest that sometimes just because *you can do something,
doesn't mean you should *(tipping my cap to Rob's '*cat -v harmful*'
observation of years gone by).

As a side note, I will say there is another vector to this same curse.
It's the new guy coming into the project and deciding what is there is
crap, they can not understand and they can do a better job.   IMO this is
a problem that is rampant in many FOSS community projects, but I used to
see it at DEC >>all the time<< and still run into it at Intel these days.
Picking on DEC and using Tru64 as an example, it took 3 extra years to get
Tru64 out the door from the original OSF/1 codebase because of it.  Every
major subsystem was rewritten.  Not saying what they got from OSF was
perfect, but DEC could have shipped Tru64 with the original terminal
handler/SCSI/memory/graphics/100% 64-bit clean ... and replaced the code
later with 'better' implementations.

The bottom line for me is that I rather give up a tiny amount of the
absolute speed for long-term scale and maintenance cost (then again it one
of the reasons while I'm a microkernel fan too).  Unless this new
feature/rewrite something that is really going to make or break me, I
rather make what works today, and evolve over time when I have a revenue
stream (*i.e.* OSF/1 was good enough for most of Alpha, but Tru64 was
amazing -- it just took three years].   Plus, as Warner points out, the
original author will be long gone - which only play farther into my
thinking of simple is clear is better in the long run.  No just in FOSS,
again, DEC/Intel, we have people retire or go elsewhere all the time (plus
we get a new set of VPs that reset the corporate direction every 18-24
months).

My basic thinking is you should pick the one or two specific features that
really matter for your product and you need to ensure that its value is
exposed and very much available to the customer.  The rest needs to be simple,
clear, and works, and you're done.  Get on to the next thing.

BTW: this is not just a system SW issue.  I suspect it's more fundamentally
human when people get excited by their own ideas and what they can do and
don't stop to think about the true ramifications of the effort.   One of my
all-time favorite papers is Tom Lyon and Joe Skudlarek's wonderful 1985
tome 'All the Chips That Fit' which bemoans the hardware equivalent of this
same problem [which if you have never read, as a system person you should].

Also, it's also not a computer business only issue.  I have another story,
I'm not sure if I have told here before, which I call the 'Milacron
problem.'  I use it to explain to our younger engineers why creating
something new is not always the right way.    Cincinnati-Milacron is one of
the oldest, largest, and most respected machine tool manufacturers in the
world. My HBS brother ran the robot division and later the machine tool
group at one point.  Milacron can make anything -- period.   That is their
business.   So what happens, ever newly minted Mech E wants to make his own
hydraulic values for their project.  At some point in the 80s, Milacron had
over 5000 different hydraulic values in their internal parts catalog
because no one would take the time to see if one from a previous project
would work.

Clem

ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20201217/c14e6401/attachment.htm>