Hacker News Reader

Comment by yummyfajitas | Hacker News Reader

I have no difficulty with configuration. I have a reference.conf which provides sensible defaults and is bundled in the jar file:

    cache {
      ttl = 1024
    }

I have an application.conf which belongs on the classpath and contains location specific configuration:

    cache { 
      redis_server = "123.456.789.012:6379"
    }

In my code, I do this:

    server = getRedisServer(config.getString("cache.redis_server"))
    server.put(key, value, ttl=config.getInt("cache.ttl")

https://github.com/typesafehub/config

Java does have fugly enterprisey frameworks. But it's silly to claim that this is some property of Java.

Incidentally, Python also does "code as data as config" also - see django's settings.py, for example.

View on HN

You're correct that the particular tools and XML everywhere culture of the Java ecosystem isn't a property of Java itself. However, the verbosity and corresponding lack of expressiveness of Java does, I think, have an impact.

Elegance seems to be much more highly valued in the Lisp world than in the Java world.

All the languages that get wide adoption at the enterprise level suffer from similar issues.

I think it is something that is bound to the enterprise architect culture.

All the enterprise users want the tool to fit their work flow. They don't want to have to change their workflow to fit the tool (no matter how stupidly inefficient their workflow is). This means that the enterprise tool vendors all need to create tools that are highly configurable. In fact, they often have to be customized for each different customer.

This leads to enterprise software vendors trying to write extension/customization languages for their tools. And of course, they almost all do it badly, and they all do it differently. (If you're hearing an echo of Greenspun's tenth law here, well, yes, I think that this is exactly what he was talking about.)

Maybe it'd better to write that as: Only the languages that suffer from similar issues get wide adoption at the enterprise level. (Yet, I don't think that completely captures causality.)

Enterprise architects have a surprisingly big diversity of culture. I'd look first at the process by what enterprises choose their development stacks. It often has little input from architects, developers, testers, or admins.

My employer does enterprise consulting in Fortune 500 companies, the developer stacks and architecture designs we sometimes end up doing, chosen by architects, end up in what is usually called "space station architecture".

I think it comes down to the perceived lack of value to the enterprise of elegance in programming languages.

It's possible in any language, although usually not done with compiled languages, because then the user needs to recompile after every change to the configuration, and distributing as a binary becomes impossible. Usually not, but sometimes: I use the dwm window manager, which is written in C and configured by changing a header file and recompiling. The author points out several advantages to this, including scaring away inexperienced users who would bug him with questions.

You don't need to recompile a typesafe config. Application.conf overrides reference.conf - the latter only provides defaults.

Recompiling a Config.scala file is fast anyway unless you change the type signature.

Consider all of the code that goes into making typesafe config work. Then contrast that with the code necessary to store configuration as sexps.

Yes, typesafe config is an external library rather than using the built in interpreter. That is extra code.

If you wanted to do things in equivalent lisp style, you'd just compile a Config.java/Config.scala file and add it to the classpath. That's only a few extra lines in your ansible script. Your configuration will be statically typedchecked - failure to include a required parameter or including a param of the wrong type will result in a compile failure.

This is unconventional but a very reasonable way to go. At the moment I'm just using typesafe config because it's more or less the standard, but the more I think about it the more I like the idea of compiling my config.

> If you wanted to do things in equivalent lisp style, you'd just compile a Config.java/Config.scala file and add it to the classpath.

That's really not equivalent though. With Java and Scala, there's a sharp divide between what's code and what's data. Even if you create a Config.java class, you can still point to some bits and say "that's Java code" and other bits (like primitives or array literals) and say "that's data". Java doesn't know how to treat the code bits like data, or the data bits like code.

This means that there's a whole load of cool stuff that you just can't do with your Config.java that you could with a config file holding Lisp code. For one, you couldn't use macros to easily pre-process your config file. Or, as Yegge pointed out, you couldn't just turn the tag names (in an xml like structure) into functions that transform themselves.

Newer versions of Spring use Java for configuration. As you said, it's pretty cool to be able to compile and type check your config. As cool as that is though, it's not at all the same as putting your config in Lisp code.

In addition to my other comment. One giant difference is creating said file. It is trivial to output files like this from lisp. Not so much for java/scala/whatever.

Consider, if you were to do this the way you are describing. How would you support saving updates to the configuration from within the application?

I think the point is often best regarded as annoyance by lispers that it has taken so much code and time to get back to where they were at the start.

Reply on news.ycombinator.com