Hacker News new | comments | show | ask | jobs | submit login

Regarding #5, I quite enjoy text-based configuration files, and can't stand systems that force me to use a GUI to change settings. If I have a text-based config file, I know that it will play nicely with git. If there are many related settings, users can change them all quickly with their preferred text editor.



Agreed, text based config files are good and not the problem. (Though binary formats != GUI tools only.)

I think the real problem is config files either in hard-to-parse-correctly custom ad-hoc formats or even "config files" written in a scripting language (-> impossible to parse).

All config files should use the same standard format. I'd say "like YAML", but I'm not aware of a widely-used format with standard features like file includes or data types beyond "int" and "string" (e.g. for time intervals; these really shouldn't be "just a string... with a custom format").


That works fine when config files are simple straight forward text data. But config files can grow increasingly complex over time, and eventually become complex turing complete languages of their own.

I think it would be better to just start with a Turing complete language. I think they should use Lua. It has very simple general data structures that are self explanatory, and its very lightweight and sandboxable.

The only issue is combining config files with other programs. You don't want to strip the comments or formatting when you modify it with another program. Also wish there was a way to specify metadata, like what the possible values for a variable are allowed to be. Or descriptions and help info. With that you could easily convert config files into GUIs.


> I think it would be better to just start with a Turing complete language. I think they should use Lua. .......... when you modify it with another program ...

No! Turing complete config files are even worse than ad-hoc config files.

If your config format is turing complete, you couldn't correctly modify config files automatically. (You wouldn't even know how long until you're done evaluating it.)

If you need more logic, put it in your program or have a plugin system or write a program that generates the config file, but don't put it in the config file.


I don't see anything wrong with adding the option to do scripting. No one is making you use it. But when you need it, there's no alternative.

Many projects start out with just simple config files. But then they realize they need to do logic, and hack that into it. Then they realize they need more complex logic, and hack even more stuff in. And it's just a mess. It would have been much cleaner if they just started out with a scripting language.

Whether you should be putting logic in the config file is a different issue, but as long as people do it or have a need to do it, it's much better than crazy ad hoc solutions.

See these discussions on the issue: https://stackoverflow.com/questions/648246/at-what-point-doe... https://medium.com/@MrJamesFisher/configuration-files-suck-6...


I do understand your point.

But as soon as scripting is supported, it's impossible to write tools that process the config files and always work, especially with untrusted config files. You can't have both.

So the question is: can code be separated from config (like I've proposed above) (the code can still be inlined in the config file, as long as the "root" of the config file is declarative and the boundaries are well-defined)?

If no, which is more important: parseability or flexibility? It's a tradeoff.


What you could do is go the other way around. The program's canonical configuration format is pure data in a well-defined format (XML, JSON, Protocol Buffers, etc.). However, the top-level user-facing configuration is a script, written in a well-known (and ideally easily sandboxed) scripting language, whose output is the configuration data. The script can still load pure data files, which can be automatically analyzed and transformed, and with enough discipline most of the rapidly changing parts of your configuration will live in these pure data files. Even without this discipline, the final output of the configuration script is pure data that can easily be stored separately for tests, diffs, analyses, etc.


The problem with this approach is that there's no way for my program to parse my config file and tell me if I've screwed something up without actually executing the config file, which may be expensive or infeasible to do at program start.

My personal opinion is almost exactly the opposite. If the program's config file requires anything more complicated than a regular language to specify, it's doing too much.


>All config files should use the same standard format. I'd say "like YAML", but I'm not aware of a widely-used format with standard features like file includes or data types beyond "int" and "string" (e.g. for time intervals; these really shouldn't be "just a string... with a custom format").

Not sure how this compares http://raml.org/



I thought of HOCON, it's quite usable for users, but it's not a solution:

1. Lack of adption: It's not widely used yet. Implementations for few languages.

2. No formal spec; the "spec" is very imprecise and seems to try very hard to leave as much as possible to the implementation.

3. The spec is very, very Java specific. No clear separation between "core HOCON" and "Java extensions".

4. It probably doesn't lend itself well to automatic changes in a way that preserves structure of an original file (-> without just rendering out JSON).

It's clear that HOCONs only real focus is being easy to edit manually.

It's a nice idea, but it's definitely not the long term solution we need.


> All config files should use the same standard format.

I can't think of a single format that would lend itself to all cases, but I agree that config files should be in a standard format (i.e. a format that is supported by parsing tools).

YAML++ for being very readable.


XML has includes and you can have data types like string, int, time intervals, strings with regex, etc. with an XSD, if you want.

The complexity this brings can be overwhelming compared to an ad-hoc config file format.


XML is too verbose for manual editing and I've yet to see an XML library that isn't cumbersome to use (compared to JSON). It's probably too complex, alright. But I'm convinced a simpler format could be specified.

But your complexity comparison is unfair. Ad-hoc file formats are overwhelming. Users don't see the complexity because there is no spec and they just write config files by example. Developers generally either give up or write something that doesn't behave quite the same. A fair comparison would be:

  """"
  XML looks like this:

  <section>
    <subsection>
      <key>value</key>
    </subsection>
  </section>
  """
That's about the level of detail in the documentation of most ad-hoc file formats I've seen. Followed by hundreds of examples that happen to show (but not specify) special cases.


The emphasis on doing everything with text is not a problem, it is a major feature of Unix. Configuration management, portability, and interoperability are all a lot easier to do thanks to Unix's dedication to text as the lingua franca of the operating system


+1 for GUI-based configuration being a pain, having a dotfiles repo that I can edit, clone, fork, etc. is magical (and far more flexible).


Never mind being able to put comments in line with the settings to potentially document why the seemingly crazy changes have been applied.


Text config files plus the command line makes explainations and documentation a lot simpler, more concise, and more precise. You can exactly duplicate a series of commands and config changes. "Type this command to edit this config file, change the value of this setting to this other setting, then run this command to reload." Making documentation is often simply a matter of copying from your .bash_history.

Making documentation for graphical programs often requires screenshots and sentences like "click the third radio button on the right-hand section" that add nothing to the documentation and are easily misunderstood by hapless users. Then the developer changes the layout of the dialog box and you need a new set of screenshots. I'll grant that GUIs are more discoverable to a casual user.

I seem to recall that it's possible to automate GUI software but it seems fraught with peril in a way that automation of a commandline and text config system simply is not.


Check out AutoIt for an example of GUI automation. I've used it before as a hacky way to extend GUI programs.


Totally with you. I HATE dealing with Windows server for this very reason. Whereas, even before Puppet and Chef and the like you could mostly automate the deployment and configuration of a new *nix server with shell scripts and config file templates.

Try automating the deployment of a new IIS server 8 years ago. Hell, try it today.


    > Try automating the deployment of a new IIS server 8
    > years ago. Hell, try it today.
I've tried manually setting up a new local development server a couple of times; given up either on that.

"Download this, and this. Then run the Installation Wizard and select this and this and this, and this if you want it but you might not need it. Then install this and reboot. Then run the New Server Configuration Wizard Utility Package. Then ..." (cont. 94 pages) -- every tutorial.




Applications are open for YC Winter 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: