Interview: Zem on programming and Txp
Alex Shiels a. k. Zem is well known by the Txp community for his many helpful plugins and for his website thresholdstate.com. Recently i got the chance to interview him
Alex Shiels a. k. Zem is well known by the Textpattern community for his many helpful plugins and for his website thresholdstate.com. Recently i got the chance to interview him. Here we go.
Alex is 30 years old and lives in suburban Sydney, Australia. For the last 2 years he has been a self-employed freelance software developer, mostly working from his home office for clients in other cities and countries. Before that he spent about 6 years as a employed as a software engineer by several R&D and telecommunications firms.
Zem on working and other interests: Working from home has a way of eating into spare time, but when I’m not too busy I enjoy taking photographs and collecting obscure and noisy music.
The Interview
Some people on Txp forum regard you as one of the most creativ developer. Does your creativ ideas result from many years of experience?
Aww, shucks.
Not so much from the extent of that experience, as its quality. I’m a problem solver, not a code guru – I can come up with 6 clever
solutions at the drop of a hat, but have to check the manual every time I use preg_replace, because I can never remember which way around the parameters go.
That means I usually wind up as The Guy In Charge Of Stuff Nobody Else Can Figure Out, designing and writing code to do things that aren’t supposed to be possible, usually on a short deadlines. That’s given me an overdeveloped sense of professional paranoia, and a knack for avoiding unnecessary complexity and dead ends. Oh, and a SDLC process that’s a kind of habitual defense mechanism, evolved from running critical projects with minimal resources and little room for error.
Which other programming languages you know as well, if any?
I started in C and C++, moved to a proprietry language nobody has ever heard of, then Delphi, Perl, C++ again, Java, a little Prolog, and finally PHP and Python. Recently I’ve started experimenting with Javascript.
Which progr. language you like best or you like to get into deeper?
Python is my language of choice these days, because it’s neat and simple and everything just works the way it should. For all its
shortcomings, PHP is the best choice for web applications. Prolog is the most fun, though it’s impractical for almost everything.
Really, the language doesn’t much matter to me, particularly since I’m not so good at remembering the details. The platform and
application framework are far more important. That’s why Python and PHP are so effective: there’s very little overhead, and most of the functions you’ll need are already there, installed by default.
Is thresholdstate your first personal website?
I’ve built web sites before, some for clients and some for fun. But Threshold State is the first to feature me, by name, writing in the
first person, so I guess that makes it my first personal site.
Which advantages Txp has compared to other Blogsoftware like WP?
I’ve only briefly looked at Wordpress, never really used it. I spent a little time bothering the Serendipity developers, I’ve tried
Movable Type a few times, and was possibly the only long term user of bplog, but other than those I don’t have much knowledge of other blog or CMS applications. So instead of comparing details, I’ll give a rather abstract answer.
I think Textpattern’s greatest asset is its inflexibility.
Programmers are trained to write code that is infinitely reusable and modular. They’re very good at that, at minimizing limitations and assumptions. Essentially what they do is delegate up: they defer decisions, passing them up the chain of command to the higher level modules of the software. Most of the time that’s a good thing. But it’s a terrible thing when that same philosophy is applied at the highest levels of an application, at the user interface and it’s associated structure (and often at other interfaces too, like APIs and network protocols).
At those interfaces, it’s critical to understand how and why an application is used, and to simplify and minimize the decisions required of the user. That’s the opposite of what programmers normally do: taking responsibility and making decisions, instead of passing them on to the user (and, of course, knowing which decisions to make and which to leave). Businesses try to distinguish between these using two roles, analyst and programmer, but usually both roles are handled by one person. Too often the programmer takes over and they just keep delegating up. That leads to the kind of mess common in the Linux world: software that is extremely flexible, but hopelessly hostile,
with every conceivable decision made into a configuration option. That places a burden on the user to discover how the software works in order to use it effectively. It’s great for geeks and people for whom tinkering is an end in itself; but very unhelpful for those who merely want to use the software as a tool.
The other mistake often made by programmers is to confuse function and functionality. A screwdriver has only two functions – inserting and removing screws – but endless functionality as a lever, prod, punch, scoring tool, etc. I shudder to imagine the contraption that would emerge from a typical programmer’s attempt at designing a screwdriver.
Though I don’t know much about Dean’s background, a flip through the Textpattern source shows he’s not a typical programmer. It’s too neat and simple. He’s made the decisions about what the software is used for and how it should work first, and let that drive the implementation details, rather than the other way around. Textpattern’s limitations are largely intentional, designed to reduce the number of decisions required to build and maintain a web site. The section structure, template syntax, markup language, article schema, permissions and so on were all designed by someone who knows how to run a web site (and how not to do it). The important decisions have already been made, and a great many mistakes avoided.
The end result is a fine tool, something that lets people forget about how it works, and get on with the business of using it. They can spend their time designing layouts and writing content, rather than figuring out how to configure and manage the application. Page templates are edited in a browser and written in a syntax already familiar to the people who need to manage them (rather than in PHP, which is highly flexible but relatively dangerous and unforgiving, or a new template language with its own syntax). Article markup is semantic. Regular pages and static content are managed using exactly the same functions as weblog pages and articles. Textpattern was built by developers who understand the difference between function and functionality.
Which parts/functions of Txp, you think, could be improved? What is important for the future development of Txp, as far as you are considered?
The design of the template parsing engine has some limitations that are likely to become apparent as more conditional and looping tags start to emerge. It has problems with recursively nested structures like this:
1. <txp:else>
2. . . . <txp:else>
. . .
3. . . . </txp:else>
4. </txp:else>
The regexp parser is context-free, so it matches tag (1) with tag (3) rather than tag (4). Fixing that requires a context-sensitive
parser.
The other important improvement, which I hope will be available soon, is an admin-side plugin API. That will allow plugins to create
their own pages for the Txp administration interface, and handle events triggered on the admin side. I think that’ll open the floodgates for many new capabilities.
You did develop the drop cash plugin and did write an article about developers have to make some money too. Do you think the Open Source development/community is a blessing or a curse for developers?
It could be both, or neither. It’s easy to see open source and the open source community as one and the same, when they’re really quite distinct. Open source is a method, not a group or a movement. The majority of productive open source developers have relatively little direct contact with the community. They write code and release it as open source for their own reasons; the community is a side effect. Few open source projects are truly colaberative efforts. Most applications, even large and popular ones, tend to be written almost entirely by one or two people.
I keep hearing from enthusiastic open source advocates about the multitude of ways for a developer to make money writing open source. Yet none of them are developers, let alone open source developers. Most of them earn a living providing administration or technical support services based on open source code that was written by someone else.
There are business models based around open source, but they tend to favour large companies. Developing a new application is usually a speculative investment. There aren’t many individuals or small businesses that can afford to spend months of unpaid work on a new project, in the hope that at the end of it they might be able to earn some money from support contracts.
Fact is, earning a living as an open source developer is difficult and uncertain, and has more to do with good fortune and marketing than a sound business model. Most of my time is spent writing code that is never published, either because I’m paid to write proprietary code, or I’m customzing open source in ways that are only of use to a single client. I don’t get paid a salary, so an hour spent on open source is an hour not spent earning the rent – open source has to come last, for reasons of survival.
Fortunately, the very existance of open source software and its community demonstrates that a win-win situation is possible, though not necessarily inevitable. As long as developers can find ways to develop open source software on their terms, the community will benefit.
That’s why experiments like the Dropcash software ransoms are important: it gives the community a way to invest in the direction of the software, rather than leaving it in the hands of large companies. The more ways there are for developers to earn a living at open source, the more code will be produced.
Thanks Zem for beeing so kind giving this very detailled interview.
Alexander Shiels can be booked for commercial projects. Please feel free to contact him any time you like.
