8 ms·

This makes me sad. It's 2021 and we still haven't figure out how to serialize configuration in a format that is easy-to-edit and predictable.

trhway 6y ago
XML with a convenient UI tools to edit should have fit the bill. Yet, for whatever reason a convenient UI tool would never happen to be there when needed, and thus scared and tired of manual editing of XML the world have embraced YAML.
- masklinn 6y ago
  > XML with a convenient UI tools to edit should have fit the bill. "You need this special tool to work" immediately and instantly rules out "easy to edit". Or makes the debate irrelevant: every format is easy to edit if you have "a convenient UI" to do it for you.
  - anticristi 6y ago
    Opening XMLs in ZIP containers is easy! Just spin up Word. :)
  - sergeykish 6y ago
    The fault was in XML editing, pure data authoring is hard. We have convenient UI — web browser, think of it as literate programming, a way to merge man page and configuration file. And plain text editor is a "widely deployed special tool to work". Actual data is countries:\n- GB\n- IE\n- FR\n- DE\n- NO Or 636f 756e 7472 6965 733a 0a2d 2047 420a 2d20 4945 0a2d 2046 520a 2d20 4445 0a2d
imhoguy 6y ago
We had such: XML. With proper editor support it is easy. I guess it needs rediscovery /s ;)
- anticristi 6y ago
  I used XML and didn't like it: - A proper editor was never around. - Closing tags were verbose. - Attributes vs tags was confusing. - It didn't map "naturally" to common data types, like lists, maps, integers, float, etc.
  - mattmanser 6y ago
    Don't forgot about namespaces, another fiddly bit of XML that caused all sorts of problems and headaches.
  - sergeykish 6y ago
    You've just used XML tech as it was designed to post this comment. XML is serialization. I hardly believe you was concerned about serialization while posting comment or thought about attributes-tags distinction. This page utilizes request to server for multi-user editing. But it is easy to build truly serverless (like a file) document with same interface: data:text/html,<html><ul>Host: <span class=host contenteditable>example.com Change it, save it, done. Web handles input of lists, maps, integers, float and much more.
    - anticristi 6y ago
      You are right. XML is great for encoding the DOM. However, I didn't find it practical for interfacing with humans, due to the concerns I raised.
      - sergeykish 6y ago
        It is not practical to edit plain text in binary: 636f 756e 7472 6965 733a 0a2d 2047 420a 2d20 4945 0a2d 2046 520a 2d20 4445 0a2d It is not practical to edit Excel documents in plain text: <?xml version="1.0"?> <Workbook xmlns="urn:schemas-microsoft-com:office:spreadsheet" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:html="http://www.w3.org/TR/REC-html40"> <Worksheet ss:Name="Sheet1"> <Table> <Row> <Cell><Data ss:Type="String">ID</Data></Cell> Tim Berners-Lee browser was browser-editor. Can't you see parallels?
kstenerud 6y ago
This is the problem space I'm targeting with https://concise-encoding.org/ https://concise-encoding.org/ * Text AND binary so that humans can edit easily, and machines can transmit energy and bandwidth efficiently. * Carefully designed spec to avoid ambiguities (and their security implications). * Strong type support so you're not using all kinds of incompatible hacks to serialize your data. * Versioned, because there's no such thing as the perfect format. * Also, the website is 32k bytes ;-)
- anticristi 6y ago
  Nice! I like some concepts that this format proposes, but the `@` and `|` modifier feels a bit too "loaded".
  - kstenerud 6y ago
    It's a compromise; there are only so many letters, numbers, and symbols available in a single keystroke on all keyboards, and I don't want there to be any ambiguity with numbers and unquoted strings (e.g. interpreting the unquoted string value true as the boolean value true). So everything else needs some kind of initiator and/or container syntax to logically separate it from the other objects when interpreted by a human or machine.
- chousuke 6y ago
  I'm skimming through the human readable spec, and it seems decent, but I noticed the spec allows unquoted strings. What's the reasoning for this? In my experience unquoted strings cause nothing but trouble, and are confusing to humans who may interpret them as keywords. Any reason for not using RFC2119 keywords in the spec? Using them should make the spec easier to read.
  - kstenerud 6y ago
    > I noticed the spec allows unquoted strings. What's the reasoning for this? In my experience unquoted strings cause nothing but trouble, and are confusing to humans who may interpret them as keywords. Unquoted strings are much nicer for humans to work with. All special keywords and object encodings are prefixed with sigils (@, &, $, #, etc), so any bare text starting with a letter is either a string or an invalid document, and any bare text starting with a numeral is either a number or an invalid document. > Any reason for not using RFC2119 keywords in the spec? Using them should make the spec easier to read. I use a superset of those keywords to give more precision in meaning: https://github.com/kstenerud/concise-encoding/blob/master/ce-structure.md#terms https://github.com/kstenerud/concise-encoding/blob/master/ce...
