Weeknotes 2022 W23:
Gardening leave

June 6​–​12, 2022
← previous weeknotes
next weeknotes →

I got put on gardening leave at the beginning of the week. Even though, as Basti said to me, I do not have a garden.

In the first morning after the weekend, I got pulled into a meeting with HR, where I was told that I’m being put on gardening leave effective immediately. It was strange and sad to not have the opportunity to talk to any of my teammates before my access was revoked.

(Sometimes I feel that it would be nice to have a physical garden, though I feel I wouldn’t have the time nor the expertise to deal with it properly.)

No gremlins this week either, but then again, I’ve barely touched my work laptop.

The gardening leave has given me a ton of spare time I did not plan for. My idea was to use a good chunk of my regular working hours to expand the implementation of my programming language. There is plenty to do there, and plenty of interesting problems to solve.

I’ve made some changes to the language:

I found the JVM a useful source of inspiration for what sort of bytecode to generate. Given a JVM .class file, pass it to javap -v (e.g. javap -v Test.class) and it’ll show the entirely contents of the class file. This helped in figuring out how to implementing array literals: I created a Test.java file containing int numbers = [100, 200, 300], compiled it and passed it to javap — and boom, the bytecode it spat out was the inspiration I needed.

My biggest struggle is forcing myself to not try to implement things efficiently right from the start. I obviously want the VM to be fast, but I’m sacrificing performance in some cases, because there are parts where I just don’t know how to implement them efficiently. I have lots to learn.

In part, the answer to writing an efficient VM is to pick a different implementation language. Crystal is fine for the compiler, but probably not for the VM. I’m not going to switch implementation languages at this point, though.

But there is one more issue.

I’m getting the impression that my idea for this programming language might not work out. I still think it’s a worthwhile goal to build a programming language with no globals and where dependencies are always explicitly passed in, but this will only work if pretty much the entire standard library, and all external libraries, end up being implemented in this language itself.

It’ll remain a good idea, for performance reasons, to implement new modules in a compiled host language — even if this VM ends up being very fast (which it won’t). The question, then, is how those compiled modules are made available. Making them available with import would be misleading, as those modules have access to the filesystem, the network, etc, defeating the purpose of the universe parameter on the main function. The alternative would be to make those modules available only through universe, but that’d end up being very annoying for any program of non-trivial size.

The only solution I can see to this problem is to build a language that compiles to native code, rather than bytecode. But… is this the road I want to go down?

Out of curiosity, I set up Twitch on my MacBook Pro to find out how feasible it is to stream some of my programming language development. Unfortunately, this MacBook Pro (2017, 3.1 GHz dual-core i5, 8 GB DDR3 RAM) is very much not up to the task: the stream was very choppy and the audio was unintelligible. If I want to stream anything, I need a new laptop.

Luckily, Apple announced new laptops at WWDC 2022, and the M2 MacBook Pro or even Air look like a significant upgrade. The MacBook Air with M2 chip, 16 GB of RAM and 512 GB storage will just under €2000 though (once it’s released), which is very expensive. Has Apple gotten even more overpriced?

Not much happening in terms of entertainment.