I hate it :-P

Seriously, I don't think writing all those annotations is any less effort than composing opts or commands.

But YMMV. Also, thanks for the code, as I'm looking to work on some macros and may take inspiration from it :)

github.com/indoorvivant...

Looks weird at first, but you're working with just values that are composable, it's intuitive for complicated validations or multiple commands with sub-commands, defined in multiple subprojects. This instead of a brittle or limiting macro-based or OOP-based DSL (e.g., Rust's Clap or Kotlin's Clikt).

Those are the applicative types. In Scala, we solve that with syntax for tuples, e.g., `parMapN`, but it's uglier.

You can improve it by telling where it went wrong, so by having a dialog. But it's so freaking frustrating that you may as well do the job yourself – works better if there are some tests defined, at least it can converge on a solution by bumping into walls.

alexn.org/blog/2025/10...

A type-class instance is just a dictionary of functions, indeed, and this is a common tactic, even in Haskell, because in Haskell type-class instances aren't just values, and that can be limiting.

But the super-power of type-classes is that you can derive their instances.

Type-classes are generic interfaces. You're referring to OOP subtyping, which is powerful, and I can ask the same question in reverse (i.e., why do you need OOP, when you could …).

Type-classes work better w/ functions + ideology (note that I love OOP, too):

alexn.org/blog/2022/05...

Oh wow, I just had the same opinion:

alexn.org/blog/2025/10...

Much of that thought leadership is obviously LLM-generated