Text Auditor

I hate Microsoft Word. I feel that I came by this rightfully, after a whole book's worth of numbered lists that refused to line up, images that refused to stay put, and the truly irritating indexing interface.

For a long time I'd sort of rant about how word processing was this core user task and we still couldn't figure out the right UI for it. I'm not totally backing off that, although I've also read people ranting that text editing was solved 20 years ago by Emacs and Vi, and there's no point in looking at anything new, which achieves a level of crankiness that makes me look calm.

What occurred to me as I was thinking about writing about text entry and UI was the sheer number of different programs that I use for various kinds of word processing or text editing. Most of these are optimized for a specific set of activities, and do that particular job well enough that it's worth learning a new program in order to get that benefit.

More and more, I find myself also using tools that help me with text cross-applications, like generic text expansion tools, or clipboard history tools, or even monster aggregators like Quicksilver. Put that way, it sounds a little bit like the OpenDoc dream, where your spell checker would come from one place, and your text editor from another, and the font manager in from another. But OpenDoc was about components instead of applications and looking at the list below, it's pretty clear that applications aren't going away anytime soon...

So here's a list of all the apps I can think of that I do some kind of text edit in, with some comments.

Adium/Pidgin -- IM Clients (Adium Mac side, Pidgin in Windows, plus another couple for internal work things). None of these has a ton of text editing support, although I do wind up typing a fair amount of text into them over the course of day. Pidgin has a great name, but I really wish it had one piece of AIM functionality, namely the ability to read text in a different size then you send it.

Eclipse -- Currently it's my Windows side Ruby/Rails editor of choice, although I'll probably change my mind six more times before I settle on something. It's also my Windows Perl editor of choice, as it seems to be the only free editor that does syntax checking.

GMail/Google Docs -- Gmail, obviously, used for email, although I do sometimes use it as quick storage for text I want to be able to work on from multiple locations. You're supposed to use Google Docs for that kind of thing, and I do, sometimes. It's great for collaborating (we used it for final notes on the manuscript for the wx book, for example). But for normal use, it's just a hair too unresponsive, and the UI is just a touch awkward within the browser.

IntelliJ IDEA -- Java editor of choice. Still the most fully featured of the big Java IDE's, although the other's are catching up. A big memory hog, though.

jEdit -- Window's side default text editor, especially for Python. Been using it for years. Very nice feature set, I'm used to the controls, decent syntax coding for the languages I use.

Jer's Novel Writer -- I don't use this as much as I'd like, but I'm putting it in here as a great example of tuning a text entry program to a specific use. In this case, writing fiction. Nice features include easy annotating and the ability to specify separate display and printing formats -- very useful for keeping your print document in manuscript format.

MarsEdit -- Well, I'm writing this post in it. Mac side editor of choice for blog posts. Why did I spend $25 on this when it's functionality is pretty easily replicated from TextMate? Good question. It's got a very clean UI, and I like that it previews while you type. And if I need to do something fancy, it interfaces with TextMate.

MS Word -- Windows word processor when forced to use it. Word actually isn't that that bad if you stay within the confines of a four-page office memo. Once you add styles, though, it's a mess. Actually, I don't think anybody's really solved the UI for a WYSWIG styles system -- which is one reason why I use HTML, Textile, or Markdown where I can. I feel like I have much greater control over the styling if it's all in text.

NeoOffice -- Mac side word processor of choice, although I rarely use it for the reasons given above. I've gone through all the free or free-to-try alternative word processors on the Mac, and NeoOffice is the one I keep coming back to (especially since the newest version, which fixed some performance issues).

Outlook -- Windows email program. Possibly the worst styled text email editor around. I think it's the only one that, if you insert a paragraph in the middle of a quote from a previous email, keeps the quote formatting on your new text. This is, shall we say, not helpful.

PowerPoint -- I guess it's a text editor, of sorts. This is here mostly for a mini-rant... I know that everybody says that effective presentations should have minimal text on each slide. I even agree. But... in many environments, including lectures and a lot of corporate situations, the slides become a de facto deliverable to people who are unable to make the original meeting. If you don't have enough text for those people to follow along, they will get angry...

TextMate -- Mac side programmer editor of choice. I tried a number of different editors when I switched to Mac and realized that jEdit didn't really play nicely with OS X. I find the TextMate UI to be unusually clean, and it's the most powerful and extensible text editor not written in Lisp.

VoodooPad Lite -- Mac desktop Wiki application. I'd probably use this more if my daily work were Mac side. It's very nicely done.

That's a lot of applications. I'm pretty sure I missed some, at that. I think my point is that specialization is the way to solve the text UI dilemma. Still, needing 13+ apps to solve my basic text entry needs.... seems less than optimal somehow.

A Program Note

This is for the two or three of you that are subscribed to this blog via RSS feed -- I've just added a FeedBurner feed, and if it's not too much trouble, it'd be great if you could switch over to it at:

http://feeds.feedburner.com/10Printhello.

The "Subscribe" link in the sidebar will also work.

Thanks.

An Agile Musing

Of course, since I muse in an agile way, I reserve the right to change my mind based on future developments...

Software development usually takes place in a complex environment where your goal can change quickly. In general, there are two ways to deal with a complex environment. One is to try to anticipate, in advance, every possible permutation you might need to deal with, and the other is to manage your environment with the flexibility to respond to new challenges with minimum effort. Software is just a specific case where that challenge plays out.

Of course, being software engineers, we've given these approaches names. They are nicely defined by James Bach:

agile methodology: a system of methods designed to minimize the cost of change, especially in a context where important facts emerge late in a project, or where we are obliged to adapt to important uncontrolled factors.

A non-agile methodology, by comparison, is one that seeks to achieve efficiency by anticipating, controlling, or eliminating variables so as to eliminate the need for changes and associated costs of changing.

It seems worth pointing out that, at least in theory, there's no reason why you can't both make a reasonable effort to find potential changes up front, and still make your working environment as flexible as possible.

In practice, of course, this is kind of difficult to do well. There's a logistics problem -- the kinds of things you do when you're trying to control change up front generally involve creating a lot of models and documentation and the like. This is exactly the kind of thing that works against minimizing the cost of change. But it seems to me that a group determined to do some up front analysis of what will largely be an agile process could manage to work around that.

The bigger problem is an issue of mindset -- if you think that you can solve all your design problems up front, then you start to look at any change to the design or implementation with suspicion. At that point, any change is, by definition, a mistake of some kind. Which leads to suspicion of all changes and can mean all kinds of tracking and procedural overhead that pushes up the cost of change. The sort of organic, bottom-up design that you get from test-first and tight iterations doesn't fit in this model at all.

Although I should say that in my experience trying to get groups to adopt XP or agile practices over several different companies is that nearly all programmers and managers agree that automated tests are a good thing. Most programmers are at least willing to consider the idea of test-first, although getting somebody to do it consistently is tough (hey, it's tough even for somebody who's totally bought into it).

The resistance I do get tends to be around the idea that you can start programming with an incomplete design without it leading to disaster.

Waterfall-style up front design can be incredibly seductive. You're brainstorming with other smart people, you're solving all your problems before they even come up. It certainly feels like you are doing something vitally important to the success of your project. Even if you know that many of the decisions will later be revised in implementation, it still feels good to have that crisp UML diagram. You can't have bugs in a UML diagram. The issues that do get solved in design are assumed to justify the time cost of the design, because the assumption is that the time cost of later improvements will be much larger (which is true, in part, because of the amount of design work).

In contrast, starting coding with incomplete information can feel risky, especially the further you get from the actual implementation team. Any issue that gets changed later can be blamed on the relative lack of design, true or not, and the time savings from not doing as much design can be invisible. It's very hard to let go of the idea that all your design problems can be solved up front. But once you are willing to allow that some problems can only be solved in the moment, you're much better equipped to deal with the inevitability of change.

State of the Art

O'Reilly Radar has been analyzing the state of the computer book market on a quarterly basis for a couple of years now.

This link is to a drill-down into the Q1 2007 results for programming languages. The information is of some passing interest to me, both as an author and as language geek.

Things that jumped out at me.

• Ruby is up a ton, and is now selling more than Perl and Python combined. There are now as many Ruby books in print as there are Python books.



• Two of the top five books are Rails, with number one being PragProg's Agile Web Development with Rails. Two of the remaining five are Head First books.



• But Javascript sells almost twice as many books as Ruby, and is also growing quite a bit. I still see the occasional thought that Javascript will escape the browser and become the language of the future. It certainly seems to be gathering the base.



• The numbers have just under 10,000 Python books sold in Q1 2007. I don't have the wxPython book numbers for that quarter yet -- results to authors are delayed a quarter, but that means that the wx book was roughly 10% of the overall Python market. I can't decide if that surprises me or not.



• It's funny how your personal perspective skews expectations. In the abstract, I know there have to be a lot of Microsoft shops out there, but I've never worked at one, so it's surprising to see C# and .NET so high on the list. I'm currently surrounded by a lot of IT Perl experts, so it surprises me a little to see Perl so low, even though it probably shouldn't.

from internet import *

Three posts that caught my eye today.

Ruby School

Gregory Brown over on O'Reilly net has an article about using Ruby in Computer Science courses, at least in later algorithm classes. It's not a bad argument, but I think it'd be more convincing if the Ruby example was a little cleaner and easier to read compared to the pseudo-code.

Let's see... The last time I had to care about this issue was about eight years ago when my grad institution was going through a somewhat controversial revamp of the CS curriculum. The fight, as always, is between the theorists and the pragmatists. The theorists want to teach a lot of "pure" CS up front -- Turing machines, big "O" analysis, computational theory, that kind of thing. The pragmatists want the students to be able to get jobs.

You should know that I spent the better part of three years as part of a group working with an object-oriented class that we taught in Squeak Smalltalk. Lovely language, to be sure, but we had to spend part of every course explaining to some nervous students why we weren't teaching them C++ or Java...

At the time, the initial CS classes were moving to Java, with some relief. This is because a) nobody wanted to inflict C or C++ on unsuspecting new CS majors, and b) the previous most common language, Pascal, was woefully obsolete. Java is reasonably straightforward to teach and is actually used in real programs, both high points.

Personally, I think you can make a pretty nice case for a scripting language like Python or Ruby in the initial CS class. They are both pretty easy to get started with, the syntax is clean enough that algorithms are easy to visualize (which was Brown's original point). In Python you can do it without introducing objects (which most CS1 classes didn't do eight years ago, don't know if that's changed). In Ruby it's easy to teach meta-programming.

Cha-Ching

Paul Julius of ThoughtWorks about how CruiseControl can save you $12,535 per broken test. The money coming from the difference between the cost of fixing a bug immediately versus not catching the bug until integration testing.

I dunno. I love continuous integration, and would shout about it from the rooftops if they'd let me on the roof, and that number still sounds a bit more "look what I can do with numbers" than "look what I can do with Continuous Integration". But then I'm skeptical of nearly every numerical analysis of programming productivity.

Plus, Marshmallows

Over at Roughly Drafted, Daniel Eran goes on about the smooth, harmonious relationship between Apple and Sun. Naturally, I want to talk about one of his sidebars...

The name of Apple's Mac OS X frameworks was even named Cocoa in part to associate it with Sun's Java. The other reason was that Apple already owned the Cocoa trademark, having using it earlier for a children's programing environment.

You know, I've always wondered about that. The original Cocoa was a project that was being worked on in Apple's Advanced Technology Group the summer I interned there, plus it some buzz in Educational Technology circles for a while. Internally, it was called KidSim, but the name was changed to Cocoa when it was being prepared for release. Java was programming for grown-ups, so Cocoa was programming for kids. It seems like Apple isn't really using that connotation of the name anymore.

The project (now called Stagecast Creator) is a graphical rule-based programming language, something like a cellular automata program. The user specifies an initial arraignment of sprites on the screen, then specifies how that arrangement should change in the new time slice. Complex programs could be created with almost no typing (although, like all such programs, you still had to use drawing tools to create your own sprites -- that was still hard). Stagecast still seems to be around, although it's been ages since I tried the software. It was pretty cool, though.

Comment On This

So the other day I'm looking over some code, and I see this... (slightly paraphrased to protect the innocent -- in the original, the declaration and the getter were, of course, separated.)

/**
 * The name of the user
 */
private String m_userName;

/**
 * @return The name of the user
 */
public String getUserName() {
    return m_userName;
} 

And I thought, "I really hope some of that was generated by the editor"

And then I thought, "This is why other languages make fun of Java"

And I finally ended up with, "Most of what beginning programmers are taught about comments is useless". At least that was true when I was in school.

For the moment, I'll put aside the Java issue, to talk more generally about comments.

First though -- we're agreed the example is absurd, right? In that it repeats that the user name is, in fact, the user name five times. Which is at least four more than strictly necessary (I realize that Java more or less forces some of this duplication).

I realize that this is hardly the worst coding sin you can commit, but when I look at code like that I do think that either the programmer isn't quite sure which parts of his code are most important or that the person is rigidly following an overly formal standard. Neither of which is all that flattering.

About 95% of the time, it seems like you either get no comments, or the kind of useless comments in the example. Given the choice, I'd rather have no comments -- it's less distracting, and you can see more code at once.

However, you can do comments effectively. Here's what I think, which should not ever be confused with what I actually do.

• The best commenting is clear and accurate names for your variables, functions, and classes.



• The "No Duplication" rule applies to comments at least as much as it does to code.



• Possibly more, since no compiler is ever going to catch if your comments fall out of sync with your code.



• Therefore, under normal circumstances, comments should avoid repeating what the code does.



• However, limitations on input or output values that are not apparent from the code should be included in comments. If the user name was guaranteed to be under ten characters because of the underlying database, that would be a useful comment.



• Rationales for choosing a particular implementation are often good comments, as is the code's place within the larger program.



• If you find yourself commenting inline within a long method to explain what the next section does, odds are you'd be better of extracting that to a well-named method and skipping the comment.



