
Essentials of Interpretation - DmitrySoshnikov
http://dmitrysoshnikov.com/courses/essentials-of-interpretation/
======
chrisseaton
There seems to be a real cottage industry of how-to-write-
interpreters/compilers at the moment - Writing an Interpreter/Compiler in Go,
Crafting Interpreters, this, etc.

~~~
mhh__
I think it's people realising that compilers aren't _that_ complicated until
you get into the backend.

Lots of optimization passes, even, are relatively obvious (not necessarily
trivial, but they make sense) - to my eye at least, the Voodoo magic is in the
scheduling and code generation

~~~
seanmcdirmid
With something like the dynamic language runtime, even code generation can be
easy. Too bad it hasn’t been copied on other platforms outside of .NET.

~~~
chrisseaton
What does .NET do to make code generation easy?

~~~
seanmcdirmid
The DLR as I mentioned is an API for dynamic code generation that hooks into
the platform’s JIT. The code you can generate with it runs fairly fast (as
fast as other JITTed code)

~~~
chrisseaton
Do you mean just generating bytecode through an API? That's a completely
trivial problem in the first place - just linearise your AST. When people talk
about 'code generation' they mean the complexity of native instruction
scheduling and selection.

And if you want to just generate byetecode doesn't Truffle on Java do that far
better than DLR? Truffle seemed to actually achieve what DLR promised but
never really managed - genuine support for dynamic languages on .NET/JVM.

~~~
seanmcdirmid
The DLR had two parts: support for dynamic languages, and a strongly typed API
for generating expression trees at run time. The second component is the one
that survived and is fairly robust. It is quick, skipping the bytecode stage
completely, and is fully typed.

------
Areading314
Javascript for a compiler course? That seems like a very unusual choice. Good
luck to you!

~~~
chrisseaton
The great thing about compilers is they're conceptually pure functions - take
an array of characters as input and produce an array of bytes as output. You
can do that in _any_ general-purpose language - high level, low level, old,
new, whatever, you don't even need any libraries - it's all just numbers in
and numbers out! So yeah pick whatever you want. Algebraic and object-oriented
languages seem to work well in practice as the problems are data-structure-
intensive, but many other paradigms also work well. I really love compilers, I
think they're the perfect program.

~~~
JadeNB
> The great thing about compilers is they're conceptually pure functions -
> take an array of characters as input and produce an array of bytes as
> output.

While this is undoubtedly strictly true, it seems so high-level that the same
could be said of essentially any programming task, with I/O suitably modelled,
and so gets awfully close to "the C language is purely functional"
([http://conal.net/blog/posts/the-c-language-is-purely-
functio...](http://conal.net/blog/posts/the-c-language-is-purely-functional)).

~~~
chrisseaton
My friends who work on web services have to send out tens of requests to other
services to get anything done. So their request handlers aren’t pure
functions.

People think about compilers as being systems code but it’s the opposite. It’s
the web and business code that’s a nest of state and dependencies on systems.

Compilers are just numbers in numbers out.

