## LL4 Program and Abstracts

The program and abstracts for LL4 are available, including a presentation by LtU's own Anton van Straaten on reconciling REST and continuations. (Here's hoping LL4 will be webcast as in previous years.)

## Comment viewing options

A previous discussion on LtU mentioning REST.

### Webcast

By popular demand, we will be webcasting again. http://ll4.csail.mit.edu

### Change in program

I noticed that there was a change in program yesterday or today. The previous keynote address, "Debugging without Programming" by Henry Lieberman and Earl Wagner has been replaced by a talk entitled "English: The Lightest Weight Programming Language of All." by Hugo Liu and Henry Lieberman. Looks very interesting, too. I'd love to see them both!

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

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

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

Glad to see there's a webcast. 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. :)

### I'm sure it will be saved

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.
It's either worse than that, or not that bad. The parser could get past column 1, and in fact could easily reach column 33 or so without incident. The problem then becomes deciding which column to report the error in. Reporting column 1 is a bit misleading -- a sufficiently intelligent parser might phrase that more meaningfully as "Dude, line 1 is just plain confusing!" Which could actually be considered a fairly reasonable response...

### how about basic english

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

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

### Stop dominating your computer :-)

It was:
Human> Time flies like an arrow, fruit flies like a banana.

Computer> Dude, line 1 is just plain confusing!

I would prefer:
Human> Time flies like an arrow, fruit flies like a banana.

Computer> Hehe, funny :-) Do you want me to remember this? Or to criticize your style?


On a serious side: a language is not only syntax and semantics. Any language serves for communication between parties. And its use depends on the relationship between particular users - the same sentence may serve as a command, a notice, or even a joke - depending on a communication history AND extra-language relationship. The meaning of Human's statement might differ depending on whether the parties were communicating about philosophy or English language before this particular exchange. Or was it a koan to enlighten the Computer? Is the Human a teacher or a master?

Unless their previous discussion prepared a sufficient context, this statement will be puzzling to humans as much as computers.

Why are we always commanding computers, and mostly outside of any historical context?

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?

### I am waiting for my computer to command me

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.

### Here among the rock and reel / Let us settle, steel to steel!

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.

### Come to ravish, come to loot / Come to play the googlish brute.

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.

The advent of computers, however, did not necessarily change human nature.

### EWD

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!

### But the HAND...!

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!

### Holy rattling buzz saws, batman!

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? ;)

### For those going to the workshop...

Is there anything going on Friday night? I'm flying in tomorrow afternoon and out on Sunday morning, so in lieu of site-seeing I was wondering if anything was going on or anyone getting together the night before?

### Try ll-discuss

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!

Not fair!

### Did it happen?

Did LL4 take place on Dec 4 or do I have the date wrong? Any reviews of the talks available anywhere?

### One Review

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. :) )

### Yep, it happened!

The conference did indeed take place on Dec. 4. And it was indeed fun! Well, fun except for the poor people who had to sit through my Frink talk. :)

I haven't seen any posted reviews of the talks, but the talks themselves are available for viewing via RealPlayer at the official LL4 website. I did get a lot of positive feedback on my talk, and lots of complimentary e-mails. Thanks, guys!

I think everyone was universally impressed with the Gooze "stream processing language" talk which was visually very flashy and technically impressive. I can't believe how fast that stuff runs... it did effects on video streams in real-time, and not just one but dozens of streams. If you want to watch it, that starts the "afternoon session 2" file. (I'm the other half of that file, starting about 33 minutes and 40 seconds into it.)

As Anton noted above, the time was really short. The organizers ruled the clock with an iron fist, and 25 minutes for presentation plus 5 for questions went really, really quickly, and there was absolutely no room for slippage. I think everyone had to pare down their talks on the fly. But that made the conference run efficiently and enjoyably. I know I was moving pretty fast, and didn't get to all of my material by a long shot.

My favorite part of the conference was the question-and-answer session after my official question-and-answer session. Lots of people came down to talk about obscure topics in measurement theory.

I'll be fixing up and publishing the notes from my talk within the next few days.

### IronPython

Just watched Jim Hugunin's IronPython implementation talk on the webcast, which was very informative - answered a lot of the questions I had at the back of my mind about how the more dynamic features of the language could be handled.

One thing he said in the Q&A was that he preferred statically-typed languages for larger projects where he already knew what he was doing, because the static type declarations were a good way of capturing that knowledge up-front. Large Python frameworks (Zope, Peak, Twisted etc) are increasingly making use of "interface" objects to enable a similar sort of self-documenting / DBC(-ish) approach.

The discussion of "code insight" support in VS.Net was interesting, too. I've tried any number of Python IDEs, and PythonWin (which in the script editor just remembers things you've typed before) still has the most useful code completion of any of them. Improving on that level of support is probably, as Jim suggested, a research project.

### Frink presentation now available

I've turned my presentation from the Lightweight Languages 4 conference into more platform-friendly HTML format. I've also turned my notes into a more human-readable semblance of either what I said, or what I meant to say, or what I didn't get to say due to time restrictions. It includes links to watch the webcast as well.

I'll be revising it slightly over the next few days. I did some surveying of MIT's "Infinite Corridor" with my GPS receiver in an attempt to get a better measurement of the azimuth of the corridor and predict sun and moon alignments. (Initial predictions are at the end of that presentation.)

### More presentations online

Several more presentations were put online yesterday at the LL4 site.

### Wow

A URL is a GOTO. Who knew?

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

### This thing all things devours: birds, beasts, trees, flowers

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.

### cache-resource-here

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?

### Re: cache-resource-here

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.

### I can't go on. I must go on.

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.

### distributed amb?

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?

### Controller?

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.