• There is a cost to commenting -- it takes time to do well, and it can be distracting. It also limits the amount of code you can read at once.



• The most obvious exception to all of the above is when you are in a situation where people will read your comments without ready access to the source code. Writing an API or a framework, for example. In that case, most of the issue about duplication doesn't apply and you need to be descriptive for the benefit of users who will only see your JavaDoc or RDoc.



• However, none of that excuses writing a one line comment for getUserName().

Fame and Fortune 2

To continue on the fame and fortune theme, I just got the first part of the statement wrapping up the first year of the wxPython book. (Since the book came out at the end of March, we got a first quarter statement which covered the first 10 days of the release). Anyway, I'm pleased. The fourth quarter statement was only about 5% down from the third quarter (I don't have the exact numbers). This is rather amazing to me, since the Jython book dropped about 50% from quarter to quarter over its first year. I think, but am not 100% sure, that the wx book has now outsold the Jython book. If it hasn't now, it will next quarter.

Which makes this a good place to again thank all the people who have bought the book, read the book, and said nice things about the book. It's all appreciated.

Fame And Fortune

Well, the Jython Book celebrated it's fifth anniversary with a royalty statement showing that it had sold the grand total of two copies over the previous quarter.

I think it might be played out. O'Reilly's statements don't give total accumulated sales count, just total accumulated royalties. I think it sold just on the low side of 6,000 copies, and is something like 500 short of earning out.

Meantime the wxPython book still seems to be holding it's Amazon rank, so I'm very curious what the next sales total is going to be.

Posting to Blogger via Ruby

TextMate has what seems to be a very nice blogging bundle for programmatically sending posts to your blogging engine of choice. Except that it doesn't work for the new Blogger API. Or at least it didn't the last time I checked. Mostly I just wanted to see if I could write my own script to send to Blogger.

This is a Ruby script based on the Python script located at http://djcraven.blogspot.com/2006/10/success-posting-to-blogger-beta-using.html -- the author of that script did the heavy lifting in terms of the GData API calls, what I did was translate it into Ruby in a somewhat more flexible structure. At least I hope so. I also hope this will look like decent, idiomatic Ruby and not like a horrific hack. And I'd like a pony. If you're asking.

Let's do this in pieces. The first piece of the puzzle is using the Google ClientLogin API to get an authentication token. The token is then passed as a parameter to later calls when we actually want to post something. Google says that the lifespan of the token is dependent on the application being used, but I don't see where they specify how long Blogger keeps them.

Here's the start of our class. We're in a module called Blogger and a class called Blog. I've got an external dependency here on BlueCloth because I'm also going to automatically translate Markdown later, but that's not something you need to do...

  module Blogger

    require 'net/https'
    require 'net/http'
    require "uri"
    require "bluecloth"

    class Blog

      attr_accessor :account, :password, :blogid

      @@auth_url = "www.google.com"
      @@auth_path = URI.parse('/accounts/ClientLogin')

      def http
        http = Net::HTTP.new(@@auth_url, 443)
        http.use_ssl = true
        http
      end

      def request_data
        ["Email=#{account}", 
         "Passwd=#{password}", 
         "service=blogger", 
         "service=TestCompany-TestApp-0.0"].join("&amp")
      end

      def auth_headers
        {'Content-Type' => 
            'application/x-www-form-urlencoded'}
      end

      def auth_token
        response, data = http.post(@@auth_path, 
            request_data, auth_headers)
        return nil unless response.code == '200'
        data.match(/Auth=(\S*)/)[1]
      end

After the setup lines, we've got three methods here. The first two define the data objects. The first one creates a Ruby HTTP object, set up for an HTTPS connection to the Google ClientLogin URL. The second builds the request data string, tying together the four pieces of data into a single string. They are both used in the auth_token method -- I'm taking advantage of one of my favorite features of Ruby, which is the lack of distinction between local variables, no-argument methods, and data field getters.

So, http, request_data, and auth_headers are just dropped into the auth_token code as if they were local, even though they are separate methods. To me, that makes the code read cleanly, and encourages moving small bits out to separate methods where they can be separately tested and documented.

The auth_token itself takes the path, the request_data, and the headers, and uses the HTTP object to make a secure post call. Request data, by the way, has account and password information that I'm assuming would be defined in an abstract subclass of this Blog class. If the response code is 200, we're good to go, and we do a little regular expression magic to extract and return the authentication token.

We use the authentication token in our actual post call, the one that contains the blog post itself. We need to build up the XML Atom document to send to the Blogger server. Step one is to get the data. Since I'm going to be doing this from TextMate, I'm going to assume we're going to start with the file name that will eventually be provided by the TextMate command. First, we'll convert it to an array of lines.

    def read_data(filename)
      text = open(filename) { |f| f.readlines }
    end

In case it's not already clear, this method and the ones that follow are all parts of the

Blog

class. We're splitting this into lines to facilitate some processing of the text. I'm assuming that the first line of my file will be the title of the post, the second line will be a comma-delimted list of category labels, and the remainder of the file will be the body, written in Markdown. Obviously, that specific format is a weird quirk of the particular blog I'm posting to, which is set up to take XML and not to preserve blank lines. In your case, do whatever you need to do. Building that data structure
is quite simple in Ruby.

    def build_data(lines)
      categories = lines[1].split(",").map {|c| c.strip}
      body = BlueCloth.new(lines[2..-1].join(" ")).to_html
      data_xml(lines[0], categories, body)
    end

The last line of build_data calls the data_xml method that builds up the XML document:

    def data_xml(title, categories, body)
      result = []
      result << "<entry xmlns='http://www.w3.org/2005/Atom'>"
      result << "  <title type='text'>#{title}</title>"
      for cat in categories
        result << "  <category scheme='http://www.blogger.com/atom/ns#' "
        result << "            term='#{cat.strip}'/>"   
      end
      result << "  <content type='xhtml'>"
      result << body.to_s
      result << "  </content>"
      result << "</entry>"
      result.join("\n")
    end

I was going to use the REXML library for this -- normally I'm a big fan of building XML programatically. However, REXML really, really didn't like it when the included content contained HTML tags. So I decided it'd be much less aggravating to build the XML from scratch. Details on the syndication format can be found in the GData and Atom online docs.

Once we can create the data, we can finally make our post:

    def post_headers
      {'Content-Type' => 'application/atom+xml', 
          'Authorization' =>"GoogleLogin auth=#{auth_token}"}
    end
    
    def uri
      "http://www.blogger.com/feeds/#{blogid}/posts/full"
    end
    
    def post(lines)
      response, content = http.post(uri, build_data(lines), post_headers)
      while response.code == '302'
        response, content = http.request(response.location, entry.headers)
      end
      return response.code == '201'
    end
    
    def post_file(filename)
      post(read_data(filename))
    end
  end
end # of module

Couple things to point out here. First, we call auth_token directly when we're building up our header in preparation for the call -- so that's when we perform the HTTPS login shown above. The while loop takes care of following along if Blogger decides to redirect the post. Finally, we return true if Blogger sends us an OK response code 201, meaning the post has been successfully added.

