Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

XML is the future

bitecode.dev

Post reply on HN
Print view View original

211–220 of 408 posts

Re: XML is the future

#211

Post by mythhabit »

vbezhenar wrote: post #176
preommr wrote: post #30

It's easy to just mark XML off as one of the many fads in tech given how many there are. But I think it's much more worthwile to dive into the particulars of why it failed. While they're all fads, some of them share commonalities that, in hindsight, I think we can say were major catylsts to their downfall. With XML, it failed because something like JSON was much simpler. Time and time again I see people saying that j…

IMO XML failed because of mismatch between programming language structures and storage format. JSON is perfect because it maps 1:1 to arrays and objects. XML does not. There were whole ORM projects to map XML to data structures. That's a fundamental issue and replacing XML was not that hard. My prediction is that SQL will fail too. There are infinite attempts to dethrone it. And the reason is the same: tabular data d…

SQL is a pretty decent language. Sure it could be improved and made more intuitive and maybe even simpler. Relational data maps directly to objects if you have halfway decent tooling. SQL is almost 50 years old now - it'll be here for a long time because it is actually useful paradigm that has not been outdone by other paradigms (so far).

Re: XML is the future

#212

Post by another2another »

bruce511 wrote: post #23
gnulinux wrote: 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…

>>when I started working in the industry, I realized that it's absolutely exhausting. It's been this way forever. For every level of the stack. When I started the physical hardware hadn't been settled (coax, ethernet, token ring etc.) Fortunately when I started we only got paid when we shipped. So we were motivated to ship, not be distracted by rewrites. We were also lucky that as a boot-strapped company we had no ma…

>(coax, ethernet, token ring etc.)

Well, some things did bring improvements, or new ways of thinking about existing problems, and some things really moved the state of the art. Taking your example of token ring -> coax (with terminators,eek!) -> ethernet is arguably a good progression (and now also wifi).

But there's also lots of churn in software and people solving the same problems in slightly different ways.

However ... this is also collateral damage from another improvement, imho - that is the ceding of control of the tech landscape from big companies (IBM, Oracle, Microsoft, Intel, Sun, Borland) to smaller open source clusters of people and VC funding. There was a time when nothing happened without some big tech company behind it, and everybody waited for (particularly MS) to bless things and provide library support, IDEs and tools.

Those days are over, but the result is a bazaar of nosql servers, messaging servers, languages and front-end JS frameworks.

Re: XML is the future

#213

Post by ExoticPearTree »

devjab wrote: 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…

Not in Denmark only. In some projects across the EU I only saw XML/SOAP used for the so called API access. I really do not understand the XML fetish still going on in 2020+.

Re: XML is the future

#214

Post by TeMPOraL »

shocks wrote: post #189
edejong wrote: post #179

Earlier quoted context omitted.

In the meantime, your PHP app had 40 major security flaws, no meaningful monitoring, a DB that wasn't backed up and major data consistency problems. Also, when your box's hdd crashed, you lost all those minor changes you had vim'ed over the years. But for the rest, yeah, all is fine.

If you forget about a PHP container for a few years it will /also/ have 40 new vulnerabilities. Actually, containers are worse because OS updates of core shared libraries do nothing. You have to rebuild every damn container. Setting up monitoring for your docker containers is also a whole thing. :) I think you’re taking my example a little too literally. My point is not that docker/k8s/whatever is bad; just that the…

I think what people are missing is that sure, code "rots", at the very least because of security patches. But since this all happens to everything simultaneously, the more distinct layers and support tools you have in your stack, the more often you have to deal with something breaking in a nontrivial way.

In short: the more moving parts you have, the less time you have between major malfunctions.

(Manufacturing and hardware world understands it well, which is a big part in why they like integrating things so much.)

