wingolog

guadec ho!

2 July 2009 9:42 AM (guadec | gnome)

Does anyone have the address of the Mr and Mrs Vengaboy? I have a patch for them.

--- /tmp/were-going-to-ibiza.txt	2009-07-02 11:41:09.000000000 +0200
+++ /tmp/were-going-to-gran-canaria.txt	2009-07-02 11:40:53.000000000 +0200
@@ -1,8 +1,8 @@
 Whoa!
-We're going to Ibiza!
+We're going to Gran Canaria!
 Whoa!
 Back to the island!
 Whoa!
 We're going to have a party!
 Whoa!
-In the Mediterranean Sea!
+In the Atlantic Sea!

Anyone? Perhaps they have a Bugzilla somewhere.

* * *

I wrote to Federico earlier to let him know I was down for hippietime, saying I'd be at GUADEC from Saturday evening to Thursday at midday. He was surprised I was leaving early, which made me realize: why was I being so miserly with my time?

I think my thought was that somehow I couldn't afford to be away for so long, that maybe I should make it back and work the Friday. Ridiculous. I changed my flights so I'm leaving on Sunday instead. See you there, GNOME kin!

the chosen one

16 June 2009 8:53 PM (bike | barcelona)

Today I met up with an old friend I hadn't seen in a while, at the bar that he runs. Conversation was lovely. But that's not what I want to talk about.

On my way home, I rode on roads I hadn't been on in a while. I'm used to riding in the normal lanes, taking up the space of a vehicle, but they recently put in new protected bike lanes on these roads, so I decided to give them a try.

Most of Barcelona is laid out on a grid, with truncated corners. Like this:

   /------\ ^ ^  /------\
  /        \. " /        \
  |        |. " |        |
  |        |. " |        |
  \        /. " \        /
   \------/.  "  \------/
crossing *.   "
   /------\.  "  /------\
  /        \. " /        \
  |        |. " |        |
  |        |. " |        |
  \        /. " \        /
   \------/ . "  \------/
            . ^<- cars
            ^ <- bike lane

Streets are mostly one-way, alternating by block, and there are some larger arteries. The bike lanes that they put in are two-way, on the left of the cars. This means that every other block, cars will be turning into the bike lane -- a sure point of danger.

To compensate for this, the bike path designers made the bike lanes turn in at those dangerous crossings, and cross alongside the pedestrians. Cars are stopped at a light, in theory.

I suppose I appreciate the theory. In practice, it's a bit irritating to have to go the extra distance at the dangerous crossings. It slows you down, the curves present a danger of their own, and you make fewer lights. Sometimes there are times you could have caught the intersection if you were in a car lane, but the bike lane's light is red. Etc.

So when I came to about my tenth turnout, I looked around to see if there were cars, and seeing none, I decided to cut straight to the other side of the bike lane. I lined up my wheel with the rubber dividers separating the bike lane from the road, looked under my shoulder at speed, and accelerated across the intersection---

    ---into the air---

         ---to one of those brief moments of false clarity, the silent "shit!", the grasping rationality, the approaching pavement---

             ---the bounding up to look for cars---

                 ---the joke about it, ashamed of course, with the nearby parked scooter...

Apparently I didn't line up right with those damn rubber things. They're there to keep scooters out of the bike lane, but they have other effects.

My bike appears to be fine. Amusingly, the only lasting effect is that the left side of my handlebar has been bent back by about 15 degrees, which is one of the only parts that I haven't yet had to replace.

I would like to believe that in that brief aerial instant, that I executed some clever and graceful landing, informed by Aikido, but no, the evidence points elsewhere -- a skinned knee and elbow, a pedal-bitten calf, and two stigmata on the palms: perhaps a divine warning against hubris. The Lord does work in mysterious ways.

in the beginning was the word

14 June 2009 12:28 PM (scheme | flib | money | eisenstein | unwelcome guests)

shamanic rites

You see, magico-religious thinking normally works. Whether it is a shamanic rite, the signing of an appropriations bill, or the posting of an account balance, when a ritual is embedded in a story that people believe, they act accordingly, playing out the roles the story assigns to them, and responding to the reality the story establishes. In former times, when a shamanic rite was seen to have failed, everyone knew this was a momentous event, signaling the End of the World, a shift in what was real and what was not, the end of the old Story of the People and the beginning, perhaps, of a new one. What, from this perspective, is the significance of the accelerating failure of the rites of finance?