To use this, you need to set up your own subclass of Blog with the expected information, for example.

 class MyBlog < Blog
   def initialize
     @account = "YOUR_GMAIL_HERE"
     @password = "YOUR_PASSWORD_HERE"
     @blogid = "YOUR_BLOG_ID"
   end
 end

As written, that would be included in the Blogger module, otherwise, you'd need to qualify the name Blog. The invocation of the whole thing looks like this. This assumes that the filename with the post is in ARGV[0], placed there by TextMate.

p Blogger::MyBlog.new.post_file(ARGV[0])

One problem, though. We're making an HTTPS connection for authentication to keep our password secure, but including the password in plain text in the script file. Good point. There's a cool way around that in TextMate, and probably

Rubies in My Coffee

Now two of the big Java IDE's are promoting Ruby language tools as a big thing. IntelliJ has a plugin in early beta, and NetBeans is also making a big deal of their new early beta support. Eclipse has had a Ruby/Rails plugin for about a year or so.

This is weird, weird, weird, that suddenly all the Java tools would feel the need to grow into somewhat ill-fitting Ruby IDE's (Eclipse has always styled itself as more of a meta-IDE, so that's a little less strange). But do we really need all these Windows Ruby IDE's to be attached to big, memory hogging, Java tools. (And in IntelliJ's case, I say that with love...)

I've played with all three now -- I've used Eclipse for Windows-side Ruby editing for a while, and for the last few days I've been going back and forth between IntelliJ and NetBeans checking them out on an existing Rails project. None of the three are going to make me ditch TextMate yet (although I'd say the big tools all have somewhat more developed project support that TextMate).

IntelliJ's plugin really strikes me as Not Ready Yet. For one thing, there's no syntax checking on .rhtml files, which is a big problem. Also, there's a cool Rails project view, that associates the .rhtml files with the appropriate controller method, but there didn't seem to be an obvious way to get to partial .rhtml files. Another minor frustration is that the Ruby syntax layout is not customizable yet, the way the Java one is. It's even hard to keep a separate setup so that Ruby files only have a two character indent. (And there's a good sociology of programmers paper, on why Ruby is canonically a two character indent, not four).

This seems like a good place to point out that I still haven't spent all that much time with any of the new tools, so it's entirely possible I just missed something. For instance, even though the IntelliJ docs say there are Live Templates for Ruby, my installation didn't seem to have them.

There's some nice stuff in the IntelliJ tool -- all the ctrl-N navigation works on Ruby classes and methods. It's very easy to run arbitrary Rake tasks from the UI (although they seem to run kind of slowly) I don't think syntax completion is there yet, but it does syntax check .rb files on the fly I'd like to see this one a few revs down the line.

The NetBeans tool is in their beta for version 6 (you have to download the tool, then grab Ruby support via the update center). I was kind of amazed to be liking this because I fled NetBeans in a huff around version 3 and haven't had any success in trying it since. The syntax coloring and layout seems to be a bit stronger. It appears to be using JRuby not just for internal parsing, but also as the default external engine for running, say, WEBrick. Which makes everything feel a little slow. There is some syntax-completion -- I found it a little hit-and-miss in terms of getting useful alternatives. The project view is nice -- it flattens out all the /app subdirectories, but I couldn't see an obvious way to run arbitrary rake tasks or the test suite. Although there is a keyboard shortcut to run an individual file, and if you try it in a view page, it attempts to open that action in a browser. My app has a slightly nonstandard route configuration, though, so it didn't quite work for me.

I also had some stability problems, mostly with trying to run the server from NetBeans, it either hung or took a really long time to load. Development on this seems to be progressing rapidly -- they are releasing new versions much more quickly than IntelliJ, so all these things could be fixed by Thursday.

Right now, NetBeans would be my pick of the three if I couldn't use TextMate. I'm as surprised as anybody by that conclusion, but it felt pretty good as I was using it. Adding easy test hooks would help. All three tools are still under development (RDT for Eclipse just released a new version, and RadRails just passed to a new owner with new development promised). So, watch this space, I guess.

Update: Looks like NetBeans has a bug in reformatting code -- it kind of messed up some of my source files. Nothing permanent, just kept indenting and not noting the end to outdent so the file kept creeping to the right.

Wow, There Are Comments

It's true -- the way to get comments on your blog is to mention Apple... I do something like one substantive post in three months, and then two apple posts in 48 hours, and bang! Four comments within a day. I'm surprised, not least because I really wasn't sure anybody was out there.

Anyway, interesting points have been made, and I thought I'd pull them up to either agree, or whine defensively.

On the Win 95 post, Massive writes:

My observation at the time was that the 'competitve analysis' of the OS features and capabiltiies was basically bogus and totally irrelevant. I felt that Apple wasn't whistling past the graveyard so much as completely lying to itself.

You say "tomato", I say "tomahtoe". There was a lot of denial in the air, that's for sure.

Still Massive, about the impact of Win95 on end users:

You could already, with Windows 3.1, show demos rigged to look identical between Mac and the Windows apps. And people were sufficiently ignorant about computers at the time that they would actually buy Windows 3.1 and tell people that it was 'just like the Mac'.

I can't really disagree with that, but I still think the general point that Windows 95 brought the two platforms much, much closer together holds. I certainly remember that to be the theme of much of the Win95 press coverage. I also remember Apple's slogan "Windows 95 = Macintosh 89". Y'know, Apple's marketing also kind of stunk in that period...

Massive also mentions that Apple had a poor relation with the dealer channel and that didn't help. Also true. As far as I can tell, still kind of true.

On to the internet posting, a couple of people comment on some other facets of how Microsoft eventually took over after they decided to start competing in browsers. Right, but there was a time when it was not yet clear that they were going to be willing and able to do that.

One anonymous poster did bring up a long-buried memory:

Nonesense. Apple's initial 'internet strategy' was CyberDog, which was a fantastic set of tools (web browser, mail client, etc ) unfortunately chained to the technological boat anchor that was OpenDoc.

Mike, is that you? Mike Pinkerton, who went on to create Camino, was the only person I knew who used CyberDog. I remember him as being very enthusiastic about it, but it was about 10 years ago, so I could easily be wrong. It did indeed look cool, but I recall the setup as being kind of daunting, and OpenDoc was kind of a pain in the neck. Also, CyberDog came out in 1996, and by then Microsoft had already moved in.

Thanks to the commenters -- I like responding, and it's a good way to get a post, so by all means, keep writing.

Apple Dot Net

What is it about us tech fanboys and Apple... I've always found them interesting, even when I wasn't a regular Mac user. Infuriating, sometimes. But interesting.

So here's another thing about Apple, circa 1995... That was right about the end of something like a two-year period where Apple was way ahead on internet integration and didn't really make anything out of it. By the time the internet really started to escape out of academia, the Windows world was well on it's way to catching up, and by the time it all really went mainstream, Macs would be a fading memory. (I remember as late as 1995 impressing non-techy visitors to my grad school office with demos of a web browser. But a year later, the cat was largely out of the bag.)

