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 ranging from Perls' strict mode, to the Java sandbox, to web browsers running code securely, even agent programming arcana such as Telescript, to appreciate the issues. And 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 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. Although 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 heavily 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....
Previous Topic
