Thinking Webapps out loud (Part 1: ¿Se Habla?)

Posted by Antonio 3 years ago (Aug. 28, 2005)

I've spent the last couple of months thinking about web development platforms (due to a project that I will soon be able to talk about here) and apparently so have other people.

The debates have ranged from thinking about the nature of the languages, to thinking about the points for modularization of functionality (the libraries versus frameworks question) to the value of the community in helping get the tedious stuff out of the way. In this post, I want to focus on the language part of my thinking; in future posts I will move up the stack to consider libraries, frameworks, and communities.

A long time fan of Paul Graham, I naturally started by focusing on the importance of the language in terms of productivity. This answers the whole Java/P-languages question on the side of the P languages (Perl, PHP, Python & Ruby). In my experience, dynamically-typed wins every time. In fact, it's funny how many Java web projects I've been involved with that end up supporting dynamic language semantics via internal Hashtables and some sort of "meta-method" call system. That said, here is the caveat: I have never worked (and hope never to have to work) on an engineering team that is bigger than 12 people but I could imagine how the formalism of Java/C# helps when the problems of coordination become more significant the problem the code is actually trying to solve.

The more interesting question to me over the last two months has been: once you know the P-path is the way to go, how to pick? And here is my conclusion: among the P-languages (Python, Ruby, PHP, and Perl), there is only one relevant distinction, designed languages versus evolved hacks with Python and Ruby in the designed camp and Perl and PHP in the hacked camp. I'm not going to go into this distinction in detail as whole religious wars are being fought over this right now on IRC. I will just say that OOP seems like a hack in Perl and a crazy global namespace with several different ways to parse a string seems like an even bigger hack in PHP. Both languages have strong advocates that are Very Bright Folks. These people have valiantly tried to smooth over some of the major issues in Perl and PHP but at the end of the day you can only polish coal so much and I am often left wondering how much further Python or Ruby could be if these Very Bright Folks had spent their efforts there.

Among the designed languages (by which I mean someone with a good sense for computer languages drove the core of the design early on), I think things boil down to maturity of the runtime and taste. Python beats Ruby on the former and in my opinion it beats it on the latter as well. Python's runtime seems to have received more attention: it has been implemented 3-4 times (CPython, Jython, IronPython and PyPy), there has been more solid debate about implementation internals, and CPython appears to release often with about 10-15% speed bumps every time. And more importantly, it has bytecodes! Ruby's running straight off the AST worries me, not because I am some sort of VM purist but because it seems like this sets a natural limit for the optimization of the runtime (and yes I know that Rite will move us to a bytecode-based runtime but I have to wonder how long this will take to get to the mainstream).

On the taste side, I dislike the @:@@# littering Ruby code and the parentheses-for-method-calls-as-optional and I haven't yet seen why I should go ga-ga over Ruby blocks, but I am willing to admit that is just me and that I need more deep experience with Ruby to really be conclusive here.

The thing that is clear however is that both Python are more alike than different at their core. They offer the same built-in types, they are both extremely dynamic, their C-based runtimes are relatively easy to understand, and their C-extension mechanisms are pretty clean. Which means that despite my slight preference for Python, once you've crossed the bridge to the P-world, the web application development question has to be answered higher up the stack.

Update: A fabulous piece on closures Ruby and Python. The best argument and link list I've seen yet.

Tags:

Comments

Post a comment

(Please use only plain text. Though I will escape all of your HTML, URLs will be clickable)

Your name:

Comment: