Monday, July 30, 2007

Thanks For Being Here

Every now and then I get the overwhelming urge to thank all my readers for being here and on my other sites, notably the programming blog diagrammes modernes. This most recently happened when I realised I'd had 24,293 visitors so far this year.

I use the amazing free Statcounter tool, which I recently found out is written by an Irishman, Aodhan Cullen. He just won BusinessWeek Young Entrepreneur of the Year, celebrating, in proper Dublin style, with pints at the Brazen Head. I recommend this analytics package for those who do not have full access to the web sever logs.

So, Statcounter has told me that I am now averaging over 42,000 unique visitor -- over 50,000 hits -- per year. Not bad!

To celebrate I'd also like to invite you all down to the pub... but that may not be practical. Instead I promise to keep writing as much as I can, though lots of other interests might compete.

But, hey, you can always encourage me. More on that shortly.
Thursday, July 26, 2007

Looking Forward To Wasp 2.0

WaspWasp needs to be significantly rejigged before I'll release it. Times have changed; Python has gained a lot of functionality in seven years, and people expect more from a web application framework. This article will outline what I hope to do to improve Wasp.

Wasp currently works in two modes: as a command-line batch processor and as a CGI application. The first of these is fairly uncommon in WAPs, but of great utility. Many times I have used the simple templating together with a few custom functions to produce HTML documentation as static files that I can throw on a server or disk.

I want to preserve both these modes and add a third: a threaded web server with Wasp embedded. This will make it easy to test web applications on the desktop. And maybe it'll be robust enough for production use, perhaps even out-performing the CGI mode. I'm going to ensure this outputs a detailed log in standard format, unlike the Python library modules for same.

Perhaps an obvious addition would be a mode to allow WSGI compatibility. But I'm not going to bother, at least not for the version 2.0 release, because I think WSGI apps serve a different niche. And there's already plenty of them out there.

I need to do a major code cleanup, removing obvious warts, refactoring the modules and stripping away useless libraries... even some that are not entirely useless but just not core enough. Here I'm going to be quite ruthless. My forms handling module will be going as there are other, likely better, approaches out there. So too the data buffer module. People can use SQLAlchemy (though I'll not enforce a choice).

The configuration file module will be removed, as I'm going to change the syntax of the Wasp configuration file to plain Python code. That's just more elegant and the syntax is no harder to understand. However I'm keeping my date and cookie modules because I like them better than the standard libraries.

By the way, Wasp 2.0 will require Python 2.5, because I can't be bothered remembering what features I'm not allowed to use to make it compatible with earlier versions. This version has been around since September 2006, so I hope most people have updated by now.

Error handling needs to be enhanced. I like how easy it is to debug web app errors, but more can be done, I am sure. Useless info needs to be removed from some of the error dumps. And I will add a local variable listing.

User modules will be renamed "plugins" and it'll be even easier to use them. Currently they need to be listed in the configuration file, but I want them to be automatically recognised based on the fact they are in the plugin folder. And automatically reloaded as they change, of course. Not needing to stop the web server for dynamic user changes will be a big productivity boost.

The application-level modules, those not strictly necessary to run Wasp, need to be so indicated through nomenclature. If there was greater integrity between the modules, and enhanced app functionality out of the box, that would be nice. How about ready-made blogging tools? Yes, I'll start there, but target version 2.1 for that functionality.

Finally, the templating needs to be enhanced. I'll write more on that subject anon.

I've always been rather good about writing documentation, but I need to make the presentation of same clearer and prettier.

And more unit tests. And a document test suite that will exercise Wasp server functionality.

That likely sounds like an awful lot of work. Certainly it means that this Wasp will be significantly unlike its predecessor... hence the jump to version 2.0. The tags and configuration files will not be backwards compatible, so in addition to everything else I will need conversion utilities to ease the upgrade pain.

Maybe you are by now thinking that this is all pie in the sky. But here's the good news: Most of the work is already done!

It's just that I'm very tardy writing my blog articles. Bonus!
Monday, July 23, 2007

An Architecture For Plugin Code in Python

I recently needed a framework that would allow a user to create a Python module of functions that could be accessed by custom scripts launched from a different module entirely. I think I've written similar code three or four times now, so it's about time I came to grips with the "pattern" involved. Like most things in Python, it's dead simple once you get your head around it.

