obvious reasons, I've been thinking a great deal this week about
the strong opinions people form on very little information. Even
worse, people tend to fixate on a subset of the limited information
they have available while actively ignoring the rest.
A number of modern computer languages have what are called
In Time compilers, aka JIT compilers. With JIT compilers, a human
writes source code in a human-readable form. There is usually then an
initial compilation stage which does some simple validation and
transforms it into a form suitable for interpretation by an idealized,
imaginary computer. At some later point in time, the transformed
version of the code is executed on an actual, real, live computer.
Just In Time compiler takes the transformed version for an
idealized computer and turns it into actual code for this specific
type of computer. With some super-fancy JIT compilers, the first cut
at this is very basic with some modest assumptions as to how the code
will be used. As the same pieces of code are run over and over again,
a super-fancy JIT compiler might recompile the code with new
assumptions (based upon past-usage) as to how the code will be used so
that the code can be as streamlined as possible for the most-frequent
or most-costly cases.
For systems without a JIT compiler, one of two approaches is taken.
Some systems take the human-written source code and transform it for
an idealized, imaginary computer and later emulate the imaginary
computer using your actual, real, live computer. Other systems take
the human-written source code and immediately transform it the whole
way into code for your actual, real, live computer.
Those systems which emulate the imaginary computer sacrifice speed.
Your computer cannot emulate the idealized computer nearly as fast as
it could run its own stuff.
Systems which compile directly for the real, live computer
sacrifice adaptability since they can only be run on computers which
are almost identical (in hardware and operating system) to the one for
which they were compiled.
Either way, without a JIT compiler, there is never an opportunity
to revisit the initial assumptions about how the code would be used.
Any optimization has to be done up front before the code is ever
As a real-world example, suppose that I have decided to write all
of my email in Esperanto from now on. You might set up a filter on
your mail-reader that invokes a translator when it goes to display any
message from me so that you can read it in Klingon rather than
Esperanto. This is
Just In Time translation. The message sits
in your Inbox in Esperanto. When you read it, it is transformed into
Klingon. If, later, you decide that your preferred language is
Elvish, you just have to re-open the message to get it in Elvish
instead. The alternative, not-
Just In Time version would be
that I have the filter set up on my end so that when I write a message
to you, it gets translated into Klingon before it gets sent. It sits
in your Inbox in Klingon. Even after you've moved on to Elvish, that
message will be in Klingon.
Most programming languages have an
Eager evaluation model.
Eager evaluation model, you can safely pretend that
when you see multiple function calls in a row, the functions will be
called in that exact order. For example, in the following code, the
foo() would definitely be called before the
y := foo();
x := bar();
Lazy evaluation model, when you see a call to a
function, all you are really seeing is a promise to call that function
if its value is every actually needed. As such, in the code snippet
above, if there is something that
foo() does with the
global state of the program that
bar() requires be done
before it is invoked, you might end up out of luck. The model hasn't
guaranteed the order these two functions will be called.
As a real-world example, imagine that you tell me to subtract the
year Hannibal crossed the Alps from the year Madonna won her first
Grammy Award and then write down my favorite color. I might search
Google to find out when Hannibal crossed the Alps and when Madonna won
her first Grammy Award. I might search for either one first. I might
just write down my favorite color and not bother subtracting anything.
I have done Lazy evaluation. If I were doing Eager evaluation, I
would have had to look up when Hannibal crossed the Alps before I
could even consider the question of when Madonna won her first Grammy
Award and I would have to do the subtraction before I even considered
what I should write down as my favority color.
I like to think of
Just In Time compiling as lazy evaluation
make me a version for my actual, real, live computer
function. You don't actually need code that can be run on an actual,
real, live computer until you are really, truly, about to run the code
on an actual, real, live computer. If no one ever runs that code,
there is never a need to compile it.
When do we form opinions? Are our opinions pre-compiled or
Just In Time? Are our opinions evaluated Eagerly or
Lazily? At what point do we need an opinion?
Is the strength of our opinion correlated to the strength of the
evidence we possess? Is our opinion taking into account how it is
actually going to be used in this situation, or is it based on modest
assumptions on how opinions are generally used?
Certainly, before flaming someone online, we have to have formed an
opinion. Was it a Lazy opinion where we decided to comment and used
all of the available information to form the opinion? Was it an Eager
opinion where the opinion was already formed well before it was needed
for this comment?
I, personally, have almost no drive whatsoever to flame someone
online. As such, when the question is
Should I respond (with
vitriol) to this blog post or comment?, I never need to try to
calculate an opinion. When I do try, I find that I'm stretching my
opinion over shockingly wide gaps in the landscape to try to make very
sparse evidence cover very large ground.
I have been realizing this past week though, that I do calculate
opinions early and on little information on other questions like
Should I go to this event? or
Do I want to talk to this
person? I close many doors with barely a glance as to what's
It is time to flush the caches. It is time to recompile the
routines that were compiled with very little information on how they'd
actually be used.