Category Archives: programming languages

Python at CommunityOne

CommunityOne is a free and open developer conference that is run by Sun on the day before JavaOne. This year, there will a space at CommunityOne dedicated to the Python community, complete with whiteboards and wifi. If you are in the Bay Area for JavaOne, or in the Bay Area, or just plain interested in Python, please register for CommunityOne — space is limited.

Registering for CommunityOne gets you a bag of swag, a free lunch the day of CommunityOne, access to all the CommunityOne events and sessions, and a free pass for Day 1 of JavaOne. When you register, put “Python/Jython” in for the referral code.

I will be on a panel on community models during the general session from 9:30AM – 10:45AM, and Frank Wierzbicki and I will be doing a Python/Jython panel. In addition to the usual developer stuff, there will also be a two day Startup Camp, and the folks from RedMonk will be back to do their day long unconference thing.

PyCon 2008

It’s been 2 years since I’ve been to PyCon, and things have definitely changed. The last time I went to PyCon (2006 in Dallas), it was still a relatively small conference (3-400), if I remember what I was told), with a familiar feel, especially if you had attended in previous years, or were a part of the Python community. This year, there were over 1000 people (double the 500 people that came in 2007, apparently). I spent a sizable portion of the conference days feeling like “I miss a year, and you guys go and get 1000 people”. It’s a great thing that so many people are interested in Python.

PyCon 2008: Day 1

The talks

I went to a reasonable number of talks – talk quality at PyCon has historically been pretty good, and I was a little out of date on the latest on things like Django and Turbogears. The best talk that I went to was Raymond Hettinger’s talk “Core Python Containers — Under the Hood”. This was a great talk for several reasons: Raymond was a good and entertaining speaker. There was significant technical meat – explanations of the implementation choices for all the core containers in Python, lists, sets, and dicts. We heard about doubling factors and amortized big-oh time. Most importantly, there was significant practical applications for Python programmers. Raymond’s talk gives a cost model for the core containers, and having an understanding of that model is important for folks who are writing Python programers. It’s also useful for developers of alternate Python implementations because it allows them to follow suit or to diverge and (hopefully) document the places where the cost model is different. My next favorite talk was Jim Baker’s “More Iterators in Action”. I missed the talk given last year, but I liked this one. Jim hit two of my favorite topics, language integrated query (LINQ) (albeit without the DSL), and concurrency.

Concurrency

There was a lot of interest in concurrency this year, which warms my heart, because I see high-level/dynamic languages and concurrency as the chocolate and peanut butter in the old Reese’s peanut butter cup commercials. There were 2 open space sessions and 1 lightning talk, and the topic entered many of the conversations that I had.

Sun, Jython, and JRuby

People were generally positive to learn about Sun’s interest in Python and Jython. A number of people stopped me to congratulate me on the new job, and we had a nice turnout at the open space session, where people were free with ideas, comments, and a few not so easy to answer questions. I hope that Sun can live up to the goodwill that people extended towards me and Frank.

If I was surprised about the jump in size of PyCon, I was even more surprised by the amount of energy around Jython. At most of the previous PyCon’s that I attended, people would mention Jython, and either be sorry that it was too out of date to consider, or be just plain dismissive of it. This year there was none of that. People were very interested in Jython. I was really surprised by how much interest there was, and by some of the people who were interested. It was certainly a nice feeling to sit in the sprint room and occasionally have people pop in to ask if such and such was running in Jython yet, or did Jython support X because package Y needed it.

This was the first time that I had met Frank Wierzbicki in person — I think he’s the happiest person at Sun right now. I was also able to spend some time hanging out with various folks from the Jython community. It seemed to me that the community was doing quite nicely. If you looked at some of the community metrics that we would use at the ASF to allow a project to graduate from incubation, almost all of those criteria have already been fulfilled. One of my goals for Sun’s Python efforts is for as many of them as possible to be highly community oriented, so it was nice to see that Jython is well on it’s way in that regard. The folks working on Jython are very sharp (including the aforementioned Jim Baker, who it turns out was a classmate of mine at the Brown CS dept – although neither of us can remember meeting the other), and have one of the those (in my mind) essential community ingredients, a community sense of humor.