But in 1994/1995 it was all Macish. Just accessing the internet was much easier (although it was a separate software purchase initially). And all the best software was on Macs (well, some of it was Unix, too) Eudora was the standard email client, and it was still Mac-only, for some reason the Windows version remained ugly forever. The Mac version of Netscape (and before that Mosaic) were much prettier than the Windows versions. (In my memory, the Mac versions came out sooner, particularly for early Netscape, but I can't find a source that backs that up).

On top of which, Microsoft was in the middle of a totally clueless stage. Win 95 did not, by default, ship with a web browser, and the big Microsoft internet initiative of 1995 was something called Blackbird, which was going to be a proprietary replacement for HTML. That worked out about as well as you'd expect, evidenced by the fact that Blackbird doesn't even have a Wikipedia article. Making it less important than even the most minor anime character...

Putting that all together, in the months before the Win95 launch, Mac had about a 12-18 month lead in Internet apps and Microsoft was distracted by an attempt to privatize the nascent WWW. There's clearly some room there for Apple to have maneuvered themselves into a better position than they wound up in. Being the best internet platform around would have been an interesting counterweight to the Win 95 launch, and while I doubt they could have stopped the upcoming onslaught, they probably could have mitigated it somewhat.

Instead, Apple didn't really do anything in the space, except release an email client (Claris Emailer -- which does have a Wikipedia article, which charitably refers to it as "popular"). Microsoft, on the other hand, turned on a dime, and gave up the futile attempt to take over the internet by co-opting the authoring tools. They switched instead to the more lucrative method of taking over the internet by co-opting the client tools. Apple wandered around in a fog for a few years, until they attacked the opportunity to go after digital media. But you probably know that part...

Apple Summer of 95

As I may have mentioned here, back in 1995 I spent three months as a summer intern at Apple HQ in Cupertino.

I was buried deep in the educational technology research group so, trust me, I didn't work on anything you've heard of. It was a fun summer, though. They stuffed about 15 of us, a mix of grad students and contractors, in a room that was really long and narrow. They tried to make up for the cramped office space by supplying us with Nerf toys (the admin assistant for our group would sometimes come in and announce a Toys R' Us run, and did anybody want anything). I got about a dozen free T-shirts in three months. I also experienced my first earthquake, which went like this:

A slow rumble, like a truck going down a slowdown strip

All the non-California people: What was that?

All the California people: What was what?

None of which is why I brought this up. 1995 was near a low point for Apple, but even at that there were three or four good-sized company parties during the few months I was there. I'm talking about food, music, drinks, some entertainment, all in the inner courtyard of the Infinite Loop campus. I may be slightly exaggerating in memory, and I was assured that it was small-scale by later Valley standards, but it sure seemed elaborate to me.

In August 1995, Apple held what you'd have to describe as an anti-Windows 95 launch party. More of a morale booster, I guess. The thing I remember most is a screen projecting Windows 95, while some Apple guy pointed out it's flaws. As in, "Windows 95 will only let you have 256 characters in a path name, but if you have more than 15 directory levels, you can cause it to give you a really weird error message." Thin stuff, but enthusiastically received by a lot of people who wanted to whistle in the dark together.

Everybody there, I think, knew that Apple lost something big that day. Prior to Win95, the visual differences between Mac and PC were so clear that you could see the difference in a store just by looking at the two. Afterwards, you actually had to use them both for a while to learn the difference. This was a big change in the Mac/PC dynamic, and it took Apple about five years of flailing before they would come up with a decent response.

GWT part 3 and 4

Sorry for not mentioning this earlier, but part three of the GWT series is now up on the IBM site at:

http://www-128.ibm.com/developerworks/opensource/library/os-ad-gwt3/

This one is about remote procedure calls, and I'm pleased with how it turned out.

I just got the proofs for the fourth and final article in this series, about deployment. I expect it to be online Tuesday, Feb 27th at:

http://www-128.ibm.com/developerworks/opensource/library/os-ad-gwt4/

Clearing The Decks

A collection of small things, half-finished posts, and pure whatnot that hopefully will lead to more posts in the future:

• Got my first Amazon affiliate statement with no less than $1.55 heading my way. Thanks to the person who clicked through...
  
  
• There's a new sidebar, for small links, via del.icio.us. The sidebar has it's own RSS feed, on the off chance somebody is interested. UPDATE: It doesn't appear to work on Safari, which is a problem... Weird, because I did the preview using Safari, and it showed up fine, but not in the actual blog. Until I figure that out, Safari users can still click on the RSS icon and see the items.
  
  
• I had a half-finished post on the iPhone that got buried by the trillions of electrons poured on this story. So, I'll distill it to this: that was one cool demo.
  
  
• I also had a half-finished post on using XML as a scripting language, as in Ant scripts. Distilled: Don't do it. It's hard to read and nigh impossible to maintain. The thing I most like about Groovy is that it lets you actually script an Ant target. Although I think the JRuby/Rake combo is going to be pretty powerful here.
  
  
• Hey, another half-finished post. This one was about the lack of list or hash literals in Java. Which bothers me just about every day that I work with Java.
  
  

Decks now cleared. Hoping to get some new content here soon.

GWT Article Now Online, Part Two

The second part of my IBM Developerworks series on Google Web Toolkit is now online at http://www-128.ibm.com/developerworks/library/os-ad-gwt2/. This one focuses mostly on the Derby database, and features a really quick and dirty database-to-Java conversion tool.

Enjoy.

Playing in the Sandbox

This message showed up in the Manning Sandbox forum for wxPython In Action.  After saying some nice things about the book, the poster has some suggestions:

I would love to see an advanced volume covering topics such as XRC, using XML to define a screen layout; creating custom widgets...  internationalization, and a full chapter or more expanding on chapter 5 "Creating your blueprint." I find that... program organization is most important yet little seems to be written about it, for any programming language.... A book that illustrates solutions to design problems using patterns, Python, and wxPython will help many people...

Thanks for the kind words.  I'm thrilled that you found the book helpful.

There are about three or four things that I regret not being able to include in the book.  XRC is definitely on that list -- I think that XML or other GUI description languages are going to be increasingly important.  (Also on the list: multimedia and how to distribute your finished program).

These all got pushed out of the book over space considerations.  We were something like 75 pages over budget as it was.  Owing to some communication issues, nobody realized that we were that far over our page count until the pages were already written, and while it wasn't a problem to get them approved, it did mean that we didn't push forward into other topics.

There are no current plans for a second book, although it's not out of the question that we'd fill a gap or two with an article on line somewhere.  (To be clear, there are no current plans for that, either).  Frankly, sales are not high enough for a publisher to seek us out for a second book at this point, especially since an advanced book would, almost by definition, sell fewer copies than the original.  That's not a knock on the sales, which seem to be roughly in line with publisher expectations, just a comment on the size of the potential market.

As for a patterns/program organization book for Python, I'd love to write one.  For one thing, it'd give me a chance to rant at length about the finer points of architecture and class structure.  I've been known to have an opinion or two on the topic.  The main problem would be selling it.  My sense is that it's rather hard to sell a general-topic programming book compared to one that's tied to a specific tool or product.  This would especially be true for a relatively small market like Python. 

Still, that's what blogs are for, so hopefully I'll be able to get some interesting thoughts on those lines here.

GWT Article Now Online

I'm happy to announce that Part One of my four part series on using Google Web Toolkit is now available at: http://www-128.ibm.com/developerworks/opensource/library/os-ad-gwt1/



This part focuses on creating a GUI front-end using GWT. In case you wonder about the lead time on these things, it was originally written in August, and slightly updated right before it was published.



I think that the future part of the series will appear monthly. The next one is about using the Derby database as your back-end.



I'm pleased with how the article turned out, although I sort of wish I had taken the time to polish the look of the sample a bit -- that's one ugly Web 2.0 application. On the other hand, there's only a limited number of space available in this article (2000 words, and I was already over), and any graphical enhancement needs to be put in code and explained. So it's a tradeoff.



Hope you like it.

Don't Ask Questions, It Only Encourages Him

Let me promote this from the comment section -- it's not hard to find, it's the only comment on the previous post.

What is your favorite Python IDE? Your editor choices are interesting and valid but I wondered if you have a preffered IDE for Python and wxPython work?

I may have covered this somewhere, either on this site, or in the Python 411 podcast interview. If so, I'm sorry.



When I'm on a Windows machine, my Python editor of choice is JEdit, and has been for quite a while. I should say that I only rarely use the Python debugger and Jython interpreter add-ons that are available for it. I do have a couple of custom scripts that execute the script I'm working on and so on, but it's not a very elaborate set-up. What I like about JEdit is that it has a clean interface, had familiar Windows keyboard shortcuts and menus, and had a lot of plugin and macro power. The main downside is that it's kind of a memory hog for a text editor.



When I jumped Mac-side for my personal stuff, I tried just about every free programmer's editor I could find (JEdit, like a lot of Java/Swing programs, behaves a bit oddly on a Mac). Finally, I somewhat reluctantly decided to pay for TextMate. Although Python-mode on TextMate hasn't quite gotten the love and attention that Ruby has, there's still a lot of power there. It's really easy to script and customize, and it's about the only editor I've seen that has dynamic mode. So that if you are writing, say, a Django template, TextMate knows the the HTML portion gets colored and edited under HTML scope, and inside the Django tags, you use Django/Python mode.



My main issue with the various IDE's is that I haven't seen a Python one where the gain in the IDE functionality makes up for the editor itself not being as powerful as my normal editor. Some of this is my personal workflow -- using Python and test-first programming, it's very rare for me to feel that I need a step-through debugger. I'm also not very fond of code-generating GUI builders, for reasons that are probably worth another post.



That said, one thing I do like when I'm in and IDE for whatever reason is the ability to specify a project and do useful things across project scope. (Both JEdit and TextMate have this ability, but not fully formed.) I've done some Ruby work using Eclipse with Ruby plugins, and it's nice to, say, have one-button access to running all your unit tests.



That's what works for me, but I'm always looking for new tools and finding out how other people work.

Editors I Like

Two tools I use all the time. Neither is free, and since my strong bias is to use free tools where possible, these are some really impressive editors.

IntelliJ IDEA For all my Java needs. It's got more features and is more usable than any other Java IDE out there. The only downsides are that it's not free, and there are about a half-dozen keyboard shortcuts you have to get down before you achieve anything like full Zen mastery (well, and it could be nicer about the way it arranges tabs in the editor). I converted one of my teams to IntelliJ largely by just using it in team programming session. (Sample comment: "You don't seem to be typing very much"). IntelliJ is so good at using the class and type information that it single-handedly makes it useful to have static typing.

There are a couple of killer features that I miss horribly when using another tool, like the control-n series of shortcuts to browse classes, files, or symbols in the project. Even better, in the search box, the search is camel-case aware. So if you type MBGC, it'll match the class MyBigGoofyClass, or the symbol makeBeveragesGreeenCoffee. It's brilliant, completely intuitive and makes searches through the code very quick. Ten seconds after you try it once, you're hooked.

Another cool feature -- a help menu item that lists cool features along with a count of how often you use them, so you can see what neat stuff you are missing out on.

TextMate My Mac-based editor of choice for everything other than Java. The Mac editor wars (BBEdit vs. Everybody Else) do sometimes reach a fever pitch normally associated only with critical topics like Emacs vs Vi. So I don't want this to be a bash on other Mac editors -- if I want to do that, I'll do another post. Besides, if what you are doing works for you, more power to you. What I like about TextMate is that it really was built from the bottom up to be scriptable, which gives it a tremendous amount of flexibility and power to handle different file modes, integrate shortcuts, run scripts from TextMate, just easy as could be to use that stuff, and even pretty easy to create new commands. Biggest quibbles are the single-keystroke only Undo, which I understand as a design choice even as I find it kind of frustrating, and the project mode, which is useless to me, at least partially because it will only display like five tabs across before going to the overflow menu, and that's just not enough.

Killer feature: select a chunk of text, type the left half of an enclosing pair, like a left paren or bracket. Rather than replace the selected text with the keypress, which is almost never what you want to do, TextMate will surround the selected text with the enclosing pair, which is so useful that I try and fail to use this in all my other editors now. And yes, the list of enclosing pairs is adjustable for each file mode.

Less Frequently Asked Questions

Hi. Miss me? Thought not. Well, I've been feeling increasingly guilty about not posting something here, especially as the comments continue to trickle in -- we're up to eight now that I've cleared off some comment spam!

I'm going to boldly ignore the three partially written posts and do another round of publishing questions.

How's the wxPython book selling? Not bad. Got my first-ever royalty check a couple of weeks ago (actually, a royalty direct deposit). Went well into the low three figures, which is relevant to the older question about how much money you can make at this thing. (To be fair, that's artificially lowered a little bit because some of the royalties still were going to finish paying off the advance. I was hoping that the book would substantially outsell the Jython book, which hasn't happened yet. A little surprising given both the relative health of the mailing lists for the two tools and also the fact that the wx book had a substantially better rating on Amazon. And oh yes, I know what the Amazon rank is. Also the current total of reviews -- thanks to all ten people who have gone to Amazon and side nice things.

The implication of the Amazon numbers would seem to be that either a) Amazon is selling fewer books than four years ago or b) Manning doesn't have the distribution within bookstores that O'Reilly did. I suspect the latter, especially since the Jython book seems to have had more foreign sales.

