[TUHS] Unix stories

[Steffen Nurpmeso]

Larry McVoy <lm at mcvoy.com> wrote:
 |It's simply a lack of craftsmen level thinking.  Managers think that people
 |are fungable, whatever that means, I think it means anyone can do this \
 |work.
 |
 |That's simply not the case, some people get the big picture and the details
 |and some people don't.
 |
 |There is also a culture of the cool kids vs the not cool kids.  For \
 |example,
 |at Sun, the kernel group was the top of the heap.  When I was doing nselite
 |which begat Teamware then BitKeeper then Git et al, I was in the kernel 
 |group.  They wanted me to go over to the tools group.  I looked over there
 |and saw people that weren't as good as the kernel people and passed.
 |
 |Same thing with testing.  So many bad test harnesses.  Because testing
 |isn't respected so they get the crappy programmers.  One of the best
 |things I did at BitKeeper was to put testing on the same level as the 
 |code and the documentation.  As a result, we have a kick ass testing

I had the thought this being standardized, as part of ISO 9001?
Groups of three which iterate in a rotation over the three parts
of a codebase, documentation / implementation / tests, also
rotating internally, inside the group?  And having some student
satellites.  Or atoms and electrons that form molecules, to be
more bionic.

I think much of the grief is owned to money, a.k.a. short-living
interests.  I think it is crucial, and very likely even essential
for survival, that there are Universities where people have the
possibility to linger badly paid in dark caves for years and
years, to finally come to a spiral conclusion, so to say.
If you doom a young human or student to spend a month doing
nothing but writing tests, you surely do no good, and gain the
same in return, and that only probably not in short-term.
Donald E. Knuth really got that right in his TeXbook, with those
funny homework excercises for over the weekend, say, "write an
operating system".

Laziness is another problem.  I for one dislike a lot what C now
is, where one has to write functions like explicit_bzero()
/ _memset() in order to avoid that compilers optimize away
something that seems to "go away anyway" at the end of a scope.
Or code blow due to automatic inlining and loop unroll.  Or
terrible aliasing and "sequence point" rules, where i think it is
clear what i mean when i write "i = j + ++i" (i believe this is
undefined behaviour).

Explicit instrumentation via new language constructs would require
more man power than paying a standard gremium to define semantics
which effectively allow more compiler optimization and gain more
performance and thus a sellable catchphrase, but on the long term
this surely soils the ground on which we stand.

I for one maintain a codebase that has grown over now almost four
decades and i still cannot say i stand on grounds of pureness,
beauty and elegance; attributes which, were possible, brighten up
everydays work and make a day.

--steffen