Real-world applications need to be configurable. There are lots of reasons an app must be configured - different environment, modify the thresholds, even change what providers are used for a task. There's a big difference between coding, and configuration:
Configuration implies using knowledge of the domain to tweak the app, after it's been deployed, usually via a small number of config files.
|Requires knowledge of language syntax||Yes (and usually for many languages)||No (syntax is usually just xml. A huge point of configs is that they abstract out syntax).|
|Requires business domain knowledge||Yes||Yes|
|Requires re-compiling||Sometimes (C#, Java --> Yes, Html/Sql --> No)||No. Usually just xml or plain text|
|Number of files||Many - a 10,000 line app, with 50 files, could still just have 1 app.config||Few (usually just 1, or 1 per directory)|
More and more, the push is to abstract coding into configuration. I believe WCF is big on this - instead of getting bogged down in how to transport data (web services, remoting, FTP, messaging, etc...) you just configure the app as appropriate. We also see this in domain specific languages and code generation. For example, .Net tiers has a big config file, but it makes perfect sense if you understand the concepts of N-Tier architecture. So, you can do a little configuration, and it generates 1000s of lines, which spares you from tons of tedious coding.