January 15, 2008

My First Scheme Program

Filed under: Scheme — bnsmith @ 4:15 am

Today, I am releasing my first (more or less) working Scheme program. I’m still only learning Scheme, so my work is not very sophisticated, but I hope this is just the beginning.

I named the program “Conversation Tree Writer.” It’s purpose is to allow someone to more easily write the “conversation trees” that are commonly used to express the plot in role-playing games (RPGs). Once the conversation trees have been written, the program then allows the user to step through the conversations and see if they work as intended.

If I understand correctly, my program implements a domain specific language (DSL) for expressing conversation trees. I implemented it with the ‘define-macro’ syntax, because it is a little easier for novices to pick up.

As you’ve probably guessed, the primary reason that I chose to write this program was as a learning exercise. However, I still hope that it might become useful to someone after a few more revisions. Someone working on a video game would probably find it very difficult to write these trees in a standard word processor. It would become something like a choose-your-own adventure book; adding a page would mean having to manually update all of the instructions for what page to turn to next.

Presumably, commercial game developers have some internal tools to ease this process, but I was not able to find any such open-source programs.

I’m currently distributing the source-code only, so you will need to install Gambit Scheme and SLIB to run it. See Getting Started with Scheme on Ubuntu Part 1 and Part 2 for instructions. After Scheme is set up, download the source code here, open a terminal, move to the directory where you extracted the source code and run this command:

./ctw.scm secure.ctw

You can then choose between the available options by entering a number.

January 1, 2008

Five Management Strategies to Hire and Retain Great Programmers

Filed under: Programming Professionally — bnsmith @ 3:55 am

And they won’t cost you a dime…

DISCLAIMER: I’m still an underling, and so I haven’t actually had the opportunity to put these ideas into practice. I base my theories on experiences that I’ve had working on various teams over the course of my career, and how these experiences affected my own decisions. Although I’m convinced that the ideas are sound, I can’t offer any proof. Use at your own risk!

1.) Cultivate a Casual Work Environment

I love throwing on jeans and a T-shirt in the morning. It’s not just the convenience though; it’s all part of the uber-geek ego-trip. If you try to make developers wear shirt-and-tie to sit in their cubicle and code, don’t expect to retain anyone besides those that aren’t good enough to get hired anywhere else.

This assertion probably seems a tad extreme, given that all we’re talking about is a useless flap of cloth wrapped around the neck. Still, I think of it this way: managers who enforce a dress code are forcing needless, arbitrary complexity on their developers. Dressing up in a special costume doesn’t make developers more productive or NP-complete problems less difficult. So what’s the point? Even worse, managers who make bad decisions about clothing are equally likely to make bad decisions about technology and architecture, and these decisions would be vastly more painful to a great programmer.

The only possible exception that I can see to this rule would be for organizations with fat, bloated, governmental bureaucracies that force the dress code, but also incredibly cool technologies that a geek can’t play with anywhere else. I think that the best example of this would be NASA. Of course, once commercial space companies really start to take off, this situation won’t last for long.

2.) Let Your Developers Choose Their Tools

Have you just read the most fascinating article/advertisement in your favorite management magazine about the amazing new integrated version control system that will double the productivity of any developer? Stop right there. If you haven’t committed any changes in the last six months, then you are not in a position to make an informed decision. Try to realize this fact, and listen to what your developers tell you.

This doesn’t only apply to version control. The more control that you give your developers, the better.

If you’re hiring Java programmers, then let them develop on a Linux or BSD box instead of Windows, if that’s what they want. Java is multi-platform anyway, right? You might have to tell them to test on Windows extensively, if that’s your primary market, but your programmers would still be grateful to be able to work on the desktop OS of their choice. Perhaps the IT department might not like it, but are you going to let them stop you from building a first rate development team and thus creating fabulously successful software? This important benefit will help you attract and keep more talented programmers than you might otherwise get, and it costs nothing.

3.) Allow Your Developers to Connect with your Clients

