Apr 21 2007
MinneBar Conference Report
My stream-of-consciousness memoir on MinneBar.
Had a blast at MinneBar. The space was a bit small and I think turnout was much higher than anyone anticipated, and it way hot (in the thermal sense), but it succeeded with flying colors at creating “something exciting by being in close proximity to lots of smart people”. Got a chance to meet a guy from the OCaml mailing list, and generaly hung out with a lot of smart people.
The session I lead on executable documentation went pretty well…eventually. When I first showed up, the outlet didn’t work and the projector was sitting too low, but my wonderful wife came up with the solution of stacking chairs and the MinneBar organizer (Ben Edwards) managed to find an outlet that worked. Once we were through with that, I plowed ahead, and there was a really good conversation that ensued.
I’m discovering that it’s kind of hard to illustrate a good example of a Fit document outside the context of some kid of project, though — for future presentations on the topic, I will probably have a mock project and a more complex example. I was hoping to build that interactively during the session, but I simply ran out of time. All in all, though, it seemed like people were really warming to the idea of using story tests to provide a common language between customers and developers. It at least seemed to be a bug that got into people’s ear.
The presentation on Agile Development and Functional Languages totally blew me away. The plan going in was to talk to the half-dozen functional language wonks who showed up about how to do test-driven development and other Agile-esque coding techniques in functional languages, and/or to talk to the Agile folks who showed up about why object-oriented languages seem to be an implicit assumption in Agile thought. The low attendence was also a given assumption by the organizers, I think: they put me in one of the smaller spaces for that presentation. That plan was thrown out in a hurry when I walked into a very, very full space — we had people outside the room all the way to the stairwell trying to get into the conversation. So much for being the only person who cared about functional languages in MN.
The conversation that ensued was really good. There were about five or six people who really became the ad hoc panel, and we talked about advantages of functional languages, and limitations to the adoption. During the talk about the advantages of concurrency with functional languages (see Brian’s post on the matter for more on that), this guy who had his head in his computer most of the time piped up to make an interesting observation: that Rails basically addresses the problem by forcing a single-threaded model, and leaving any “multithreading” aspect out of the user space. I thought that was pretty insightful, and I said something which I can’t really recall, and we moved on — it was until later that I realized it was celebrity guest David Heinemeier Hansson, the creator of Rails! I retroactively got a bit fanboyish when I found that out: I’m only now starting to recover.
I ended up having to cut out at about 3 PM. After the presentations, the general lack of food, and the trouble I’ve been having sleep for the past week, I was just kind of done. It’s kinda too bad: I was having some fun, but I just couldn’t do it.
Please feel free to comment on this post if you’d like to continue the conversation from MinneBar, or if you’ve got any feedback for me — I’d like to hear any kind of constructive criticism about the presentation, or any ideas that it got you rolling on.
(A review of functional programming and agile development conversation.)
Popularity: 4% [?]
Get some sleep :)
I enjoyed the snippet of your presentation which I stuck around for, and really, the concept of pure functions as atoms of provable functionality (duh) has been stuck in my head since then.
I’m still chewing on it, which I think means you did enough to get your merit badge in functional evangelism to the unwashed.
Please join the unwashed masses interested in functional programming at lambda@ruby.mn
Thanks again for the presentation.
Ruby on Rails model of concurrency is also known as the “Unix Version 6″ model of cocurrency- if you want more concurrency, just run more programs, or more copies of the same program. With Unix version 6, the model was seperate programs in seperate address spaces communicating via the operating system (specifically, the file system). With the Web, it’s seperate programs in seperate address spaces and possibly on seperate machines communicating via the database.
This is also known as the mainframe model- dumb terminals connecting to a central server where all storage and most computation occurs. All that’s happened is that we’ve change the names (to protect the guilty) and slapped a layer of graphical gloss over the whole thing to obscure the outlines. That, and a steaming pile of hype.
Having been around this merry-go-round at least once already, let me tell you what comes next. People will discover, to their shock and horror, that centralized servers are single points of failure. They won’t go down often, but when they do go down, the outages will be system-wide. Some backhoe will cut the trunk lines to Google, and suddenly no one will be able to read their email, check their calendars, or (comming soon) use their office suite. Google has an extraordinary reliability and huge amount of redundency- so did the mainframes.
The other thing people will realize is that there is more storage, and more processing power, on the edges of the network than there is in the center. This has been true for at least 25 years (since the introduction of the PC), and arguably longer. The resources at the center are more efficiently used, it’s true. Which raises the question of wether these resources can be utilized, even if less efficiently? Can we push processing, or storage, out to the client?
Back in the eighties, this was called the “fat client” solution.
In either case, the problem of parallel execution remains. The CPU companies have, if effect, given up on single threaded performance. There will be clock speed improvements, but (unless and until we solve the power leakage problem) they’re be fewer and farther between than we’ve come to expect. Moores law never gaurenteed that clock speeds would double every two years. Just that the number of transistors on a chip would double.
Which means that if you want to improve the response time of a single process- of a single transaction, in web terms- you have to go multithreaded.
You also run into a problem when you have more processors than programs to run on them. If your web site is getting 100 hits at a time, and has 100 processors, this works- each processor deals with a single, unique transaction. But if you have 200 processors and 100 hits, you have two choices- either use multiple processors per transaction, or simply not use half your processing power. Since the number of threads are, more or less, doubling every generation, by ignoring half you threads it means your web site runs no faster on this generation of hardware than on last generation’s hardware. And what happens next generation, when you’re handed 400 processors?
You can ignore this, for the moment. Even single threaded, processors today provide a huge amount of computing power- esepcially compared to the bandwidth limitations of memory, disk, and internet access speeds. And, if your programming language is slow enough to start with, you can provide huge leaps in performance simply by fixing your language. But, sooner or later, multithreaded is going to happen.
[...] Functional Languages and Agile Development - Robert Fischer [...]
I got into this a bit during the session (when DHH chimed in) — the thing that’s interesting abour Rails is that it has one, explicit niche: website handling. And in the case of website, the level of actual computation needed per transaction is pretty minimal in comparison to network access speeds. Even the cost of spawning an entirely new processes is pretty minimal. So the performance of Ruby on Rails isn’t a critical issue — this point was actually made by DHH during his “couch talk”. And this continues to be true considering the growth of AJAX and its one-request-one-piece-of-work approach.
Now, this is a niche case. For “heavy lifting” applications (like most business batch applications, and even moderately un-thin clients), the performance limitations are in the way data is managed and handled. That’s where multithreaded applications are huge, and getting multithreaded capability for cheap is a major win.
[...] when I mentioned David Heinemeier Hansson talking about Rails concurrency in my MinneBar [...]