Oct22006

Alternatives to Python

Filed under: python boo logix 

Lately I've been keeping my eye on alternatives to Python. I've gotten tired of waiting for features in Python that, to put it in GvR's words "ain't gonna happen". Most of these features aren't strictly essential to day-to-day programming, and the lack of them doesn't make Python a bad language, but they are features that give that warm feeling known as "elegance".

What are these features? A very short list (for me) includes:

  1. Expression-based syntax
  2. Closures
  3. Macros (Lisp-style, not C-style)

To be honest, I'd settle for #1, but if I'm looking for an alternative, I may as well look for all three.

You might be wondering why Ruby isn't an option, since it supports at least the first two items and it currently has a thriving community (which is always good to have around a language you plan to use for more than hobbies). Ruby has two major drawbacks to me: first of all the performance is absolutely dismal. Until Ruby has a bytecode compiler or leverages an existing VM such as .NET/Mono, this is unlikely to change (I know work is being done here, but I'm not holding my breath. By the time a Ruby 1.x VM is done, Ruby 2.x may well be released, which would seem be a setback for one or the other). The second reason is I simply don't like the look of Ruby code. Too much syntax. This is more critical than even the performance issues. The performance issues will certainly be fixed at some point, but the language isn't likely to change much cosmetically (lest it become a different language). While Ruby may have the heart of Smalltalk, it has the face of Perl. I may like the ugly girl with the heart of gold, but I'm not going to marry her, thanks.

Anyway, I'm not bashing Ruby here, for all of you who are going to get upset about it. I think Ruby embodies some great ideas that have been languishing in the programming world. The deaths of Smalltalk and Lisp pretty much set the programming world back 20 years, IMO, and the fact that Ruby has brought back to life many of the fundamental concepts embodied in those languages is deeply appreciated. Ruby just isn't for me.

Anyway, I'm old and lazy these days, so whenever I see a new language with a syntax I'm readily familiar with, I perk up. Two languages currently sit on my radar as candidates, Boo and Logix (see bottom of article for references).

Of the two, Logix is the most appealing. Logix isn't so much a language as a metalanguage, with a Python-like syntax definition. It also runs on the Python VM and is, in fact, implemented as a Python module that you import into the Python interpreter. This means you can use the Python standard library which is a big win. It meets every requirement I've outlined above (and then some). My major concern with it is that it appears to be dead or at least stagnating and never appeared to have a community to start with. It's so great, I've considered opening a Trac and trying to jump-start a community, but I doubt my own ability to take the lead on development (language design isn't my area of expertise).

The second language I've recently discovered is Boo. I saw the announcement for Boo on c.l.py a couple years ago where it was met with some bit of scorn by the Python community, but recently I stumbled across it again and see that it's grown into a real project in the interim. Boo isn't as easy a jump as Logix (it's a completely new language, with a Python-like syntax, but some major incompatibilities). Also, it runs on .NET/Mono, not the Python VM. I don't consider this a bad thing, but that VM isn't quite as stable as the Python VM on Linux, at least in my experience. Of course, Boo hasn't hit 1.0 yet, so I expect that by the time it does, the CLR will be production-ready across platforms.

Update: Boo also scores major points for having an MVC web framework called Webbness. Documentation looks pretty thin, but it's a start. I'm guessing (but don't know) that Logix could work with some existing Python framework such as Pylons or TurboGears. That remains to be tested.



0 comments Leave a comment


Jul272006

Expressions vs Statements in Python

Filed under: python logix 

Something has been eating at me for a while. There is a fundamental inconsistency in Python, something that has kept me from writing code how I'd like to write it, but I haven't been able to put my finger on it.

I think I finally have.When I first saw anonymous code blocks in Ruby, I thought "aha, that's it", and I was close. But really anonymous blocks aren't it. They just remind me of it. In fact they are a special case of "it". "It" happens to be expressions. Python makes a distinction between statements and expressions and because my background has been with procedural languages (Pascal, C), this distinction seemed natural. But Python's flexibility hints at something more, something that it has not quite provided but I couldn't describe. I liked the presence of functional tools in Python (map, filter, reduce, list comprehensions, etc), but bemoaned lambda's crippled self. I wanted a ternary operator. I've finally realized these things are all just ways of using statements as expressions, and I've also realized that statements really could be expressions, except that they are intentionally crippled in Python.

As anyone who reads this blog knows, I've been doing lots of work with Stan. Stan is an s-expression style DSL for generating XHTML from Python. I decided early on when creating the TurboStan plugin for TurboGears that I would keep Stan templates as pure expressions, even though I realized this would reduce their power to some extent. My feeling was that too much code in the template was wrong. I still feel that way. However, I don't feel that way about my program itself. I feel the language I use should not restrict me in fundamental ways. Many problem domains lend themselves to a functional style of programming and not having language support for that idiom can be painful. I do acknowledge that functional programs can be more difficult to take in at first glance, but they also tend to be more elegant when properly applied. The same argument can be made about many other concepts, such as recursion. Until you are familiar with the concept, recursive code can be like looking into a hall of mirrors. That certainly isn't a reason to not support it in a language. I don't think anyone would take a language seriously that didn't support recursion. Or object-orientation, for that matter. So why does functional-style programming have such a bad rap with the Python devs?

I admire Phillip Eby's work and find his articles thoughtful, so I emailed him about it (he probably thinks I'm a stalker). Anyway he suggested that having statements as expressions leads to nested code and flat is better than nested. This may be true. However so does nested functions and classes. Further, just because something can be abused doesn't mean it's necessary to ban it from the language, especially if having it easily doubles the expressive power of the language itself. Many hacks that have been added to the Python syntax to support special cases of functional programming would no longer be necessary. The syntax itself would be more self-consistent. I certainly don't find Lisp to be an attractive language visually, but I do find the concept it embodies quite elegant and tempting.

In short, I think Python needs to dump the artificial distinction between statements and expressions.

In the meantime, Phillip was kind enough to point me to Logix, which is more or less exactly what I'm asking for. It even generates Python bytecode.

So provided I'm able to actually leverage Logix for use in my day-to-day work, it may be goodbye Python (sort of) and hello, Logix.



0 comments Leave a comment


Copyright © 2007, Cliff Wells