4 ms·

> StrictYAML, by contrast, was designed to be a language to write readable 'story' tests where there will be many files per project with more complex hierarchie

> StrictYAML, by contrast, was designed to be a language to write readable 'story' tests where there will be many files per project with more complex hierarchies, a use case where TOML starts to really suck. I can’t be the only one who feels this way; isn’t it this use case the thing that sucks? “plain text but not really” config formats that aren’t “code” but have special syntax but lack a debugger and handy IDE tools and you’re never really sure of what you’re doing … isn’t that the thing that sucks?

masklinn 3y ago
That was also my first reaction opening the example, I’m perfectly fine with a half-assed programming language (embedding more programming languages) not working in TOML, I don’t think it works in yaml in the first place, and it’s exactly the sort of usual mess which makes me recoil at the sight of a yaml extension. This specific example is like somebody saw cucumber and went “I think this should be a lot worse, and in an ecosystem which doesn’t want to come anywhere near that too”. This would probably be half the size and actually comprehensible if it were just a pytest test file.
- hitchstory 3y ago
  Hi, I'm the author of hitchstory. With the stories in YAML two new use cases (which are demonstrated in the example projects) are enabled: * Automatically updated how-to docs. I used to write these types of docs manually and if they existed at all they would ALWAYS get out of sync with the code and were painful to maintain manually. Now I have YAML files and a simple jinja2 template I can push out new markdown how-to docs on each new build - with snippets of JSON, screenshots from the app, whatever. * Tests that rewrite themselves. E.g. if I have a REST API test of the form "call API x and expect y blob of json", I don't have to actually write that blob of json into the test, I just write the code that produces it and run the test in rewrite mode so it updates the "expected JSON" field with actual json. I can then eyeball it and 20 seconds later it's part of the test and part of the docs. The productivity improvements from doing both of these things means that writing tests is cheaper so I do more of them. Having how-to docs for all scenarios is way cheaper so I now always have them. These use cases are impossible with pytest. They are impossible with cucumber. They would be too painful to maintain with regular (i.e. not type-safe) YAML and those stories have enough indents that they would be an epic unreadable mess of syntactic noise if they were built in something like TOML or JSON.
  - skrebbel 3y ago
    The second thing reminds me of how Jest does snapshot testing: the first time you run it, it simply edits the JS source file with the result. For a test runner to edit test code feels weird at first but it works spectacularly well.
  - dharmab 3y ago
    The first thing reminds me of example tests in Go: https://go.dev/blog/examples https://go.dev/blog/examples
    - hitchstory 3y ago
      Similar. It's like that but in reverse. Instead of running snippets of your docs as code, the tests and their metadata are used to compile doc snippet or entire how to docs pages.
      - dharmab 3y ago
        That is how Go's examples work- your example tests are inlined into the GoDocs at pkg.go.dev
  - fishyjoe 3y ago
    > Tests that rewrite themselves. That sounds like expect tests in OCaml [1]. I've found them quite a joy to work with and I'm surprised more languages don't have something similar. [1] https://dev.realworldocaml.org/testing.html#expect-tests https://dev.realworldocaml.org/testing.html#expect-tests
  - Terretta 3y ago
    Your way of thinking, shared transparently not just in your "why not" section but throughout, is a breath of fresh air in the miasma of grabbing a tech because dogma or hype. It's not that I agree with all your choices. It's that I'll defend to the end your method of making them.
schmuelio 3y ago
Yeah that use case really sounds like they're on the cusp of just making a DSL from a config language. If you need it to be _that_ complex then just write your configs as code...
myaccountonhn 3y ago
I agree, I quite like https://dhall-lang.org/ https://dhall-lang.org/ for that reason. It strikes a good balance between features and being a config language.
marcosdumay 3y ago
I don't have any problem with complex "symbol vs literal" resolving in configuration languages. Unless your syntax is very weird, it should be very hard to confuse those. That said, YAML's syntax is very weird. YAML just sucks. And any such implementation must necessarily be unityped (up to the point where the data is coerced into the configuration structure at your program) and completely preserve the original data. TOML could be extended to support it. I don't think it's "tasteful", but I see no practical problems with it.
- masklinn 3y ago
  > TOML could be extended to support it. Seems doubtful as that's specifically something TOML was created not to support. If you want unityped ini files you can define that dialect of ini files.