PyCon 2008: Day 3

Jim snuck this bit of commentary on Jython’s lack of a global interpreter lock into his talk.

There were several Ruby related surprises at PyCon this year. David Heinemeier Hansson, create of Ruby on Rails, made an appearance for one day, and a number of the JRuby committers made a road trip down from Minnesota, to hang out, meet the Jython folks, and generally display their hacker prowess. Which they totally did. Charlie and Tom powered their way to JRuby 1.1RC3 during the conference. Meanwhile Nick Sieger demonstrated what a happens when you stick a bunch of hackers, an EVDO card, and an EVDO hub into a car. The Jython guys (if any of them lived in the same state) need to get some of that – The best thing since the Adobe AIR Bus Tour, and at a fraction of the cost.. The JRuby folks and Jython folks are already starting to talk and share experiences, and I am sure that this will only result in even better dynamic language stuff for the JVM.

Other Cool stuff

On one of the sprint days, I did a bit of wandering and stopped to talk to my friend Brian Dorsey, who is doing some cool stuff here in Seattle. Brian was working with Richard Jones on pyglet and Bruce. Pyglet is a set of Python libraries for writing games and doing other kinds of multimedia. There’s pygame, which I am aware of because of Armin Rigo’s infamous use of pygame to deliver talks about PyPy. Richard has created Bruce, a presentation tool based on pyglet. In addition to being able to do cool multimedia presentation effects, there are some really cool things that you can do. Perhaps the coolest is that you can have a slide which is essentially an embeddd Python interpreter, so no more switching out of your presentation to demo your Python code at work. Really slick.

On a different note, on several evenings, conference goers who stuck around to hang out in the hotel’s common area were treated to musical performances by a dynamic (as in constantly changing set of members) band of Pythonistas:

PyCon 2008: Day 2

PyCon 2008: Day 2

The Sprints

Perhaps the most amazing way in which the conference has changed is this picture.

PyCon 2008: Sprints

That is a picture of a part of the lunch crowd on the first day of the sprints following the conference. When I talked to David Goodger about it, he said that he had taken a count and there were over 250 people at the sprints. Visually, that sprint lunch room looked to be about the size of the room for the first PyCon that I attended (PyCon 2004). Simply amazing. The ASF has a hackathon before every ApacheCon, but I can’t remember one ever reaching this kind of size or scale. Another thing about the PyCon sprints is that they are aimed at growing the community — you don’t have to be a committer on any project in order to attend, and experienced project members will take time to sit and help new people get started. There were several people like that in the Jython sprint room. I was more impressed by what happened with the sprints than any other part of the conference. The only central organization here was that the conference planners obtained sprint space, and in a few cases got some sponsors to cough up money for lunch. Everything else was organized by the projects themselves (I heard that the Django folks closed 100 bugs in a single day). If you want to get a sense of what kinds of things got accomplished at the sprints, you can look at this page on the wiki — it’s not exhaustive, but it’s a start.

Travel

In the past, I’ve had some travel nightmares getting home from PyCon. This year I am happy to report that I didn’t have any problems at all, except for a fight that I had with the Sun internal travel system (and lost).

Conclusion

It was great to be back at PyCon. Interest in Python is growing (as measured by attendance), as is interest in Jython, and interested people are also rolling up their sleeves and pitching in (as measured by sprint attendance growth).

PyCon: Open Space with Sun folks

For those of you at PyCon, Frank Wierzbicki and I will be hosting an open space session on Saturday (tomorrow) at 2pm for people to come and tell us what they think Sun should do in the Python space. We are definitely interested in input and feedback from the larger Python community. If you aren’t at PyCon but have ideas, you can drop either of us e-mail. Our Sun e-mail addresses are <firstname>.<lastname>@sun.com.

If you think my job is all about Jython, you are confused.

Apparently people are confused about what I am working on at Sun, and with PyCon starting tomorrow, this is not a good thing. I am not going to be working on Jython directly, although I will certainly be poking my nose in to see what’s going on. The Python related part of my job (which will be the majority in the short term) is to figure out what Sun should be doing in the Python space, across all of the relevant platforms at Sun, including but not limited to: the JVM and JEE, Netbeans, and Solaris.

Sun isn’t done in the dynamic language space, and I will also be looking for opportunities with other dynamic languages and related technologies.

The Sun is going to shine on Python

Today is my first day as a Sun employee.

How?

Tim Bray was one of the first people to respond to my “looking for a job” blog post. I have not written about it much, but I’ve been very impressed with how Sun has handled the JRuby project. Tim told me that Sun was interested in ramping up their support for Python in a similar fashion, and asked if I would be interested in coming to Sun to lead such an effort.

Why?

After a bunch of talking and interviewing and so forth, it turns out that I was very interested. Long time readers know that I am a dynamic languages guy, going back to the original dynamic language, Lisp. I spent 2.75 of the last 4 years at OSAF working on a big desktop application written in Python (Contrary to some recent blog posts, Python was not a factor in the difficulties that we had with Chandler). The prospect of doing something that would help Python was very attractive. However, Sun has been slow to embrace dynamic languages (whether atop the JVM or not), and Sun’s history in open source has been somewhat checkered in my view. So there were some questions that I had to answer for myself before deciding to go to Sun (especially since I had 3 other very good options):

1. Can Sun actually work with an open source community?

It’s no secret that I have not been a fan of Sun’s handling of the open sourcing of Java, and it seems like OpenSolaris is having some governance problems of its own at the moment. However, if you look at the way that JRuby has been handled, you’ll see that there are parts of Sun that are learning how to work with a community, and doing a very good job of it. Sun hired two of the leading JRuby contributors and gave them license to keep doing what they had been doing. The JRuby guys have been well received by the “C” Ruby community and even the CLR/.NET Ruby community. In addition Sun has been investing in Ruby via support in NetBeans and via some collaborations with the University of Tokyo on the C VM for Ruby. Over the years, I’ve met many people at Sun who understand a collaborative development style. Many of those folks are committers on Apache projects.

2. How serious is Sun about dynamic languages and how deep does that support go?

Sun is (finally?) very serious about this. As part of Sun’s new direction, Sun wants to give developers the ability to use whatever tool sets they want. Ruby, Python, PHP, Java. On or off OpenSolaris. On or off the JVM. There is an official project, John Rose’s DaVinci Machine project, to modify the JVM to support dynamic languages. As far as Python goes, Frank Wierzbicki, the maintainer of Jython, started at Sun last Monday, so there will be at least two of us working on Python related stuff. That includes Jython, Python support for Netbeans, and some other stuff that we haven’t quite figured out yet. We definitely will be looking for things that we can do to support CPython and the Python language as a whole. This is not just about Python on on the JVM. Sun will try to make its platforms, OpenSolaris and the JVM, the best place to develop and deploy Python applications. But at the moment that’s a goal and not a reality, so there is lots to do.

What’s Next?

Frank and I will be at PyCon in Chicago in a week or so. One of my goals (besides hooking back up with people since I missed PyCon last year) will be to sit down and talk to anyone who has ideas about sensible things that Sun could do to help Python. In the mean time, my e-mail address will be <FirstName>.<LastName>@Sun.com

Oh, one more thing. My new job title is “Principal Engineer, Dynamic Languages and Tools”, so expect to see me dinking around with other dynamic language stuff as well.

My thanks to Tim Bray for helping to make this happen.

Update:
It looks like it’s going to take a little longer to get my e-mail address fully operational…
Update 2:
Ok, e-mail is set and ready to go.

Leopard, Java, and Open Source

