Important Shock

This article reflects merely my own thoughts and opinions. I doubt it applies to you personally, so don’t think I’m proposing a new law.

Last night, as my LAN-party-attending friends and I drove home from the pizza place, I was asked to explain the concept of Turing-completeness. I managed to give a somewhat coherent overview of the topic without simultaneously befuddling my listeners, and gave examples of Turing-complete and non-complete languages. Listing off my favorite programming languages, all of which fell in the former category, I was struck by a realization, and drifted off into thought until awoken by the derision of my peers.

I appreciated the furor on reddit regarding my How to Beat Rails and Blocks != Functional Programming posts; debates between programmers are often informative and always entertaining. The contests between languages, though they rarely (if ever) change anyone’s mind, are fertile ground for inflammatory quotes and flame wars. But the realization I came to in the car yesterday was this - since almost all programming languages are Turing-complete, what’s the difference? At a fundamental level, they’re all the same, right?

Then why do I like Python and Ruby so much more than C or Java? Why, indeed, doesn’t everyone just write bare machine code? Am I wasting my time wondering about abstracts instead of actually coding? I pondered these questions through many hours of video games, and eventually came to a conclusion.

The largest factor in whether I like a language is its attitude towards “magical” behavior. “Magical” behavior is difficult to define - my best effort is ‘the ability to redefine the most fundamental aspects of the language’ - but here’s an example, taken straight from the perlvar man page:

$[
The index of the first element in an array, and of the first character in a substring. Default is 0, but you could theoretically set it to 1 to make Perl behave more like awk (or Fortran) when subscripting and when evaluating the index() and substr() functions.

Perl, which I loathe with every fiber of my being, condones - nay, encourages - the deep, evil, horrible black magic to find the quickest way around a problem. Ruby, which I like more and more with every passing day, allows for happy, Good-Witch-of-the-North-esque magic with metaprogramming, different eval() scopes and near-total introspection. Python, which I’ve loved since the seventh grade, really discourages the use of magic - custom infix operators are the extent to which Pythonistas have dabbled therein. However, it always tries to permit the clearest, most concise non-magical solution to a problem. Scheme, which I respect, isn’t so much a language as a wellspring of magic through which you can do whatever you want. In the right hands, it’s brilliant, and in the wrong ones impotent. Rails and Pylons reflect the different attitudes towards magic - Pylons requires you to render the templates explicitly, while Rails just evaluates instance variables and goes with the flow.

In summary, my preferred language depends on attitude towards magic - my favorite languages either allow for positive, as-readable-as-possible magic (Ruby) or disallow it altogether (Python.) Which is better? It depends on your situation - and on the necessity of good documentation. (Documentation, and therefore long-term maintainability, cannot coexist with magic.) Overall, though, I enjoy a little code magic - do you?

Let’s say you came up to me and said “Patrick, I want to start a Web 2.0 company. I have some great ideas, good web developers, a firm grip on the quagmire that is public relations; in short, I have everything except a web development framework. Which one would you recommend?”

My answer would be this: Though Turbogears is worse than Pylons, it is nonetheless the best web framework.

You would probably inquire what the hell I was talking about. Well, let me elucidate:

I believe that one of the reasons for the massive success of Ruby on Rails is David Heinemeier Hansson’s damn-the-torpedoes attitude towards Rails’s scope. DHH, being an extremely opinionated person, refuses to incorporate things he doesn’t like into his framework - but he incorporates everything he does like into it.

ORM? Check. Database migrations for aforementioned ORM? Check. Embed Ruby arbitrarily into your views? Check. Built-in script.aculo.us integration? Check. Single-minded, near-zombielike focus on unit testing? Check. A bunch of nifty code generators? Check. Regular-expression-powered routing system? Check. Vastly needed improvements to the Ruby language? Check. (Whether ActiveSupport should be incorporated into the main Ruby code base is another blog post. Sneak preview: Yes.)

The list goes on and on - in short, Rails has a bunch of functionality built in, but just as much functionality left out. There’s no easy system for template inheritance, no userauth system, no multithreading support. Rails is a monolith - don’t like the ORM? Too bad. Don’t like ERb? No one’s making you use Rails; go back to Perl::Mason. Don’t like feature X? Here’s what DHH has to say.

And many people love the fact that Rails is a full-stack framework, that they don’t have to juggle dependencies between templating systems and ORM’s, that they don’t need to worry that easy_install or gem will break everything. Rails has that market covered.

But true web framework nirvana comes from freedom of choice. I should be able to say OK, for this next web application I need a really powerful ORM - SQLAlchemy should be fine. I like Mako, let’s use that. Routes is nice, we’ll take it. Oh, and I want an authorization system, and I’ll whip up some slick Javascript widgets while I’m at it.

I’ve been spending time in the #pylons chat room, and I feel that the people working on Pylons are close to realizing that goal - that a web framework should come in parts, like Legos, and that you should just plug components into as minimal of a base as possible until you get exactly what you want. WSGI can allow us to build interchangable parts - at least I think so, as I’m still not 100% positive what WSGI actually is.

But Pylons, ToscaWidgets, Migrate, AuthKit, Mako - they’re all very young projects, still struggling under the scarlet letter ß for Beta. The pieces aren’t ready to be put together yet - like Legos, you can’t build elaborate structures with misshapen blocks.

Pylons is representative of the freedom of choice that I want. But it’s not ready. Turbogears has echoes of Rails in its inability to use anything for the controller except CherryPy, but on the whole, it allows you to make some choices as to ORM, templating system, and what have you. And even the incomplete measure of choice which Turbogears offers allows it to dominate over Rails for all but the simplest CRUD apps. Pylons should win on principle, but when companies and jobs hang in the balance you can’t entrust all you have to principle.

When Pylons and all its corresponding pieces are ready, it will be a sight to behold. Until then, use Turbogears.

(Note: I really, really like Ruby and Rails. Anything disparaging that I say about either of them should be taken with several grains of salt. If I seem to be encouraging Pythoneers to crush Rails, it’s simply because I love both, and want all frameworks to be constantly innovating.)

Everybody with the slightest interest in web development has heard of Ruby on Rails. It thrust Ruby into the spotlight, created a hype machine that stubbornly refuses to go away, and made David Heinemeier Hansson a celebrity. I adore Rails - it’s by far the best web framework for simple CRUD apps. However, as a Python devotee, it hurt me deeply to see Ruby stealing the spotlight. As such, I embarked on a quest to find out why Rails is winning; I looked at Django, Turbogears, Pylons and web.py. After months of building the same simple CRUD app, I came to the following conclusion:

Python can beat Rails. It can grind it into a pulp in every way concievable - speed, elegance, coolness, extensiblity, organization, AJAXness, beauty, and flexibility. It can send Rails crying home to David while Guido basks in the Web 2.0 spotlight. But right now, Rails is thoroughly torching all of the Python web frameworks. The following is a list of recommendations that, if applied to a Python framework, could dislodge Rails from the position of King of the Web Frameworks.

(more…)

(Disclaimer: Python is my favorite programming language; however, I do criticize it in this article. Please redirect flames to /dev/null.)

I’ve been comparing web frameworks lately, developing a relatively simple CRUD database-backed application that can support a few bells and whistles. I’ve checked out Ruby on Rails (who hasn’t?) Django, and Turbogears in my search, and realized something as I was hacking together some templates in Kid:

Python, a far more restrictive and inflexible language - one that would seem, on the surface, to be worse for web application development than Ruby - is better for programmers, designers and security by nature of its inflexibility.

Let me explain what I mean. When designing ‘views’ - the web pages that users will see - that need to be updated with data from a given database, it is natural to break the Model-View-Controller paradigm and embed some controller logic into the application. After all, it’s so much less effort to embed

<% found_books = Book.find_all(”title = ?”, given_title) %>

into your .rhtml files then to go back into the controller file, change the return types, and make sure everything works correctly. However, Python is whitespace-sensitive, and therefore is much more difficult to embed into HTML. As such, you can’t write the mixture of Ruby and HTML that makes Rails so easy to use.

This is a good thing. I am a strong advocate of separating the model, view, and controller; by the very fact that I can’t write a combination of Python and HTML, I am forced to go back into the CherryPy/Django controller codebase and write a properly formed, secure, and elegant SQL query. Normally laxity wouldn’t bother me, but I believe that any large web application will grow into a hideous, Nylartothepic tangle if the MVC rules are not followed to the letter.

I still love Rails, but I love the templating systems in Python even more. Because Python is so restrictive, people had to write templating systems the Right Way - and that’s a good thing for everybody.