Andy Chase

I've managed to use *nix-based operating systems for three and a half years without taking a written stand in the never-ending Vi versus Emacs flamewar, but having just been forced to use Vi to edit a crontab, I would like to go on record as saying that in the 21+ years that I have been using computers, I have never had such an instantaneous, overwhelmingly negative reaction to any other piece of software. I simply can't stand it, and it angers me when I'm forced to use it.

It was true the first time I tried Vi when getting into Linux in late 2000, and it's still true almost four years later. Using Vi makes me want to hit something. Why can't I just move the cursor, enter some text, or delete a few characters just like I can with pretty much every other editor written in recent memory?

Well, I know there are well-established historical reasons for Vi's infuriating separation of command mode and insert mode, but that doesn't make them any more tolerable for me. I'll also be the first person to admit that Emacs' key-bindings are arguably just as obtuse as Vi's editing model, but at least in Emacs you can open up a document, move the cursor and insert/delete text pretty much as you'd expect.

I don't buy the classic rebuttal that "People who hate Vi just can't be bothered to spend a few hours learning it," either. I don't care if Vi has a small memory footprint, or how fast it is, or how powerful it is once you stop being a wuss and pretend to enjoy incessantly jumping between command and insert modes. I think this quote from 6 years ago sums up my feelings best:

I thought it was the stupidest, most perverse and irritating thing imaginable. I couldn't believe that people sat down to write a text editor and came up with this.

Building on yesterday's experiment with oblique origamic architecture, I tried using a grid whose vertical lines radiate from the same origin as the horizontal lines: (The Illustrator 10 "Polar Grid" tool is very handy for this)

The radial lines do compensate for the distortion caused by the angled horizontals, which makes the end result much more subtle... at first glance you might even assume the above design is a standard 90 degree card photographed with a very wide lens.

(Again, pardon the floppy paper, mangled folds and rough cuts - this is a proof of concept model)

I'm currently trying to familiarize myself with Zope as a tool for building and managing web applications.

Zope is not, as is commonly misstated, "a programming language like ColdFusion", nor is it "like PHPNuke written in Python". It's rather more complicated that that - the best way I can think to describe it is "A self-contained, web-based application for building other applications which includes the ability to do embedded scripting like ColdFusion or PHP, which in turn allows you to build things like, but not limited to, PHPNuke."

I first heard of Zope a good two years ago, and after reading all kinds of gushing praise for it all over the place, I installed it somewhere and took a look at it, found it pretty much inscrutable, and dropped it.

I took a closer look at Zope last fall, and once again installed it on my Linux box. That time I even worked my way through the official tutorial, which uses DTML to construct a simple Elvis sightings database. Then I dropped it again.

Within the last month I've renewed my interest in Zope, having come to the conclusion that my own evolving attempts at a modular, extensible framework in PHP are always going to be falling short of where I need and/or want them to be. I can continue my one-man development efforts and maybe in a few years I'll have something I can call stable and more or less consistently usable, or I can invest some of that time in learning something like Zope, which has been around for a good long time and has an extensive developer community, and seems to have already handled most of the obstacles and use cases I keep encountering in my own work.

So once again, I worked my way through the tutorial. It's the sort of tutorial that kind of teaches you some core concepts, but mostly just teaches you how to copy and paste your way to the end of the tutorial. When you're done you have a form that submits to a database, and a page that pulls from the database, and you understand how it all works, but you see no compelling reason not to have done the same thing with PHP or PERL.

Obviously, the tutorial is meant to introduce you to mechanics, rather than the process of building a more complex application. I can sense the compelling reason for using Zope to build more complex web-based applications lurking right around the corner, but I'm having a hell of a time reaching the lightbulb-flashing-on-over-my-head point. This is the problem I've encountered with all of the so-called "frameworks" I've looked at since finding myself in the business of building web applications; the common goal of all of them is to make the process of building and managing solutions easier, but because most web frameworks tend to be scripted applications themselves there's a steep initial learning curve to tackle while you figure out how to build things through the layer of abstraction that the framework imposes on development.

Universally, the problem has been lousy documentation. I can usually get a technical sense of how a framework works, but that's usually where the documentation peters out. I see how Zope Page Templates work, and I could spend a few hours creating forms that submit to other ZPT files which then "do stuff" with the submitted info, but I would love to see a more advanced tutorial that works through database interaction and user authentication, covering those subjects in depth as they're introduced. Few things are more irksome than being told "Don't worry about what all this means right now" after a code listing and then getting referred to an appendix at the end of the exercise.

Short of paying somebody to teach me this stuff, I suppose there's nothing for it but to keep banging my head against it until that lightbulb goes on. The nice thing about Zope is the complete web based GUI it provides for building things within the framework. Most frameworks leave most of the repetitive dirty work of including libraries and correctly coding method calls up to you, and in the end you're still left with a pile of files in a directory somewhere. Everything is self-contained and consistent in Zope, and I expect that will make the crucial difference.