---
layout: news
author: Torsten
---

Nothing significant has ever been achieved by a single person. Also software is clearly a group effort.

For me the time has come to pass the baton on. The journey has been fun and the results surprising
to say the least. But i did my sprint, with over 1000 hours/commits, and the air is out, energy gone.

Time for **you** to do your bit, or (more litkely) some other project making the next move.

## The hierarchy of languages

To recap: Traditionally VM's have been built as interpreters, because of what i called the semantic
gap in the last post. Meaning the language being compiled (say ruby) and the language used for
implementation (say c) are just too far apart, mentally.

The way to do it is the way c++ did it, by compiling **into** a lower language, c in c++'s case.
This leads to high demands on that lower language, which is why i created [soml](/soml/soml.html).

Now the **main rquirement** is really that it be dynamic, so that it is possible to create more code
at runtime. I threw in oo and multi-returns, but those things can be dealt with in other ways
as we see below.

Having [written the language](/2015/11/28/one-compiler-down-one-to-go.html) i really really
appreciate what other people have done. While i got it up and running (surprising in itself) it is
a loooong way off a usable system. So i took a step back to evaluate.

## Language alternatives

Looking around with my new "requirements" i found a couple of other alternatives. So the main idea
was not to add another language to the world, just so i can compile into it. Instead to use an
existing one. Go and Julia are good candidates i think. Go would be my choice, so i'll go
(pun intended) into a little detail.

### Dynamic

Now go is not per se a dynamic language, other than julia where it is baked in already. But other
than julia, go is self hosted, so the whole compiler, assembler, linker chain is available in go.
And once one has found a mapping from oo to go, in oo as well. So then it is "easy" , just compile
the oo into go, compile, link and run.

Maybe one needs to be a little more clever about replacing existing methods, but that's not too
difficult. One just writes the new on, and when done,
[CAS's](https://en.wikipedia.org/wiki/Compare-and-swap) the first instruction of the old
function to be a jump to the new. To save memory one can even rewrite the old one to be the new one
(reuse the memory), apart from the first jump off course. And then cas the patched jump to the
new first instruction. Ok, some footwork, but conceptually easy.

### OO in go

As Go is so insistent on pointing out, there is no oo in go. So how is that supposed to work when i
said one needs oo in the lower language. Well, go has all the pieces needed to make oo, compound
and basic types, interfaces and methods. It's just a matter of perception.

Objects map to structs off course and methods to methods (duh), good to go, yes? Not quite.
Classes do not map to types. What i had as a Layout maps to a type, and so each type must
carry it's class. For basic types this off course can't work and that brings us back to one of the
earliest things, that values are not objects, so that's ok.

A class is then the set of all types (structs) with the same names, but not same sub types
(potentially a lot, but computers are good at that). Julia shows nicely how then the method
matching has to be done on the type signature. I had written
[that down already](https://dancinglightning.gitbooks.io/the-object-machine/content/object/dynamic_types.html)
but found it has a name, multi-dispatch. Problem solved.

### No multi-return

Then the last problem is to solve is the lack of multi-return in any of those languages.
Multi-return was an idea that i hadn't actually implemented yet, but it was to allow several
return *addresses* (not values). There are two ways around that as far as i see.
The sort of more Julia way is to "box" the return value and check for type in the receiver.

In go, i would use multiple return values to achieve the same. So *every* (generated) oo function
would return a tuple of all possible types (int/float/ref) and a separate indicator which is the
value to be used. Off course that makes the generated functions ugly and bloated, but since they are
typed (and probably will include a lot of dead ends) optimisation should take care of that.

## Time is getting on

As i said, i feel i've done my bit here. 50 is very close and with it comes a surprising joy of
mowing or raking the lawn. It really needs someone younger to pull this off.

I also had some idea of using this project on pi or arduinos, because ruby just is not fast enough
on those. But [Artoo](http://artoo.io/), has got some brothers, one is [Gobot](http://gobot.io/),
and since they all play together nicely, they will do me fine. Ruby where possible, go where needed.

It seems the language scene has never been so active and so i'm sure someone will have the
same idea soon enough. We are after all **one species**, not nearly as individual as we like to think.
I'll be watching.