Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TOML – Tom's Obvious, Minimal Language

toml.io

Post reply on HN
Print view View original

61–70 of 163 posts

Re: TOML – Tom's Obvious, Minimal Language

#61

Post by alecbz »

chillfox wrote: post #35
alecbz wrote: post #27

Earlier quoted context omitted.

I think terseness and readability are often at odds past a certain point, and TOML seems to optimize for readability at the expense of terseness. E.g., having to specify column names again and again is tedious to write, but makes the file easier to read and modify safely.

Yeah, I think toml is great short/simple config files, yaml is good for medium length/complexity, and I have yet to see anything that’s not painful for long config files.

I actually think it's almost the opposite for me.

In a tiny yaml file it's pretty easy to understand what everything is; it's huge files where toml's forcing you to full qualify nested tables becomes useful.

Too many huge yaml files where I'm just scrolled somewhere in the middle and have no clue what part of the tree I'm actually looking at.

Re: TOML – Tom's Obvious, Minimal Language

#62

Post by chillfox »

smitty1e wrote: post #56
chillfox wrote: post #35

Earlier quoted context omitted.

Yeah, I think toml is great short/simple config files, yaml is good for medium length/complexity, and I have yet to see anything that’s not painful for long config files.

There is always cutting to the chase and using SQLite. https://www.sqlite.org/appfileformat.html

SQLite is lovely to work with, but I don't think it is entirely appropriate as a configuration format for server software considering that all of the existing tooling for configuration management (Ansible, Puppet, CFEngine) is based on template text files.

Re: TOML – Tom's Obvious, Minimal Language

#63

Post by chillfox »

alecbz wrote: post #61
chillfox wrote: post #35

Earlier quoted context omitted.

Yeah, I think toml is great short/simple config files, yaml is good for medium length/complexity, and I have yet to see anything that’s not painful for long config files.

I actually think it's almost the opposite for me. In a tiny yaml file it's pretty easy to understand what everything is; it's huge files where toml's forcing you to full qualify nested tables becomes useful. Too many huge yaml files where I'm just scrolled somewhere in the middle and have no clue what part of the tree I'm actually looking at.

Maybe our ideas of scale is a bit different?

I think yaml files hold's up well to about 50 lines.

I have only seen toml files up to about 10-20 lines and it looks great at that scale, but I am having a hard time imagining it being nice at 500+ lines.

Re: TOML – Tom's Obvious, Minimal Language

#64

Post by jiggawatts »

3np wrote: post #43
jiggawatts wrote: post #37

Earlier quoted context omitted.

It's about strong typing. I detest stringly-typed programming. If the format specifies some stronger types, the decoders can "bubble that up" to the programming language that decode the file. E.g.: a guid turns up as a "System.Guid" type in C# instead of "System.String". This matters, because all of these are the "same" GUID, but not all GUID parsers can handle all of these formats: {123e4567-e89b-12d3-a456-426652340…

Surely you shouldn’t be limited to types as interpreted and represented in the low-level config parser library but should have a strongly typed representation i of the config structure that you implement in whatever language you’re using. C# is a good example. JSON doesn’t have any of these types. It doesn’t even make a distinction between integers and other numbers. Yet it’s common practice to marshal these into the…

> whatever language you’re using.

This is the #1 mistake people make when designing, evaluating, or critiquing frameworks, file formats, protocols, and the like.

I don't get to choose the language. I'm not writing 100% of the code that I use.

In fact, I have control over approximately 0.00001% of the code involved in processing a typical JSON file, or TOML file, or YAML file.

OTHER people control the language choice, and it certainly won't be ONE language. It'll be many languages.

If submit an ARM template to Azure, it'll go through at least three languages in the process: C#, Python, and JavaScript. Possibly C++ and F#. Who knows?

Even when the language is reasonably consistent, such as JavaScript, there is very little consistency in the specific parser used.

After the parser-level inconsistencies, there's further inconsistencies in how the stringly-typed data is converted into some more strongly typed format. That's just up to whoever wrote the code that consumes the data. There is exactly zero standardisation of this. None whatsoever. It's almost never documented, and there's just no way to know without experimenting.

