A thought that struck me in the swimming pool today.

Lazy lists are another kind of late-binding.

Everyone hypes lazy lists by saying “wow! you can even have infinitely long lists!”

To which the natural response is, “So what? The universe is finite and my life and this program are certainly finite, why should I care?”

But, instead think about this. “Infinite lists” are really “unbounded lists” are really “when you create them, you don’t know how long you want them to be” lists.

It’s another part of the program, the “consumer” of the list, which knows how long you want them to be.

For example, I’m currently generating patterns in Clojure + Quil. Here’s one which is basically formed by filling a grid with a number of tiles.


The important thing here is that, although I know I want a repeated pattern of different tiles, I don’t need to know how many of these tiles in total I’m actually going to need to fill my grid, so I just create an infinite list, using

(cycle [tile1 tile2 tile3 tile4])

Then I have a function which zips the list of tiles with a list of positions to be filled. The list of tiles is infinite, but the list of positions on the grid isn’t, so the zipping ends up with a finite grid of tiles.

In a sense, this is yet another example of “late-binding” (ie. leaving decisions as late as possible). It allows the names of data-structures to stand for things (data-structure) whose shape and extent is determined much later.

I’m expounding my usual “late-bound” tabs model of IDEs again, over on StackOverflow.

… late binding between the buffer in the editor and actual concrete thing you’re working on, gives the editing environment more flexibility and power.

Think this is out of date? One place where the idea is back with a vengeance is in the browser, where you don’t have 1-1 correspondence between tabs and web-pages. Instead, inside each tab you can navigate forwards and backwards between multiple pages. No-one would try to make an MDI type interface to the web, where each page had it’s own inner window. It would be impossibly fiddly to use. It just wouldn’t scale.

Personally, I think IDEs are getting way too complicated these days, and the static binding between documents and buffers is one reason for this. I expect at some point there’ll be a breakthrough as they move to the browser-like tabbed-buffer model where :

a) you’ll be able to hyperlink between multiple files within the same buffer/tab (and there’ll be a back-button etc.)

b) the generic buffers will be able to hold any type of data : source-code, command-line, dynamically generated graphic output, project outline etc.