Chad Perrin: SOB

28 May 2006

Whitespace and Instructional Programming Languages

Filed under: Cognition,Geek,RPG,Writing — apotheon @ 09:26

A discussion of the “whitespace problem” of Python occurred in another venue, and some of what was said there got me thinking. It starts with a complaint about the way Python eschews punctuation, and snowballs from there.

One particular point that came up was the assertion by Pythonistas that using significant whitespace instead of punctuation somehow reduces “syntactic clutter”, even while noting that whitespace is a part of Python syntax. It’s kind of surprising, once one stops to think about it, that these guys don’t notice that it doesn’t reduce “syntactic clutter” at all, but merely replaces one type of “syntactic clutter” with another. Depending on one’s definition of “clutter”, one might even say that Python’s approach increases rather than decreases “syntactic clutter”.

The comment that got me thinking the most interesting thoughts, though, was the one that mentioned a study that found significant whitespace provided an appearance that was “easier to read” for non-programmers than programming punctuation. I rather suspect that was skewed somewhat in favor of the significant whitespace crowd by comparing all-indentation-without-punctuation to all-punctuation-without-indentation. Of course, in the real world, nobody eschews indentation formatting in production code. It’s Just Not Done. I guess part of my problem with Python, based on that, is the fact that Python does something akin to making a law forcing people to use verbs. Everybody uses them already, and even if someone decided to avoid using verbs for some reason, it would surely be a joke that didn’t hurt rather than because they’re criminal masterminds. It’s the same situation with indentation in programming.

That note about non-programmers being better able to read it brings Ruby to mind (for me, at least).

Basically, the idea is that an instructional language has to be more than merely readable to someone that hasn’t yet been instructed. It also has to be writable and, perhaps most importantly of all, editable and debuggable. Python achieves the first of these, but demands an awful lot from rank newbies for the second (writing), and even more for the third (editing and debugging). Even expert Python programmers can have intractable issues with misplaced whitespace from time to time: I’ve heard the complaints. I’m inclined to try to insulate brand new programmers against the problem of spending an hour looking for one misplaced space in an indentation. Beginners should be learning how to develop good code, after all.

Good indentation formatting is important, but so too is everything else. A language that encourages good indentation is what’s really needed: making whitespace significant so that good indentation is necessary for the program to run is a very heavy-handed way to achieve that effect. Considering the wide range of languages available, and all the available syntactic quirks in all those languages, it seems something with a flexible syntax is more important than one that enforces a specific individual’s idea of what constitutes “good practice” — but there’s no reason to pick a language with a flexible syntax that doesn’t encourage “good practice”. In addition, anything you can do to increase the ability of a new programmer to recognize what’s going on is a good thing: eschewing end delimiters just because you think you’ve found the Holy Grail of indentation schemes and enforced it syntactically seems antithetical to that aim.

Ruby seems to provide all of these benefits, and also makes a smooth path of transition toward learning the formatting methodologies employed by other languages. What’s not to love?

That’s how I see it, anyway.


  1. Agreed, wholeheartedly. Lets leave the indentation rules to COBOL and Fortran.

    Comment by SterlingCamden — 29 May 2006 @ 10:57

  2. Of course, in the real world, nobody eschews indentation formatting in production code. It’s Just Not Done.

    That, I think, was the point of saying Python reduces clutter. It’s the DRY (Don’t Repeat Yourself) principle — any time you must state something twice is an opportunity to introduce inconsistency, and requires more work to maintain. So, why specify the nesting relations twice, especially when they might not say the same thing?

    Granted, in the real world, it’s not really an issue. The people who run into indentation issues in Python are generally the same people who have indentation issues in other languages. The real lesson, perhaps, is “don’t program using pico/notepad”. If you have to care about those sorts of things, you’re probably doing it wrong.

    I like both approaches… Punctuational nesting is easy to auto-format with tools like “indent”. That works great for the linux kernel crew… each person can use their own preferred style and auto-convert it during checkin. However, without auto reformatting, I’ve spent far too many hours tracking down single-character- and indentation-related errors in C and C-like languages. I’ve only spent a few minutes (if that) on the same sort of thing in Python and lisp.

    The Python approach has different advantages, like having visually clear relationships and a general straightforwardness about it. It resembles the high-level pseudocode many people use to describe algorithms in documentation or collaboration, except it’s executable. I found, at least, that the language felt natural to me because I had been using something almost identical for years before I ever heard of Python.

    As for being easy/hard to write, that’s probably just a personal thing. I’ve found that, even my first time using it, my python code almost always works on the first try. ESR’s article about writing fetchmailconf described a similar experience (which is what got me interested in the first place).

    Anyway, it works well for me. But if it doesn’t fit your thought patterns, then don’t use it. :)

    Did I have a point? I forget. Oh well… I ramble.

    Comment by ToyKeeper — 11 June 2006 @ 07:49

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

All original content Copyright Chad Perrin: Distributed under the terms of the Open Works License