NONE of this is in my control, or your control. I can't emphasise this enough.

Stop thinking in terms of a developer sitting down in front of an IDE with a new project, where they type all of the code in, hit compile and ship the binary to some customer.

Start thinking in terms of having to deal with inconsistencies between Terraform, Cloudformation, Amazon, AWS, GCP, and CloudFront.

Starting thinking about having to publish something like a Rust module to three different crate repositories, and cache it locally, and have it work properly with the various IDEs people use.

Start thinking in terms of security vulnerabilities of different parsers at different layers escaping data differently, or smuggling data using encodings accepted by the back-end past web application firewalls that don't understand that particular encoding.

This stuff matters.

JSON famously had a definition so short that it fit on a business card.

Less is more, right?

This "simplicity" lead to fun blog posts titled "Parsing JSON is a minefield": http://seriot.ch/parsing_json.php

The designer of TOML seems to have never read that article, or if he has, he hasn't learned any lessons from it...

Re: TOML – Tom's Obvious, Minimal Language

#65

Post by thayne »

nuclear_eclipse wrote: post #46
thayne wrote: post #39

Earlier quoted context omitted.

What confuses me is why there isn't a toml module in the standard library.

I think the general feeling in the community is that the standard library is where packages go to die. Once something is in the standard library, it can't get meaningful features/updates outside of the yearly release cycle. pip and setuptools are already vendoring a TOML implementation, and once you have pip, you can pick from multiple great toml implementations that are all under active development. Maybe once the p…

> the standard library is where packages go to die

I totally understand that sentiment. But that does seem to contradict the "batteries included" philosophy. Then again pip itself seems like one of the batteries you would expect to be included, so maybe that philosophy is just no longer as relevant to python.

Re: TOML – Tom's Obvious, Minimal Language

#66

Post by smitty1e »

chillfox wrote: post #62
smitty1e wrote: post #56

Earlier quoted context omitted.

There is always cutting to the chase and using SQLite. https://www.sqlite.org/appfileformat.html

SQLite is lovely to work with, but I don't think it is entirely appropriate as a configuration format for server software considering that all of the existing tooling for configuration management (Ansible, Puppet, CFEngine) is based on template text files.

I dunno. By the time one manages a full enterprise of configuration, one puts it in SQLite and treat your cookbooks/roles/stacks as report products.

After normalizing, one could get to a tidy heterogeneous solution.

(Only the finest vaporware spoken here.)

Re: TOML – Tom's Obvious, Minimal Language

#67

Post by sullyj3 »

chillfox wrote: post #35
alecbz wrote: post #27

Earlier quoted context omitted.

I think terseness and readability are often at odds past a certain point, and TOML seems to optimize for readability at the expense of terseness. E.g., having to specify column names again and again is tedious to write, but makes the file easier to read and modify safely.

Yeah, I think toml is great short/simple config files, yaml is good for medium length/complexity, and I have yet to see anything that’s not painful for long config files.

Dhall bills itself as being designed for longer configuration files. It has functions, allowing for some abstraction, but it's not turing-complete.

https://github.com/dhall-lang/dhall-lang

Re: TOML – Tom's Obvious, Minimal Language

#69

Post by jiggawatts »

pydry wrote: post #20
jiggawatts wrote: post #4

TOML superficially looks clean, but it has many of the same problems other similar languages have. Such file formats are typically used for configuration files. Yet, a substantial amount of effort was expended on data types not commonly seen in configuration files, such as a date-time-offset. Meanwhile, much more common data types typically used in configuration files is missing, such as GUIDs, IP Addresses, and byte…

databases: db01: 10.1.2.3 db02: 10.1.2.4 filers: user01: 10.3.10.1 user02: 10.3.10.2

What if I needed to add about 5-10 additional columns to that. Would TOML still have a similarly terse way of encoding that?

E.g.: Region, AZ, Network, Subnet, Description.

Post reply on HN