Software II (11 mins)

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.