Keep Working, Worker Bee!


Okay, time for the rest of the Startup School writeup.

Michael Mandel — Chief Economist, BusinessWeek

Mandel had a pretty amazing talk. He only spoke from prepared remarks for a few minutes, and then opened up his talk for questions. This wouldn't work for most people, but Mandel was so provocative with his prepared remarks and so broad in his ability to answer questions that it worked.

His talk was about the larger economic context of startup businesses. He said what he's learned about economies can be summed up in four words: "Boom, bust, boom, bust." Furthermore, no matter what stage you're in, everyone thinks it'll never end. Now that there's a bust people think it'll go on forever, but during the Internet boom people thought that would go on forever too. He said that once he was giving a talk called "The Coming Internet Depression" and after the talk, "a bunch of Cisco executives pushed me against a wall and suggestied I should recant, or bad things would happen to my Internet connection."

Economists don't talk about startups very much, but in Mandel's view the chief advantage of the United States is that we foster innovation. Not technology, per se, since that can transfer across borders very easily, but a culture that actually fosters innovation. That puts us in a great position to be the engines of economic growth, since innovation accounts for something like half of all economic growth.

More specifically, he listed some of the US's key advantages:
  1. Financial. The US is, in Mandel's view, the only country in the world with a viable venture capital system.

  2. Human capital. People here are willing to work harder to make innovation happen. The role of a venture capitalist is not to give you money, it's to spur you on to do better. As he said, their job is to throw you out if you have a good idea that you're not executing well, and it's your job to not give them that chance.

The problem with economies driven by innovation is that they're more susceptible to boom/bust cycles. That's why he's worried about China's move towards capitalism: not because they're booming right now and are going to take over the world, but because eventually they're going to have a big old capitalist-style bust and they've got a communist government that may not be able to handle it.

Steve Wozniak

Woz gave a fast-and-furious talk about the origins of Apple Computer in just something he was doing in his spare time. He went much too quickly for me to keep notes, so you'll just have to download it from the Startup School's presentation page to listen to it. One thing that struck me was that we take computers so much for granted that we forget that just a few decades ago they didn't take for granted that a computer game could be written entirely in software, for instance.

Mark Macenka — Partner, Goodwin Procter

Macenka gave a talk called "The Great Value of Avoided Mistakes" about the legal stuff you ought to know about beforehand rather than finding out later on you should've known about. First of all, he said you've got to understand that you need to get cashflow-positive as soon as you possibly can.

Second, you need to know your intellectual property status and be sure where you stand there. Before you get started, know the rights of your former employers, your NDA status, your non-compete status, and so on. Remember that your former employer doesn't have to win a court case with their non-compete agreement, they've just got to scare away the company that would otherwise be buying you; in other words your former employer's rights might be more important than you thought. Also consultants, research sponsors, and the other owners of your company are important considerations at the outset.

A related issue is third-party infringement — if you're using GPL software in your application, for example, be sure you're not using it in an illegal way, and if you are using it in an illegal way make sure you fix it immediately. If you don't fix it immediately it'll just get harder and harder later on, and deals really do fall through based on issues like this.

Also be sure you're clear on who owns what within your group of founders, and make certain you can't get screwed by them. If your not careful, one of your co-founders might quit a few months in and still end up owning half the company, and if that happens you're working for them.

Stan Reiss &mdsah; General Partner, Matrix

"What's venture capital about?" Reiss answered this question from the perspective of a real live venture capitalist. First off, venture capital isn't for everyone, and if you can't make more money by accepting venture capital and its associated strings than you can without it, then you shouldn't take it. (Sounds obvious, but apparently a lot of people don't think about this calculation very much.) That said, VC-backed firms really do tend to have much bigger outcomes than non-VC-backed companies. (Exactly why isn't totally clear, but it could be due to the fact that VC firms are more interested in companies that bigger outcomes, or simply that the good VC firms are really able to make good companies great.)

He also said that while it's tempting to think that venture capital is very hit-and-miss, but the reality is that the top ten venture capital firms are making about 80% of the money of the entire industry, and the list of companies in the top ten have barely changed over the last 30 years. So it's very important to be backed by a good firm, not just any firm.

The question and answer period was pretty weird, dominated mostly by people who wanted to know how they ought to protect themselves from the evil VC companies that were going to listen to their pitch and then steal their brilliant idea to give it to someone else. I was reminded of Paul Graham's comment:
Actually, startup ideas are not million dollar ideas, and here's an experiment you can try to prove it: just try to sell one. Nothing evolves faster than markets. The fact that there's no market for startup ideas suggests there's no demand. Which means, in the narrow sense of the word, that startup ideas are worthless.
Reiss, along with everyone else who talked about VC, pointed out that they're really much more interested in the quality of the people than the ideas.

Stephen Wolfram — Founder, Wolfram Research

Stephen Wolfram told us all about his revolutionary and new ideas about science that in the long run will overturn everything we thought we knew about anything (it's true, just ask him) and in the short run produce nifty ringtones. You can't argue that he hasn't been able to create a successful business, though, and he thought he knew why: first of all, his entire company insists on understanding everything from first principles before doing anything, and that includes everything from the mathematical principles to the design of the user interface. (I haven't used Mathematica enough to know whether this approach works, but it sounds good anyway.) Second, he said that at the core of everything successful is some very hard problem, though it might not be where you expect it, meaning that if you want to start a successful business you've got to be willing to take on hard stuff.

Chris Sakka — Principal, New Business Development, Google

This talk was basically an ad for Google, but it was a heck of an advertisement. He (and his incredibly slick slides that were certainly put together by some graphic designer somewhere) basically said:
  • Start!
  • Focus on solving a user problem first and let monetization flow from that solution
  • Go big!
  • Make a demo as soon as you can — just talking about stuff won't get you very far; you need to really show people what your product does before they'll be interested.

Sakka also spent a long time talking about how great Google is to work for — on-site laundry, a giant gourmet cafeteria where the whole company eats at once (they like to do it that way so people can sit around and spin ideas off each other), a culture of complete openness, and so on. The clear message was: build a company to be bought out by Google, because if you do and you're good enough you'll get to come work for us.

Olin Shivers — Associate Professor, Georgia Tech; Founder, Smartleaf

Olin basically just went down the list of things he thought people might not know that he'd learned through starting a company. His major points:
  • Choose your co-founders wisely. You're getting married to them for all practical purposes, so treat it that way.
  • You should be open about money. People tend to try to be private about that stuff, but it hurts the internal politics of a company more than it helps it.
  • Venture capitalists: you'd think they're all technically deep, experienced managers who are contrarian and have nerves of steel, and once they're on your side their interests are in making your company successful. That's completely wrong! Most of them are sheep who are just following trends, and their interests may not even be self-aligned, much less aligned with you. He underscored Stan Reiss's point that you really have to choose your venture firm carefully, and hope a good one will take you on.
  • Failure is a part of the process, but you have to learn from it. Steve Jobs was a big loser, and his endeavors are at best hit-and-miss — but the hits (iPod, OS X) have learned from the misses (Newton, NeXTSTEP).
  • Related: to start a business, you've got to have a high tolerance for feeling like a moron all the time.
  • To succeed, you need to be both stubborn and flexible at once. Stubborn in that you need to pursue your goals even in the face of seemingly impossible adversity, and flexible in that the way you get to that goal may need to change on the fly.
  • You need to work like crazy and be obsessed.

Participants of the 2005 Summer Founders Program

The last talk of the day was by a large group of the participants in Paul Graham's Summer Founders Program. They mostly just took questions, but here's what I took away from their answers:
  • We had fun!
  • If you start a company, your relationships will suffer.
  • Large businesses often don't want to give small businesses the time of day. To have any chance you must be fantastic at communicating.
  • Make a demo.
  • Tell people your idea. The people in particular said that they were initially very secretive, but they found that most people won't run out and make a competing product the day after you tell them what you're working on, and they're much more likely to give you helpful pointers.
  • Make a demo.
  • Starting a company is like jumping off a cliff and trying to build an airplane on the way down.

So that was startup school. Overall, very informative and lots of fun. I can't say I'll do it again next year — I've already learned what I was hoping to — but I'd recommend it to anyone who's at all interested in making a company.


As I've mentioned before a few times, I attended Paul Graham's Startup School a couple weeks weeks ago. I took lots of notes with the hope of sharing them with you, and then, um, left them in Boston. Mike mailed them to me, though, so I've got them now and I can share them with you. I don't have time to write all of them up at the moment, so this is just part one.

By the way, MP3's of most of the presentations, and those presentations' slides, are available at the Startup School wiki. They're useful.

A general thought: there was a lot of advice given at this event, and a lot of it, I'm realizing now, seems just as relevant to computer science research as it does to starting your own company. Of course the stuff about the venture capital system and finding a way to sell your company for millions might need a little tweaking to apply to research, but I'm surprised by how much of it applies straight across to what I do on a day-to-day basis.

Mike and I biked the mile or so from his apartment to Harvard's Science Center. It was raining like crazy and generally really unpleasant to be outside, but gosh darn it, if you can't handle biking in bad weather you can't handle a startup!

Also the bike I was riding had its seat rusted in place a little too high for me, so biking was that much more of an adventure.


Langley Stein — Co-Founder, TripAdvisor

Stein gave us his six lessons from starting a startup. In his case the particular startup was, a travel-oriented search site, but these lessons apply generally:
  1. Follow your passion
  2. Do it for the right reasons (not money)
  3. Choose your partners carefully
  4. Less is more — raise as little money as you can
  5. Don't be afraid of change
  6. Keep an eye on the exit sign

I didn't realize it at the time, but this was a pretty decent outline for the rest of the day. All of these lessons got repeated throughout the day, so Stein was really giving us the big picture of how all the things we'd learn came together. This talk was where I first got the inklings of two themes: what venture capital is really all about, and how startup companies really make money.

Marc Hedlund — "Entrepreneur in Residence," O'Reilly Media

An "entrepreneur-in-residence" turns out to be someone who sits around thinking about startup companies while drawing a regular paycheck. Anyway: Marc's talk, "Startup Stories," was basically a litany of little parables drawn from the many experiences he's had with startup companies. There are too many of them for me to list them all, but here were a few:
  • — turns out this whole site was the work of one guy, who recently was paid a huge amount of money for it (some number of millions, I forget exactly how many). Turns out that a single talented programmer who has a good idea can still make big bucks.
  • flickr — you've probably heard of flickr as a photo-sharing service, but they actually started life trying to make computer games for girls. They quickly abandoned that idea and went on to make a chat room. The chat room didn't do so well either, but it had a photo-sharing feature that people liked, so the company just made that into their whole product. Even then, they changed around their profit model a few times before they settled on what they've got now. The moral: be flexible! Your first idea may need some refinement (or outright replacement) before it's good enough.
  • koders — Koders is a search engine for source code. Hedlund pointed out that they had a problem with their business model originally: they'd try to sell ads on their regular site, and then sell customized installations of their search engine to corporate clients. In principle either of these models is fine, but if you're a company you really need to focus on one or the other, since you've only got so many salespeople and so many programmers to make the ideal product for whatever userbase you target. Giving your people two unrelated sales tasks is a recipe for not getting either task done well.

Hedlund concluded with what I think is excellent advice: DON'T START A WEB 2.0 COMPANY! Or more generally, don't chase after the current hot buzzwords. Make your own new hot buzzwords instead, that's a better way to make sure you're on the cutting edge.

Qi Lu — VP of Engineering, Yahoo!

This was the first of two talks by people who might buy you if you're successful enough. It was really mostly about the various Yahoo! subsidiaries that the company bought when they were startups. The technology demos were cool, but since I'm not really interested in making a company that's primarily a web page company and then selling it to Yahoo!, this wasn't super-interesting to me. It is amazing what you can do with some well-placed Javascript and CSS, though.

Hutch Fishman — CFO of cMarket and Veveo

Hutch's talk was all about startup financing and I thought it was fantastic. I knew nothing about venture capital or anything like that, but this talk spelled it out for me pretty well. First of all, one thing you've got to accept is that it turns out that there are lots of companies out there that you could reasonably convince to give you a few million bucks in exchange for partial ownership of your company. Once you've accepted that, the next thing to know is that there's actually quite a bit of structure to these companies, and they give out money in "rounds" that correspond to the various stages your company might be in. Here they are:
  • "seed" funding — this is a very small amount of money, and your goal with this money is to get you set up with a strategy, an intial business plan, and maybe a demo.
  • First round — this round is for developing your intial product, and to buy you time and experience with which to develop your business plan, and to put together a team that's larger than just your initial group of founders.
  • Second round — this is for taking your product to market and filling out your team.
  • Third round — this money is for expanding: building a sales and marketing team, and taking out any significant risk that's left in your business.
  • Fourth/"mezzanine" round — this is for preparing for a "liquidity event" (i.e., getting bought) wherein you, your partners, and mostly all the people who gave you money in these five rounds, make a whole bunch of money.

Venture capital firms think in terms of these rounds, and if you can't accomplish the goal of the round with the money you're given, it'll become much harder to get funding for the next round, and so on. Also, funding at the early rounds tends to be much easier to get, but costs a whole lot more in terms of control and amount you've got to pay back. Your goal, as startup founders, should be to own somewhere between 5 and 10 percent of the company by the time it becomes liquid. That seemed shockingly low to me at first, but remember that five percent of $100 million is a whole lot more than 100% of nothing, so taking a bunch of VC money may well be very much in your interest even though when all's said and done they own more of your work than you do.

He pointed out that these days you really are going for getting bought rather than making an IPO, due mostly to the fact that corporate accounting laws are starting to make running your own company prohibitively risky and expensive. It's cyclical, he said, so at some point the pendulum will swing back and nobody in their right mind will want to sell their company anymore, but at the moment your sole job is to make a company that Google or Microsoft or somebody will want to buy from you.

He also stressed the importance of having enough money in the bank to operate for 12 to 18 months, if not for yourself then to present a solid financial picture to your potential investors and buyers. He also stressed that you should get professional accountants, and you should shell out the big bucks for the very best national firms — since you're trying to get bought, you really want your books to be in order. Deals can and do collapse all the time because the books weren't straight.

Paul Graham

Paul read us this speech about how people get ideas for startups. Paul is a great speaker, though I've got to say some of his fans can get annoying in their zealotry. My favorite part of this talk, and probably the part I'll be repeating over and over again as the situation arises, was his story of the new oven at his mother's house:
The average programmer seems to produce UI designs that are almost willfully bad. I was trying to use the stove at my mother's house a couple weeks ago. It was a new one, and instead of physical knobs it had buttons and an LED display. I tried pressing some buttons I thought would cause it to get hot, and you know what it said? "Err." Not even "Error." "Err." You can't just say "Err" to the user of a stove. You should design the UI so that errors are impossible. And the boneheads who designed this stove even had an example of such a UI to work from: the old one!

I think I've already recounted this story once or twice.

David Cavenaugh — Partner, Wilmer Cutler Pickering Hale and Dorr

This was about intellectual property. I actually happen to gave gotten a really well-done hour-long lecture once in undergrad all about intellectual property, so I knew all of this stuff, but if it's new to you you might want to check it out.

Okay, after that was lunch. The White Sox have just won the World Series as I type this, so I should probably take off and join the revelry for a bit. I'll give you the exciting conclusion of what happened after lunch later on.


Now a brief word in praise of my programming language implementation of choice. I decided three or four days ago that if I'm serious about the whole studying-language-interoperability thing, which it appears I am, I really ought to know something about actual language interoperability systems. So I picked for myself a modest little project: implement a standard CLR-style binary heap in C, where heap elements were abstract pointers and when you create a heap you've also got to pass in a less-than function with respect to which the heap will remain balanced. The heap algorithms are all dead simple, so I figured that even though there's a little rust on my C programming skills it wouldn't be too bad.

I did the code yesterday and was able to write make-heap, insert and extract-min functions pretty quickly. There was one maddening oddity, though: in my test harness, if I printed out each number as I inserted it, everything went along fine and I could insert as many numbers as I wanted to and then suck them all out, no problem. If I didn't print the numbers as I inserted them, things went all crazy and I'd end up with nonsense in my heap. Now, I haven't forgotten enough C to not realize that this was a classic memory problem, but the particular manifestation was driving me crazy: I couldn't watch what was happening at all because whenever I put a printf statement anywhere interesting the problem disappeared. I stepped through the algorithm in my head over and over again, and couldn't find anything wrong in any of the three algorithms I'd implemented even after extensive staring. So I gave up.

But it ate at me, and so today I came back to the problem. I didn't even care about interoperability anymore, I just wanted to figure out where this bug could be coming from. Long story short, after about three hours I discovered it: suffice it to say, despite their amazing visual similarity sizeof(void) and sizeof(void *) are not the same thing, and if you malloc the first and mean to malloc the second you may end up getting surprised.

That fixed, the library snapped into shape and after a rather-longer-than-it-should've-been digression on how to build dynamic libraries in OS X (gcc -dynamic -g -c yourfile.c && libtool -dynamic -o libyourfile.dylib yourfile.o, in case you're curious), I was ready to try bringing the library into DrScheme and calling it from Scheme code. Ten minutes later:
> (define h (heap 20 <))
> (insert h 10)
> (insert h 9)
> (insert h 8)
> (insert h 7)
> (extract-min h)
> (extract-min h)
> (extract-min h)
> (extract-min h)

