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

It doesn’t answer the question, but I do wonder if XML would be an improvement in devops, compared to the current obsession with YAML. For everything except the part where you write it.

Make an xml stylesheet and your kubernetes cluster is instantly documented.



I recently entered DevOps (not my choice), and I would like to take your request further: replace everything with a regular language.

Having to use a gazillion declarative languages to achieve what a regular programming language does is simply crazy.


Here the next thing I hope will be code in the format you use for the apps themselves.

It’s testable, discoverable etc.

https://www.pulumi.com/

(Sorry about shameless plug, I’m not affiliated)


XML is pretty horrible to edit by hand.


Maybe if you are using Notepad. Any decent text editor will provide things like auto indentation, completion, auto end-tags, structured editing, and schema validation. For example, Emacs comes with nXML mode:

https://www.gnu.org/software/emacs/manual/html_mono/nxml-mod...


That assumes that you edit XML all day long. This is not always the case.

I am writing non-XML code most of the day, and I do not have structured editing / auto braces enabled. So when I need to edit that one XML config, I'll open it in my regular editor, which will provide at most syntax highlight, and edit it as needed with a bit of swearing. And next time, I would promise myself I'd choose a different config format which does not need special editors.


> I'll open it in my regular editor, which will provide at most syntax highlight, and edit it as needed with a bit of swearing.

That sounds like a very passive-aggressive way to deal with a problem. Do you do the same thing when writing programs?


Which "same thing"? Not setting up editor and complex environment for the things I am only going to edit once or twice? Yes.

In general, when you see something inefficient, you can either fix it to make it better, or ignore and come up with random workarounds.

In my opinion, a config file which cannot be edited by hand, and which needs a special editor with non-trivial learning curve, is a inefficiency. I can either ignore it, and set up the specialized tools; or I can fix it, by ripping out XML and replacing it with something more human-editable, like TOML or YAML. In large teams, it is almost always better to fix it -- sure, I will spend a few hours getting rid of XML, but this will pay itself off in the long term, as no one else will have to bother with special setup anymore.

(This obvious only applies to the systems where XML is a minor part, like a single configuration file. If your system has huge amount of XML, you better learn the right tools)


I don't understand, what is there to set up? With the Emacs mode I gave as an example, you just open an XML file and everything is there. Any decent text editor will have XML support.


xmllint --noout <file> will check the file and report any issues with XML syntax in a very detailed way with line numbers for you to see.

I myself don't even use syntax highlighting and normally work in vim and although I do make errors in XML sometimes, I find that I make at least as many syntactic errors in Python or C code that I have to weed out before I can proceed. But I never heard anyone complaining about Python or C being too strict :)


They all are, but xml isn’t the worst. (Json and S-expressions are worse, for example).

Not even formats designed for human consumption such as yaml are very good. The good ones for editing (toml, csv, ini) fall short when it comes to complex structure instead. There is no silver bullet.




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

Search: