[wwwhizz]

I'm probably biased by writing a lot of algorithms in the classical way, but I find your way a lot less readable and very unintuitive. Pseudocode is easy to transform to code; your notation, not so much.

I do applaud your determination of not liking the classical notation and coming up with something different. Maybe it's just that I don't like the syntax of math either (if math would be an API, it would be considered poorly designed, poorly documented and incomplete and inconsistent).

[kragen]

Yes, as I say on the page, I find it less readable, too. But it's much easier to write. And it isn't that hard to transform to code.

[continuational]

I must say i find it more readable than pseudo code; the reason being that all the keywords have been replaced with graphical elements and layout. This means that all the text is essential to the algorithm, which makes it much easier to read for me.

[kragen]

I'm glad you like it! Maybe I'll get used to it in time myself.

I do still use things like "argmin", which you could argue is a "keyword"; by argmin_{x ∈ S} f(x), I mean what you would express in Python as min(S, key=f), which ends up translating to something like this in C:

    int min_found = 0;
    T min;
    U min_item;
    for (iter it = first(S); hasNext(it); it = advanced(it)) {
       U item = itemAt(it);
       T val = f(item);

       if (!min_found || val < min) {
          min_found = 1;
          min = val;
          min_item = item;
       }
    }

    do_whatever_with(min_item);

Maybe this is what someone earlier meant when they said this paper algorithm notation was still too hard to translate into code, but I feel like argmin (over a finite set) is a sufficiently familiar concept that there's no need to spell it out in more detail, and indeed it's a standard library function in Python.