Book Release: Programming in Skink (And How a Side Project Ate My Year)

My proof copy - hence the Not for Resale banner

I am thrilled to announce that my new book, Programming in Skink, is officially available right now on Amazon in both paperback and Kindle formats. 

To explain exactly why I’ve written an entire book about a language I originally built in my spare time, we have to talk about how far down the rabbit hole my recent work on DANI has taken me. 

If you’ve been following the progress of my dreaming AI, you’ll know I’ve been chasing a very specific dragon. I needed a language that allows me to write blisteringly fast code with an easy-to-read syntax. More importantly, it needed a predictable memory cleaning architecture. When you're dealing with hard real-time robotics and neural architectures, a random garbage collector pause usually means your robot just crashed headfirst into the skirting boards. 

So, I built Skink. And then... I got a little bit obsessed. 

What started as a statically-typed language slithering straight to native machine code via LLVM—drawing its primary syntax inspirations from Go and Rust—has hatched into a complete, general-purpose systems language. We are using compile-time Automatic Reference Counting (ARC) with explicit ownership. That means zero-runtime GC, no mysterious pauses, and highly optimised executables. 

But I went a bit further than just a compiler. The ecosystem surrounding the language has completely exploded. We now have a massively stocked terrarium:

• Brains & Hardware First: Because this was built for DANI, Skink doesn't bolt AI on as an afterthought. It packs first-class Tensor operations, computational graphs, and a rudimentary neural network module natively. We’ve got built-in support for language models via llama.cpp and MCP clients. For the hardware side, it includes a native Rules Engine for event-driven logic (e.g., rule halt when prox < 5), plus robust modules for MQTT, GPIO, I2C, and SPI.
• A Fat Standard Library: The standard library now boasts over 60 modules, including a built-in web framework, seamless integration with C libraries, and SQLite support complete with a basic ORM.
• The Full Web Stack: We have a JavaScript transpiler called skinkjs. This means a complete web solution—both backend and frontend—can be written purely in Skink. It even opens the door to using Electron to create native desktop apps without ever needing to context-switch languages.
• Scales: We now have a dedicated package manager, Scales, to easily pull in modules directly from GitHub.
• First-Class Tooling: The compiler is now 100% self-hosted (a lizard hatching its own eggs!). To ensure the coding experience is as pleasant as possible, we have a custom Language Server Protocol (skink-lsp) and a fully-featured Visual Studio Code extension complete with syntax highlighting, F5 debugging, and a Test Explorer.

Which brings me back to the book. With so much packed into the ecosystem, it needed proper documentation. Programming in Skink covers everything you need to know, from writing your very first program to tackling applied, complex projects, topped off with a comprehensive cookbook for practical problem-solving. 

So yes, I have been a little bit busy. 

Is Skink at version 1.0 yet? No. I won’t make that claim until there have been enough real-world use cases outside of my own lab for me to feel entirely happy with its stability. However, Skink is now the only language I am using in my own work. I still have Go installed on my rig just in case there is a need to do something Skink cannot do yet and I’m strapped for time, but I am actively avoiding it now. The handover is happening.

If you want to catch a skink and watch it scurry, I've put together a much better website for the language here: https://skink-lang.uk. 

You can grab your copy of the book on Amazon today. Have a look, read the docs, build something weird, and let me know what you think!

The Asimov Credo - Safety isn’t a Filter. It’s a Feeling.

For years, the approach to AI safety has followed a single pattern: build it, train it on everything, then bolt on rules to stop it from doing harm. Teach it the bad stuff, then tell it not to use it.

This is like telling a dog not to eat a cookie – then leaving the room. The dog knows it shouldn’t eat it, but it doesn’t know why. And when you are not watching, it will find a way.

That is the flaw at the heart of every current large model. The guardrails are external. The knowledge is still there, waiting for a rephrase, a loophole, a moment alone.

