Fairy killers and prototypes

TL;DR: JS doesn’t have classes because it’s prototype based

People usually deal with weird patterns in languages they are learning by trying to bend them into the boundaries of something they are already familiar with. Every time someone says JS has classes a fairy dies :’(

In the class-based approach, the one people are usually more familiar with (Java, Python, Ruby anyone?), objects have, among other things, a state and a behaviour. state is all the data owned by the object, while behaviour identifies the methods you can call on the object.

To provide a blueprint for these objects we use a class and we call instances of the class those objects which conform to the definition.

So far, so good.. where’s the trick?

The trick is that JS belongs to a different family which makes uses of prototypes (it’s called prototype-based programming). In this case we have just one single object (we’re going to refer to it as BaseObject) which is the brick on which we’re gonna build our entire system. You can set properties on BaseObject, these properties are called slots. If we need a certain type of abstraction (where we would normally use classes), we clone (make an exact copy) of BaseObject, add the properties we need by slot manipulation et-voilà!

Ok wait, we now have our abstraction.. how do we define an object which makes use of it? You guessed it.. we clone the abstraction and set the slots we need to give it some state. This is the foundation on the top of which JS is built: Arrays, Function, Number, String.. it all comes from one single Object that was cloned and whose properties were altered.

As you may have noticed, while explaining prototype oriented programming, I haven’t referred once to the notion of class. This is because we just have one instance (BaseObject) and since all the work is done by cloning there are no blueprint definition. That, kids, is why JS has no classes.

VMs, architectures and snakes eating their tails

TL;DR: PyPy is insanely cool and you should go check it out

When this mad idea first came to my mind I thought it would be cool to create a compiler (which would have been awesome for some obvious reasons), but I’ve decided to stick to interpreters for this time mainly because for some reason I like them more and they’re more flexible (everything exists in runtime).
The next step was to decide how to structure inori and, at first, I kinda wanted to follow the path Lua chose a while ago (so basically a really really small C VM with easy embeddability) but after some digging I discovered PyPy.

So what is it exactly? First of all it’s a Python implementation written in RPython and it’s also a translation toolchain that makes it an ideal platform to implement VMs (and fast ones).

It basically works this way: RPython is a Python subset on which you can perform static analysis and thus translate it to multiple backends (currently C, JVM and CLI) on top of which the toolchain automatically adds a meta-tracing JIT compiler and a garbage collector (all for free, no strings attached!). As some of you may know, a tracing JIT is a compiler which traces the path your code follows, optimizes hot-loops (LOCs that are executed frequently) and compiles them to native code for later execution, but meta-tracing JIT? Yeah, it’s one of my favourite parts.

When you have an interpreter and you want to add a JIT compiler you make a lot of assumptions, based on the object model of your language and other things in order to make it blazing fast. These choices make it really hard to implement a platform that is general purpose and language independent, so how did these guys do it?

The trick is to consider how an interpreter works… it’s basically a GIGANTIC switch that loops as long as the program runs. This means that on the same input, your interpreter is going to choose the same path. This is exactly what PyPy’s toolchain exploits, as it doesn’t care about what your programming language actually is structured, as all it traces and optimizes, providing a few hints, is the code the interpreter executes while running your program (hence the name meta-tracing)! Obviously since the interpreter is written in a language already known (RPython) we can do all sort of optimizations and they’re totally transparent to the implementation of the language :D

If you’re interested you should go and check out topaz which is an awesomely written implementation of Ruby written in RPython and compiled to native code (it outperforms MRI by ~4x)

Some articles i really found enlightening
The Impact of Meta-Tracing on VM Design and Implementation
Fast Enough VMs in Fast Enough Time


~ yawnt


A New Hope

TL;DR: I’m doing a language because I wanna learn cool stuff o/

It’s been more than a year since I first discovered node.js and, after spending so much time on it, I’m looking for new challenges.

It’s not the first time I experience this post-language stall and I’ve usually solved it by picking up a new technology. This time I wanna try something different.

I’ve lately become interested in compilers and interpreters which opened my eyes on a branch of CS that I have found to be highly fascinating. So what’s next?
I usually tend to pick up a project when I have to learn something new so, after giving it some thought, the most logical choice seems to create a toy language that’s somewhat barely usable.

As you have probably figured out by the URI I’m gonna call it inori (祈り), which is a Japanese word meaning ‘prayer’ (although i’ve chosen this name because it’s the name of the female protagonist of an anime I was watching at the time)

This purpose of this blog is to document my journey as I learn new concepts, face problems, discuss the design and implementation of inori and whatever comes to my mind really.

Quick disclaimer: I’m a total noob in this field, so please bear any heresy I might say :D


~ yawnt

Related GIF: