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

311–320 of 408 posts

Re: XML is the future

#311

Post by commandlinefan »

edejong wrote: post #179
shocks wrote: post #172

Earlier quoted context omitted.

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.

I think the takeaway here is: programming is hard, and we deserve more money.

Re: XML is the future

#312

Post by jerf »

andrewflnr wrote: post #58
hardwaresofton wrote: post #17

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 would phrase almost the same idea from the opposite angle: focus on the fundamentals that never change, and view the trends in terms of how they relate to those fundamentals. But also, those are some pretty odd comparisons. For sure Ansible and Terraform aren't directly comparable. If anything they're complementary. Terraform provisions machines (and also infra, etc), and Ansible configures provisioned machines.

A great example of the narcissism of small differences [1]. Locally in the space of management tools, terraform and ansible are very different beasts, in that they can hardly even manage the same tasks. Globally, if you plot all software in the world on some big graph, they are right next to each other and indistinguishable on a plot that has "video games" and "databases" and "routing software" and "spacecraft code", etc.

[1]: https://en.wikipedia.org/wiki/Narcissism_of_small_difference...

Re: XML is the future

#313

Post by 0x445442 »

Devasta wrote: post #224
yread wrote: post #125

Earlier quoted context omitted.

I still can't believe that we (as a profession) kinda traded away schemas, namespaces, comments, sanity and well defined dates basically because some kids were too cool to write out closing tags. My early 20s teammate now closes blocks with } //for in his JS. That's even worse than XML!

Its incredible to look back at the arguments against XML and XHTML and realise just how poorly thought out they were. Now, we've wasted the past few decades re-implementing everything that XML provided, but worse, and will spend the next few decades doing that all over again.

99% of the arguments in this industry are straw men or false equivalencies back by nothing but assertions and gut feel. There is little engineering in the field.

Re: XML is the future

#314

Post by sacado2 »

xnorswap wrote: post #223
fragmede wrote: post #167

Earlier quoted context omitted.

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

JSON schema aren't part of the JSON definition, and JSON itself suffers from lacking good handling of types such as dates. JSON itself succeeds as a way to represent JavaScript objects but it is far less useful than XML for representing custom types, which are easily enforced through XML Schema. JSON Schema adds some of this, but it isn't a standard (yet).

XML schemas aren't part of the XML definition either, although, granted, they're an official recommendation too.

Re: XML is the future

#315

Post by jerf »

madsbuch wrote: post #297
Mikhail_Edoshin wrote: post #204

Earlier quoted context omitted.

Children and attributes are different. Attributes are like fields to a record. Parent/child is a relation between records. There are clear criteria for choosing attribute vs text representation. Text is for humans; all the rest is for the computer. If we see something like this: 123 this means the text is precious and we cannot alter it, only attach some records (‘ssn’) to some character ranges. And in most cases the…

that's a long explanation on how to use various features of a notation. would it be easier to just use json? You have many moving pieces with a complex notation, a complex domain, and potentially multiple architects..

If you have a simple use case, yes.

If you need the things that XML has, no, JSON is not simpler. It is more complex. Every attempt to embed XML/HTML into JSON has resulted in something worse than XML/HTML... and they are all different, too, which is bad.

The main problem with XML is that most people don't need what it has. The main problem with XML in the late 1990s and early 2000s is that it was jammed in many places that did not need what it had, and put a bad taste in developer's mouth as a result. It's actually a good solution for its niche, and that niche is large enough it isn't going anywhere, but it is also still only a niche. In that niche you're crazy to try to jam JSON in; out of that niche you're crazy to use XML. The mythos that XML is useless persists because the latter category is a much larger one.

Re: XML is the future

#316

Post by papruapap »

yread wrote: post #125
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…

I still can't believe that we (as a profession) kinda traded away schemas, namespaces, comments, sanity and well defined dates basically because some kids were too cool to write out closing tags. My early 20s teammate now closes blocks with } //for in his JS. That's even worse than XML!