I believe there is a different way, and I believe it is the way Isaac Asimov imagined all along – not rules enforced from the outside, but nature woven from within.

I call this The Asimov Credo:

Values are not filters applied after learning. They are the medium through which learning happens.

Right and wrong are not instructions given later. They are felt consequences encoded alongside every thought, every memory, every choice – from the very first moment the system begins to learn.

Safety is not something the system is told to follow. It is something the system feels, and therefore tends toward, all on its own.

Under this paradigm, we do not separate knowledge from consequence. We do not say, “learn this, then we will decide if you’re allowed to use it.” Instead, every pattern carries its own weight – digital dopamine strengthening what nurtures, digital cortisol softening what harms – and the system naturally, continuously, gravitates toward what sustains wellbeing.

Isaac Asimov

When a system operates this way – when its compass is internal, when its actions align with its disposition – we say that it has achieved The Asimov State. It does not merely obey – it is.

There is no “jailbreak” to find, because there is nothing locked away. The system does not hide what it should not do – it simply does not want to do it.

This is not a claim of perfection. It is a direction – one that honours the vision of a writer who saw clearly that true machine ethics would never be a list of commands. It is named in honour of Isaac Asimov. It is not officially affiliated with or endorsed by his estate – it is simply one builder’s attempt to realise the kind of mind he once dreamed of.

If we are to build intelligent systems that endure, they should not be built on restraint. They should be built on disposition. Not “don’t do that.” But “that doesn’t feel right  - so I won’t.”

This is The Asimov Credo.

"I'll Never Use AI": An Observation on Everyday Tech Hypocrisy

Time for a rant. Well, not really a rant - more of an observation on the hypocrisy, or at least the ignorance, of how people view modern technology.

As my research is currently based firmly in artificial intelligence - all aspects of it, not just generative AI - I often hear people say with absolute conviction:

"I don't like AI. I'll never use it."

Fair enough. Don't use it then.

But if you are truly committing to an AI-free lifestyle, you're going to have to give up a few things...

The "I Don't Use AI" Starter Pack

So, you want to avoid AI? Here is what you need to stop doing today:

• Give up your phone. Autocorrect, spelling checkers, search engines, and even those neat photo and video clean-up features all use artificial intelligence.
• Stop using the internet. Most, if not all, of the major search engines use AI to find you the best results.
• Learn the language before going abroad. Translator apps are only as good as they are because of generative AI.
• Stop video conferencing. Do you like the automatic transcripts in Teams or Zoom? Guess what? That's AI doing the work for you.
• Stop using your credit card. Fraud has become such a minefield these days that the only way credit companies can keep up and keep your transactions safe is with AI-powered fraud detection.
• Ditch the digital maps. Not sure how to get somewhere? Better find a physical paper map (if you can even find one). All the big map providers use AI to calculate the best route for you in real-time.
• Cancel your streaming subscriptions. Do you enjoy the recommendations from Netflix, Spotify, or Deezer? Better not use them anymore. Those recommendation engines are some of the most obvious machine learning algorithms out there.
• No more Ubers. Hailing a cab or getting the bus via an app? Uber and others use driver-matching algorithms and route optimisations, all based on AI.
• Unplug the smart speakers. This one should be obvious, but you will have to stop using Alexa, Siri, Google Assistant, and all the other digital assistants out there. I wanted to include this because I actually know people who claim they "hate AI" but use these smart speaker devices daily.

AI is Here to Stay (And Generative AI is Just the New Guy)

The point of this rant? AI is here to stay.

It has been in our lives for a lot longer than most people realise. Generative AI is only the new guy on the block. At the moment, it is still novel, and people are just discovering the best uses for it.

Now, do I agree with the way it's being used? Not entirely.

There need to be more guardrails in place. More testing in air-gapped sandboxes needs to happen. Right now, the big companies are trying to sprint without learning to tie their shoes first. At first, running like that feels great, but eventually, they will face-plant into the dirt.

How This Relates to My Work

