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

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.

Applications are open for YC Winter 2018

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