Our example plugin module we'll call plugin.py and make as simple as possible:
def Iron():
print 'Iron'

def Gold():
print metal

def Again():
Transform()
print 'Plastic'

I note that the second function appears to be referencing a variable metal that does not exist, and the third calls a function Transform that also seems to be missing in action. These are to be provided by the calling programme.

That module is named master.py and looks like this:

import os, sys

class Alchemy(object):
def __init__(self, filespec):
# add module to system path
filepath, filename = os.path.split(filespec)
if filepath not in sys.path:
sys.path.append(filepath)

# import module into a custom namespace
filename = os.path.splitext(filename)[0]
space = __import__(filename, globals(), locals(), [])
self.namespace = space.__dict__

def __call__(self, code):
# define a new function
def _Transform():
print ':: into ::'

# add that to our namespace along with a constant
self.namespace.update({'Transform': _Transform,
'metal': 'Gold'})

# ok, go for it!
exec code in self.namespace

myAlchemy = Alchemy('/path/to/plugin/plugin.py')
myAlchemy('Iron()\nTransform()\nGold()\nAgain()')

(To get this to work on your system you'll need to update the path in the second-last line.)

Run master.py and you should see five lines of output to the console.

I wrote this as a class to emphasise the difference between the setup work done in the init method and the execution work done in the call. The setup is likely done when our application launches, while the rendering of the code might occur many times during execution.

The importing uses the hook documented here. A namespace is just a dictionary mapping names to objects, instances, functions and so on. We can update this with whatever specific elements we require.

The example function here is trivial. In a more practical example _Transform() might (for example) provide important environment information to the plugin.

The nice thing about this architecture is that the plugin modules themselves need not be littered with all sorts of imports accessing internals of the application. Just remember to document the available functions for the plugin author.

Code similar to this provides the functionality of the new Wasp plugin system.

Maybe something like this will make it into the third edition of that invaluable reference, the Python Cookbook.
Friday, July 20, 2007

Dragonflies And Lizards At Lough Gur

dragonfly
On Canada Day (July 1st) I was with my family, climbing the somewhat boggy hillside around Lough Gur, an area in County Limerick steeped in history and, indeed, pre-history. But on this occasion we were thinking less of the Celtic and megalithic peoples who once lived here, than we were of the variety of animal life around us.

Climbing the hill over the visitor's centre, we found ourselves walking through clouds of lovely blue dragonflies, one of which didn't mind perching on my finger. The way up the hill was rather nettle-ridden and a bit dangerous given the steepness and mud. We found one discarded mobile phone, obviously fallen from the pocket of a not-so-prepared hill walker.

caterpillars
Climbing Knockfennell on the north side of the lake was a bit of a challenge in the loamy ground, and not recommended for someone with a twisted back (doh!). It's steeper than it looks and the ground underfoot is not always stable. But it was well worth it on the day to witness the caterpillar "infestations". (Funny how things we dislike "infest" while things we like are "bountiful" or some such.) These larvae seemed to enjoy one particular type of plant, sharing their food with some sort of winged beetle as seen in the picture.

vista
From halfway up the hill there was a nice vista of the countryside, looking back across the lake in the direction of the road approach to the Lough. This photo would then be facing south-east with Bolin Island the little cluster of trees in the foreground. This is more notable than it looks, as it was a crannóg, or artificial island, used as a home in days long gone. I don't know the date of this one, but crannógs have been known to be 5000 years old and some of the other remains at Lough Gur date to that time.

lizard
It was while we were halfway up Knockfennell that we made a discovery, a specimen of Common Lizard (Lacerta vivipara), the only reptile native to Ireland. While "common" in name, and widespread in habitat, this little fellow is rarely seen. So much so that a couple years back the Irish Wildlife Trust ran a National Lizard Survey to find out more about where they lived.

It was a speedy little dude, and didn't wait for the snail to get out of its way, walking right over the mollusc. Finding this animal really made our day.

sites
Anyone visiting this part of Ireland should spend half a day in Lough Gur to check out the Grange Stone Circle, Wedge Tomb and other "sites of interest". Don't let the clouds and rain put you off -- landscape like this is better in the rain.

But look out for lizards underfoot!

all images © Robin Parmar 2007.
Wednesday, July 18, 2007

Dynamic Language Weenies Victorious After All

I just had the "pleasure" of being introduced to Hacknot, a blog on software development by an author hiding behind anonymity, but whom we will, for convenience, call "Ed Johnson". In "Invasion Of The Dynamic Language Weenies" he derides dynamic languages, claiming they are not easier to code in, produce no real benefits and are generally the tools of bad programmers, those who live in the thrall of some juvenile fan dementia. He makes so many mistakes here it's hard to know where to stop criticising. So I didn't (stop, that is), and wrote this reply instead.

The effluent Johnson takes 8200 words to make two points, that language evangelists over-state their claims (shock! horror!) and that some of their behaviour is unkind to those who disagree with them.

The last point we can dispense with immediately, since his own behaviour is equally unkind. The article is full of statements like "get back in your high chair" and derogatory labels like "fanboy" that negate any moral high ground he may have otherwise had.

This frees us up to get into the meat of the article, or perhaps "gristle" is a more appropriate term. I will do so by presenting a number of sections corresponding to his own supposed rebuttal of various dynamic language evangelist claims.

Benefit: Application Code Size Reductions

Johnson1 defines "Dynamic Languages" in terms of three attributes and then goes on to show that they do not produce enough in the way of code reduction to justify a claim of 80-90% savings (made by Stephen Deibel2).

But perhaps he should have widened his definition to include the fact that Python (the specific target in this section of his article) contains very high level library support. This means actual application code is dramatically reduced. I go further than Deibel: the fact I can instantiate a web server in two lines of code reduces my application volume (in this case) by 99%3.

He does get to discussing libraries after about 1200 words explicating why his own limited definition gets him no closer to understanding the claims he is supposedly refuting. But when he does get around to it he only mentions the subject of libraries to dismiss it entirely. "But any saving in code that occurs from the use of third-party libraries has nothing to do with the dynamic nature of Python." Perhaps not according to his own limited definition.

Forget "third-party", it is the completeness of the standard library that provides a substantial benefit to Python developers (the community uses the phrase "batteries included"). Having a complete high-level and standard library that you can be sure the entire installed base has access to is a boon to developers. Apparently Johnson is blind to the advantages of this, having learned nothing from the history of C, C++ or Java.

Add to this the very real benefits from the three attributes of dynamic languages he does admit to and we start to glimpse the substantial, perhaps even profound, advantage dynamic languages offer.

Bias Evident, But No Evidence

Johnson goes out of his way to shoot down studies and opinions contrary to his own. Without evidence.

He attacks Lutz Prechelt's "Are Scripting Languages Any Good?4 for various methodological errors, and fair enough. But he provides us with no similar study that contradicts the conclusions, or was done with a less flawed methodology. So, on one side we have a comprehensive though flawed study, and on the other we have... nothing.

When he slams the Java versus Python code comparison he forgets to mention that the author goes out of his way to mention that it is, in fact, subjective. Rather than acknowledge the honesty of the author he chooses to disparage him. Again, without any contrary evidence.

It is not enough to state that Python code is no briefer than Java; examples must be forthcoming. But I'm not surprised Johnson backs off trying to prove the impossible. His cases would have to be far more contrived than those put forward by his "victims".

Advantage: Dynamic Typing Increases Development Speed

Johnson rebuts this claim by saying that type declarations do not add appreciably to code overhead, but this is a simplistic claim which does not take into account the need to build templates, track and convert between types, etc. All of this adds not only to the code but, far more importantly, to the cognitive overhead needed to manage a code base.

Certainly there are advantages to strict compile-time type checking, but these may be offset by using tools to perform static analysis of your source code5. This avoids having to enforce the overhead of strict types continuously throughout the development process. Even static languages benefit from these, witness Lint et al.

Yet this argument would not convince Johnson. He sees nothing good about being flexible, seeing it only as "an opportunity to err".

I imagine that's because he has never used Python to open a string object and then treat it as if it was a file, even though it is not. Polymorphism equals convenience and all out of the box. I am not sure how this flexibility necessarily leads to errors, but it is immediately apparent how it increases productivity6.


Advantage: Interpretation Increases Development Speed

Johnson states quite rightly that compiling code does not always take hours, so that the benefits in raw time gained by not needing to compile might be small. He notes that code components that are static can be made into libraries, then linked into code that is currently being tested, in order to decrease compile time.

Never mind that this is a tacit admission of the problem, how does this affect workflow? In a dynamic language all the time spent managing those "temporarily static" libraries, determining when parts have changed enough to require recompiling, publish various versions etc. gets reduced to zero. The coder can instead focus attention on more valuable aspects of the programming job. Looks like a productivity increase to me.

Advantage: Reduced Code Volume Increases Development Speed

Johnson writes about syntax only to dismiss improvements to it as a mere "keystroke-saving mechanism". Here he refuses to think about how clarity of syntax improves the comprehensibility of code and boosts productivity, especially across larger development teams.

As usual he exaggerates to make his point: "Many language comparisons performed by DL enthusiasts focus on concision as if it were the sole measure of programmatic worth." Well, Johnson, how about we admit it's not the "sole measure", just an important one. Happy now?

He dismisses claims for syntax improvements by saying that examples could be tailored to the situation at hand. Sure, a given example might be chosen to emphasise a point. I mean, what else does he really expect of an example? That it should be chosen to disprove the assertion? Tailored or not, his opinion of a given example hardly invalidates the original claim.

As the Problems Change, People Use New Languages

Johnson rebuts this claim in two ways.

1) Ruby development only exists because people love Ruby.