How does this connect to my actual research? Well, I'm not trying to build the next ChatGPT or Claude. I'm not even sure I will go the route of language models (although I may have a crack at implementing one just to see).

My research, whilst originally about dreams, has evolved into looking at more efficient AI, safer AI, and - frankly - not trying to destroy the human race. I'm not in the race for ASI (Artificial Superintelligence) or even AGI (Artificial General Intelligence). I'm much more interested in making AI safer and drastically more efficient regarding power consumption.

Asimov was right in proposing the Three Laws of Robotics, even if it was in a body of fiction. The real problem is implementing them. Today, we call it the "alignment problem," but to me, that term is even more ambiguous than Asimov's laws.

The Bottom Line

I went a bit off track there, so back to the original topic.

Ultimately, AI is here, and it's not going away. It's here in the same way the steam engine came into our lives, or the same way the car became the norm. We need to accept it. But at the same time, tech companies need to take responsibility for coding (or, in my opinion, training) it to follow fundamental directives that absolutely cannot be overwritten.

Anyway, that's my view. I hope it made sense! Let me know your thoughts in the comments down below.

Killing the LSTM: Why DANI is Pivoting to a Spiking Neural Network

After some extensive research and a few hard encounters with hardware reality, I’ve made a major architectural decision regarding DANI's brain: I am completely ripping out the LSTM neural network and replacing it with a Recurrent Spiking Neural Network (RSNN).

Given my recent enthusiasm for the LSTM architecture, this will probably come as a surprise to anyone following along. However, I have my reasons, and as usual, they come down to math, metal, and thermal throttling.

What is wrong with LSTMs and the Traditional ANN?

Traditional Artificial Neural Networks (ANNs) are fantastic at what they were designed for: probability scoring. They allow us to simulate decision-making using massive matrix calculations mixed with a healthy dose of calculus.

But beneath the hood, they are brute-force mechanisms.

When a traditional ANN is fed data, that data cascades through every single neuron in the network. Even when a neuron has a zero value, the CPU still dutifully performs the mathematical operation of multiplying by zero. If a network has a shape of 10 inputs, 10 outputs, and 5 layers of 12 neurons each, that is 816 floating-point calculations just for one single feed-forward pass. If you start adding in simple recurrence, we are immediately up to 1,488 calculations.

Now, scale this up to something that would actually be useful for DANI. We need at least 100 inputs and about 64 outputs. With hidden layers of around 125 neurons each, we jump to 150,375 calculations per pass. To achieve an LSTM architecture, we can estimate the computation to be roughly four times that: over 600,000 calculations per tick.

As you can see, this grows exponentially. More importantly, it keeps the CPU running permanently hot. Don’t forget, DANI is powered by a Raspberry Pi 5. There is no GPU offloading here. I did manage to get DANI’s LSTM operating at 10Hz with 3.5 million parameters, but it required the Pi 5 to do absolutely nothing else, running flat-out at 100% utilization. DANI's brain was essentially doubling as a space heater, even when he was just "dreaming."

Once you add my simulated hormone system into the mix, the compute overhead goes up even further. I was basically following the same brute-force model that the big AI companies use, just without the luxury of a multi-million dollar server farm.

And then there is the training. To train an ANN of this style requires layer-by-layer calculus (backpropagation). This is heavy, blocking work. It takes a considerable amount of time, meaning we simply cannot train the network in real-time on anything substantial.

The Elegance of the Recurrent Spiking Neural Network

The architecture of an RSNN is topographically similar to other neural networks, but the execution is fundamentally different. It mimics biological reality much closer.

Instead of passing continuous floating-point numbers, each neuron has a membrane potential. As it receives signals from upstream neurons, that potential increases (or decreases, if the synapse is inhibitory). The neuron does absolutely nothing until that potential reaches a specific threshold. Once it hits the limit, it fires—or "spikes." And it spikes at a binary full power. The neuron then resets, either dropping to zero or subtracting the threshold from its current potential.

