Henceforth, on all applications I create of my own volition, I will indicate which things were an inspiration to me regarding the design of that application. It could be (and is) anything. It could be a particular set of music albums—perhaps the ones I played a lot during the planning or executing of that application—or a particular weblog I was reading a lot at the time. Or a novel I was reading. Or a particular gun whose design I may have studied in that time. Or a scientific publication I read. Or a person whose work was inspiring in that time. Anything.

For the spammers of old, the cue that a page had an e-mail address on it was the “@” sign. Twitter made that strategy too costly, since now very few of the things that have “@” in them are addresses. There are now other ways to get addresses, but the easiest of them is useless, given Twitter.

I have in the recent days taken to learning the Go programming language.
I expect to use it on Google App Engine, at least in the learning of it. The project thereof: rewriting this blog in Go. In Python, it took me under a full day to implement it. Plus bug fixes and the move from Python 2.5 with Django templates to Python 2.7 with Jinja templates, and we could say two days.
The Go version may take me longer, since I am not as good at Go as I was (and am) at Python. But it should also not take unduly long. The key, at any rate, is to start off by biting small amounts. For example, to start off with an attempt to implement merely a subset of this already-very-simple blog.
Onwards, then.

From their tour page, I think the people behind Opa have done some very, very excellent work. Next time I am itching to learn a language, perhaps Opa will be lined up. As things go, I think their weakest point is having their own cloud thing, with DotCloud, and not something bigger like GAE; but that may have been inevitable, in order to make Opa pay for itself. (I am sure that, with such tech and managerial skills, they could have bent their system to fit any cloud-hosting system.)

The word “post” previously meant “letter”. As in “post office”.
However, now I—and many others—use it for entries in a blog.

All well and good, until I go and start blogging by e-mail—as I am doing now.
What to say? “Post by post”?

The subject is what becomes the title of the blog post. The text is the body.

Having done the small caching library for Google App Engine, I have remembered that this might in fact be illegal. The terms and conditions of Google App Engine state that:

4.3 Restrictions. Customer will not … (e) create multiple Applications to simulate or act as a single Application or otherwise access the Service in a manner intended to avoid incurring fees; …

Emphasis mine. Right. But the express reason I am doing this caching thing is to avoid spending a lot of money paying for a lot of outbound traffic (having had to turn on billing after a recent spike). In fact, Google App Engine’s webapp2 framework not only does not help with caching outbound traffic, but also includes a header, by default ensures that even blobs that are sent down via the standard BlobstoreDownloadHandler are never cached.
I would assume it is something between bug and infelicity. But then there is section 4.3(e), which could be taken to imply that Google wants things this way, in order to make money.

So, the question: is caching in this manner illegal on Google App Engine?

This is the README.mkdn of the Cache-Toi project I put on GitHub.

Cache-toi !

Nomenclature:

French for “Hide!”

Requirements:

• The webapp framework (even webapp2), as found in Google App Engine.

Introduction:

Basically, it enables your Google App Engine apps to exploit client-side caching without much effort on your part.
By default, no such caching support is provided by the webapp framework. Indeed, it even goes out of its way to ensure that client-side caching is turned off, by sending a Cache-Control: no-cache header. (This makes sense, if you sell bandwidth, and you have a lot of it.)

However, if you are paying for out-going bandwidth—as you are, if you use GAE—it is the little things that matter. Like being able to easily tell feed aggregators to use a cached copy. These are the issues that Cache-Toi resolves.

With this module imported, you have a class, CacheToi, which can be inherited by any odd RequestHandler and used as explained below.

It requires that every class (usually a RequestHandler child) that implements it also provide a method called latest, which takes the same arguments as get would. This method returns the time of the last modification, as a datetime.datetime. If this indicates that the client has a stale version, we replace it by calling another method it implements, called cached_get. This method, cached_get, replaces get, and is otherwise similar in everything but a name.

Examples:

This is a standard blog’s code, for the front page:

class FrontPage(webapp2.RequestHandler):
  def get(self):
  entries = Entry.all().order('-created')
  ...

The problem is that, even after I have just ordered for that page, I will have it all sent over again if I so much as reload the page before anything has changed.

This is a standard blog’s code, for the front page, with Cache-Toi:

from cachetoi import cachetoi

class FrontPage(webapp2.RequestHandler, cachetoi.CacheToi):
  def latest(self):
    return Entry.all().order('-created')[0].created

  def cached_get(self):
    entries = Entry.all().order('-created')
    ...

First line: you have to import cachetoi.

First method: latest returns the time the latest change was made.
Your code will likely use something like .modified and handle the case where there are no entries.

Second method: cached_get is similar in all things to the earlier get, except for the name.

Instead of cached_get you could use get_once and then that resource will be considered (by this caching layer) to never expire. This is fit for things like images. If it is a resource that is not going to be modified, this caching layer can deal with it simply if you use get_once.

Notes:

1. This thing is much fun when you use multiple inheritance. There is nothing wrong with multiple inheritance. “It is for freedom you have been set free,” as my favourite short bald-headed man once said.