2) Ruby was used once on a project he was involved with in an inappropriate context. It must have been chosen because it's a "new toy."

I kid you not, that is the sum total of his argument. There's nothing here about other dynamic languages7. Nothing about different domains, changing demands, the actual world we live in... you know, context.

Just off the top of my head, here's four pieces of historical evidence to support the original claim.

1) As the demand for desktop applications swept middle management, a need for easy-to-use GUI-based tools emerged. Enter Visual Basic to fill the gap.

2) As more technically trained people got into server management there was a need for powerful parsing-based tools. Perl evolved with a terse syntax well suited to the problem domain, which included server-side web scripting.

3) As more non-technical people got into web development there was a growing need for a quick and easy way to glue databases to CGI applications. Enter PHP.

4) Dramatic improvements in hardware capabilities (processor speed, memory, disk space, bandwidth) rendered the differences between software execution models negligible. At the same time awareness of "programming for all" hit the mainstream. Enter dynamic OOP languages with friendly faces, like Python.

Johnson will continue to argue that these tools were only used because they were fashionable, not because they actually filled a niche. Unlike his own choice of tools, of course.

Syntax Can Be Natural

Johnson states that "Any claim that a DL has a more natural syntax that [sic] another language is just an attempt to elevate one personal preference over another." I agree that claims for "naturalness" can never be totally justified, as such of course depends on context. But the author is doing what he does so often, over-exaggerating a point and finding the baby is missing with the bathwater8.

Does he really think that the strangulated syntax of Perl, or the arbitrary statements in Visual BASIC or xBASE variants are as "natural" as Ruby or Python?

The best way to "prove" this is to offer code snippets to those who do not know the given language and see if they can figure out what is going on. I'd love to see such a study.

But the results are anticipated by Johnson's own foray into Ruby. His attempt to guess syntax for summing the elements of an array is as follows:
for every x in [1,3,5,7] { total += x }

In Python it is:
for x in [1,3,5,7]:
total += x

(Providing you initialise "total" of course. I assume he knows that.)

So, I guess he is helping prove that Python does have more intuitive syntax! Good luck guessing what the appropriate statements would be in a static language, since you might have to link in a library just to get a list container. And then you'd have to rewrite your code for some other object that was iterable but not a list. And so it goes, the ever-increasing spiral of repetitive work required to code anything significant in a static language.

No Harm, No Foul

This section is very strange. Johnson objects to people who say "what's the harm in adding Ruby to your toolbox" by comparing such people to... wait for it... rabid Creationists. He reminds us that Creationism is not on par with evolution scientifically. Might I remind him that coding is not science at all, and so any possible comparison of this sort is best made after ingesting a tab of LSD?

Things The Author Chose To Forget

There are so many advantages of, say, Python over, say, C++ (to pick one dynamic versus static case -- using the author's own divide) that it's hard to imagine how Johnson could have neglected to mention them, unless he's just being very dishonest. In Python I never have to worry about memory models, pointers or any other aspect of memory management; have powerful data types built in; have robust cross-platform compatibility; have highly polymorphic code; can use introspection features out the wazoo; take iteration, late binding, and other high-level functionality for granted; and so on and so forth.

But the best thing is, I do not necessarily even need to know what all these fancy features are, I can just get on and use them, in a safe way, with no risk of core dumps or buffer overflows. The risk of my finished application doing anything untoward is reduced, the accessibility of my solution is increased, the maintainability of the source is improved, etc. etc.

There is simply no comparison. In 99% of the problem domains 99% of people need to code in, a high-level dynamic language like Python is the best tool for the job. No, it's not "pure". No, it's not perfect. No, it's not scientific. It just works.9

A Couple Of Things The Author Gets Right

"Structure, commenting, consistency, naming, performance and maintainability all influence the efficiency with which programmers can work on a body of code." So does a good chair, lighting, being respected for one's work, and not having to deal with lame blog entries shooting down your tool(s) of choice.

"One of the features distinguishing fact from delusion is the presence of measurable, reproducible evidence that permits independent and skeptical scrutiny." A shame Johnson provides no evidence, then.

"At eight thousand words, this article requires far longer to read than the attention span of the average dynamic language weenie." That's actually true, because the author is so long-winded. The fault is his, but he chooses to blame his readers. And it's not just this article. In "To Those About to Hack" he takes 2200 words to say "Think twice, cut once", even admitting as much himself. Even with some topical exposition, what he had to say there should only take about 500 words.

"There are many interrelated factors influencing overall development speed. It's not valid to consider one factor in isolation." Strange, then, that his own analysis consistently ignores the synergistic effect of combining efficiencies. Syntax clarity, dropping the compile cycle, very high level standard libraries, reduced code volume and dynamic typing all offer benefits in isolation. But taken together they point the way to a new paradigm of coding (call it Agile, XP or whatever) that is having a huge effect on programme development.

Or, you can just deny it all and hope it goes away, thumb your nose at the kids and call them names.

An approach Eddie Baby obviously prefers10.

Notes


1 I will call him this but not "Eddie Baby", "sweetie", "sugar plum", "pussycat" or "angel drawers". For more fun, see the script for "It's the Arts." It's a Python thing.

2 I would love to reference this quote but Johnson does not know how to provide references. Actually, he lists a lot of references (poorly) as though this somehow bolsters his argument.

3 Not that lines of code is the only, or the best, measure of productivity.

4 Available in PDF.

5 For Python there is PyChecker, for example.

6 Examining a data type for only the interface you require at that moment, and then treating it as though it was that type is a technique known as "duck typing". As in, "If it looks like a duck and quacks like a duck..." Coined by Alex Martelli.

7 Johnson switches from Python to Ruby depending on what he wants to slam, but consistently fails to provide evidence against dynamic languages in general.

8 Odd too that he should discuss syntax in two different sections when he does not even acknowledge it as a factor when defining dynamic languages.

9 If you want all those other things I suggest Lisp.

10 Whoops! I mean "Sir Edward".

Thanks to Paul Jensen from bringing the original article to my attention.



Tuesday, July 17, 2007

The Return Of Wasp

Wasp
So I was writing to my good friend and fellow developer Paul Jensen about Wasp when I realised that I have a programming blog that is sadly lacking in content. So maybe I should muse on Wasp here.

What is Wasp? It's a web application framework (WAF) that I've been using since about 2000. Gah! I hear you say. Not another WAF! And I sympathise.

In March of 2006 I wrote four articles, ending with this one, examining the existing Python frameworks. There are certainly lots to chose from. So why Wasp?

Well, I tried working with those others. They are far more sophisticated, have been to the best possible schools and hang around the hippest cocktail bars. But I had a hard time getting my head around them. There's so much jargon, inter-dependencies and magical OOP stuff that it makes my head hurt.

Wasp just works and in a way I can comprehend. (I suppose that makes sense, since I wrote it.) In a world of fancy shooters and martinis with vegetables, Wasp is a plain old gin'n'tonic. Or maybe a home-brew beer -- I think I'm losing the metaphor.

Wasp is not popular since I never did much in the way of promotion. It has been used to run a small (but very real) e-commerce site and, back when I was maintaining it, I would get emails asking this or that question. Someone out there was using it. Soon after taking it off the net I had people asking where it had gone.

So maybe Wasp still has a place. Perhaps it still has advantages for newcomers to web development. Looking at it in a new light I like the following attributes:

1. Zero external dependencies. Install one package in a folder somewhere on your path and you are done.

2. It can work as plain CGI. No need for fancy application servers, compilation steps or other mechanisms. This means you can set it up quickly with just about every web hosting company in existence.

3. It can work from the command line. Process a bunch of templates into static HTML you can throw anywhere you like.

4. It doesn't try to reinvent web files as classes. URLs retain their traditional interpretation as file locations. There's no super-OOPy "one thing really means another" stuff going on.

5. Since your web files are still files it's easy to integrate with designers and their tools. Ever try to get a web designer to write a subclass of a page or a regular expression to parse an URL? Didn't think so.

6. Has a simple templating mechanism that can be described in one page.

7. Easy to plug in your own code.

8. Emphasises a proper division of markup for display purposes, code for back-end processing.

9. Has no database dependencies.

10. Comes with session and cookie management that works.

Now, to be fair, here are the main disadvantages:

1. Written by one guy: me. No support team or corporate hand-holding.

2. Not WSGI compliant. Doesn't know from middleware. Not designed to be used with other web packages in a turnkey way. (Though of course any Python module can be imported as usual.)

3. Did I mention the templating is very simple? Maybe too simple for some.

4. Uses custom modules for some things that didn't exist in the Python standard library back in 2000 (cookies, dates, logging).

5. Not replete with unit tests and other aspects of correctness.

So, yes, I think Wasp is a good thing. I've decided to use it for my own projects and will make it available for others once again (as free open source, naturally). But not before I have it good and ready.

In my next article I'll discuss what I've decided to do to update Wasp for the year 2007.

Update 2007.07.26: So as not to draw any further flack, I've changed the word "meaning" to "traditional interpretation" in point 4.
Saturday, July 07, 2007

"The End Of Violence" Reconsidered

"The End Of Violence" is a film that did poorly at the box office and was panned by critics (28% on Rotten Tomatoes). On watching it again I wish to offer the contrary view that it is one of Wim Wenders' best. The unusual juxtapositions of mood (hitmen played for humour), odd choices of content (no fewer than three scenes at a poetry reading), measured pacing and disjointed narrative could easily have failed, but work splendidly thanks to a consistent humanist message delivered with confidence.

Wim Wenders is an uneven film-maker, with as many brilliant successes ("Paris, Texas", "Wings Of Desire") as failures ("Million Dollar Hotel", "Faraway, So Close"). But even the failures are films full of intriguing performances, excellent cinematography, enjoyable music, and keen observations of human behaviour.

In "The End Of Violence" the omnipresence of technology is a recurring motif. Pullman's character, the action film producer Mike Max, begins the film embedded in his space-age computer chair, plugged in to phone, video conferencing, and internet data streams. Even his wife (Andie McDowell) has to phone him to reveal she is leaving, apparently to go to Guatemala. (One of many hilarious lines in the film.)

Mike will soon become unplugged by an act of seemingly random violence. But by then we have been shown the surveillance center installed in the Griffith Observatory, its cameras now trained to look down on people rather than up to the heavens. Ray Bering (Gabriel Byrne) is having second thoughts about the ethics of the secret project, and sets in motion the chain of events that culminates in the action we are witness to.

Wenders makes clear the artifice in play, setting some of it on a film set in which a German director enjoys, almost despite himself, making a low-brow film in Hollywood. It's great to see him poke fun at himself. The set is a beautiful replica of Edward Hopper's painting "Nighthawks", a heightened depiction of average people at an average bar.

Later in the film, at such a bar, Cat (Traci Lind), dressed in her costume from a movie set, and Mike, dressed in his costume as a Mexican labourer, talk. "You know, I hate it in movies when the guy, running from the government, meets a well-intentioned beautiful girl, gives her top-secret information... that character, she always dies." Despite that misgiving he gives her the information because he trusts her.

The characters in this film all have one syllable names (Six, Doc) that attest to their emblematic status as objects within a Hollywood landscape (and inside a Hollywood film). Mike's wife Page appears as blank as one, Cat is a slinky love interest, Doc can't help looking into things, Mike himself is a character who literally takes it to the Max.

"The End Of Violence" is also engaged politically, showing us what it means to be all-too visible to the dominant authority (infra-red cameras and sharp-shooters in the night) but also what it means to be invisible (Hispanic workers with leaf-blowers). The romantic view of the migrant worker is not allowed to go unchecked. "Don't like us too much" the patriarch tells the former mogul he has befriended.

The penultimate moment in the film is a scene of heart-stopping violence, not played out as frames from a bloody Mike Max movie, but delivered to us cold. The reaction shot is from an old man in a room. The consequences of the act on the very human characters we have come to know is delivered without fuss, without excess, and is all the more powerful for that.

The final scene involves four characters, three of whom are little known to us, but who will carry on the narrative after the film ends. Some will continue the violence, but others will continue to trust, to weave the web of human interactions that is all we have, says Wenders, to fight the system of imposed values Hollywood embraces.

The camera captures the blue of the sky, the blue of the sea, a blue that has saturated the film with its deep promises of redemption but also threats of danger.

Both are entwined together in this remarkable film.
Tuesday, July 03, 2007

Inside The Mind Of escalation 372


My recent post on Reaktor is part of my post-gig assessment of how I work and why certain sounds become certain other sounds that end up in the ears of certain listeners. The escalation 372 concert in Galway is now a moment in history, but the nine new pieces I premiered will have other airings. For a start, a couple are being used to launch my new Bebo page.

(There's also one added to my MySpace page.)

The ideas behind the songs started off with an intensive consideration of the music of Delia Derbyshire, pioneering sound artist at the BBC Radiophonics Workshop. Derbyshire is best known as the arranger of Ron Grainer's Doctor Who theme. This music has always been with me, from my earliest childhood. Perhaps because of this, I have avoided becoming too familiar with her oeuvre, lest it become too great an influence on my own productions.

Regardless, it appears I have managed to replicate some of the Derbyshire sound without even realising it. The fact that she was working with musique concrète and I with software instruments hardly seems to matter.

For this project I took some of those Derbyshire-esque sounds and combined them with drum machines, though once again these are software replicas of drum machines, tortured and abused. One song has a tempo of 2 BPM. Another stretches the notes out into long ambient noises. In a couple of cases the beats remain relatively unmangled; these tunes verge on being dance pieces. But one thing that stops them from becoming "standard" is the non-structural approach.

Each song is based on riffs but these don't form into regular patterns. Instead, I improvise with them live, changing any number of factors including the fundamental beat. I am not sure if any other artist uses this approach in quite the same way. It is something I have evolved and it works for me.

The sounds themselves I kept simple, avoiding anything that recalls too clearly a synthesizer. However, I did use a MIDI keyboard in the performance, for triggering certain notes, some samples, and for tweaking parameters of the sounds.

Speaking of the samples, I have dipped deeply into one of my favourite sources, the film THX 1138. I have been promoting the sound design of that masterpiece long before Walter Murch had a bundle of Oscars on his mantelpiece. I have little to repeat about this film, except to say that I have been happy to listen to it with the visuals off, and broadcast it this way as a radio programme many moons ago.

I also got out my guitar, which went from five to four strings in the process of tuning. I am rather fond of getting synthetic tones on the guitar and guitar tones through synthesis. I combined the two timbres in the climactic piece, the long drone masterpiece "Self-Winding Coil".

The final instrument was a strange device known as a pillow speakerphone, which I use as a limited band microphone. Adding a high degree of compression to the output turns it into a great feedback device at live volume levels.

With all of these elements something still seemed to be missing, so I asked Susannah Clare to improvise vocals to a couple of the tracks. This takes them into a different zone, one that perhaps contradicts some of the other impulses on display. If so, good!

I also put together visuals for every song, but thanks to a faulty DVD player these did not get shown on the night. Disappointing, considering the hours that went into the video production.

The result was nine pieces in forty minutes, with a good deal of variety and a pace that never faltered. In fact, I might prefer more extended jam sessions on some of the riffs. Maybe next time.

The pieces tend to work better as a whole than broken up into "songs". The final sound is what? Electro-noise-ambient-beatscapes? Something like that. Listen, and see if you like it.