Tuesday, January 19, 2010

Sapir-Whorf in Software Engineering

What follows is a short essay I wrote for my software engineering class last semester.
I have many interests; one of them is linguistics. I first heard of the Sapir-Whorf hypothesis, also called the linguistic relativity principle, some years ago and it caught my interest. Despite the many objections and resistance brought against it, I have always found it to be rather compelling.

It seems obvious to me that the language we use to describe and interface with the world should shape our cognition about the world. Many studies have been done which show this in natural languages. But it seems that there have been fewer studies about this principle in programming languages, especially in software engineering.

I remember when I took CS 330 about a year ago. CS 330 is a course on programming languages, and the language of the class is Scheme, a cousin of Lisp. Scheme is a functional programming language, which is to say that, in Scheme, functions are first-class objects, just like any other data type. This was the first time I was ever really exposed to the functional paradigm (although I saw a little of it before in Javascript), and it had a rather profound effect on my skills as a software developer. For when we studied Scheme and used it to investigate the principles of programming languages, my thinking about programming changed; it expanded into new realms, and I could see things that I had never really seen before.

One of the things studying Scheme did for me was to get me interested in programming languages and related concepts. But more immediately, it added to my cognitive landscape the idea of functional programming. Not long after I began to learn Scheme did I come to see the benefits of functional programming in other languages, like Python, which I learned has a "lambda" keyword like Scheme. Soon I began to incorporate functional principles in my work outside that class, in  other classes, and so on. I was writing software in a way that I would not have done before without having been exposed to this new paradigm.

And thus it is with software engineering. The long use of the same tools, practices, patterns, languages, etc. often constrain our thinking and deprive us from creating elegant, simple solutions to problems. While I am a firm believer in process---process in the sense that there must be some means by which a software development organization develops its software, and that it should be at least somewhat structured, I also acknowledge the fact that adhering too rigidly to process and procedure can stifle creativity and ossify the mentality of an organization. This is to be avoided, since software development is a creative enterprise; it is by no means formulaic.

We software engineers, programmers, or whatever we like to be called, are, in a sense, linguists. We learn and use languages all the time. As such, we are subject to linguistic principles. Despite the objections of Chomsky and others, I have always found Sapir-Whorf to be true---so true, in fact, that it's a self-evident proposition.

Friday, February 27, 2009

Build Firebug Into Firefox

The other day I came to a startling realization: that all of the major web browsers—except Firefox—have Firebug-like developer tools built into them. Specifically, these browsers:



  • Internet Explorer(!) 7 and 8

  • Safari

  • Google Chrome

  • Opera


This is clearly the way things are going. Firebug and similar tools are so critical to developing web apps now that I think the Mozilla Foundation ought to acquire Firebug and build it into Firefox. I'd accept making it an option on installation, defaulted to "off," so that non-developers needn't deal with it.

Tuesday, November 11, 2008

A little WTF from academia

Have a look at this:

Notice Anything Weird Here?

It's from a genome sequencing project from one of my CS classes. Do you notice anything odd about this database---perhaps a bit WTF-ish?

Thursday, August 21, 2008

I Love Ubuntu

I am curious by nature, and I'm always looking to see whether there's something better over the horizon. I installed Ubuntu 8.04 Hardy Heron the day after it was released, and I was impressed. But I knew there were other fine Linux distros out there, like Fedora 9, OpenSUSE, Arch, and others.

Recently I've tried a few of these on my laptop, but I invariably return to Ubuntu Hardy Heron.

Why? Here:

  1. It just works. You put the CD in, run the installer, and, after answering a few questions, you get a nice, working Linux system that supports your hardware and is ready to go. No extra configuration, no tweaking of the UI (do you hear me, Foresight?), the drivers are loaded, and everything's happy.
  2. The default install is excellent. In the installer, you don't pick packages to install. Instead, you get a default installation, which includes Firefox, Evolution (which I actually could do without), the OpenOffice core, Gnome, and common Gnome apps. That's fine with me. Then, once the system is installed, I can pick the packages I want—Vim, Emacs, Eclipse, Thunderbird, and so on.
  3. The package repositories are vast and up-to-date. Want to install Orpie without building it from source? It's available on a few other systems, but I've found that only Ubuntu has version 1.5.0 in the repos. If I want it, chances are high that it's already in Ubuntu's repos. Want to install Emacs 23, which uses Xft font rendering? Install the emacs-snapshot package.
  4. It's not paranoid about "non-free" software. Some Linux users might call this a bad thing, but when I need an MP3 codec, I really don't want to have to jump through hoops to get it. Yes, Ubuntu will warn you when you're about to install these, but they're in the repos, and you can just get them. Same with Sun's JDK. For most purposes, I really don't care whether it's "free-as-in-speech" or not.

Those are the four main reasons I like Ubuntu. At this point in the world of Linux distros, if Linux is ever to make any substantial gains into the desktop market, it will be Ubuntu that does it.

Thursday, July 17, 2008

Vim tip

In Emacs, you can use C-x-right or C-x-left to switch between buffers. Vim has the commands :bnext and :bprevious which do the same thing, which can be shortened to :bn and :bp. But with these lines in your .vimrc file:

map <C-Tab> :bn <CR>
map <C-S-Tab> :bp <CR>

you can use ctrl+tab and ctrl+shift+tab to switch between buffers. Nifty, eh?

Or better yet, how about this:

map <silent> <C-Tab> :bn! <CR>
map <silent> <C-S-Tab> :bp! <CR>

Wednesday, June 20, 2007

Amazon SQS CFC

I've just published the first version of a ColdFusion component for the Amazon Simple Queue Service (SQS). The SQS CFC uses mostly the query interface to SQS' API, except for the sendMessage method, which uses REST. This is because the query interface version of sendMessage only allows messages with a maximum size of only 8 KB, whereas the REST interface allows messages up to the full 256 KB limit.

A known issue exists with the addGrant method, which, as of 20 Jun 2007, is returning "Service Unavailable."

It's now available at Google Code. Just download the zip file and insert your Amazon Web Services Access Key ID and Secret Access Key into index.cfm, and start queuing.

Amazon SQS CFC - Google Code

Tuesday, June 12, 2007

I shall never use Eclipse again

Today, while working on a snazzy ColdFusion component I've been writing for the Amazon SQS API, my IDE, Eclipse, behaved erratically: first, when trying to save the latest changes to the CFC, Eclipse paused for several seconds, and then finally saved the file. Then I continued making changes, and tried to save again. Another pause, and then Eclipse said, "This file has changed outside in the filesystem. Want to reload it?" I elected to reload it, which I now know was not the right thing to do, because I got a file that was zero bytes in size! Eclipse had just destroyed my source file!

I'm sorry, but I can't have that--not while working on serious code. I am furious.

A ColdFusion IDE! A ColdFusion IDE! My kingdom for a ColdFusion IDE!

I shall never use Eclipse again.