More Packages Than The Mailman Can Handle

You would have thought that once I finished writing the Programming in Skink book and got the self-hosted compiler bootstrapped, I could finally step back and get straight to work on DANI.

You would have thought...

Turns out my neurodivergent brain had entirely different plans. The moment I stepped back, a small voice whispered that the language needed more. More tooling, more ecosystem capability, and a proper set of modules so I wouldn’t end up reinventing the wheel mid-build on a robot brain.

So, naturally, I put the robot on pause for a moment and went on a massive module-authoring spree. Here is what just landed in the ecosystem:

Database & Storage Stack

• skink-dbx — The underlying shared database-driver core. Handles connection vtables, DSN parsing, buffered/TLS connections, SCRAM authentication, value models, and connection pooling.

• skink-postgres — Pure-Skink PostgreSQL driver implementing the v3 wire protocol (cleartext/MD5/SCRAM-SHA-256 auth, simple + extended queries, TLS) as a dbx adapter.

• skink-mysql — Pure-Skink MySQL/MariaDB driver handling wire packets, mysql_native_password + caching_sha2_password, COM_QUERY, prepared statements, and TLS.

• skink-mssql — Pure-Skink TDS 7.x driver for Microsoft SQL Server (PRELOGIN, LOGIN7, SQLBatch, sp_executesql, token streams, transaction control).

• skink-mongo — Pure-Skink BSON codec + OP_MSG wire protocol for MongoDB, featuring SCRAM-SHA-1/256 auth and cursor-based CRUD operations.

• skink-redis — Redis client supporting RESP2/RESP3 wire codecs, typed commands, pipelining, pub/sub, and TLS (rediss://).

• skink-tegu — A dialect-aware, database-agnostic ORM. Unlike the minimal SQLite-only ORM currently sitting in std/db, Tegu provides struct-to-table mapping, joins, eager relations, migrations, and transactions over any skink-dbx driver.

Web & Network Architecture

• skink-zilla — A Fiber-inspired web framework built on top of std/web. Handles app context, routing groups, JWT, sessions, RBAC authorization, rate limiting, CORS, multipart uploads, and WebSockets.

Audio, Vision & Intelligence

• skink-vox — The baseline NLP module for natural language processing in Skink.

• skink-stt — Speech-to-Text module with a pluggable provider interface. Supports OpenAI-compatible REST transcription endpoints alongside local whisper.cpp and generic subprocess pipes.

• skink-tts — Text-to-Speech engine interface with OpenAI-compatible REST output alongside espeak, piper, and say subprocess execution.

• skink-audio — Raw PCM/WAV processing unit: DSP (gain, mixing, audio filters, resampling), FFT spectrum analysis, synth oscillators + ADSR envelopes, and native subprocess audio playback (aplay, paplay, ffplay).

• skink-cv — Computer vision core written in pure Skink (PNG/BMP/PPM codecs, resize/crop/flip, spatial convolutions, Sobel edge extraction, adaptive thresholding, histogram equalization, connected components, Harris corner detection) with an optional OpenCV C-backend.

UI, Desktop & Game Engines

• skink-game — A 2D game toolkit featuring an entity-component engine core, fixed-timestep loop, custom vector math, an ANSI terminal backend for CLI games, and an optional SDL2 backend. (Purely a "what-if" scratchpad evening project, but ridiculously fun).

• skink-gnome — Direct GNOME/GTK 4 desktop integration without a single line of C shim code. Exposes native GTK 4 widgets (windows, header bars, entries, menus, GActions, GLib main loop) and libadwaita elements (toast overlays, banners, preference rows, dialogs, dark mode toggling).

• skink-nest — Centralized configuration management for Skink applications.

Expanding Beyond standard library Constraints

While std covers basic requirements, these modules supercharge the developer experience where standard implementations hit a wall.

For instance, skink-zilla builds on top of std/web to offer a fast, ergonomic microservices and API engine inspired by Go's gofiber.

skink-tegu completely replaces the basic SQLite-only ORM in std/db. By talking directly through skink-dbx, Tegu gives Skink full structural querying, migrations, and complex multi-table joins across Postgres, MySQL, SQL Server, and SQLite.

And then there is skink-gnome. The early UI attempt in std/ui was... well, frankly terrible. skink-gnome fixes that by letting me build proper native Linux desktop applications using GTK 4 and Libadwaita. I might eventually construct an abstraction layer to target KDE, macOS, or Windows natively, but I run GNOME—so GNOME gets first-class treatment.

Native ARM64 & The Road to 1.0

The entire reason Skink exists in the first place is to drive my synthetic cognition research with DANI. But that presented an immediate architectural hurdle: DANI's primary brain is an 8GB Raspberry Pi 5.

To fix that, Skink now officially builds natively for ARM64 alongside x86-64. You don't need to specify architecture flags or manually cross-compile—the installation script over at skink-lang.uk automatically detects your OS host and system architecture to fetch the right pre-compiled binary and system dependencies.

Lastly, I've started drafting the next book: Cooking with  Skink. Where the first book established the core language mechanics, this one is structured around real-world application recipes. If all goes to plan, it will form the foundation for an entire series covering database architecture, web services, and native desktop app development in Skink.

Skink hasn't hit version 1.0 yet—I won't tag a formal release until the language is battle-tested across several production-grade projects. But if I can manage to stop tweaking the compiler long enough to actually build things with it, 1.0 shouldn't be far off.

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!