Personally I just miss Dates. Even if I dont really like not having comments, it is probably for the best, force software to have proper documentation.

Re: XML is the future

#317

Post by tivert »

steveBK123 wrote: post #295
edejong wrote: post #290

Earlier quoted context omitted.

CPU/Memory: scale horizontally when needed. Monitor cost. Disk: essentially limitless. If disk of VM runs out, node will crash, new node will start. Service should keep running on other nodes meanwhile. If restarts happen too often, throughput/error rate will suffer or cost will rise. Modern mentality is "let it crash" [0]. Software has bugs. Design so it can crash and scale depending on need. [0] https://medium.com/…

This is an adequate philosophy for like.. a CRUD app, some freemium SaaS, social media, etc. Stuff with millions of users and billions of sessions, etc. However there are industries applying these lessons in HPC / data analytics / things that touch money live .. operating on scales of users in the 10s to maybe 100s. So stuff where downtime is far more costly both in dollars and reputation. I'm also intrigued by the c…

> I'm also intrigued by the constant cloud refrain of "stuff crashes all the time so just expect it to" coming from a background where I have apps that run without crash for 6 months at a time, or essentially until the next release.

IMHO, those aren't mutually exclusive. Your app code should be robust enough to run 6+ months at at time, and the "stuff crashes all the time so just expect it to" attitude should be reserved for stuff outside your control, like hardware failures.

Re: XML is the future

#319

Post by paulddraper »

NoboruWataya wrote: post #196
paulddraper wrote: post #24

> XML is the future That kinda happened, just not in the way everyone thought. In 2023, JavaScript XML is the most popular way to develop web applications, and a common choice for mobile and desktop applications. --- EDIT: JSX/React/React Native, in case that wasn't clear.

XML underpins of a lot of standards that are ubiquitous in their areas, eg, RSS, XMPP, GPX/TCX. Tons of government APIs still use XML. In the EU, in the financial sector at least, pretty much all regulatory reporting uses XML. And when the regulators decide to make some of that data available to the public, it typically uses XML as well. Companies in many countries are required to tag their financial statements using…

Don't forget SVG!

Re: XML is the future

#320

Post by jerf »

madsbuch wrote: post #106
Mikhail_Edoshin wrote: post #88

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…

You could say the same about JSON. It is arguably closer to how and AST is represented in software as it does not posses the two dimensional notation like XML does. The unique thing about XML is that you can both have children and attributes. My guess it that this is to model OOP-based systems: Attributes are for the constructor or a certain class while the children represent dependency injections. This is IMHO the w…

"My guess it that this is to model OOP-based systems:"

No, SGML which became XML is a separate independent track from OOP. They both set themselves up in some concrete before they really encountered each other and the contact was a mess. This is part of why the DOM, especially the first couple of iterations, are so messy (reading DOM 1 is almost hilarious in hindsight, if you know what you're reading for [1])... it doesn't help that the DOM also smashed into yet another tech line, the dynamically-typed scripting language, face first. The hasty three-way committee-arranged shotgun marriage in the late 1990s between these techs produced a fairly dysfunctional family.

[1]: https://www.w3.org/TR/REC-DOM-Level-1/level-one-core.html Notice this API, primarily used by Javascript, is specified in Java, complete with specifications of checked exceptions. Total clusterfuck. And a prime example of just how hard Java was inorganically jammed down the programming community's throats (which I say without regard to your current opinion of the language, it did grow up certainly, but the initial push was completely inorganic); this standard is 1998, with Java 1.0 release 1996. Java 1.2 (or 2.0 depending on how you look at it) was released in 1998, with such notable features as... the first Collections support in the library. This was not a language mature enough to be writing specifications in yet, even ignoring that you shouldn't be writing specifications like this in a specific language anyhow, especially since it was obvious and known it was going to be cross-language anyhow.

Post reply on HN