I haven’t gotten around to upgrading to Leopard yet for several reasons, probably the most prominent of which is that Lightroom doesn’t work correctly, and I’m starting to use it a lot (more on that in a later post, perhaps). But it’s not for lack of Java 6. I’ve been following the Java on Leopard thing with bemusement, but John Gruber’s most recent post sparked a few thoughts.

Since I haven’t posted in a while, let me remind you of the context. For a while I was a Java developer, but that was another life ago, and since then, I’ve been a Python developer, and am now a manager of Java (and Javascript) developers. I’d agree with John that Java is not directly important to the Mac. No important piece of Mac software that I am aware of is written in Java, and the only important (unless you count Azureus, which Mac folks would not) client side Java apps are Java IDE’s or custom corporate applications. So it is hard to make a compelling argument that a late Java is directly bad for Macintosh sales, which Apple is surely focused on.

Nonetheless, I do think that Java, and all those Java developers (who many in the Mac community look down their nose at) are important. Their pushing for Titanium Powerbooks and MacBook Pros helped (in a lot of situations that I am directly familiar with) to improve Apple’s credibility in development shops, which helped Apple get to where it is today. I might still be using Windows if I hadn’t gone to ApacheCon 4-5 years ago and started to see the Mac’s, which were being used by my Java developing friends.

Gruber says that Java is not made to “just build” on any Unix-like OS:

Several irritated Java developers suggested that I’d feel differently if it were a developer runtime that I personally cared about — that I’d be irate if, say, Perl or Ruby or Python were dropped or degraded in Leopard. But that’s not a good comparison; Perl, Python, and Ruby pretty much compile out of the box on Mac OS X. Apple doesn’t have to do much at all — at least relative to Java — to include them on Mac OS X. Why? Because that’s how these tools are designed and engineered — they’re made to “just build” on any Unix-like OS. It’s not Apple’s responsibility that Java isn’t like that — it’s Sun’s.

Actually, I don’t think that he is correct here. When I worked at Apple, one of the projects that I worked on was a port of Java 2 to run atop the Newton operating system. I personally wrote the driver code for networking and the file system, and I can tell you from first hand experience, that Java definitely builds fine on Unix like operating systems. That’s not the problem. The problem is where OS X is not a Unix like operating system.
The places where there seem to be problems are the places where Java needs to talk to Carbon to do all that client side GUI Java stuff. I don’t think that you can claim that Carbon is part of “any Unix-like OS”.

I do think that there is something important buried in the quote from Gruber’s post. Look at the difference between the runtimes that got “kept” in Leopard. Perl, Python, and Ruby (Let’s leave aside for a moment the sad truth that hardcore Python and Ruby developers end up installing their own local runtimes). Not only were these runtimes bundled, but 2 of the 3 were actually improved – things like bridges to Cocoa, DTrace probes, and so on. What’s a critical difference between these runtimes and Java? How did all these improvements happen? Many of them were done by people outside of Apple, on a schedule that was not Apple’s, but which coincided with Apple’s. The Ruby DTrace probes were done by Joyent, the Python Objective-C bridge was done by people outside Apple. Apple pretty much just had to pick up the changes that were made. How did this happen? Those runtimes are open source, as were all the improvements that I just mentioned.

A few years ago at JavaOne, Sun took a poll of Java developers to see if open sourcing Java was important to them. If I remember right, about half those developers said no. From where I sit, it looks like an open source Java would have contributed substantially to having Java 6 ready to go for Leopard. Today, Sun has opened up the source code for Java, but a version of Java based on that opened codebase has yet to arrive. Maybe open source Java really is important after all. I guess we’ll have to wait for OS 10.6 and Java 7 to find out.

The Erlang community

Matt Croydon Didn’t agree with my commentary on the Erlang community, and he’s partially right. I shouldn’t have said “we need a community” because there is an Erlang community, and I knew that. I have never been a fan of Java, and I don’t want to be stuck using the moral equivalent of Java when the multicore/concurrency thing shakes out. So if I want to be able to use Erlang (and I’ve not totally made that decision), then it needs to have a bigger, more diverse, and easier to find community.