Thursday, August 31, 2006

Languages I Use

Continuing in the getting to know you kind of vein, I thought I'd ground some of what I say by talking about the three programming languages that have made up the bulk of my professional and hobby work for the past five years or so -- Java, Python, and Ruby.

Java: I've been programming Java since either just before or just after the 1.0 release... can't quite remember at this point. I think I've covered most of the major Java libraries (although I've done very little EJB work). Basically, Java is the station wagon of programming languages. It's not elegant or efficient, but it gets you where your going and you won't offend anybody along the way.

Far and away the best feature of working in Java is the tool support, especially the IDE support. If you're doing something in Java, odds are somebody has done it before and there's an open source .jar file somewhere that will help. Plus, IntellJ IDEA makes working in Java almost as productive on a time-basis as working in a scripting language.

Java is, of course, famously verbose, and there's the constant sense of telling the compiler things that the compiler should already know. (The 1.5 language features improve this somewhat, at the cost of moving some of the verbosity elsewhere). Java's original design goal was basically to get C programmers to do object-oriented stuff without scaring them away, and at that it's a success, but that does lead to oddities like having both basic types and object wrappers for them, and keeping the ridiculous C-style switch statement.

There's also the "Java style" of OO design, enshrined early on by Sun, and followed by many third-party libraries. To oversimplify, there's a lot of design made complicated by the desire to make less common tasks as privileged in the API as more common ones. For example, the need to spell out what are basically boilerplate properties in a web.xml file or a Struts config file. Swing has several features like this, including the event system and say, supporting multiple listeners for a button click.

Python: With Python I suppose you have to start with the whitespace thing, although I know that anybody who actually works in Python is sick of hearing about it. I wrote what I hope was a spirited defense of it in the Jython book, and I'm not going to repeat myself. What I like most about working in Python is the conceptual consistency -- objects are like classes are like modules are like dictionaries. I find that to be a very powerful equation, and it makes Python code more predictable to me. I also think the syntax is very clear and readable. (I particularly like the list comprehension syntax.)

