CLI tools have always been broken

zebulun-arendsee.com

2 points·arendsee··4 comments

Seems cool, though it gives me xkcd 927 (Standards) energy

A standard would be a document specifying how a CLI should be written. Best practices, like a style guide stating that every CLI tool should have a --json-help option for machine readable usage.

Morloc is a compiler. The entire hand-written interface, the source of the inconsistency, disappears. It is not a standard anymore than gcc is a standard that determines how machine code is written.

Also standards have no teeth. If you compile a Morloc program, you don't have to assume the creator followed a convention, you have a guarantee from the compiler.

Every Morloc module can be compiled into a CLI with well-typed inputs and outputs, checked at runtime, with usage descriptions that follow from their types. They are also importable as modules into other Morloc languages, where the exported functions can natively composed. And they can be used as APIs serving HTTP/TCP/sockets or as MCPs. One typed module with many faces. This isn't a standard. It's a language, compiler and build ecosystem.

Anyway, Morloc is my baby and I always love talking about it, but this problem with CLIs is a more general issue that many are blind to. What other solutions are there? Do we really want to continue rely on writing wrappers around idiosyncratic interfaces?

FYI, here's the missing Morloc link: https://github.com/morloc-project/morloc

TLDR: CLI tools are fine for terminal interactive use, but problematic as building blocks in workflows and tooling ecosystems. The linked post describes the problem and proposes a new solution: strip our CLIs to their functional cores and generate the interfaces with the Morloc language compiler.

Reply on news.ycombinator.com