mickeyp

Watching AI play games is fun, but I can't wait for someone to crack having small LLMs in games to enrich them in useful and interesting ways.

Give dreamcoder.ai a whirl. I wrote it, and it works with your codex sub and any other inference, endpoint.

GUI in your browser. Tiling window manager.

One thing you can try is to build specialised subagents to help tease out more thinking when you're stuck with a model with limited reasoning budget as all the codex sub models seem to be (compared to API) --- but I have no firm, hard evidence of this so treat it as guesswork on my part.

Let me explain.

Creat a subagent that is told to just mull about a subject. This can be a simple file.

Have the agent expound on it with its own thoughts and additions.

Now rinse and repeat: give the file to another blank 'reasoning' subagent; then another; and so on.

This will eventually reach a point where they are unlikely to add more real value.

I believe they've locked down temperature and other sampling parameters so you cannot tweak these to get it to consider more unusual approaches.

The absolute best approach is a second model that is of a different family. Try Deepseek, GLM, Qwen, etc. and have it add its own thoughts. As a bonus, these models do not hide their reasoning. Put that in a file also.

If all you're going to do is chat with an AI, you don't need a 400B parameter MoE model.

13 TPS is unusable for agentic coding, because if decode is that slow, then prefill is absolutely abysmal, and agentic work live and die by prefill speeds.

Plug: Try dreamcoder.ai. It's not foss but it is opinionated.

Very different experience from all the other harnesses.

I have not tried Flash Next yet; but 27B is a cracking, little model. It is the first small model that I, as someone with 30 years of experience, can finally say is good enough to hand off small and mid-sized tasks and expect a pretty good result.

It is also a competent tool caller when quantised to NVFP4 for use with ninfer; my own harness only reports the occasional hiccup and it is only because the model will sometimes emit tool calling tokens in its reasoning loop.

Delphi would compile & link 2 MLOC of code on a crappy work laptop in 30 seconds to a minute. Incremental compiles were instant. So fast most developers never bothered learning the "go to next error" hotkey and just spammed F9 (compile & run) whenever they fixed a syntax error. It was that fast.

Trivial C interop - yes. Both pascal and cdecl style calling conventions.

Toolchain? Back then - yes. Today? Probably not; depends what you mean by it. It had perfect COM interop which mattered back then, and you could trivially link stuff if you wanted to. And people did.

Meh. The challenge is 4k+ at high display frequency that doesn't cost the same as a small boat. There are gazillions of KVM switches that do 1080. That's easy.

It's not like a lot of these small-time outfits used their own photography to begin with.

They'd pick a kebab from a menu of professionally made kebab pictures the printer has in stock. Or worse, they'd take pics of their own plated food with a dead-centre point flash in a dark cupboard or something and you end up with awful-looking food, no matter how good.

You don't have to apologise for anything. Your blog post, post-mortem, and detailed walked through is fantastic. This is a great use for AI.

I miss my Amiga 500 and all those days spent playing wonderful games so much. Thank you for the hit of nostalgia.

You're probably right. But they most likely know more about functional programming, logic programming (if they studied CS), and have some awareness of advanced concepts that generally weren't widely known when we were young.

I think it's just a shift in how development works: epicycles and all that. Luckily most OOP stuff they need to know can be taught quite quickly. And perhaps not knowing about GoF is a minor win for cyclomatic complexity in your codebase :-)

If you're a Typescript developer doing React you're probably not going to reach for classes, for example, as it's just not a common paradigm in most modern React/TS codebases.

But functional programming and OOP are intrinsically the same, but expressed using different primitives.

The thing that empowers first-class functions and closures (lexical binding) is the exact same method by which encapsulation works, even if the latter opts for heap vs stack. The fundamentals are the same.

