Interview and JSON Schema Link
November 26th, 2008
Justin Meyer, author of the JavaScript MVC library (a great client-side framework for client-centric applications) recently interviewed me to talk about approaches to web development. I was very honored to see that he blogged about the interview.
Also, Ganesh Prasad recently talked about the importance of JSON Schema in the evolution of service oriented front-end architecture.
New JSONQuery Implementation
November 17th, 2008
Jason Smith recently created a standalone JavaScript implementation of JSONQuery, based on the version I created for Dojo.
Imperative, Functional, and Declarative Programming
November 8th, 2008
Much of the efforts in modern programming language evolution are focused on moving beyond the low level programming paradigm of imperative programming and into the realm of functional and declarative programming. Imperative programming is simplest way to interact with hardware and generally forms the foundation of higher level constructs. However imperative programming is highly error-prone approach to programming and can obstruct optimizations and implementation opportunities that better abstractions provide.
Functional programming focuses on computations and aims to minimize mutating states. Functional programming avoids side-effects and changing data as the basis for operations. Many computations that might rely on changing variables and state information in imperative programming, can be described in terms of mathematical computations in functional programming. Functional programming may rely on imperative steps in the implementations, but these imperative actions are ideally abstracted. For example, lets take a simple loop that finds all the objects in an array with a price property under 10. In imperative programming, this would be:
function bestPrices(inputArray){
var outputArray = [];
for(var i = 0; i < inputArray.length; i++){
if(inputArray[i].price<10){
outputArray.push(inputArray[i]);
}
}
return outputArray;
}
Can you spot the state mutations that we had to induce in this imperative approach? For each loop we had to modify i (increment it) and for each match we had to modify outputArray (push appends a value to it).
Now if we use a more functional approach:
function bestPrices(inputArray){
return Array.filter(inputArray, function(value){
return value.price < 10;
}
}
This code is completely free of side-effects. We simply described the operation in the form of expressions. The underlying implementation hides all the imperative actions necessary to make this work.
Declarative programming is defined as programming in terms of "what" instead of "how". Functional programming can be categorized as a form of declarative programming since we describe "what" computation should take place with expressions, instead of describing how the computation should be performed in a series of steps as in imperative programming. However, the declarative programming concept goes beyond just functional programming.
One of the central aspects of most applications is persisting data. A core service that most applications provide to users is to be able to store information relating to the use of the application. A social networking application is useless if it can’t actually remember anything about you and your friends. The functional paradigm is limited here, it’s methodology stands in complete opposition to the central goal of the application. Quite simply, applications must deal with mutating states and data. Here we can still apply declarative programming concepts, describing what the data is, instead of how it was created or how we modify it. Perhaps the most critical and invaluable benefit of declarative programming is that the representation of "what" the object implicitly dictates"how" the object is modified . With a declarative approach there is no need for describing how we interact with and modify data, because the structure of the data reveals the how without any further instruction.
JSON provides a great example of declarative programming. JavaScript supports numerous imperative techniques, but JSON is a declarative subset, which precisely defines what an object’s state should be without directions on how to get it there. For example, we could use imperative techniques:
var movie = new Object();
movie.title="Transsiberan";
movie["rat" + "ing"] = 1+2;
movie.setHowLong = function(len){
this.length = len.trim();
}
movie.setHowLong("2 hours ");
This representation describes how to build the state of the object, and can be of unbounded complexity, but it is not actually a representation of the final state. Alternately with JSON:
{"title":Transsineran",
"rating":3,
"length:"2 hours"}
The application of the concept of representation implicitly defining the method of modification can be seen here in the simple JavaScript object. The object’s state is observable as a set of properties and we can immediately infer from the presence of these properties how we modify the objects. We can simply set one of the existing properties to modify the state, and the effect of setting a property is obvious. Conversely, when an imperative approach where opaque object methods are used to modify an object’s state, the effects are not inferrable, one has to refer to out-of-band documentation to understand the interaction necessary to cause a state change.
The other central concept of a declarative approach to data is reversibility . If we modify the state of this movie object, there is a clear unambiguous easily computable representation for the new state of the object with a declarative definition. However, this is not true with the imperative definition. With the unbounded complexity possibilities of the imperative representation, it is impossible to always know exactly when step in the directions needs to modified to correspond the state change.
Another example of declarative programming is HTML. HTML represents the state of the layout of the page. The steps for how to get into a particular layout are not described, the layout is a state that is represented by the HTML. HTML provides clear reversibility as well. Layout changes can be clearly and directly mapped to changes in the HTML representation.
Applications themselves are a form of state as well, both at the low level (code is occupies memory in the form of binary data) and at the high level in languages that reify code. JavaScript is an example of an language where code is data. Here as well, we can benefit from code being organized in declarative approach rather than an imperative approach. An application runtime state that is the result of confusing imperative steps is much more difficult to debug than application that has a clear declarative organization.
Furthermore, declarative programming can often allow programmers to work within a "live" interactive environment, where code can be changed on the fly without requiring a restart. Imperative programming often means that the only way to predictably see the effect of a change in imperative code is to restart. We certainly want to be able to move towards faster development techniques that aren’t stuck in windows-style "restart" cycles.
Once again, declarative programming can be built on imperative programming. If strict discipline of rules is applied to imperative steps, the consistency can yield an declarative form in the context of rules. For example, if we said that all class declarations must take the form assigning a constructor function to a variable and then assigning an JSON object to the constructor’s prototype, then within the context of these rules, we can have a reversible representation that still be used even if we change the state of the class (changing method implementations for example).
It is important that these principles be used to direct our continuing evolution of JavaScript. Techniques like pseudo-classes based on the side-effects within constructor function execution are a regression in the evolution away from imperative to declarative. Prototype-based inheritance does a great job of maintaining declarative programming, as the application itself can be continually updated in interactive code. Debugging can be "live", classes can be evolved without requiring environmental restarts.
JSON vs Flash AMF
November 5th, 2008
Jared Jurkiewicz posted an excellent and thorough article debunking the myth that Flash’s AMF is signficantly faster than JSON. JSON is shown to be efficient and performant, and as Jared pointed out, it is not tied to any specific type system. AMF is also a binary format, whereas JSON is a highly open and readable format.
New JSON-RPC Library for PHP
October 27th, 2008
Matthew Morley has posted his PHP library for JSON-RPC 2.0 .
Dojo 1.2 Released
October 27th, 2008
Dojo 1.2 was released a few weeks ago, and I am really excited about this release. Take a look at the release notes to see all the new features added. This release includes a comprehensive set of new JSON features including JSONQuery , JSON Referencing , JSON Schema , and a RESTful JSON client . I am think it is great to see the expanding JSON toolset available in JavaScript libraries.
Persevere is now a Dojo Foundation Project
October 27th, 2008
JavaScript Expressions - Beyond JSON
September 22nd, 2008
JSON a powerful simple expressive format for data structures with a high level of interoperability; implementations exist in virtually every popular language. However, there are certainly situations where developers often want additional constructs for effectively representing data that are not natively supported in JSON. Perhaps the most common usage of JSON is for the consumption of data in the browser. Most JavaScript libraries, parse JSON by using eval, and consequently are actually capable of full JavaScript expression evaluation, of which JSON is a subset. JavaScript expressions support a much wider range of constructs than pure JSON. Usually a simple JSON/JavaScript expression parser looks like:
function parseJson(jsonText){
return eval('(' + jsonText + ')');
}
One of the most oft-desired data type that JSON doesn’t provide is a date type. Numerous creative, bizarre, weird, and silly techniques have been proposed for expressing dates in JavaScript. These methods often require extra parsing or walking strategies. Douglas Crockford’s reference library for JavaScript JSON serialization, serializes dates to strings by ISO format. I have written about deserializing these ISO dates. But, on deserialization it is not possible to determine if a value is actually a string or is really intended to be an actual date object. However, if the recipient of JSON is known to support full JavaScript evaluation (like the browser with a library using an eval), the solution for delivering date type value is simple, we can just use the normal JavaScript constructor:
{"mydate":new Date(1222057313264)}
There are also several numeric entities that JavaScript provides that are not available, including Infinite, -Infinite, and NaN. I am not sure why you would need it, but undefined can also be transferred with JavaScript. Functions can be included as well:
{
"reallyBig": Infinite,
"parsedString": NaN,
"whatValue?": undefined,
"doSomething":function(arg){return doSomethingElse{arg};}
}
The data representations thus demonstrated are not JSON, they are JavaScript using the same object/array literal that JSON is based on. However, certainly one of the biggest benefits of JSON is it’s interoperability. If your data is going to be consumed by more than just JavaScript-parsing JavaScript libraries, you must make your data available in pure JSON format as well. This is well-handled through content negotiation. If you are using JavaScript expressions to transfer data, you should make sure your requests from the browser actually are specifying they can handle JavaScript:
Accept: text/javascript
Your server should be prepared to handle requests from clients that indicate that they only understand pure JSON:
Accept: application/json
Persevere, the JavaScript/JSON application and storage server, also provides support for parsing and storing extra constructs including non-finite numbers (NaN, Infinite), functions. Persevere can output the data as JSON or JavaScript (expression).
JSON is certainly powerful, expressive data format. This post is by no means an attempt to expand or lobby for the modification JSON. However, when it is known that consumers are actually JavaScript capable clients, it can often be advantageous to use the full power of JavaScript to represent data, while still providing JSON as representation for non-JavaScript capable clients.
New JSON-RPC Python Library
September 2nd, 2008
Roland Koebler has just released a new JSON-RPC module for Python . jsonrpc.py implements both JSON-RPC 1.0 and JSON-RPC 2.0 .
Dojo 1.2 Beta Available
September 2nd, 2008
Next Page »