My Nikon D3 Report

I’ve been dithering back and forth about writing this, but Duncan’s recent posts about his new D700, as well as several camera discussions that I had at ApacheCon have pushed me over the edge.

Back in April I bought a new camera. When I got my first digital SLR back in 2005, I was just getting (back) into photography, and I had no idea if was going to really take to it or whether I would be any good. As a result, I went for the best cheapest camera that you could get at the time, which was Canon’s Digital Rebel XT. That camera served me well, but thanks to the digital format, I’ve been getting better at a pretty decent rate, and I was starting to run into areas where the camera was interfering with my ability to get the shots that I wanted. I knew that a new camera was not going to bump my work up a huge amount, but I was starting to get frustrated with it. It also wasn’t a smart idea for me to play with a Nikon D300 at one of the Seattle Flickr Meetups.

If I was going to upgrade cameras, I was also probably going to go full frame, because I like very shallow depth of field shots, and the possibilities for thin depth of field are better on full frame. This presented a problem. I only had one really good lens in my Canon set, the 17-55mm EF-S lens. The Canon EF-S lenses are unusable on the Canon full frame cameras, which basically meant that I would have to start over in terms of good lenses. Since I was going to have to start over, it only made sense to look at all the cameras in the marketplace.

When I did that, I was really impressed with the ergonomics of the Nikon cameras, so I started really looking at them much more seriously. Nikon has been been very aggressive about improving their cameras. This is in contrast to Canon, which had not dramatically improved the 20D/30D/40D series, had yet to announce the 5DMk2 and which has had very public problems with the top of the line 1DMk3. Back in April, there was only a single full frame Nikon camera, the D3. So after a bunch of deep breaths, that’s what I decided to buy.

Likes

So far, I am really happy with the camera. It is sensitive to light in a way that goes even beyond what my eyes normally see (unless I am really careful). As an example, at a recent Flickr get together, I took a shot of some chairs up against a red wall. When I looked at the picture on the back of the camera, there was a definite gradient in the lighting, but neither I nor several people that I asked saw the gradient without the benefit of the D3 picture.

Brews and Views at Crimson C

When I was in Prague back in July, I was able to take a number of night shots completely hand held. Ordinarily, I would have had to use a tripod for many of these, but these shots are more than passable for handheld.

Prague, The Czech Republic

As far as image quality goes, I am very happy. I am quite satisfied with the sharpness and color rendition of D3 images. The Nikon white balance does a pretty good job, better than the XT’s auto white balance, but of course, that’s not a very fair comparison at all. The biggest thing that I’ve run into is that the exposure really needs to be spot on, because the camera is so sensitive to light, that it is easy to blow out highlights. High ISO performance is really good, and when the noise starts to creep in, it looks much less objectionable than the noise that I’m used to on the Canon sensors. I shoot entirely in RAW, and I’ve brought back both badly over and underexposed shots in postproduction (I’m pushing myself to shoot fully manual as much as possible, and sometimes I forget to adjust). One drawback is that the 12MP RAW files take up around 12-13MB. The D3 eats CF cards very quickly, and I rarely shoot in one of the burst modes. This translates into demands for more hard disk space and bandwidth, and ultimately ends up pushing the computer harder, as Lightroom and Photoshop have to work harder to get all that data into memory and then do all the image processing operations. A Mac Pro is definitely in my future for these reasons, and I don’t even want to think about what this means for people shooting the Canon 5dMk2, 1DsMK3, or the Sony A900, at 20+MP resolutions.

The build quality is fantastic. Everything is solid and well crafted. Even though my hands probably on the smaller side, I find that the camera fits my hands well, and that the camera is well balanced, even with a 70-200 zoom lens mounted on the front. My hands fall naturally on the command dials and the autofocus point selector, whether I am using the main controls or the vertical controls on the grip. All the build quality means extra weight, which is taking a little getting used to, but it is good exercise.

It’s taken me a little while to get used to all the controls, but I much prefer Nikon’s system of using buttons in combination with dials as opposed to forcing me to take the camera from my eye in order to change things in a menu. I’m finding that I’m very quick to make adjustments, with one exception. I still haven’t quite gotten the hang of switching metering modes without taking the camera down from my eye. The control for this is up on the prism housing, and requires a decent amount of force to switch. In some low light situations, I tend to switch back and forth between evaluative (matrix) and spot metering modes, so this is an inconvenience. The alternative is for me to spend more time shooting in manual mode and learning to compensate for how the meter behaves, which is probably a good skill to be developing anyhow.

The autofocus system has performed really well. I’ve been able to accurately track fast moving action, and even in fully automatic mode, the camera finds the correct focus point a high percentage of the time. For portrait work, I still switch to a mode where I can select the focus point, because I just want the extra level of control. The only thing that I have noticed is that under some very low light situations, the camera can take a little while to lock. It’s still not entirely predictable to me when this is likely to happen. I love the huge viewfinder on the D3. I frequently had shots where I framed carefully in the camera, only to have extra stuff creep into the picture due to incomplete coverage in the viewfinder. I like this more than I expected to.

It seems to be conventional wisdom that Nikon’s TTL flash system is better than Canon’s, and based on my experience I’d have to agree. For the most part, I am an off camera lighting guy, but there are some situations, like parties and wedding receptions, where you just don’t have the time to make the adjustments for manual lighting. So far, I’ve found that the iTTL system works better than the Canon system. The D3’s high ISO performance adds to this by allowing you to shoot bounce flash pictures in rooms with much higher ceilings than previously possible.

There are lots of smaller things to like. The battery for the D3 lasts forever. I shot three ballet performances in one weekend, using a big image stabilized zoom in continuous focus mode, on a single battery charge. There was plenty of charge remaining. The other thing that I like is the dual Compact Flash card slots. I like the flexibility of using two smaller cards and overflowing from one slot to another. It means less worrying about managing cards in high volume shooting situations.

Dislikes

There’s one major thing that I have found that I dislike. On Canon’s you can switch between Aperture Priority and Manual modes, and have two different aperture settings. This makes it easy to have a set of manuals setting for strobes, and then flip to Aperture Priority for natural light. On the Nikon, whatever Aperture you set, will be the same for both modes. So if you are at f/8, 1/250th in Manual, but need to shoot at f/2.8 in Aperture Priority, when you switch from Manual to Aperture Priority, you’ll need to also switch the Aperture to f/2.8. And when you go back to manual, you need to go back to f/8. I can understand why it’s designed this way, but for the way that I use the camera, it’s something that I miss from the Canon.

Another dislike (well, I don’t mind it that much) is that the shutter snap on the D3 is pretty loud. Back in May I spent a day shooting with some wedding photographers. Almost all of them were shooting Canon 5D’s, and a few people exclaimed over how loud the shutter was. I guess that Kevlar shutter is going to last.

The D3/D700 start at ISO200. You can get down to an ISO 100 equivalent, but its an extension. If you are outside trying to knock down the Sun with strobes, ISO200 is one stop higher than you want to be. This is one area where the 5D/5Dmk2 have a nice advantage — you can get down to ISO50, 2 stops better. I guess you can always bring more watt/seconds, but it’s kind of a pain. Or you could use something like RadioPoppers to get your sync speed up several stops.

It’s annoying that Nikon didn’t put the dust shaker from the D700 into the D3. I’ve learned to clean the sensor myself, but it is annoying. On the other hand, even people with dust shakers need to have their cameras cleaned periodically, so maybe it’s just not that big a deal.

Some shots

This is an awesome camera - so if you see bad shots from me, you know it can’t possibly be the equipment.

JavaOne 2008

Fort Worden OSP Trash The Dress Shoot

Bainbridge Ballet Recital 2008

Bainbridge Ballet Recital 2008

EuroPython 2008
OSCON 2008
PyCon UK 2008
ApacheCon US 2008

Olio - a web 2.0 benchmark?

So there’s a new project in the Apache Incubator called Olio. It’s a “toolkit that can be used to evaluate the suitability, functionality and performance of web technologies”. There are already implementations in Java, PHP, and Ruby on Rails. Here are some additional versions that I would like to see:

  • Django (Python)
  • Turbogears (Python)
  • Lift (Scala)
  • Seaside (Smalltalk)
  • Erlang
  • Clojure
  • Haskell
  • Common Lisp
  • ASP.NET

If I’ve left out your favorite language, framework, feel free to add it in the comments. Or better yet, show up to the project with an implementation. Wide Finder this ain’t, but the results could still be pretty interesting.

My personal story on the Sun Storage 7000 series

Today Sun is announcing a new line of storage appliances. I haven’t been involved with this product at all, but I do have a personal angle on them. Shortly after I joined Sun this year, I took a trip to California to meet various people in person. Amongst the people that I met up with were Bryan Cantrill, Mike Shapiro, and Adam Leventhal, the inventors of DTrace. I was a graduate student at Brown when Bryan and Mike were undergraduates. I was mostly interested in talking to them about DTrace, because DTrace is an important part of your toolkit if you are building web applications using dynamic (and other languages).

During a break, Mike took me aside and asked if anybody had shown me what they were working on. I said that they hadn’t, so he took me back into a server room and showed me a prototype of the Sun Storage 7000 product. There’s lots to write about regarding this project, and there will be a veritable storm of blog posts about it today. The two things that stood out to me when I saw the prototype were:

a) the innovative use of flash memory as part of the storage hierarchy, and the work that has been done to ZFS in order to manage flash in an intelligent way. If you are interested in the science/engeineering behind this, you should look at Adam Leventhal’s article in the first issue of the revamped CACM on this topic. The impact on both cost and performance is very impressive.

b) the AJAX based UI that the Fishworks team has created for interacting with monitoring tools like DTrace.

You can read Mike and Bryan’s blogs for the full story of how the products came to be, and you can go to the launch and product pages for the details the specific product offerings.

Well done Mike, Bryan, and team!

ApacheCon US 2008

ApacheCon US has come and gone for 2008, and here’s the roundup.

Talks

I’ve known Simon Phipps since we worked together at IBM in the late 1990’s. He’s always been great at finding and articulating trends in the computer industry, and I had read his post on the Adoption Led market. I expected him to talk about just that one issue, but it turned out that he had five points to make. Besides the adoption led characterization of open source, he talked about substitutability as preferable to interoperability, with a corollary of standards body reform. He also made the point that effective marketing messages for open source will be either first or second derivatives of freedom. I’m still doing some pondering on some of these.

Kevin Crowston from Syracuse University has been coming to ApacheCons for five years now, and I was very interested in his talk summarizing some of the things that he and his students have learned. I had a very extended in person conversation with Kevin, and it’s hard for me to remember what content came from where. Kevin and his students have really become a part of the ApacheCon community - I always look forward to talking to them and seeing what they are finding interesting. As I’ve written in other posts, the social/cultural/organizational lessons of open source development will likely turn out to be more enduring than much of the actual software.

ApacheCon US 2008

It’s fashionable for some company to be controlling the ASF. Every year it is a different company. Over the years this honor has been held by IBM, Google, and Joost. This year, I would say that the honor belongs to Yahoo. There was an entire track dedicated to Hadoop, which originated with Yahoo. Many of the Hadoop sessions were jam packed, so Hadoop contributed substantially to the attendance at ApacheCon this year. I predict that nextt year’s Hadoop Camp will be double or even triple the size of this years’ track. The talk that I got the most out of was Dhruba Borthakur’s description of the way that they use Hadoop at Facebook.

The conference

I think that I’ve only missed a single US ApacheCon (I’ve never made it to an EU ApacheCon) since 2000. This year, there were some changes to the conference structure. In addition to the Hadoop Camp track, there was also a track for OFBiz. I didn’t attend any of the talks, but from talking to people, it seems that the OFBiz track also contributed heavily to the attendance. ApacheCon’s program is determined pretty much by who submits and that can lead to a very haphazard program. I think that the success of two well planned coherent tracks is something that should influence the direction of the conference. The conference needs whole or half day tracks which are technically coherent and which accommodate the skill levels of the various Apache user bases.

ApacheCon US 2008

Another experiment was the decision to run a BarCamp during the second day of the Hackathon. I think that this was very successful. We had a very good discussion on git versus subversion, a topic that is generating a lot of interested within the foundation. There was a session on dynamic languages, which wasn’t very successful because the organizer ran through a long slide deck rather than engaging the participants. I ran a session on digital photography, and the people who participated seemed to get some value out of it. I would love to see a BarCamp, Open Space, or similar track be included in the main conference, rather than being limited to just the Hackathon.

ApacheCon US 2008

The lightning talk session is always well attended. The ApacheCon lightning talks are decidedly biased towards the light hearted (like Aaron Farr’s hilarious portrayal of Apache world domination), in contrast to the PyCon lightning talks, which tend to be more serious. I think that the Python community is gettting more bang for the buck when it comes to the lightning talks. There’s much more dissemination of information that might be hard to get accepted as a conference talk, either because it’s a tidbit, or it’s very new work, for example. The demand is so great that there are multiple days of lightning talks - a sign that something is working really well.

There were two other unusual features of ApacheCon this year. The first was that it took place during this year’s historic U.S. election. I’ve never watched election returns much, and never with a group. The whole experience of sitting in the Sheraton bar/lobby and watching the events on a huge TV screen is one of those memories of a lifetime.

ApacheCon US 2008

The other unusual happening took place at the end of the lightning talks, where a few of the sponsors got together and organized a “death of proprietary software parade”, complete with brass band and a police motorcycle escort as we marched through a few New Orleans streets. The parade’s final destination was a local club for the ensuing “celebration”.

I really love ApacheCon, but it was impossible for me to ignore the difference between this year’s ApacheCon and PyCon. At over 1000 people, PyCon was easily twice the size of ApacheCon, and the level of energy just seemed higher at PyCon. I also continue to be impressed by the PyCon sprints, which are just blowing things off the map in terms of attendance, productivity, and ability to engage completely new people in the various Python projects. From talking to a number of people on the ASF ConCom, I know that some changes are in the works, and I am hopeful that next year’s ApacheCon will be revitalized and energized.

Photography

I talked with people more about photography this time than any other conference that I’ve been too. Several people told me that my previous photo coverage had made it possible for them to “attend” ApacheCon even though they didn’t physically attend. It’s gratifying to feel that the picture making is doing some good beyond indulging my need for an artistic release. Beyond the aforementioned BarCamp, I had a number of gear related discussions with people, and on the basis of those, you’ll probably be seeing some gear postings from me in the next little while.

ApacheCon US 2008

Shane Curcuru, the conference lead made it a point to give me a spare key to very nice suite that the hotel gave him. It was up on the 48th floor, and you could get a pretty decent view of New Orleans, which made it pretty hard to turn that offer down. I took two trips up there and shot a bunch of frames to turn into panoramas. That was a relatively new experience, and I didn’t pack a tripod, so the result is somewhat less than optimal, but it was fun nonetheless.

As usual there is a set of photos for the conference on Flickr.

Travel

ApacheCon US 2008

I had a pretty smooth travel experience - the “worst” part was missing a ferry because of a delayed leg. This was my first time to New Orleans, so I’m not sure how to judge it. All the meals that I had were fantastic, right down the the Jambalaya that I got from one of the airport restaurants. I’ve been messing around with BrightKite on my last few trips, wondering if it would really amount to much. Shortly after touching down in Denver on the way home, I got a phone call, and several directed Tweets. That seems like some thing useful, so I’m probably going to keep playing with it. I don’t have any more trips scheduled for the rest of 2008, so that experiment will have to pick up sometime next year.

Next year ApacheCon is in Oakland, where we’ll be celebrating the 10th birthday of the ASF. That’s one birthday party that I am really looking forward to.

Book Review: Practical Django Projects

James Bennett, the release manager for Django has written a book called Practical Django Projects. At 237 pages, this book is even shorter than Learning Website Development with Django. Miraculously, Bennett manages to pack even more content into his book. He uses three different projects to illustrate the basic concepts of using Django. Early on in the book you are introduced to Django’s generic views mechanism, which makes it very easy to do the kinds of displays that are common in many web applications. Along with generic views, there’s a good treatment of how to keep functionality separated and reusable by good design of URLs. There’s also a much stronger treatment of the templating aspects of Django. He covers template inheritance, but also covers the creation of custom template tags.

Like “Learning Website Development with Django”, “Practical Django Projects” was completed before Django 1.0 shipped, so there are going to be some differences between what is described in the book and what you’ll encounter with Django 1.0. I like both books, and I’m probably biased by the order in which I read them. Either book would be fine for someone learning Django from scratch, but I think that “Practical Django Projects” is the book that I would turn to first when I couldn’t recall how to do something. In addition to the extra topics covered (and that’s not entirely fair because “Learning Website Development with Django” also has a few areas that it covers better), there’s more of an application building focus in Bennett’s book. That emphasis appeals to me, and Bennett has lots of application architecture hints sprinkled throughout the book.

Django is a great piece of work and deserves very serious consideration by people looking to build web applications. I’m glad to see that publishers are getting Django books out into the world.

ApacheCon US is next week

Next week I’ll be at ApacheCon US in New Orleans. I’m not officially on the program, but I am planning to run a dynamic languages session during the BarCamp on Tuesday.

Retry: Dynamic Languages for Desktop Apps

Apparently, I wasn’t very clear in my previous post, because almost all of the commenters seem to think that I was talking about using a dynamic language to script parts of a desktop application. That’s not at all what I mean. I think that it will be a success point when a dynamic language (I don’t care which one) is used to write a substantial portion of a desktop application that enjoys reasonably widespread success/distribution. I used Lightroom as my example because that’s the kind of application that is the target. While 63% of the code written by the Lightroom team is in Lua, only around 40% of all the code in the application is written in Lua. I am looking for a much higher percentage. I don’t have quibble with Lightroom’s percentages, because it’s very sensible for Adobe to reuse their C/C++ code for RAW processing etc, and there’s no commercial justification for even trying to rewrite that code in Lua.

We already know that dynamic language interpreters can be embedded in applications. That’s been happening for years and years. But since we are starting to see progress in the performance of dynamic language runtimes, it should be possible to write really good desktop applications using them.

Lua in Lightroom

One of the points that I discussed in my PyConUK keynote was the role (or lack thereof) of dynamic languages in desktop software development. I know that some people believe that desktop software is dead, but I am not one of them. I think that the nature of desktop software is changing, but that it is still relevant. In my discussion of dynamic languages and desktop software, I used the example of Adobe’s Lightroom, as the best example of commercial software that is written in a dynamic language. Lightroom is written in Lua, and according to this presentation by Troy Gaul, 63% of the code written by the Lightroom team is Lua (there is a bunch of C code for the low level image processing code, which is shared with Adobe Camera Raw). A number of people at PyConUK had no idea of the role of Lua in Lightroom, which is unsurprising. The only reason that I knew was that I was following Lightroom as a photography nut, and the information flew by on some boards. Troy’s presentation is pretty illuminating, so if you are interested in dynamic languages in desktop applications, you should watch the whole thing.

The First Annual JVM Language Summit

You know that a conference is good when you go home with a list of stuff that you never heard of but now need to go follow up on. The JVM Language Summit was exceptional in this regard. Sun provided a location and a few of the speakers, but most of the speakers at the Summit were not Sun employees, although there were a few Sun alumni amongst the speaker ranks. The topics that were discusssed went all the way from type theory (including the usual greekified type proofs), typical language design stuff, VM design, all the way down to discussions of how high allocation rates can cause hot data to get flushed out of caches on the bare metal. Slides for all the talks are available on the wiki for the conference, and some of the talks will have video at either InfoQ or YouTube. Here are some of my favorites from the three days.

Clojure

I’d been aware of Clojure prior to the summit and had looked at the page on Clojure’s use of persistent data structures, so I thought that I had some idea of what was interesting about Clojure. I was wrong. Rich Hickey’s 30 minute presentation on Clojure had a really large amount of information per unit time. By the end of the time I was really interested in Clojure, and I was able to find out a bit more about it by going to an open space session and by being at the same table as Rich during dinner one night. As and old Lisp guy, my usual reaction to Lisps on the JVM or CLR is why? They don’t typically fit in that well with the host VM, and there are great implementations of Common Lisp that can compile to very efficient machine code. I was looking forward to Arc, but that has turned out to be very disappointing. Clojure has taken a very practical approach to the Lisp parts of the language. It fits in very nicely with the JVM, is able to call Java code easily and has the potential to achieve very good performance on the JVM. Also, Rich has made a number of design decisions which improve the syntax (he showed a short program in both Python and Clojure, and they occupy the same amount of vertical space and have roughly the same visual density) of Clojure. He’s also generalized many operations that would have worked on lists to work on sequences, which really means any Java sequence type. Like many Lisps, you can supply data type hints, and the compiler will use those to make the program more efficient. There is a nice library of collection operations, which look very comparable (or better) than Python or Ruby’s facilities for collection types. There are some other really interesting data structures in the libraries, like bit partitioned hash tries and zippers.

Beyond the Lispish stuff in Clojure, there are a several interesting features in Clojure related to the problem of concurrency. In Clojure things are immutable by default, which is a huge benefit - a benefit shared by functional languages, and quasi functional languages like Erlang. Beyond that, Clojure supports persistent data structures as a way of managing state in a concurrency friendly manner. The idea is that “updating” a persistent data structure yields both the version before and after the update. This means that updates don’t impede readers of the old version, and are not blocked by readers of the old version.

Lastly, Clojure provides an interesting mechanism for utilizing Software Transactional Memory. Normally STM systems make all accesses to memory transactional. This makes the STM a bottleneck, and makes it much more likely that the performance of the STM system will be the limiting factor in a concurrent system. Clojure requires you to make uses of the STM explicit via its Ref structure. This yields a potentially much more controlled usage of the STM, which could help preventing the STM from being a bottleneck.

My original impression of Clojure was that it was still in the very early stages, but it seems to be bit further along that that. I was surprised by the size of the community, and by other parts of the ecosystem, like the tool support. There are several Emacs modes, integration with SLIME, and even a Netbeans plugin for Clojure.

I will definitely be giving Clojure a closer look, and I am not alone. There was a lot of energy in the room during and after Rich’s talk, and there was a burst of Twitter traffic during the talk. It’s pretty interesting to see the number of language geeks on Twitter.

Davinci Machine

If you’ve been following John Rose’s blog and Charlie Nutter’s recent writings on invokedynamic, you wouldn’t be very surprised by the content of John’s presentation on the DaVinci Machine Project. This is a highly important piece of work for non-Java languages on the JVM, so it was good to hear John tell a more complete version of what he’s been up to. It was also my chance to meet John in person. We somehow missed each other at JavaOne, so it was good to put a face to the name, and have some in person contact. John and Brian Goetz did a great job of organizing the summit, and John was always trying to find out what kind of features would be useful to JVM implementors. JSR-292 can’t happen soon enough.

Fortress

David Chase talked about the work that folks at Sun labs have been doing on Fortress. I never really paid much attention to Fortress, since they are really aiming at the scientific, high performance computing space, and that’s kind of outside of my interests. The Fortress guys are doing some interesting explorations as far as concurrency is concerned. In fact, David referred to Fortress as “infested with parallelism”. My todo item from the Fortress talk has to do with the work-stealing model that they have for concurrency. Apparentl this work is based on a data structure known as an ABP queue, so I’ll be tracking down the paper on that one.

JRuby

I’ve heard Charlie Nutter talk about JRuby several times, and have talked with him a little about JRuby. Even so, his talk on JRuby was really interesting, because he was able to go full out for an hour to a very sophisticated audience. I know from talking to some of the Jython guys, that there were a few aha moments for them, even though they’ve been to the same talks that I’ve been to.

Dynalang MOP

Attila Szegedi described his proposal for a MOP for dynamic languages. Once you start hosting a bunch of languages on the JVM (or any VM), then people start to ask if they can call code written in language A (say Clojure) from language B (say Python). The tough part is that the code in language A may have compiled to Java bytecodes in a way that doesn’t really resemble Java code, and you can end up in a situation where B can call A but does it by grabbing things which are really artifacts of A’s implementation. Of course, A’s implementors will continue to improve A, and in the process of doing so, might change the details. You can see what the problem is going to be. Attilla’s MOP would go a long way towards helping here. I hope that people will give it a serious look.

Gradual Typing

Jython committer Jim Baker has been after me about the work that Jeremy Siek (UC Boulder) has been doing on adding types to Python. His system is called gradual typing and allows a programmer to selectively add type annotations to a program. It’s a cool idea in principle, and I hope that it will end up being cool when it finally gets implemented all the way. I have to admit that the first time that I saw an annotated program, I had a violent reaction. There were a ton of angle brackets due to the type annotations. Jeremy and his students are working on ways the reduced the amount of notation that is needed. I hope that they’ll be successful — in Python at least, it’s going to be key to whether people will adopt it or not.

Fundamentalist FP

