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.