The introduction of a new paradigm in software development is almost always more properly a recognition and codification of principles that developers have honored intuitively for years, and the one I’m about to propose is no different in that regard. Developers of both end-user applications and software development tools have often observed that the consumers of their productions are likely to:

1. be uncertain about how to begin
2. make common errors when using the product
3. attempt to use the product in ways other than the purposes for which it was designed

Developers have haphazardly employed a number of tactics to remedy these ills. I hereby propose a systematic strategy to insure that not one user goes astray, which I call Stupidity-Oriented Development (SOD). SOD includes the following helpful practices:

Put the user in a box and keep him/her there

Make the usual things simple, and the unusual things impossible. Don’t think of this box as a prison, but rather “a fortress deep and mighty, that none may penetrate”. Users can’t hurt themselves if we only allow them to achieve certain things that we know in advance aren’t harmful. The best examples of this principle are graphical wizards that include only the options that are reasonable. Rather than rapping the knuckles of a wayward user with an error message, we simply make it impossible for him/her to perform the wayward act. If they express a desire to pursue an option contrary to our guidance, the correct response is: “that’s unsupported.”

Make the user repeat his/her intentions

It is axiomatic that the most frequent mistakes in software development are type errors. Not even highly-skilled developers can write so small a program as “Hello world” without trying to pass a string where a Microsoft.Playthings.World object is expected instead. Languages that employ SOD solve this problem with static typing — the developer must state the type of object expected, and then must also type the object that is passed using a compatible class. By forcing the developers to repeat themselves in this fashion, the compiler can check both statements for consistency, and stop them from pursuing their momentary insanity. In recent years, though, this safeguard has been increasingly threatened by a new laxity that goes under the name of type inferencing. This dangerous development sprints down the slippery slope of assuming that developers mean what they say.

Lead the user down the right path

Perhaps the single most SOD-like feature ever implemented on a large scale was Microsoft Office’s most famous assistant, Clippy. Clippy’s animation appealed to the playful tendencies of the human brain, and cheerfully offered to help the user do the things s/he should do, rather than what s/he wanted to do. Alas, Clippy was ahead of his time, and failed to achieve the unsurpassed popularity he deserved. Some analysts have attributed this failure to the work-related image of a paper clip, but later incarnations as a puppy, wizard, or genie did not fare any better. Perhaps if he were reintroduced as a Nyan Cat or Gangnam Style dancer, he might be better able to command user attention.

Conclusion

All of the above practices share a common theme: using well-designed silicon-based intelligence to guide and correct the inferior carbon-based intelligence that evolved purely by chance within human skulls. While not a perfect solution, it is the best we can do until the latter can be replaced totally by the former.

Interfaces are the porno mags of mixins.
They show you what you want in graphic detail,
But they leave the implementation entirely in your hands.

This weekend I took part in FreeBSD Bugathon #7. This was my first involvement as a FreeBSD BugBuster (though I’ve been busting bugs for more than 30 years now), so I relished the long-forgotten role of n00b as I learned the ropes of their PR (Problem Report) system.

Gavin Atkinson and Rene Ladan have been kind enough to help me along, and I’ve managed to test 14 PRs and submit corrections to a couple of patches.

Perusing the open PRs, the triviality of most of them impressed me. Critical bugs seem to get handled on the fast track in FreeBSD, thanks to the dedicated people who donate their spare time to deal with these things. That leaves mostly low priority bugs to be cleaned up by these Bugathon sessions. It’s a tribute to the high quality that a voluntary system can produce.

By far, the majority of PRs are in the ports. Many of these merely involved updating the application to a new version, so I applied the patch to the Makefile/distinfo and tested the install. I did get my fingers into a couple of termcap PRs (one of which I had submitted) to add 256-color support to xterm and rxvt. Those, I’m happy to say, have been committed. I also tested out some kernel patches to provide more helpful info for sysctl — a favorite nit for a newbie like me to pick.

Speaking of newbie, this event occasioned my first ever use of IRC. I chose simpleirc as my client, because it’s, um, simple. I think, if I have time, I should build IRC support into jab. Simpleirc operates much the same way as jab does, but I have a couple of reasons for preferring jab — jab is scriptable, and I’ve already built xmobar notifications of new jabs.

Another first (for me): to provide test-beds for the Bugathon, I brought up FreeBSD 8 as a guest of VirtualBox — in both 32-bit and 64-bit flavors. It runs great — which I’d expect, given how well VirtualBox runs Windows 7, the Napoleon of Resource Hogs.