This even though I'd only ever used the PLT foreign interface once before, and never with higher-order functions or C functions that made callbacks or any of that stuff. I was very impressed.


On Sunday, I had a meeting with Mike and Dave to discuss the future of Topsl. One very productive decision we all finally came to agree on at this meeting is that a web survey is inherently a two-phase computation: one phase that runs statically (i.e., before anyone takes the survey) with and one that runs dynamic (i.e. as someone is taking the survey). The static phase just takes the survey from something the user types in, which might have convenient abstractions or computations that are only meant to happen once or whatever, to a fully-elaborated program; that program then runs as the dynamic phase.

So as we were talking about that, Dave or Mike (I forget who) brought up a problem. If you want to perform a map over a list of, say, strings to turn them all into questions, that's no problem. On the other hand, if after you've done that the survey author contacts you and says they want to add the currently-logged-in user's name to one or all of those questions, now you're screwed: you don't have static access to variables bound at runtime, for the obvious reason that their values aren't known yet. That causes a big problem wherein a small tweak can force a large reorganization, something we all wanted to avoid. So we had the idea to have an opaque value representing a variable bound only dynamically by Topsl but available statically, so as long as you don't actually need to observe the value of the variable you can include it when you're generating Topsl code.

Today, in a totally different context — discussing my NEU talk of Monday — Eli pointed me towards the notion of "exotic functions" in higher-order abstract syntax and how one approach to eliminating them is to just give variables an opaque type as far as the metalanguage is concerned, which guarantees that you won't use their values for anything. The type system simply won't allow it. If you think about it, that's a typed version of the exact same solution we discovered, and that connection opens up the whole world of HOAS and fresh languages to Topsl.

