Lambda the Ultimate

Does anyone know if the webcast will be saved for later? I'd rather see how my Frink talk goes off before telling my friends to watch. :)

The previous webcasts were saved (e.g. at LL3). So if we crash and burn, it will be recorded for posterity, and freely watchable by (in theory) billions of people around the world. Now there's an incentive!

BTW, thanks to Matthew Morgan for the plug in the original post.

> Time flies like an arrow, fruit flies like a banana.

Syntax error in Line 1, column 1. I'm going home.

"I dunno... I'd hate to be the one to write the parser for English. :)"

http://en.wikipedia.org/wiki/Basic_English

All excellent points, but I think that the current attempts of computers to take a more active role are often less than impressive. Have you met my good friend, Clippy the Paperclip?

Back to PLs: what makes them different from other languages? Pragmatic desire to make them as context-independent as possible or even more? Sacrificing holism to version control and modularity?

Leibniz gave a good answer to this question back in 1677:

Now the characters which express all our thoughts will constitute a new language which can be written and spoken; this language will be very difficult to construct, but very easy to learn. It will be quickly accepted by everybody on account of its great utility and its surprising facility, and it will serve wonderfully in communication among various peopl
es, which will help get it accepted. Those who will write in this language will not make mistakes provided they avoid the errors of calculation, barbarisms, solecisms, and other errors of grammar and construction. In addition, this language will possess the wonderful property of silencing ignorant people. For people will be unable to speak or write about any
thing except what they understand, or if they try to do so, one of two things will happen: either the vanity of what they advance will be apparent to everybody, or they will learn by writing or speaking. As indeed those who calculate learn by writing and those who speak sometimes meet with a success they did not imagine, the tongue running ahead of the mind. This will happen especially with our language on account of its exactness. So much so, that there will be no equivocations or amphibolies, and everything which will be said intelligibly in that language will be said with propriety. This language will be the greatest instrument of reason.

In addition, this language will possess the wonderful property of silencing ignorant people. For people will be unable to speak or write about any thing except what they understand, or if they try to do so, one of two things will happen: either the vanity of what they advance will be apparent to everybody, or they will learn by writing or speaking.

Sadly, the advent of computers changed all that.

Sadly, the advent of computers changed all that.

I see it as quite the opposite. The more formally-founded computer languages are as close a realization of Leibniz's vision as humans have yet achieved, and the computer provides an automatic check for some of the "errors of calculation, barbarisms, solecisms, and other errors of grammar and construction" with which Leibniz was concerned, providing an external check of greater rigor than would be possible with rooms full of monks scrutinizing manuscripts.

Dijkstra was a firm advocate of Liebniz's dream, as the (no doubt familiar) EWD1298 and EWD1243a demonstrate:

In the next fifty years, Mathematics will emerge as The Art and Science of Effective Formal Reasoning, and we shall derive our intellectual excitement from learning How to Let the Symbols Do the Work.

Calculemus!

providing an external check of greater rigor than would be possible with rooms full of monks scrutinizing manuscripts

Checks which most programmers are not only all too happy to throw to the wind, but indeed seem to regard as a constriction of their personal liberties. The ease with which we can write programs—both meaningless and meaningful—is both a blessing and a curse.

But enough of that. I am far more interested in the fact that you recognized my quote. Did you Google it? (Is that why you have "googlish" for "ghoulish"?) I memorized this poem of Robert Service's, My Foe, for English class in seventh grade, and AFAIK it's not one of his most famous. (I think the most famous one is The Cremation of Sam McGee.)

P.S. I misremembered it:

Here amid the wreck and rout
Let us grip and have it out!
Here where ruins rock and reel
Let us settle, steel to steel!

Checks which most programmers are not only all too happy to throw to the wind, but indeed seem to regard as a constriction of their personal liberties.

You're just focusing on a particular type (heh) of check. There are many other checks that have to succeed for any program to run usefully. Certainly, if we were trying to convince Leibniz of something, we might wish to use every bit of rigor at our disposal, and achieve that pinnacle of monkish elegance in which every term is typed, the equivalent of dotting every 'i' and crossing every 't' — painstakingly, with gold leaf.

