What I call information diffusion is barely a tree which nodes are web pages/articles and let u, v be two nodes of the tree, if v is a child of u, then the information posted on v was first read on u. The root being the original source of information (or at least the first observable occurrence).

The difficult part is to try and build such a tree. There are several papers on the subject, but most of them reconstruct the tree, using semantic wizardry : take a blog network, identify subjects (whatever it may mean) and using statistics and temporal information, try to guess the path the rumor/buzz/information took. While this method is OK and gives result, I'm not convinced this is the best way of doing things. I strongly believe that whatever are the results one wants to see, there is a way to reconstruct the diffusion to fit those specific results, and this might influence the measurement.

Then I thought that on blogs we had this wonderful concept called trackback. A couple of weeks ago I firmly believed that you could actually track the diffusion of an information just by looking at the trackbacks. The idea was pretty simple : I made the assumption that if blogger B reads something on blogger B's website, he'll create a trackback.

So I wrote a few lines of python and using the Technorati API I built a few trees. In each of those, the nodes are the articles, and there is an (directed) edge between two nodes if the target has made a trackback to the source.

Here is an example : I looked at how the announcement of YouTube's acquisition by Google spread from two different sources. The obvious thing is that the tree is really large and not deep at all. And this is not an artifact, I have quite a lot of data on other information trackbacks and they all follow the same pattern : almost everybody makes a trackback to the source, and there are extremely rare occurrences of trackbacks to another article.

I started wondering where I made a mistake, and after some reflexion I came to the conclusion that there is a very simple yet enlightening explanation : things do not work that way at all, trackbacks do not capture information diffusion.

I'll give you a real life illustration : let's say you have a friend and that this guy tells you something like "Hey, I saw an awesome video on YouTube yesterday, blablabla". Let's assume that you're interested, you'll go and watch the video and when you'll talk about it, you'll never say : "One of my pals told me he saw this video on YouTube, check it out" ; you'll directly cite the original source. This is exactly what happens on the internet.

Moreover, there is another important thing to consider : when blog A tracks back to blog B, there usually a link on blog B to blog A. And if blog B is TechCrunch (or any other huge blog), it's fair to assume that a little traffic will leak to blog A. This is an incentive to track back to highly visited blogs (which happen to be, in most cases, the source of the information).

You might wonder what I'll be doing now that I realized that the whole trackback stuff doesn't work out so well… I'm planning on launching something quite interesting in the following weeks, which might help understanding how information flows from blog to blog, so stay tuned

A robot is located at the top-left corner of a 53 x 32 grid. The robot can only move either down or right at any point in time. The robot is trying to reach the bottom-right corner of the grid. How many possible unique paths are there?

The first thing I thought about was calculating all the paths using dynamic programming and memoization:

Let P(w,h) be the number of paths the robot can take to go from to top left corner of an w x h grid to its bottom left corner. If the robot goes left, it has P(w-1, h) possible paths left, and if it goes down, it has P(w, h-1). Of course, P(w, 1) = P(1, h) = 1.

The second approach gives the same results, but is obtained in a completely different manner. In the first case, it's mainly algorithmic, whereas the second case is purely combinatorics and — I think — far more elegant.

In order for the robot to go from the top left corner of an w x h grid to its bottom left corner, it must go (w-1) times left, and (h-1) times down, which is a total of w+h-2 movements. The number of paths is then the number of way of choosing which of those movements are (for example) going left. That is, choosing w-1 elements out of a set of w+h-2, best known as the binomial coefficient C(w+h-2, w-1). Of course, to compute it, one would use the recurrence used in Pascal's triangle : C(n, k) = C(n-1, k) + C(n-1, k-1), with C(n,0) = 1 and C(0,k) = 0.