So, so far, Topsl is related to fresh languages, multilanguage semantics, domain-specific languages, various approaches to static analysis, and staged computation, at least. Is there anything this goofy programming language isn't related to?


Lessons learned from my Northeastern talk:
  1. If your talk is about something abstract, make it concrete with an extended analogy that you thread through. I opened with some talk about Mars and Earth and how they want to interact but the Martians are afraid of Earth germs, and threaded that through the entire discussion. I thought it might seem to cutesy and the audience of staid and serious computer scientists wouldn't go for it, but I found that even staidest and seriousest people there were completely happy to think in terms of forcefield-encapsulated Martians travelling to Earth and so on. If anything I think it actually really helped the audience understand what was going on, based on the evidence that audience questions seemed to be phrased in "Earthlings versus Martians" terms much more often than "Scheme versus ML" terms even when my slides weren't talking about that analogy at all.

  2. If you follow point 1, make sure you understand that extended analogy perfectly! Like I said, I added in all my discussion of Earthlings and Martians last week; I've been working on this line of thinking for a year or so at least and so the Earth/Mars/forcefield way of looking at the problem is something I translate my thoughts into rather than a tool I use to think about the problem in the first place. For my audience, though, it was the other way around, and as a result I think they actually saw the analogy more clearly than I did myself. I got a question about whether you had to wrap Martians-in-forcefields in Earth forcefields to send them back to Mars (this being an analogy for sending a foreign value back to the language it comes from). I heard "When you're sending a value back to its host language, don't you need to make it completely opaque to that host language?" and answered "no"; but the analogy doesn't actually quite work that way and the answer really ought to have been "Yes, and forcefields cancel each other out." People really really didn't like that answer, and for a while I thought the audience was going to revolt and refuse to buy a central premise of my talk. Turns out they actually understood what I was saying better than I did and were correcting me.

  3. Practice practice practice, and find someone to listen to you do it. The more you practice the wording and delivery of your talk before you give it, the better it will be, and having someone listen to your talk can be invaluable to telling you where you're being confusing, where you're belaboring things, and where you're doing well (also how funny your jokes are). Don't decide exact phrasing you're going to use on the spot. Of course this advice is obvious and something I already knew, but every time I give a talk it amazes me how much just going through it a few times with a couple people makes it go from awful to good.

  4. Don't suddenly discover a few hours before your talk that you've got a non-negotiable deadline an hour after your talk finishes. I can't stress this one enough.

  5. It's much more fun to give a talk to a bunch of smart researchers whose interests are closely aligned with your own than it is to give a talk to a more general audience.

