You can find the list of talks here. If you hover your mouse over a particular talk, it will pop up a description box which will (possibly) include links to notes, audio and video. If these things aren't available right now, they may show up over the next few days or weeks.
One Laptop Per Child
The opening keynote was tremendous. Ivan Krstic' is a software architect and researcher currently on leave from Harvard University. He is the director of security and information architecture at the One Laptop per Child project. He told us about the project, how it overcame numerous challenges after they had been told that each hurdle was impossible. He brought several machines with him, so you could see what they were really like.
The project decided to write everything in Python, except for a few pieces of low-level driver-type code. Even the file system is written in Python. And there's a dedicated button on the keyboard, with a little gear on it, to "view source." So kids can see what code is making their applications run, and even modify it.
Ivan is looking for people to help on the project -- they are supposed to begin shipping in August -- both in full-time and internship positions. I found myself wondering if there was some way that I could even fit a few weeks in to go help. I think this is a truly world-changing project.
The following morning, Adelle Goldberg (of Smalltalk fame) followed with a keynote about the hurdles and problems of education, both in the US and in the world. It's even more of a mess than I've always thought. We learn in spite of the education system. The one laptop per child initiative allows children to learn in spite of not even having an education system. My hope is that it might catalyze change in the education system worldwide. If you want a vision of what this might mean, read Neal Stephenson's novel "The Diamond Age" (which I personally like better than "Snow Crash").
One great anecdote Adelle told had to do with schools that had only one or two computers per classrom. They put them in closets, and the students would take turns going into the closets and working on the computers. But they discovered that the students in the classes that had only one computer were doing much better. Because the teacher was sending them to the computer closet in pairs. So they were helping each other. On numerous occasions she pointed out how much the educational system discourages us from helping each other. Sigh. To the point where management (and programmers) often patently dismiss the possibilities of of pair programming.
What Can Python Learn from Other Languages?
I held an openspace session on this topic. Here's a list, in no particular order, of ideas that came from that session (those of you who photographed the whiteboard, if you think I left out something important please add a comment):
Extension methods/Open classes
Multicore Concurrency (like Erlang?)
Better support for metaclass programming. It has gotten better in Python, but
it still requires an intellectual leap -- to the point that many Ruby programmers don't
think metaclass programming is possible in Python.
XML Direct Support (or more trivial). Groovy has XML support that allows you to completely treat XML as an object tree -- you don't have to see or type a single angle brace. The inclusion of elementree has helped the situation, but I like the idea of being completely shielded from XML.
Macros -- a'la Lisp. This might throw open the door to tremendous power. I've never seen a Lisp macro, but I've heard Lisp programmers wax poetic about them.
Restricted Execution (sandbox). Similar to Java's applet sandbox. Might allow an applet-like mechanism for Python on the web.
Forking Interpreter/Cached Interpreter. A potential way to deal with the concurrency issue, if it's very fast to start up a new interpreter in a separate process.
Improve Interprocess Communication. (Posh?)
Built in application packager. It would be really helpful to be able to have zero-configuration, one-button creation of an application distribution.
Direct support for useful Idioms/Patterns. For example, the reactor pattern has direct support in the form of the asyncore library.
Trigger SQL from SELECT, etc. Take inspiration from C# Linq query expressions, which look like list comprehensions for data selection. Database programming becomes fully integrated into the core of the programming language.
Agents/Actors. This may have some support through Pygame extended agent. Apparently an agent framework on top of Pygame. Pyro -- Python Remote Objects -- apparently has some agent behavior.
Precompiler for domain-specific languages -- library and other tools. It would be nice to have some kind of support for creating DSLs in the way Ruby does. This could be a precompiler, the aforementioned Lisp-style macros, or something else. IPython is embeddable, and something like that might be a good start.
Miscellaneous Notes
Crunchy (formerly crunchy frog) is a very impressive way to create interactive tutorials that work inside a browser (for full functionality, requires Firefox).
I saw a very impressive lightning talk about a new game and multimedia library from Pyglet. This apparently uses ctypes to directly connect to the built-in operating system facilities on Linux, Mac OS X and Windows. Looks quite promising.
IronPython gets around the global interpreter lock. So you can create fully threaded programs that run in true parallel on multiple cores using IronPython. It also provides an easy interface to Windows Forms.
ctypes are built into Python 2.5. These allow fairly easy connection to C dlls. This provides a way to reuse C libraries, but it also seems like a good way for speed optimizations. Numpy supports ctypes. There's also COMtypes, which is a Win32 COM wrapper. Swig seems to have improved, as well (but doesn't support nested C++ classes).
Bazaar-vcs.org. A new distributed version control system. The next step up from subversion.
Trac (written in Python) has a plugin framework, might be useful as an example plugin architecture.
Enthought: SciPy, visualization support.
Itertools talk. Very powerful stuff here. Look for Itertools recipes. Talk slides at
http://us.pycon.org/common/talkdata/PyCon2007/028/IteratorsInActionWithNotes.pdf
It seems likely that TurboGears and Pylons will merge. This looks like a good thing.
Pylab has good plotting support. Also Matplotlib.
There's a 300-page book out soon about Numpy (Numerical python).
Checking tools: Pychecker, Pylint, pyflakes.
The Zeroconf Python library uses multicast DNS to broadcast configuration information among machines. Also see mod_rendevous.
Guido's current project information can be found by looking him up on Google video.
Pymock appears to be a very powerful mock object framework.
Nose: discovers and runs unit tests. Eliminates unit test scaffolding. Also provides code coverage, and uses the hotshot profiler.
Nosy: "cruise control" style system for Nose tests.
Stackless python seems to have evolved significantly. Gained many benefits from PyPy project (Python written in Python). It doesn't seem to get around the global interpreter lock problem, and thus is a code organization technique rather than allowing true parallel programming on multiple processors.
RPython allows you to write Python that is compiled to C, in order to execute 30-40 times faster.
A universal problem with conferences is the infamous "closing session." These are usually fluffy, boring and a waste of time. Pycon ended with lightning talks. What an excellent way to finish the conference.
There were 593 attendees, which is a 44% increase over last year. The day before the conference started was tutorials, which were all full, and the days after the conference were sprints where groups got together and worked on specific problems for a few days. Real code is developed during these sprints.
Scala, while being quite different from Python, has built-in support for a few of the things on that wishlist of features.
- XML is a first-class value. Thus I can assign <blah>meh</blah> as a value and Scala will infer its type to be Elem. You can also use pattern matching on XML values. It really beats the pants off using the DOM or SAX in my opinion.
- Scala is extensible; as an example of this, it implements lightweight Erlang-style concurrency as a library, using an event-based actors model. It has wonderful support for mixins, it's really pretty nice.
Thus if you're looking at implementing these you might look at Scala's take on them.
I saw in an early version of Scala the claim that they were going to directly support agent-based programming, which was a very exciting concept. But all those references seem to have vanished.
Apparently there is an extension of Pygame that supports either actors or agents, which sounds quite interesting.
I'm not exactly sure what you mean by "agent-based programming." There is a library that implements event-based actors which is fairly usable today. It is in use in David Pollak's new Scala web framework Lift: www.liftweb.net. The kinks are still being worked out but it's usable for real-world work today. The actors library is, as far as I can tell, able to scale massively in a manner similar to Erlang. Unfortunately it's kind of poorly undocumented; Phillip Haller, the guy who wrote the actors library as part of his graduate work, is working on an extended tutorial to explain all this stuff.
I didn't mean to derail this into Scala advocacy, although I do think the language is worth the attention of anyone who wants to work with an expressive language that targets the JVM.
Why will Python 3000 have C-based runtime? Ruby, Python, PHP, Java etc. all have different incompatible runtimes what means incompatible libraries. I can't use libraries written in Python with PHP or Ruby. Same for Java vs. Python, Ruby, PHP. Creating a common, free and language-independent runtime should be No. 1 on the TODO-list if you ask me.
The next-generation of multicore processors will demand complete new runtimes and complete new concepts. The time has come to create the universal common runtime for Java, Python, PHP, Ruby and the likes. Why not building it on top of the JVM now that Java will be opensourced and supported by big hard- and software companies like IBM, Sun, Intel etc.?
The Python-. Ruby- and PHP-communities will probably vaste a lot of effort to get their C-based runtimes done whereas IBM, Intel and Sun will probably spend millions in tuning the JVM for multicore. A CLR and JVM optimized for multicores will outperform any other runtime. I hope you know that.
> Why will Python 3000 have C-based runtime? Ruby, Python, > PHP, Java etc. all have different incompatible runtimes > what means incompatible libraries. I can't use libraries > written in Python with PHP or Ruby. Same for Java vs. > Python, Ruby, PHP. Creating a common, free and > language-independent runtime should be No. 1 on the > TODO-list if you ask me. >
Who's TODO list? How many years has parrot been in development for the newest version of perl now? Also, given the number of languages available for both the JVM and .NET, why would anybody be motivated to undertake the effort to create yet another language independent runtime? Given the particular strengths of the languages you mention, creating one runtime to rule them all would be a difficult task, assuming running all those languages efficiently is a goal.
> The next-generation of multicore processors will demand > complete new runtimes and complete new concepts. The time > has come to create the universal common runtime for Java, > Python, PHP, Ruby and the likes. Why not building it on > top of the JVM now that Java will be opensourced and > supported by big hard- and software companies like IBM, > Sun, Intel etc.? >
If completely new concepts are going to be required, that will more than likely require completely new languages as well. Erlang comes to mind, given how it was built from the ground up for concurrency.
> The Python-. Ruby- and PHP-communities will probably vaste > a lot of effort to get their C-based runtimes done whereas > IBM, Intel and Sun will probably spend millions in tuning > the JVM for multicore. A CLR and JVM optimized for > multicores will outperform any other runtime. I hope you > know that.
So what? Based on the number of successful applictions out there written in PHP, Ruby, Python and PHP, the fact that they are slower than the CLR, JVM or compiled C and C++ programs, I don't see how that matters much. People that need fast software will continue to use those compiled environments. People that need to develop software fast will use whatever tools let them accomplish their goals.
>On numerous occasions she pointed > out how much the educational system discourages us from > helping each other. Sigh. To the point where management > (and programmers) often patently dismiss the possibilities > of of pair programming. >
I think the educational system just reflects the realities of the working world (even where pair programming is practiced).
Look, mixing divergent management practices doesn't work very well. In the 1980's I suffered through quality training inspired by the success Japan was having at the time. One of those companies where I experience this was Xerox which trained 100% of it's employees for a minimum of two weeks. That made it one of the most expensive projects they had at the time. Has Xerox set the world on fire since then?
The problem is that you can't cherry-pick the practices you like and expect that it's going to work like the full commitment. With Japan's (at the time) policy of life-time employment a statement like "Act like you own the company" makes sense. In the US, where you might be laid off at any time, it just makes a good Dilbert cartoon (and it did).
One problem with pair programming is that it isn't a real collaboration. Developers are working together but are really competitors in any way that matters (salary, prestige etc). If a company truly believed in collaboration, each developer would share common pay and couldn't be laid off except as a unit. This might sound "extreme" but .. you get the idea.
I still can't see the big usefulness of macros. In 80% of cases you can use functions. There is nothing done with macros that cannot be done with first class functions also. First class functions might be slower and uglier (mostly because Python has no syntax for anonymous code blocks), but you can use runtime values that you cannot with macros. If you need a new syntax for your DSL that exceeds that, you can always pass strings around and do transformations using a parsing library and tailor the DSL to your specific needs. I think that is cleaner than using some Frankenpython to do the same IMHO.
> >On numerous occasions she pointed > > out how much the educational system discourages us from > > helping each other. Sigh. To the point where management > > (and programmers) often patently dismiss the > possibilities > > of of pair programming. > > > > I think the educational system just reflects the realities > of the working world (even where pair programming is > practiced). >
This might be the first case in history of that happening. General consensus seems to be that the educational system reflects very little of the working world. I tend to agree based solely on experience and for one I am glad that is the fact. Actually trying to learn something in the working world is extremely difficult compared to learning in school. At least at the school I went to.
> Look, mixing divergent management practices doesn't work > very well. In the 1980's I suffered through quality > training inspired by the success Japan was having at the > time. One of those companies where I experience this was > Xerox which trained 100% of it's employees for a minimum > of two weeks. That made it one of the most expensive > projects they had at the time. Has Xerox set the world on > fire since then? > > The problem is that you can't cherry-pick the practices > you like and expect that it's going to work like the full > commitment. With Japan's (at the time) policy of life-time > employment a statement like "Act like you own the company" > makes sense. In the US, where you might be laid off at any > time, it just makes a good Dilbert cartoon (and it did). >
Cherry picking in that way is incredibly counter productive. Blech. I fail to see how managements at US companies expect rabid loyalty while offering little in return. But, alas, that's how it is.
> One problem with pair programming is that it isn't a real > collaboration. Developers are working together but are > really competitors in any way that matters (salary, > prestige etc).
All that means is you have people with ego problems. If people worried more about improving their skillset to be as good as the person they were paired with (You might even learn something from the person you are paired with. It's not like we are all equally bad programmers. Some of us suck more than others.) and less about how 'unfair' it is that somebody is making less money, well, it probably wouldn't be as big a deal.
In the end, life is all about competition. We compete for food, shelter, mates, getting the best seats to the superbowl and so on. True collaboration requires a pretty high level of maturity. Suppressing your own needs for the good of 'the whole' is a very hard thing to do in some cases.
> If a company truly believed in > collaboration, each developer would share common pay and > couldn't be laid off except as a unit. This might sound > "extreme" but .. you get the idea.
Heaven forbid people get compensated on something like 'merit' or 'the value they bring to the company'. I know there are plenty of cases where this isn't the case in the real world, but I'll take what we've got over making the same amount as everybody else. That sounds more 'communist' than 'extreme'. Admitting that somebody else might be right and you may be wrong seems well nigh impossible for some people. I fail to see how equal salaries will fix that. If anything, it will make it worse because some schmuck will believe that he is 'just as right' as everybody else. He must be. He's getting the same pay!
> I still can't see the big usefulness of macros. In 80% of > cases you can use functions. There is nothing done with > macros that cannot be done with first class functions > also. First class functions might be slower and uglier > (mostly because Python has no syntax for anonymous code > blocks), but you can use runtime values that you cannot > with macros. If you need a new syntax for your DSL that > exceeds that, you can always pass strings around and do > transformations using a parsing library and tailor the DSL > to your specific needs. I think that is cleaner than using > some Frankenpython to do the same IMHO.
That's not true. Lisp macros are a different sort of animal. The best I can do for an explanation that might at least get you interested it so point you here
In most cases you don't need macros and they are even generally frowned upon in lisp if used unnecessarily. In lisp code and data are the same thing, so using runtime values is possible.
None of this is an argument for putting macros in python (I've never used macros in any of the lisp I've written, but then I've never done anything 'interesting' in lisp), but I don't think that lisp macros can be casually dismissed as the same thing as first class functions.
> All that means is you have people with ego problems. If > people worried more about improving their skillset to be > as good as the person they were paired with (You might > even learn something from the person you are paired with. > It's not like we are all equally bad programmers. Some of > us suck more than others.) and less about how 'unfair' it > is that somebody is making less money, well, it probably > wouldn't be as big a deal.
It's not really about ego, it's about the contradiction between a practice and the incentives that should be driving it.
BTW, I hate this negative way of looking at ourselves "It's not like we are all equally bad programmers". The dailyWTF mentality is like a cancer in our industry.
> > In the end, life is all about competition. We compete for > food, shelter, mates, getting the best seats to the > superbowl and so on. True collaboration requires a pretty > high level of maturity. Suppressing your own needs for the > good of 'the whole' is a very hard thing to do in some > cases.
That's a nice philosophical statement but has little to do with corporate life. > > > If a company truly believed in > > collaboration, each developer would share common pay > and > > couldn't be laid off except as a unit. This might sound > > "extreme" but .. you get the idea. > > Heaven forbid people get compensated on something like > 'merit' or 'the value they bring to the company'. I know > there are plenty of cases where this isn't the case in the > real world, but I'll take what we've got over making the > same amount as everybody else. That sounds more > 'communist' than 'extreme'. Admitting that somebody else > might be right and you may be wrong seems well nigh > impossible for some people. I fail to see how equal > salaries will fix that. If anything, it will make it worse > because some schmuck will believe that he is 'just as > right' as everybody else. He must be. He's getting the > same pay!
Does anyone with a few years of experience under their belt really believe that pay and performance go hand-in-hand? It's not about convincing people that they are the same, it's about creating an environment that minimizes competitive behavior. Besides, unless your company is providing a social service to train schmucks, there isn't any value to pairing one with somebody competent anyway.
> > I still can't see the big usefulness of macros. > > That's not true. Lisp macros are a different sort of > animal. The best I can do for an explanation that might at > least get you interested it so point you here > > http://www.paulgraham.com/avg.html > > In most cases you don't need macros and they are even > generally frowned upon in lisp if used unnecessarily. In > lisp code and data are the same thing, so using runtime > values is possible. > > None of this is an argument for putting macros in python > (I've never used macros in any of the lisp I've written, > but then I've never done anything 'interesting' in lisp), > but I don't think that lisp macros can be casually > dismissed as the same thing as first class functions.
Lisp is a different beast. The odd syntax and scoping of Lisp makes it somewhat easier to write macros. Still I don’t buy Paul’s assertion that you absolutely need macros. In all examples I have seen on the Internet so far you can replace macros with another style like functional code or object orientation. It might not run as fast or be as aesthetical pleasing to Paul as the macro paradigm, but it is doable. I would love to see a short problem solved in Lisp with macros and with functions side by side in which the code using macros is significantly easier to understand.
> > All that means is you have people with ego problems. If > > people worried more about improving their skillset to > be > > as good as the person they were paired with (You might > > even learn something from the person you are paired > with. > > It's not like we are all equally bad programmers. Some > of > > us suck more than others.) and less about how 'unfair' > it > > is that somebody is making less money, well, it > probably > > wouldn't be as big a deal. > > It's not really about ego, it's about the contradiction > between a practice and the incentives that should be > driving it.
What contradiction, exactly. The way I see it, better people should get paid more. I've not ever taken a dislike to pair programming because somebody is getting paid more than me or is more prestigious than me. Maybe that's just me. Maybe others can share their experiences if they differ. Of all the problems I have with pair programming, the fact that developer A gets paid more than developer B has never crossed my mind. I don't know what any of my coworkers get paid and I don't really care. It's never come up.
> > BTW, I hate this negative way of looking at ourselves > "It's not like we are all equally bad programmers". The > dailyWTF mentality is like a cancer in our industry. >
It's called self depracating humor. I'm sorry if it bothers you.
> > > > In the end, life is all about competition. We compete > for > > food, shelter, mates, getting the best seats to the > > superbowl and so on. True collaboration requires a > pretty > > high level of maturity. Suppressing your own needs for > the > > good of 'the whole' is a very hard thing to do in some > > cases. > > That's a nice philosophical statement but has little to do > with corporate life.
How do you figure? We're all competing for our share of the company's limited resources. If a company had infinite amounts of money to pay out then sure, pay everybody the same. Until then, I'll take my chances that on some level I'll have a shot being paid, at least in part, on the value I bring.
I'll also guess you've never been part of the sales process if you think that competition has little to do with corporate life.
> > > > > If a company truly believed in > > > collaboration, each developer would share common pay > > and > > > couldn't be laid off except as a unit. This might > sound > > > "extreme" but .. you get the idea. > > > > Heaven forbid people get compensated on something like > > 'merit' or 'the value they bring to the company'. I > know > > there are plenty of cases where this isn't the case in > the > > real world, but I'll take what we've got over making > the > > same amount as everybody else. That sounds more > > 'communist' than 'extreme'. Admitting that somebody > else > > might be right and you may be wrong seems well nigh > > impossible for some people. I fail to see how equal > > salaries will fix that. If anything, it will make it > worse > > because some schmuck will believe that he is 'just as > > right' as everybody else. He must be. He's getting the > > same pay! > > > Does anyone with a few years of experience under their > belt really believe that pay and performance go > hand-in-hand?
I've got about 13. As I said, in real life there are many times this isn't the case. I have had some experiences where pay and performance have gone hand in hand. Really. The notion that everybody getting paid the same is going to somehow magically solve this 'competitive problem' (I don't see it as a problem) doesn't make sense to me. And the thought of everybody getting paid the same just irks me. And I don't see what that has to do with collaboration. I have collaborated just fine with interns, peers and senior vice presidents. 'My paycheck is bigger than yours' never entered into the picture. I've never been part of a discussion that has ended with "I get paid more than you, so just shut up."
> It's not about convincing people that they > are the same, it's about creating an environment that > minimizes competitive behavior.
There is a lot beyond flattening pay scales that needs to be done to minimize competition. Having worked many years in market research, every study I've seen shows that among the factors that strongly influence job satisfaction, salary is very low on the list. Maybe I'm odd, but if I can see that somebody is bringing more value to the organization and I know he is getting paid more than me, I say good for him. I've not ever felt the need to compete with somebody based on the size of their paycheck. Maybe I'm just strange that way. From what I've seen, competitive behavior or the lack thereof is pretty hard wired into people. Either you are or you aren't. Life in generally has been rewarding organisms that compete successfully for millions of years now. I don't really see that changing any time soon. Personally I like competition. It makes me work harder. It usually teaches me something I didn't know. This doesn't mean you need to be an ass about it.
> Besides, unless your > company is providing a social service to train schmucks, > there isn't any value to pairing one with somebody > competent anyway.
At any company with more than say 45 people schmucks are going to start getting through the hiring process. It's inevitable. If they are willing to learn, then there is great value in pairing them with somebody competent.
And I think the whole 'laid off as a unit' idea is completely flawed BECAUSE every now and then somebody really awful gets hired. If a project is failing because of one person (I saw it happen once) then I believe getting rid of that one person is the thing to do. Having the project succeed with the problem person removed is, in my mind, much better than either firing everybody or having what could be an otherwise successful project fail.
Jeff, I was totally with you until your last paragraph.
> > > I still can't see the big usefulness of macros. > > > > That's not true. Lisp macros are a different sort of > > animal. The best I can do for an explanation that might > at > > least get you interested it so point you here > > > > http://www.paulgraham.com/avg.html > > > > In most cases you don't need macros and they are even > > generally frowned upon in lisp if used unnecessarily. > In > > lisp code and data are the same thing, so using runtime > > values is possible. > > > > None of this is an argument for putting macros in > python > > (I've never used macros in any of the lisp I've > written, > > but then I've never done anything 'interesting' in > lisp), > > but I don't think that lisp macros can be casually > > dismissed as the same thing as first class functions. > > Lisp is a different beast. The odd syntax and scoping of > Lisp makes it somewhat easier to write macros. Still I > don’t buy Paul’s assertion that you absolutely need > macros. In all examples I have seen on the Internet so far > you can replace macros with another style like functional > code or object orientation. It might not run as fast or be > as aesthetical pleasing to Paul as the macro paradigm, but > it is doable. I would love to see a short problem solved > in Lisp with macros and with functions side by side in > which the code using macros is significantly easier to > understand.
This brings us right back to the "well, you can do everything in assembly language" argument. And he didn't say that you absolutely need them. He said that they allow you to do things that are hard to do in any other language. He can't imagine working without them because they let him do some things that are hard in other languages.
I tend to feel the same way about a few things in python. Array slicing is the easiest one by far for me to point out. It is so damn nice to just cut an array apart with python's array slicing syntax that I really miss that in other languages. You can get the same results in almost every other language, but to me it's just so elegant to say something like myarray[:-1] to whack the last character off the end of a string, for example.
I don't think a short problem solved with macros vs functions is going to show the kind of advantage you get with lisp macros. It is similar to people declaring languages bad because they do not do recursive fibonacci number calculations efficiently. It's too simple of a problem to accurately make any meaningful decision.
If you are talking about macros like C macros then, yeah, those are pretty much universally abhorred. There are a very few cases where they are nice, but in general most people prefer using functions, objects, etc. but the blog entry specifically cites lisp macros, so that was my assumption that this is what you were talking about. Your 'lisp is a different beast' comment perhaps makes me think you were thinking otherwise?
Flat View: This topic has 21 replies
on 2 pages
[
12
|
»
]
Previous Topic
