Stephen Molyneaux

It is extremely obvious at this point that the vast majority of apps will be replaced by personalised, one-to-one programs that a user’s AI assistant will simply build and maintain for them at will, exactly as they want, on the fly.

The inversion from apps to intelligence is inevitable, because no one ever wanted an app in the first place - they wanted their problem solved as cheaply, quickly and effectively as possible.

The SaaS apocalypse has barely begun. We are in the opening act.

— Rational Aussie (@rationalaussie)

This is not the way the world will work.

Apps are curated to suit particular workflows and can teach how to do something through its interface that a user wouldn’t even know they needed.

Apps provide a social/communication layer that personal software can’t provide.

Apps provide a common platform for teaching skills built on top of the app. In a new domain you can’t learn from any other users if you’re the only one.

Personal software is wonderful, but platforms, data, and social connections will still remain entrenched for years to come. YouTube, Gmail, and Google Maps won’t suddenly be replaced with personal software. WhatsApp, Facebook, and Instagram won’t disappear. Netflix and Disney+ aren’t threatened. A budding video editor won’t remake DaVinci Resolve before learning their craft. You’re not going to play your own knock-off Minecraft when you could be playing with friends.

When these are the majority of apps people spend their time with, it’s unreasonable to claim that it’s “extremely obvious” that personal software will take over. Personal software will grow alongside traditional software.

If you were in an art community before generative AI, you almost certainly hate it. Watching this anti-ai video from a YouTube channel I like inspired this thought:

Why hasn’t the programming community pushed back as hard as the art community?

Shimlang has gone through many iterations since it was first conceived. Originally it was meant to be an interpreter that was small enough to include directly include in a project repository for multiple platforms, and to be deployable as single file executables like Love2D.

While that was a neat concept to play around with, that motivation was fairly thin. I know that I’ve had issues with other projects relying on Ruby or Node or Perl for some tasks, especially if they required newer versions of those languages that weren’t readily available.

Conversely, most Linux distros will already have Python and I can easily write Python that doesn’t depend on third party libraries (eliminating venv issues for others) or newer features (Python 3.6).

That left my primary use-case for a custom language — gamedev.

For the longest time this blog was using tailwind v1 in all it’s bloated glory. Compressed on the wire, this CSS took 304.74 kB and a whopping 2.93 MB on disk! Since Tailwind v2, it’s typical configure it to only output the classes that are used, but that would drastically increase the complexity of generating the site which otherwise only depends on python and hugo.

What were my options?

• Keep the massive CSS file
• Move to a newer version of tailwind and complicate the site generation (hugo extended, node, npm, postcss, autoprefixer, tailwind config, postcss config)
• Manually extract the necessary classes
• Redesign the site

No need for that, LLM’s to the rescue!

Rust allows you to jump from high-level algorithms and data handling to low-level byte manipulations and optimizations. I’ve found it incredibly helpful to be able to shift between the two. You can start out with heap allocated Vec and HashMap and slowly migrated to more specialized and byte-optimized structures.

This flexibility is what made it practical to implement my scripting language in Rust.

I’ve previously blogged about the “Shimlang” language. This is not a continuation of that design. Instead, this page solidifies some of the internal implementation details of the programming language.

A large amount of virtual memory (4 GB) will be dedicated for the interpreter. All memory operations are done relative to the base address of this memory chunk. A dump of this memory should be sufficient to completely restore the state of a game written in the language. This includes loading state from some point in the past of a gameplay session to be able to easily reproduce errors and tweak behaviour.

To start working towards the design goals of Shimlang, the first goal is to create a “vertical slice” of a many of the interfaces that Shimlang will provide.

Shimlang is a new scripting language and interpreter that’s intended to be modern, lightweight, and easily distributed. But what does that mean, exactly?

There’s a niche of programming languages that I’m looking to fill. This is the first part of what will (hopefully) be a series of the journey of the development of my little scripting language called shimlang.

Here is a collection of recipes I’ve transcribed/tweaked since 2020. It follows the “Modernist Cuisine” recipe template I worked on mid-2021. The template ought to have it’s own blog post, but for now an outdated version of the script and template can be found in this GitHub Gist.

Calling Rust code in Lua is great for calling optimized routines, and leveraging libraries from the Rust ecosystem. Packing Rust code for consumption in Lua requires learning how to:

• Generate Rust bindings from C headers
• Generate dynamic libraries in Rust
• Creating Rust ↔ Lua interop code
• Load dynamic libraries in Lua

This post covers all the steps needed to wrap the Rust regex crate into a library loadable by the Lua-based LÖVE game framework.

Hugo is a flexible way to generate static sites. Many people reach for premade themes/templates, but some people (like me!) want to create their own. There’s a lot to learn about Hugo and it can be daunting to take it all in at once.

This post is a beginner’s checklist for learning Hugo. This picks up right after you’ve completed the Hugo Quick Start Guide.