There are very good reasons for C occupying a special place in the
firmament of languages, although I think one thing to say at the outset is [that] really
it finds its maximum power - it's maximum raison d'etre for even existing at all - if you
think of it as being the classical system implementation language. Again, for
younger viewers, it's going to be hard to understand and comprehend this. But if
you go back to the early mainframe era you're getting really, really, powerful
computers - well by those days' standards - coming along, from the early 60s
onwards. They were so expensive they had to be time-shared between lots of users
and that in turn means you've got to have system software that can multitask
between different people, different people's programs loaded in the
machine at the same time, all being time- sliced with a little bit of time. But at
the same time, increasingly, computer systems had to evolve into not just
being able to print out your output and your answers but to store it in a
file; they had to run file systems. And by the early 1970s you are in this
incredible situation that one of the biggest challenges in programming - a
real-time challenge where you had to keep people happy - was nothing more or
less than the operating system in your computer. One of the hardest challenges
going. And, yeah, the wisdom was: "You will only ever be able to do this in
assembler". Some of the low-level tricks you need to do in operating systems - you
know the `real man' attitude: "Real Men use assembler!" And I think a lot of people
said: "No, there's some truth in that but on the other hand just a little bit of
higher-level operations - if only it could be done without slowing the language
down too much would help us stay sane. I think a lot of
people, gradually, were, if you like, embellishing assemblers to become macro-
assemblers to try and give the kind of higher-level approach to things that you
got in high level languages. But on the other side the opposing armies were always
saying: "High-level languages - they're so inefficient! You need assembler for
everything, ideally". Moore's Law put paid to that, y'know. Yes, we can afford to use
high-level languages for a lot more things in the early 70s. Then there
were a lot of experiments in trying, usually, to adapt existing languages for
system implementation use. And particularly ones that had started to
build in some low-level operations for bit twiddling. It was getting important
to be able to dig down to the byte level and get out characters. Looming up, just on
the horizon, shock! horror! as if 16 bits wasn't a toy computer - 8 bits [was] coming.
So you needed a language to evolve that could cope with different widths of
objects. Of course as it becomes ... you go through a sort of - like a minimum - in the
curve. You know - we have to chop things down in size because otherwise we can't
make it at a price that people will buy. But then, as hardware becomes cheaper,
generally you then turn the corner. And you could see it even in DEC and
their PDP-11 minicomputers. Soon enough they come along with a 32-bit computer
[the VAX] which they can afford to make at long last. And, of course, that was the era when
discrete transistors and components, on printed circuit boards, gave way to chip
technology. So you have, like, LSI-11s. It's large-scale integration, it's not
separate components any more. And gradually the curve turns the other way
>> Sean: How did this change in architecture feed back into the language choices then?
>> DFB: Well, I think that it's two things. First of all, can you get a system implementation
language that helps you do low-level things at a higher level? And I still
think that, probably, you could say that the most successful of all time - and on
that front - was C. It's not that there weren't others. There were things like Bliss, there
were things like, even, Algol 68. And other high-level languages, BCPL, were tried out.
But C had the great advantage that you could see how you might port it. Ah! yeah!
Dennis, Ken all that. They're doing it on the PDP-11; they'll be doing it on the
VAX but up come the SUNs, all of a sudden. The SUN servers. Hey! can we port
UNIX to this? We're porting UNIX - we got to get the C compiler working! Can you get
the C compiler working - yes of course you can. And it really stood the
test of time. I mean when you look now, in the `gcc' compiler, at the architectures
that are supported, it just writes its own brochure saying: "Just look at this, we
can cope with anything!" However, the other side of that, was then the
differentiation to, if you like, higher-level languages - even imperative
ones - just became more marked. And I think it was very interesting that - I think it
was in the mid to late 80s - James Gosling of Sun effectively ... it's people who
run programmers and see how many mistakes they make when they're using
pointers. And, as far as I recall it, one of the design requirements of Java was:
"We're gonna ban pointers at user level". When we start looking at why
programs go wrong it's people who've made mistakes with pointers. So therefore
we're gonna ban them. I'm actually not against that. If you really don't need to
do low-level manipulations of pointers then let the language do it for you.
Or if it's like C++ where you could do them and you say I don't want to do all
my clever stuff under the hood - I'm not writing an operating system. Yeah! get
hold of a library full of functions and trust them because they'll have been
tested. They'll be efficient and all this kind
of thing. So, yes, things like functional
languages, which of course always used to - still do! - get flak for being so slow,
They became more and more possible to do I suppose Brian [Kernighan] might say they got
`less and less inefficient' y'know. But no, it was a liberation to have that much
compute power around that you didn't have to think too much. I'm glad that
many sensible souls on the comment streams of recent videos have said this.
It's no good getting theological about: "You're not a real programmer if you don't
program in C" or anything silly like that. You've got to have an attitude of
`horses for courses': the right programming language for the right task. If it's
yelling out to use Python, use Python. If it's yelling out to use AWK - as I've
been known to do ... Yeah! I tried out, as you know, my Reed-Muller `messages from Mars'
I got it ... hacked it together in AWK. Well, why not? You can always take the
view that if it's not efficient enough we can drive down to a lower
level, more efficient, language. But the ability to try things out, without them
taking hours and hours - because of really fast hardware - is probably about the
biggest liberation I can think of in terms of my professional career as a
computer scientist. >> Sean: You know I'm not a programmer. I mean, one day it might make a
video - my bad exploration of BASIC in my youth. But, as a non programmer I suppose
I come at this and think, well, why can't there be one thing that fits all and my
kind of taking examples from other parts of life. Presumably certain
things are good for certain things like you say> >> DFB: I think that's right. I think that
you see it in all sorts of other realms in life. It's that you know the true
professional tool for doing something - it was probably very different from a user-level
tool. Y' know, I mean, if you go to a hardware store and buy yourself a drill
with a hammer action, you know that's a very different object from what they
would use industrially to hack into buildings. It's in principle the same but
the whole spec. and construction of it is very different. And that's what we
now have the ability to do, is to fit the language to the task.
Of course, it still leaves a big problem that lots and lots of software ideally
should have been rewritten years ago. Because the moment you get something
that's good for its time, and works, the temptation is just to leave it in place
because it works and we daren't change it because so many things are dependent on it.
So, this is why there are still 8-bit Z80 programs doing heaven knows what in the
Armed Forces. There are probably still companies out
there, in the wild, still using COBOL on mainframes. You know [the] cost of a mainframe
simulation these days? Peanuts! That program [will] cost us a fortune to rewrite it.
And it's bound to go wrong, And it's known and reliable so that thing about having
legacy software and hardware and it's so difficult to trust to replacing it. It's
still is going to be a problem eternally I think, that. >> Sean: well there is a
well-known phrase: "If it ain't broken, don't fix it!" >> DFB: What's helped the `ain't broken'
bit, you see, that's the thing, is that if there's something rather exotic on the
hardware front, from the 1960s, you no longer have to literally build one of
those. You can simulate its action. So as long as you put a lot of effort into
getting a good simulator going, then you can carry on with the code you've had
for 30-40 years in some cases.