What tools do you use to write the books? I'm actually pretty interested in this one with respect to how other authors do it. It seems to me that there isn't a fully satisfying tool for authoring technical books. In both cases, the main tool decisions were made before I came on board. For the Jython book, we used Word. There was exactly one positive of this -- it was nice to use the change-tracking system to do comments back and forth. Word, though, seems to be optimized for a two page office memo, and is really a pain for anything more complex. Especially when you are changing font styles frequently for things like code literals, or inserting code blocks, or numbered lists (which can be nightmarish). Most of my demo code was written in jEdit. O'Reilly provided a Word template with predefined paragraph and character styles for things like lists, headers, and literals, and they then automatically converted that for production.

Manning had something similar, but we only used it directly. For the wx book, we used ReStructured Text and a CVS server to do change tracking. This enabled us to do the writing in an ordinary text editor -- I used jEdit again (Robin used Emacs, I think). The CVS server was a great idea. Using ReST had some benefits -- for one thing, it was much easier to integrate figures and code snippets with include statements. The biggest downside from just a typing standpoint was tables, which were a pain. However, Manning would only accept submissions in Word at that time, so we had a kind of convoluted system where we would auto-convert the ReST to OpenOffice, then hand save it as a Word file. Once we turned the books in, we were stuck doing final proofreading and edits in Word. (Although Robin and I used Writely, now Google Docs, to do our change lists from the proofreading -- that worked really nicely). One significant difference between the publishers was that O'Reilly did the indexing in-house, whereas Manning asked us to do it. It's actually more difficult than it looks to do well -- I'm under no illusion that we did the index as well as somebody with more experience would have.

