« RFC 3930 | Main | 502 Bad MVC Framework »

Execute this: managing configuration in programming languages

Sean hones in on an aspect of GMail's use of Javascript:

Web clients carry around a basic, low level programming language called Javascript. The real beauty of Javascript is that it is dynamic - you can blurr the distinction between code and data. You can hoist the level of abstraction you work with in your app by layering domain specific concepts on top of it in the form of functions and data structures. You can sling across data structures already teed up for use on the other end with the aid of the magic of "eval". You can implement complex behaviour by sending across a program to be run rather than trying to explain what you want done declaratively to the other side.
Now, in such a world - would you send XML data to and fro? Developers with a static typing programming language background might be inclined to say yes but I suspect javascriptophiles, lispers, pythoneers and rubyites are more likely to say no. Reason being, it is so much more natural to exchange lumps of code - mere text strings remember - that can be eval'ed to re-create the data structure you have in the XML. - Sean McGrath

There are more trivial but not to be underestimated uses to such an ability. Configuration is one such use. In Python/Jython, you can define your configuration files using plain code and import the configuration file for use. For example:

   minute=60
   session_timeout=minute*30

is a perfectly good and clear way of doing things - the intepreter will assign to session_timeout without the need for the programmer to write any tedious setup code (try doing that in a Java properties file). And given that more and more developer time is spent in configuration and declaration (be it setting things up or writing tools to read and write things to set up) this is good thing. Being able to define configuration in terms of functions and inbuilt data structures such as lists and dictionaries rather than string literals is not only useful and powerful, it also lowers the burden on developers by reducing the number of config languages in the system.

Of course you could do this in Java with a configuration object. But hardly anyone does this - most would consider it hard coding of data, the wrong thing to do. Perhaps this is because there is sufficient effort in compiling and packaging Java that we have always preferred to use XML or .properties files as being less work. That's worth some emphasis - it's considered less work to write XML configuration files for Java than use Java itself for configuration. Languages like Javascript, Ruby and Python having managed to avoid placing that level of obstacle in front of developers. Some might consider that a wakeup call, given how despised "configuration hell" is by Java developers. I imagine some of this argument holds for C# assemblies as well.

Another example comes from trying to distribute and manage system configurations - HP have been developing such a system, or 'fabric', under a OSS licence called SmartFrog. They considered the options, such as XML, but the language they came up looks something like a scripting one.

A significant argument against moving code over the wire and running it is security - eval() will no doubt make some people nervous. Consider this from the SmartFrog FAQ

Q: How secure is SmartFrog?
A: Without security, SmartFrog would be a near-perfect virus transmission engine! Fortunately, we have taken security seriously, and the system protects itself from malicious use using a public key infrastructure (PKI) system. Each node that participates in a SmartFrog runtime system is supplied with a certificate. Furthermore, all software components and system descriptions are signed with a certificate. The certificates are used to permit only validated nodes to participate in the runtime system, and those nodes will only manipulate components and descriptions that have been appropriately signed. Additionally, all network communication takes place using an encrypted transport. Currently there is a single-level security model, where nodes and components are either fully trusted or not trusted at all. Finer grained models of security are currently being researched.

Update: Steve Loughran pointed out in comments that SmartFrog is not a scripting language..

SmartFrog is not a scripting language.
It is a declarative language that is even less scripty than ant, because it evaluates all references in a resolution phase that doesnt depend on the order of execution of things (unlike ant's property resolution which depends upon execution order)
So what you are really doing is uploading a configuration over the wire, just one that can choreograph stuff, including shell scripts (which you can insert inline into the runsh component)

...which dents my argument a bit. Oh well :)

Others will point out that having a static type system allows for secure runtimes in ways that a dynamic type systems does not. Thankfully there has been significant research, practice and experience to draw from (ranging from Perl's strict mode, to the Java sandbox, to web browsers running code securely, even agent programming arcana such as Telescript) It's not as though data for execution is not being sent around already today. It is, but it's not normally talked about as such. Consider that a huge amount of forms based traffic going over the web is ultimately obfuscated SQL, or that you are probably downloading Javascript every day onto your computer for execution - GMail is taking this a few notches higher. Security concerns notwithstanding, there is a clear need to move behaviour over the wire in ways that are not as well-supported as we might like.

The point seem to be this: it is beneficial to lower the distinction between declarative data and code. Lisp hackers have known the value of blurring the distinction for decades; only now is it becoming an imperative to consider the idea in mainstream distributed programming.

Having discussed Java, it should be mentioned that Java's designers are aware of this benefit. In the past, Bill Joy has argued to the limits of XML by claiming that passing around static data is not enough; you always end up needing to pass behaviour around, even if it's only a stylesheet. Joy was involved in Java's Jini framework which features code mobility and then JXTA. Java itself has always allowed for mobile code, going back as far as Applets and the JVM sandbox model. Ironically it may turn out that Joy was right all along, but due to Java's compilation and packaging mechanisms lost out on flexibility.


October 30, 2004 03:15 PM

Comments

Steve Loughran
(October 30, 2004 05:29 PM #)

SmartFrog is not a scripting language.

It is a declarative language that is even less scripty than ant, because it evaluates all references in a resolution phase that doesnt depend on the order of execution of things (unlike ant's property resolution which depends upon execution order)

So what you are really doing is uploading a configuration over the wire, just one that can choreograph stuff, including shell scripts (which you can insert inline into the runsh component)

The interpretation of all those config files depends on which components are loaded -you can refer to new JARs with sfCodebase attributes in your deployment descriptors. When security is turned on, nothing, not even local JARs, are loaded if they are unsigned. So it is deeply paranoid. Oh, and all comms are RMI over HTTPS; no listening in either.

I'll comment on the why-no-XML some other time. Suffice to say, there is work in the grid forum on an XML language, and the deeply protocol will be built on (sigh) WS-RF. Its going to be v. hard to do an XML representation that is usable by humans, and XSD doesnt help; there is a good argument for RDF here, perhaps in the N3 form.

Bill de hra
(October 30, 2004 06:08 PM #)

"SmartFrog is not a scripting language."

I've lifted some of your comment in the entry text. Thanks for setting me straight :)

Jason Yip
(October 31, 2004 12:25 AM #)

How about using something like BeanShell or Jython?

Diego Sevilla
(November 1, 2004 10:26 PM #)

Hi, Bill:

You also can find other examples in emacs's .emacs files (using emacs-lisp), sawfish (one of the GNOME window managers) that uses guile (a lisp-like language/implementation from GNU). Also, many Perl applications use simple Perl scripts to configure the same way you show in the article.

Trackback Pings

TrackBack URL for this entry:
http://www.dehora.net/mt/mt-tb.cgi/1425

Listed below are links to weblogs that reference Execute this: managing configuration in programming languages:

» Data is Code, Code is Data from Stefan Tilkov's Random Stuff
Excellent stuff from Bill de hÓra: The point seem to be this: it is beneficial to lower the distinction between declarative data and code. Lisp hackers have known the value of blurring the distinction for decades; only now is it becoming an impera... [Read More]

Tracked on October 30, 2004 06:33 PM