Hacker News Reader

Comment by weberc2 | Hacker News Reader

I’ve been around long enough to use them all. I’m pretty happy with JSON as a debuggable serialization format for machine-to-machine or light machine-to-human use cases. YAML works well for human-to-machine (JSON could fill this use case as well if it would support comments and multi line strings). I don’t use TOML much, and good riddance to XML.

View on HN

TOML is simply the old INI format except with a single concrete specification instead of many adhoc ones. YAML is the "kitchen sink included" of serialization formats, so much so that most only use a small subset of its features. In that case I think TOML is usually the better choice unless you really do need some of the power and complexity offered by YAML.

I agree that less power is better, but I find TOML pretty cryptic. Like I said, JSON with comments and multi line strings is my ideal. :)

What do you feel is cryptic about TOML? I always felt it was pretty straightforward, especially if you're coming from INI (you could feed INI files into a TOML parser and most of the time end up with something somewhat sane, especially if you're using octothorpes instead of semicolons as comments).

That aside, I'm personally a big fan of using Tcl-like / shell-like syntax for configuration, since it enables some pretty rich and expressive config directives while not being insanely verbose like most attempts at using XML for this. It's one of the things I really like with OpenBSD's various subprojects like PF¹ and OpenSMTPD² and relayd/httpd³, and I'm semi-actively working on a way to do similar things in Erlang/OTP applications⁴. The only alternative that matches that level of expressiveness (besides just doing all configuration directly in the host language) is s-expressions.

¹: https://man.openbsd.org/pf.conf

²: https://man.openbsd.org/smtpd.conf

³: https://man.openbsd.org/relayd.conf.5 / https://man.openbsd.org/httpd.conf.5

⁴: https://otpcl.github.io

I'm not coming from INI files. :) I actually always felt they did a poor job of representing anything more than key value pairs and they weren't standardized, so I always managed to avoid learning the grammar(s). I'm sure if I put much effort into it, I could figure out TOML, but I don't want to ask my users to figure out yet another configuration language.

If I'm going to make them learn another configuration language, it's going to have something more to offer than just 'simpler than YAML'. Maybe Starlark for more powerful configuration applications (think infra-as-code where YAML/JSON/etc clearly isn't powerful enough) or if someone ever builds it, "JSON with comments and multiline strings" which offers simplicity without compromising familiarity. Actually, it would be really interesting to hear what people's ideal configuration languages would look like.

> That aside, I'm personally a big fan of using Tcl-like / shell-like syntax for configuration, since it enables some pretty rich and expressive config directives while not being insanely verbose like most attempts at using XML for this.

I'm not really familiar with this. I'll have to read up.

TOML is what I'd naturally write as notes if I wanted to document how something is working.

YAML is all sorts of strange.

JSON needs comments and support for trailing commas. Since that isn't going to happen.... TOML!

"Good riddance to XML" is a bit much. Did you read the article? XML is ideal for representing tree structures. Pick the tool for the job.

For example, XAML does an excellent job in declaring your UI. Its use of namespacing, and how you can use child nodes to declare properties of an object, makes it highly flexible albeit slightly verbose.

Years of experience > "the article"

JSON is a tree structure. It is dictionaries and arrays mixed together in a hierarchy.

Your opinion != Everyone's opinion

Don't get me wrong, I prefer JSON in most cases. But XML does have many valid use cases. Perhaps you haven't had an opportunity to see its beauty. You can't blindly say JSON > XML or JSON < XML, or "XML sucks" -- this shows ignorance.

I didn't say any of that. JSON is a tree structure, that isn't an opinion.

My bad, I think I was responding to another comment.

Using child nodes to declare properties of an object is the main reason I dislike XML. Because some people use children, and some use attributes, and some use both. Granted, that isn't XMLs fault, but every time I to have get XML data into a usable format it feels like a struggle.

You’re welcome to your opinion. I disagree that XML is ideal for representing tree structures or anything else for that matter. I’ve used XML a lot (including for UIs and other tree-like data structures), but ever since JSON became popular I haven’t found myself missing it.

> For example, XAML does an excellent job in declaring your UI.

JSX does a better job.

I hate XAML, it doesn't add anything except verbosity over just using C#. The original goal of XAML was to allow bindings to multiple programming languages and to allow designers to use a suite of amazing tools to finished designs off to developers for implementation.

What ends up happening is developers write XAML, then they write C# to back up what XAML can't do, then they have a complex build stage to shove all this crap together, but instead of XAML just being transpiled to C# it has its own run time thing that hosts compiled XAML files.

JSX by comparison is a trivial transformation to JavaScript. It is easy to read, and it does not try to replace JS control structures.

In fact you could probably trivially transform a JSX syntax to ANY C type of language, I know there is a proposal (implementation?) for a JSX-like to Dart.

The sheer awesomeness of JSX is hard to describe if you haven't used it. It is like something asked "what is the simplest, easiest to understand templating language we can possibly create?" and out popped JSX.

My favorite part of JSX is how it doesn't try to have control structures in it. Everyone else gets this wrong and adds some sort of string types DSL to their templating language.

JSX doesn't do that. If you want to map over an array and spit out a bunch of elements, you just do so in JavaScript/TypeScript.

Interesting, I'll have to take a second look at JSX. So far I feel like in certain cases XML is better at declaring objects and their properties (along with their Types). XAML can declare any type and configure it as needed, it is a way of declaring components in a logical fashion. I wonder if JSX/alternatives are a true superset of XML-derived formats. FYI, XAML generates a binary format at compile-time. From my many experiences with desktop applications, the additional code for XAML/UI is required regardless of the languages/frameworks, to control things like animations, behaviors, markup extensions.

> XAML can declare any type and configure it as needed, it is a way of declaring components in a logical fashion.

XAML is a lot like Python object constructor syntax with all named parameters except one positional parameter that is a list of child objects (obviously, explicit closing tags rather than a closing square bracket and paren is a difference, but structurally it's m almost identical.) It's certainly a convenience for declaring certain kinds of object trees, especially if your main programming language doesn't have a similarly succinct object construction syntax. JSX is effectively a way of adding an equivalent object constructions syntax to the host (JS) language, rather than requiring it to be in separate code files.

Reply on news.ycombinator.com