Skip to content
November 11, 2008 / Abe Pralle

Ergonomic programming and the multi-dimensional ‘which’

In classic fantasy stories, knowing the true name of a demon or a faerie gives you power over it.  Taken as a metaphor, I think this leads to a profound truth: you do not truly understand a thing until you can accurately describe it.

I’ve seen this in practice many times.  Some examples:

  • Once I started teaching I became a significantly better programmer because I had to explain things to my students.  I could no longer just avoid using or discussing the commands I was uncertain of – students have a knack for asking you about the one thing you wish they wouldn’t!
  • One of the best techniques for debugging something is to explain exactly what you’re doing to someone else.  Usually, half-way through the explanation the light-bulb will click on.  That process of trying to distill your abstract problems into coherent sentences is usually the nudge you need to spot the problem.
  • Likewise, John Placer, a CS professor who was at NAU for many years, once said (and I paraphrase): “Write a comment for a method before you write its body.  If you can’t explain what that method does, you need to redesign it before you continue coding.”  So true! (Not that I actually write comments first, but I agree that you should be able to!)

Until recently, Slag’s motto was “The Language of Games”.  I’ll admit to taking a cue from Matlab’s “The Language of Technical Computing.”  But as time wore on I grew increasingly dissatisfied: what makes Slag the language of games?  How do I really sum up the language in a short phrase to someone who’s never heard of it?  In short, I had picked an arbitrary description that did not really fit.  I did not really understand the nature of my own language.

After months of off-and-on deliberations, I changed the motto to “Ergonomic Programming”.  It instantly felt right.  It’s a mnemonic that enables me to identify and understand the underlying nature of the language, to reexamine past decisions in light of this unifying theory, and to add new features with purpose and clarity.  Most all of my language features are still solid, but now – like a trained psychologist reflecting on his own childhood – I understand why I designed things the way I did.

So: Slag is the language of ergonomic programming.  This means that it provides an easier way to accomplish the tedious, repetitive coding tasks that we always perform but rarely actually think about.

I’m teaching Compilers this semester and taking the opportunity to rewrite the Slag compiler in Slag itself (instead of Java) as part of my “prep”.  There are a number of cool ergonomic enhancements in “gen2” – I’ll mention all of them over time, but let me start with just one: the multi-dimensional which.

It’s super-simple: the which (Slag’s equivalent to switch) can now evaluate multiple expressions at once.  The idea for it came after realizing that I type this sort of thing a lot:

  if (A == value1)
    if (B == value1) result = R
    elseIf (B == value2) result = S
    else result = T
  elseIf (A == value2)
    if (B == value1) result = U
    elseIf (B == value2) result = V
    else result = W
  else
    if (B == value1) result = X
    elseIf (B == value2) result = Y
    else result = Z
  endIf

As a which it would look like this:

  which (A,B)
    case (value1,value1): result = R
    case (value1,value2): result = S
    case (value1,value3): result = T
    case (value2,value1): result = U
    case (value2,value2): result = V
    case (value2,value3): result = W
    case (value3,value1): result = X
    case (value3,value2): result = Y
    case (value3,value3): result = Z
  endWhich

In addition, which now accepts simple ranges case cases – “which (code) / case 33..126” is converted into “if (code >= 33 and code <= 126)”.

Pretty neat eh?  And ergonomic too.

Advertisements

2 Comments

Leave a Comment
  1. Jacob Stevens / Nov 17 2008 2:42 pm

    Really, really, great idea! I can’t wait to use this feature!

    It’s also great for bug prevention. When writing code that looks like the if statement version, I’ll often update one of the if(B) cases and forget to change and test the other if(B) cases. This is much more robust and easy to maintain.

    Jacob

  2. ergonomic height / Dec 12 2009 8:20 am

    Intimately, the post is actually the greatest on this valuable topic. I concur with your conclusions and will eagerly look forward to your incoming updates. Just saying thanks will not just be enough, for the extraordinary clarity in your writing. I will right away grab your rss feed to stay privy of any updates. De lightful work and much success in your business endeavors!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: