Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> It's a perfectly reasonable choice: flexible, well specified, well supported, reasonably performant. I think the extreme level of hype 20 years ago was overdone and (just like with anything) there's good ways to adopt it and bad ways. But as a basic technology choice, it's fine.

Absolutely with you up to here, but...

> Particularly these days when you can have a coding agent write the parser boilerplate, etc. for you.

Absolutely not. Having seen the infinite different ways a naive implementation of XML goes wrong, arguably being one of the main causes of death for XHTML because browsers rightfully rejected bad XML, "Don't roll your own XML implementation" should be right up there with "Don't roll your own crypto".

I don't feel like it's going out on a limb to say that if someone needs to defer to a LLM to implement XML they're not qualified to determine if it's done it right and/or catch what it got enthusiastically wrong.

 help



Oh sorry, I don't at all intend to say you should write your own parser! Totally agree: "Don't roll your own XML implementation"

What I was addressing is, interfacing with an XML parser and converting that into whatever your internal representation is, can be a chore. LLMs are great at that stuff.


I'm going to stand by my position there, if you're writing an application that's primary technical purpose is to communicate via an XML based protocol and feel the need to outsource the XML part to the bullshit machine, IMO you probably shouldn't be writing that application.

To each their own.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: