Tell HN: Generational Gap
So this week, I was teaching a new employee about the system. He is 30 years old and has been in the industry for six years now. At one point, I described an external tool that we use, which produces an XML file. Something felt off about his questions, and then a realization hit me:
"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.
This doesn't sound right.
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.
45 years old here with a Computer Science degree. I've mostly avoided having to deal with XML, thankfully. Despite having to deal with it on occasion, I'd say I barely know about it.
He's just one of today's lucky 10,000.
https://xkcd.com/1053/
[flagged]
Interesting.
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.
https://rachelbythebay.com/w/2020/11/26/magic/ lists a few of these magic numbers
XML has robust tooling. JSON is created and used haphazardly.
Right, because JSON makes a great ad-hoc data format. XML is a heavy duty format with very strict heavy duty tooling which can do things that JSON isn’t a great fit for (heavily nested, structurally complex, large, exactingly created, extremely formalized, etc.) Developers of a certain age were traumatized by having to work with XML that was the default choice for applications that JSON would have been a much better fit for: lightweight tasks with ad-hoc formats like simple configuration files, simple request data for async JavaScript, etc. They often had lax specifications with poorly considered nesting rules, improper namespace configuration, etc. Or, even worse, I had to regularly parse large amounts of XML handwritten in editors by nontechnical people following policies written by other nontechnical people that thought they were technical.
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.
My biggest issue with XML is trying to figure out if something is an attribute or a sub element. On the contrary, there are time when it would be nice for json to have attributes.
I think the only really happy path with XML is starting with an extremely rigid spec for extremely consistent data where you have official dtd releases if something changes, etc. I think if you’re trying to figure something structural out when you’re processing the data, you’ve already lost.
> ...traumatized by...
I think you meant to write "...paid well for..."
Some tools we don't get to choose. Part of any job.
That very much depends on the job. The job I had to process all that handwritten XML in was a library job.
"I envy him" - when I read at HN in comments when people discuss something I don't know, I envy them. I suspect that OP is also more about this (reading from his frustration), but "knowing something" doesn't always mean "have to work with something". Not knowing even at least vaguely that XML is something related to HTML is a flag of the lack of interest in the sphere you're working in
You assume too much. You have no idea what sphere I'm working in. we are so far removed from html that that it will make more sense to us to contribute to the OS/390 kernel if that was feasible
What’s DDE and its nearest relation?
Is there an ODBC driver for the DDE? ;-)
>JSON simplicity won
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.
It always seemed to me that most of the hate around XML was really misdirected hate for SOAP. XML (and particularly XSDs) I rather liked, but maybe I just never dove deep enough to feel the pain.
Some of it has to be because people know Lisp.
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.
I just don't buy that there were enough Lisp devs around for that to be a significant source of the hate.
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.
I'm the same age and I started with AJAX, with real XML. :)
Everybody knows real programmers use the XMLHttpRequest object directly.
Same here.
I've never understood the hate for XML. I'm not a pro, but I found xmlstarlet easy to pick up and use, while jq still frustrates me (a lot of escaping issues).
Oh man, in Java world it used to be all over the place. You had a pom.xml for your builds, and you had configs in XML, and your API requests in SOAP, and you had SAML auth, it was just so much verbosity. And of course, you needed schemas to keep all of this sane, which was basically one more thing to keep up to date.
It was a large cognitive load, I don't miss those days.
XML. Bah! That’s new fangled stuff.
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.
5 years ago I had a new employee fresh from a good CS grad program in the U.S. not have a clue what design patterns were in computer programming.
I've noticed a lack of familiarity with design patterns in junior employees as well, but I've attributed it to them not paying attention in class and/or forgetting about it. Are design patterns not part of the standard curriculum these days? I guess to some degree, the most successful patterns are already "baked in" into frameworks and even languages, so maybe they're not even worth mentioning as something noteworthy?
I have 15 yrs exp but I haven't used XML in last 6 years :)
(I used lot of S3 via aws cli but only saw XML in server response :D while debugging)
As a mentor is the security field I found curiosity is key - I have absolutely no problem someone having 0 clue about something but with a good foundation they need to kick into 5th gear.
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.