"Do you know what XML is?"
He didn't.
I have a few takeaways:
1. I'm old. 2. I envy him—I hate XML. 99% of the time, it actively sabotages my work. 3. JSON simplicity won.
That's it. No moral.
Having to parse a big pile of sloppy JSON data can inspire you to take an eeextra long lunch. Having to parse a big pile of sloppy XML using real XML tools inspires you take an extra long lunch browsing job openings that don’t contain the word XML.
I think you meant to write "...paid well for..."
Some tools we don't get to choose. Part of any job.
A 30 year old engineer with 6 years of industry experience should know what XML is.
This isn't a generational gap. I would argue that in a large sample of other 30 year old engineers with 6 years of experience that most of them would know what XML is.
Something else is at play here.
When XML hit the fan, it was the first time some of our Lisp-ignorant colleagues got a taste of notation for structured data.
But what a disappointing flop: basically just a recursively chopped-up chararacter string, with no notion of type whatsoever, and a huge amount of verbiage
No arrays or lists, no distinction between numeric and textual data. <foo>0xff</foo> might come out as 255 in one application or garbage in another.
In XML-land, you see ad-hoc notations within XML that are not part of it, like <temperatures>12.3, 13.7, 13.1, 12.9</temperatures>.
When people wrapped their heads around XML, though, it did become a tad easier to explain Lisp as being structured data (like XML) that represents code.
Besides, Json has plenty of those issues and doesn't garner a fraction of the distaste.
On the other hand SOAP and the tooling around it, particularly the tooling in the Java world which was a hot tech at that time, sucked - and so far as I could see a lot of devs didn't really draw a distinction between XML and SOAP.
Ok, actually SOAP probably didn't suck per se - but it was a wildly inappropriate tech for a lot of the problem spaces it was inflicted upon.
Where I worked, a critical financial process kept on aborting flagging value "-2147483648" as bad. Unknown to me, 2 groups, including the people I work with, were baffled for at least a week.
In a staff meeting (via on-line) someone brought it up. I said that value has a meaning, I will check and let you know. After a quick check I told them the data being processed had a value that was too large. The end result the data type was changed and all went well. This happened on a packaged ERP system the company was using.
I am sure there will be many more of these little things that people these days takes for granted.
It was a large cognitive load, I don't miss those days.
I'm in my mid-30s and work with 20-somethings who insist that YAML is even simpler. I hope you turn out to be right because after a couple of years of staring at Kubernetes manifests I still don't agree with them.
Back in the day, we’d find ways to redefine packed fields in EBCDIC flat files to save a couple of bytes. Kids these days have no idea how many turtles are under the one their feet are upon.
(I used lot of S3 via aws cli but only saw XML in server response :D while debugging)
Few are able to do it in a reasonable amount of time - During these situations the ressource ain't the problem - it's the person who took them in that didn't make the right choice...
But yeah I'm with you 100% - having no clue about XML is kinda of scary tbh.
