A Nightmare called YML

I started working as a professional developer around year 2000.

At that time, XML was the last trend, everyone and his cousin was migrating legacy config files and data to use XML.

People was writing parsers to marshall and un-marshall XML into objects in-memory.

Java was much slower and verbose at the time, the RAM was very costly, and everyone wanted to migrate databases to a bunch of XML files, because it seemed like a cool thing to do.

Everyone wanted to query data with XQuery, make the fancy prints with XSLT and maybe validate with XSD for the fun of it.

Corba was a thing of the past, and now we could finally break our heads on WSDL and the S in SOAP that the legend says it stands for: Simple.

One hour of implementation and a team for six months performing painful XSD validations: a good standard for the industry.

If you wanted to look smart in job interviews, you just had to name a lot of things with J in it: EJB, J2EE, JDO, JDBC, JNDI!

In a few years, the revolution was about to happen, Spring project promised to get rid of all the mess in J2EE and costly application servers. The solution was simple: just type in a bunch of XML files, and you fulfill the enterprise specs without the intended application server.

Nowadays we're much more loose, a decade of Rest webservices have totally spoiled us: life is finally quite easy, we don't need so much head scratching on the backend: there is the frontend for that.

Just give them some Json response and let them complicate their lives with the latest coolest vulnerable Node module, and they will get back to you in a month of two.

Infrastructure as a code: if you ask me, a very good idea. Git is a gift from the gods, even more if you have been using CVS, SVN, PVCS or other monsters from the past. Only hearing the names scares the hell out of me!

The only problem I witness today is a scary proliferation of products based on YML.

If you ask me, YML has taken the bad enterprisey parts of XML, and joined them with the casual attitude of nowaday's API designers: code first, explain (maybe) someday. Provide some structure, but not too much.

And as bad as XML was - and still is - you can actually reformat it like you want. Validation is a pain, but it's not left to your human discernment of spaces vs tabs. You don't have to count the dashes and the spaces on each line to make some sense out of it: we had enough of strange syntaxes editing SGMLS DTDs (see: monsters as above) and just wanted few simple, machine-enforceable rules.

In a nutshell, the good part of XML is that it was never really meant for humans, while YML is supposed to be "helpful" and "friendly".

I don't know why, but this looks pretty much like a mistake, and in my mind the proper adjective seems rather: "hostile", and if I can convert it to Json instead, or anything else, I'd rather go for it.

I see that the line of thinking in YML could be considered similar to Markdown: comfortable to type, structured, easy to read, apart that Markdown structure is sound and mostly makes sense for a human, while still being parsable from code. On the other hand YML structure mostly sucks for a human, while it's quite brittle and fragile for parsers too.

I have to admit I've never incurred into the Norway problem, because YML files started to bite me so much earlier, and when copy-pasting around, I just assume I must have done something wrong, like adding an invisible space somewhere, then I have to start typing everything from scratch.

Put in perspective, I think that in a decade or so, and with an ever aging population of technologists, someone will eventually come up with a Manifesto that argues the true agility consists in avoiding stupid keyboard shortcuts and whitespace hacks.

I expect someone to come up with talks that illustrate to the wider public the Total Cost of Ownership of a code base relying on positional semantics that, given somewhere an extra whitespace, implodes on itself.

The links for this week:
https://kevwe.com/weekly/202243