Interview with Alex Martelli

An interview with Alex Martelli, employee of AB Strakt and author of some great Python Books

Tom Deprez

EuroPython: Can you introduce yourself a little bit to the readers?

I'm an old-timer in programming terms, since I've been programming for over a quarter of a century. I didn't want to program... I wanted to design hardware. I chose a thesis in integrated circuit design... and found myself writing a huge program to help design integrated circuits.

After my Laurea I joined Texas Instruments to design integrated circuits... and found myself working in Artificial Intelligence. I then joined IBM Research, to design image processing hardware and set up an image processing lab... the hardware was done and the lab was ready in a few months, and then there were zillions of image processing algorithms to research and image processing programs to develop.

That's when I gave up and acknowledged the Universe wanted me to do software, not hardware. Haven't designed any hardware in twenty years... fortunately, pretty soon something "clicked" and made me see the joys of software development (as well as the frustrations, which were always quite obvious:-). When I got tired with the I've Been Moved way of life (not with IBM itself, a firm I still hold in the highest regard), I came back to my home town, Bologna, and accepted a job as Senior Software Consultant for a then-small software house (Cad.Lab, later renamed to think3,inc) in the mechanical CAD field. The 13 years that followed were lots of fun...

EuroPython: Why did hardware fascinate you more than software? Was it because of the more diverse way of working?

Back in the '70s, my impression as a student was that hardware design was an engineering discipline, while software struck me as out of place in engineering school, as belonging far more to the humanities or the arts. Like most 20-somethings, I wanted things clear and well-defined, and the strange role of software, "neither fish nor fowl", left me uneasy back then.

EuroPython: Does it still fascinate you or was the 'click' final?

I've come to realize that my intuition of 25 years ago was rather correct, that software is not truly an engineering discipline, and much of that realization came from seeing excellent engineers striving hard to make it one, and failing over and over again. But at the same time as I was confirmed in my estimation of the subtle and ambiguous nature of software, which is at least as much about the strengths and limitations of the human mind and of human social communication as it is about computers, at the same time I gradually managed to perceive as its strength, its source of unending interest. Bridge is much the same: the rules themselves are rather simple (although their deep structure may give rise to profound, non-obvious results, as I showed in my research), but the game still yields unending fascination, because it's all about human interaction within that reasonably simple "technical" framework.

Editor Note: More about Bridge later in this article

EuroPython: I've heard you are one of the 'robots' on comp.lang.python: Martellibot. How did you earn this name? What happened?

The other two bots, timbot and effbot, surely deserve the title more than I do: they're Python long-timers, at the heart of Python development (Tim Peters is in the core team, Fredrik Lundh maintains a zillion crucial modules), while I'm a newbie -- I only met Python in late 1999, after all.