unhammer 6y ago
https://dhall-lang.org/ https://dhall-lang.org/ ?

trhway 6y ago

XML with a convenient UI tools to edit should have fit the bill. Yet, for whatever reason a convenient UI tool would never happen to be there when needed, and thus scared and tired of manual editing of XML the world have embraced YAML.

masklinn 6y ago
> XML with a convenient UI tools to edit should have fit the bill. "You need this special tool to work" immediately and instantly rules out "easy to edit". Or makes the debate irrelevant: every format is easy to edit if you have "a convenient UI" to do it for you.
- anticristi 6y ago
  Opening XMLs in ZIP containers is easy! Just spin up Word. :)
- sergeykish 6y ago
  The fault was in XML editing, pure data authoring is hard. We have convenient UI — web browser, think of it as literate programming, a way to merge man page and configuration file. And plain text editor is a "widely deployed special tool to work". Actual data is countries:\n- GB\n- IE\n- FR\n- DE\n- NO Or 636f 756e 7472 6965 733a 0a2d 2047 420a 2d20 4945 0a2d 2046 520a 2d20 4445 0a2d

imhoguy 6y ago

We had such: XML. With proper editor support it is easy. I guess it needs rediscovery /s ;)

anticristi 6y ago
I used XML and didn't like it: - A proper editor was never around. - Closing tags were verbose. - Attributes vs tags was confusing. - It didn't map "naturally" to common data types, like lists, maps, integers, float, etc.
- mattmanser 6y ago
  Don't forgot about namespaces, another fiddly bit of XML that caused all sorts of problems and headaches.
- sergeykish 6y ago
  You've just used XML tech as it was designed to post this comment. XML is serialization. I hardly believe you was concerned about serialization while posting comment or thought about attributes-tags distinction. This page utilizes request to server for multi-user editing. But it is easy to build truly serverless (like a file) document with same interface: data:text/html,<html><ul>Host: <span class=host contenteditable>example.com Change it, save it, done. Web handles input of lists, maps, integers, float and much more.
  - anticristi 6y ago
    You are right. XML is great for encoding the DOM. However, I didn't find it practical for interfacing with humans, due to the concerns I raised.
    - sergeykish 6y ago
      It is not practical to edit plain text in binary: 636f 756e 7472 6965 733a 0a2d 2047 420a 2d20 4945 0a2d 2046 520a 2d20 4445 0a2d It is not practical to edit Excel documents in plain text: <?xml version="1.0"?> <Workbook xmlns="urn:schemas-microsoft-com:office:spreadsheet" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:html="http://www.w3.org/TR/REC-html40"> <Worksheet ss:Name="Sheet1"> <Table> <Row> <Cell><Data ss:Type="String">ID</Data></Cell> Tim Berners-Lee browser was browser-editor. Can't you see parallels?

kstenerud 6y ago

This is the problem space I'm targeting with https://concise-encoding.org/ https://concise-encoding.org/ * Text AND binary so that humans can edit easily, and machines can transmit energy and bandwidth efficiently. * Carefully designed spec to avoid ambiguities (and their security implications). * Strong type support so you're not using all kinds of incompatible hacks to serialize your data. * Versioned, because there's no such thing as the perfect format. * Also, the website is 32k bytes ;-)

anticristi 6y ago
Nice! I like some concepts that this format proposes, but the `@` and `|` modifier feels a bit too "loaded".
- kstenerud 6y ago
  It's a compromise; there are only so many letters, numbers, and symbols available in a single keystroke on all keyboards, and I don't want there to be any ambiguity with numbers and unquoted strings (e.g. interpreting the unquoted string value true as the boolean value true). So everything else needs some kind of initiator and/or container syntax to logically separate it from the other objects when interpreted by a human or machine.
chousuke 6y ago
I'm skimming through the human readable spec, and it seems decent, but I noticed the spec allows unquoted strings. What's the reasoning for this? In my experience unquoted strings cause nothing but trouble, and are confusing to humans who may interpret them as keywords. Any reason for not using RFC2119 keywords in the spec? Using them should make the spec easier to read.
- kstenerud 6y ago
  > I noticed the spec allows unquoted strings. What's the reasoning for this? In my experience unquoted strings cause nothing but trouble, and are confusing to humans who may interpret them as keywords. Unquoted strings are much nicer for humans to work with. All special keywords and object encodings are prefixed with sigils (@, &, $, #, etc), so any bare text starting with a letter is either a string or an invalid document, and any bare text starting with a numeral is either a number or an invalid document. > Any reason for not using RFC2119 keywords in the spec? Using them should make the spec easier to read. I use a superset of those keywords to give more precision in meaning: https://github.com/kstenerud/concise-encoding/blob/master/ce-structure.md#terms https://github.com/kstenerud/concise-encoding/blob/master/ce...

unhammer 6y ago

https://dhall-lang.org/ https://dhall-lang.org/ ?