Live data from Hacker News

XML is the future

bitecode.dev

171–180 of 408 posts

Re: XML is the future

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

At the tax authority we could query that directly from a database. But yes, the public sector suffers from countless different systems that have accumulated over the years. It happens because everything has to go out to a public bid and throughout the times it has been considered anti competitive to built things in-house.

More than that, the vendor winning the bid will happily use the opportunity to latch itself to the flow of taxpayer money. That's a big reason you end up with XML hell - the systems are designed to make future interop impossible without going through the vendor.

In fact, wasn't Denmark a case study of that? I remember there was someone on HN a while ago, IIRC working in public service of some country in Europe, who posted stories about their constant fighting with a vendor who intentionally makes it very hard to have any kind of integration and data exchange between various administrative branches.

Re: XML is the future

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

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. :)

Re: XML is the future

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

This is a benefit (non-commercial) FOSS has over software authoring in commercial corporations. Developers get to call the shots, and usually, don't bend to such passing fads.

> I don't even know how I would do it.

Depends on the software you're writing of course, but the core would probably be some libraries with C (and maybe other language) bindings, some command-line executables, and anything else - above that.

Re: XML is the future

#174
The brutal truth is that the "pro-dev" is aggregating all these buzz words in the application you are destined to take over. It's not him that will maintain his academic overly enthusiastic code base. Once he has completed his task he will brush some documentation off his shoulder and condescendingly assume that everyone smart and capable shall understand the produce of his loins.

heed the buzz-words. simplify your solution and beware developers incapable of cooperating with the entire team. Predictability and long time consistency equals professionality.

Re: XML is the future

#175

Earlier quoted context omitted.

> Look I'm not even complaining. But it feels like I'm stuck in a Franz Kafka novel. We just keep changing and changing the same things again and again because that's the new way to do. Big distraction. Destroys your workflow. Forget about all the util scripts you wrote last 6 months being useless. Here's how I stay sane -- I focus on the changes. For the technologies that you noted, here are some good questions that…

I believe there's a spiraling pattern, where the same ideas reappear every N years but with slight internal or ecosystem changes. I'm not sure if we're running or circle of if there's a real slow progress.

I think it is mostly just adopting. To new hardware, new demands, new plattforms.

There is maybe some progress on a academic level, but I don't think we progress fast on the fundamental level, on how to write better code. There are slight improvements here and there, but it is mostly just different. And more complex. Or rather new tools are needed because everything gets more complicated (some say bloated).

That being said, the new thing that I am learning is general purpose GPU compute. That is quite new and useful (but hard). But it is an improvement.

Re: XML is the future

#176
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 does not map well to our data structures.

Dethroning SQL much harder, though. It'll take decades.

We introduced fundamental roadblocks into IT and river of time will either break those roadblocks or smooth them into shapes hardly recognizable (SQL + JSON, for example).

Re: XML is the future

#177
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 can imagine this is frustrating and have experienced people wanting to push the "latest trend". My usual way to approach this is to ask them to explain to me the _why_. Why is this new thing better? What specifically is it better at? How? What trade-offs does it make?

More often than not, they aren't able to properly articulate the why and the trade-offs involved. Sometimes they do fully understand the trade-offs and that leads to good discussions.

Re: XML is the future

#178
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. :)

As an admin of PHP apps at that time I can sincerely say screw you, you're lying. PHP apps breaking because new version of PHP shat on compatibility was pretty common, and weirdly enough got more common in newer versions.

You also had to keep unholy combo of php extensions (why that garbage is in app server and not app) and server config because the special little retard that designed the app decided he must do something different.

And forget about ever leaving apache, if it doesn't use some apache module to fix PHP/developer ineptitude it will at least have half of the request routing logic in .htaccess file.

Re: XML is the future

#179
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. :)

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.

Re: XML is the future

#180
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 agree that there is nothing inherently wrong with XML, the problem is with the way it is used. I have worked with great XML schemas, and terrible ones also. Also the XML APIs in the programming languages are a bit dated, and oftentimes a bit cumbersome to use. Yet the standard API to support not only DOM style, but streaming parsing is also a great thing, should you have to process several gigabytes large XML files…

> I agree that there is nothing inherently wrong with XML, the problem is with the way it is used.

Right, but the spec allows for so many different ways of using it, that you end up with lots of variations in how it's done.

I've mulled over these choices myself when trying to come up with a XSD spec, and I wish I could slap that idiot who wrote the last XSD spec around with a large trout (that idiot being past me).

While you can do a lot of weird things with JSON as well, the syntax is more restrictive and naturally leads to fewer variations.

Post reply on HN