By the way, people have requested my slides, so I've put up a little companion page that has both the slides themselves and the reduction systems I talked about encoded as PLT Redex programs.


So I just got back from an incredibly hectic, amazingly productive three-day trip to Boston, at which I attended Paul Graham's Startup School, had a long meeting about the future of topsl, and gave a talk at Northeastern about the semantics of multilanguage programs. I will have more to say about all these things later, but for now I'd just like to give a big thanks to the folks at Northeastern and the Boston area for coming to my talk and being such a great audience. I've never given a talk before where everyone was so obviously attentive and understanding of what I was presenting, nor have I ever felt so nervous that halfway through the talk someone would raise their hand and destroy my entire talk. Great fun!


Hi all. Sorry about the lack of updates of late — I've pretty much been racing to get things done in time for my Boston trip and haven't had time to write a proper update. Good news is that I heard back from the Startup School folks and they have accepted my application, so I'll actually get to attend the school around which I planned my trip and I won't be flying out there just to spend a weekend in scenic Boston.

Actually, my weekend has quickly filled up, and I'm busy pretty much continuously the entire time I'm there from touchdown to takeoff, with my Northeastern talk, Startup School related stuff, visiting my sister, and my being an invited speaker at the esteemed Topsl Periodic Summit run by the biggest names in the hot area of PLT Scheme web-server-based psychology questionnaire language research (i.e. Mike and Dave). Who knew there was so much for me to do in Boston?


