« December 2006 | Main | February 2007 »

January 24, 2007

On learning to program (in 21 days or 10 years)

A few years ago Peter Norvig wrote a great article about how absurd it is —contrary to many popular titles—to learn to program well (or learn most other worthwhile skills) in less than several (ten) years.

I first came across this article when Phil Windley mentioned it a few weeks ago (I wish he'd written more about his perspective as a CS teacher). It got me thinking about my programming roots, and the several times I've taught programming to others. I realized I really haven't thought a lot about my programming background.

I started programming as a kid 25 years ago, on the Apple ][+ at the local public library. I spent a lot (probably too much) of my free time programming (AppleSoft BASIC, TRS-80 BASIC, 6502 assembler, Pascal, C) over 2-3 years, and off-and-on through my teens until I got my first full-time job as a programmer. Even though I haven't been a full-time programmer for most of those 25 years, I've easily programmed for a cumulative 10 years. Wow.

The thought process this article started helped me realize a few things (that may apply to other programmers):

  • I think about programming more than the average person (maybe more than the average programmer). Even when I've worked in other jobs, I tend to see many problems as programming opportunities (and can't understand how anyone could live with tedious manual processes). I've always been a "programmer-mailroom-sorter" or "programmer-network-engineer" or "programmer-NOC-manager" or "programmer-IT-manager".
  • I forgot a long time ago how I learned to program. My brain has been wired for "programmer think" for a long time, so I understand why teaching someone else to program and think like a programmer is a different effort than I'd expected.
  • Programming is something like riding a bike: the basic skills and thought processes that are tough to learn seem to stick with you, though they may need to be fine-tuned to the latest technologies.

    Probably a good thing I've gone back to programming full-time.

    Posted by pete at 12:54 PM

    January 20, 2007

    Updates on recent posts

    A few updates on recent posts:

  • Joe Hewitt, the creator of FireBug, wrote an excellent article in DDJ on using FireBug. His focus is on debugging AJAX, but there's useful information for any Web developer. Finding FireBug continues to be an "a ha!" moment for Web developers. If you're not using it, you're spending way more time than you should debugging and fiddling around with CSS, JavaScript and HTML.

  • After writing about algorithms and Perl, I stumbled across Mastering Algorithms with Perl (author interview). I looked through it at a local university library and it's on my to-buy list now. Not only does it have an in-depth look at sorting in Perl, there's in-depth coverage of all the basic data structures (lists, trees, heaps), searching, sets, matrices, graphs, strings, etc, etc, etc. In the 30 minutes I looked at it, I found several great tips I could put to use. Looks like a worthy addition to the reference library.

    Posted by pete at 8:08 AM

    January 15, 2007

    Adjusting algorithms for dynamic languages

    One of my college Computer Science classes introduced me to Sedgewick's Algorithms in C. Though after a decade I don't remember specifics of the class, I regularly find myself applying the principles I learned, evaluating the cost of each way a problem can be solved (and once in a while pulling the book from my reference library).

    A Perl program I was working on recently seemed like a textbook case to apply Algorithms. After some testing I realized that though the fundamentals might be the same, Algorithms in Perl would be quite different from Algorithms in C.

    The program required dropping the smallest value from a random list of numbers if it was more than 50% smaller than the next-smallest value, and similar for the largest value on the list.

    Two possible algorithms came to mind. First would be to run through the list and find the two smallest and two largest values, then compare them and delete as necessary. Another option would be to sort the list, then look at the first two (smallest) and last two values (largest), and delete as necessary.

    Sedgewick says sorting takes at least N log N time, while a sequential search takes only N / 2, so the first option seems the best. I was working with a short list (~200 values), so could easily be done in memory. (Of course, you might be wondering why I'm going through all of this when it's probably not noticeable which I use on a small list--don't spoil the fun). So I hacked up both implementations, and iterated each 100,000 times to amplify the difference:

    Sequential search: 34.75 seconds
    Sort: 7.85 seconds

    Surprising, kind of (more in a moment). For comparison, I implemented the same thing using D, a successor to C/C++ (and with similar performance):

    Sequential search: 0.566 seconds
    Sort: 3.47 seconds

    Sedgewick predicts that the sort method would be around 4.6x slower than sequential search, that's pretty close to the results in D. But Perl is almost the opposite (search 4.4x slower than sort).

    Explanation? Not suprisingly, Perl implements sort in C (or maybe C++) using quicksort or mergesort. From the perlfunc manpage

    Perl 5.6 and earlier used a quicksort algorithm to implement sort. That algorithm was not stable, and could go quadratic. (A stable sort preserves the input order of elements that compare equal. Although quicksort's run time is O(NlogN) when averaged over all arrays of length N, the time can be O(N**2), quadratic behavior, for some inputs.) In 5.7, the quicksort implementation was replaced with a stable mergesort algorithm whose worst case behavior is O(NlogN).

    All of this leaves me wondering how the principles from my algorithm class apply to dynamic languages (where's Algorithms in Perl--maybe Sedgewick's book on Java would be a start). Or maybe algorithms and machine performance aren't such a big deal anymore, and I should worry more about cookbooks, patterns and developer performance.

    Posted by pete at 8:33 PM

    January 10, 2007

    Surprise -- DST comes early this year

    A question today about plans for Daylight Saving changes came as a bit of a shock. I'd forgotten that dates for Daylight Saving Time (in the US) change this year. DST starts 3 weeks earlier (2nd Sunday of March--March 11--instead of 1st of April) and ends a week later. This changed in 2005 (I vaguely remember thinking at the time how far off 2007 was), but doesn't seem to have gotten a lot of attention.

    Network/system admins have some work to do in the next couple of months (and any programmers who've unwisely hard-coded DST). Microsoft has a page about patch release plans, though older Windows requires a manual process. Looks like Linux distros have been updating (my Gentoo and Ubuntu machines both work), but any older releases may require manual updating of zoneinfo files.

    While testing one of my Linux machines, I got an unexpected error:


    $ date -d"03/11/2007 01:59:00"
    Sun Mar 11 01:59:00 MST 2007
    $ date -d"03/11/2007 02:00:00"
    date: invalid date `03/11/2007 02:00:00'
    $ date -d"03/11/2007 03:00:00"
    Sun Mar 11 03:00:00 MDT 2007

    Was somehow expecting date to convert 2am for me, had never thought about how 2am-2:59am does not exist on the day you change to DST (at least, not in timezones that switch). (On the other hand, 1am-1:59am happen twice when switching back to Standard time).

    Update: Looks like OS X (10.4.8 fully-patched) is also updated (looks like almost a year ago).


    $ date -r 1173603599
    Sun Mar 11 01:59:59 MST 2007
    $ date -r 1173603600
    Sun Mar 11 03:00:00 MDT 2007

    Posted by pete at 5:09 PM

    January 2, 2007

    An interesting mix (of oil and water, kind of)

    By coincidence, I happened to watch or read An Inconvenient Truth and State of Fear over the last month. They're both interesting and entertaining (I wish more Powerpoint presentations were like Al Gore's), and highly opinionated in a subtle way that doesn't often detract from the entertainment.

    I picked up State of Fear because it was Crighton, had no idea what it was about (a perspective on global warming that's raised some controversy). Not knowing anything about it (even the back cover doesn't give it away), I started reading it after watching half of An Inconvenient Truth. Sure made the second half of the slide show much more interesting and raised a lot more questions (even got me to spend a few hours looking at climate data at NOAA and some other places).

    This coincidental mix ended up generating more questions than answers, but more than anything reminded me of lessons (as far back as middle school) in critical thinking and specifically in examining data and charts carefully, and not just accepting the conclusions the presenters advocate. (Was interesting to see Gore and Crighton frequently using the same data and charts to make opposing points.)

    (As I wrote this, I realized I also recently read The Davinci Code and a counterpoint by some religious academics at BYU, which soundly debunked every "wow, I never knew that" from Davinci Code.)

    The next movie I watched was Who Killed the Electric Car?, Any suggestions on a counterpoint to this one?

    Posted by pete at 2:31 PM

  • golf tips