Must be blogged: The collaborative Zoomquilt 2.
Really worth seeing. Much longer, much better, now as a screensaver too.
Take the trip.
Zoomquilt 2
Continuations are the new threads
I’ve always thought that continuations are the right answer to many if no all the network-programming problems.
What are continuations?
A continuation represent the state of execution of a function: all the local variables and the instruction pointer (the last line executed).
(Update: At least: there can be many kind of continuations. Other than the local variables, it’s possible to store the state of the entire thread/process/stack)
What are them used for?
You can interrupt the execution of a function and resume it later.
This can be useful to create “generators“: iterators made simple.
A generator looks like this:
[js]
function next() {
for(x=0; x < arr.lenght; x++) {
yield arr[x];
}
}
[/js]
The function next return the next element in the arr array every time is called.
When you call the function you resume the continuation, so the execution will resume from the yield.
If you want to implement an iterator like that without generators you'll have to explicitly unroll the for loop.
The resulting code will be surely less readabe.
Like:
[js]
function next() {
if(this.current == null) this.current = 0;
this.current++;
if(this.current > arr.lenght) {
this.current = 0;
return null;
}
retrun arr[x];
[/js]
This can get really worse for every non-trivial iterator (eg: tree traversal).
Another nice use of continuations is to generate cooperative threads.
They are different from standard threads because they can't be stopped, they should cooperatively stop.
For example you can do:
[code]
function process() {
sendConnectRequest();
yield;
if(!this.connected) return false;
sendLoginRequest();
yield;
sendMessage();
yield;
trace("msg received: " + this.response);
}
[/code]
The process function return the control to the calling function every time it has to do an asynchronous operation.
Without continuations you'll have to do:
[code]
function process(onComplete) {
connect(function (connected) {
sendLoginRequest( function(logged) {
sendMessage( function (response) {
trace("msg received: " + response);
onComplete();
}
}
}
}
[/code]
As you can see we have used closures in a Continuation Passing Style:
Every time you have to do an asynchronous operation, you'll have to pass a function (a callback) that will be called when the operation is done.
Without closures the code will look even worst, this is why recently there is a great buzz about closures in the java world.
But, what have in common continuations and threads?
A continuations-like style of programming (but without continuations) is possible only using threads.
However, threads are the heavier and most problematic way to handle the I/O waitings. (see: 10Kproblem)
You have not only to deal with concurrency problems with read/write variables, but you have to block an entire thread for every I/O operation.
A better way is to use asynchronous events, like in the last two example. But of the two, which one do you prefer?
If your answer is like mine, take a look to:
- Jetty servlet engine, it support a limited form of one shot continuations: the function is re-executed from the beginning, what is restored is only the HTTP connection state.
- RIFE continuations, it's a bytecode-level implementation in Java, these are real continuations
- NarrativeJS, a precompiler that create a simple form of continuations in Javascript: using the
->operator the execution can be resumed from that point. - Update: Torsten Curdt suggest Javaflow, a continuation implementation that seems really interesting, he offers some tutorials on his blog too
Jetty scratched only the surface of what is possible with continuations, while with RIFE it's possible to develop highly concurrent servers using cooperative sessions instead of threads (some >10000 connections instead of 1000). See: Mina Java-NIO library, Perl POE, Mina-Mule.
A server that uses continuations, will allow the simple and linear programming style of blocking-synchronous operations while using non-blocking ones. With a huge increment in performance.
In the client side, the most interesting is NarrativeJs, that use an approach that can be adapted to every language:
it unroll loops and transform all local variables in object variables to generate his quasi-continuations.
[js]
function boo(){
alert("start");
sleep->(30);
alert("end");
}
[/js]
became:
[js]
function boo(){var njf1=njen(this,arguments);nj:while(1){switch(njf1.cp){case 0:
alert("start");njf1.pc(1,null,
sleep,[30]);case 1:with(njf1)if((rv1=f.apply(c,a))==NJSUS){return fh;}
alert("end");break nj;}}}
[/js]
The code looks ugly but it is so to preserve line numbers.
With narrativeJs you can do complex animations in a simple, linear way:
[js]
waitForClick->(theButton);
animate->(theButton, "left", 200, 1000, 20);
theButton.innerHTML = "go left";
// move the button to the left (again note the blocking operations)
waitForClick->(theButton);
animate->(theButton, "left", 0, 1000, 20);
[/js]
or:
[js]
document.getElementById("myElem").innerHTML = fetch->("http://www.url.com/");
[/js]
Really interesting now that Flash and Ajax are pushing asynchronous operations to the masses.
Will we say goodbye to events, and maybe to threads as we know now?
My two cents on Static Typing
While I was wondering if using haXe or Java with my server, I’ve stumbled upon some discussion on Static Typing (Java) vs. Dynamic Typing (Ruby, Php).
In a really interesting blog post (read the comments too) I found this touching phrase:
“Static typing is Communist Bureaucracy”.
In short: since we (should) have pervasive testing, Static Typing is only more testing. However, a comment is enlighting:
I’m finding this logic hard to follow. Testing is good, coverage is good. Static typing is, among other things, a way to have the compiler test your code for type issues. Since we like testing, this makes static typing good, right?
But Static Typing not only prevent you to do mistakes, like typos, it allows your IDE to know what you are doing:
DynamicStatic Typing speeds up development because there is physically less to type since ctrl+space and ctrl+2 write the declarations for you.
Its seems obvious to me that Dynamic Typing is worth the catch only for a quick start or for learning.
Since almost all of the dynamically typed languages (like Actionscript, Perl, Php) have migrated to some kind of Static Typing (eg: Type Inference), there should be a reason.
Periodically, a new Dynamically Typed language spawn, attracting junior/tired programmers with the mirage of the simplicity and the less-to-type-ing, riding the hype until his young audience grows and start doing large projects hoping not to call a function with the wrong arguments.
Only then they realize the big truth: Static Typing is just more informations in the source code.
And more information means less wondering-what-object-was or what-was-the-method-name-and-parameters or who-instantiate-this-object, not to mention static analysis.
And hey, they have invented Javadoc-like documentation and Annotations just to add some more information, why remove one of the most important?
10 Great Muppet Moments in Muppet History
Just like the title, incredibly fun.
Markdown in Javascript
Someone ported Markdown formatting to Javascript.
In the page linked, the text is formatted as you type. I wonder if there is a WordPress plugin that do something like that.
Ban Time Travel Now!
I’ve adhered to the campaign: “Ban Time Travel Now!”


Our mission:
To preserve the integrity of the spacetime continuum, I hereby petition the governments of the world to immediately enact laws banning the research and practice of time travel.
Gearge Lucas in love
Ok, this isn’t a tech thing like the ones I usually wrote (but it is geeky):
a Star Wars remake like Shakespeare in Love, really funny!
Bruce Eckel on Flash
Here a great post of Bruce Eckel (author of “Thinking in…” books) on Java, Ajax and surprisingly: Flash.
So here’s my question. Allow for a moment the possibility that, after 10 years, Java is not going to take over the world of RIAs. Further allow that Ajax is just “how JavaScript was supposed to work in the first place,” but that the limitations imposed by browsers, HTML and CSS committees seem unlikely to let it expand beyond its current bounds. What are we going to use to build RIAs? [...] The only obvious solution is Flash.
Simon Brocklehurst pointed out that there are more ugly Flash interfaces than good ones, although I think he is talking about the old do-all-by-yourself hackery of Flash 7-8 since there isn’t many Flex 2 web apps out there yet. I wonder if he saw Picnik.
Eckel highlight a really interesting point: to use Flash as a domain specific language. Do in Flash the interface for your Java/Python/C application. We are waiting for you, Apollo.
Map of Web 2.0 startups in the world

(from readwriteweb)
I’ve found really interesting this map of Web2.0 startups in the world:
Europe and World
Sadly nothing in Italy…
CoComment
CoComment is a new tool that manage all your online conversations: install the firefox plugin and it will recognize every blog/forum you visit and track the comment you post.
It will also attach a toolbar to every comments textbox:
Worth a try