You've seen a little bit of JavaScript
code and in this section; I wanna talk
about what connect to that world to the
machine code in the CPU. So, this is
beyond generally the topic of computer
languages. So a programmer works in some
computer language and computer languages
are said to have high quote, high level
features and that means things like loops
and if statements and strings. Those are
facilities that are more complicated, that
are most present in a really simple
machine code on the CPU. So the programmer
writes what it's called source code in
whatever computer language they are
writing. So here is an example of some C++
source code, this assigns a string into a
variable and then puts and exclamation
mark on the end of that string. You know
what? Some, it's kinda similar to the
JavaScript code we've seen A lot of these
languages at the syntactic level and of
their kinda similar to use of quotes and
semicolons or what not. So how do you get
from the C++ source code say to running on
a CPU? So one strategy used is what's
called a Compiler. And, the Compiler is a
separate program. And what the compiler
does is it looks at all of the source code
and it does a bulk translation over to a,
to create a big body of machine code. So
for example maybe there is a part of the
source code where there is an if
statement. And there is not a specific
instruction in a machine code for an if
statement but maybe there's a sequence of
five machine code instructions that in
effect make up an if statement and so the
compiler does that kind of expansion. So,
just an example Firefox is written in C++
and so, to make a new version of Firefox
someone runs the C++ compiler and it reads
in. Of the many source files that adamant,
the great body of source code that makes
out Firefox and proves that essentially,
firefox.exe. Firefox.exe is the output of
the compiler to just translate all of that
source code. Couple of things to point out
about this The compilation only has to
happen once so somebody with source code,
someone makes Fi refox [inaudible] and
then you can just send out Firefox
[inaudible]. The end users don't need the
source code and they don't need the
compiler so the compilation can just sort
of to be done, done at the factory in
effect. Another fact, another feature that
this doesn't work backwards, So, I can
distribute firefox.exe all through this
machine code but there's not something
that will read that in and go backwards to
give me a big body of source code. Really
is not perfectly, you can try to do it
imperfectly but ideally, to produce a new
version you who really wants the source
code. So, let's talk about the source code
a little bit. So if you wanna add a
feature of fix a bug to Firefox, real way
to do that is to go back to the original
source code and rework it just what we've
done in JavaScript. So, add a few lines or
an If statement to change some behavior
and some way into source code and then run
the compiler again to make in effect a new
version of Firefox that has this, this
little change that you've put in the
source code. And just as were, we're
talking about source code. There's also
give you, gives you a sense of what Open
Source software means. So, Open Source
software is a format where the program is
distributed but also there's access to the
original source code to the program and
usually does come with a license saying,
hey here's the source code if you wanna
make your own version or if it's about
whatever, this program, feel free. So, the
two main features of Open Source software
is one, it's, it's typically distributed
for free so it's just, you know, cheap.
But the other feature is it comes with a
sort of freedom. Because if the software
is close source and you want some
different feature there is some bug that
you need implemented you're really
dependent on the vendor who holds the
source code like do they feel like
implementing that feature. In contrast
with open source software it's like there
is no handcuffs you know the source code
is available and if there is something
that you really wanted to do or say the
original vendor goes out of business then
because you got the source code you could
or you know maybe pay someone to make a
change and produce your own custom
version. And so it comes with this sort of
deep, you could take this as an insurance
policy. So often there's, there's many
different types of license terms for open
Source software but most often they
require in some cases that if you take the
source code and add some feature that you
then offer those changes back to the
community. So sort of in the same way that
you've benefited from others work they can
benefit from your work. In, in the details
on how that can be done is complicated.
There's, there's many different forms of
it. I'm gonna talk about open source
software a little bit later on but I just
want to mention it now because it really
gets up this idea of what is the source
code of a program versus just having the
.exe or something. So that's why I just
talked about C++. So there's, a whole
another very big category of languages. We
come in to call Dynamic Languages Or
sometimes interpreter languages. And
there's sort of a big strategy, there are
many different languages with many
different qualities and I'm just kinda
sort of [inaudible] for this large
category So examples of Dynamic Languages
currently are Java and JavaScripts and
Python. So one way that these can work is
that they are implemented by what is
called an interpreter as supposed to the
compiler case I was describing earlier so
an interpreter is a program which takes in
code written in some language and sort of
quote, unquote runs it so. Best example is
that there is this computer language
called JavaScript that actually we've been
using and web browsers which are programs
include as part of them a Java Script
interpreter and so when the web browser
comes across a page with some JavaScript
code in it, it can use the interpreter to
run that code to make it do whatever it's
going to do. So, an available detail, the
way an interpreter works. Is that it, it
deals with the program one line at a time.
So, if, so here's a little bit of
JavaScript code. If the interpreter wanted
t run this, well, we'll look at the first
line and it would look at what that line
says and then the interpreter would do it.
So in this case the interpreter would say
oh well, I guess I need a variable name a
and I need to put a one in it. So, once it
summed at that line it goes ahead and it
does the next line and so on. So the
compiler does this big bulk translation
from the source code into machine code.
But it's not really running code, it's
just doing a translation to be run in the
future. In contrast, the interpreter
really lives in the moment Just going
through the code line by line and just
doing it. So let me talk a little about
the differences between these two and I
should tell you as a disclaimer there are
many computer languages. There is no best
language. The old joke is that. Really
when, you know, you're on this seminar and
you are arguing about the pros and cons or
something. Ultimately, the answer is just
it depends. Like there's not a best
language, it's like well, what's the best
language for the situation with all the,
with all the feature. So broadly speaking,
compiler code does tend to run faster and
when you put, when you compile C++ code
and produce that EXE, it's sort of in a
sense lean. A lot of detail and decisions
has been stripped out as much as possible.
On the other hand, dynamic or interpreter
languages tend to have more features. More
features that make their programmers job a
little bit easier or put in another way.
Broadly speaking, programmers can tend to
get more work done per hour in dynamic
languages than they do in compiled
languages. However there is no free lunch.
It is also the case that dynamic language
code tends to run slower on the CPU in
terms of just getting work done compared
to a compiled language, compiled source
code that was going to do the same thing.
So, an example of this, a great example of
this is memory management. So, memory
management refers to the problem in the
code of knowing how many bytes are needed
to store something And in particular, for
how long. Well, I need these bytes for
here on line six but maybe on line twenty.
I don't need them anymore and I can reuse
those bytes for something else. And that
is actually a kind of a complicated
problem. In C and C++ memory management is
to a degree manual and that just means
that the programmer, they're producing all
these lines of codes to do stuff and there
is going to be times when they maybe to
add some lines to do some thinking to help
guide the memory management so there is
some programmer effort required. In
contrast most dynamic language have what's
called automatic memory management and
this means that. No programmer input is
required that the lower on the stacks that
the language is gonna notice automatically
when memory is needed; when memory is not
needed anymore it can be recycled and just
take on that whole problem. So, this fits
within the, the, the trend of dynamic
languages that I was mentioning earlier.
So this is an example of how well, you
know, because the programmers has less to
do they're able to just get stuff done a
little quicker, so memory management is a
great example of that. However, you can
also imagine this is one of the things
that makes dynamic language codes run a
little slower because the CPU now has this
additional bookkeeping problem where it's
looking at memory and trying to figure out
of when it can be reused. So, very broadly
speaking the trend for computer
programming today is towards dynamic
languages that the trade off that. The
programmer will get things done a little
quicker at the expense of using a little
more CPU or maybe a little more memory,
that's a pretty attractive payoff for many
for many problems. In this, maybe a little
unintuitive you can think off. We'll
what's the scariest quality for a computer
program and oftentimes, it's the
programmer that having skilled programmers
working on a problem who, you know,
working on those, working on these do
main. A lot of times there are hard to
find and so using up their hours. Using
few of their hours looks attractive. In
contrast the CPU only we want programs to
run as fast as possible but Cpus are
fairly, and if it got some fairly,
effective and there was even this funny
effect where Moore's Law keeps making it
more truth. Where the CPU in a fact each
year gets a little bit cheaper, but if you
think of the balance between the
programmer cost and the CPU cost of
getting something done, that means in
terms of the share of the pie, the
programmer is in a fact of getting more
expensive each year. A little bit more
scarce. So, this fits the pattern that on,
on, on, on whole, dynamic languages are
becoming a little bit more popular. Just
the last thing I'll mention is that
there's, I think a thing called a JIT, a
Just in Time compiler and this is sort of
the natural synthesis of the compiler and
interpretative strategies of trying to get
the best of both worlds. It's like, well,
we'd like to have a dynamic language with
all these features, all these
programmer-friendly features but we wanted
to run fast and so the JIT will take parts
of the code and try and compile them on
the fly and so I try I to sort of
[inaudible] the two approaches. It turns
out this works pretty well. So all modern
browsers now have jets for JavaScript code
so actually when you are running
JavaScript code even for this class inside
of the browser there was a jet that was in
a very physical way on the fly, taking
those scraps of JavaScript code and
compiling them on the fly, Anyway it, You
do not get exactly the formats of compiled
code but it gets fairly close. So, this
is, this is actually how most dynamic
languages were at first. And I'll say
well, it's an act the value of research
but it.