Live data from Hacker News

XML is the future

bitecode.dev

321–330 of 408 posts

Re: XML is the future

#321

XML is very much misunderstood. The hype that surrounded it was for a good reason, because XML is somewhat unique as a concept. There was nothing like it and still isn’t. It is not a data format or something like that. It is a notation tool. Normally you invent some syntax and parse it to get what is called “abstract syntax tree” (AST). With XML you work directly with an AST. Parsing from text is convenient because y…

Yes, one of XML's killer feature is that it can model rich text documents as much as ASTs. There's a reason why HTML never ever became JSON-ML, or why LibreOffice uses XML rather than JSON to save files.

In a way, XML can be seen as a generalization of simpler formats such as markdown (for text) and JSON (for structured data). Yes, I'm oversymplifying it.

Re: XML is the future

#322
post #7

I've been working in the tech industry in the US for about 5 years. Ever since I knew myself I've been coding. From middle school to high school, given any problem, like Sudoku, or keeping up daily chores, my solution was Programming! Programming wasy homebase. Then I studied it in uni, thought I was kinda good at it, and loved it. But when I started working in the industry, I realized that it's absolutely exhausting…

I am in the exact opposite,but equally frustrating boat. In last 5 years, I have worked at 2 Faang and a large hedge fund and everywhere they had extremely outdated stack or undocumented in-house stack or outdated undocumented in-house stack. Already derecated dependencies were pinned years ago and management won't let you modernize anything since there "no business value in it" and we need to ship a feature instead…

Sounds like such a place could have really nice documentation.

Re: XML is the future

#323
post #303

Earlier quoted context omitted.

I think "XML" is way too broad to meaningful discuss anything. XML the data format is pretty great in its basic form. Not space-efficient, but unless you're dealing with bulk data, the inefficiencies don't matter unless you're googlescale or can't spare a millisecond. The format itself doesn't absolve you from the design work of your model; your ssn example is typical of the "CEO said we have to use XML now" rush-job…

> XML Webservices are easy and consuming them from a WSDL is easy. Maybe in theory, but I've never had a WSDL that was actually complete. In the end, it generated stubs of types and clients for me and I still had to do a lot of nonsense. The concept of a WSDL would be nice but in practice I've seen _so_ many people do them poorly and create a bad experience.

> Maybe in theory, but I've never had a WSDL that was actually complete. In the end, it generated stubs of types and clients for me and I still had to do a lot of nonsense. The concept of a WSDL would be nice but in practice I've seen _so_ many people do them poorly and create a bad experience.

In a previous life, I shipped many, many, many APIs that used consumed and/or delivered XML data. We'd ship WSDLs if asked, but it was far easier for customers and from a support perspective for us to use the WSDL to generate API clients ourselves and then add some of the necessary supporting bits like authentication. We'd ship these to customers and it made life easier for everyone, despite the overhead.

Re: XML is the future

#324

Earlier quoted context omitted.

news flash: You are working in exactly the same place.. it is just 5 years later :-) All that outdated technology you mention, was probably introduced as the newest-cant-live-without at some earlier time.

So how old does the tech need to be?

It doesn’t matter as long as it is consistent and maintained.

Re: XML is the future

#325

Earlier quoted context omitted.

I am in the exact opposite,but equally frustrating boat. In last 5 years, I have worked at 2 Faang and a large hedge fund and everywhere they had extremely outdated stack or undocumented in-house stack or outdated undocumented in-house stack. Already derecated dependencies were pinned years ago and management won't let you modernize anything since there "no business value in it" and we need to ship a feature instead…

It's a weird tradeoff between innovation vs reliability, investments vs cost, but also, staff retention & hiring. I think a lot of companies follow fads as a way to attract talent. It's not in their best interest to follow the fads or spend time rebuilding the same thing over and over, but otherwise they'd run out of competent staff and are left with low energy / "safe" developers.

Competent staff = magpie devs?

Re: XML is the future

#326

Earlier quoted context omitted.

news flash: You are working in exactly the same place.. it is just 5 years later :-) All that outdated technology you mention, was probably introduced as the newest-cant-live-without at some earlier time.

So how old does the tech need to be?

I’d say at least 5 years since it’s debut.

Long enough for the rough edges to be softened, to show that people are willing to maintain it, for detractors to have pointed out legitimate issues, for the tech to become stable.

I’d prefer 10 years personally, but I value stability more than most. I dislike revisiting problems I’ve already solved.

Re: XML is the future

#327

Earlier quoted context omitted.

I am in the exact opposite,but equally frustrating boat. In last 5 years, I have worked at 2 Faang and a large hedge fund and everywhere they had extremely outdated stack or undocumented in-house stack or outdated undocumented in-house stack. Already derecated dependencies were pinned years ago and management won't let you modernize anything since there "no business value in it" and we need to ship a feature instead…

really surprised faang management doesn't see the value in addressing technical debt.

Move fast and break things has downsides that get to be paid some years down the road.

Re: XML is the future

#328

Earlier quoted context omitted.

> In the meantime, your PHP app had 40 major security flaws I just did a "npx create-react-app text" and I got "74 vulnerabilities (69 moderate, 5 high)" 40 major security flaws in 10 years sounds almost like a bargain.

create-react-app has been discouraged to use for a couple of years now, not really sure if the React team is still supporting it.

April 2022 was the last maintenance release.

Out of curiosity, why is it discouraged?

I’m not really in the React world, but have been fixing up a Create React App for a client recently, so learned a bit more about it.

Re: XML is the future

#329
post #172

Earlier quoted context omitted.

To give another perspective, at my first job deploying meant sshing into production and execute a make script. It worked 98% of the time, and you'd be having fun the 2% else. It sure wasn't the state of the art, but wasn't something people would yell at you for. We needed windows machine because of corporate policy and remoted into a Solaris box to dev, as a vague replica of production. Fast forward to today, and we…

Here’s another perspective: A decade ago you could deploy an internal PHP app to a box and forget about it for a few years, then fix a minor bug by sshing in, viming a file, and hacking it a few times. These days, if you leave the app untouched for six months that 10 minute fix becomes 2 hours of fixing a broken docker build. :)

>then fix a minor bug by sshing in, viming a file, and hacking it a few times.

Yeah, screw version control! Who needs any record of the change you made? If you have to move the code or redeploy it somewhere because that server goes down or something else changes, _real_ 10x rockstar ninjas remember every change they've made for the last several years.

Re: XML is the future

#330

Earlier quoted context omitted.

> In the meantime, your PHP app had 40 major security flaws, no meaningful monitoring, How does Kubernetes, microservices and front end frameworks fix that? They don't. In fact, as someone who works at the more modern end of these things, I'd suspect that "no meaningful monitoring" probably correlates quite well with cloud era microservices thingies. But we can't blame the tools, that space is just younger and by nat…

> How does Kubernetes, microservices and front end frameworks fix that? Doesn't being in a container mean its much easier to rebuild it from zero and thus allowing security updates to be more regular?

IME, this is rarely true; hence “2hrs fixing docker build”.

It’s really difficult to pin everything. Even if you manage that, upstream resources change/move.

Post reply on HN