(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)

Tuesday, January 02, 2007
  Where were you on Saturday, November 9, 2002?

Had you dropped by MIT on November 9th, 2002, you might have seen a rather large collection of hackers, academics, tool vendors, and programming language enthusiasts gathering for the LL2 conference. It was rather like taking the current readership of Lambda the Ultimate and programming.reddit.com—no, I am wrong.

It was rather like taking the top couple of hundred of the people who write papers and blogs cited on Lambda the Ultimate and programming.reddit.com and gathering them in an auditorium together to talk about programming languages.

As the rather Spartan LL2 web page explains, the theme of the conference was:
How to get usable and useful programming tools into the hands of programmers, minimizing dogma, and maximizing flexibility.
Like any other conference, there were speakers. The speakers talked about the languages they had invented, and about how and why people ought to use them.

Had you been there, what would you have thought about the first speaker, Joe Armstrong, and his language, Erlang? Just another weird language for embedded telephone switches? Or an important language that is powering diverse applications such as a distributed, replicating database?

Joe spent a lot of time talking about unreliability. About how computers and programming languages are always designed as if everything always worked and that not working was the exception case, rather than the rule. And about how you can’t build systems out of dozens, hundreds, or thousands of pieces without assuming that everything is unreliable, all of the time.

And how there ought to be a programming language that builds that right into the system. Like Erlang. Would your eyes have glazed over? Or would you have thought about MapReduce and grid computing and would you have taken notes furiously?

Would you have thought that two different talks (one about persistence and another about asynchronous exceptions) were too much for an obscure language called Python? Would you have marked Python down as “One to Watch”?

And what would some random guy know about inventing “the next big programming language”? Oh, he was managing Microsoft’s Programming Languages Systems group. Well, there you go, one guy that Corporate America might care about. I wonder how many of his predictions about the next big programming language have come true? Good thing his talk is on line, we can check…

Paul Graham, author of “On Lisp: Advanced Techniques for Common Lisp,” was one of the LL2 organizers.
After lunch, some random guys talk about getting an un-typed language running on top of the Java Virtual Machine. I mean, really, who the hell would think that would ever become important?

Next up, the organizers had flown Yukihiro Matsumoto in to talk about Ruby. Yes, in 2002 the organizers wanted a bunch of Lisp-heads—the Q & A for absolutely every talk included at least one question about when macros would be added to the speaker’s language—to hear from someone who had designed a language known at the time as the most popular scripting language in Japan. Had you heard of Ruby in 2002? Did you care?

And what was with him constantly talking about making programming fun and comfortable? As if a programming language was a user interface for programmers. Everyone knows that programmers love idiosyncratic tools like Emacs, right? Who designs a language for usability? Who indeed.

There were other talks. They were all good, just as good. There was a spirited exchange of ideas over lunch in the lobby, again upstairs in the MIT researchers’ offices, and continuing late into the night at a nearby pub. It was a phenomenal gathering.

Were you there?

That isn’t important right now. If you were there, good for you, and I hope in the four years since you have taken some of those ideas, and a lot of that enthusiasm, and rolled it into what makes this industry great. The fact that anyone—even some guy from the other side of the world—can make something that other people like and use. Whether it’s free or for pay, whether it’s a language, a tool, an application, or a piece of hardware.

But even if you were there, that was then and this is now. 2007. Here’s the important question: Where is LL2 this year?

I asked “where is LL2 this year.” Actually, it may not be a Lightweight Languages conference. It might have nothing to do with programming languages. But somewhere in the world, somewhen in 2007, there is going to be a conference. Or a gathering. Maybe it’s this year’s Startup School. Maybe it’s a DemoCamp in your city.

Programming Ruby: the second edition is an indispensable reference, especially to the latest libraries.
Wherever, and whenever it is, you are going to see and hear things that are going to matter to you over the next five years.

They may not look like much in 2007, but they’re the seeds of the next Big Thing, the thing that will be big four or five years hence, in 2012.

Finding the conference

In 2002, LL2 didn’t look like much. You probably couldn’t find a job using any of the languages discussed at the conference. Unless you wanted to work on telephony. The lone representative of a mainstream company—Microsoft—wasn’t talking about their products, he was talking about things that would disrupt their products.

So if you’re looking for the right conference in 2007, there are two clues: the agenda isn’t going to include anything you can use to make money, and it isn’t going to feature anybody trying to make money off of you.

That’s right: no consultants, no white papers, no thinly veiled sales pitches. That knocks most Ruby conferences out. Maybe not all, but most. The right conference isn’t going to be about building CRUD applications on top of MySQL with AJAX goodness. That may not be out of date, but it’s so 2007, and we’re looking for 2012.

In 2002, the audience was highly interactive. Most of them were working on their own projects. They were practitioners, not tourists. They weren’t there to get a job, or goof off work. They were there to learn stuff for themselves and share what they knew with others.

In 2007, you should be looking for the same thing. For a conference that will be attended by people who are, as Joel would say, Smart and Get Things Done. Lacking a way to check the door before you show up, how do you find out?

Naturally, you find out by talking to other would-be attendees before going. LL2 had LL1’s active mailing list. In 2005, Startup School had a wiki. I don’t know what the right conference in 2007 will have, but I will bet on this: if there’s no community building in advance around a wiki, a list, or some other peer-to-peer communication, it isn’t the right conference.

The kind of conference where there is a one-way exchange between you and the organization—they tell you where to show up and you send them money—is not the right kind of conference. Look for the conferences that are built on top of active communities.

And when you find the community, pay attention to the action-to-talk ratio. I’m terrible at this, I always have to push myself to work and stop goofing off on my blog. But you know what’s worse? People who don’t have any work to begin with, it’s all just entertainment to them. They are tourists, and they are a liability to a conference.

Here’s why.

When tourists reach critical mass, the organizers start to cater to them. That means safe topics and safe speakers. Consultants. People with a good “patter” but not much to say that would disturb anyone.

Also, the tourists tend to ask the wrong questions, because they aren’t the market for anything new and interesting. Say a tourist raises her hand. She’s going to ask about something she imagines might concern a user, but you know what? She isn’t a user and she really has no idea how a user thinks, because she’s not the type to learn anything new until it’s already popular, and she doesn’t have any idea how such people think.
I think the root of your mistake is saying that macros don't scale to larger groups. The real truth is that macros don't scale to stupider groups.
—Paul Graham

So she asks something irrelevant. Like about language performance. Or bindings to Oracle. Or whether there is an Eclipse plug-in. Or how it will scale to larger programming teams.

But when a practitioner asks a question, it’s a smart question, it’s important. The speaker learns something important about their tool and the rest of the audience learns too. The next thing, someone asks a smarter question, and the energy builds.

If there are too many tourists, you can’t learn anything significant in the Q & A, and that’s a shame, because Q & A is where the action is.

So, my advice for finding the right conference is, avoid anything to do with either you or the presenters making money, find a conference built on top of an active community, and go the the conference with the highest density of practitioners.

And my question really ought to have been, will you be at this year’s important conference? and better still, will you be presenting?

Labels: ,


Comments on “Where were you on Saturday, November 9, 2002?:
"And my question really ought to have been, will you be at this year’s important conference? and better still, will you be presenting?"

Well, what do you think this year's important conference will be?
Cool blog!

It may be a little more 2008 than 2012, but I'd say any conference focused on Software Product Lines, Domain Specific Languages and/or Language Workbenches. I know this isn't exactly new stuff (Check out the Book: Generative Programming from 2000 - and the ideas of high levels of abstraction and lots of little languages have been about eve longer than Unix), but I still think there is a space here for some new thinking.

One conference in the UK is Code Generation 2007 in May in Cambridge, and I'd love to hear about any other such conferences (apart from the obvious biggies like OOPSLA which include this with a bunch of other stuff).


(Not affiliated, although may be presenting).
Thanks, Peter!

Here's Peter's follow-up:

Focusing on the Wrong Stuff
If you're interested in how LL2 happened, here's a piece of the story behind it.

During the summer of 2001, Greg Sullivan was my boss's boss at the MIT AI Lab. I was working on Jonathan Bachrach's Lisp dialect Goo, which (in retrospect) could be described as a combination of the best features of CLOS and SmallTalk.

One thing that we were wrestling with at the time was split between academic language design (where lots of cool things happened, but the user bases were miniscule) and the real world (which was trying to wring a 5% speed increase out of decades-old abstractions).

