mickeyp

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.

I'm glad they're doing this also and that more people are adopting it. Event sourcing [0] is the right way to represent informaiton like tool calls, user interactions, etc. --- it makes it easy to fork conversations and maintain a cohesive conversation stream and stable message history that does not break the cache.

[0] https://www.dreamcoder.ai -> scroll down to the event graph.

That is precisely how the dreamcoder [0] ai agent I built also works.

It has an event sourced architecture in SQLite and it resolves queries using recursive CTEs (and sneaky projections to speed things up) to deliver exactly that. Identical, stable message chains to AI and complete introspection.

Bonus points include a constraint-satisfaction solver for the tiling window manager so windows never shrink too small to read. And many other keyboard-friendly features.

[0] https://www.dreamcoder.ai/ [1] https://www.dreamcoder.ai/assets/graph.webp

This is one of the things Combobulate [0] tries to solve by using the output of tree-sitter. Simple breadcrumbs are easy enough to do (your cursor has a clear parental lineage) but much harder to do if you want to retain semantic things, or do interesting things with (say) sibling nodes.

You can see the treeview it generates in the GIFs in the link below

[0] https://github.com/mickeynp/combobulate

I love RSS but what I love more than RSS are people who blog about stuff: high concept stuff, day-to-day stuff and just what they did yesterday.

I wish people would blog more like in the old days.

I think it should look like this: https://www.dreamcoder.ai/

A smart, tiling window manager with workspaces and a great tool harness. An everything app, if you may; bring the terminals, code reviews, etc. into the tool itself, and make it high fidelity: no blocky terminals for the app itself.

Yeah but my idea was more about mobiles handing out quests or answering simple questions maybe about what they do. the dungeon gpt thing was a bit more organic.

I miss MUDs. My old MUD went through a rename, a fork, and what have you --- but it's limping on, though with few playing it. The cost of hosting these things are so cheap today that you can just let it sit and mind its own business.

Back in the 90s you needed a permanent internet connection (rare!) and fast enough to handle all the usually uncompressed text, so it had to be a - shocker - T1 or better. Then you needed a server.

My old MUD has a discord; turns out a lot of the people I knew 25 years ago were there and remembered the my nick if not a little about myself back then. That was a fun nostalgia trip.

MUDs will eventually see a resurgence, I think. Mobiles with little language models to give flavour text and quests, plus a little tool calling language behind it to make it happen? I can see it working; in fact, I might just myself...

That's lovely. I look forward to seeing your autoconf and GNU Make replacement in MAUDE SYSTEM.

So you don't like using programming languages as config languages, so you:

1. Use a declarative-style format for config, which is fine, I guess; 2. ... and when that inevitably fails, you... use a programming language?

Some people -- not all, but some -- may prefer to skip the first step and go straight for the second option. Particularly if it's a complex thing indeed like a build system and not, y'know, configuring your blog.