We like to scoff at primitive cave-dwellers who imagined that their representations of animals on cave walls could magically affect the hunt. Yet today we produce our own talismans, our own systems of magic symbology, and indeed affect physical reality through them. A few numbers change here and there, and thousands of workers erect a skyscraper. Some other numbers change, and a venerable business shuts its doors. The foreign debt of a Third-World country, again mere numbers in a computer, consigns its people to endless enslavement producing commodity goods that are shipped abroad. College students, ridden with anxiety, deny their dreams and hurry into the workforce to pay off their student loans, their very will subject to a piece of paper with magical symbols ("Account Statement") sent to them once every moon, like some magical chit in a voodoo cult. These slips of paper that we call money, these electronic blips, bear a potent magic indeed!

How does magic work? Rituals and talismans affirm and perpetuate the consensus stories we all participate in, stories which form our reality, coordinate our labor, and organize our lives. Only in exceptional times do they stop working: the times of a breakdown in the story of the people. We are entering such times today. That is why none of the economic measures enacted so far to contain the crisis have worked, and why the current stimulus package won't work either. None go deep enough. The only reform that can possibly be effective will be one that embodies, affirms, and perpetuates a new story of the people (if we can agree on one)...

This from Money and the Turning of the Age, by Charles Eisenstein. I prefer the audio version while doing the dishes: harness the desire to scrub out capitalism!

Lyn Gerry has been doing readings from Eisenstein's book on her radio show, and it's really quite a compelling story. I like the episodic audio delivery of the book, but if that's not how you roll, the whole text is available online as well: The Ascent of Humanity.

There's something about Eisenstein's perspective that really feels right. To me, his work has the quality without a name.

fringe languages in barcelona

The other day Jao and I had lunch with another Schemer in the area, Jos Koot, and we decided it's well past time to have a fringe languages group here in Barcelona.

The name comes from a blatant rip-off of what the charismatic Conrad Barski does in DC. Here's what he has to say about FringeDC:

It is commonly believed...

...that most programming languages languages are essentially identical. However, anyone who has spent any significant time studying languages such as Lisp, Haskell, or Prolog knows that some of these uncommonly used languages not only are fundamentally different from more popular languages but can actually give you a glimpse into the future of mainstream programming!

If you think ideas such as Aspect Oriented Programming or Microsoft's new LINQ system in C# 3.0 or Declarative XML programming in .NET or C++ Template Metaprogramming are entirely revolutionary new ideas, you are mistaken: They are all innovative but also evolutions from ideas developed long ago in Lisp, ML and other older fringe languages...

There's a fine line between being on the leading edge and being in the lunatic fringe.
-- Frank Armstrong

So it's in that spirit that I'd like to invite all in the geographical vicinity to our first meeting on this Wednesday, 19 edit: 17 June. Jao has more details as to the first meeting, but in any case check out the new evil empire Google Group, Flibug.

Jao is on deck to talk about Factor and FUEL, Jos to talk about PLT Scheme's Redex operational semantics debugger, and we'll go out for beers later. Good times!

hospitalized for approaching perfection

8 June 2009 9:30 PM (scheme | guile | june)

My god, June, June must be the most amazing month of the year. Things are green, and the awareness is palpable that summertime is here, in the street, at the bars, at the beach -- this is the time that is not the other time.

June is when strange and wonderful things happen. My sister, who lives in DC, called the other day to say she'd be here in Barcelona this weekend. Just on Sunday I was walking to the park and ran into an old friend I hadn't seen since 2000. June is the month of picnics: of picnics on the Seine, of picnics in the park, of picnics on the beach, of barbecues on terraces. June is for bare feet and open windows. June is for fireworks and music in the street.

hack

And yet, I hack, so much. I'm growing a little concerned, to be honest -- but now more than ever I feel like I'm doing my best work, and so I continue. It might be an illness.

In case you're new here, I've been hacking on Guile, an implementation of Scheme. Since my last dispatch, I landed a branch to Guile master that brings psyntax to the heart of Guile, as the default expander.