I had been posting (rather a lot...) to comp.lang.python for less than a year, when I found myself answering a question about interfaces in a somewhat verbose and thorough manner, as is my wont -- a couple hundred lines (here's a link to the Google-archived copy of that post), including short explanations of the worth and use of interfaces in Java, C++, Eiffel, COM, and Visual Basic, and how to implement similar schemes simply and effectively in Python.

That was, I believe, the first time I was called a "bot" in c.l.py -- specifically by Ng Pheng Siong, who responded "You just outed yourself, bot! ;-) Excellent post.". Steve Holden (who I believe coined the specific term "martellibot"), Martjin Fassen, and other posters, soon took it up, in connection with other posts of mine, and before I knew what was going on, bang!, I was "outed" as a bot...

EuroPython: When did you start writing Python Books? And why do you like it so much (judging from the vast amounts of books you are writing)?

That's Greg Wilson's fault! Around mid-2000, having noticed my c.l.py posts, he asked if I might be interested in writing a Python book, and, upon my enthusiastic assent, he introduced me to O'Reilly. It took a long time to set things up, but, almost a year later, I had a contract in hand and started writing "Python in a Nutshell" -- which then got shelved to give priority to the "Python Cookbook", which I co-edited with David Ascher, having been kindly invited in mid-project, jointly by David himself and by my O'Reilly editor (who was the editor for both books). Now, having seen the Cookbook through (it's at the printers as we chat, and will be launched at O'Reilly's OSCON, a few days after Europython), I'm back to the Nutshell, revising it for full coverage of Python 2.2 and getting it ready by October 2002 - that's its new target date.

There are many activities I find utterly fascinating, but, over and above all others, nothing can really beat writing. Any kind of writing -- from off-the-cuff posts, to technical reference books -- from poetry and fiction, to Python. Brevity is always a challenge for me... just like the Emperor of Austria is said to have criticized Mozart because his music had "too many notes", thus might I be fairly criticized because my writing, as it comes most natural to me, has "too many words" (and if you think that comparing myself to Mozart is a bit immodest of me, stick around -- you ain't seen nuttin' yet!-).

I think they're generally reasonably appropriate, colorful, and accurate words, but there are too many of them, and moreover, they're enmeshed in long, intricate sentences (that's partly the fault of the Italian school system -- they always have you writing essays and debates, and never do you hear about length limits on them... and they make you study Cicero and Seneca and other such example writers...! -- but, admittedly, it's also got a lot to do with the way my own mind works:-).

It's exactly BECAUSE brevity's a challenge, that my best writing comes when I have to be concise -- although it takes me many hours and a lot of blood-sweating to reach conciseness. As Pascal wrote in the Lettres Provinciales (two centuries later, Mark Twain paraphrased him without attribution, so this is sometimes thought of as a Mark Twain quip...), "Je n'ai fait [cette lettre] plus longue que parce que je n'ai pas eu le loisir de la faire plus courte", i.e., "this letter is so long because I have not had the leisure of making it shorter". Oh yes, it does take much longer to make my writing short and to the point. Can't spend that sort of time on c.l.py postings (actually, these days, I have to keep off c.l.py altogether, or all of my extremely-scarce time will disappear before I know where I've put it... but I definitely hope that's just a transient!) -- and I only did that to a certain extent in the Cookbook, since in that case there were so many other challenges already (such as keeping the original "voices" of over 100 contributors reasonably intact, while giving the book enough uniformity to make it easier to read and understand) -- but, in the Nutshell, it's definitely THE issue.

People who know me from c.l.py postings (or from my equally verbose, rambling-prone and superabundant face-to-face conversation) sometimes quip that the Nutshell will be a cocoanut (and then go on to debate the air velocity of an African swallow carrying it -- our language IS named in honor of Monty Python, after all!). But, come October, we'll see who laughs best...:-).

My dream is not really to write about Python, although that's indeed what I'm doing these days, and I do enjoy it a lot -- rather, it's to write about the most fascinating and important issues of programming -- program architecture, programming paradigms, design, methodologies -- using Python as the language to express my writing in (side by side with English, to be sure:-). Python is great because it's easy to master, simple, pragmatic, and gets out of your way once you have mastered it, just like a great tool should. Then, the truly interesting part begins: using the tool to turn your dreams into reality, specifically into executable code.

Most programming languages are unsuitable in this role because they impose specific predefined paradigms on you. With, say, Java, or Eiffel, you really have to buy into OOP -- the language is just too slanted towards it -- just like, with, say, SML or Haskell, you have to buy into functional programming. Great if that one paradigm is what you want for a given part of your work, not so great otherwise...!

Multi-paradigm languages, on the other hand, tend to be so utterly complicated, like Perl or C++, that they never really "get out of your way" entirely. Great books like, say, "Design Patterns", Coplien's "Multi Paradigm Design for C++", and Lakos' "Large Scale C++ Software Design", end up being about C++ at least as much as they're about architecture, design, and paradigms. Using Python, on the other hand, I could exhibit a panoplia of paradigms, the architectures they afford, the technical side of the methodologies you can use to reach them, and both the process and the results of design, far better than with any other programming language I ever heard of (Ruby could come close, perhaps -- it is a great language -- but Python's even more appropriate). Maybe it's true that "Euclid alone has looked on Beauty bare", as Edna St. Vincent Millay maintained, but such a book should at least afford a glimpse of Her in a reasonably skimpy outfit:-).

But we need to have the Nutshell, pinning down the fundamentals of Python and its libraries in a handy, concise desktop reference, and the Cookbook, with hundreds of recipes showing how the fundamental mechanisms hang together and are used idiomatically to solve practical problems, before we can soar into "Multi Paradigm Design and Architecture with Python". I think I'll have a try at making that dream book of mine a reality, some day -- perhaps with a suitable co-author, because writing a book is a large undertaking, and, like wheb doing software, it helps immensely to have the right partner at your side (it can easily more than double your joint productivity, if the sinergy between co-authors is indeed "just right").

EuroPython: You name here some other programming languages. Do you know them all well, did you once use them?

Yes, I do know a lot of programming languages. Like many developers, I find programming languages interesting in and of themselves, so I study them and try them out even if I have no specific need. I haven't had a chance to use all interesting programming languages in production work, of course: ars longa, vita brevis...! Right now, I find Python so suitable for the vast majority of my programming that I find myself rarely using any other language besides Python (and C or C++ for extensions, and SQL for relational database work, of course).

EuroPython: So 'Architecture, Design, Methodology', interesting, isn't this a move back to 'hardware', from which you have been driven away?

Interesting suggestion! Software architecture and design, viewed as artifacts, can definitely be considered similar to the same concepts as they apply to hardware. And "methodology" has often been used as a catch-word for "let's make software a true engineering discipline". But that's not what I have in mind. "Getting there is half the fun", or more: the artifacts (except working code that serves customers' needs!) are secondary to the processes that lead to their being developed and continually adjusted. In hardware, once you move beyond the breadboard stage, your architecture and overall design are pretty much fixed. Software is also often approached this way, but it need not be -- not with the right language (and Python definitely qualifies) and the right development tools (which we don't have yet -- not fully -- but if you look at the best development environments for Common Lisp and Smalltalk you'll see what I mean... they've been close to "right" for quite a while now). "Methodology" is then to be seen as an issue of continuing, fruitful, structured human interaction. I'm thinking of "Agile Software Development" and all schools that reflect some aspects of it, NOT of heavy-weight, rigidly-structured methodologies with strong orientation to intermediate artifacts, mind you.

EuroPython: You tell that the right development tools aren't there yet. What do you think of Boa Constructor?

Very good project, and, indeed, IDLE and the commercial IDE's are also quite good, roughly on a par with what you can get for most widespread languages. But these tools don't really address the issues of methodology, design, and architecture, all that much, and surely not for large and interesting problems that involve several developers. One day, maybe, I'll be able to work on the kind of collaboration tools which today I can but vaguely envision -- most likely, that will be on top of the Strakt framework for computer-assisted collaborations... but, more about that later.

Did you already wrote some articles concerning your 'dream' topics?

Only some posts, so far. For example, here's a link to the Google archived version of one such post -- be sure to look also at my other articles on that thread, if you're interested in my opinions about these subjects.

EuroPython: Do you solely work on writing books or do you perform other jobs as well?

Books are what I do in my (proverbially copious) spare time!-) No, really. My full-time work is now as Senior Systems Developer for AB Strakt. We explicitly agreed that "full time" means 40 hours per week -- pretty unusual in the field of software development, but the Strakt founders are unusually clever people, and this is not the only aspect in which their philosophy and practice of software develoment matches some teachings of the "Extreme Programming" school.

Since I'm used to 60+ hours weeks (hard to lose the habits of 20+ years... particularly given that, since childhood, I witnessed my father, a physician, keeping similar working hours -- he's reduced them a bit, now that he's 80, but is still going at it...), I have quite a reasonable amount of time left to devote to writing, editing, and other pursuits not contrasting with my commitment to AB Strakt. From this point of view, I'm almost a freelance. Besides books, I also write articles, do some consulting, speak at Linux meetings, that sort of thing.

EuroPython: 'Extreme Programming', we hear more and more about it, how do you perform it at AB Strakt?

We don't, quite, first of all because we're not exactly in the typical in-house development situation where XP can indeed be applied verbatim -- for example, with "the customer" as a member of the team, able to make the business-value decisions. We do apply some of XP's key ideas, such as 40-hours weeks, pair programming, continuous integration, and lack of "code ownership" through a consensus-defined style guide. More generally, we do apply the general principles of "agile" methodologies, which include but are not limited to XP, as well surveyed in Cockburn's short, excellent book "Agile Software Development".

EuroPython: Can you tell us something of the N-Tier Framework you are developing at AB Strakt?

Ah, now that is a really exciting prospect, too! Strakt people have been working on it for quite a while -- I've been with Strakt for only 4 months, so my own contributions have been reasonably modest so far, but I can at least recognize brilliance when I see it:-). Tier 0 is any good RDBMS: we've been working with PostreSQL so far, also keeping an eye on Oracle, but I'm confident that we could substitute any really good RDBMS (such as, say, SAP/DB, nee Adabas -- or IBM's DB2 -- and so on), as we're not using any deeply nonstandard features. And that's brilliance #1 -- don't reinvent the wheel when Michelin and Bridgestone are eager to supply you with most excellent ones already. Brilliance #2 is that every other tier is in Python. With suitable support by C-coded or even C++-coded extensions where needed, to be sure -- but such needs are quite localized, and mostly rely on existing extensions (DB interface, web interface, GUI, ...). Where Strakt has had to develop its own extensions (for security, using SSL) it has made them Open Source to get the advantages of the open source model (and I count that as Brilliance #3).

And this is where the fun begins! Tier 1, called the "Infinite Filing Cabinet" (IFC), is an O-O database (built on top of a relational DB) like no other, with a strong real-time orientation (you can "subscribe" to some object, or to a query, and get notified in real time each time the object or result set changes) and an intrinsic "audit trail" of changes. Tier 2, provisionally called BL (for "business logic"), builds business objects on top of the services that the IFC provides, so that every other "downstream" tier can deal directly in high-level, application-oriented terms. Moreover, the BL works in a highly modular way, dynamically loading (from the IFC) Python-coded "business logic modules" (BLMs) that do the application-oriented work on top of the BL infrastructure.

One can reasonably count the BLMs as "Tier 3". That is one spot where I did contribute a little, developing a "little language" (actually a collection of Python classes and functions) that lets the BLM itself be coded in application-oriented and quite high-level terms -- terms quite close to an entity-relationship diagram, typically -- although, of course, the BLM author has the full power of Python at his or her disposal whenever the "BLM Little Language" does not meet all needs. Moreover, the BLM can also include, besides business logic, whatever presentation-level information and actions are specific to the application area it deals with -- the presentation level executes in Tiers 4 and upwards (AKA the "front-end" parts of the framework), but the information and specific code that defines its appearance and behavior may still reside in the "back-end" parts of the framework (Tiers 0 to 3) -- coded in the BLM which in turn is stored by the BL in the IFC which puts the bits in some tables of the relational DB. If this makes your head spin, don't worry -- took quite a while for ME to grasp it all, too:-). I think this whole 'back-end' part must count as Brilliances #4 to #8, at least (actually, there are quite a few more than that "behind the scenes", making the whole apparatus work so smoothly and rapidly, but let's be conservative in our Brilliances-count:-).

And so, we come to Tiers 4 and upwards -- the "front-ends", also somewhat inappropriately known as "clients" in the framework. "Somewhat", because some of them are indeed clients -- for example, a GUI client (coded on top of Qt, for cross-platform deployability and performance), and a batch client (which runs Python scripts, of course:-) that we use for such tasks as testing, creating ("populating") sample databases, and so on. But other front-ends are, in turn, servers -- for example, a Web server, coded on top of Webware, which lets web browsers access a substantial set of the framework's functionality (not the real-time aspects, at least not so far -- "push" technologies appear to be somewhat out of fashion, and portable, cross-platform access to information updated in realtime from any standard browser requires some interesting technological choices).

The front-ends are quite open-ended -- together with the ability to write and load BLMs, the front-end architecture is what makes this Framework exactly that -- a Framework, not just a software tool. Let's count all that goes on in tiers 4 and upwards as Brilliances #9 to #12, to round up a conservative dozen, and we'll make it into a baker's dozen by prefixing Brilliance #0 -- all the aspects of agile methodologies, and the human aspects of the AB Strakt team, that made the opportunity quite irrestistible for me when I got the offer of joining it. Consider, for example, that I live in Bologna, able to spend in Sweden less than a week a month, on average -- yet, thanks to AB Strakt's culture, I'm still able to blend in quite well, by teleworking, and I feel as involved, as much a part of the team, as everybody else.

We have lots of plans about deploying and growing this Framework, of course -- starting with a "help-desk" application, built on top of it, which we'll shortly be installing in beta form at our first customer. Integration with all kinds of other systems comes quite natural to the Framework, thanks in part to its own architecture, in part to Python's superb suitability for such integration work. For example, we'll definitely develop integration with e-mail systems, and the like. My own personal pet project is to have a "midget" version of our fundamental GUI client running on my new toy, the wonderful little Sharp Zaurus hand-held... both the GUI client and the Zaurus are based on Qt (via PyQt), which I think will ease my task considerably.

EuroPython: What did you do before you knew Python?