masklinn 3y ago

That was also my first reaction opening the example, I’m perfectly fine with a half-assed programming language (embedding more programming languages) not working in TOML, I don’t think it works in yaml in the first place, and it’s exactly the sort of usual mess which makes me recoil at the sight of a yaml extension. This specific example is like somebody saw cucumber and went “I think this should be a lot worse, and in an ecosystem which doesn’t want to come anywhere near that too”. This would probably be half the size and actually comprehensible if it were just a pytest test file.

hitchstory 3y ago
Hi, I'm the author of hitchstory. With the stories in YAML two new use cases (which are demonstrated in the example projects) are enabled: * Automatically updated how-to docs. I used to write these types of docs manually and if they existed at all they would ALWAYS get out of sync with the code and were painful to maintain manually. Now I have YAML files and a simple jinja2 template I can push out new markdown how-to docs on each new build - with snippets of JSON, screenshots from the app, whatever. * Tests that rewrite themselves. E.g. if I have a REST API test of the form "call API x and expect y blob of json", I don't have to actually write that blob of json into the test, I just write the code that produces it and run the test in rewrite mode so it updates the "expected JSON" field with actual json. I can then eyeball it and 20 seconds later it's part of the test and part of the docs. The productivity improvements from doing both of these things means that writing tests is cheaper so I do more of them. Having how-to docs for all scenarios is way cheaper so I now always have them. These use cases are impossible with pytest. They are impossible with cucumber. They would be too painful to maintain with regular (i.e. not type-safe) YAML and those stories have enough indents that they would be an epic unreadable mess of syntactic noise if they were built in something like TOML or JSON.
- skrebbel 3y ago
  The second thing reminds me of how Jest does snapshot testing: the first time you run it, it simply edits the JS source file with the result. For a test runner to edit test code feels weird at first but it works spectacularly well.
- dharmab 3y ago
  The first thing reminds me of example tests in Go: https://go.dev/blog/examples https://go.dev/blog/examples
  - hitchstory 3y ago
    Similar. It's like that but in reverse. Instead of running snippets of your docs as code, the tests and their metadata are used to compile doc snippet or entire how to docs pages.
    - dharmab 3y ago
      That is how Go's examples work- your example tests are inlined into the GoDocs at pkg.go.dev
- fishyjoe 3y ago
  > Tests that rewrite themselves. That sounds like expect tests in OCaml [1]. I've found them quite a joy to work with and I'm surprised more languages don't have something similar. [1] https://dev.realworldocaml.org/testing.html#expect-tests https://dev.realworldocaml.org/testing.html#expect-tests
- Terretta 3y ago
  Your way of thinking, shared transparently not just in your "why not" section but throughout, is a breath of fresh air in the miasma of grabbing a tech because dogma or hype. It's not that I agree with all your choices. It's that I'll defend to the end your method of making them.

schmuelio 3y ago

Yeah that use case really sounds like they're on the cusp of just making a DSL from a config language. If you need it to be _that_ complex then just write your configs as code...

myaccountonhn 3y ago

I agree, I quite like https://dhall-lang.org/ https://dhall-lang.org/ for that reason. It strikes a good balance between features and being a config language.

marcosdumay 3y ago

I don't have any problem with complex "symbol vs literal" resolving in configuration languages. Unless your syntax is very weird, it should be very hard to confuse those. That said, YAML's syntax is very weird. YAML just sucks. And any such implementation must necessarily be unityped (up to the point where the data is coerced into the configuration structure at your program) and completely preserve the original data. TOML could be extended to support it. I don't think it's "tasteful", but I see no practical problems with it.

masklinn 3y ago
> TOML could be extended to support it. Seems doubtful as that's specifically something TOML was created not to support. If you want unityped ini files you can define that dialect of ini files.