Hacker News new | ask | show | jobs
by dragonwriter 4734 days ago
> So, coding the configuration of your application is an ideal way to work. Interesting.

You're coding it one way or another; whether you do the whole thing in Python, or most of it in Java and some of it in XML (or YAML, JSON, etc.) because Java is inconvenient.

The main motivation for using XML (YAML, JSON, etc. are equivalent for this purpose) "configuration" over Java "coding" for certain pieces is that: 1. XML, unlike Java, doesn't need to be AOT compiled 2. XML is more naturally suited than Java to a succinct declarative style 3. Its easier for external tools to work with and modify XML than Java, which may be useful for configuration tools.

In many other languages, one or more of these advantages of XML over the main coding languages is less significant or entirely absent (interpreted/JIT-compiled languages avoid #1; functional and many modern multi-paradigm languages avoid #2; Lisps and other easily-parseable homoiconic languages avoid #3.) Depending on the language you are using and which of these factors is important to your use case, there may be no significant reason to bear the cost of a second language for configuration.

1 comments

> You're coding it one way or another;

Yes. I agree, most of these frameworks are in some sense a DSL. I cannot agree that writing in a different language changes the underlying purpose and function of separating configuration from the code.

> I cannot agree that writing in a different language changes the underlying purpose and function of separating configuration from the code.

Language features effect the degree to which the underlying purpose and function of separating service identification from other code requires framework support, and the style of framework which is most sensible to support it to the degree that framework support is necessary.

I can agree with that. Untyped languages seem to allow for better gradients of separation as well as tend to work with a wider variety of tools. It's not always good, but it usually quicker to start with.