Here's a simple one in Emacs Lisp:

    (defmacro send (object method &rest args)
      "Sends a METHOD to an OBJECT with ARGS."
      `(funcall ,object ',method ,@args))

    (defun make-animal (name)
      ;; 'hunger' is entirely private (encapsulated)
      (let ((hunger 5))
        ;; here's our lambda using lexical binding
        (lambda (method &rest args)
          (cond
           ((eq method 'get-name) name)
           ((eq method 'feed) 
            (setq hunger (max 0 (1- hunger)))
            "Yum!")
           (t (error "Animal does not understand: %s" method))))))

    (let ((good-boy (make-animal "Rex")))
      ;; "call" (via our macro) the "get-name" method; then feed. hunger does down 1.
      (send good-boy get-name)
      (send good-boy feed)
      ;; pretty-print the "object" good-boy
      (pp good-boy))

    ;; this is the state of it after the two calls.
    #[(method &rest args)
      ((cond ((eq method 'get-name) name)
             ((eq method 'feed) (setq hunger (max 0 (1- hunger))) "Yum!")
             (t (error "Animal does not understand: %s" method))))
      ((hunger . 4) (name . "Rex"))]

Oh, I agree. But there's value in people who set out to do things a certain way, even if that approach ends up not working well in the long term.

We're collectively shaking a lot of trees when we build frameworks, languages and tools. What works? What does not? What is the right level of abstraction? How much developer ergonomy do we want to sacrifice?

Sadly we only seem to know in hindsight what works well. But that is also how we learn and grow; it was just meant to be this way.

OOP is fine. Not using OOP is fine too if your architecture / design demands it.

What people forget -- much like the design patterns in the gang of four book -- is that languages and frameworks evolve.

A decorator pattern was a niche but useful abstraction in the 1990s. In Python today you can @decorate stuff just like that. It's evolution.

The same holds for OOP. Encapsulation and co-located methods with the encapsulating slots was an incredibly powerful upgrade over basic structs. Now most languages have first-class functions and lexical scoping so you can build your own encapsulation that way.

It's all good. Just use whatever fits best.

Happy to supply you with a beta key; give me a ping via email.

I'll happily hook you up with a key for you to play around with - feel free to drop me an e-mail.

Yeah I'll be working on it. Been busy on another product (see bio) which has taken up a year-plus of my time. Hence the lack of regular postings!

You typically won't see it installed at all because it's considered an intermediate artefact. You'll have to compile Emacs yourself from source to get it.

Thank you so much for the kind words :) I'm glad I could help you switch!

I recommend the tutorial (Help -> Tutorial) from the menu bar inside Emacs to get you started. Don't listen to people telling you to disable this or that. Use your mouse and arrow keys to get started. Don't worry about what other people are doing with their Emacs too much. Pick one thing you want to do with Emacs and focus purely on that (writing Go, taking notes in Org, etc.) and avoid a wholesale move unless you have infinite time and patience.

See also my reading guide: https://www.masteringemacs.org/reading-guide

My book is of course an option also, but it costs money.

My Combobulate page has suggested package versions but note I have not yet confirmed 100% compatibility with every single Emacs 31.1 major mode yet, though all tests for Combobulate do pass in 31

github.com/mickeynp/combobulate

AI is very good at Emacs Lisp - esp GPT. So you'll have an easier time around today!

But I do test things out, by virtue of often running the tip of master branch and submitting bug reports. But I cannot test every mention in the NEWS, so on that part you are right.

Deprecating :vc + :load-path without expressing why is a curious oversight. And "portability issues" is all fine and good, but why embed custom git clone + build grammar code in the treesit.el file if VC checkout portability is a concern? Surely VC is better at it than a bunch of brittle string concat code in treesit.el I do not understand why one part works and another supposedly does not.

The change is especially infuriating as for most of us it actually worked fine, and user-lisp directory does not solve the retrieval and setup problem, which `use-package` for all its flaws at least standardises.

Most users probably do care about discoverability of related packages, existing user or not. But that's in the eye of the beholder.

`package-review-policy` is security kabuki theatre. Someone who wants to harm an Emacs user can find many other ways of doing so with or without this flag.

Writing, supervising and training LLMs are now the purview of... even larger LLMs. Optimising CUDA kernels; hand-writing SIMD assembly to speed up data loading; tinkering with your particular brand of DRAM to see if there's anything to gain from optimising for its memory topology and NUMA --- these are now the job of AI.

There is very little reason for humans to get all too engrossed in this type of work now, today, with the hope of being good enough at it to command a high salary in 3-5 years. AI can already do it incredibly well, and they can do it persistently and doggedly 24 hours a day.

MUDs are such a wonderful way to introduce kids to "slow gaming", if one can call it that. I grew up with MUDs; they are a cherished memory of mine.

There's a lot of fun "lego-style" creativity to be had in designing rooms, mobs and coming up with grand area designs.

Cool idea.

Meier's about as connected to most of these things as Tony the tiger is to the actual production of cornflakes.

Or maybe, just maybe, these guys made great games because they were surrounded by great people. That QA guy who gave key insights into how tedious certain game mechanics were; the "bad executive" they all hated who reined in their unreachable goals; that one developer who applied his good game design senses despite not being a designated designer.

I find the notion of auteur "game developers" somewhat puzzling. I say that as someone who played, and still play, these games when they came out. Most of these guys haven't made great games in a long, long while. Obsidian's only decent game in a long while is Pentiment, and that for all intents was a passion project.

I always loved that purple/slate blue colour of WindowMaker/GNUStep/NeXTSTEP.

Model benchmarks are useful, to a point, but it is the long tail of things you do with the model that determines if it's good at a wide range of activities. Ant/OAI, to their credit, build their models -- even the small ones -- so they follow instructions and do tool calling well, without the system prompts confusing them. This is especially important for long-horizon tool calling.

So one open weight model might "meet" Opus or whatever on benchmarks, but then fail to follow a simple answer format and also tool call correctly. The models are whipped to within an inch of their lives to strictly adhere to their post training quality gates.

There's no pretension. It's mine.