I bet this is another controversial suggestion. Do you really want your shabbily-dressed (see point #1), Unix-hippie (see point #2) developers to be talking to your valued clients?

I would say yes.

Think of it like this. Your developers are smart people, and as long as you express your needs, you should be able to trust them to behave properly. If the customer has a particular dress-code, tell your developers what it is, and tell them that they will need to follow it in order to go there. In this case, it isn’t an arbitrary decision. You don’t have any control over your client’s rules, and so your developers won’t resent it.

But would developers actually want to see the clients? I think that most would, as long as you are careful not to take it too far, and make your developers feel like they are first-line tech support. Developers appreciate being able to see how real-life customers use the software, and how it helps to make their lives easier. If you have some people working for you who have never once seen a client-site, spare them a thought and ask them if they would like to tag along and see the sights. If you’re going to be driving over there anyway, why not? This is especially important if the client-site is something that a geek might find interesting.

4.) Offer Benefits Like Flex-Hours and Telecommuting

I don’t use an alarm clock. I wake up in the morning, generally about 8:00 am, roll out of bed, get dressed and go to work. But if I wake up at 8:30 or 9:00, I don’t have to worry about it. Nobody is keeping track of exactly the hours I work, as long as I get things done. If I was forced awake at 7:00 am every morning, I’d probably be an unproductive, coffee-chugging zombie for the first couple hours of each day. Is that really a worthwhile price to pay to maintain the same nice, rigid schedule for everyone?

Why even show up at all? If there are no meetings scheduled and a lot of solitary development to be done, there’s no reason that a developer can’t be equally productive from home. And of course, nothing makes me appreciate telecommuting like waiting at home for the FedEx guy to deliver a new tech toy.

Also keep in mind that telecommuting shouldn’t cost anything to implement — at least for programmers. If we were talking about marketing or sales people, then you would need to buy an expensive VPN appliance to give them access, but for any programmer worth their salt, all they should need is SSH. A little port forwarding magic is all it takes.

5.) Promote Ceaseless Learning and Discovery

Next Monday morning, as your developers arrive at work, hand them each an envelope containing a first-class ticket to Chicago and vouchers for a penthouse suite at the Drake Hotel so that they can attend PyCon 2008. Oh, wait… I promised that these strategies wouldn’t cost you a dime, didn’t I? Well, in that case, try this on for size.

Ask your developers what technologies they’re interested in. Ask them what they’re learning about in their spare time. Ask them how the technological landscape will shift in the next five years. Listen to their answers, and suggest that they each plan a short seminar on their favorite subject, so that they can share it with everyone. Friday lunch is an ideal time for such an activity. If you decide that you might be willing to part with a few dimes for this exercise, then perhaps you could even offer to order pizza for your crew. Who knows? You might even learn something.


Offering a high salary is a good start for finding top talent, but you will eventually run up against the law of diminishing returns. An extra thousand dollars added to the salary likely won’t be as big of a draw as a thousand dollars of well-thought-out perks. And when it comes right down to it, sometimes the best perks in life are free.

November 25, 2007

Getting Started with Scheme on Ubuntu — Part 2

Filed under: Linux,Scheme — bnsmith @ 11:59 pm

Installing and Using SLIB

Scheme is a very minimalistic language. This is Scheme’s great strength, but this trait can also make the language seem a little bit barren. There is a collection of excellent libraries that can help allieviate this, though using them requires some set-up. First, follow the directions from Part 1, if you haven’t already. As with Gambit Scheme itself, the version of SLIB in the Ubuntu repositories is not the latest, so we will install from source.

Go to the SLIB website and download to your home directory. The download link is under the “Quick Start” heading.

Next, open a terminal (Applications -> Accessories -> Terminal) and enter the following commands:

cd slib
sudo make install

Then, edit the SLIB configuration file with the command:

sudo gedit /usr/local/lib/slib/gambit.init

Find the line:

  ((unix)    (lambda () "/usr/local/share/gambc/"))


and change it to:

  ((unix)    (lambda () "/usr/local/Gambit-C/current/"))


Now start the interactive interpreter with root permissions:

sudo gsi -:s /usr/local/lib/slib/gambit.init -

In the interpreter, enter the command:

(require 'new-catalog)

Exit the interpreter by pressing CTRL-D twice. Finally, copy and paste this command into your terminal:

echo "(include \"/usr/local/lib/slib/gambit.init\")" > ~/.gambcini

SLIB is now fully installed and can be used by the Gambit Scheme interpreter. To test the installation, run the interpreter by typing gsi and paste in the following code:

(require 'random)
(random 10)

This should display a random number from zero to nine. It is similarly possible to use SLIB with programs saved in files. Copy the following code into a text file named slibtest.scm:

(require 'printf)
(require 'srfi-1)
(define userlist '((45607 "Ted Randalph" 34.90 5)
                   (91238 "Rob Smith" 32.45 3)))
  (lambda (userinfo)
    (printf "Employee %s (%d) has %d years experience and makes $%.2f per hour.\n"
      (second userinfo) (first userinfo) (fourth userinfo) (third userinfo))) userlist)

This program can be run by entering gsi slibtest.scm and should display the following output:
Check out the SLIB documentation for a complete list of what is available.

November 23, 2007

Getting Started with Scheme on Ubuntu — Part 1

Filed under: Linux,Scheme — bnsmith @ 3:44 am

Installing Gambit Scheme

As I described in my previous post, I am a fan of the Gambit implementation of Scheme. While following these instructions, try to keep in mind that the Scheme community is smaller than the communities of the more major languages like Python or Ruby, so there are still rough edges that get in the way. I hope that my experiences can speed things up for other fledgling Schemers.

It is possible to install Gambit Scheme from the Ubuntu repositories. However, the repositories contain an older version, so I recommend building Gambit Scheme from source instead. First, go to the Gambit Scheme website.


Click on the “Sources” link and save the gambc-v4_1_0.tgz file to your home directory. Next, open up a terminal (Applications -> Accessories -> Terminal), and enter these commands:

tar -xzvf gambc-v4_1_0.tgz
cd gambc-v4_1_0
./configure && make
make check
sudo make install
sudo make bootstrap
cd /usr/bin
sudo ln -s /usr/local/Gambit-C/current/bin/gsi gsi
cd ~

Once the installation is complete, conduct a few tests. From your terminal, enter the command:


You should then see Gambit’s interactive interpreter prompt. Enter the following code:

(define numlist '(2 10 6))
(map (lambda (x) (* x x)) numlist)

You should receive these results:


Exit the interpreter, by pressing CTRL-D twice. You can also use the Gambit Scheme interpreter to run Scheme programs stored in files. As an example, put the following text into a file named hello.scm:

(display "Hello World!\n")

Run the file with the command:

gsi hello.scm

That should be enough to start experimenting with Scheme. Part 2 will describe the installation and use of the SLIB libraries.

November 17, 2007

On the Importance of Programming Language Popularity

Filed under: Scheme — bnsmith @ 6:20 pm

I recently decided to learn Scheme. I’ve only just begun this journey, but already I’ve learned a great deal, some of which has nothing to do with Scheme programming.

My first step in learning Scheme was to choose an implementation. I knew that there were numerous Scheme implementations to choose from, as one would expect, given how easy it is to implement the language. This was, in fact, one of the things that drew me to the language in the first place. I was still just starting to learn Scheme, so I figured that it wouldn’t really matter which implementation I selected. As long as I was just playing around and not implementing real software, I could always switch later with relative ease.

So I installed MIT Scheme, fired up the interpreter and started typing in my first tentative lines of code:


It worked! I had successfully calculated that seven times two is fourteen! I was clearly well on my way to becoming an omnipotent programmer deity. Now, how about changing that first line to use the number 13 instead of 3? I tapped the up-arrow key on my keyboard and:


Well, apparently the MIT Scheme interpreter doesn’t support that. This discovery gave me pause. I really like learning with an interactive interpreter, and not having the ability to bring back the previous line would make things much more difficult. No worries though; there are plenty of other Scheme implementations out there. There has to be at least one that does what I want. Chicken Scheme seemed pretty popular. Trying the same code again:


And the up-arrow:


Chicken Scheme’s interpreter has the same problem. I also tried MZScheme, Scheme48 and Guile, with the exact same result. Five Scheme implementations, and they all suffer from this same issue.

And then it hit me. This is the sort of thing that causes newbies like me to give up and move on to something else. In fact, I think that I may have actually done just that after a previous attempt at learning Scheme, months ago.

Well, I didn’t give up this time, and I eventually found a Scheme implementation that supports my beloved arrow keys in its interpreter. And the winner is: Gambit Scheme. This excellent implementation seems to have been influenced by the “batteries included” philosophy that I love about Python. And given the state of the programming language world right now, I don’t think that “batteries included” is optional anymore. For a language to win users, and all of the benefits that a large community brings, at some point someone must create a polished implementation without the rough edges that I had to wrestle with. To some degree, this is a chicken and egg problem. On one hand, you must deal with all of the boring little details to grab users and build a big community. On the other hand, a big community will mean more contributors willing to tackle the boring details. I suppose that the polish of the implementation and the size of the community must move in lock-step. The only thing that anyone can do to speed this process is to adhere to the “batteries included” philosophy and encourage others to do the same.

If you’re thinking about learning Scheme, I highly recommend that you give Gambit a try. My next posting will explain how to install Gambit and set up the SLIB libraries on Ubuntu 7.10.

November 1, 2007

Practical Applications of Searle’s Chinese Room

Filed under: Programming Professionally — bnsmith @ 2:18 am

Consider the following:

A paper with Chinese characters is passed into a closed room through a slot on the door. The room’s occupant picks up the paper and examines it briefly, but he can’t read Chinese characters, and so he shrugs and sets about his task. He brings the paper over to his desk and opens a hefty volume containing thousands of rules describing a complex procedure. The rules themselves are written in English, but they are extremely tedious and dry, and so the man feels no enthusiasm for the dull task that he now begins to execute. The book tells him to look at first character, painstakingly copy a few of the inscrutable Chinese characters onto a new piece of paper, and then proceed to follow the rule on page three-thousand, four-hundred and ninety-eight. The rules are extremely detailed, providing a course of action for any possible set of characters. After several hours, the instructions tell the man that his task is complete, and that he should now take his new sheet of paper and pass it back out through the slot in the door.

A native Chinese speaker then retrieves the resulting sheet of paper and reads it, likely with some surprise, for the sheet of paper contains a coherent response to the letter that she had written and slipped into the slot earlier in the day. The volume of rules is a remarkable piece of work, indeed. It describes a completely mechanical process by which any suitably meticulous person can appear to understand the Chinese language.

The situation that I have just described is a thought experiment known as “Searle’s Chinese Room.” The philosopher who originally described these events used it to show that even if a computer seemed to understand Chinese (or English, French, Spanish or any other human language), it wouldn’t neccessarily mean that the computer was sentient, as you and I are.

Of course, this is all common knowledge for most computer programmers. However, you may not have realized that a variation on Searle’s Chinese Room has been adopted by many large software companies.

The “Large Software Company Room” method begins when a software team-lead passes a piece of paper through a slot in the door and into the sealed room. The piece of paper contains a list of character strings, mostly made up of English letters, but with the odd number thrown in as well. For example, character strings such as WTL, DB2 or UDP sometimes appear on these lists. The occupant of the room examines each string on the list, and compares it to the character strings on a stack of other documents. If he finds that one of the other documents contains one or more of the character strings on the list, he places that document into a separate pile. Once he has finished sorting the documents, he takes the pile of documents that contained at least one of the desired strings and passes the pile back out through the slot in the door. The software team-lead outside of the room may then select one of the resulting documents, called “Resumes,” and contact the person who wrote it. What I have described as the “Large Software Company Room” is more commonly referred to as the “Human Resources Department.” In practice, the list of desired strings will frequently also contain other qualifiers, such as the number of years of experience in using a particular character string.

Sometimes this system can have undesired consequences. If a software team-lead asks for “Resumes” containing “Java,” then all resumes that don’t contain “Java” but do contain strings like “J2EE” and “JDBC” will be discarded. The obvious advice would be for the software team-lead to simply be sure to include all character strings that could possibly indicate a desirable candidate. However, I doubt that this is really a workable strategy. For example, even if I’m looking for a Python developer, that doesn’t mean that I would automatically eliminate a candidate with no Python experience. If they had experience with Scheme, Erlang, Haskell, Ruby, Smalltalk, Perl or any number of other interesting tools and technologies that have piqued my interest, then I might decide to invite that person to an interview. The only way to really know for sure is to see the Resume myself.

I understand that this may not always be possible if a company receives ten thousand resumes for a single opening, but how often does that really happen? I don’t object to HR departments helping to take some of the burden of hiring away from technical people, but the help should always be optional rather than being forced on resentful software developers by arbitrary corporate policies.

« Previous Page

Blog at