Ian Bicking: the old part of his blog

Ruby Meetup

I went to a Ruby Meetup the other day, where DHH attended. I didn't talk a whole lot (at least, I don't think I did); I'm a Python programmer, and I didn't want to intrude, so I mostly listened.

If anything, I came away feeling even more that Ruby and Python are alike. Not just at the language level, but at the community level as well -- especially when you take away the syntax and other particulars (and people talk with neither begin and end, nor significant whitespace, so all those particulars are gone in conversation).

David had actually read my last post on Rails and we talked about it a little. One thing he cleared up for me is that templates and helpers are not mixed into the controller, so helpers aren't a way of creating private methods, but a way of giving templates access to code. The confusing part, for me, is that Rails copies all the instance variables from the controller over to the template, so the template appears to be the same object as the controller, even if it isn't.

Another thing that people talked about a lot of Ajax (DHTML), which everyone was very excited about. During their discussion of Ajax, one advantage of their "partials" (HTML reuse by composing multipe templates/files) is that these same bits of partial content are used heavily for the Ajax portions -- a typical Ajax request in Rails sends something to the server, and the server rerenders the content of a <div> and sends it back. So in many cases the partial is rendered in isolation and delivered in isolation (then put in place by assigning to innerHTML). I still think it's an unpleasant way to reuse HTML, but this unexpected benefit might change that. I guess it's a move towards page-as-widgets, which has never attracted me before, but Ajax does really change that.

My ASP comparison came up again. Anyway, in that case he explained that he didn't want people to think that Rails had an execution model like ASP, where the URL points to a template, and so forth. I just meant ASP in terms of template syntax, to clarify.

And lastly, on the Rails topic, there's a a complaint I forgot last time ;)

This code from the to-do tutorial shocked and surprised me:

if item.save  # Try to save our item into the database
  redirect_to(:action => "list")  # Return to the list page if it suceeds
else
  render_text "Couldn't add new item"  # Print an error message otherwise
end

I've just been dealing with some Perl CGI code, and one of the things that drives me nuts is how the code -- not horrible code, mind you -- just ignores all sorts of errors (usually causing things to fail at a later point in time). If something isn't successful raise an exception. The only time not to do this is if the function has no side effect and has indication of success/failure as its sole purpose. This does not describe a database save.

Anyway, that's all on that.

Ultimately I'm left unsatisfied. Like all occassions in the past when I've looked at Ruby, I'm left feeling mystified. There's room for multiple languages, but Ruby and Python are so similar, and only seem to become more similar with time. Not just technically, but culturally as well. Sometimes I think people have choosen Ruby because it is less popular, because green field work is more exciting, because they can have a larger influence on the community. I wish them well... but now that they are putting up a real fight for mindshare I at least plan to meet them head-to-head, and leverage all of Python's strength that I can. I don't see any reason to snipe Rails users -- you could do a lot worse than Rails, and that's not a group ripe for conversion -- but I won't let them define themselves as the Next Big Thing in web programming without a fight.

Well, that's a good segway... so, the topic of Rails clones came up at the meetup. David felt that the clones weren't taking the right approach by using pre-existing components, as Subway and Trails are, that they should have rewritten things from the ground up. Of course, this really would put them on level ground with Rails (except a year behind), which is why the authors chose not to do that. People seemed skeptical that anyone could achieve what Rails achieved without total integration and design (and redesign) of multiple components in concert. (For Pythonistas -- we're not talking Zope-2-like integration here, since Rails is heavy on testability which discourages explicit coupling.)

Personally I don't buy that, but I'll let you all think about that on your own.

Created 27 Apr '05

Comments:

I've been playing with Ruby (and Rails) a fair bit over the past couple of months, and one thing that took me a while to understand was the importance of being able to leave out parentheses on method calls. Initially, I found that ability pretty disgusting (I imagine in the same way that people new to Python are put off by the forced indentation) but I've begun to realise that it's one of the key features in making Rails so pleasant to use. The loose syntax actively encourages the creation of domain specific mini-languages, which is exactly what Rails is when you come down to it. It may seem like a small thing, but it's the small things that make all the difference.

I'm not saying Python should introduce this kind of loose syntax - in fact I'd argue against it, as one of Python's main strengths is its clarity and uniformity. It does make for a very interesting aspect of Ruby as a language though.

# Simon Willison

simon says "The loose syntax actively encourages the creation of domain specific mini-languages"

I think this is one of the problems that makes reading Rails source code hard for me. Variables appear magically with no indication of where they are from, as if they were just another keyword. I'm easily lost without the use of explicit namespaces and imports that Python provides. All of the RoR code I've looked at doesn't do this, and it seems unpleasant to use. There's no accounting for taste though...

# John P. Speno

I think Ruby's calling syntax makes the distinction between variables and methods much more casual. Of course, that goes as far as having no public instance variables, just methods, but it looks the same as methods anyway. The equivalent in Python is actually less explicit, because the name embodies the privacy (leading underscores) and it tends to be casual what is public and what is not. You can always fix things up later with property, but I seldom do that.

# Ian Bicking

# Todd G

Good write-up, Ian. I'll attempt to address some of the points raised in a later blog posting. Regarding item.save, I have a longer rant prepared on whether or not to raise an exception in the case of Base#save, which will actually appear in the forthcoming book on Rails, but for now I'll leave you with the fact that if you do item.save! an exception will indeed be raised on error.

# David Heinemeier Hansson

I believe that the success of Rails is ultimately a success in marketing. DHH presented rails to the ruby community delicately (I was following the ruby mailing lists in fall 2003). His website, the Rails site and most of his language have a level of polish that has sold the project to the point that it has taken on a life of it's own.

If you really want Paste to compete I think you need to spend a bunch of energy on marketing. Pay a designer to develop a nifty logo/template, etc.

ch

# culley

I thinks its the combination of success in marketing and the technical excellence to back it up. If it were simply good marketing hype, no one would stick around after their first look.

# Curt Hibbs

There are plenty of web frameworks with a high degree of technical excellence. Sadly, it is the marketing that pushes an excellent framework to achieve social success.

# culley

Um, BetaMax?

# Todd G

I have the impression that one aspect of RoR success is that it manages because of its evolution/history and presentation to appeal and capture designer (in the broad sense of interaction designers etc) mindshare, not only programmers'. This discussion seem also relevant: http://radar.oreilly.com/archives/2005/04/designing_from.html

# anonymous

I don't really see how you can fight them (as the next Big Thing in Web Development).

How many books have there been on Python web frameworks? None

They already have several almost done and published, with a few more in active development. Look around on a bookshelf, and the competition you'd see isn't in Python Frameworks. For reference sake, the Perl folk have had a few books written about different Perl templating languages (Mason, Template Toolkit). Where are the Python web framework books, is anyone working on one?

Books do help! Especially for getting new developers interested.

How much money is used to fund Python Web frameworks?

Each person going with TextDrive for their Rails hosting is inadvertantly funding more Rails development. Look at the amount of contributions and code patches sent in, its a pretty decent number. Take a cruise through the Rails wiki and community section, there's a decent amount of people contributing advice and documentation.

Even if every developer responsible for all the myriad Python Web frameworks came together behind one, that'd only match or slightly exceed the amount of development Rails has going on. We all know there's no chance of that, given some of the massive differences in personality between some of the developers and design paths chosen for the various Python web frameworks.

The real question we (Python programmers) need to be asking ourselves in regard to Rails is, Do we want to compete with Rails?

I personally don't see why we should, not to mention I don't think its possible anyways. Rails is not all hype. It's getting a lot of well deserved attention for what it does. What it does, is make writing mainly single-purpose web applications (Project manager, to-do list apps seem popular) quite easy. Only time will tell whether it can quickly evolve to meet various simultaneous application requirements.

What I mean by this is, if you build a large-scale corporate website with Rails, and then Sales/Marketing declares that entire sections have to perform in drastically different ways, can you quickly and easily cope with this request? How well does Rails cope with sudden, unexpected design changes? How much of the Rails framework is built solidly into the expectation that your requirements are clearly defined in advance? (As I'm guessing the designers of BaseCamp did)

To summarize this, Rails does well what its meant to do, it has a well deserved hype going for it which I think is great. It doesn't make sense to compete. If we want a Python web framework to get as much attention, it needs to satisfy a large enough niche that is currently not filled or lacking, with enough developers supporting it.

# Ben Bangert

How many books have there been on Python web frameworks? None

Well, that's just not true. There's probably a dozen Zope books, two (?) on Zope 3, and a couple on Plone. And there's two general Python web programming books.

Even if every developer responsible for all the myriad Python Web frameworks came together behind one, that'd only match or slightly exceed the amount of development Rails has going on. We all know there's no chance of that, given some of the massive differences in personality between some of the developers and design paths chosen for the various Python web frameworks.

That's not true either. There's a large number of quiet Python web programmers out there. There's a large number of in-house frameworks... I think in-house frameworks might have as much share of Python programmers as the open/public frameworks. Well, not counting Zope, which is large as either group, and larger than Rails.

But I'm not saying we need to compete head-to-head with Rails. Still, we don't need to concede territory to them yet. They are not that big. I don't mind using Rails to put a little scare into Python developers to get our shit in order, but I think it's wrong to buy into Rails' hype too much.

# Ian Bicking

Ah yes, good catch there. I completely forgot about Zope again, which is humorous for me as we're running a production Plone site here for a small business so I have several of those Plone and Zope books lying around.

I agree completely with the large amount of quiet programmers. When I used Mason extensively, while the user-base was very large there didn't seem to be much hype even though it was used extensively within several large companies. The Mason Wiki is also relatively small and bare compared with the Rails wiki. Very reflective of a large, but quiet developer community (They do talk quite a bit on the Mason mailing lists though).

So with Python Paste and other such systems, are we aiming to convert Zope developers/programmers to unite around a different web framework? They have such a time investment in the system, plus Zope 3 makes some nice advances, I'm not sure I see them ready to move off it to lend support to a different Python Web framework.

When you say "get our shit in order" what do you mean?

# Ben Bangert

Very reflective of a large, but quiet developer community

I'd say this is a cultural problem, but not an insurmountable one. One aspect of Rails is that it excites people. Excitement has a lot to do with interpretation. Getting your job done well and on time is not exciting. But it could be exciting, if you phrase it differently; and that's what Rails has done. Sharing can be exciting, and experimentation and playfulness. Important things to think about.

So with Python Paste and other such systems, are we aiming to convert Zope developers/programmers to unite around a different web framework?

No, I don't think it makes sense to focus on converting current Python web programmers. Paste isn't intended to convert anyone to a particular framework, as it isn't a framework and is intended to encompass several frameworks. Potentially any framework. Once Zope goes WSGI (which is in the works) it could run Zope too (though I suspect it won't attract that crowd as much, as they already have their own custom infrastructure to match Paste). I want to make the experience better for people who aren't doing Python web programming; both web programmers who aren't using Python, and Python programmers who aren't using the web.

When you say "get our shit in order" what do you mean?

Being able to answer the question "so how do I do web programming in Python" easily. Being able to provide robust infrastructure. Being able to write documentation that is both complete and concise (which simply isn't possible if the underlying code doesn't allow for that). All the boring stupid stuff that needs to be done to make working apps, but isn't exciting.

# Ian Bicking

Ok, I'm not sure how Paste will meet any of the goals you seem to desire. (This is assuming I'm understanding Paste correctly, as the comments on your blog have demonstrated its exceptionally difficult to explain Paste to other web developers, so how one could explain it to a new person....)

First, you want Paste to encompass other frameworks, however I'm not sure how thats possible. From several of the frameworks I've looked at, they work in such a different environment that I don't see how they can be modified to fit into Paste without destroying what makes them unique and valuable to their creators.

As one example, when I was reading over Paste, it seems to have its own Resolver in it, that then dispatches to Webware or a different framework. Myghty has a very powerful resolver methodology that we wouldn't want interrupted or pre-empted. I'm sure many other frameworks have a lot of parts to them that their developer doesn't want stepped on by some sort of "universal" meta-framework.

Being able to answer the question "so how do I do web programming in Python" easily

If we take Paste to what I see as your desired conclusion, ie, you download Paste, hit a command, and have an app ready to go with the framework of your choice (assuming there's a half dozen or two frameworks ppl have integrated). How does that make it easy? Sure, installing it was easy, but now what? How do you choose what framework to set your app to? How does that help documentation? There's still a dozen different frameworks, written by a dozen or more different people, documented by a dozen or more people, etc.

How easy would Rails be if once you had it installed, you had to choose from a dozen different framework paradigms?

As I'm working actively with Myghty and web development, I'd love to see it included in Paste. But why spend time developing that out if its easier and quicker to do what Paste provides myself?

For example, I'm currently writing up a little script, that when run lays out a basic directory template with some defaults setup for Myghty. It's fairly simple, and the directories it lays out are pretty conventional for a MVC webapp. With a single command, I can run the Myghty app standalone and play with it locally, however it also has a CGI, WSGI, and mod_python set of scripts allowing it to easily be used in any of those environments with no modification.

The module component I'm writing for use with this layout will be flexible enough to call methods (actions from the Rails-jargon world) based on URL if desired, or any other scheme. Myghty has a Path Translate function that works as an internal redirect of sorts, sort of like Rail's routing mechanism, I have Module Components? to handle mapping to controllers, and the Myghty template language to handle the view.

In the earlier Ruby post, some of the responses were wondering how Myghty is a framework vs template language, maybe that helps some?

Anyways, with one simple command, a small set of directories will be laid out, ready to run, with an easy to configure set of mapping rules to controllers and methods. It will also deal with a bunch of your complaints about Ruby's implicitness by relying more on Python's explicit nature (ie, you pass the arguments to templates rather than having them all copied, the URL can map to components and methods in whatever method desired, things aren't passed-by-name everywhere).

Add a dozen different frameworks, and its Paste, no?


Just wanted to clarify my prior comment as it might come off "flame-ish". My main intention was not to insult Paste or claim Myghty was the way. It was focused merely on realistic goals given the developers working on various projects.

As far as I know, Ian is the sole person working on SQLObject and FormEncode. I really really dig SQLObject and use it extensively, and I'm starting to use what I can from FormEncode to as its a really killer way to verify/coerce forms. Paste is yet another project that Ian's tackling. How many projects can you work on at once before some of them start lapsing?

The goal of my prior comment was, is Paste the solution? Will being able to easily install a dozen or two frameworks help a new web developer? How will the documentation be collected in one location and made uniform? Will Paste come with bundled frameworks, or will the framework maintainer be able to push framework updates down independently of Paste?

I'm sorry about the tone my other comment.

That's it. I'll shut up now. :)


As far as I know, Ian is the sole person working on SQLObject and FormEncode.

Actually, I've been lapsing on SQLObject work, but thankfully Oleg has been doing a good job maintaining it, and there's a group of people answering questions about it and submitting patches. So it's working out fine. There's been other significant contributions to FormEncode, and I'm hoping by keeping its scope very limited and clearly defined that it will also be able to exist on its own at some point, maybe even reach "maturity". And while Paste represents a particular vision of mine, I hope to bring other developers and visions into it; I know it's not easy getting an open source project to the point where it really is a collaborative project, but it's possible and something I think about quite a bit as I develop these things.


Paste is still a work in process, so its advantages aren't extreme. You can reimplement its functionality for your framework, and it wouldn't be that hard. It's also quite easy to use Paste with your framework, so I honestly don't know that it's easier to do things on your own, even if you factor in the getting-to-know-you time (at least if you are planning to support WSGI at all). Peter Hunt said it took him about 4 hours to convert Subway to Paste; I haven't seen the details of his code yet, but I think that includes some degree of integrating setup scripts and other pieces.

As one example, when I was reading over Paste, it seems to have its own Resolver in it, that then dispatches to Webware or a different framework.

It is definitely not expected that all frameworks will share a resolver. paste.urlparser does file-based parsing as WSGI middleware, but you could implement other strategies as middleware, or just provide a single entry point and do it internally. That's how initial Quixote support will work -- it'll use their Publisher without modification, and maybe in the future that can become middleware. I think it's reasonable to expect framework support to start as a monolithic integration -- a single entry point and everything after is internal to the framework. Later pieces can be factored out, or replaced with existing Paste functionality. This is the way that WSGI middleware can make a framework melt away. But it's incremental, and I'm as dedicated to backward compatibility as you probably are, so the buy-in required is gentle.

If we take Paste to what I see as your desired conclusion, ie, you download Paste, hit a command, and have an app ready to go with the framework of your choice (assuming there's a half dozen or two frameworks ppl have integrated). How does that make it easy?

That sounds easy to me. Really, I tried the framework comparison thing, and it was really hard because of installation. Not because I couldn't figure out the difference between the frameworks quickly. It doesn't mean there's no work to do for the framework authors, but they can focus on making their frameworks compelling instead of robust or easy to install.

How easy would Rails be if once you had it installed, you had to choose from a dozen different framework paradigms?

Paste isn't Rails, at all. There's a couple ideas I'm taking, but only a couple. Like maybe two. They have very different scopes and purposes.

[description of new Myghty features...] Add a dozen different frameworks, and its Paste, no?

Paste without the reuse, sharing, or community. I think that's a big difference.


I really wonder why Aquarium is AFAIK never being mentioned as Python alternative to Rails. It is very Pythonic, uses all Cheetah goodies, doesn't dictates how the Model must be programmed but has clear conventions for View and Conroller, and it has just enough "magic" for an easy start :-)

# Ksenia

Some thoughts: pretty bare-bones website, minimal docs ("docs" being more than API). And using literate programming ideas for docs is basically telling people who want to RTFM to just read all the source code to figure out how it works. Most people don't find that an attractive way to learn something.

Also, with "never being mentioned", who should be mentioning it? It's up to the project and its users to make some noise! Everyone bitches about the Rails people making too much noise and (sometimes un)justified hype but then laments all the attention it's getting. They (DHH mostly) didn't just sit back and wait for attention. He went and got it. For better and/or worse.

I personally found 'Aquarium' a very fitting name, as it struck me as the code equivalent of a real one - a container with all different kinds of things floating around all over the place in it. Clearly I've some more source code to read...

# ToddG

You answer your own question....

"doesn't dictates how the Model must be programmed"....Rails wouldn't be much without ActiveRecord.

# Huy

Ian, you should look at PSE: http://nick.borko.org/pse

Also, the images on your HTML comment editor are broken.

# Ken Kinder

In this small thread: Subway, Paste, Zope, Myghty, Aquarium, PSE!!! We need to clone GvR and have a webBDFL ...

# Pedro Lima

I'm just starting to look at Ruby. It's the performance of Python that's driving my to look at other things. Code that runs on Perl (without much optimization), can take 5X longer in Python (with optimization). The whole immutable object thing makes Python spend all its time creating and destroying objects.

Python has always downplayed performance, but ultimately it limits how far it scales. You can create a hybrid system with C/C++, but that loses all the portability advantages.

Ruby appears to have performance closer to Perl, with the elegance of Python.

# Dan C