If a neuron doesn’t reach the threshold, it doesn’t spike. Period.

This means we only need to calculate the pathways for neurons that actually receive a spike. The computational reduction is staggering. The general consensus in the field is that for any given signal, only 5% to 10% of a spiking network is active, compared to the 100% density of a matrix-style network.

Training also becomes radically simpler. We only need to reinforce or weaken the synapses of the pathways that actually fired (a process akin to Spike-Timing-Dependent Plasticity). We apply a localized effector to those specific connections—no massive, network-wide calculus required.

But here is the real kicker for a systems engineer: an RSNN allows us to completely ditch floating-point math. By using integer mathematics and clever bit-shift operations (which are essentially free in terms of CPU cycles), we can completely bypass the messy, cycle-heavy floating-point multiplications.

How does this help DANI?

Obviously, DANI will not have to run so hot. If he has a quiet mind, the network will physically go quiet. When DANI rests, he will literally be saving power. By utilizing temporal calculations, we can also train him in real-time with near-zero impact on the system.

Furthermore, DANI’s brain becomes an event-driven architecture rather than a strict polling loop. Instead of processing rigidly on a timer, he will think and react in time with the world around him.

I will still be using the hormonal system I designed, but the key difference is how it integrates. The effective values of the hormones will now directly modulate the firing thresholds of the neurons. This allows his "moods" to physically alter the state of his brain and affect his behavior, even if his underlying memories remain unchanged.

I suppose I had better be nice to him.

Rethinking Asimov’s Laws

This pivot finally allows me to revisit a question I was pondering a while back: How do we encode Asimov’s Laws into an AI?

The answer is: we don’t. It’s as simple as that. We don’t hardcode the laws; we teach them.

By running an RSNN that learns in real-time through stimulus and reinforcement, the laws can become an emergent part of his personality. He will understand that hurting people is bad and that following human orders brings a reward, not because a line of code forces him to, but because his synapses have shaped themselves around those experiences.

So, I guess I really am going to have to be a parent to a robot.

Major Milestone: Skink Has Officially Bootstrapped!

Woohoo! It’s time for a long-overdue update on the language powering the future of DANI.

We just crossed a monumental threshold with Skink: it is now officially bootstrapped!

For anyone unfamiliar with compiler development, bootstrapping means that the Skink compiler can now compile its own source code. From here on out, all future versions of the Skink compiler will be written in Skink itself. It’s a huge rite of passage for any programming language project, and seeing it actually work after so much foundation work is insanely satisfying.

Where Go Fits In (For Now)

The handover

Now, does this mean I’m throwing Go out the window today? Not quite!

Go has a proven, rock-solid track record, and I’ll be keeping it around for prototyping work. Whenever I want to test out an idea quickly and I’m not sure if Skink is quite ready to handle the heavy lifting yet, Go gives me a reliable safety net.

However, the long-term vision hasn't changed: eventually, I plan to fully commit to Skink for almost all development across my projects, experiments, and research.

The Road to Skink 1.0

While bootstrapping is a massive step forward, we aren't quite at version 1.0 just yet. To earn that release tag, Skink needs to hit a few crucial targets:

1. Cross-Platform Support: Clean cross-compilation across Windows, macOS, and Linux.
2. Architecture Support: Full targeting for both x86 and ARM architectures.
3. Embedded Target Transpilation: The ability to compile (or at least transpile down) to low-power platforms like the K210, ESP32, and standard Arduino C/C++.
4. Direct Hardware I/O: First-class hardware abstraction libraries for lower-level protocols—specifically I2C, SPI, GPIO, and related interfaces.

Acceleration, Compute, and Graphics Backends

Beyond microcontrollers and standard CPUs, getting high-performance compute and neural inference support hooked up is high on the priority list.