One more question along these lines upcoming, but it's longer and it's late. I'll try not to wait six weeks.

Now with sound

Robin Dunn and I were interviewed for Ron Stevens' excellent Python 411 podcast -- you can download and listen to the .mp3 file here. It's about 45 minutes long, which should mean that Ron used nearly all of the interview. Hope you like it. It was a lot of fun to do. Thanks again to Ron for having us on, and also for the very nice review of the book he wrote on Slashdot. Haven't listened to the podcast myself yet, so I hope I don't sound like a gibbering idiot.

wxWorld

I'm pleased to be able to link to a new article: Build cross-platform GUIs using wxWidgets available on the IBM developerWorks site. The original title was "wxWorld", and it's a quick look at wxPython, the wxWidgets toolkit, and some of the other wxWidgets language bindings. I had some fun digging through the different language tools trying to create short wx programs in each. Hope you like it.

Tips-First for Test-First

Of all the exciting ideas and revelations that came from Kent Beck's original XP book, Test-First Programming has been the one that most significantly affected the way I work on a day-to-day basis.

I love programming test-first. It's a great way to take a large, amorphous task and solve it piece by piece. It's also a nice morale boost -- "Hey, I know that my code does nine things. Let's go for ten..."

Here are a bunch of things I wish somebody had told me about test-first programming.

Unit Testing is not All Testing

So, after I started doing test-first, I walked around for about six months all, "my code is perfect because I wrote tests". My smugness came crashing down when testers found some bugs. My code was better because I wrote tests, but turns out I had made some dicey assumptions about the inputs, and so my tests passed, but were still incorrect. Test-first is not a complete test suite. You still need to do acceptance testing, you still need to do GUI testing where appropriate.

However, you can still automate a very large percentage of acceptance tests. The more you can automate the tests, the more they'll be run, and the happier you'll be.

Test-First is a structure for writing good code at least as much as it's a means for verifying code

Code that has been written in a test-first style tends to have certain qualities. Small methods, loosely coupled. Small objects, loosely coupled. Code that causes side effects (such as output) tends to be separated from code that doesn't. These are all side effects of what's easy to test -- it's easy to write small methods in a tight test-first loop. And dependencies between methods or objects make tests harder to write.

