strangest systems I've sent email from

[Noel Chiappa]

    > From: Swift Griggs

    > even though there is *more* overall documentation on the Internet, the
    > docs you get with hardware and tools are nowhere near as good as they
    > were in the 80s AFAIK. 

I think that's partially because the speed of product cycles has sped up;
there just isn't time to get good docs done and out. Also, there's more
competitiveness/'efficiency', and good documentation costs money/overhead.

Wonderful as e.g. DEC Technical Manuals were, I suspect producing their ilk
nowadays is simply beyond the industry's capabilities (in the organizational
sense, not the technical skill sense).


    > From: Liam Proven

   > C is popular because C is popular.

Yes, but that had to start somewhere.

I think it _became_ popular for two reasons: i) it was 'the' language of
Unix, and Unix was so much better than 99% of the alternatives _at the time_
that it grew like crazy, and ii) C was a lot better than many of the
alternatives _at the time it first appeared_ (for a number of reasons, which
I won't expand on unless there is interest).


    > direct memory allocation, pointer manipulation and so on -- are
    > widespread /because/ of the C family influence. And I have a deep
    > suspicion that these are harmful things.

Pointers, yes. Allocation, not really - a lot of languages have heaps. Did
you mean manual freeing when you mention 'memory allocation', because
technically even something like CONS allocates memory? And one could consider
'auto' variables as 'allocated' - but the 'freeing' is automatic, when the
routine returns.

As to whether those two are harmful - they can be. You have to have a 'clean'
programming style to use them extensively without running into problems. (I
personally have only rarely run into problems with them - and then mostly in
very early C, before casts existed, because of C's wierd pointer math rules.)

I would need to think about this for a while to really come up with a good
position, but my initial sense is that these two are perhaps things that
should be hidden in the depths of large systems, for use by very good
programmers, that 'average' programmers should only be using higher-level
constructs.

(E.g. build a 'system' of routines to manage a certain kind of objects -
like OO languages enforce in the language itself - and the average user
only calls foo_allocate(), etc.)


    > I actually hugely admire Linux
    > ...
    > We are continuing to refine and tweak a 1970s-style OS -- a
    > technologically conservative monolithic Unix. FOSS Unix hasn't even
    > caught up with 1990s style Unix design yet, the early microkernel ones
    > .. It's roughly 2 decades behind the times.

I'm a bit puzzled by your first thought, given your follow-on (which I agree
with).

I'd go further in criticizing Linux (and basically all other Unix
descendants), though - your latter comment above is just about the
_implementation_. I have a problem with the _basic semantics_ - i.e. the
computational environment provided to user code. It was fantastic on a PDP-11
- near-'mainframe' levels of capability on a tiny 16-bit machine.
On modern machines... not so much.

	Noel