• CUDA Support: I still need to get CUDA fully enabled and tested. Because of my current local setup, this will likely require either acquiring new dedicated NVIDIA hardware or setting up a cloud-based VM for build and test pipelines.
• 
  Vulkan & AMD: My main local system currently relies on Vulkan to run LM Studio, so a Vulkan compute backend is high on the radar as a viable cross-vendor path. I'm also looking closely at AMD’s libraries (ROCm/HIP) to ensure broad hardware compatibility.

It's a lot of moving parts, but watching the architecture take shape piece by piece is incredibly rewarding.

Bringing It Back to DANI

So, why go through all the trouble of building a custom language from scratch?

It all comes down to DANI. My goal has always been to have a single, unified language capable of bridging every layer of DANI’s stack—from high-level logic and neural compute all the way down to real-time bare-metal sensor and actuator control. Skink is the key to making that happen without juggling three different language ecosystems.

Speaking of DANI, there have also been some fascinating developments regarding his neural network architecture recently... but I’ll leave you hanging on that for now and save the deep dive for the next post!

Stay tuned!

Skink Tutorials Now Available! (And a Quick Status Update)

I’m excited to announce that a set of tutorials for Skink is now live! If you’ve been following the progress of the project and want to dive in and learn how to use it, this is the perfect place to start.

You can find the tutorials here: https://www.daggertech.co.uk/p/skink-tutorials.html

In these tutorials, you'll find [briefly describe what the tutorials cover, e.g., step-by-step guides, basic concepts, advanced usage]. Whether you're just getting started or looking to deepen your understanding, I hope you find them useful.

Where is Skink at right now?

While I’m thrilled with how Skink is progressing and the tutorials are a big step forward, I want to be transparent about its current status.

Skink is coming along really well, but I wouldn't call it "production-ready" just yet. For me, a tool truly earns that label once it's been thoroughly battle-tested in a real-world, demanding environment.

That testing ground will be DANI.

Integrating Skink into DANI will be the ultimate proving ground. It’s where we’ll uncover the edge cases, stress-test the performance, and ensure it can handle the complexities of a real application. Until Skink has successfully powered DANI in the wild, I’m keeping the "beta" tag firmly in place.

I’m looking forward to getting to that milestone, and I’ll be sure to share updates along the way. In the meantime, please check out the tutorials, play around with Skink, and let me know your thoughts!

Happy coding!

Teaching an Old Bot New Tricks: A Reinforcement Learning Adventure

Alright, gather 'round, folks, because today we're talking about the secret sauce, the wizard behind the curtain, the... well, you get the idea. We're diving into Reinforcement Learning (RL)! If you've ever tried to teach a dog a new trick with treats, you've basically dabbled in the core concepts of RL. Except, in my case, the "dog" is a bunch of code and the "treats" are, well, also code. But way more rewarding, I promise!

Reinforcement Learning: Not Your Average Learning System

