Working on a chat app/server and protocol builder to support it, in an attempt to use as little network as possible (e.g. dial-up should work fine).

It's heavily supported by Claude Code, but much fun.

https://superchat.win/

Actually not built on this yet I think, but I could switch over, haven't made anything more of it since it's still a bit rough around the edges, and I keep finding various issues during actual usage: https://binschema.net/

Cool! Isometric for the win :)

The trick is to have 3 terminals with Claude Code open at the same time. You won’t be able to follow more. Reviewing the stuff or plans written is harder than telling them to write it.

Yeah, completely understand that viewpoint. It’s bizarre how many people hate it. Everything I can do with LLM’s is amazing.

It works perfectly! You can become the president of the (debatably) most powerful nation on earth by employing it successfully.

Translation: Lets think about it before we do stupid shit.

Outcome: Fail to think about it, only do stupid shit.

When applied without thinking about why. Yes.

Except dependency injection. I really can’t imagine why you’d ever not use that. I suppose it’s possible to overuse, but you’d still have better code than without. Certainly more testable code.

Because code becomes harder to understand.

With direct dependencies, if you are trying to understand some code that calls some function and what it does exactly isn't completely obvious, you can press a button to go to it, understand it, and come back.

With dependency injection it depends on what is going to be inserted during runtime, so you can't.

If you can press a button to understand what is going on, "it’s possible to overuse" most definitely applies. Dependency injection, as the name implies, is for dealing with dependencies — things that you cannot observe until runtime.

Hence the benefit to testing; allowing you to inject a deterministic implementation while under test.

With dependency injection your interface always describes what your implementation can do. If you see the interface and you have to care what is going to happen when you use it you are doing it wrong.

Unless you mean just regular constructor parameters, dependency injection in the sense of a runtime dependency injection framework is the one thing I try to avoid like the plague.

That is called a "DI Container", and usually manages the objects and order of instantiation etc.

Dependency injection simply means to take objects as parameters, and not instantiate them themselves (which causes "Inversion of Control" also commonly mentioned when talking about DI). DI Containers just makes the managing of objects easier.

Avoiding it like a plague seems excessive, did you have a bad experience with them?

When Martin Fowler coined the term Dependency Injection [0], that was specifically for the context of container instrumentation. Merely passing service objects as constructor parameters is more akin to the Strategy pattern. At least in the Java world where it originated, “dependency injection” has always been about wiring application components and services together at runtime based on configuration, often directly injecting the dependencies into object fields via reflection, and not about statically compiled constructor invocations that happen to pass service objects.

[0] https://martinfowler.com/articles/injection.html

You think?

I think the “I maintained this thing for 12 years” weighs a lot heavier than the “and then I even went through the trouble of reimplementing it” before changing it to a license that is more open. Seriously…

I dunno, I’m inclined to think the WTFPL and MIT did more to help open source. And for a while during my youth there was indeed no distinction between publically accessible code and free and unencumbered code.

Inclined to think that why?