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.
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.