Summary
A response to Guido's discussion about marketing Python, and some observations about the issues that have come up.

Guido's discussion is here.

I feel like I've been neglecting Python while working on the fourth edition of the Java book (and didn't make it to Pycon this year). But under the covers, I write all my tools in Python.

After a lot of initial resistance, I finally decided that Ruby was interesting, and I will continue to learn things about it from time to time, but at this point it's just because I find that learning new languages help me with the ones I use on a day-to-day basis. But the hurdle to actually writing a tool in Ruby is still too big; I just don't have the incentive yet comparied to my positively-productive experiences in Python.

Someone in the discussion said that it should be about frameworks, and I would argue that it should be more generally about libraries. I've never forgotten one of the comments that Bjarne Stroustrup made in a very early C++ Standards Committee meeting (I think), to the effect that the goal of OO programming is to make library use easier. I think C++ did that, in comparison to C, and yet the creation of libraries was still hard, which meant that the number of C++ libraries grew relatively slowly. I think the further development of OO languages has been in the direction of making both the use and the creation of libraries easier (which is why Java generics is not such a big step forward). In general, Python does this (although not completely trivially; I've never had the patience to figure out the whole __init__.py thingy), and as a result we've seen lots of libraries -- and to my mind most importantly, lots of standard libraries in the distribution (perhaps CheeseShop will change this distinction).

As far as the RoR/Django/TurboGears issue, I think that it would be even more interesting to move up a level of abstraction and try to figure out what problem we're really trying to solve here. In broad terms, I think that EJBs, and to some degree Zope, are examples of big systems that do everything, and in the case of EJB1 & 2, were designed for the wrong consumers of the technology (which in the case of EJBs, didn't exist). So RoR comes along at the other extreme and makes the case that most of the time, web sites are "babysitting databases," so why not make that really easy.

In design patterns, we try to "encapsulate change." So the interesting question here is "what changes?" I think that it's more than just "babysitting databases," but over time the issue of databases has grown more and more prevalent in programming, to the point where, instead of writing specialized languages that just solve database problems, we're starting to see mainstream languages (like C# 3.0) incorporate support for databases directly in the language.

I think the big-picture Pythonic solution will not be to simply create a better RoR, or to only solve the web-programming problem (although that should be one of the goals). I think we need to take a look at databases in general and to find a better way of solving the database problem within Python, in such a way that the database support for a web system falls out naturally, but also in a way that data storage and retrieval becomes a natural thing to do in all Python programs.

This might be something inspired by the way annotations are used in EJB3, which (at least at first glance) does seem simple and elegant, and holds out the hope that EJBs are not a lost cause (although you could certainly argue that EJB3 bears almost no resemblence to EJB1 & 2, and so the reuse of the EBJ name is just a marketing ploy). I think the important direction here is not to try to create an OO database, because it doesn't seem that OO databases have ever been particularly successful, but instead to acknowledge that relational databases are a good (and possibly necessary) solution to the database problem, and what we need is something that makes straightforward usage of relational databases easy, and more complex uses possible. I think that with this problem solved, then solutions that require databases (including web-based solutions) will fall out naturally.

Just my current thought-stream; I'd be interested in hearing ideas from others.

Talk Back!

Have an opinion? Readers have already posted 17 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Bruce Eckel adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Bruce Eckel (www.BruceEckel.com) provides development assistance in Python with user interfaces in Flex. He is the author of Thinking in Java (Prentice-Hall, 1998, 2nd Edition, 2000, 3rd Edition, 2003, 4th Edition, 2005), the Hands-On Java Seminar CD ROM (available on the Web site), Thinking in C++ (PH 1995; 2nd edition 2000, Volume 2 with Chuck Allison, 2003), C++ Inside & Out (Osborne/McGraw-Hill 1993), among others. He's given hundreds of presentations throughout the world, published over 150 articles in numerous magazines, was a founding member of the ANSI/ISO C++ committee and speaks regularly at conferences.