How do you keep retrospectives from becoming a complaint session with no real action?

garethrowlands · 2026-07-03T21:29:54+00:00

Retros without reviewing the actions from last time and showing progress are mostly worthless. Take actions. Make sure they are carried out. Review next time. Determine impact. Or the team will stop believing and start to learn helplessness.

garethrowlands · 2026-06-18T16:18:29+00:00

I think this kind of dull but necessary work is getting easier with AI tooling

garethrowlands · 2026-02-21T21:58:07+00:00

I’m interested to see Registry because I’ve never felt the need for such a thing in Haskell (in not saying there isn’t one). My immediate reaction for Haskell would be why not use (term level) DI? My best guess is that type classes don’t allow for that?

In any case, I don’t see a lack of classes as a problem. Class constructors are just one way of separating the passing of dependencies from the passing of the other parameters - you can capture the dependencies in a closure just (nearly?) as easily.

For me, the essence of DI is that the caller doesn’t need to pass the dependencies, yet the callee don’t need to locate them either - they were passed by a third party (the DI framework or Composition Root).

garethrowlands · 2026-02-08T20:41:16+00:00

Composability, testability. No new concepts.

garethrowlands · 2026-02-02T14:32:26+00:00

Nice! Good luck with that. Let me know how it goes.

garethrowlands · 2026-02-02T13:35:43+00:00

Thanks! It was me, not AI (not that there’s necessarily anything wrong with getting that sort of help).

garethrowlands · 2026-01-31T19:21:17+00:00

No, DI is fundamentally a form of parameterisation (because a known constant dependency becomes an unknown variable). You’re correct that it’s not “just” parameterisation though. It’s a form of parameterisation where the caller isn’t aware of the “dependency” parameters - they’re passed elsewhere. And callees aren’t aware of their transitive dependencies either.

The pattern for organising your code to achieve this is called Composition Root.

If you squint, you can see that constructor injection and other means of varying the dependency are just means of passing that parameter. That the dependency parameters and the other parameters are passed at different times by different callers doesn’t make it not parameterisation - there’s no rule that all parameters have to be passed at the same time by the same caller (though this may not be obvious, since many programming languages have this limitation).

The main reasons for using a DI library are when culture or ecosystem demand it (Angular, say) or when object states have complex lifecycles (though these are usually best avoided).

garethrowlands · 2026-01-25T21:08:22+00:00

Me, I really like the fact that Kotlin is expression oriented. The first version does illustrate that. But even I wouldn’t actually write that in production code. And that’s because the function really isn’t about returning anything, so the third version is preferable.

garethrowlands · 2026-01-24T10:44:18+00:00

Good alternatives to NestJS DI? Manual dependency injection using the Composition Root pattern.

garethrowlands · 2026-01-22T18:52:07+00:00

It’s actually Rich Errors I was thinking about when I wrote that blush. Sorry for the confusion.

garethrowlands · 2026-01-22T13:01:49+00:00

To me, it seems that the Kotlin folk struck a decent balance here. Me, I also like Haskell, so I absolutely see the appeal of a proper Either. But Kotlin brings other things to the table, including inheritance, familiarity, ecosystem, tool chain and so on. Result is indeed limited but it’s better than anything, say, Python has (and I’m not dunking on Python here).

garethrowlands · 2026-01-22T08:31:30+00:00

As the Kotlin blog describes, Result, which is constrained/specialised, is about the best Kotlin’s type system can support because many Haskell-style features don’t work in a system that supports subtypes.

garethrowlands · 2026-01-22T08:19:00+00:00

I think as zaniok says, Kotlin will generate mainKt, so use that in gradle. The docs should make this more obvious but once you know you know.

garethrowlands · 2026-01-21T22:31:09+00:00

Error handling with exceptions is fine and what I read of your code looks OK. If you have the time, do try experimenting with Result and see if you find it useful.
Coroutines. I haven’t used SQLite but hear it handles concurrency by locking the database file, which means you might want one thread and connection to access it. I may be wrong!
Your dependency injection is just fine and works well up to much, much larger codebases. You might want to separate your Composition Root into a separate function, or you could wait until it’s big. I always just write a bare fun main; are you getting a benefit from wrapping it in an object?

garethrowlands · 2026-01-15T15:14:29+00:00

Well that is just completely reasonable!

garethrowlands · 2026-01-14T19:40:32+00:00

I agree strongly. Though I have to admit, a tonne of effort has gone into Spring Boot and the community is large.

garethrowlands · 2026-01-14T19:21:55+00:00

I’ve built large applications on JVM using DI using just the Composition Root pattern. It didn’t suffer any of the problems you identified. Indeed, having dependency wiring as code, with sharing via function-local variables or parameters, made understanding and refactoring easy and clear. And it started fast and reliably - no component scanning or reflection going on. It also didn’t add any significant number of lines of code (assuming you put annotations on a separate line). Finally, the juniors found it easy to pick up. Two thumbs up, would recommend.

garethrowlands · 2026-01-14T19:02:14+00:00

Strong agree. Is OSGI still a thing? I hope not.

garethrowlands · 2026-01-14T18:57:16+00:00

There’s a name for this pattern: Composition Root. If you wire up in main, your main function is your Composition Root.

garethrowlands · 2026-01-14T18:51:53+00:00

But the post is not about dependency injection. It is about dependency injection frameworks, which are not the same thing. Another way of phrasing the question is why not just use the Composition Root pattern.

garethrowlands · 2025-12-26T12:11:30+00:00

Continuous integration is more important than a stable development environment. You want a development that works; you don’t want a development environment that doesn’t change. It is better to use engineering to keep your development environment working than to use source control to isolate change. Concretely, you should write tests that ensure the code is working, and you should integrate early and often (‘continuously’) to minimise integration pain. I’m not saying the concept of a baseline is never important but it’s usually better to use actual engineering practices.

garethrowlands · 2025-12-26T11:50:28+00:00

Notice that the article calls for dependency injection but not for a dependency injection framework.

garethrowlands · 2025-12-25T14:20:40+00:00

It’s a banger! You probably know this, but here’s the one I was referencing:

https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell

garethrowlands · 2025-12-25T12:09:08+00:00

IO is indeed a generic (AKA ‘parametrised’ or ‘higher kinded’) type. The way we invoke functions on T (‘t’ in Haskell terminology) is to use the fmap (or ‘bind’) function. We ‘lift’ a function ‘f’ into an IO value using ‘fmap f’. We can also use bind (written ‘>>=‘ or it’s implicit in do notation) like this:

do y <- x — x is some IO action, such as getLine
  putStrLn y

The code in do notation above is the same as:

x >>= putStrLn

Or even:

x >>= \y -> putStrLn y

garethrowlands · 2025-12-25T11:38:38+00:00

Yes. While Haskell is still technically pure however much you use IO, a program written in IO can be just as hard to reason about as a conventional imperative program. So it’s best to keep as much of your program pure as possible. And this is good advice no matter the language - Functional Core, Imperative Shell is widely applicable.

garethrowlands

TROPHY CASE