As Senior Software Consultant in think3, inc (nee Cad.Lab, S.p.A.), I dealt with every kind of software development issues except CAD itself (of which I knew, and still know, quite little). During my 13 years there, the firm grew about ten-fold and development moved from proprietary workstations, to Unix, and then on again to Windows; from Fortran, to C, and then on again to C++. I was heavily involved with the technical aspects of this progress -- teaching internal courses, writing libraries, tools, and frameworks to ease migration, acting as a firefighter, mentor, and consultant for every kind of emergency. Interfacing to operating systems, databases, networks, the web -- I did all that, not to mention frameworks for GUI development, COM interfacing, general-purpose event dispatching. It was a great ride (still is, for think3, inc, who's still going strong, despite my departure, and is and remains a superb place to work for)! My only regret is that I was not able to evangelize Python effectively enough to get it officially adopted in the firm: it snuck into several niches, such as sytem administration and the development process, but AFAIK it's not delivered to customers as part of any think3 product... yet. The regret is not on my own behalf, as I count my moving to AB Strakt as a great stroke of luck for myself, but on behalf of think3 itself, and all my friends there -- it's such a wonderful firm, that it would fully deserve using the best of all programming languages!

What do you think of Zope? Would it be interesting to combine Zope with the N-Tier Framework?

It would be a wonderful idea to combine Zope and the Framework -- we do have a web-oriented front-end developed as part of the Framework itself, as I mentioned, on top of Webware, but, of course, Zope is a much richer, higher-level framework for web applications in itself. Both Zope and the Framework are so open to integration that I'm sure they''' play together wonderfully well, for firms who need highly sophisticated web applications and an equally sophisticated, modular real-time "back-end" as the Framework can so well supply.

EuroPython: Did you or AB Strakt already looked in the direction of the development of Zope 3? Are you following it?

Not yet! It's on my personal list of "interesting things too look at when the time crunch abates", though.

EuroPython: Have you devoded yourself completely to Python? With another nickname 'portable library of Alexandria', I assume you're interested in everything. What I wonder however, is how can you keep all this information in your mind? :-)

I've mostly given up on the latter a few years ago, as the advancing years started making my memory gradually sub-eidetic. What I keep there now are, mostly, basically pointers to places where information can be rapidly and effectively looked up -- plus, of course, whatever's already there from the years where accumulating information in my mind was anything but an effort, and those aspects whose intrinsic interest lodges and keeps them there regardless. But I couldn't tell you the exact line-up of Italy in each of its four games in the Cup (although I did suspend all work and join my father to see each of them on TV), nor the exact list of titles and publication times for the novels in the Recherche du Temps Perdu -- I'm anything but a walking encyclopedia these days (I do admit I used to be one... but that was 10 years ago). I suspect the "library of Alexandria" quip is a (respectable!) pun on my name, "Alex", and/or my currently favourite song, Leonard Cohen's "Alexandra Leaving", presumably prompted by the fact that, since a few weeks ago I believe, there is a Library of Alexandria again now, after so many centuries.

But yes, it's true that I can't conceive of a subject that doesn't have some fascinating aspects, if looked at from the right angle -- "Homo sum, nihil humanum a me alienum puto", after all. Among my hobbies is economics: I can't imagine how some people can consider it a dreary subject, it's so chock full of charms! History, too, of course -- poetry -- evolutionary biolory, and many facets of politics. Everything's so inter-woven...!

EuroPython: I know of one hobby, namely Bridge. How did you get in contact with it and where is it place in your life?

I met bridge when I was 13, and a (very) budding chess player -- because bookshops kept bridge books next to chess ones. I was an avid reader of chess books (inter alia) and once purchased a bridge book by mistake -- not suitable for beginners, I was unable to understand all the rules from it, but so fascinating it stole me away from chess forever. As a teen-ager I played a lot of bridge -- although my best results (not very good ones:-) where two 3rd places in Italian National junior team championships. As I started university, then married, and moved away from Bologna for years, I kept playing bridge on and off, when the fascination came back stronger than the undeniable fact that there always were so many other claims on my time.

The only mark I've left on the game of bridge, so far, is a little piece of research work. As double-dummy playing engines became available and usable on PC's, I started musing about the ways those shiny little new toys could let us apply in reality Culbertson's abstract principle of hand-strength evaluation. I kludged together a strange apparatus (C++ programs, Perl scripts, quite a mess) and came up with some great results. They were published in the most prestigious journal in the field, The Bridge World, quite a bit later than I had obtained them, in January and February 2000. Actually that's quite a large reason that drove me to Python a bit earlier -- I was looking for some more reasonable way to develop a bridge-research framework than that unholy, unmaintainable mess of C++ and Perl. Unfortunately, the intrinsic charm of Python itself and its infinite posibilities then stole me right back from bridge again. These days, I manage maybe once a week to spend a couple of hours playing online -- often with my son (now 19, and a brilliant student of financial economics). But, hey, I will be back to bridge one day -- just as soon as I've handled all the other more pressing demands on my time...!-)

Unfortunately, I don't think those articles are available online -- if you're interested, you'd have to lay your hands on the actual January and February 2000 issues of the Bridge World magazine (here's a link to their site, just in case). I used to post a lot to newsgroup rec.games.bridge, and using Google's advanced group search to look for my posts there would surely put together most of the actual substance of the articles, albeit in a fragmented and disorganized manner. Yet another thing to put right one day, when I can find time for it...!

EuroPython: What do you expect from EuroPython2002?

Mostly to meet (or see again, in some cases) and interact with a lot of interesting people. Anybody smart enough to be interested in Python must by definition be an interesting person, and I most definitely look forward to meet as many of them as possible!

EuroPython: Thanks alot Alex, you are a wonderful speaker.

...albeit at times a bit too colorful and/or passionate, I guess, but of course that goes with being Italian...:-).

I think we could go on forever, which is something we better leave for during the conference itself when we can actually meet each other.

Good point. Virtual beer is never quite as refreshing as the real kind.

EuroPython: I noticed that you like to quote people, do you know of an appropriate one to end this interview?

"Good night, good night! Parting is such sweet sorrow, that I shall say good night till it be morrow"...:-)

Editor Note: Well, well, well, didn't knew you were so romantic..., but afterall you are an italian ;-)

Url links to which referred during the interview:
Martelli Bot: http://groups.google.com/groups?selm=8ubclp01s4t%40news1.newsguy.com
Boa Constructor: http://sourceforge.net/projects/boa-constructor/
Dream Topics: http://groups.google.com/groups?selm=NRYX7.411%242F4.13671%40news1.tin.it
Bridge World: http://www.bridgeworld.com