Live data from Hacker News

XML is the future

bitecode.dev

271–280 of 408 posts

Re: XML is the future

#271
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've watched this happen to so many coders in the land where people write code for companies that sell code . Personal advice: Write code for any other kind of company. They're much more resistant to fads. They don't care how you accomplish the new feature. They just want to get it done. And they certainly don't want to change their stack, ever , although in a new project you'll have more flexibility to pick the righ…

This is how you get stuck working with XML in 2023, as is the case with a woman I was just talking to the other day at my co-working space.

Re: XML is the future

#272

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…

> The insistence of the JSON-people to sabotage any kind of data validation is absurd to me. I don't understand what you mean by this. JSON supports schemas which can be used to validate input. It's not super advanced, but it's functional.

Having written a bunch of XML schemas and a bunch of JSON schemas at the same time while integrating multiple third party APIs, I can unreservedly say that JSON schema is awful.

It just about works, but it's horrible to write and horrible to maintain. What you can actually do with the validation is surprisingly limited in some forms and the fact that you have to write JSON to write the schema shows just how non-user-friendly JSON is.

A friend told me that she writes JSON schemas in YAML and then uses a build step to downgrade that to JSON for the actual validator. I wish I'd thought of that.

Re: XML is the future

#273

Earlier quoted context omitted.

> won't matter as much if they're about erasing your directories or killing your machine Those sort of attacks have tapered off though, right? Unless you're engaged in a specific feud, or have caught the ire of a social justice warrior, these days we're mostly looking at data exfiltration as the primary goal. That being said, there are a lot of ongoing feuds and active social justice warriors.

If we're talking about common, automated attacks, I think the game plan for the past few years has been to probe for systems vulnerable to RCE, install a crypto miner, join the server to a botnet and see how long it takes its owner to notice.

Aha, how could I forget the crypto mining botnets. I agree.

Re: XML is the future

#274
post #61

I worked a decade in public sector digitalisation in Denmark, where for some reason they still use a lot of SOAP and thus XML. I’m not so against XML in theory, but I hate it in practice. You’d have these completely over engineered solutions where you’d basically need to call a separate micro services for every “field” of anything. So if you wanted a name, a ssn, and, an address for a citizen you’d need to make sever…

I also have experience with the digital services of the Danish public sector. Trafikstyrelsen's SOAP service validates its own responses against an xsd. The data in the motor vehicle registry does not always conform to the xsd. In which case it returns a SOAP fault with the original response embedded as an escaped string in the details. So to actually get the response we need to parse it out of the SOAP fault...

Another piece of insanity is the e-TL (elektronisk tinglysning) SOAP service. Getting a non-java client generated is a PITA because of the use of the java Catalog feature. Even after hacking around it by setting up a local webserver and liberal abuse of the host file the generated .net WCF client needed manual fixes in a lot of places.

After doing that your calls still fails. It turns out the service wants the client to tell it which xsd to validate the request against (?!?). Also did I mention that the service expects every request to be signed, even when only reading information - it doesn't do anything to validate the signature though.

Re: XML is the future

#275
post #227

Some thoughts of why software is so hype prone and will likely remain so, if not accelerate * Its intrinsically easy to come up with new approaches. Thinking and writing software is a mental process, it is not limited by physical constraints and messy manufacturing. * The scope of use contexts in society exploded. You only needed the formula-translation language when you had five whitecoats in a research lab punching…

I think you left out the main factor which is that programmers are people and people subconsciously copy what other people are doing. We are herd animals. Also most people are not really good at judging novel things and are mainly influenced (subconsciously) by surface appearance and popularity.

I fully agree with that. I just focused on the more exaggerated ways this behavior shows up because programmers are the first tribe to really become fully online and interacting.

For software people it is sometimes easy to forget that in most other professional domains exchange of real information, detailed opinions etc. is still much more siloed and inaccesible. It does not happen out in the open. This has a dampening effect as copycat behavior spreads much slower.

Re: XML is the future

#276
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…

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.

Re: XML is the future

#277
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…

Be thankful there are still people willing to pay you for bullshit jobs.

Things will be tougher when management starts asking for real, measurable results.

Re: XML is the future

#278

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…

Maintaining old stuff is way more sensible than rewriting everything every few years. Companies tend to measure costs of maintenance vs rewrite. Edit: there's always a tradeoff but I wrote "every few years". Cobol is an odd example. Many banks have been going back to Cobol because they found it less expensive than the alternatives and are there is an influx of new graduates learning the language right now.

Up to a point, there's always a tradeoff and a turnover point; at the moment the old Cobol mainframes are one of those; the tradeoff is that there's a lot of institutional knowledge and essential processes in that code, but on the other it's harder to find competend staff that can - and want - to work with it.

Re: XML is the future

#279
On the specific point of XML being for everything it was not meant to be. It was a document format and the extensible part meant you could have an island of SVG in your XHTML and it was all still a well formed XML.

But some people ran away with the idea and extended it to uses that should have never been done in XML such as streaming.

Re: XML is the future

#280

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?

Not really. A "container" is usually just an instance of a Linux distribution, and the work involved in updating it is roughly the same.
Post reply on HN