Hello.
In this video, we're going to talk about
something that I've referred to as
the economy of programming languages.
So the idea behind this video is that,
before we get into the detail of how
languages are implemented or designed,
I wanted to say something about how
languages work in the real world, and
why certain languages are used and
others are not.
If you look around, there's actually a few
obvious questions that come up to anybody
who thinks about programming languages for
more than a few minutes.
One question is, why are there so
many of these things?
We have hundreds, if not thousands,
of programming languages in everyday use,
and why do all of these
things need to exist?
Why wouldn't one programming language,
for example, be enough?
A related question, but
slightly different is,
why are there new programming languages?
Given that we have so
many programming languages already,
what is the need for
new ones to be created?
Finally, how do we know a good
programming language when we see it?
What makes a good programming language,
and what makes a bad programming language?
I just wanted to spend, this video anyway,
talking about these three questions.
As we'll see, I think the answers
to these questions are largely
independent of the technical
aspects of language design and
implementation, but
very interesting in their own right.
Let's begin with the question of why are
there some many programming languages, and
at least a partial answer to this
question is not too hard to come by.
If you think for a few minutes, you'd
realize that the application domains for
programming have very distinctive and
conflicting needs.
That is, it's very hard to design one
language that would actually do everything
in every situation for all programmers,
and let's just go through some examples.
One domain that you might not think
about very much is scientific
computing, so these are all the big
calculations that are done for
engineering applications primarily,
but also big science and
long-running experiments,
simulation experiments.
What are the needs for such computations?
Well, typically,
you need very good floating point support.
I'll abbreviate that as FP.
You need good support for arrays and
operations on arrays because
the most common data type
in most scientific applications
is large arrays of
floating point numbers, and
you also need parallelism.
Today to get sufficient
performance you really have to
exploit parallelism in these applications,
and
not every language actually
supports all of these things well.
This is actually not an exhaustive
list of the things you need, but
it's a few distinctive
things that are needed.
One language that has traditionally done
a very good job of supporting these things
is Fortran, and Fortran is still heavily
used in the scientific community.
It was originally designed for
scientific applications.
If you recall, the name means formula
translation, and it has evolved over time.
It doesn't really look much like
the original language anymore,
but it's always retained this core
constituency in scientific computing and
remains one of the leading
languages in that domain.
Now, a completely different kind of
domain is business applications.
What do you need here?
Well, so here you're going to
need things like persistence.
You don't want to lose your data.
Businesses go to a lot of
trouble to get the data, and
they need a way to hold onto it, and
they want that to be extremely reliable.
You're going to need good report
facilities because, typically,
you want to do something with the data,
so you need good facilities for
report generation, and, also,
you want to be able to exploit the data.
The data is actually, in many modern
businesses, one of the most valuable
assets, and so you need good facilities
for asking questions about your data.
Let's call it data analysis.
Again, this is not an exhaustive
list of things that you need,
but it is representative, I would say.
Probably the most common, or one of
the most commonly used languages for
this class of applications, is SQL,
the database query language.
Relational databases and
their associated programming languages,
but most notably SQL, really
dominate in this application domain.
Then, another domain, let's do one more,
is systems programming.
By this, I mean things like embedded
systems, things that control devices,
operating systems, things like that,
and what are the characteristics here?
Well, we need very low level
control of the resources.
The whole point of systems programming is
to do a good job of managing resources,
and so we really want fine grain
control over the resources.
Often there's a time aspect, so you might
have some real-time constraints, so
you need to be able to reason about time.
Because these are actually,
again, devices, and
they need to be able to react
within certain amounts of time.
If it's a network device or
something like that,
you need to be responsive to the network,
lots and lots of things.
Lots and lots of examples where timing is
important, and these are just two aspects,
and I'm running out of space here,
so I'll just stop with that.
But again, these are representative
of the kinds of things you need
in systems programming.
Probably today, still the most widely
used systems programming language, or
family of systems programming languages,
is the C and,
to some extent, C++ family of languages.
As you can see, the requirements in these
different domains are just completely
different from each other.
What's important in one domain,
or most important in one domain,
is not the same as in another domain,
and it's easy, I think,
to imagine at least that it would be
difficult to integrate all of these into
one system that would do a good
job on all of these things.
That brings us to our second question.
Why are there new programming languages?
Okay.
There are so many languages in existence.
Why would we ever need
to design a new one?
I'm going to begin the answer to this
question with an observation that,
at first glance, has nothing to
do with the question at all, so
let me just take a moment to explain it.
I claim that programmer training is the
dominant cost for a programming language,
and I think this is really important,
so I'm just going to emphasize
the bit that's important here.
It's the programmer training.
The cost of educating
the programmers in the language.
If you think about a programming language,
there are several things that have to
happen for that language to get used.
Somebody has to design it, but
that's really not very expensive.
That's just one or
a very few people, typically.
Somebody has to build a compiler, but that
is also not actually all that expensive.
Maybe 10 to 20 people for
a really large compiler project
can build quite a good compiler.
The real cost is in all the users,
in educating them.
If you have thousands or
hundreds of thousands or
millions of users of a language,
the time and
money that it takes to teach them all
the language is really the dominant cost.
Here I don't mean just the actual
dollar expense of buying textbooks and
taking classes and things like that.
It's also the fact that the programmers
have to decide that it's worth it for
them to learn this language, and many
programmers learn on their own time, but
that's a use of their time.
The expense of their time is a real
economic cost, and so, if you think about
the number of hours that it takes to teach
a population of a million programmers
a language, that's really quite
a significant economic investment.
All right.
Now, from this observation, we can make
a couple of predictions pretty easily.
Again, these are just predictions,
now, that follow from this claim
if you believe that it's true.
Let me erase that and
fix it, so first prediction
is that widely-used languages
will be slow to change.
Why should that be true?
Well, if I make a change to
a language that lots of people use,
I have to educate everybody in
that community about the change.
Even relatively minor
language extensions or
small changes to syntax small new
features, even just simple changes in
the interface of the compiler,
if you have a lot of users,
it takes a very long time and it's quite
expensive to teach them all about that.
As languages become widely used,
their rate of change will slow down.
This predicts that over time, as the world
of programming grows, as we have more and
more programmers in the world, we would
expect the most popular languages,
which will have larger and larger user
bases, larger and larger programmer bases,
to become more and more ossified,
to evolve more and more slowly.
I think, actually,
what you see in practice is very
consistent with that prediction.
Now, at the other end of the spectrum,
this same observation
makes an almost what appears to
be a contradictory prediction,
which is that it's easy
to start a new language.
That, in fact, the cost of starting up a
new language is very low, and why is that?
Well, because you start zero users, and
so there's essentially zero training cost
at the beginning, and then,
even when you have just a few users,
the cost of teaching them the changes
in the language is not very high.
New languages can evolve
much more quickly.
They can adapt much more
quickly to changing situations.
It's just not very costly to experiment
with a new language at all, and there's
a tension between these two things.
Okay?
When is a programmer going to choose
between a widely used existing language
that perhaps doesn't change very
quickly and a brand new language?
They're going to choose it if their
productivity now exceeds
the training cost.
If they perceive that by
spending a little bit of time and
money to learn this new language they're
going to be much more productive over
a relatively short period of time,
then they're going to make the switch.
Okay?
When is this likely to happen?
Well, putting this all together,
languages are most likely to be adopted.
To fill a void.
Okay, and, again, this is a prediction
that follows from the fact of programmer
training is the main cost.
What do I mean by this?
Well, what I mean is that programming
languages exist for a purpose.
People use them to get work done, and
because we're still in the middle
of the information revolution,
there are new application domains
coming along all the time.
There are new kinds of programming
that emerge every few years, or
even more often than that.
In terms of recent history,
mobile applications are now
something that's relatively new, and
there's a lot of new technology built
up to support mobile computing.
A few years ago it was the Internet itself
was the new programming platform, and
a bunch of new programming
languages like Java, in particular,
got started during that time.
New programming niches open up because the
technology changes, what people want to
do with software changes, and this
creates new opportunities for languages.
The old languages are slow to change,
and so they have some difficulty
adapting to fit these new domains.
They aren't really necessarily well-suited
to them for the reasons we talked about
on the previous slide with the previous
question because it's hard to have
one language that incorporates
all the features you would want.
The new languages are not necessarily
perfect for these application domains.
They're slow to adapt to
the new situation, and
this tends to call forth new languages.
When there's a new opportunity in
some application domain, if there
are enough programmers to support the
language, often a new language will arise.
I just want to point out another
prediction that can be made from this
one observation, that programmer training,
again, I'll underline that,
is the dominant cost for
a programming language.
That is that new languages.
Tend to look like old languages.
That is, that new languages are rarely,
if ever, completely new.
They have a family resemblance
to some predecessor language,
sometimes a number of predecessor
languages, and why is that?
Well, partly that it's hard to think of
truly new things, but also, I think that
there's an economic benefit to this,
namely that it reduces the training cost.
By having your new language
look like an old language,
by leveraging off what people
already know about the old language,
you make it easier for
people to learn the new language.
You make them learn it more quickly, and
the most classic example
of this is Java versus C++.
Where Java was designed to
look a lot like C++, and
that was, I think,
very conscious to make it easy for
all of the existing C++ programmers
to start programming in Java.
Finally, we can ask ourselves,
what is a good programming language?
Here, unfortunately,
the situation is much less clear.
I would make just one claim,
that there is no, and I'll emphasize no,
universally accepted metric for
language design.
What do I mean by that?
Well, I guess,
the most important part of this
statement is the universally accepted bit,
so
I mean that people don't agree
on what makes a good language.
There are lots of metrics out there, and
people have proposed lots of ways of
measuring programming languages,
but most people don't
believe that these are very good measures,
and there is certainly no consensus.
If you just look at
the world of programmers,
they can't agree on what the best language
is, and to convince yourselves of this,
just go and take a look at any of the many
Newsgroup posts where people get into
semi-religious arguments about
why one group of languages, or
particular language,
is better than another language.
Even in the research community,
in the scientific community and
among the people who design languages,
I would say
that there is no universally accepted
consensus on what makes a good language.
To just kind of illustrate
the difficulties in trying to come up with
such a metric, let me discuss one
that I've heard people propose,
in all seriousness, and
that is that a good language.
Is one people use.
Let me put a question mark on that
because I don't believe this statement,
and I think, with a moment's reflection,
I can convince you that
this isn't a great measure.
On the positive side,
I guess, the argument for
this is that it's a very clear measure.
It measures the popularity
of the language.
How many people are actually using it,
and presumably
languages that are more widely used
are more widely used for a good reason.
In some sense, perhaps, they are better
languages, but this would imply,
if you believe this and
follow it to its logical conclusion,
that Visual Basic is the best language.
Yeah, above all other
programming languages, and
I have nothing against Visual Basic.
It's a well-designed system, but I don't
even think the designers of Visual Basic
would claim that it is, in fact,
the world's best programming language.
As we saw in the discussion that
we just had, there are many,
many other factors besides
technical excellence
that go into whether a programming
language is widely used or not.
In fact, technical excellence is probably
not even the most important reason
that a language might be used.
It has much more to do with
whether it addresses a niche or
an application domain for
which there isn't a better tool.
Then, once it's established and has lots
of users, of course, there's inertia and
history that aid it in surviving.
That's why we still have FORTRAN and COBOL
and lots of other languages from long,
long ago that we could, if we were
starting over today, design much better.
To conclude this video on the economy
of programming languages,
I think the two most important things to
remember are that application domains have
conflicting needs, and, therefore,
it's difficult to design one system
that incorporates everything
that you would like to have.
You can't get all the features
that you would like into
a single system in a coherent design,
at least it's very hard to do that, and so
it takes a lot of time to add new
features to existing systems.
The second point is that programmer
training is the dominant cost for
a programming language, and together
these two things, these two observations,
these really explain why we
get new programming languages.
Because the old languages are difficult
to change, and when we have new
opportunities, it's often easier and more
direct to just design the language for
those rather than trying to move
the entire community of programmers and
existing systems to accommodate
those new applications.