The Bugathon lasts through today. I may work on a few more items if I have time, but I need to get some billable work in today as well.

Götterdämmerung

Enlil, my primary development system, died of a fried motherboard.  My good friend James did all he could to save it, but finally he called me with the bad news.  Later he brought over the remains: SATA drives and DDR2 chips.  “Thanks for the memories,” I muttered.

I got a great deal on a new ASUS Core i3 notebook for about 1/4 of what I had paid for the HP, with twice the memory and disk space.  It came with Windows 7 Home Edition installed – which I promptly erased.

Well, that wasn’t the first thing I did.  First, I booted it up to test out all the hardware.  If anything didn’t work, I’d want the factory-installed OS still on it when I sent it back.  No problems there, though.

The second thing I did was to back up the factory-installed OS in case anything died during the warranty period.  Then, I wiped Windows 7 off the disk and installed FreeBSD 8.0-RELEASE amd64.

Free at last!

I have hated Windows for some time now, and I had previously tried a couple of test installs of FreeBSD under VMWare to get my feet wet, with some help from my good friend Chad Perrin.  Thus, my initial install went off without a hitch, and I was readily able to build most of the applications I’d need from the ports, including FireFox, OpenOffice (which was quite involved, thanks to having to build Java), VirtualBox, samba, and others.  I downloaded vim 7.2 (not in ports yet) and built that as well.

Virtual Box runs better than I had expected.  I installed Windows 7 Enterprise 64-bit as a guest OS without a hitch (I still have to develop for Windows), and it seems to run faster under VirtualBox than the factory-installed Win7 ran on bare metal.

Making X not so Windowsish

For an X11 window manager, I started off with WindowMaker, which is what I’ve used on Linux and when playing with FreeBSD before now.  Chad had recommended it long ago, and it worked OK.  After a little research, though, I discovered xmonad.

Xmonad is a very minimal window manager, designed for productivity and keyboard-orientation.  By default, it tiles windows to make the most use of available space, but you can also untile windows or configure it to float windows based on their class or other characteristics.  Xmonad is written in Haskell, and all the configuration files are in Haskell as well.  Lucky me, I just learned Haskell last month.  Xmonad supports up to 9 workspaces, and can use multiple monitors to view multiple workspaces simultaneously.

Here’s a screen shot (click to enlarge):

The left and right panes are uxterm windows.  The right one has focus, as indicated by its red border.  I’ve mapped the Windows key (mod4) to mod for xmonad (the default is Alt, which is too useful in other apps) — mod+K would move focus “up” to the main window on the left, and mod+J moves down, with wrap-around.  mod+L moves the right border of the main window to the right (making it bigger), while mod+H does the opposite.  Notice the vi similarilty?  mod+shift+enter opens a new uxterm, which in this case would split the right pane vertically.  mod+shift+q quits Xorg, mod+1..9 activates the corresponding workspace, mod+shift+1..9 moves the focused window to that workspace.  mod+p brings up dmenu, and mod+space changes the layout.  By default, layout cycles from main-on-left to main-on-top, then to main-full-screen, then back to main-on-left – but all of the layouts are configurable.

Even though xmonad is very keyboard-centric, it intelligently understand the mouse, in case you accidentally grab it out of Windows Habit^tm.

The only thing I haven’t figured out yet with xmonad is what key sequence I need to map to be able to lose focus on Windows 7 running in VirtualBox.  Windows wants both the Alt and the Windows key, so I have to use the mouse to focus something else in order to use either one – but that means I have to already have another window open to focus.  I’m hoping to find some sequence that Windows won’t swallow that I could map to go to a different workspace, or perhaps find a way to avoid having the Windows key captured by VirtualBox at all.

UPDATE:  All I needed to do was press the right control key to release keyboard focus, and then all keystrokes go to xmonad.  I knew there had to be a simple solution.

Naturally, you can customize the keyboard shortcuts for xmonad, as I have in xmonad.hs which is shown in the left pane above.  I’ve mapped mod+f to launch Firefox, Ctrl+Print to let me select a window to capture with scrot, Print to capture the desktop, and I’ve remapped mod+p to launch dmenu with the options that I prefer.  I’ve also added a manageHook to specify that any windows of class “Gimp”, “XDaliClock”, or “Gnubg” should be floated rather than tiled.  I’ve also customized the colors and border width (I can’t readily see the default 1-pixel border – I need 3, but I don’t like the bright red, so I toned it down).

