Why your CLI and configurator sucks
Tags: yaml, protolanguages, cli
Published: 2020-09-28 19:35:15

## Just a short one

Don't give me a CLI with 50 flags (lower- and uppercase meaning different stuff), don't give me a "simple config object, , so easy to change". Give me simple stuff in any platform independent language instead and I will be way better off.

> It is better to have a **real programming language you are unfamiliar with** than a **proto-programming language**, you _think_ is simple enough that unfamiliarity would not matter.

## The explanation
There are things called _programming languages_, that are standard enough to cover the cases you need and also flexible enough to cover the exceptions that you will need and never thought of.

You see, it starts with somebody seeing a pattern and deciding to build a "configurator object". 

> The moment it is built it robs you of the ability to deal with any exception you did not expect. And the moment you need your first _if_ or _import_ you know you should have used a programming language.

### The `kubernetes` example
You know them `yaml` files for `kubernetes`? 

Oh yes, so easy, just drop in some config stuff and you're done. A minute later you have 6 services and 6 `yaml` files. 

Oh, it's no longer manageable, I have copy-pasted the same stuff into 6 files! Let's have a _templating language_ (say `helm` over it), where I can import those common values and maybe I can omit some stuff from some of the stuff.

Now you end up with a really immature, undebuggable, brittle piece of _code_, a very under-developed, under-documented proto-programming language. And the promise of being so easy was a lie, you still need to learn it, you still need to figure out the gotchas.

I tell you, if the devs didn't have the budget to port their solution to the language you know, in _any modern programming language_ you can design an **API** so simple, that any programmer can deal with, with a bit of googling.

I'd rather start learning a bit of Go from scratch if I have a _debugger_, _code completion_, rich ecosystem of _examples_ and _training materials_, than learning one company's one time application's almost language.

When you need to briefly interact with someone else's platform, you actually don't need to learn the language in such depth you can write beautiful code... 

And **the time spent on a new language is _reusable_**, unlike the horrible-ass custom format that you came up with (CLIs are the same - sorry I don't want to bother if `-f` was `file` or `force`, or was it `-F`? _Please._) 

### A frontend example
Design and product came up with very similar screens: 
* a status card
* a list of advices what to do with that status 
* and an action button bringing you to some other screens

All of them had different, related texts though, but these were common among them.

The solution of the inexperienced architect was to throw a configurator object at it. It had 3 properties, you can guess what were in there and made sure the UI was generated based on these values.

Pretty smart, huh? Except it will break the moment product will need a second button, a link in advices, or not having advices at all, but some interactive slides... Things get customized when customers arrive with their real world problems...

Well there was something as well, that could have solved it, and it was _not being_ afraid of typing some React components and using polymorphism (i.e. knowing the type of the screen, have a map to the components and receiving the custom props it was needing)...

### Summary
So, think twice before you decide to go with a custom configuration object (maybe with a custom file format) and avoid creating a myriad of proto-languages when you could use battle-tested programming languages.