I’ve been an admirer of Erik Meijer’s work for some time, so I was glad to be able to hear him speak in person. There was another talk on LINQ, so Erik didn’t talk about that. Instead he talked about what he called “Fundamentalist Functional Programming”, which is really just the functional programming that the old school functional programming people have always talked about. I think that Erik is concerned about the amount of lifting of functional programming ideas and idioms, without a full understanding of the essence of functional programming. His presentation style is very entertaining. The major thrust of his argument was that for the past 50 years of computing, we have been abstracting, but abstracting over the wrong things. He asserted that the thing that we really need to do is to abstract over evaluation order. Given the coming many/multicore world, this is understandable, but don’t think that I agree that all the other lessons that we’ve learned about abstraction are invalid. He provided the simplest explanation of monads that I have ever heard or read, as well as showing how to handle things like object creation and process creation monadically. In the end, though, his talk reduced to the essentials of lazy pure functional programming.

Bytecodes for fast JVM’s

Cliff Click asked that JVM language implementors send him an implementation of a particular program written in their language. Cliff then ran those programs (in their respective languages) on Hotspot and on the Azul JVM. His talk was a report of his findings as to what was keeping various languages from getting the best results on the JVM. He said that he wasn’t trying to compare the merits of one language versus another, but more to give the implementors insight into what was up with their code. I found this talk to be tremendously interesting because Cliff really knows the guts of HotSpot and because he was able to be very specific about what was causing problems for the various languages.

Parrot

I’ve known Allison Randal for several years now, mostly via her organizing of the FLOSSFoundations meetings that happen every year at OSCON. In all that time, we’ve never really sat down and talked about her work on Parrot, and it’s been several years since I heard a talk on Parrot. I give John and Brian a lot of credit for inviting Allison to come and talk about Parrot. The architecture of Parrot is very unlike either the JVM or the CLR. They started with very different assumptions and goals, which unsurprisingly lead to a different design. As far as I can tell, Parrot is looking reasonable on the performance front, will be able to use the C libraries of Python, Ruby, PHP, etc, without much hassle, and will have a good story for interoperability between hosted languages. Control flow is modeled using continuations which means that continuations are really cheap to create. Allison also talked about what a different method of doing call site caching - Parrot does the caching in the Parrot class object, not in little caches strewn all over the call sites. This makes it easy to invalidations the cache when the class hierarchy changes, for example. I’m still trying to digest all of what I heard, as well as the conversation that several of us had with Allison after her talk.

The Parrot team has been lying low and working away on Parrot, and they are definitely making progress. Allison showed some very preliminary benchmarks of the incomplete Python, Ruby, and PHP implementations on top of Parrot versus the C based versions. She told me afterwards that the project has reached the point where they are working to time based milestones, and that they are hoping to do a 1.0 release early in 2009. Chalk up another to-do.

Random Thoughts

There aren’t any pictures to go with this report because I was not motivated to take any. There were several people snapping away quite frequently during the conference, and I didn’t want to add the slaps from the D3 to the cacophany and the flash light show.

It seems clear to me that many folks share some of the same problems, and I hope that on result of the summit will be that people will start to work together when it makes sense. I know that the Jython and JRuby folks are working in that direction, and it seems likely to me that there will be some collaboration around the dynalang MOP as well. There was a lot of good energy in the room: people were very respectful and curious about other people’s work.

I think that the only regret that I had was that this was the first annual JVM Language Summit. Imagine where we’d be if this had been the fifth…

Update: finished the sentences about persistent data structures in Clojure

Book Review: Learning Website Development with Django

The folks at Packt Publishing sent me a copy of Learning Website Development with Django by Ayman Hourieh. It’s a fairly thin book, weighing in at just 243 pages, but it it is a very good introduction to Django. Knowledge of Python is assumed, so if you need that information, you’ll need another book. Hourieh uses a running example, a social bookmarking application, throughout the book. This means that he is adding features to the application in each chapter, which is a style that I like because it shows how to use Django to build up a decently featured application piece by piece. There is lots of code, which I found easy to read, except for some places where the bold facing of new code was somehow omitted.

The only problem with the book was that it was finished before Django went 1.0, so there are undoubtedly some places where things are not quite in sync with Django 1.0. Hourieh did make an effort to deal with some of the largest 1.0 changes, like newforms, but omitted other like Unicode support. This is inevitable when the book and software are not in sync, but since Django only went 1.0 a few weeks ago, the only documentation that is completely up to date is the official Django documentation itself.

If you know Python and for some reason have been holding off on learning Django, this is a good book to help you get started. There is also an e-book version available via Packt’s website.