My passion for writing programming languages began in the late 90s when I wanted to automate computer monitors to be able to be used as customisable lights in a similar way to how IoT lights are used now. I cobbled something together to get the task done. It was incredibly basic, but worked.
Ideas started to accumulate over time, and eventually it was time to begin working on Achel.
Table of contents
The early days
In 2001 I created a basic scripting language, and embedded it into our application at work to cope with rapidly changing on-site requirements that previously required ~1 hour of of extra travel to recompile, and a delay in delivery. With the added scriptability I was able to deliver & demo on-site changes within a few minutes.
At the time, this was inspired by Achel more than it guided it. But it did give me some room to learn from mistakes, which was useful later on.
A year earlier, I created my first version of Achel. It couldn’t do much, but it worked, and the dream was very much alive.
It had some interesting quirks:
- Execute each statement as-soon-as it had parsed enough of that statement.
- Scripting languages (eg bash) often do this. It’s great for a quick start up, but bad for stability of long running code while the source file is changing.
- In this particular case, it actually read the whole file in one go (it simply didn’t parse it all at once), so this wasn’t an issue.
- Possible to execute up to 2GB of code per file. This sounds crazy now, but had interesting implications.
- It’s unlikely that it will ever make sense for someone to write 2GB of source code in a single file.
- There was scope to compile from something else to this. At that point the 2GB limitation might make more sense.
- Computers of the time typically had around 64MB of RAM. So a 2GB limitation gave a lot of head room.
The brewing stage
There was a long gap while I researched and played with concepts, but nothing concrete.
During this time, I developed Achel-web which began with the same ideas but basically turned a web framework. I did some cool concepts like how the UI related to the database. But there are many great frameworks, and it didn’t seem worth investing time sticking with it.
The current version
In 2012, I created The current version of Achel. It originally began as mass, but it was growing so quickly that it made sense to separate it out into Achel, and Mass. Where Achel is the language, and Mass is the single source of truth about the hosts in your infrastructure, which got heavily integrated into work-flows at the company that I was working at.
While the first version of Achel would interpret code on the fly, this one essentially compiled to memory, and would perform execution after that was complete.
There were some interesting challenges along the way:
- Re-wrote the memory management to include variable scoping, meanwhile keeping the interpreter running well enough to run the unit-tests so that I could see my progress.
- Re-wrote the bootstrap & parsing to give >20x speed boost during startup on ARM environments.
- Automated the ability to include third party packages (Modules, Scripts, and Templates).
- I’ve written an auto-pilot using Achel.
Once interest in mass died down, Achel became my platform for:
- Experimenting and learning how different concepts work.
- Testing how ideas play-out in reality.
- Playing with performance optimisations.
Here is the video from which the title image came from.
It’s the moment when I got pipe and faucet functionality working.
The future of Achel
Something has to happen.
On one hand, a re-write would be nice:
- It’s very old code that has been refactored, and experimented with many times for well over a decade, and the wrinkles are showing.
- Some of my early design decisions are slowing development now, or leading to sub-optimal designs. If I re-write the code, I can start fresh.
- I could also switch technology choices.
- It would be much easier to develop the remaining features on fresh code.
On the other hand, it would be nice to make use of what I already have:
- I have a few projects that use Achel and significantly rely on how it works at the moment. If I re-write Achel, I’d either have to create a compatibility layer, or rewrite those as well.
- It will take less time to develop the remaining features on an existing code base than to wait for the replacement to be ready.
- When I look at everything I want to achieve over the coming years, a complete re-write of Achel is a huge time cost that will interfere with my other goals.
I keep thinking that I’ve come to a firm decision about the direction that I’m going to take it. And then I realise that I haven’t. I don’t have time to act on the decision at the moment, so it can wait. So for now, I’ll maintain it at a works-for-me level. And if I do re-write Achel, it’s likely that I’ll continue to do that in the medium-term to keep my other projects running.
And the remaining features?… I guess I’ll make a decision in 2024. I really want to get on with them, because some of them, I’ve yet to see elsewhere, and they are really cool.
In any case, this has been a lot of fun, and it’s still not done.
Where did that name come from?
The toilet.
No, seriously. I was in the bathroom, looking at the water levels on the washing machine, thinking about what to name the language, and started playing with “H” and “L”. So for a long time, it was literally pronounced like “H L”.
Then about 12 years later, I was working at a company that introduced a tool called “H Shell”, which regularly got slurred to sound similar to “H L”. So I changed the pronunciation to rhyming with “axle” to avoid confusion. This was important because we were using Achel there, and it wasn’t uncommon for both to be in neighbouring sentences.