Okay, here's the ICFP conference report, part one, including our trip out and the Scheme Workshop.

Maurice, Robby and I set off last Thursday from O'Hare to Schiphol Airport in Amsterdam, and from there to Tallinn Airport in Tallinn, Estonia. Strangely enough, as we were leaving O'Hare we ran into Matthew Flatt and a small entourage; strange because they started out in Salt Lake City and were going to Tallinn via a totally different route, but they happened to pass through O'Hare right as we were leaving. As you'd expect, there were about a million people going to Amsterdam for a million different reasons, but the people going from Amsterdam to Tallinn were much more likely to be headed for ICFP. At Schipol we ran into Paul Hudak, Mitch Wand, Dan Friedman, Eli Barzilay, Danny Dubé, and Ronald Garcia, all of whom were headed to the conference.

We arrived, and after we checked in to our hotel Maurice, Scott and I wandered around the city a bit to find the conference venue and get our bearings of the city. Here's a picture from then:

The next day was Scheme Workshop day. Here are my notes about that:

Type Classes Without Types
Haskell's type classes are good for facilitating C++-template-style "generic programming" — how can we get the same in Scheme? Ron Garcia introduced the idea of "predicate classes" that are like typeclasses but dispatched dynamically based on a predicate. Unfortunately there's a modularity problem with these — it's impossible for two modules to introduce two predicate classes each, where in each module one predicate class is more specific and one is more general than a typeclass in the other module. But it seems like a nifty programming paradigm related to predicate dispatch, and I'd sort of like to try it out.

