Comment by patrickmay | Hacker News Reader

Comment by patrickmay | Hacker News Reader

"The whole nasty 'configuration' problem becomes incredibly more convenient in the Lisp world. No more stanza files, apache-config, .properties files, XML configuration files, Makefiles — all those lame, crappy, half-language creatures that you wish were executable, or at least loaded directly into your program without specialized processing. I know, I know — everyone raves about the power of separating your code and your data. That's because they're using languages that simply can't do a good job of representing data as code. But it's what you really want, or all the creepy half-languages wouldn't all evolve towards being Turing-complete, would they?"

This touches on the core problem with the whole Java ecosystem. The existence of so many tools demonstrates, first, that the underlying technology is insufficiently expressive and, second, that many programmers would rather create tools than applications.

Leaving the second aside, the kinds of tools required for Java development are largely unnecessary in the Lisp world because the language itself is expressive and extensible. You don't need different representations for data and code, separate parsers, and frankly bizarre build systems (coughmavencough).

As ESR, I believe, said "Lisp is worth learning for the profound enlightenment experience you will have when you finally get it." Unfortunately, it also makes you more aware that things don't have to be as bad as they are in the Java world.

Hopefully s-expressions will be the next aspect of Lisp rediscovered in "modern" programming languages.

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.

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.

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.

> 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?

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.

What??? Java is bad because it can't store data as code? (a) That's stupid (b) That applies to every other language in the world which isn't a lisp or scheme.

Python can do it. As I'm sure every interpreted language can.

e.g.

./data.py:

me = "RamiK"

EOF

./code.py

import data

print(data.me)

EOF

I think we can wait a long time (not infinite hopefully) before people let go of complex syntax (order of ~yacc) for smaller, simpler yet more programmatic (sexp, forth).

This discussion is tempting me to dust off my partially finished Scheme-based clone of Ant.

next: sexp based systemd

http://www.gnu.org/software/dmd/

Didn't know it was using scheme. Kudos. I wonder if anyone is using guix + dmd

I use Guix on top of Debian right now, but not dmd. Things are getting closer to the point of having a full Guix system, but we're not there yet.

http://usesthis.com/

Please do.

Let me see if I can channel some of ESR's pomposity: If S-expressions are the answer, you're asking the wrong question.

I don't know why you got downvoted.

Reply on news.ycombinator.com