So e.g. over in the backend-land where I live, it used to be that I had to occasionally update the compiler or one of the few third-party dependencies that I used. Today, I have many more libraries (to the point there's something to update for security reasons roughly once a month, on average), and on top of that, I have CI/CD introducing its own mess, Conan updates which occasionally get messed up, or make some existing recipes incompatible, CMake updates which are done unexpectedly and break stuff, now also Docker is adding more of its own problems, etc. So I have to deal with some kind of tooling breakage every other week now.

And always, always, when I think it's all finally OK and I can get on with my actual job, some forgotten or hidden component craps itself out of the blue. Like that time our git precommit hooks broke for me, because someone changed them in a way that doesn't work with my setup. And then me wasting a day on trying to fix it, eventually giving up and degrading my setup to unblock myself. Or another day where, for no apparent reason, some automation that made automated commits to some git repos started losing Change-ID headers in commit messages, making Gerrit very sad, leading to several people wasting a total of several person-days trying to fix it. Etc.

There's always something breaking, the frequency of such breakages seems to be increasing, and it's a major source of frustration for me in this job. Which is why I too am often thinking back to "good old days", and am increasingly in favor of keeping the amount of dependencies - both libraries and tooling - to a minimum.

Re: XML is the future

#215

Post by bad_login »

yarg wrote: post #166
throwaway744678 wrote: post #163

Earlier quoted context omitted.

Don't sweat it, it was a joke (turning your sample into LISP)

Sorry, I haven't spent any time with LISP. I do however want to write a dialect of it, though mostly for the sake of naming it 'Lithp'.

Here is the racket view of xml

https://docs.racket-lang.org/sxml/SXML.html

more examples: https://docs.racket-lang.org/sxml/ssax.html

and then you can manipulate your sxml with https://docs.racket-lang.org/reference/match.html

Re: XML is the future

#216

Post by nordsieck »

vbezhenar wrote: post #176
preommr wrote: post #30

It's easy to just mark XML off as one of the many fads in tech given how many there are. But I think it's much more worthwile to dive into the particulars of why it failed. While they're all fads, some of them share commonalities that, in hindsight, I think we can say were major catylsts to their downfall. With XML, it failed because something like JSON was much simpler. Time and time again I see people saying that j…

IMO XML failed because of mismatch between programming language structures and storage format. JSON is perfect because it maps 1:1 to arrays and objects. XML does not. There were whole ORM projects to map XML to data structures. That's a fundamental issue and replacing XML was not that hard. My prediction is that SQL will fail too. There are infinite attempts to dethrone it. And the reason is the same: tabular data d…

> My prediction is that SQL will fail too. There are infinite attempts to dethrone it. And the reason is the same: tabular data does not map well to our data structures.

I'm deeply skeptical.

The relational data model is fundamentally about correctly representing relationships between data. Whereas data structures are about efficiently using computer hardware to perform computation on that data.

I don't see either going away, because they're driven by fundamental needs.

Re: XML is the future

#217

Post by klabb3 »

isoprophlex wrote: post #108
chunkyks wrote: post #33

Time to link grug brain again! https://grugbrain.dev/

Thanks to chatGPT there's an infinite supply of Grug wisdom on this specific topic: Grug see tribe use XML for talk between cave wall. But XML talk too loud. XML say Hello . Why not just say Hello? JSON talk quiet. JSON just say "message": "Hello". Grug like quiet talk. Grug also see XML not consistent. Sometimes XML use attribute, sometimes use element. Make Grug confused. JSON always use key-value. Grug like consis…

It’s good in the shallow style but that’s not exactly why grug would prefer JSON. I think mostly it’s because fewer things can go wrong, and parsers are widely available and always works. Grug would also admit that JSON lacks features (like timestamps), but that the workarounds (number as unix timestamp) works just fine.

Re: XML is the future

#218

Post by s-lambert »

noduerme wrote: post #82
gostsamo wrote: post #59

Earlier quoted context omitted.

I work for a company which sells code and we are a counter example. We make gradual changes in the development stack and processes, every change needs a reason, and even though some changes are necessary, they will not be implemented soon. Some possible factors are that the company is not that big and we have a feature list to deliver. We are not VC, so we cannot afford to burn money. The devs churn is low, so we don…

Hah. That sounds like my dream job. A software company that's not controlled by VC, not burning money, actually shipping a product, and (presumably?) turning a profit... that's an actual unicorn these days...

Isn't this just normal business-to-business apps? They're mid-size companies that are everywhere.

Re: XML is the future

#219

Post by mrweasel »

shocks wrote: post #189
edejong wrote: post #179

Earlier quoted context omitted.

In the meantime, your PHP app had 40 major security flaws, no meaningful monitoring, a DB that wasn't backed up and major data consistency problems. Also, when your box's hdd crashed, you lost all those minor changes you had vim'ed over the years. But for the rest, yeah, all is fine.

If you forget about a PHP container for a few years it will /also/ have 40 new vulnerabilities. Actually, containers are worse because OS updates of core shared libraries do nothing. You have to rebuild every damn container. Setting up monitoring for your docker containers is also a whole thing. :) I think you’re taking my example a little too literally. My point is not that docker/k8s/whatever is bad; just that the…

> You have to rebuild every damn container.

I can say with great certainty: Almost no one rebuilds their damn container anywhere near as often as the the gray-beard in the basement updates the Debian packages on the the server that runs the container.

I had the debate with a client, we did monthly security update, unless something horrible happened. The client was rather upset that we didn't patch more frequently, like weekly or daily. My argumentation is that it doesn't really matter if the Linux kernel or bash is patched, when the only thing running is a container with a beta version of Tomcat that hasn't had security updates applied in three years.

Even worse are the people who just pull things from Docker Hub, with no plan as to how and when they'll pull newer versions. But fine, let's just keep running KeyCloak from 2017, and that old Postgresql image which the developer never configured to do backups, I'm sure it's fine.

Re: XML is the future

#220

Post by Pamar »

noduerme wrote: post #98
Pamar wrote: post #76

Earlier quoted context omitted.

This is all fine but... the rest of the world is not freezed. Let's say you are happily mantaining a stable, boring ERP app for your... cigarette lighters plant. Out of the blue, one of your main suppliers declares they will accept orders only through a REST interface starting next quarter. And that you can/must use it to track your orders, instead of sending an email to one of their employees. One week later, you ar…

Well, I can't tell you how many dozens of times I've had to learn some stupid company's API and integrate it into software just because a client decided to do business with them. That comes with the territory, and you set up whatever you need to make it work. When it happens, it's a sprint, and you migrate everything you need to. But that's very different than migrating it because you're bored or want to sell the cli…

Of course, but I was just trying to explain that sometimes you are forced to innovate due to external interfaces/dependencies.

And maybe these were introduced in other companies because their IT depts. are run by "fashion of the month", but whatever the reason, you now have a problem. And if your sw and your skillset has remained frozen in jade since the early 90s... this will be painful and probably require at least one false start before getting it to work reliably.

I have noted a tendency in people who work always on "very stable" technologies to go in crisis mode as soon they have to (for example) produce a file in XML or JSON format after 2 decades of CSVs... this unfortunately almost routinely ends in stuff which is very brittle ("XSD? you do not understand, we need to produce an XML, ... I dunno what an XSD is or has to do with this requirement - except that they both start with an X, maybe - so please do not make things unnecessarily complicated and just go back to coding, we were supposed to start testing one week ago.")

Post reply on HN