Eager comprehensions
Sebastian Egner explained the design of SRFI 42, eager comprehensions; eager comprehensions are a sort of analog to Haskell comprehenesions that construct the list immediately rather than lazily. This was a very comprehensive talk, and Sebastian really gave the impression that he'd thought his design through. He even gave several performance numbers for the reference implementation. This was the first of two talks about Scheme loops we'd see over the week.

Abstraction and Performance from Explicit Monadic Reflection
So you want to thread a value through a scheme program and thus you use a monad. But you don't want to use the normal monadic combinator implementation because they're too slow. On the other hand, you really don't want to write the code without monads because you also really care about code clarity. So you use macros to implement the monads, and a thing called "monadic reflection". Jeremy Sobel's talk was energetic and fun.

An Operational Semantics for R5RS Scheme
This was my talk. Exciting! I'm not sure whether people followed me, or fell asleep, or what, but I think that at least some people followed me and appreciated some of the details I was trying to bring across. Most excitingly I found out that Martin Gasbichler has used PLT Redex to encode a hygienic macro system.

After that was lunch, followed by:

Commander S — the Shell as a Browser
A program written on top of scsh that improves with two major new features: a plug-in architecture for implementing "views" of particular commands' outputs, and a novel approach to job control. Pretty neat-looking. In Q & A people asked about piping — you'd like to be able to incrementally construct pipes, which seems like something Commander S should be able to facilitate, and also it's not obvious what view to use on the output of a pipe. It turns out this is an area where the system hasn't been fully fleshed out yet.

Ubiquitous Mail
Manuel Serrano showed us all about synchronizing IMAP servers with a Scheme system called bimap. The most interesting part was when he showed that you can use bimap to write Scheme programs for general mail processing, to implement policies like whitelists or whatever.

Implementing a Bibliography Processor in Scheme
I had never really thought about BiBTeX before, but it turns out that like all things TeX-related it's creaky and barely works and needs to be replaced. The author presented MLBiBTeX, a replacement with special multilingual features originally written in C and rewritten in Scheme.

The Marriage of MrMathematica and MzScheme
Chongkai Zhu presented his interface between PLT Scheme and Mathematica. It's neat to see these languages connected together.

ACT Parameterization Framework
An simulator for internal combustion engines written in Scheme.

Javascript to Scheme compilation
The author presented a neat Javascript compiler that compiles to Bigloo scheme. The semantics of Scheme and Javascript are similar, so mapping Javascript onto Scheme class systems seems to work well, and once the code is in Scheme they're able to take advantage of the excellent Bigloo compiler to get fast code. Performance is better overall than any existing Javascript system, though that's not fair since their compiler isn't quite ECMAScript compliant. During Q & A, they explained that two features it doesn't support that will likely hurt its performance are string-based field/method access and modification of globals via the global object. Overall this seemed like a very cool piece of work.

Okay, there's more to write up but I figured I should at least get the Scheme Workshop report up. More to follow.