Here we go. The never ending story of inventing new syntax to configure software. Because that somehow brings value to what you are trying to accomplish with the software? Really? But why stop there? Why not invent a whole new programming languages to make writing your “To Do” single user web application easier? That makes as much sense to me as spending time thinking about your configuration file syntax.
YAML and Configuration Files
81–90 of 96 posts
Re: YAML and Configuration Files
#82The solution for defining a more complicated config is to write your own config file format? I would think a custom format wouldn't necessarily be easier for others to read and write unless it came with a guide/readme, but then that's just one more thing to learn. Admittedly, I've never had to write a super complicated config file, but can anyone tell me why I shouldn't continue to use something like JSON for all of…
Compared to yaml or ini formats, JSON is arguably harder to read and definitely harder to write due to having to keep track of brackets, commas, and/or quotes. Ideally, a configuration file should be easy to read and write/modify by a user of the application. A lot of applications just stick with ini like formats because it meets both requirements.
I prefer JSON to YAML. There are no objective way to measure whether one is better than the other.
Re: YAML and Configuration Files
#83Earlier quoted context omitted.
There are lots of ways to implement it. The problem is that one of JSON's strengths is its ubiquity: every language under the sun has half a dozen different battle-tested parsers for it. Clients and servers and everything in-between have first-class support out of the box. You can even paste it directly into JavaScript as valid code. If anybody short of a standards body tries to expand the spec, you lose out on most…
i think you can possibly define how you want to use json for a configuration file; json by itself is not much more than javascript objects/maps, defined as a data format. I frankly don't think that you need to be too pious about standard compliance if dealing with a cofiguration format for your application.
Editors, for one, will be an issue
Re: YAML and Configuration Files
#84Earlier quoted context omitted.
What a delightfully readable example of a hand-rolled lexer and parser that is.
I thought you were being sarcastic, but I think I just finally learned how lexers and parsers work by reading the code, and I don't even know Go.
Hah yeah no sarcasm intended at all! It's really neat code.
Re: YAML and Configuration Files
#85Earlier quoted context omitted.
Compared to yaml or ini formats, JSON is arguably harder to read and definitely harder to write due to having to keep track of brackets, commas, and/or quotes. Ideally, a configuration file should be easy to read and write/modify by a user of the application. A lot of applications just stick with ini like formats because it meets both requirements.
For me, the brackets, commas, and quotes are what make json readable (and writable). I really struggle to write yaml. I end up writing it as json and converting it. I agree about ini though.
> I really struggle to write yaml. I end up writing it as json and converting it.
Since valid JSON is also valid YAML with the same semantics, it is impossible for it to be harder to write YAML than JSON, and no conversion is necessary.
Re: YAML and Configuration Files
#86Earlier quoted context omitted.
> I think YAML is even worse as a serialization format than a configuration format. This. I find YAML to be the least offensive option for configuration and one of the worst for serialization. I might be misinformed, but I find it absurd that in 2021 we still don't have a default, universally available tool that supports the basic table stakes without headache: 1. core data types (number, string, etc) 2. lists, maps,…
My JSON parser ( github.com/nanoscopic/ujsonin ) has these things: 0. Looks essentially the same as JSON 1. Core data types, and customizable data types can be added easily. 2. Arrays, Objects, and arbitrary nesting. 3. Comments ( both /* */ and // format ) 4. Multiline strings ( by default; carriage returns are no problem within strings ) 5. It is JSON with relaxed restrictions and slight addition for actual named t…
I like the idea of what you're doing. May I suggest a Nim port? Nim outputs C anyway, but is safe, so you'd worry less about bugs.
Re: YAML and Configuration Files
#87I always wondered, why XML is not used by developers. I use it for my programs. The combination of attributes and data within nodes, to me, has been very useful.
It's a slog to write, harder to parse, and you have to make more decisions (do I put this in the node's attribute, or as a child node?). Maven had pom.xml files for declaring dependencies. Very few developers enjoyed editing those, and you don't see many XML-based config files these days for a reason.
I've seen devs that came from the XML era treat json the same way, and I hate it. Exanple:
{ "key": "the key", "Value": "the value" }
Re: YAML and Configuration Files
#88Earlier quoted context omitted.
It's a real shame JSON doesn't have 3 and 4, because it would be so easy and it's otherwise pretty much perfect imo. No ambiguity, every value type can be identified by its first character, clean and reasonably minimal syntax.
What about a key named “_comment”, or something similar? Of course, the underlying software must ignore unknown keys, so it’s not a full win anyway.
That might help for a general comment, but not for a comment on a specific part of the structure.
Re: YAML and Configuration Files
#89Earlier quoted context omitted.
My JSON parser ( github.com/nanoscopic/ujsonin ) has these things: 0. Looks essentially the same as JSON 1. Core data types, and customizable data types can be added easily. 2. Arrays, Objects, and arbitrary nesting. 3. Comments ( both /* */ and // format ) 4. Multiline strings ( by default; carriage returns are no problem within strings ) 5. It is JSON with relaxed restrictions and slight addition for actual named t…
I like the idea of what you're doing. May I suggest a Nim port? Nim outputs C anyway, but is safe, so you'd worry less about bugs.
Thank you.
Glancing through the Nim documentation it doesn't appear to support goto. Searching online reveals one can hack something into the underlying instruction set, but it looks very unclean.
To port my parser I would need to alter the core of the processor a bunch to make it effectively be a large switch statement inside of a loop to build the state machine.
Right now all three implementation are essentially following the same logic with just the language syntax altered between them to make maintenance of all implementations simultaneously easier.
I have spent some time generating ragel grammars for this sort of thing, and ragel can output a number of different languages itself. The code generated by ragel, is, though, quite messy itself and can have random problems that require workarounds, which is why I haven't decided fully upon going down the ragel path.
May I ask what the point is of having a Nim port? You've listed safety; which can be better addressed by building a state machine generator and a state machine DSL. Also, the code is quite small, so I don't think "safety" is the primary concern for the codebase.
Nim compiles to C, C++, and Javascript. I can already effectively run the C parser in JS by compiling to WASM ( and I've done so with my XML parser ) C++ code can call the C code without issue. A wrapper to auto-call object deletion in C++ would be trivial to write.
Rewriting in Nim would not, so far as I can see, offer any benefits to me that are worth the effort.
Re: YAML and Configuration Files
#90> YAML isn't a configuration language or a configuration language format, it's a serialization format I think YAML is even worse as a serialization format than a configuration format. It has too many ambiguities, implementations are too inconsistent, and many implementations are insecure by default with untrusted input. > Using a good custom designed configuration file format instead of trying to shove things through…
> I think YAML is even worse as a serialization format than a configuration format. This. I find YAML to be the least offensive option for configuration and one of the worst for serialization. I might be misinformed, but I find it absurd that in 2021 we still don't have a default, universally available tool that supports the basic table stakes without headache: 1. core data types (number, string, etc) 2. lists, maps,…
Use dhall and serialise to JSON/YAML!