Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

If we assume this is serious then it falls into a division I see in a lot of areas. Catch errors sooner or Catch errors later. The Catch errors later group tends to take the position that Because I have to catch some errors later anyway I might as well catch all the errors later. The catch errors earlier group tends to take the position that the earlier I can catch the error the easier it is to handle and the safer my code will be.

Neither seems to be able to see valid points in the other's position so it ends up being polarizing.



I don't think this is to do with catching errors. You can throw errors at load time with both mechanisms if that's what you want. Instead, the question is, should the file format include a bunch of notation so that the computer can deserialize the value to some type even without knowing what it'll be used for?

Since ini is a format designed for humans to read and write, the argument is that no, the reading code should decide how to interpret the value, and this is fine because it knows whether it wants this particular value to be a boolean or a string or a number or a continent.

The ini file reader has an implicit schema in its reader code. The TOML file makes (some of) the types explicit in the file itself at the expense of making it less convenient for a human to read and write.


Following this argument to its logical conclusion, why bother having any kind of standardized format at all, ini or otherwise? The program's config reader knows what it wants to read, why bother standardizing names, notation, section delimiters, or anything else?


> why bother having any kind of standardized format at all, ini or otherwise?

So you can reuse the parsing code and the file-editing instructions.

Standardization is not about catching errors.


I presume the argument the author of this article would make is because it helps the human writer of the file.


And a standardized format takes that even further, since now text editors can be aware of more of the file structure and assist with highlighting, completion and more.


NestedText was mentioned earlier in this thread, and it takes the philosophy to it's logical conclusion. That conclusion includes schemas https://nestedtext.org/en/latest/schemas.html. Text editors could absolutely be written to understand schemas and provide the help you suggest.


> The Catch errors later group tends to take the position that Because I have to catch some errors later anyway I might as well catch all the errors later.

I'm not sure why that follows. It doesn't seem to apply to any other domain, eg: since I have to deal with diseases associated with aging later anyway, I might as well not take care of myself now and just go wild and do anything I feel like.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: