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. Especially free()! If you only let people call malloc(), a lot of bugs would go away! ;-) 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