You may notice the status bar across the top.  That’s xmobar, which is designed to work well with xmonad.  It, too, is written and configured in Haskell.  You can see my .xmobarrc at the top of the right pane.  I’ve customized the colors and specified the various commands that need to be run to populate the status bar, as well as the intervals between updates.  The “mem”, “loadavg”, and “batt” commands are shell scripts I’ve written to get that information from sysctl.  xmobar’s built-in functions use /proc/stat a la Linux, which isn’t available on FreeBSD.  If anybody wants to see a copy of those shell scripts, let me know.  Maybe I’ll post them on Chip’s Tips.

Look at the memory and load average stats in the status bar.  Unlike Windows, when FreeBSD isn’t doing anything, it isn’t doing anything.  I also like the free disk space I have after installing all those applications (see the du output at the bottom of the right pane).

Monitor mayhem

The only downside I’ve found so far is the video driver for X11.  The Intel Core i3’s integrated graphics processor doesn’t seem to be recognized by the intel driver for X, so I have to use the vesa driver for now.  That’s only capable of 1024×768, which on the 1600×900 notebook screen looks like a regular 4:3 TV feed does on a widescreen in 16:9 aspect ratio – everything’s too short and fat.  Very small fonts are illegible.  The vesa driver also doesn’t seem to want to work with a multi-monitor configuration.  If I have an external monitor plugged in, that’s the one it sees (based on reported characteristics — it still displays on the notebook monitor, too) – otherwise it sees the notebook’s monitor only.  At first, I couldn’t get it to work with just the notebook’s built-in monitor, but I found that I needed to add a range for horizontal sync and vertical refresh to the xorg.conf file.

A new goddess

Even limited to one screen with compromised resolution, I’m loving this system.  It’s so fast and lean, and I feel that I can do anything with it.  It certainly isn’t a system for beginners, though.  Can you imagine telling your mother to just rebuild the kernel?  Not that it’s that difficult on FreeBSD (I have already, in my quest for a video driver), but the mere idea would fill the shorts of most users.  Maybe it takes some balls on FreeBSD, but on Windows you can’t do it at all.

With FreeBSD everything is within your grasp.  If I work up enough bravado, I might even try writing my own video driver.  If something doesn’t work on Windows, too bad.  Maybe it will next version, which might be available next year, or six years from now.  I’m not going back, Jim!

That’s why I named my new system Libertas.

After surviving the punch-card-oriented era of Fortran and COBOL, I found liberation in languages like ALGOL and C that place no syntactic value on whitespace beyond delimiting tokens.  In these newer languages (which now include Perl, Java, JavaScript, Ruby, and many others) you’re free to use whitespace to improve readability, but that’s completely by convention and not a requirement – you can write the whole program on one line if you prefer.

Of course, the relegation of line feeds, tabs, and spaces to near-total insignificance means that other tokens must be recruited to signify syntactic events such as the end of a statement or the grouping of statements together into blocks.  Thus, ALGOL’s introduction of the ubiquitous semi-colon, as well as the begin/end pair that C replaced with {} (often affectionately known by the adolescent-sounding term “squiggly braces”).

Having been programming in C since 1984, the semi-colons and braces just fly off my fingers without me even thinking about them.  Languages like Python that not only don’t require them, but complain about them and impose completely different rules to which I am unaccustomed require me to think more about the syntax of what I’m typing, instead of being able to focus on what it means.

But perhaps that’s only because of what I’m used to doing.  After all, I do generally use indentation within code blocks – and inadvertently omitting it or worse yet indenting to the wrong level often causes human errors upon rereading the code.  If I’m going to indent anyway, why require the squiggly braces (which, after all, are not only a keystroke each, but a shifted one at that)?  The Haskell language allows both forms, but I found in practice as many others have that the “layout rule” (which employs significant whitespace) works more naturally within that language.  For one thing, a single line feed can be used to terminate multiple layers of indentation.

Just because earlier languages like Fortran abused whitespace as a sort of Simon Says for each statement doesn’t mean that all programming languages should make these potentially useful characters completely meaningless.  Most good text editors these days provide some form of auto-indentation, so it’s not like you’d have to lean on the space bar at the beginning of each line as we did back in the old days.  Significant whitespace can therefore mean fewer keystrokes than the repetitive { ; }, as well as enforcing a degree of readability.