This was actually quite a feat, given the module hygiene work I wrote about earlier -- because how do you have an expander that understands modules and hygiene, before modules themselves have booted up? Anyway, it works now :)

For users, the practical implication of this is that syntax-rules and syntax-case are available, all the time. This is a lovely, lovely thing.

However, running the expander works against the most important performance hack of Guile 1.8: the memoizer. When you load a module, Guile 1.8 reads everything, but only does the minimum amount of work. For example, once it sees a procedure, it doesn't process the body of the procedure until the procedure is called. This reflects the reality that only a fraction of code is ever called, and was a big win for Guile 1.8.

But in Guile 1.9 / 2.0, we lose this advantage, as the expander does traverse all code. Of course, if your code is compiled already, it needs no expansion so loading is very very fast, but Guile has a lot of users and existing code out there, and I don't think they'd be particularly pleased if an upgraded touted to speed up their programs actually slowed them down.

So, for that reason, I hacked in some automatic compilation support, and turned it on by default. The upshot is that if Guile sees a file for which it can't find a corresponding compiled version, or the compiled version is out of date, it will compile it then and there -- and stash away the result, so it will be found the next time.

Of course, figuring out how to find the compiled files, and where to put the cache, but how to keep supporting shared installed architecture-specific compiled files, and how to cope with lack of permissions to write the compiled files, or errors in compilation -- you know, it's like Steve's legalizing marijuana. The devil's in the details. Hopefully I have things ironed out now, though. After all, if Python can do it...

Historically, expanding Guile Scheme with psyntax has had a couple more problems, though: the original variable names would be lost, due to the alpha renaming I discussed before; and, you lose source location information, so you don't know where backtraces come from. Through a stroke of luck and wine-induced hubris (thanks Ángel!), I did manage to plumb that information through, which is really pleasing.