But if all one needs to do is convince a computer to, say, accept text messages and store them in some form for later rendering, or perform some simple arithmetic operation on numbers and produce totals — which two basic operations constitute an enormous proportion of most systems in the commercial world — then the marginal cost/benefit of extra rigor may be hard to justify, especially in the current context in which existing languages make this choice so starkly binary and irreversible - choose a particular language, and be forever doomed to produce nothing less than ultimate rigor, regardless of whether the situation really warrants it.

Perhaps we need more economic analyses of the impact of static typing, but we can already draw some conclusions simply by examining the market.

But enough of that.

Oh, OK. ;)

I am far more interested in the fact that you recognized my quote. Did you Google it? (Is that why you have "googlish" for "ghoulish"?)

Yes, and yes. I googled it in part because the line you quoted was intriguing, and the poem didn't disappoint. It seems kind of gruesome for seventh grade, though!

P.S. I misremembered it:

I know, that threw off the search on the first pass. Reducing it to some essential words did the trick (rock reel settle steel). Who needs a semantic web? ;)

Although it's getting a little late, you might try asking on the ll-discuss list.

I'm afraid I'll be closeted in my hotel room, trying to make sure I can fit my talk into a mere 25 minutes!

Here's a review of my Frink talk that I found from perusing my referrer logs. I appreciate the author's comments--it's a good synopsis of what I talked about, along with some of his own calculations and derivations. (Don't worry, I'll post the bad ones too if I find any. :) )

A URL is a GOTO. Who knew?

At least I now know the exact location of the itch that Frink was created to scratch...

A URL is a GOTO. Who knew?

I assume that's a reference to my REST talk. I intended the slides to be somewhat readable by people not already familiar with the subject, otherwise I could just have said "REST applications are implemented in CPS" and gone from there.

In fact, I should have done more of that in the actual talk, but unfortunately, a problem with my laptop at the beginning (the wireless LAN started spewing errors) forced me to reboot it. That wasted time and really threw me off the pace of my talk, and I didn't get to provide the context for the later slides that I wanted to.

I'll be writing up some details and posting it over the next couple of weeks.

BTW, as for whether a URL is a GOTO, the slide being referenced by the above quote is only part of the story. In a REST application, a URL is more than a GOTO: it represents a continuation, complete with state, but most of the state is stored in the form of resources on the server. The URL (continuation representation) references that state. An ordinary GOTO in a traditional program isn't the same thing, because the GOTO itself does not represent any state; which of course, is precisely how GOTO's differ from continuations.

In your resource caching example, are you doing a server side redirect to a point after the users form data has been processed? Is this a similar approach to the 'Post-redirect-get' pattern [1] to avoid double processing of data?

[1] http://www.theserverside.com/patterns/thread.tss?thread_id=20936

In your resource caching example, are you doing a server side redirect to a point after the users form data has been processed?

Yes.

Is this a similar approach to the 'Post-redirect-get' pattern [1] to avoid double processing of data?

That aspect of it is the PRG pattern, used here to provide the client with the URL of the resource that's just been created (or perhaps updated). The call to redirect-to in slide 49 implements that.

But the broader idea is to allow a workflow to expose its intermediate steps as (REST-compliant) resources, without being required to code the entire workflow in CPS style. (In real applications, the workflow would have more than just the two steps shown in the slide example.) The URL returned to the client isn't the "traditional" temporary URL with an embedded continuation identifier — instead, it's a URL representing a resource, which the server framework maps onto a continuation, if an appropriate continuation exists. There are a number of ways this mapping can be implemented, depending on the application.

An interesting fringe benefit of RESTful abstract continuations is that the state of a computation can be exposed for inspection. If we move ahead in the computation by POSTing to the current continuation (which will create a new resource, representing the next continuation), then we should also be able to query the current state using GET, and perhaps even cancel or roll back with DELETE.

Even in a context where one doesn't have first class continuations in the implementation language, I'm persuaded that abstract continuations are useful for thinking about the flow of RESTful applications, and offer an elegant way of dealing with situations involving complex program state.

Just a thought: The URL of the continuation could always be on another server. Could we then try multiple branches of the same search tree simultaneously, in a distributed fashion, while still using continuations to manage backtracking?

You'd need a controller somewhere for all those continuations, but other than that it sounds like a workable approach.

Connecting to your point about inspecting the state of computations, I'm envisioning a script in the browser opening a new tab for each continuation being pursued, waiting for the response, and then the tab closing itself if the desired result wasn't obtained. In the end, all that would be left is a single tab with the correct result. It'd be a fun demo, at least.