INI was an amazing concept that does its job very well, being easy to read and easy to parse. TOML is not a good INI extension for many reasons, some you've listed, but YAML isn't any better of a format. The main difference is that I've never had to use TOML, while, for some reason, YAML has been shoved into all kinds of places it doesn't belong.
For one thing, strings should be quoted; this TOML and JSON get right, and YAML gets wrong. For another, significant white space may work for Python, but that doesn't mean it's a good thing and certainly doesn't justify its use in a data file format; this goes doubly so when the - is enough to do the job anyway.
TOML lets the users decide what type a thing is. But in most cases, this is not correct as the client should decide what type a thing should have. If the types are incorrect they should be coerced or an error should be thrown.
I couldn't disagree with this more. Types should be clear and unambiguous, and the correct type should be chosen by the person entering the data, not by the client, parser, or any other software. If the software is having coerce types, then you're doing something wrong. But, to be fair, this is basically the dynamic typing vs static typing debate in a different package, so I'm sure opinions will differ.
In the end, given the choice, I'd take old school INI over TOML or YAML any day of the week.
Anyway, great article and I look forward to reading your future articles.
I agree to almost all your points from a programming point of view. But config files are supposed to be human readable, not just programmer readable. I guess I didn't fully mention that in my post, that's why I said I'll be making a better one someday.
TOML is not a good INI extension for many reasons, some you've listed, but YAML isn't any better of a format.
Absolutely. In fact, I was planning to make that my next post.
For one thing, strings should be quoted; this TOML and JSON get right, and YAML gets wrong. For another, significant white space may work for Python, but that doesn't mean it's a good thing and certainly doesn't justify its use in a data file format; this goes doubly so when the - is enough to do the job anyway.
Configuration files are supposed to be human readable and writable, not just programmer readable and writable. Programmers may feel at home knowning the difference between "1" and 1, but other (non-programmer) humans find it confusing. This is where type coercion comes into play.
Also, humans find indents more helpful than braces (that's why we indent code!)
TOML lets the users decide what type a thing is. But in most cases, this is not correct as the client should decide what type a thing should have. If the types are incorrect they should be coerced or an error should be thrown.
I couldn't disagree with this more. Types should be clear and unambiguous, and the correct type should be chosen by the person entering the data, not by the client, parser, or any other software. If the software is having coerce types, then you're doing something wrong. But, to be fair, this is basically the dynamic typing vs static typing debate in a different package, so I'm sure opinions will differ.
Today you write "42" as a value, your app receives a string and everything goes well. Tomorrow you write 42 and the app crashes because the parser decided that the value 42 was a number. Of course, we could defensively program to avoid this, but having a schema as a source of truth is the best way to go.
In the end, given the choice, I'd take old school INI over TOML or YAML any day of the week.
Me too. In fact, I'm designing a simple INI like file format. It may never be complete, but I'll see.
I love it when people post comments like this on my blog posts. Thanks.
I think we as programmers underestimate the ability of non-programmers and programmer-adjacent people. Normal people understand numbers and they understand that "42" is different from 42. Personally I've never had a problem teaching dentists, doctors, nurses, and receptionists that text should have quotes around it when working with configuration and data files.
More over, quoting strings seems like a weird place to draw the line. These normal users already have to learn that some things require colons after them, things below that have to be indented two spaces with a dash, what aliases are, and how & and * are used. I don't see any reason that quoting text is the thing that makes it too complicated for them. Especially when more and more schools are teaching basic programming skills at younger and younger ages.
Today you write "42" as a value, your app receives a string and everything goes well. Tomorrow you write 42 and the app crashes because the parser decided that the value 42 was a number. Of course, we could defensively program to avoid this, but having a schema as a source of truth is the best way to go.
Totally agree that schemas are the way to go, but when some user changed "42" to 42, the parser shouldn't try to fix the human's mistake, it should simply alert the user that they made a mistake by forgetting the quotes. Again, static typing vs dynamic typing; even for non-programmers it is better when things work like a deterministic machine and not like a magic hat.
Also, humans find indents more helpful than braces (that's why we indent code!)
I disagree and think braces with proper indention is the best option for programmers and programming languages.
Regardless, my point was simply that YAML specifically fails by requiring both indentation and the dash character before items when the dash character should have been enough on its own.
Me too. In fact, I'm designing a simple INI like file format. It may never be complete, but I'll see.
That's awesome! Making a standard, parser, and editor for a backwards compatible extended INI format was one of the first projects I took on as a young programmer and it was a lot of fun.
I love it when people post comments like this on my blog posts. Thanks.
No problem. I love articles like this and thank you for writing it and responding to my comment. :)
I think we as programmers underestimate the ability of non-programmers and programmer-adjacent people. Normal people understand numbers and they understand that "42" is different from 42. Personally I've never had a problem teaching dentists, doctors, nurses, and receptionists that text should have quotes around it when working with configuration and data files.
That's definitely true. But most people will never had heard of strings, or TOML, or INI, and might not have been taught by a programmer. We must consider them too.
More over, quoting strings seems like a weird place to draw the line. These normal users already have to learn that some things require colons after them, things below that have to be indented two spaces with a dash, what aliases are, and how & and * are used. I don't see any reason that quoting text is the thing that makes it too complicated for them. Especially when more and more schools are teaching basic programming skills at younger and younger ages.
Actually I was talking about config files in general, not just about YAML. My post has nothing to do with YAML, it just shows it as an example to compare to.
I know that YAML isn't perfect. I know that the two spaces before dash thing is weird (don't ask me how many times my GitHub actions broke before that), and I know how the & and * and | and > are confusing.
Actually I was talking about config files in general, not just about YAML. My post has nothing to do with YAML, it just shows it as an example to compare to.
Apologies, I was also using YAML as a generic example. The same points hold true for any file format; users already have to learn various syntax and semantics of the format, also learning to quote strings isn't much of a stumbling block and brings more benefits than it does disadvantages.
That's definitely true. But most people will never had heard of strings, or TOML, or INI, and might not have been taught by a programmer. We must consider them too.
Agreed, however there has to be a line draw somewhere. We should assume that anyone allowed to edit the config file has at least been taught (or learned) the format of the file, whatever that format is. After all, in the real world it isn't random people off the street editing config and data files, it is most often trained employees and/or learned users. So by the time they get to the file they should have heard of sections and entries, numbers and strings, arrays and objects, and/or whatever abstractions and constructs the file format requires.
To paraphrase something an old C++ teacher told me back in the day, "Users aren't unintelligent, they are ignorant and that means they can learn." In other words, a user may not know the difference between a number and string, but when the computer yells at them for giving a number instead of a quoted string, they are more than capable of learning the difference. By trying to be forgiving and guessing what they really wanted, one isn't so much helping the user as depriving them of an opportunity to learn and improve.
Actually I was talking about config files in general, not just about YAML. My post has nothing to do with YAML, it just shows it as an example to compare to.
Apologies, I was also using YAML as a generic example. The same points hold true for any file format; users already have to learn various syntax and semantics of the format, also learning to quote strings isn't much of a stumbling block and brings more benefits than it does disadvantages.
Yes, and the point of human friendly languages is to try and minimize whatever needs to be learned. Like you said, quoting and unquoting can be easily learned. But if we remove that it becomes (albeit slightly) easier for users.
Agreed, however there has to be a line draw somewhere.
Definitely, we have to. I was just mentioning the others.
By trying to be forgiving and guessing what they really wanted, one isn't so much helping the user as depriving them of an opportunity to learn and improve.
Makes sense.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
INI was an amazing concept that does its job very well, being easy to read and easy to parse. TOML is not a good INI extension for many reasons, some you've listed, but YAML isn't any better of a format. The main difference is that I've never had to use TOML, while, for some reason, YAML has been shoved into all kinds of places it doesn't belong.
For one thing, strings should be quoted; this TOML and JSON get right, and YAML gets wrong. For another, significant white space may work for Python, but that doesn't mean it's a good thing and certainly doesn't justify its use in a data file format; this goes doubly so when the
-is enough to do the job anyway.I couldn't disagree with this more. Types should be clear and unambiguous, and the correct type should be chosen by the person entering the data, not by the client, parser, or any other software. If the software is having coerce types, then you're doing something wrong. But, to be fair, this is basically the dynamic typing vs static typing debate in a different package, so I'm sure opinions will differ.
In the end, given the choice, I'd take old school INI over TOML or YAML any day of the week.
Anyway, great article and I look forward to reading your future articles.
I agree to almost all your points from a programming point of view. But config files are supposed to be human readable, not just programmer readable. I guess I didn't fully mention that in my post, that's why I said I'll be making a better one someday.
Absolutely. In fact, I was planning to make that my next post.
Configuration files are supposed to be human readable and writable, not just programmer readable and writable. Programmers may feel at home knowning the difference between
"1"and1, but other (non-programmer) humans find it confusing. This is where type coercion comes into play.Also, humans find indents more helpful than braces (that's why we indent code!)
Today you write
"42"as a value, your app receives a string and everything goes well. Tomorrow you write 42 and the app crashes because the parser decided that the value 42 was a number. Of course, we could defensively program to avoid this, but having a schema as a source of truth is the best way to go.Me too. In fact, I'm designing a simple INI like file format. It may never be complete, but I'll see.
I love it when people post comments like this on my blog posts. Thanks.
I think we as programmers underestimate the ability of non-programmers and programmer-adjacent people. Normal people understand numbers and they understand that "42" is different from 42. Personally I've never had a problem teaching dentists, doctors, nurses, and receptionists that text should have quotes around it when working with configuration and data files.
More over, quoting strings seems like a weird place to draw the line. These normal users already have to learn that some things require colons after them, things below that have to be indented two spaces with a dash, what aliases are, and how & and * are used. I don't see any reason that quoting text is the thing that makes it too complicated for them. Especially when more and more schools are teaching basic programming skills at younger and younger ages.
Totally agree that schemas are the way to go, but when some user changed "42" to 42, the parser shouldn't try to fix the human's mistake, it should simply alert the user that they made a mistake by forgetting the quotes. Again, static typing vs dynamic typing; even for non-programmers it is better when things work like a deterministic machine and not like a magic hat.
I disagree and think braces with proper indention is the best option for programmers and programming languages.
Regardless, my point was simply that YAML specifically fails by requiring both indentation and the dash character before items when the dash character should have been enough on its own.
That's awesome! Making a standard, parser, and editor for a backwards compatible extended INI format was one of the first projects I took on as a young programmer and it was a lot of fun.
No problem. I love articles like this and thank you for writing it and responding to my comment. :)
That's definitely true. But most people will never had heard of strings, or TOML, or INI, and might not have been taught by a programmer. We must consider them too.
Actually I was talking about config files in general, not just about YAML. My post has nothing to do with YAML, it just shows it as an example to compare to.
I know that YAML isn't perfect. I know that the two spaces before dash thing is weird (don't ask me how many times my GitHub actions broke before that), and I know how the
&and*and|and>are confusing.Apologies, I was also using YAML as a generic example. The same points hold true for any file format; users already have to learn various syntax and semantics of the format, also learning to quote strings isn't much of a stumbling block and brings more benefits than it does disadvantages.
Agreed, however there has to be a line draw somewhere. We should assume that anyone allowed to edit the config file has at least been taught (or learned) the format of the file, whatever that format is. After all, in the real world it isn't random people off the street editing config and data files, it is most often trained employees and/or learned users. So by the time they get to the file they should have heard of sections and entries, numbers and strings, arrays and objects, and/or whatever abstractions and constructs the file format requires.
To paraphrase something an old C++ teacher told me back in the day, "Users aren't unintelligent, they are ignorant and that means they can learn." In other words, a user may not know the difference between a number and string, but when the computer yells at them for giving a number instead of a quoted string, they are more than capable of learning the difference. By trying to be forgiving and guessing what they really wanted, one isn't so much helping the user as depriving them of an opportunity to learn and improve.
Yes, and the point of human friendly languages is to try and minimize whatever needs to be learned. Like you said, quoting and unquoting can be easily learned. But if we remove that it becomes (albeit slightly) easier for users.
Definitely, we have to. I was just mentioning the others.
Makes sense.