People who've made the switch to dynamic languages seem much, much happier. I was a bit out of sorts from jet lag and travel in general when I entered the Birmingham UK conference and suddenly a wash of good feelings poured over me. "Ahh! Python Programmers!"
I worked long and hard on my two presentations and the audience was extremely appreciative. Many people came up to me during the rest of the conference and said how much they enjoyed both the keynote and the metaprogramming talk. It really makes it worth your efforts to know you've made a difference.
I also sat on a panel chaired by Steve Holden about open-spaces style conferences. The other two panelists had primarily worked with Bar Camps, but you could tell from their enthusiasm that they'd had the same experience I have, of the magic of letting go and allowing everyone to create the best conference possible. Naturally, the first thing we did was pull chairs into a circle and turn the thing into (almost) a conversation (since we were primarily answering questions). I immediately noticed the change in feeling from "presenting to an audience" to the connectedness of having a discussion. As much as I enjoy speaking to an audience, once you've experienced an open-spaces style event, you don't want to do anything else.
All the "eyes-forward" (non-open-spaces) presentations have audio recordings and the slides are downloadable; see the EuroPython site for availability.
Originally more space was available for open-spaces sessions but the conference unexpectedly expanded with more talks and more people so we were limited to one room (but in the spirit of open spaces, we got creative and appropriated any other spaces we could find as necessary). Because of the down economy, the organizers (this is a community-organized conference, all volunteer) expected less than 380 people, but got over 430, a tribute to both the growing popularity of Python and the low cost and high appeal of user-organized conferences. Indeed, whether or not the economy improves next year it looks like the conference will outgrow the venue; it was already tight (like Pycon in the US, the pattern seems to be to reserve a space for two years at a time, apparently for economic advantages).
Steve Holden (head of the PSF, the Python Software Foundation) and I spontaneously decided that I should shoehorn my short Introduction to Open Spaces in at the front of my keynote because the open spaces started right afterwards and hadn't had a lot of entries. Whether because of that or the nature of the conference, they filled and often overflowed. I ended up attending two very valuable sessions and by request held a session called "So You Want to Write a Book" about the perils and difficulties of book publishing.
The first open-spaces session I attended was on the MoinMoin wiki system. It appeared that the whole core team was in attendance, willing to answer any questions, and it pretty much convinced me that I should move the Python book over to MoinMoin, even if it means changing the markup. The barriers to entry have been too great so far. Despite having around 100 volunteers, using Sphinx and Mercurial create too much of a hurdle for most people to contribute, and I suspect it makes contributing seem too "intimidating and important," so it isn't moving forward the way I want. Converting to a wiki will, I think, put it much more into the hands of the group and unstick the project.
The second open-spaces session I attended was on Kamaelia, which is a very different approach to solving the concurrency challenge. This was convened by Kamaelia's creator. The question he asked was at the other end of the spectrum from things like "how do we prevent deadlock?" Instead, it was "what programming model is easiest for people to grasp and use" (which, of course, is the Pythonic way to look at the problem). His observation was that people make very effective use of Unix pipes and filters without knowing anything about concurrency, so Kamaelia is a system that allows you to create concurrent "filter" components with an easy way to wire such components together in sequence and in parallel. I found this approach quite compelling; one particularly attractive aspect is the ability to quickly wire together components for rapid testing and partial system building. Right now Kamaelia's concurrency is all process-based, but the use of threads (which would still be isolated like processes, but would just utilize threads if it helped performance) is a future consideration. I think Kamaelia is worth further exploration.
The other session that stood out to me was Mark Ramm's overview of TurboGears 2, which was recently released. TurboGears takes the attitude that creating all the individual components of a web framework is too hard and that you can't get the best results that way. Instead, best-of-breed components are selected from what's out there by discovering the superior work that people have accomplished by specializing in a particular arena; an outstanding example is SQLAlchemy, which continues to look like the best object-relational mapping that anyone has created. By using WSGI (Web Services Gateway Interface, part of recent Python releases) in TurboGears 2, swapping components in and out is even easier, and that's what they've done -- out of the box, the group of components is the best for most projects, but you can easily change out a component if the default doesn't meet your needs. I've dabbled a bit with TurboGears 1 in the past, but Mark's presentation has rekindled my interest. I need to find Python hosting for MoinMoin, so perhaps this will give me the opportunity to use TurboGears as well.
One thing I found puzzling was that the Brits consistently apologized for and/or denigrated Birmingham. I didn't find it unpleasant at all; parts were quite attractive and charming. Maybe if you live in Europe it raises your expectations for a place.
PS: I'm posting this from inside the RailAir bus on the way from the Reading train station to Heathrow. Having wireless on a bus is pretty cool, but by using it I'm not paying attention to the beautiful English countryside so it's a mixed benefit.
Birmingham gets very shady very quickly not far from the EuroPython conference venue. Mentioned on the mailing list was a mugging between there and the Etap hotel where most people are staying (it wasn't a conference-goer). Of course it has lots of nice areas too. They just happen to be adjacent to areas with empty storefronts, pawn shops, and cash checking joints. It reminds me of Philadelphia.
Also, thanks for the mention in your slides! I gave a version of the Class Decorators talk last year at EuroPython and was probably standing in the same place you were when you mentioned it.
Thank you for your kind words on Kamaelia. I'd just like to correct one minor misconception - it's not just process based. We have generator, thread and process based components. We tend to prefer generator based components since you can generators inside threads and inside processes, but not the other way round. ie it provides a clear migration path. We tend to use threaded components for any components that make blocking calls.
The issue I think has caused the misconception that we're process was the discussion around the ProcessPipeline chassis. Generally we'll do something like Pipeline(A(), B(), C()), but we can also write this: ProcessPipeline(A(), B(), C()) - which will run all of those sub-components in separate processes.
When asked if we had the logical equivalent - a ThreadedPipeline(A(),B(),C()) - ie automatically running A,B & C in separate threads, the answer was no. Though, thinking about it, it should be possible to make that safe to do. (We do have threadedcomponents after all)
It's just a riskier thing to take something tested as a generator to use it as a thread, than it is to use it as a process, for the obvious shared memory reasons - which is the sole reason for not having done that yet.
That said, the benefits on GIL-less platforms - ie IronPython & Jython - could potentially make the time investment extremely worthwhile.
Also, many thanks for the session on book writing - it was extremely interesting & fun :)
Regarding MoinMoin for your book, moving should be quite painless since it supports the same reStructuredText markup that you are already using. The only conversion you may need to do is with any Sphinx-specific features you may have been using. MoinMoin supports Docutils but not Sphinx (that I know of).
Just write "#format rst" on the first like of a page. And install Docutils on the system, of course.
Just another thank you for the talks you gave at Europython. I really enjoyed them. Especially your thoughts about Exceptions really coincides with mine, I've for many years thought that there's this ridiculous amount of confusion about when to use Exceptions. Which is to say, use it as a replacement for other error handling techniques. Exceptions are, I think, essentially a solution to the function-call-error-code style of coding which if followed strictly results in extremely hard to read code since you invariably end up with a heck of a lot of error handling code interspersed with the actual code you're interested in, which makes code hard to read and maintain. Exceptions removes all the error handling to another place, and allows the "happy path" to be expressed cleanly and succinctly without being obscured by error handling concerns. Ideally then, one should try to use only exceptions wherever possible, since using both them and more conventional methods can be confusing, especially to new developers in a code base. Anyway, this is drifting off topic a bit, so I'll cut this short and just reiterate my thanks and wish you all the best.
EuroPython was the first Python conference I went to and it is the first conference that made me realize there is something fundamentally wrong with what you call 'eyes forward'-only conferences. The problem I had was figuring out how deep the talks I intended to go to would go. Being interested in the topic beforehand meant I was already familiar with it. I just hoped to learn new things. I sat through many talks hoping it would go a little deeper along the way. Sometimes it did, sometimes it didn't. Unfortunately I had not many means to steer the talk. The presenter had already prepared his talk for what he/she expected to be the average level of his audience. The only thing I could do was leave the room early, which I sometimes did but always gave me a guilty feeling.
I am sorry to say the same about your metaclasses talk. I already read your online articles and the necessary background material and the talk didn't bring much additional information. I didn't leave though, I sat on the front row and leaving the room would mean I would have gotten 400 eyeballs piercing my back. That's not to say there was something wrong with your talk, quite contrary, I think it was perfect for the average audience member. It's just a shame nobody is avarage :) (neither perfect).
Besides the many advantages of open spaces conferences you mentioned here and during your talk, one of the biggest advantages I see is that the participant are able to lift the discussion to the maximum level the group can handle. Compared to an 'eyes-forward' presentation, in an open spaces talk the speaker is just the one that is known he/she can handle the maximum level of the group in an open discussion. A fundamental difference. And if a participant can't keep up or just isn't interested where the discussion is going hecan leave at any time. Or start an open space talk himself.
If there is one thing EuroPython taught me it's that next time I'll be looking for open spaces type of conferences.
I used to program in Smalltalk for a living for almost 10 years and I would say that Smalltalk is fairly dynamic (to some extend you can change the language if you want to). Then I had to make the change to Java when Smalltalk finally appeared to die sooner than expected. I found static typing in Java a real plus. Earlier when there was only Smalltalk and C++ I would always have preferred Smalltalk over C++. The utility of static typing in C++ comes at such a high cost that it's almost not worth it. In Java, by contrast, the price is low (everything compiles instantly) and the utility is high. Back then in the Smalltalk times I never changed a method without retesting it. Would simply not be possible. Doing changes in a layer deep down was really a big thing. My conclusion is that optional static typing is really a useful thing. Maybe at present Scala comes closest to this.
"One thing I found puzzling was that the Brits consistently apologized for and/or denigrated Birmingham. I didn't find it unpleasant at all; parts were quite attractive and charming. Maybe if you live in Europe it raises your expectations for a place."
Your proposed move from Sphinx/Mercurial to wiki is interesting since I'm in the process of moving the other way. I've run wikis for years but besides the onslaught of wiki spam I've just not seen the level of contribution to make them worthwhile, at least for local communities. I still end up posting much of the content. So I've decided to make it easy for myself, using my preferred editing environment and tools.
Re open spaces, I find them fun but at PyCon at least, a bit unsatisfying. I can appreciate the dislike of canned slides and eyes-forward but the lack of a projector and letting everything be informal makes it difficult to dig into some topics. Some topics just call for carefully prepared diagrams or source examples to explain complex ideas and you can't do good ones on the fly. It turns into all handwaving and passing URLs around. Social but not enlightening, in my limited experience. I'd like to believe in them and perhaps I've just attended poor ones.
> Your proposed move from Sphinx/Mercurial to wiki is > interesting since I'm in the process of moving the other > way. I've run wikis for years but besides the onslaught > of wiki spam I've just not seen the level of contribution > to make them worthwhile, at least for local communities. > I still end up posting much of the content. So I've > e decided to make it easy for myself, using my preferred > editing environment and tools.
If I was the only one developing the book, as I primarily have been with books in the past, then the Sphinx/Mercurial approach would have been good; I was liking it.
The problem this time is that I am trying a very different experiment, which is to involve a lot of people in the process of creating the book (rather than just giving feedback and corrections). And what I found was that the hurdles were too large and that people weren't participating -- at least that's my current theory. So I'm lowering the barriers to participation by putting it on a wiki.
As far as wiki spam goes, I will turn on password protection for MoinMoin, and only group members will have it.
> Your proposed move from Sphinx/Mercurial to wiki is > interesting since I'm in the process of moving the other > way. I've run wikis for years but besides the onslaught > of wiki spam I've just not seen the level of contribution > to make them worthwhile, at least for local communities.
Take another look at http://wiki.python.org/ where spamming has been greatly reduced. Indeed, this is the case for most MoinMoin installations running with the text-based question/answer anti-spam mechanisms, even though some people complain about them claiming that they're complete show-stoppers for getting people to edit the Wiki. You can exempt regular contributors from having to deal with such questions, of course, but this then has people complaining about other things, such as needing to have a new account, which are completely fixable (MoinMoin supports OpenID).
I accept that some people just won't edit a Wiki or will let everyone know that they don't like doing so, but I think that in general Wikis encourage more participation. Where one doubts that others will participate, one obviously has the choice of using whichever tools one feels is appropriate (the Hatta Wiki runs directly on top of Mercurial, incidentally), but I think that many of the reasons for disliking Wikis are spurious. I use more than one Wiki which employs secure logins for genuinely trusted users, so the "Wikis get spammed" argument isn't universal by any means, although it is used extensively by those perpetuating the myth that a Wiki must be anonymously editable by the entire Internet or "it isn't a Wiki".
As I've said in another forum, the python.org Wiki is probably one of the most vibrant parts of that site and could definitely fill the documentation gap, but currently it's rather hidden and de-emphasised. Moving that resource to a more "top-down" architecture would quite possibly turn most of the contributors away.