6 ms·
> For human-edited files, pick almost literally anything else. I'd still take XML over JSON for human-edited files. At least XML supports comments. > For seri
by kllrnohj 3y ago
> For human-edited files, pick almost literally anything else.
I'd still take XML over JSON for human-edited files. At least XML supports comments.
> For serialization, JSON handles the common cases
Counter-point, JSON sucks and is way overused. The types are too fuzzy, the syntax too quirky, and validators/schemas are almost never present. You can bolt that all on, but it wasn't designed for it and it shows. It was designed to be eval()'d, which you should also never do because it's a terrible idea. It's flawed at the foundations.
- kstrauser 3y agoThose are valid points, and while I have a different opinion, I can't say you're wrong about any of it. But I will say that the first time I used a JSON API that had replaced an XML one, I almost wept with relief. Perhaps because JSON is so simple, it pushed APIs toward having simpler (IMO) semantics that were far easier to reason about. Concretely, I'll take an actual REST API (that is, not just JSON-over-HTTP) over the SOAP debacle any day of the week. I know you can serve XML without using SOAP, but to me they're both emblematic of the same mindset. Still, at least neither of them are EDI.
- SahAssar 3y ago> The types are too fuzzy Do you mean non-json types? Because the supported types seem pretty straightforward. (besides perhaps supporting null bytes in strings in things like postgresql) > the syntax too quirky Care to explain? This has always seemed like one of jsons strengths. The syntax for what is valid is pretty straightforward.
- kllrnohj 3y ago> Do you mean non-json types? Because the supported types seem pretty straightforward. (besides perhaps supporting null bytes in strings in things like postgresql) What is a "number"? Is it a float? int? short? double? BigDecimal? What about time values? Or dates? Oh, you have to just shove those into strings and hope both sides agree? That's fun. > Care to explain? This has always seemed like one of jsons strengths. The syntax for what is valid is pretty straightforward. One example is the json "spec" on json.org does not allow trailing commas yet many parsers do
- lmm 3y ago> Counter-point, JSON sucks and is way overused. The types are too fuzzy, the syntax too quirky, and validators/schemas are almost never present. You can bolt that all on, but it wasn't designed for it and it shows. XML's validation, schemas and typing are far more complicated and equally useless - the impedance mismatch is too big, all they do is give you a whole bunch of extra ways to shoot yourself in the foot, particularly in the presence of namespaces. If you want something fully structured, protobuf or equivalent is the way to go (and converting back and forth between protobuf and JSON is relatively painless).
- Turskarama 3y agoXML Namespaces are one of the worst anti-features I have ever encountered. I have yet to see a legitimate use for them, but they make parsing way more of a pain than it needs to be. Also the use of attributes vs nested tags seems pretty arbitrary and in my experience attributes are hardly used at all.
- jmbwell 3y agoYeah. Look, I’m a booster for XML. But I recently worked on a project to interface with Microsoft Office documents. So many conflicting namespaces. So. Many. Conflicting. Namespaces. Often for the same “kind” of document, at least as far as the user is concerned. So much flexibility. So many ways to paint yourself into a corner. Such a nightmare. Also, the reason we have jobs.
- fiddlerwoaroof 3y agoYeah, I personally find XML elegant and well-designed compared to the popular alternatives today. And things that supply what’s missing (for example, JSON-LD and JSON Schema) aren’t much less complicated than the XML equivalents. Of alternatives, I think EDN is the closest to being a satisfactory replacement because it supports namespaces.
- ChrisMarshallNY 3y agoComments are absolutely vital, in my opinion; especially for config files. I don't like XML, YAML, or JSON. If I am doing server-side PHP, my config files are executable PHP. It's my responsibility to make sure they can't break the system too much. If I am doing host-side stuff (like Swift Package Manager), I prefer executable Swift files. But I cut my teeth on BNF[0], and X.500[1]. They worked well, but were painful. They make YAML look good. [0] https://en.wikipedia.org/wiki/Backus–Naur_form https://en.wikipedia.org/wiki/Backus–Naur_form [1] https://en.wikipedia.org/wiki/X.500 https://en.wikipedia.org/wiki/X.500
- bombcar 3y agoComments that "self-document" a config file are great. Comments that result in: #Frontend server is called Alpha, and runs HTTPS frontend:"beta":http cause me to die.
- ChrisMarshallNY 3y agoI find “self-documentation” often doesn’t actually work. It’s great in theory, but often falls down, in practice. I tend to preface my config stuff with fairly substantial comment blocks that discuss the reasoning behind the configuration. Here’s an example: https://github.com/LittleGreenViper/LGV_MeetingServer/blob/master/Tests/config/LGV_MeetingServer-Config.php https://github.com/LittleGreenViper/LGV_MeetingServer/blob/m...
- bombcar 3y agoBy "self-documenting" I mean things like: # Diff for interactive merges. # %s output file # %s old file # %s new file merge="sdiff --suppress-common-lines --output='%s' '%s' '%s'" it's useful the first time you dive in, not having to read the man page. But over time, the comments can get out of sync especially if you don't carefully merge in the package-maintainer's version every update.
- somat 3y agoI like how the openbsd project does it. They have a parse.y that sort of gets traded around and joins new projects. Nothing super formal but it does mean most openbsd service configuration feels like each other. but each config is tailored to it's application. and being properly parsed the error messages can be better. In fact that is my biggest beef about yaml, I mainly use it in the context of ansible, and the parsor usually has no clue where in the file the error actually is. You have to depend on remembering where you last edited to actually find the error. My other big problem with yaml is that the ansible context is trying very hard to make it a programing language... And while it is an okish config language it is a terrible programing language. In fact this is a common problem with many complex environments. They want to try and push this complicated setup into a config file and claim "look it is easy, no programing required" when really what they have done is to push a programing situation into the worlds worst programing language. see also: xslt