2. Things like memcache prevent undue DB access. They are internal matters. Things like Cache-Toi prevent undue sending of data. They are external matters.

I have, for the first time, been slashdotted. And yet it has happened when I am running on Google App Engine. I guess I was too cheap to survive it; I have now given them the key to a whole $14 a week from my coffers, and now they let my blog run. Unto he that hath shall more be added, et cetera.

You would expect that Haskell, since it took the vow of purity, is excellent at functional programming, and correspondingly poor at imperative programming.

Until she, Haskell, comes back home and you say I know what you have been doing. She looks a bit panicky. The muted TV, the only light in the room, is making the sweat glimmer on your face. You have a glass of whisky in your hand. Too little left—you could hurl it at her. I know you have been living among them.
And you hurl it. You useless … She bolts off out of the house. Come back here!
What exactly went wrong?

Haskell did not respect the caste system, apparently. It was supposed to be a purely-functional programming language—and, in her defence, she is still pure as pure can get—but she learnt too well the language of the “lower” castes. She speaks it better than them. This is what you overheard, and you are over-reacting.

You see, Haskell is the best programming language for IO. IO is impure, but—wonder of wonders—the best language at it is a purely functional programming language. You prove me wrong: show me a language that treats IO actions as values, and I will recant. See this, which I do in GHCi:

let actions = [putStrLn x | x <- ["cat", "eat", "dog"]]
:t actions  -- Says it is a list of IO actions. A list of printings.
let snoitca = reverse actions
:t snoitca  -- Says it is a list of IO actions. A list of printings.
:m + Control.Monad
sequence_ actions -- prints: cat eat dog
sequence_ snoitca -- prints: dog eat cat

When next your programming language lets you line up IO actions and count them, reverse them—store them!—and then execute them when the fancy takes you, I will recant. Threads are hard? No, no: programming like it is 1986 is hard.

But how do you explain this to your child? That the best language for fondling IO is the language that is too pure to touch IO? Functional programming has known deeper embarrassments, but none quite this bad.

This picture is like finding out that the Pope is not a Roman Catholic.

What you see there—click it for a much larger version^[1]—is the result of a very innocent question from a Python programmer to me, after he found out that I am a Haskell programmer. I will give you the lesson that I gave, of monads in Python, using that whiteboard.

The Python programmer said he had downloaded Haskell, and was experimenting with it. “But what is this monads stuff?” Never. Never ever ask that. One negative effect of asking that question is the horror of finding out that you use monads more than Haskell programmers; but because they are everywhere in your life, you have developed a blind spot to them. (Hint: do you use nullable objects?) In fact, as I showed him, every single object in Python is an instance of [the Haskell type class] Monad. So, to prove this ridiculous statement, I told him (upper-right corner): “Monads are conditional function calls.” So, every time you see a function being called inside an if statement, you are looking down the howling void of a monad.
On the whiteboard, below that word “MONAD”, you can see the Python function, pymon, whose definition is:

def pymon(f, v = None):
  if v:
    return f(v)

And with that in hand, I proceeded to explain.

In Haskell, one example of a monad is the Maybe anythingElse type. It has two possible values: Nothing and Just anythingElse. In Python, every object is an example of a monad. It has two possible values: None and anything_else. In both these cases, anything_else can be any value. Right. So, every time you ever execute a function based on which of the two values is present, you have implemented the heart of Monad. So, what makes it cool in Haskell is that this removes about six hundred and forty nine thousand two hundred and eighty-eight if statements from your code. Much of your code is feebly re-implementing what pymon is doing up there. If you could shove pymon at every object, you would find that your code focuses on getting the job done, not baby-sitting if statements.

On the whiteboard, I proceeded to implement pymon in Haskell—as hamon—which became what you see here:

hamon f v = v >>= f

So, you see that what increased the cyclomatic complexity of pymon has been achieved in Haskell without any increase in cyclomatic complexity! That is a win, because if you can get away with conditional application of functions without littering your page with if, if, if, if, if, you can implement large logic without fear, and in a terser, more-compact, well-manicured way. The trick is that >>= is the heart of the Monad, and we already implemented it up there in Python (as I will show).

I proceeded to say (on the whiteboard) that “v >>= f” is this in a pseudo-code that looks like Python:

if v has something in it:
  return f applied to what is in v

Which, the perceptive reader will notice, is exactly what pymon says.

So I implemented hamon2, which specialises hamon to deal with one particular monad. (This is to basically show what >>= is doing.)

hamon2 f (Just x) = Just (f x)
hamon2 f Nothing  = Nothing

This obeys a rule about monads—followed in both Python and Haskell, whether we realise it or not (Python), and whether we like it or not (Haskell)—which is that a function that deals with a monad at all shall always return a monad. That is what is written to the middle-right of the whiteboard: “>>= only ever returns monads”. But the best thing here, of course, is that there is a simpler way, shown before, to implement hamon2. And you can even make it more-general than hamon2, such that it does not deal with just Maybe a, but with any Monad. In Python, this is indeed the case, because every object is a monad already!

hamon3 = (>>=)

