[TUHS] Unix stories

[Noel Chiappa]

    > From: Nick Downing

    > way overcomplicated and using a very awkward structure of millions of
    > interdependent C++ templates and what-have-you.
    > ...
    > the normal standard use cases that his group have tested and made to
    > work by extensive layers of band-aid fixes, leaving the code in an
    > incomprehensible state.

Which just goes to provide support for my long-term contention, that language
features can't help a bad programmer, or prevent them from writing garbage.

Sure, you can take away 'goto' and other dangerous things, and add a lot of
things that _can_ be used to write good code (e.g. complete typing and type
checking), but that doesn't mean that a user _will_ write good code.

I once did a lot of work with an OS written in a macro assembler, done by
someone really good. (He'd even created macros to do structure declarations!)
It was a joy to work with (very clean and simple), totally bug-free; and very
easy to change/modify, while retaining those characteristics. (I modified the
I/O system to use upcalls to signal asynchronous I/O completion, instead of
IPC messages, and it was like falling off a log.)

Thinking we can provide programming tools/languages which will make good
programmers is like thinking we can provide sculpting equipment which will
make good sculptors.


I don't, alas, have any suggestions for what we _can_ do to make good
programmers. It may be impossible (like making good sculptors - they are born,
not made).

I do recall talking to Jerry Saltzer about system architects, and he said
something to the effect of 'we can run this stuff past students, and some of
them get it, and some don't, and that's about all we can do'.

     Noel