(If you're still with me, I understand you are a programming languages enthusiast. Well to you I say: be wary of the verb "plumb". It suggests something shitty either about software of the process of making it. But I am willing to describe my interactions with psyntax as, indeed, shitty.)

(Continuing the parenthesis though -- are there not those that have a Freudian delight in shit? Whenever I hack psyntax I do feel better afterwards. It's a strange powerful relieved feeling.)

...

Perhaps the most relevant update from the last month in Guile is that we fixed a 2.0 release date, on the 15th of October; and we'll be releasing monthly until then, starting on the 19th of this month.

Also, Guile is finally joining the Unicode-speaking world, thanks to Ludovic Courtès and Mike Gran. We're using the little-known libunistring to do the heavy lifting; if there are packagers out in the audience, let this be my call to you to package this for your distros. It's by Bruno Haible, really well-done, and has been in Gnulib for a while now. It's time for it to go to distros.

Anyway, enough blathering for this Monday night. I was prompted into this by a fit of despair, looking again at the Waddell/Dybvig inlining algorithm. Perhaps after a more composed encounter with that paper, I'll have some novelties for the ether. Until then, happy hacking!

poverty, riches

14 May 2009 7:31 PM (poverty | namibia | riches | scheme | guile | dybvig | inlining | optimization)

riches, poverty

How many times have you heard the phrase, "the poorest of the poor, those that live on less than a dollar a day"?

I am tired of it.

You can grow your own food, and they call you "poor". Or you can buy transgenic, pesticide-laced, flavorless tomatoes at the store, and they call you "rich".

Poverty and riches do exist, but they have nothing to do with dollars.

hack reading

Fast and Effective Procedure Inlining, by Oscar Waddell and Kent Dybvig.

Great, great paper. It could be my ignorance, but I never realized that copy propagation, dead code elimination, constant folding, and procedure inlining were all the same operation.

I think I'm going to implement their algorithm soon. It should be straightforward, given that the new high-level intermediate language that I'm working on for Guile is basically the same as their language.

the very merry month of may

10 May 2009 8:23 PM (scheme | guile | ilc | los angeles)

Time passes.

In my last dispatch, I left readers dangling with partial summaries of the International Lisp Conference over in Boston; the only real thing I wanted to write more about was Sussman's lightning talk about visualizing the shapes of programs. Thankfully, my colleague Jao already shared his impressions, with more depth and eloquence than I could.

Then from there Jao and I headed on to LA to work for a few weeks. There's lots to write about from the work side of things; I like the gig quite a bit. More words at a later date.

Lately it seems that whenever I'm silent for a while, internet-wise, it's because I'm hacking on something that's not quite finished. Not that many things can be finished, mind you; but there is a rhythm of escape and return that hacking has, that you go out on exploratory tangents, and then only weeks later return to "home" -- maybe with freshly caught hackfish, maybe with empty hands.

The hunt that I'm on right now is to integrate psyntax into Guile. Psyntax is an implementation of syntax-case, a syntax expander for Scheme. It is a library, written in Scheme, which allows you to define macros for Scheme. If that doesn't make sense to you, perhaps we can regroup in another weblog post :)

But for the hacking audience out there, greets once more. Guile has had psyntax available as a library, (ice-9 syncase), for more than a decade. But this solution has two problems: one, that you have to explicitly request its presence in your program. This used to be a slow process, though now with Guile's compiler it's close to instantaneous. The second problem was more serious: syncase macros were not hygienic with respect to modules.

At a high level, "hygiene" in a program means that you can determine the meaning of a program by looking at its source. Macros, as programs that rewrite programs, can work against hygiene, sneakily introducing new variables into the rewritten programs that were not in the original text.

People who write syntax expanders for Scheme -- the programs that run macros on the source text -- have been very concerned about hygiene, and psyntax is no exception. But psyntax didn't know about Guile's modules.

Consider a macro like this:

(define-syntax foo
  (syntax-rules ()
    ((_ x)
     (bar x))))

This expander specifies that all instances of (foo something) be replaced with (bar something). But which bar? The reasonable answer to this is, the one in the module in which foo was defined. But Guile's psyntax integration instead chose the bar where foo was used.

This was because, 12 years ago or whatever, the psyntax expander had no conception of modules, so it had no way to know that the identifier that it was introducing in the output text -- bar -- came from a particular module.

Since then, psyntax actually grew a module system itself -- but since Guile already had a module system, Guile's copy of psyntax became a fork, because we couldn't include new releases of upstream psyntax. (Not that we had the hackpower to do it at that point.)

So making the psyntax expander hygienic with respect to modules was quite a task. In the end, though, I got it working, and Guile's psyntax expander now does the Right Thing(tm). Check out Guile from git to give it a run.

Incidentally, psyntax's current incarnation can be found over at Abdulaziz' site. There are a number of newer features that I need to backport from current psyntax, something we can get to with time. But our R6RS module system implementation will be independent from it.

a rose by any other name

The next obvious step was that once psyntax was working correctly, and loading speedily, we really should be using it throughout Guile. Scheme programmers expect syntax-rules and syntax-case to be there, and now that we can provide that nicely, we should do so.

I had other motivations for a tighter integration of psyntax. The recursive descent expander-cum-compiler that I had written duplicated many things that psyntax did, and expanded into a less orthogonal language than psyntax's output.

Plus, once I looked at starting to do optimizations, I realized that I was going to run into problems because of lexical scoping. Consider the following code:

(let ((square (lambda (x) (* x x))))
  (define * +)
  (square 10))
=> 100

One can trivially inline the square helper function, but a naive approach changes the meaning of the program:

(let ()
  (define * +)
  ((lambda (x) (* x x)) 10))
=> 20

The problem is that (* x x) in the first example did not have the same meaning as its occurrence in the second example.

The trick that most compiler writers use to get around this is just to rename all lexical variables. You know that (lambda (x) (+ x 1)) is the same as (lambda (y) (+ y 1)). This property is known as alpha equivalence -- the names of lexical bindings don't matter.

Alpha equivalence can be exploited to avoid problems like the one above. First we give the lexically bound variables new, unique names:

(let ((a (lambda (b) (* b b))))
  (define c +)
  (a 10))
=> 100

Now the inlining works as expected:

(let ()
  (define c +)
  ((lambda (b) (* b b)) 10))
=> 100

If I was going to have to go through the bother of renaming all of the variables anyway, I might as well use psyntax, which renames all variables as part of its transformation.

I go into all this detail because the topic is somewhat perennial. I was reading a paper about the Glasgow Haskell Compiler earlier this evening, and they actually avoid renaming, because generating fresh names is too expensive for them:

If the compiler were written in an impure language, fresh names could be allocated by side effect, but GHC is written in Haskell, which does not have side effects. Using the trees of [ARS94] is the best solution we know of, but it still involves plumbing a tree of fresh names everywhere they might be needed. Worse, the fresh names usually aren't needed, but the tree is nevertheless built. This is deeply irritating: loads of allocation for no purpose whatsoever. Finally, even if we were not worried about performance, it is sometimes extremely painful to get the name supply to where it is needed.

Color me amused.

but yes, back to the story

Anyway, I had sufficient motivation, and thankfully a chunk of time in which to poke at it. My syncase-in-boot-9 branch has the results. I reimplemented defmacro in terms of syntax-case, which is pleasant.

It was quite a difficult hack, because it's at boot time when you don't even have modules -- yet you need to know something about modules, for hygienic purposes, and then modules get booted later... quite some quandaries debugging it. But it at least recompiles itself, and seems to run fine.

I'm holding off on merging it because I'm still running the old recursive-descent compiler on its output, whereas I need to write a compiler that operates directly on its output instead of treating it as unanalyzed Scheme. Maybe next week.

Enough writing for today. Tomorrow, back to work again -- hopefully with all of this written, further updates will be easier to push out.

international lisp conference 2009, day three, part 1

25 March 2009 2:49 PM (lisp | ilc | guile | scheme)

Another day, another parenthetical note. It's probably worth repeating that these are just personal impressions, take them with a salt lick.

François-René Rideau spoke about XCVB, a packaging system for Common Lisp. Slides here. From what I gather, XCVB tries to make separate compilation of Lisp libraries more robust via mechanisms that isolate compile-time side-effects.

More interesting was where he headed at the end of his talk, and expanded on in a lightning talk: that the things that we do are intertwined with the stories we tell others and ourselves. The bad stories are about things. The better stories are about people making things.

Next up was a presentation by Gary King from Franz Inc., about AllegroGraph, a massive RDF triple-store capable of storing and searching billions and billions of triples. Specifically, as far as I could tell, it was about adding temporal and geospatial capabilities to queries -- so you could ask "Of the people that Bob called last week, who has a friend within 5 miles of the Boston area?"

It was quite impressive, but it makes me queasy too. Who has billions and billions of facts and needs to query them? Well, the CIA, the NSA, and similar organizations. Others too of course, epidemiologists for example, but that doesn't ease the quease.

Next up, something totally different. John Hastings lives in Nebraska and has a problem with grasshoppers -- they tend to eat up all of the grass that cattle graze on. Ranchers out there would douse their land with chemicals at any word of a grasshopper outbreak. But that's not good for the land, and it's also expensive. So he wrote an expert system to help ranchers say what the conditions are where they live, in Lisp, and help them decide what to do. The program gets deployed into peoples' web browsers via one of the Lisp-on-the-JVM projects. Voilà fewer chemicals!

Next, a talk by an engineer at Cadence Design Systems, on how they use Lisp to lay out certain kinds of electronics called "systems-in-a-package", such as the circuit boards and the amplifiers and conditioners and such. His point appeared to be that giving the user a way to extend and specialize certain designs via generic functions lets them deliver applications without source, but still allow some extensibility. I didn't care for the "freedom subtracted" aspect, but seeing more about chip design processes was interesting.

Jorge Vallejos from the Vrije Universiteit in Brussels took the floor next. His talk was on distributed computing within the Actors paradigm, whereby objects on different machines can reference and send messages to each other. The interesting part was how he used actors as containers for unadorned objects, and used generic functions to "invoke" remote objects. The meta-object protocol allowed him to extend base Lisp to have remote asynchronous procedure calls, while keeping a natural Lisp feel. It was fine, but something about RPC as a distributed programming metaphor doesn't sit right with me. I probably missed something.

Didier Verna followed, with a delightful talk comparing the speed of Common Lisp and C++. He works at a lab in France that does lots of numerical processing on images, and is the only Lisper in a roomful of C++ wizards. The funny thing is that he says he doesn't care about speed, because things are fast enough, but that he was tired of getting shit from his C++-loving coworkers, so he decided to do some measuring.

This guy is serious. This is his second paper in a projected series of 5 or so; his last installment showed that Lisp and C are comparable in speed. This talk compared instantiation time for C++ objects to instantiation of Lisp structures and CLOS objects, showing again that Lisp was comparable in speed with C++. Unfortunately the paper and slides don't appear to be online; I'll ask him about this.

Also, Verna gave a lightning talk in which he explained that Lisp is Jazz and Jazz is Lisp. When asked by the audience about other things, he explained that they were Jazz too. Also Lisp is Aikido, and buy his CD.

* * *

In a later post, I'll get to Sussman's talk on evolvability and robust design. It will take some thinking to summarize.

international lisp conference -- day two

24 March 2009 2:15 PM (ilc | lisp | cambridge | guile | scheme)

So, picking up where I left off...

David Moon, about whom the internet knows surprisingly little, gave a wild talk on a language he's been working on: the Programming Language for Old-Timers. Actually the talk wasn't about the language, but its macro system. PLOT is a language with syntax, but whose grammar is defined in itself.

PLOT macros take token streams, produced by a fixed tokenizer, and perform LL(1) parsing on that stream, building up abstract syntax tree objects or returning other token streams. Actually, given that macro output can be AST objects, macros take AST fragments as well. The interesting thing is that macros are hygienic, that they track source locations, and that they have access to the full PLOT language themselves. It seems that you can actually implement Lisp macros on top of PLOT macros.

Anyway, a sharp tool, but I look forward to seeing what Moon carves with it.

Next up was a talk by Joe Marshall, a Scheme hacker now working at Google, about implementing continuations on machines with no continuation support, like the JVM or CLR. The basic idea was for functions to be modified to return an OK/Error flag, with the actual return value in an additional output argument. The compiler should do some live-variable analysis, and have a separate flow path that saves variable values all the way down the stack, as functions return "Error", and that can be restored when you reinstate a continuation.

It's nasty. Joe must really want Scheme on the CLR.

Next there was Alexey Radul, a grad student of Sussman's, giving a talk entitled "The Art of the Propagator". The concepts were interesting, although hindered by Radul's poor diction. The basic idea appears to be an approach to calculating constraints-based systems in the presence of backtracking and conflicting information, with electronics as a metaphor -- connecting boxes and wires, signals flowing back and forth. Not like any problem I have ever seen in practice, though.

Following that were a set of lightning talks, the last of which was legendary: one M. Greenberg (who was that guy?) talking about the history of an old macro system, TRAC. Apparently all computation in TRAC was done by macros. Macros could rewrite their definitions out of existence, and thus be recursive and terminate. It was startling, but Greenberg steeled our resolve with the words, "Don't be afraid of macros -- they'll sense your fear, and fuck you up."

Then, a panel discussion on the future of Lisp, the ostensible topic of the conference. From left to right there was Pascal Costanza, an academic from Brussels hacking mostly on CLOS-related things; Edi Weitz, an industrial Common Lisp hacker; Ravi Nanavati, an erstwhile Schemer but current Haskeller; Rich Hickey, Clojure language designer; Alan Bawden, former Scheme Steering Committee member; Duane Rettig, Allegro CL hacker; and Scott McKay, a former Scheme and Dylan hacker now working for ITA software. Kent Pitman moderated.

It started good, with the long view, then things devolved. Eventually the audience started to talk with each other instead of with the panel, and for some reason settled down onto the "why isn't Lisp popular" navel-gaze. Quite disappointing.

After dinner, there was a staged "debate" on "Macros: Are they a menace?" It was obvious that the panel (Steele, Gabriel, Costanza, and the scapegoat, someone whose name I forget) was having a good time. At one point, Gabriel wrote out the "(defmacro .....)" on the chalkboard, noted that the "..." is often large and thus heavy and must sink to the bottom, leaving the parenthesis before the "defmacro" looking like a frowny face: q.e.d.

More seriously, the arguments against macros centered on control: control by bosses on workers, with the idea that macros make custom languages, thus making individual programmers less replaceable. While I don't believe the premise, the conclusion to me comes from another world. I hack Free Software precisely because I like my trade, and want to practice it in an environment free from coercion and domination.

The "debate" had an interlude, in which Costanza asked Sussman why MIT had switched away from Scheme for their introductory programming course, 6.001. This was a gem. He said that the reason that happened was because engineering in 1980 was not what it was in the mid-90s or in 2000. In 1980, good programmers spent a lot of time thinking, and then produced spare code that they thought should work. Code ran close to the metal, even Scheme -- it was understandable all the way down. Like a resistor, where you could read the bands and know the power rating and the tolerance and the resistance and V=IR and that's all there was to know. 6.001 had been conceived to teach engineers how to take small parts that they understood entirely and use simple techniques to compose them into larger things that do what you want.

But programming now isn't so much like that, said Sussman. Nowadays you muck around with incomprehensible or nonexistent man pages for software you don't know who wrote. You have to do basic science on your libraries to see how they work, trying out different inputs and seeing how the code reacts. This is a fundamentally different job, and it needed a different course.

So the good thing about the new 6.001 was that it was robot-centered -- you had to program a little robot to move around. And robots are not like resistors, behaving according to ideal functions. Wheels slip, the environment changes, etc -- you have to build in robustness to the system, in a different way than the one SICP discusses.

And why Python, then? Well, said Sussman, it probably just had a library already implemented for the robotics interface, that was all.

* * *

Now it's Tuesday morning, which started with some guy talking about bombing people with Lisp. Or maybe it was about supplying parts to the military. At one point there was a slide with a little clip-art tank and a clip-art pistol and a clip-art fighter jet. Sheesh.

Finally, via Richard Gabriel: Cobol on Cogs. Enjoy.

international lisp conference 2009 -- day one

23 March 2009 3:36 PM (lisp | ilc | guile | scheme | clojure | clos | goops)

Greetings from Cambridge! The American one, that is. I'm at the International Lisp Conference, which is an OK set of talks, but an excellent group of almost 200 Lisp hackers. What follows is not strictly journalism, but rather reflections of a more subjective nature.

Sunday was reserved for "tutorials", four sessions of an hour and a half in length, with an expository and relaxed flavor. There were three sessions running at a time, which made for some hard choices.

The first session that I went to was "Monads for the Working Lisp Programmer", which started off by explaining monads, and in the second session looked at their uses. As a working Lisp programmer, I guess it's good to be able to talk down Haskell weenies, but something about the complexity of the "plumbing" doesn't sit right. People keep talking about separating the "plumbing" from the computation -- as if programming somehow involves clogged pipes or something. The presenters did a good job, but "different strokes, different folks". I jetted out after the first session.

Next I decided to drop in on the second session of Pascal Constanza's tutorial on CLOS, generic functions, and the meta-object protocol. It was very clearly presented, and even though I've been working with GOOPS (a CLOS-a-like) for a long time, I came away with some style tips. Also seeing his LispWorks environment was very interesting. So much of programming is workflow and environment, something that often requires you to look over the shoulder of a master. I was a bit frustrated though, as I came with questions but it seemed Pascal had a curriculum he wanted to stick to. I'll corner him later.

Actually, that's the best thing about this conference, this ability to corner smart people. So far they don't have that harried, ragged look yet.

In the afternoon, I went to Rich Hickey's Clojure tutorials (parts 2 and 3). What a treat. Hickey's instincts and good taste as a language designer are evident. All languages deserve to have his persistent data structures. His discussion of state and identity was particularly lucid, as well. (Hickey say that the talk on state and time was basically the same one he gave at InfoQ.)

Personally I don't care for the JVM, and I feel Clojure's worth as a general-purpose language is actually hampered by the lack of tail recursion, but I really think that his design ideas should percolate out to all the dynamic languages of the world.

Now it's Monday morning, and I'm sitting in on the plenary technical talks and software demonstrations. They're OK, but thus far yesterday had a better feel. I'm very much looking forward to the afternoon sessions.

libreplanet 2009

16 March 2009 9:19 PM (libreplanet | fsf | boston)

Brian Gough wrote in to note that felicitously, just prior to the ILC, the Free Software Foundation is organizing LibrePlanet 2009.

So if any GNU hackers want to meet up on Saturday, March 21, perhaps we'll see each other at the conference, or more likely at the bar: the Redline pub on Harvard Square, 18h-21h. (I'll be the jetlagged guy who looks like he's been in transit for 15 hours.)

(I find the FSF a bit strange sometimes -- the suggestion that I'm not actually a member of it without paying money when all of my GNU work is assigned to it is offensive. I can only assume some temporary confusion of otherwise well-intentioned people.)