In English, the above line says: hamon3 is the longer name of >>=.
But hamon3 is equivalent to hamon2.
And hamon2 is equivalent to hamon.
And hamon is equivalent to pymon.
And pymon is equivalent to >>=.
And >>= is the heart of the Monad.
And so … you have been using monads in Python, all along sneering at the “smug Haskell douchebags who brag about the size of their gonads or something”. You are one of them. As my favourite bald-headed short man once said, “You who judge, do you not do the same things?”

So, both Haskell and Python use monads extensively; and Python does it so much more than Haskell. What, then, shall we say?
What makes Haskell’s take better is that it is simply too reusable. Do you know how it feels to write a complete JSON parser without having a single if statement to handle failure (bad syntax), and yet handling failure anyway? I do. Have you ever checked a parser’s 200 lines of code and seen only three if statements whereas every single function in the code handles a case of failure? I have. This is nothing spectacular, until you have to live without it—without pattern matching and such great abstraction as is provided by things like the Monad. The trick of that JSON parser is that no function even deals with any particular Monad—it just deals with any monad: “anything of which we can say ‘if v has something in it, return f applied to what is in v’,” which happens to be nearly anything more-complex than the byte.

Lists? They are monads. File handles? Monads. Database query results? Timer countdowns? Fuel tank status? Monads. Even simple, direct, applicable understanding of monads is a Monad: if you grok, apply. And yes, even parser results are monads.
Because it is simple, you can live without it. But because it is simple, it shows up everywhere; so it is good to have a solid and ready toolkit to save you from a swarm of the case. Learn you a monad for great good. It is the little things, brother. Do not go at the monads so that you can learn some clever move; it is a simple, mundane thing that Java programmers implement every six lines they write. Just go at the monads to stop being that bored/boring. Deal with real complexity; not

if(x == null) return null;
//  Proceed and use x

As a parting coup, I gave the Python programmer a link to the JSON parser I built in Haskell, some years ago. My company uses Haskell, because we do not have much manpower. We do not get paid enough, so we take many contracts. We cannot afford QA teams, so we use a sadistic compiler. We cannot dedicate too much time to any particular project, so we prefer to learn dense idioms (which takes time upfront, and saves time later), rather than learn sparse idioms that take more time to implement every time and debug individually. We do not keep a project in live mode after we have handed it over, due to little manpower, so any bugs that we have to cure at our own cost must be caught in development. Now, if you have few programmers, then they should be very efficient, and the best place to optimise is the tools. To make a sufficiently-fast programmer faster—like a sprinter running on a conveyor belt—make him stop dealing with gratuitously-explicit if statements for a start (this is what makes threads difficult, for example: too many ifs). Enter monads.

It was embarassing to find that the language that we thought had shielded us from the assaults of the impractical ivoritoweritis of Haskell was always an accomplice in making us expert at implementing these self-same things at which we laughed. I have known betrayal—I have seen it, I have stood at a whiteboard and denounced it for what it was—and I took a picture of it.

[1] I use a Nokia N8. 12 megapixel camera. Terrifyingly-huge images. I love it.

I have moved this blog from Python 2.5 to Python 2.7 on the back-end, and also moved to Jinja2 templates. Not a terrible decision, but it resulted in more work than I had anticipated.

There is another instance, in Romans, of this “What, then, shall we say?” that I like. Romans 9:30-32:

What then shall we say? That the Gentiles, who did not pursue righteousness, have obtained it, a righteousness that is by faith; but the people of Israel, who pursued the law as the way of righteousness, have not attained their goal. Why not? Because they pursued it not by faith but as if it were by works. They stumbled over the stumbling stone.
τι ουν ερουμεν οτι εθνη τα μη διωκοντα δικαιοσυνην κατελαβεν δικαιοσυνην δικαιοσυνην δε την εκ πιστεως
ισραηλ δε διωκων νομον δικαιοσυνης εις νομον δικαιοσυνης ουκ εφθασενδιατι οτι ουκ εκ πιστεως αλλ ως εξ εργων νομου προσεκοψαν γαρ τω λιθω του προσκομματος

Now that I have decided to make this blog about implications—and that is wide, for everything has implications—I am yet to decide what I will do with it: what implications it will be concerned with. I think it will be more-mainstream than my other blog(s), but that remains to be seen. In the meantime, it can sit here taking a few pokes every now and then. Nothing serious yet, and I think some bugs still lurk. But otherwise, cool.

This blog is about implications. When you realise that a certain thing is true, what then?
The title of the blog, What, then, Shall We Say? is a phrase that occurs in Paul’s Epistle to the Romans. Romans 8:31:

What, then, shall we say in response to these things? If God is for us, who can be against us?
τι ουν ερουμεν προς ταυτα ει ο θεος υπερ ημων τις καθ ημων

Who will bring any charge against those whom God has chosen? It is God who justifies.

Initially, I expected to move my blog to here from [elsewhere —ED]. But I think I should turn this into something different, and they can co-exist. I think there is a reason for this, a reason I do not recognise yet. The only problem, of course, is that one master will have to be abandoned and the other loved a lot. Let’s see where it ends up.