On the down side, although there probably is more Python libraries than Ruby ones floating around (although I'm not as sure of that as I was even a year ago), there's no central repository so they are harder to find. It is true, though, that Python style quirks are more likely to bleed into my programming in other languages than vice-versa -- I write a lot of Java code that really looks like it wants to be written in Python.

Ruby: I actually got into Python, Ruby, and XP at about the same time. I started on Ruby because a number of the early XP gurus were excited about it. And while I know I'm supposed to pick a side or something, I actually like Python and Ruby both quite a bit. There are some particular bits of Ruby syntax that I think are particularly well done, for example the way that accessors are handled. I even like that you can leave parentheses off method calls if the line is unambiguous, although a little of that can go a long way. Blocks make the language very flexible, and very easy to build non-redundant code in.

There are a couple of pieces of Ruby syntax that make me nervous, like the syntactic sugar for hashes as the last argument of a method or the way you don't have to specify that a block is needed in the signature of a method. To be fair, I haven't experienced practical problems with these features yet. Ruby has a lot of syntax sweetener compared to Python, which is sometimes good (elegant Ruby code is very elegant) and sometimes bad (I've had some trouble following Ruby examples if they are very magical). Because Ruby has been the focus of a lot of XP/Agile writers, the testing tools and general XPish support is very good. For a long time, I thought that general library support lagged Python, but that's becoming less true daily. And of course there is also Rails, about which more at another time.

Sunday, August 27, 2006

Code Complete: An Appreciation

It's been about 25 years since I first typed 10 PRINT "HELLO", and in that time I've read dozens of books aimed at making me better at creating software. There are several things I want to do with this site, but certainly one of them is to recognize those books that had a particularly strong impact on my professional career.

The first one is Code Complete, by Steve McConnell. It stands out on the shelf because it's not about learning a new language, tool, or discipline, and it's not a big picture rethinking of software engineering itself. Instead, it's a series of presentations of empirical data about specific features of the coding process, as well as very specific examples of how to generate elegant, readable code.

I read this book the summer before I entered a graduate program in Computer Science, in a defensive panic that I didn't know enough actual programming. As soon as I finished it, I started rewriting my existing programs to align with McConnell's suggestions, and I've never really stopped. In particular, the sections on control structures and layout paint a clear picture of what maintainable software looks like in practice, simply be setting out the principles and demonstrating them example by example.

The book's influence is all the more amazing because its examples are in langauges (C, Basic, and Pascal) that have not been useful to me professionally. (I had stopped using Pascal by the time I read it, wrote a little Visual Basic since, and probably an even smaller amount of C). The basic ideas, though, are adaptable to any declarative language. There's a second edition, dated to 2004, that I haven't read, but which I understand updates the data and examples in the book (the examples now include Java and C#). (Come to think of it, I probably should check it out...).

It's rather amazing to me that so many of the Amazon reviews of this book still, nearly fifteen years after its original publication, say that there's no other book that covers this kind of ground.. the kind of pinhole cleanup of code that is so much of the difference between a great program and a mess. I actually think there are one or two other books that cover similar ground, but it's clear to me that this is a gap in the kind of knowledge about programming that is shared. This book will make you a better programmer.

Saturday, August 26, 2006

Occasionally Asked Questions

I wouldn't say it happens often, but I do sometimes get asked some questions about being a technical author. Seemed like a good place to start.

For a long time, the most common question was Did you pick the animal on the cover of the Jython book? The answer is no. The cover animals are picked by the O'Reilly production team, and the mechanism they use for assigning animals to books is somewhat mystical. I think we could have rejected it had we had a really strong reason (I know of at least one other book that has). For the wxPython book, Manning offered us a selection of a few different art figures, and we also picked the color of the spine.

The other most common question is something like Can you make a living at this? or more generally, how publishing finances work. I'm not a complete expert, but I suspect my experiences generalize. Tech books are generally sold on the basis of a proposal (in contrast to fiction novels from new authors, which are usually not sold until the book is complete). Publishers generally describe their proposal formats on their websites -- I can't talk as much about that part of the process because I came in after the proposal phase in both cases.

The contract specifies payment as an advance and a royalty rate. The advance is paid up front in stages as the book is completed. There's room for negotiation on this, but it's typically something like 1/3 on signing, 1/3 at the halfway point, and 1/3 when the final manuscript is approved. My sense is that newbie authors can expect an advance in the mid to high four digit range. The royalty rate the amount of each books sale that goes to the author (the amount is based on what the publisher is paid by the store, not on the cover price of the book). However, the amount of the advance is subtracted from the royalties -- the author does not see additional payment until the total royalty amount exceeds the initial advance. At this point, the book is said to have "earned out". In case you are wondering, the author does not have to return the advance if the book never earns out -- the advance is a gamble by the publisher. A typical royalty rate is about 10%, but some publishers (notably Pragmatic) offer more. If there is more than one author, than the authors decide how the money will be split among them, and that split is also enshrined in the contract.

Oh, and if you have an agent, then the agent typically takes %15 percent off the top. Typically, they earn it, too, either by getting the contract in the first place, or by dealing with the publisher when you don't want to.

Tim O'Reilly said on his blog some time ago that the typical O'Reilly book earns about $15,000 for it's author. In my case, however, we earned less than that, since the Jython book has yet to earn out. In fact, it will probably never earn out -- in fact, based on the figures O'Reilly gave in his post, it's probably among the lowest selling O'Reilly books ever (at around 6000 copies or so), so I've got that going for me. I haven't gotten sales figures on the wxPython book yet, but it's Amazon ranking has been pretty good, so I'm hopeful.

I've just started writing some articles for sites like IBM developer works, which is more lucrative on a per-word basis, but I'm not planning on quitting my day job anytime soon.

That'll do for now. As I think of some other questions of interest, I'll post them here.