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.