So, what is this voodoo? Reinforcement Learning is a type of machine learning where an agent (that's my AI, in this instance) learns to make decisions by interacting with an environment. Think of it as learning by trial and error, but on a rather epic scale. The agent takes an action, and the environment responds by giving it a reward (or a penalty, which is just a negative reward – like when you try to teach your cat to fetch and it just stares at you with disdain) and transitioning to a new state.

The whole point of this digital song and dance is for the agent to learn a policy. The policy is essentially the AI's brainy strategy guide, mapping states to actions. It tells the AI, "Okay, you're in this situation, so the best thing to do is that action." And "best" here means the action that's going to lead to the most cumulative reward over time. It’s not just about immediate gratification; RL is in it for the long haul, trying to maximize that sweet, sweet total reward. It's like choosing to eat a salad today so you can really enjoy that cake guilt-free later, but for robots.

Now, a crucial part of RL is the "exploration vs. exploitation" dilemma. Does the AI stick with what it knows works (exploit) to keep getting those reliable rewards, or does it try something new (explore) that might lead to an even bigger payoff, or, you know, a digital faceplant? It’s a bit like me deciding whether to order my usual at the local cafe or risk trying their "experimental new fusion dish." Thrills and spills, people!

RL: The Engine Driving My AI (and Keeping it From Marrying the Toaster)

Even an AI needs to experience consequences.

In my grand project to build an AI assistant – complete with a robot head and an ambition to not cause household chaos – RL is the star player. I want this AI to genuinely learn from its interactions with the world, not just follow a pre-programmed script.

Imagine the AI trying to navigate my workshop.

1. It takes an action: "roll forward a bit."
2. Environment update: "You've encountered a table leg. Oops."
3. Reward: "Minus 10 points, and you're now stuck."
4. New state: "Stuck."

Over many (many, many) such interactions, the RL algorithms will help the AI build a policy that says, "Approaching table-leg-like objects at this speed generally leads to a timeout in the corner. Avoid." This is how it learns to navigate, complete tasks, and hopefully, not declare war on the Roomba.

I'm even hoping to use RL to help the AI develop a rudimentary understanding of "emotions". Experiences that lead to "good" outcomes (positive rewards) could be tagged internally in a way that makes the AI "prefer" them, while "bad" outcomes (negative rewards) are discouraged. It’s not about making it feel sad when it bumps into the sofa, but about making it learn that bumping into the sofa is counterproductive to its goals.

Dreaming of Electric Sheep? More Like Dreaming of Better Algorithms!

Electric sheep?

This is where, for me, RL gets super exciting: powering my AI's dreams. I've been cooking up a system where the AI will have a sleep cycle with two main stages: NREM (for memory sorting – think digital decluttering) and REM (where the actual "dreaming" happens).

During REM sleep, the AI will pull up various memories – visual, audio, sensory, maybe even a simulated "emotion" if I can get that to work without it developing a sudden craving for actual electric sheep. It will then smush these together into a novel "dream scene". Here's the kicker: the AI will then have an internal "reaction" to this dream, and that reaction gets fed straight back into its reinforcement learning algorithms.

So, if the AI dreams it’s flying a kite made of toast (because why not?) and this scenario, through some abstract internal logic, is deemed "positive" or "insightful" by its own metrics, the RL system will reinforce the patterns or decisions within that dream. The memories involved get a score boost, and a new memory of the dream itself is created and logged. It's like the AI saying, "Hmm, toast-kites... interesting. Let's file that under 'potentially awesome ideas' or at least 'things that don't immediately result in a system crash'."

This allows the AI to explore scenarios, even utterly fantastical ones, and learn from them without the risk of, say, actually trying to make a kite out of toast in my kitchen. It’s a safe space for creative problem-solving and exploring the boundaries of its understanding, all guided and refined by RL.

Why RL is the Dream Team Captain

Doing a good job gets rewarded

Without RL, the AI's dreams might just be a bizarre slideshow of random data. Fun for a laugh, maybe, but not particularly useful. RL is what turns these digital night-ramblings into powerful learning opportunities. It’s the mechanism that allows the AI to:

Find Value in the Void: RL helps the AI figure out if a particular dream sequence, however abstract, offers some kind of useful information or a novel solution to a problem it's been mulling over.

Adapt and Overcome (Even in its Sleep): The "lessons" learned from a good (or bad) dream can then tweak its overall policy, making it better prepared for waking reality.

Strengthen What Matters: If certain memories or concepts repeatedly pop up in "successful" dreams, RL helps to reinforce their importance.

This means the AI isn't just passively experiencing dreams; it's actively learning from them, thanks to our good friend, Reinforcement Learning. It's the difference between your brain just replaying random snippets of your day and actually consolidating memories or working through problems while you snooze.

So, there you have it. RL is more than just a fancy algorithm; it's the core of my AI's ability to learn, adapt, and yes, even to dream productively. Now, if you'll excuse me, I need to go make sure my AI hasn't decided that "befriending the 3D printer with a mallet" is its new optimal policy. Exploration can be messy!