3 ms·

- legible: readable and editable without special programmes - documentation generator: aside from "human readable", have tooling support for documentation gene

- legible: readable and editable without special programmes - documentation generator: aside from "human readable", have tooling support for documentation generation - syntax/plausibility checking: tooling support for consistency checks - UTF8 support - variables: specify and populate placeholders - modularisation: compose configurations out of reusable modules - templates: something like #define in C - concise: json, yaml and xml are too verbose imho. Maybe make use of special characters like ,!() etc for syntactical brevity - unambiguous: indentation, capitalisation, the type of quotes etc shouldn't be syntactically relevant - pluggability: APIs & libraries that allow using the language in my programmes

logicallee 4y ago
Thanks, these are great tips. >concise: json, yaml and xml are too verbose imho I'm very surprised you include yaml in this. It doesn't seem to require me to use any syntax except a colon to separate the name from the value. (and optionally indentation to specify when something is logically a child value). How can that be too verbose? What would be a less verbose version? You and others have all mentioned variables and placeholders to avoid repetition. How do you suggest specifying a variable? > unambiguous: indentation, capitalisation, the type of quotes etc shouldn't be syntactically relevant since you say types of quotes shouldn't be relevant how do you suggest I differentiate a generated image from a named one? I was thinking of making it: module_image:"images/module.png" to specify the path if the user created their own image, or allow them to generate one using: module_image: generate if they want the script to generate one using the module name, or they can follow generate with a prompt in quotes like this: module_image=generate "keywords to use for image generation" This would mean there are three formats module_image: would support depending on whether and where quotes are used. Without using quotes to differentiate, how would you suggest I let the user ask the script to generate the image for them rather than naming the location of the image? Thank you for your feedback.
- ggeorgovassilis 4y ago
  tl;dr: I don't know. That's why evening after evening I go on the internet and hope somebody smarter than me will solve humanity's problems. Reflecting on my remarks, I think I had large configurations in mind as they occur in kubernetes or terraform which can be tens of pages. > How can that be too verbose? I meant that yaml indentations eat up screen space, every attribute needs to go on a new line and is terminated by a colon, which seems redundant since the newline already delimits attributes. If you ever have written a large k8s deployment descriptor, you'll know that yaml is not the right language for describing complex configurations. > How do you suggest specifying a variable? Variables should probably be set outside the template, eg. reference environment variables or be set in INI or properties files... which makes them parameters rather than variables but potato potato. The template could then reference variables by a special notation eg. $myvar or following a naming convention eg. vMyVar. > how do you suggest I differentiate a generated image from a named one? I worded that poorly. I think parsers get too hang up on the details. '"`’«» etc could be all syntactic equals, unless a good use case justifies different meanings. Eg. bash has different meanings for different types of quotes. The parser probably could infer when a statement is a literal vs. a reference simply by checking if the reference exists. > Thank you for your feedback. If you put the specification for your configuration language on a git repo then interested parties could open issues and discuss specific topics.
  - logicallee 4y ago
    Thank you for your thoughts. Since the app itself doesn't have users yet I think it might be overkill to start discussing the configuration on its own git repo! However I will take everything you wrote into consideration and I appreciate the time you took to respond. I especially liked the clarification about screen space, which I'll use to ensure I don't nest things more than 1 max 2 levels. By the way, although it is too much to open a repo for it, what do you think about this UML for how I structure the parts of the application? https://imgur.com/a/FUTphwa https://imgur.com/a/FUTphwa (I already have the parts working.) The user talks to the voice recognition engine which is a subprocess of the voice recognition server. In terms of what to do (actions to take) the voice recognition takes configuration files and dispatches scripts. To give feedback to the user the voice recognition server also communicates via a web interface. (i.e. the user could have this web interface open and see what actions the home automation server is taking, which scripts have been launched etc.) Do you think this structure is all right for a configurable voice recognition automation server app?

logicallee 4y ago

Thanks, these are great tips. >concise: json, yaml and xml are too verbose imho I'm very surprised you include yaml in this. It doesn't seem to require me to use any syntax except a colon to separate the name from the value. (and optionally indentation to specify when something is logically a child value). How can that be too verbose? What would be a less verbose version? You and others have all mentioned variables and placeholders to avoid repetition. How do you suggest specifying a variable? > unambiguous: indentation, capitalisation, the type of quotes etc shouldn't be syntactically relevant since you say types of quotes shouldn't be relevant how do you suggest I differentiate a generated image from a named one? I was thinking of making it: module_image:"images/module.png" to specify the path if the user created their own image, or allow them to generate one using: module_image: generate if they want the script to generate one using the module name, or they can follow generate with a prompt in quotes like this: module_image=generate "keywords to use for image generation" This would mean there are three formats module_image: would support depending on whether and where quotes are used. Without using quotes to differentiate, how would you suggest I let the user ask the script to generate the image for them rather than naming the location of the image? Thank you for your feedback.

ggeorgovassilis 4y ago
tl;dr: I don't know. That's why evening after evening I go on the internet and hope somebody smarter than me will solve humanity's problems. Reflecting on my remarks, I think I had large configurations in mind as they occur in kubernetes or terraform which can be tens of pages. > How can that be too verbose? I meant that yaml indentations eat up screen space, every attribute needs to go on a new line and is terminated by a colon, which seems redundant since the newline already delimits attributes. If you ever have written a large k8s deployment descriptor, you'll know that yaml is not the right language for describing complex configurations. > How do you suggest specifying a variable? Variables should probably be set outside the template, eg. reference environment variables or be set in INI or properties files... which makes them parameters rather than variables but potato potato. The template could then reference variables by a special notation eg. $myvar or following a naming convention eg. vMyVar. > how do you suggest I differentiate a generated image from a named one? I worded that poorly. I think parsers get too hang up on the details. '"`’«» etc could be all syntactic equals, unless a good use case justifies different meanings. Eg. bash has different meanings for different types of quotes. The parser probably could infer when a statement is a literal vs. a reference simply by checking if the reference exists. > Thank you for your feedback. If you put the specification for your configuration language on a git repo then interested parties could open issues and discuss specific topics.
- logicallee 4y ago
  Thank you for your thoughts. Since the app itself doesn't have users yet I think it might be overkill to start discussing the configuration on its own git repo! However I will take everything you wrote into consideration and I appreciate the time you took to respond. I especially liked the clarification about screen space, which I'll use to ensure I don't nest things more than 1 max 2 levels. By the way, although it is too much to open a repo for it, what do you think about this UML for how I structure the parts of the application? https://imgur.com/a/FUTphwa https://imgur.com/a/FUTphwa (I already have the parts working.) The user talks to the voice recognition engine which is a subprocess of the voice recognition server. In terms of what to do (actions to take) the voice recognition takes configuration files and dispatches scripts. To give feedback to the user the voice recognition server also communicates via a web interface. (i.e. the user could have this web interface open and see what actions the home automation server is taking, which scripts have been launched etc.) Do you think this structure is all right for a configurable voice recognition automation server app?