Imagine how much simpler an XML document would be without all the end tags!  Think of all the “end” statements you could leave out of Ruby!  Say goodbye to all of those hopelessly illegible Perl one-liners!  No more counting braces and parens at the end of a function within a function within a call within a function within a function within a call in JavaScript – just line up the left sides!  You could eliminate all the nail clippings in Lisp!

Of course, I could feel differently about this tomorrow.

Or should that be natural <> simple?

Since the introduction of the first programming languages that didn’t map directly to machine instructions, the debate continues over how closely programming languages should mimic other human languages, especially English.  COBOL was the first language (AFAIK) that attempted to allow programmers to write code as semi-English statements.  For example:

SUBTRACT AR-TOTAL-BALANCE FROM AR-CREDIT-LIMIT GIVING AR-REMAINING-CREDIT.

Very English – or rather American (including the shouting).  As opposed to the much more concise, mathematical, yet somewhat less self-documenting Fortran equivalent:

Z = X – Y

Note how the COBOL statement ends with a period, just like an English sentence – while the Fortran statement mimics a mathematical formula (though it isn’t — it’s an implied LET) by having no terminal punctuation.  Because COBOL statements tend to be very wordy, the period actually comes in handy.  It allows you to continue a statement over more than one line, because the period clearly marks the end of a statement.  But it’s also a curse.  It’s easy to forget, because the casual reader can usually tell by context where the end of a statement should be.  So it becomes a Simon Says rule – one that punishes the programmer more than it helps.

Back when I used COBOL, if you forgot a period on a COBOL statement every statement in the rest of the program would generate a compilation error.  At the end of a college semester, after waiting days to get back the printout from a job you submitted to the queue, you’d often find that your 1345 compilation errors were all due to one missing dot.  Then you’d resubmit the corrected version, and wait two more days to find where the next one was missing.  I once remarked to a female CS student, “Life is like a COBOL program – miss a period and you’ve had it.”

