Twin Cities Lisp Group Starting Up May 9th, 2009
Patrick Stein

(defmeeting tc-lisp
   "Twin Cities Lisp Group Inaugural Meeting"
  :date    '(9 June 2009)
  :time    '((6 :pm) . (8 :pm))
  :venue   "Common Roots Cafe"  
  :address "Corner of 26th and Lyndale in Minneapolis, MN")

Complete details on Robert Goldman’s page. Here is an introduction to the first talk (by John Maraist):

NST: A Unit Test Framework for Common Lisp

In this talk we will introduce the Lisp unit test framework NST. SIFT developed NST for internal use on a number of ongoing Lisp projects, and we believe that the system is now mature enough to release more broadly. In this talk we will review the notion of a unit test, and introduce the use of NST in Lisp project development. NST’s implementation makes interesting use of a number of Lisp features—macro expansion, compile-time execution, metaobject protocols—and we will discuss its current implementation as well as the lessons we learned along the way.

There is also mailing list, and more information about the Common Roots Cafe.

Move over UML, I Have SQL May 8th, 2009
Patrick Stein

I have been trying to nail down a design for a sizable software project. I know how I want the system to behave. I just hadn’t nailed down a good API or internal structure for it yet.

I knew that I was going to have to track multiple versions of uniquely identifiable data with different versions stored in different locations.

I had all sorts of UML drawing on whiteboards and graph paper and in OmniGraffle. Everything just kept getting messy.

Earlier this week, I read a great article about Using SQLite on the iPhone. So, today, I tried to hammer out what I would do with this data if I were using SQL to track it. I wrote a bunch of CREATE TABLE statements and then a few SELECT statements.

It worked. Getting the JOINs in the SELECT statements to make sense forced me to make the relations in my data as simple as possible, but no simpler. I had been trying to jam many-to-many relationships into one-to-many or many-to-one relationships. The SQL exercise forced me to get it right.

Will I use SQL in the final project? Maybe, but it doesn’t seem like I will need it. Did I need to use SQL for the design? Absolutely.

What is Your Coding Style? May 7th, 2009
Patrick Stein

In cleaning out some directories, I stumbled upon a draft of a document that I wrote three and a half years ago. That document describes my programming style.

What the document says is mostly out of date. I hadn’t even used Perl or Lisp to any great extent at that time. But, here is the thing…. It doesn’t matter.

Writing the document was an important exercise. Looking at some of my Objective C code, I think it may be time to repeat the exercise. For months after writing that document, I named my variables better, I named my functions better, and I wrote more maintainable code.

So, what is your coding style?

Sneak Peek: Screenshot for Spelling iPhone App May 6th, 2009
Patrick Stein

Earlier, I gave a sneak peek at some artwork for the children’s spelling game I am making for the iPhone. Here is a screenshot of the application (click for full size):

spell-it-four

I need to touch up the jaunty logo tiles in the upper left. Some of them are worse for the wear after the perspective transformations and rotations. More to follow….

Programming When Clarity Counts May 5th, 2009
Patrick Stein

In my previous post, I wrote some code in Perl because I wanted the code to be clear and obvious. Wait? What? Who uses Perl when they want clarity?

Perl

I admit: I was surprised myself. Seriously, I tried several other languages first. Let’s just focus on the first loop here. Here’s the Perl again for reference:

my $total = 0.0;
foreach my $item ( @list_of_items ) {
    $total += weight( $item );
}

Objective C

The actual code that I was attempting to explain was in Objective C with the NeXTStep foundation classes. I couldn’t imagine that anyone would want to try to understand it:

double total = 0.0;
NSEnumerator* ee = [itemList objectEnumerator];
Item* item;
while ( ( item = (Item*)[ee nextObject] ) != nil ) {
    total += [item weight];
}

C

My first attempt for the article was to write it in C using an array of items.

double total = 0.0;
unsigned int ii;
for ( ii = 0; ii < itemCount; ++ii ) {
    total += weight( itemArray[ ii ] );
}

That’s not too terrible. There is, however, a great deal of syntax and code devoted to handling the array including an extra variable to track its length. Beyond that, the loop counter is of little use to someone trying to understand the concept.

C++

My next go was C++. My hope was that iterators would make the looping less painful. C++ iterators, however, are the very model of pain.

double total = 0.0;
std::list< Item* >::const_iterator it;
for ( it = itemList.begin(); it != itemList.end(); ++it ) {
    total += weight( *it );
}

This requires the reader to wade through a syntactic thicket to get the iterator into the picture at all. It also requires a certain comfort with pointers that one wouldn’t have coming from another language.

Java

My next attempt was Java. I hate Java. It may not be terrible for this code with the new looping constructs that came in Java 1.5. Alas, I quit coding it before I made it through this first loop.

Lisp

Of course, I wanted to code this in Lisp:

(let ((total (reduce #'+ list-of-items :key #'weight)))
   ...)

That would be perfectly clear to someone who has used Lisp or Scheme. Alas, not everyone has.

So… Perl…

If you want to write the Perl code, you have to understand the difference between scalars and arrays. To read the code, however, you don’t have to grok that distinction to see what’s going on. I didn’t try it in Python. Maybe it would be clear to a wider audience. I may have to try it next time.

Updates In Email

Email:

l