strangest systems I've sent email from

[Noel Chiappa]

    > From: Liam Proven

    >> I think it _became_ popular for two reasons: ... 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).

    > I am indeed interested.

OK, have to wind my brain back a _long_ way to remember what it was like
before I met C (which in my case was ca. '77).

Leaving aside places where you absolutely have to have pointers (e.g. device
drivers), the ability to allocate storage dynamically (whether via pointers,
or some alternative if you consider pointers unsafe) is just really key for
many uses, and not everything supported that.

For system work, stand-alone applications, etc pointers are really, really
useful (if not key), and there weren't that many languages with pointers. It
was an absolute revelation to see device drivers written *completely* in
higher-level language in Unix!

Anyway, for languages with that kind of capability, there was PL/I, which
although it was used for the Multics kernel, was rather a large pile; it
included a lot of stuff intended for commercial use.

There was BCPL, which is basically C without types (a _really_ major
drawback) and less terse syntax. Definitely a very nice language (a lot of
Alto software was written in it, for example), and probably the best
alternative to C _at the time_.

I think BLISS was just getting started then, and outside DEC I'm not sure
many people knew much about it. Can't think of any others with pointers, but
my memory is probably failing me.

Algol didn't have (IIRC) pointers or structures - the latter are
fantastically useful when writing network code (which is what I was doing at
the time). Did BCPL have structures? I don't recall.

It's just that a lot of things which we now take for granted, and will be in
any 'reasonable' language (types, structures, dynamic allocation, etc) didn't
exist in all the available alternatives back then.

And some languages had more hairy mechanisms for some things than were
probably really needed (e.g. 'thunks' in Algol, for complicated argument
support - nobody seems to miss that semantics in later languages).

C just seemed to hit a sweet spot for functionality versus complexity - in
the syntax, in the semantics; all over.


    > Well, malloc() and free(), anyway.

Especially free()! If you only let people call malloc(), a lot of bugs would
go away! ;-)


    > Not everyone's a genius. And those who aren't, often don't know. See
    > Dunning-Kruger. Klutzes think they're gods; gods think they're klutzes.
    > ...
    > So we *need* safe languages for the non-geniuses who think they're
    > brilliant.
    > ...
    > So, keep everyone in the safe space, but offer power tools - like Lisp
    > macros - so the brilliant are not held back.

There's a problem, though - the great people probably really need access to
'dangerous' capabilities, which they will use to create great software. Limit
them to the tools you make available to the average programmer, and you might
limit their effectiveness.

But once those more powerful tools exist, everyone and their mama is going to
want to use them, as you point out. With the inevitable result...

I dunno, maybe there's a way to have only 'safe' tools, but do so in a way
that doesn't limit the productiveness of the really good people.

	Noel