The really nice thing about this is that two different ideas lead to one same result (it's just a question of rewriting the recurrence). This is creativity

Just to give you an idea of the numbers involved here : on a 67×51 grid, there are 2049503709637561751443717895527866 paths. Believe me: it's huge !

bundle is used to create a new namespace, given as a string. If a function is passed as a second argument, then it is called, bounded to the namespace. For example, one could use the following :

You might think (and you'd be right) that having long names can be a pain (I would never use something like net.friggeri.quux.a). However, using the fetch function, you can populate an object with whatever slots in a given namespace. Then, using with, you can emulate some kind of pythonish import statement. An example might be useful at this point:

The code is pretty ugly: I have to use eval at some point to make sure it still works if called in a nested function and I didn't find a way to avoid using with in the function passed to fetch. Of course it's possible to use a this.bar.bleh syntax, but the whole point of fetching the contents of the bundle is to avoid using such long variable names.

If you wish to expand this, or have any suggestions, you're welcome to comment.

Update : I just realized that it could be simplified a lot with having fetch returning directly the object, allowing something like :

This is a very good example where having an all functional approach might not be the path to follow.

Peter has added a File module which wraps Java file operations, and I see this as the first step towards taking JS out of web development. Let's face it, JS is really present in browsers, SSJS is taking off very slowly and even though a few apps use JS for scripting, it's still not mainstream.

The way I dream of JavaScript's future ? As a general purpose scripting language. This means that several things have to be done. First, an easy way of binding whatever library to JS. Second, a CPAN like repository dedicated to JS. There is absolutely no control on how would evolve the latter. The former, however, can be conceived right now.

I'm not really sure if I agree with Peter's choice of Rhino instead of SpiderMonkey, but I guess he has more experience with Java than with C — which is quite the opposite of my own misconceptions. I guess there are pros and cons for each of the choices, but I wonder if it'll be easy to port generic C libraries to JS using Rhino. I must clarify something at this point : I have a deep hatred of Java — it's a kind of zealous religion — and everything that comes near it appears like obscure magic to me.

Nevertheless, I really wish a lot of good things to xjs, and I hope that Peter will take into account the fact that an easy mechanism for porting library is a must-have.

One huge drawback : the :emacs command, why is this even implemented ?

A cool addition would be an implementation of auto completion, like the one I developed in Jim.

First of all, I think the main drawback is inertia. PHP is currently the way to go in web development (even though a few still use ASP, CGI, etc.). In order to counter the inertia, any new server side language has to be as good as PHP (not so difficult to do), as easy to learn and have exciting new features.

Python and Perl have been around for quite some time, without becoming dominant, so I guess that they won't in the future.

Some said that RoR was that alternative, and let's face it : it's trendy among Mac geeks using textmate… Not that I have anything against this, but those developers live in another world: RoR has basically several flaws which can't be overcome. First, it doesn't scale. Second, it doesn't have a C-like syntax, and this has a psychological impact on devs coming from the PHP world. Third, it's yet another language to learn. Fourth, it didn't play well under Apache until recently. The reason why some guys switched to RoR could be summed up to three points: the MVC model, the Active Record pattern and scaffolding.

All those ideas are nice, but it's not enough for RoR to be the Next Big Language. SSJS is exploding right now, with quite a number of solutions being developed. However, most of those are bloated and are either ports of PHP or RoR to JS. The only one which takes it to another level is Jaxer, which is a nice concept, but is intrinsically unscalable: how can one imagine having hundred thousands instances of DOM trees being manipulated at the same time on the server and being delivered quickly ?

I believe that the JS strength resides not only in the fact that it's usable on the client, but also because it's prototype based. For example, Active Record is something nice for class based object orientation, but I believe that there are much simpler approaches using prototypes.

Nevertheless, unless someone comes up with some revolutionnary features for SSJS, I'm afraid that it'll stay a niche language (on the server).

I won't detail more than that, as the article and its comments give a lot more information that I'd be able to. From times to times, I read something and I just think we're living in the future, this will be everywhere, eventually.

There are quite a few other languages for which a JS interpreter is available: Basic, Scheme, Lisp, Prolog. Even Javascript can be interpreted in JS using Narcissus. If this is not enough for you, I can add Brainfuck or even other esoteric languages.

I guess you'll say that all of those bring nothing interesting to the browser and that using compiled bytecode instead of parsing/interpreting source code is much faster. The latter can be easily forgotten, what about an x86 interpreter ?

Nevertheless, what is the easiest thing to write ?

• plain JavaScript, with a powerful library such as JQuery
• some bloated Java using cluttered GUI tools which were not built to output web components

A few years ago, writing some JavaScript meant dealing with cross browser issues. Today, JS is much more friendly, thanks to a lot of libraries. Moreover, I'm pretty sure the next move will be SSJS, is there a reason (other than because I can) for porting Java/Ruby to JS ?

A year later, in 1993, my mum brought back a Compaq running Windows 3.11 with a CD-ROM drive. I never used that machine, because at that time I spent my time on a little game on my dad's computer. That same year, my dad came back from the US with a brand new game: Doom. The day I tried it, I had a revelation: I could not stand FPS.

In 1996, my parents bought a new computer, a Pentium Pro 200 Gateway, with a 17" monitor and Windows 95. Six months later we had an Internet access. I remember that the first thing I searched using AltaVista was Lego, followed by Star Wars… Some of my parent's friends told us about a software called ICQ, and that was the beginning of a long story. When I was not chatting, I used to play to Civilization II, Myst and Warcraft.

In 1997, I remember playing a demo of a gore game which I fell in love with: GTA. I acquired the game and spent long hours tweaking it, which was real fun. I also spent numerous hours on Age of Empires, but I was too lazy to not use cheat codes. This was my last RTS experience.

A few years later, around 1999, we got a cable connection. Internet became something different: this permanent extension of existence. Terrifying. In April I downloaded my first mp3 from a chinese web page hosted on Geocities and discovered Napster a few months later. Google arrived in my life and I never used another search engine since. In the mean time, I started having some fun with ASP and VBScript, and this was my first programming experience.

By the end of 2000, I spent my time playing GTA II. I got a free domain name on NameZero and created Copkilla.net and hosted something which was meant to be a fansite. And I was still using the Gateway…

The next year, I bought my very own computer and I discovered T4C, my first MMORPG experience, and became an addict. I spent my life online: when I was not playing, I was on some T4C forum. I spent almost 4 years on that game, and in 2003 became Game Master and eventually Admin of a french official server. No need to say that my whole life turned around that game.

In 2003, a friend sold me a motherboard with a PIV and a GeForce V for ~20€, which was a really cheap upgrade. I got my baccalauréat and went to classe préparatoire and I had to choose between computer sciences and engineering as an option. I obviously took computer science, and this is how I met Caml and functional programming.

During the summer of 2004 and 2005 I worked at MonsieurPrix.com/Kelkoo.com. The first time I wrote a robot to scrape Amazon's catalog and insert it in the products database, the second time a robot to submit loads of keywords into Google Adwords, both projects were written using ASP.

By the end of 2005 I launched my personal blog, which was a mere conglomerate of thoughts, poems and such. I started tweaking my WordPress install and got familiar with xhtml and CSS.

In 2006, I entered the Ecole Normale Supérieure de Lyon and discovered a whole new world: Linux. In september I bought the HP laptop I am currently using and installed an Ubuntu on it. I then learned a few new languages: OCaml, C, C++, a little bit of Python, PHP. I started using vim as my text editor, ion3 as my window manager and became a CLI fanatic. I got contaminated by the dual screen sickness.

In June 2007 I abandoned my personal blog and decided to have a more technical one, this was the birth of Syntactic Sugar. I discovered Duels and launched what would be its unique fansite for 6 months. In October I finally switched to Debian and installed a server in my studio, in order to have all my web development, a few screens, etc. permanently available. In December I fell in love with JavaScript and prototype based programming. More recently, I translated this whole blog in English, and here we are.

That's all for now. I can't really guarantee that the timeline is exact, but it seems that the dates are correct. I'll try to post a follow up in 10 years