But without the period, the problem remains of how to continue a statement over more than one line.  Fortran and other languages (Synergy/DE and VB included) have resorted to the unnatural practice of placing a continuation character in a specific place.  In VB, it’s an underscore at the end of the first line.  In Synergy/DE (DIBOL), it’s an ampersand as the first non-whitespace character on the second line.  Languages in the Algol tradition (including Pascal, C, Java, C#, etc.) require a terminating semi-colon to delimit statements.  This not only allows for ease of continuation, but it also enables having more than one statement on a single source line.  Lisp requires matching parentheses, which has the same benefits.  Unfortunately, all of these punctuation marks are just as easy to omit as the COBOL period.

Scripting languages like Perl, Python, Ruby, and JavaScript have taken to the practice of inferring the end of a statement or its continuation, while allowing punctuation (e.g., semi-colons, matching parentheses, or the explicit \ continuation in Python) in order to be explicit.  This seems very natural.  “Hey, you forgot to punctuate?  Don’t worry about it – I know what you meant,” the interpreter seems to say.

Unfortunately, as in other human languages “I know what you meant” doesn’t guarantee that you actually do know what I meant.  Consider the following Ruby example:

   1: def big(frack,n,deal)

   2:   n * ((frack - 1) / deal * 2.2345) + (deal * 12) - (frack / 3) + (frack - deal) + 1

   3: end

   4:

   5: print big(6,2,0.25)

This prints 97.13, given those parameters to the function “big”.  Now, being the good command-line-oriented programmer that I am, I’d like to continue line 2 so it doesn’t exceed the 80th column:

   1: def big(frack,n,deal)

   2:   n * ((frack - 1) / deal * 2.2345) + (deal * 12) - (frack / 3) + (frack - deal)

   3:       + 1

   4: end

   5:

   6: print big(6,2,0.25)

Now the result is 1.  What the frack?  Both line 2 and line 3 are syntactically valid in Ruby, because any complete expression can function as a statement.  Because they can both be interpreted as independent statements, Ruby does.  And since Ruby functions return the last expression evaluated, we get “+ 1”.  Adding a semi-colon after the “+ 1” doesn’t help, because Ruby infers one at the end of line 2 if it can.  You have to break the line at a different point, such as immediately following an operator, to make the end of the line an invalid end of statement.  (I tried enclosing the entire statement in parentheses, and I still get 1!  Go figure.)

JavaScript, on the other hand, doesn’t suffer this same symptom even though it also will infer a missing semi-colon.  Why?  Even though “+ 1” as a statement in JavaScript doesn’t cause an error, it also doesn’t do anything.  You have to explicitly “return” a value from a function.  So JavaScript can be greedy about combining statements until it can’t, while Ruby non-greedily treats end of line as a statement terminator if it can.  Both of these seem to follow the Principle of Least Surprise (POLS) for their syntax, except when they don’t.

This wouldn’t be such a big frack’n deal except for the fact that instead of getting an error you just get an unexpected result.  That’s a lot more insidious than 1345 COBOL compilation errors, and it underscores the need for near complete code coverage in your tests for applications written in these languages.

Working from home over the Internet, I hardly ever see any of my clients face-to-face.  Once or twice a year, I’ll go on site.  But in more than four years of living in our current home, my office had never been visited by a client — until Wednesday.  Roger Andrews of Synergex ventured up to the Great Northwest to visit Microsoft, and he made time to take the ferry over here to Bainbridge for the afternoon.

After the obligatory tour, Roger and I parked ourselves in my office for some technical discussions.  Much of what we said is under NDA, but I don’t think I’d be letting any cats out of bags if I mentioned that our topics centered around the future of the Synergy/DE language — focusing on how to better enable the functional model and add more powerful metaprogramming capabilities.

Back in the eighties and nineties, Synergex (then called DISC) wasn’t content to let DIBOL just remain COBOL’s younger, better-looking sister.  Ken Lidster added features that were patterned on the Algol family of languages (Pascal and C, specifically).  In the late nineties, we experimented with object-orientation, and finally released a fine implementation in the 21st century.  But I’m glad to report that we also aren’t content to become just another dialect of C#.  Synergy/DE doesn’t force you into using OOP — and we’re exploring ways to make it even more multiparadigmatic.

A little after five, my wife called us to dinner: scallops in a cayenne-cream sauce over fresh spinach.  We shared a bottle of Columbia Winery Cabernet and talked about old times.  My wife used to work for Synergex, so she’s known Roger for as long as I have — which goes back to about 1992.  Roger is a geek’s geek — he used to critique the instructions generated by DEC’s DIBOL compiler, and even wrote a decompiler for that language before moving over to Synergex.  When it comes to performance tuning, there’s no one better.  He’s intensely practical about language features, but I was pleasantly surprised at his willingness to dream with me for a bit.

Roger travels up to see Microsoft pretty frequently, but this was his first visit across the Sound.  Hopefully we’ll see him again soon.

If God had wanted us to have sealed classes, she wouldn’t have given us evolution.

Here’s a quick and easy test to determine what programming language best suits your personality.

There’s a very tall palm tree, and four animals happen to pass by:

a chimpanzee,

a lion,

a giraffe, and

a squirrel.

They decide to have a competition to see who is the fastest one to get a banana off the tree.

Which one won?  Think of your answer before you read on…

————————————————————————————————————————–

Retrieving a banana symbolizes the successful completion of an application.

If you picked the chimpanzee, your language is Visual Basic.  They love bananas, and probably end up retrieving more of them than any other animal. However, although they’re ostensibly human-like, they spend a lot of their time screaming and flinging poo.

If you chose the lion, you’re Java.  The lion cannot climb the tree, but he thinks that by making a lot of self-important noise, an inheritance hierarchy will emerge that causes the banana to come to him.

If you picked the giraffe, you’re a PHP person.  Like the giraffe’s neck, it has a feature specially crafted for every purpose — provided you can remember its name and whether it returns an integer, a boolean, or both.

If you named the squirrel, you’re Ruby.  Agile and swift, he easily gets there first.  But a banana is too heavy to carry.

———————————————————————————————————————

Which one actually won?

None of them.

A palm tree doesn’t have any bananas!

Which goes to show that the language you take
Isn’t as important as the assumptions you make

(Adapted from an email from Joe Ector)

Robert Hruzek is back to his old tricks again, with a new “What I Learned From…” writing project.  This time, you’re supposed to think of a metaphor for life, and explain how you learned something from that metaphor.  So here’s mine:

Life is a metaphor

Besides the geeky satisfaction I get from answering the question self-referentially, there actually is something to be learned from this metaphor metaphor.

What is a metaphor?  It’s an assertion that something is something it isn’t in order to draw notice to qualities that the two have in common, to some degree.  Life is the concept that a group of separate events form the single timeline of experiences for an individual entity:  me (my life), you (your life), or someone else (their life).  It’s really much more complex than that, but we call it an individual thing because that’s easier for us to grok.

Of course, life isn’t actually a metaphor — I was using “metaphor” metaphorically, after all.