Showing posts with label node. Show all posts
Showing posts with label node. Show all posts

Thursday, March 22, 2012

Bring the data to the code, or the code to the data?

Object-oriented code was conceived as message-passing between objects. Service-oriented architecture emphasizes delegation to another system. The entire web is a whole bunch of requests flying around. There is one clear way to be efficient about this: stop waiting for results.

When we're writing imperative code, we want to write the operations in the order they should happen. This is straightforward and makes sense to our brains. Pseudocode:
let filename = // calculate filename
let data = new File(file).readAllLines();
// filter the data
// summarize the data
// reformat the output
let status = new File("output").writeAllLines(newData);
println("done!");
sendEmail("done! status = " + status);
println("email sent");
This describes the order in which operations need to happen. The problem is, it is not efficient. We're holding up a thread waiting for I/O. Take the part where we read lines from the file, for instance -- we can't proceed until we get that result back, right? the rest of our code needs that data.

There is an alternative.

Instead of bringing the data to our code, we can ship our code to the data.
With functions-as-values, we can send our code along with the request for the data. This frees up our thread to continue processing, and then our code can execute when the data is ready. When passed as a parameter, the code to execute after completion is known as a callback or a continuation.

Instead of waiting for the data to come back from the file read, we can pass the code that needs to operate on the data. That way whatever thread winds up with the data can execute the code: code and data are brought together.

The pseudocode example has three asynchronous operations. In each case we can change the rest of the code in the block into a callback.
let filename = // calculate filename
new File(file).readAllLines().andThen( { data -> 
   // filter the data
   // summarize the data
   // reformat the data
   new File("output").writeAllLines(newData).andThen( { status ->
       println("done!")
       sendEmail("done! status = " + status).andThen( {
          println("email sent")
       })
   })
})
When this executes, the filename is calculated, the read is triggered and then our program goes about its business doing whatever's next. Everything needed to process the data is bottled up in that function we passed, that continuation. We're passing the code to where the data is, instead of freezing the code in place until the data is available.

The idea of putting functions into values and passing them to the data, instead of bringing data back to the code, facilitates the message-passing that OO was based on. It facilitates a faster service-oriented architecture. It can make a faster web. JavaScript is all over this technique; AJAX and Node.js use this principle.

Continuation style is a lovely combination of imperative style -- everything happens in the order specified -- with the functional concept of code-as-data. It frees the browser or the runtime to optimize and keep open threads busy.

If your reaction is, "yeah, but it's fugly!" then look for my next post.

Monday, January 30, 2012

starting to maybe get the point of node.js

Listening to Glenn Block talk about node.js at Technology and Friends, there's something interesting about the philosophy behind node.js.

Threads are hard. Threads include overhead, but more significantly, using them requires the developer to hold more stuff in his head. Node.js has a philosophy that leads to asynchronous processing without multiple threads.

Glenn explains how the node.js server is single-threaded, but all the APIs are asynchronous, using callbacks. All the incoming requests go onto one queue, and then whenever processing a request requires calling a service or doing I/O or anything that may take some time, that call is executed asynchronously and the callback goes onto the queue. Because there's only one thread, developers don't have to think about multithreading. Because of the asynchronous APIs with callbacks, the single thread doesn't block waiting for anything. Concurrent performance without threading.

Here's a speculation. This idea is implemented in JavaScript because the restrictions of the browser and the mechanics of JavaScript have driven us toward this event-driven, callback model in that language. It is natural, then, to take this idea to the server in the same language. Is this model, with a single thread and a queue of incoming requests and callbacks to process, implemented in any other languages in different frameworks?