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.
Top comments (0)