As it happens, those exact qualities -- tight cohesion and loose coupling -- are exactly what characterizes the best software architectures. My test-first experience is that I wind up with much better code architectures from test-first then I do when I try to guess the design before I start. (Which is not to say that a little bit of pre-design can't be helpful, just that it can be overdone).

Test-first is better suited for some things than others

That doesn't mean that you shouldn't try, of course. Test-first is vital in cases where you know the input and output, but not the process. It's also critical in cases where your program can be incorrect in subtle ways. It's somewhat less important for things that will visibly or loudly break. GUI's are a challenge because GUI layouts tend to change in ways that can break unit tests. GUI behaviors are more stable and easier to test. Again, though, you should try and have automated coverage of even those areas that weren't developed test-first.

Trust the process. Look ahead on tests, not implementation.

It works. The tight process is: Write a test. Run the test so that it fails. Make the simplest fix that will pass the test. Run the test so that it passes. Refactor. Keep to that tight loop. Resist the temptation to guess about what you'll need to pass the next test. What I usually do is put a list of the tests I'm going to write in comments in my test class -- that's my lookahead plan, and keeps me from forgetting something. But the design I do in my actual code comes during the refactor step, which is where I see duplication and abstraction.

The earlier you start the better off you are.

It gets increasingly hard to convert a code base to test-first the longer you wait. I've even had 20 line classes that needed significant refactoring to unit test (mostly because output was intertwined with functionality -- the code was better after the refactoring). Test-first is a good place to start, anyway -- pick something to test, and go.

Treat your tests like code and refactor them

Pretty much every test-first guide gives sort of a perfunctory nod to, "oh yeah, keep your test code clean." But I think this could stand a little more attention. For one thing, your unit tests are critically important to your ability to deliver quality code -- and they have no tests of their own. The cleaner your tests are, the better you'll be able to see issues with the tests themselves.

One thing that has worked nicely for me is extracting sets of assertions into custom assert methods. If you are continually making the same five assertions to check validity of your objects, throw them into an assert_instance method of some kind. Another common case is making the same assertion over a range of values -- move the for loop to your custom assertion and pass the range endpoints in.

There are two big advantages to doing this consistently. The first is that it's easier to see what's going on from one line of assert_person(expected_name, expected_addr) then from five lines of assert_equals. The second is that it ensures that you actually do make all the assertions every time. Hey, everybody slacks, and test-first is about making the test setups as quickly as possible. If you can trigger all umpteen tests on your class with one method call, you're more likely to do the whole set every time, rather than just picking one or two at random each time.

Don't reuse instance variables

This is another refactoring issue. It's tempting as you add new unit test cases to do something like this:

Person p = new Person("noel", "david", "rappin");
assertEquals(15, p.nameLength());
p.setLastName("flintstone");
assertEquals(19, p.nameLength());
p.setFirstName("pebbles")
assertEquals(22, p.nameLength());
p.setFirstName("betty");
assertEquals(22, p.nameLength());

The last test fails -- quick, what's it testing? Okay, now we have to trace the life of that instance variable all the way back up. It's hard to read, and prone to dangerous errors. You should never reuse an instance variable like this in a unit test -- every assertion should, where its at all feasible, be completely distinct:

assertNameLength(int expected, String first, String middle, String last) {
  Person p = new Person(first, middle, last);
  assertEquals(expected, p.nameLength())
};

testNameLength() {
  assertNameLength(15, "noel", "david", "rappin");
  assertNameLength(19, "noel", "david", "flintstone);
  assertNameLength(22, "pebbles", "david", "flintstone");
  assertNameLength(22, "betty", "david", "flintstone");
}

Now when the last test fails, you can actually see what's going on.

Avoid tautologies

The scariest issue you can have with tests is a test that passes when it should fail, allowing you to continue blithely along, ignorant of a bug you should have already caught. There will come a day, for instance, when you will forget to put any assertions in a test. There are a couple of things you can do to make tautologies less likely.

1. Follow the process. The process says each test has to fail before you add code. Adding tests that you already know will pass can easily lead to writing a test that will never fail.
   
   
2. If you have constants for text or numerical values in your code, don't reuse those in the tests -- use the literal or create a separate constant in the test.
   
   
3. Be careful with Mock Objects. Try not to test the things that you are explicitly inserting in the Mock when it's created.
   

Mock Objects Rule

Mock Objects are the missing link in helping you test all the things that are traditionally hard to unit test, like databases, GUI, web server... anything where your code is dependent on an external system or person, the Mock can get in the way and pretend to be that third-party and allow you to send and receive data in a testable way. Mock Object packages exist for a variety of languages, and using a package will save you time and effort on your tests.

Hope that helps -- go out and test something.

Why, Johnny, Why?

We interrupt Python week to bring you the following alternative programming rant. I know, Python week has sort of gone up in smoke. But one of our mottoes here is "Whenever a Hugo Award winning SF novelist writes a hyperbolic screed about BASIC in the public schools, 10 Print Hello will be there". As a motto, it's not very catchy. We're working on it.

As soon as I mentioned "Hugo Award winner", "BASIC" and "hyperbolic screed" many of you were probably able to quickly deduce that the author is David Brin, here on Salon wondering what happened to BASIC (you'll have to watch an ad to view the article):

Only, quietly and without fanfare, or even any comment or notice by software pundits, we have drifted into a situation where almost none of the millions of personal computers in America offers a line-programming language simple enough for kids to pick up fast. Not even the one that was a software lingua franca on nearly all machines, only a decade or so ago. And that is not only a problem for Ben and me; it is a problem for our nation and civilization.

Does he have your attention yet? He'll equate the loss of BASIC to an act of war later in the essay. Brin seems to be making three separate points:

• BASIC used to be available on all computers that kids touch, and that is no longer the case.

This is obviously true, but a bit less dramatic than Brin implies.

Brin implies that BASIC was available for kids for a long time, and only recently disappeared. Actually, that's close to backwards. BASIC was generally available for less than a decade, and has been fading ever since. Even though Brin says a couple of times that "20 years ago" millions of kids could have used BASIC, the fact is that by 1986 BASIC was on its way out as a standard part of home computers.

Although it was invented in the early 60's, BASIC is associated most strongly with the late '70s and early 80s generation of computers. This market would eventually be dominated by the Apple ][ line, but earlier included things like the TRS/80, and Texas Instruments. (I even remember the Bally TV based game system having a BASIC module circa 1981 or so.). In any case, neither the Mac (introduced in 1984) or the IBM PC and clones featured BASIC to that same degree. By 1985, the idea that all computers would have BASIC was much less strong, although Apple ][ and BASIC instruction lingered in schools for a few years after that Which is why Brin's son is still seeing it in math textbooks, although that says more about the textbook industry than anything else. Data point -- my middle school had an Apple ][ computer lab in 1984 or 5. In my high school, a couple of years later, the computers were already Mac & PC's without basic -- we learned Pascal.

• There is much less of an sense that kids should be taught programming (particularly in BASIC) than there may have been in the mid 80's.
  

Largely true. Another data point -- my younger relatives about ten years later were no longer taught BASIC, nor were the kids at elementary schools I studied about the same time. By now, computers had migrated into the actual classroom and were being used as reference and also for what I guess you'd have to call multimedia authoring. I do think this is a loss. But at the same time, I've always kind of suspected that the reason why elementary school kids were taught BASIC in the early 80s was because the schools were kind of floundering around for what to do with the shiny new computers. My read of the educational literature during the time I was studying educational technology was that eventually this petered out because it was not clear that teaching programming was helping students become better general learners. To be fair, that's not exactly the point Brin is arguing, but it does suggest that, perhaps, losing BASIC is not the end of civilization.

• BASIC has some magical set of properties (Brin calls it "line-programming") that makes it uniquely suitable for introducing programming concepts. Because of this, we're losing an entire generation of tinkerers. This, I don't get at all.

So, Brin goes on at some length about how the computer people he's talked to don't seem to feel that it's a problem that BASIC isn't around anymore, while he, Brin, knows better. (Anybody familiar with Brin's essay entitled "The Dogma of Otherness" should catch at least a hint of irony.) Anyway, while Brin does acknowledge that BASIC has a lot of limitations, he goes on at length about line-programming and how important it is.

I'm not completely sure what Brin means by line-programming. Google didn't give me a relevant link. I'm going to assume that it has something to do with the fact that BASIC circa the Applesoft years was coded on a line-by-line basis. Brin suggests that this was an experience that modern languages can't give:

The "scripting" languages that serve as entry-level tools for today's aspiring programmers -- like Perl and Python -- don't make this experience accessible to students in the same way. BASIC was close enough to the algorithm that you could actually follow the reasoning of the machine as it made choices and followed logical pathways. Repeating this point for emphasis: You could even do it all yourself, following along on paper, for a few iterations, verifying that the dot on the screen was moving by the sheer power of mathematics, alone. Wow! (Indeed, I would love to sit with my son and write "Pong" from scratch. The rule set -- the math -- is so simple. And he would never see the world the same, no matter how many higher-level languages he then moves on to.)

I confess, I have no idea what he's saying here, though I do like the scare-quotes around "scripting". I'm kind of trying to get my head around the idea that you can't program a mathematical algorithm in Python and follow the reasoning of the machine. I mean, there are higher level constructs, but if we're talking about loops and conditionals for 5th grade math problems... I think Python would be pretty easy to follow and would look a lot like the logical structure of the algorithm. Python even has an interactive interpreter so you could type the code in line-by-line if you wanted. That actually could be pretty cool in a learning-math setting. And you could even track it with pencil and paper.

It is true, though, that it was much more conceptually simple to do simple graphics in Applesoft BASIC than in Pascal. That's not the language's fault, and it's not because you write Python in a full text editor. It's because modern programming languages sit on an operating system that mediates access to the drawing controls, and Applesoft BASIC didn't. It wouldn't be hard to come up with a Python package that emulated the draw controls of Applesoft basic (which were on the order of "Make that pixel blue. Now make that one red").

I think what I object to is the implication that this is somehow a difficult time to be learning to program, that it's harder now to get into programming. That's totally wrong -- it's a fabulous time to be learning to program. Brin says his son is now learning C++, so I'll assume he's interested and motivated. Twenty years ago, yeah, he would have had BASIC. And that's it. Unless you wanted to pay some money. As for seeing any examples of what a real program looked like, forget it.

These days... Well, a Mac OS X box ships with what, a half-dozen or so programming languages right out of the box, with who knows how many all available for free. Want to see basic algorithm code for free? It's there. All kind of code, complex and simple, is available online. There's a whole industry of programming books, something I would have devoured as a kid. We've traded The One True Teaching Language for many different languages. An elementary school teacher explaining "20 goto 10" is now a publishing empire, plus the internet. Coloring individual dots on a screen is now building a web page, or a web application, or a sprite animation. Even an elementary school child who is motivated can do more and understand more about computers than I would have dreamed in 1985. Have we lost something? Maybe. Have we gained something? Oh yes.