There was one bright light in this otherwise depressing situation: The open source scripting languages were hugely popular, but still willing to add closures and other cool features. (Personally, I was a bit of a broken record on the subject, though I wasn't the only one.)

Later that fall (once my 3 months in hacker's paradise were up), Greg Sullivan and Mike Salib decided to bridge the gap. They scheduled a conference room in the AI Lab, and started to invite speakers: Perl hackers, Python hackers, Lisp hackers, academics with cool ideas, and so on. And LL1 was declared open to anybody who heard about it.

That tiny conference room for LL1 was packed so tight that it smelled, and the discussions were heated. The Lisp people battled with the Perl and Python people, who in turn argued with each other. Half the insights came from the audience. And by the end of the day, the gap between theory and practice had gotten a tiny bit narrower.

Word got around, and Greg Sullivan's team hit another home run with the LL2 speaker list. The rest, as you've pointed out, was history.

So if you want to build LL2, you should probably start by building LL1. Here's how I'd do it:

1) Find a gap between theory and practice. Take, for example, concurrency: There's a dozen theoretical models that are better than what we're doing today, but almost nobody's using them.

2) Invite speakers from both sides of the gap: practical theoreticians, and hackers with large user bases and a willingness to innovate.

3) Aim your conference just one notch below an academic conference. You're not looking for new theories (though that's great), you're looking to bring people together.

4) Open the doors to anybody who shows up. This is where a lot of West Coast conferences blow it; they're by invitation only, and you don't get invited back if you rub some people the wrong way (which kind of defeats the point). Sure, if you open your conference to the public, it will probably burn out in a few years. But that's OK.

Another hugely successful conference along the same lines as LLn was SpamConf, also at MIT. They're pretty good at this sort of thing down at Cambridge Tool and Die.

<< Home
Reg Braithwaite

Recent Writing
Homoiconic Technical Writing / raganwald.posterous.com

What I‘ve Learned From Failure / Kestrels, Quirky Birds, and Hopeless Egocentricity

rewrite_rails / andand / unfold.rb / string_to_proc.rb / dsl_and_let.rb / comprehension.rb / lazy_lists.rb

IS-STRICTLY-EQUIVALENT-TO-A / Spaghetti-Western Coding / Golf is a good program spoiled / Programming conventions as signals / Not all functions should be object methods

The Not So Big Software Design / Writing programs for people to read / Why Why Functional Programming Matters Matters / But Y would I want to do a thing like this?

The single most important thing you must do to improve your programming career / The Naïve Approach to Hiring People / No Disrespect / Take control of your interview / Three tips for getting a job through a recruiter / My favourite interview question

Exception Handling in Software Development / What if powerful languages and idioms only work for small teams? / Bricks / Which theory fits the evidence? / Still failing, still learning / What I’ve learned from failure

The unary ampersand in Ruby / (1..100).inject(&:+) / The challenge of teaching yourself a programming language / The significance of the meta-circular interpreter / Block-Structured Javascript / Haskell, Ruby and Infinity / Closures and Higher-Order Functions

Why Apple is more expensive than Amazon / Why we are the biggest obstacles to our own growth / Is software the documentation of business process mistakes? / We have lost control of the apparatus / What I’ve Learned From Sales I, II, III

The Narcissism of Small Code Differences / Billy Martin’s Technique for Managing his Manager / Three stories about The Tao / Programming Language Stories / Why You Need a Degree to Work For BigCo

06/04 / 07/04 / 08/04 / 09/04 / 10/04 / 11/04 / 12/04 / 01/05 / 02/05 / 03/05 / 04/05 / 06/05 / 07/05 / 08/05 / 09/05 / 10/05 / 11/05 / 01/06 / 02/06 / 03/06 / 04/06 / 05/06 / 06/06 / 07/06 / 08/06 / 09/06 / 10/06 / 11/06 / 12/06 / 01/07 / 02/07 / 03/07 / 04/07 / 05/07 / 06/07 / 07/07 / 08/07 / 09/07 / 10/07 / 11/07 / 12/07 / 01/08 / 02/08 / 03/08 / 04/08 / 05/08 / 06/08 / 07/08 /