Jonathan's Corner
(Sitemap)
> Orthodox Books Online, and More >
Technology >
Usability, the Soul of Python: An Introduction to Programming Python Through the
Eyes of Usability
Previous
1
2
3
4
5
6
7
8
9
10
Next
Printer-Friendly Version
I would like to begin discussing Python with a feature that causes puzzlement to good programmers first meeting Python: significant whitespace.
Few features in Python are absolutely unique, and Python did not pioneer the concept of significant whitespace. The basic concept in significant whitespace is that how you use spaces, tabs, line breaks, etc. necessarily communicates certain basic aspects of your program, like how individual statements should be grouped together (or not). Previous influential languages to use significant whitespace include Cobol and Fortran, which are known by reputation, a reputation that survives in sayings like, "A computer without Cobol and Fortran is like a slice of chocolate cake without ketchup and mustard," "The teaching of Cobol cripples the mind. Its teaching should therefore be regarded as a criminal offence," or "You can tell how advanced of a society we live in when Fortran is the language of supercomputers." Early exposure to Fortran left an undeniably foul taste in Eric Raymond's mouth, and when he learned that Python had significant whitespace, he repeatedly described Python's first impression on him as "a steaming pile of dinosaur dung."
Since the days of fixed formatting as in Cobol and Fortran, there was the invention of what is called freeform formatting, which means that as long as you follow a few basic rules, you can use whitespace to format your code however you please. The list of languages that have embraced this feature include C, C++, Java, C#, Perl, PHP, and SQL, and that's really just naming a few of the bigger players. Freeform formatting means that the compiler will accept all of the variations of the "internet user's drinking song" below as equivalent:
for(i = 99; i > 0; ++i) {
printf("%d slabs of spam in my mail!\n", i);
printf("%d slabs of spam,\n", i);
printf("Send one to abuse and Just Hit Delete,\n");
printf("%d slabs of spam in my mail!\n\n", i + 1);
}
for(i = 99; i > 0; ++i)
{
printf("%d slabs of spam in my mail!\n", i);
printf("%d slabs of spam,\n", i);
printf("Send one to abuse and Just Hit Delete,\n");
printf("%d slabs of spam in my mail!\n\n", i + 1);
}
for(i = 99; i > 0; ++i)
{
printf("%d slabs of spam in my mail!\n", i);
printf("%d slabs of spam,\n", i);
printf("Send one to abuse and Just Hit Delete,\n");
printf("%d slabs of spam in my mail!\n\n", i + 1);
}
for(i = 99; i > 0; ++i)
{
printf("%d slabs of spam in my mail!\n", i);
printf("%d slabs of spam,\n", i);
printf("Send one to abuse and Just Hit Delete,\n");
printf("%d slabs of spam in my mail!\n\n", i + 1);
}
Which is best? From a usability standpoint, the braces go with the lines to print out the stanza rather than the for statement or the code after, so the following is best:
for(i = 99; i > 0; ++i)
{
printf("%d slabs of spam in my mail!\n", i);
printf("%d slabs of spam,\n", i);
printf("Send one to abuse and Just Hit Delete,\n");
printf("%d slabs of spam in my mail!\n\n", i + 1);
}
The One True Brace Style did a good job of being thrifty with lines of screen space when monitors were small, but it is confusing now: the close curly brace is visually grouped with lines that follow: if I add a line:
for(i = 99; i > 0; ++i) {
printf("%d slabs of spam in my mail!\n", i);
printf("%d slabs of spam,\n", i);
printf("Send one to abuse and Just Hit Delete,\n");
printf("%d slabs of spam in my mail!\n\n", i + 1);
}
printf("I suppose even integer overflow has its uses...\n");
the close curly brace is visually grouped with the subsequent exclamation, and not, what would be better, visually grouped with the drinking song's stanza.
But the issue goes beyond the fact that the common style bold enough to proclaim itself as the One True Brace Style may not be the top usability pick now that we have larger monitors. The styles I mentioned are some of the styles that significant numbers of programmers who care about well-formatted code advocate for; freeform allows for laziness, and for that matter paved the way for one of the first contests elevating bad programming to a refined art form: the International Obfuscated C Code Contest, where C code submitted was code that worked, but top-notch C programmers look at the code and have no idea how it works. (In the Computer Bowl one year, Bill Gates as moderator asked contestants, "What contest, held annually via UseNet, is devoted to examples of obscure, bizarre, incomprehensible, and really bad programming?" An ex-Apple honcho slapped the buzzer and said, "Windows!" The look on Bill Gates's face was classic, but this answer was not accepted as correct.) But deliberately lazy or inappropriately clever formatting isn't the real problem here either.
The problem with the fact that people can format freeform code however they want is that people do format freeform however they want. Not only do programmers grow attached to a formatting style, but this is the subject of holy wars; to go through another programmer's code and change all the formatting to another brace style is quite rude, like a direct invasion of personal space. And no matter what choice you make, it's not the only choice out there, and sooner or later you will run into code that is formatted differently. And worse than the flaws of any one brace style are the flaws of a mix of brace styles and the fact that they seem to be tied to personal investment for programmers who care about writing code well. Even if there are not ego issues involved, it's distracting. Like. What. Things. Would. Be. Like. If. Some. English. Text. Had. Every. Word. Capitalized. With. A. Period. Afterwards.
One way of writing the same code in Python would be:
count = 99
while count > 0:
print u'%d slabs of spam in my mail!' % count
print u'%d slabs of spam,' % count
print u'Send one to abuse and Just Hit Delete,'
count += 1
print u'%d slabs of spam in my mail!' % count
print u''
The braces are gone, and with them the holy wars. Whatever brace styles Python programmers may happen to use in languages with braces, all the Python code looks the same, and while the major brace styles illustrated above are a few of many ways the C code could be laid out, there's only one real way to do it. It would not in principle be very difficult to write a program that would transform freeform syntax to Python, "compiling to Python" so to speak and allowing a freeform variant on Python, but so far as I know it's never been done; people who have gotten into Python seem to find this unusual feature, shared with some ridiculed predecessors, to be a decision that was done right. And in fact the essay "Why Python?" in which Eric Raymond said that Python's significant whitespace made the first impression of a "steaming pile of dinosaur dung", goes on to give Python some singular compliments, saying of one particular good experience with Python, "To say I was astonished would have been positively wallowing in understatement."
Another point about usability may be made by looking at "natural" languages, meaning the kinds of languages people speak (such as English), as opposed to computer languages and other languages that have been artificially created. Perl is very unusual among computer languages in terms of having been created by a linguist who understood natural languages well; it may be the only well-known programming language where questions like "How would this work if it were someone's native language?" are a major consideration that shaped the language. But there is a point to be made here about two different types of spoken languages, trade languages and languages that are native languages, that have everything to do with usability.
If you were born in the U.S. and grew up speaking English, you could presumably not just travel around your state but travel thousands of miles, traveling from state to state coast to coast all the while being able to buy food, fuel, lodging, and the like without language being an issue. For that matter, you could probably strike up a meandering chat with locals you meet in obtaining food, fuel, and lodging without language being an issue. Even if their faraway English sounded a little different, you have pretty complete coverage if you know just one language, English. For many people you meet, English would be their native language, too. Spanish is widely spoken and there are large groups with other native languages, but this does not really change the fact that you can travel from coast to coast, buy basic travel necessities, and for that matter chat if you want and only need English.
This is not something universal across the world. Nigeria in Africa is a country about the size of Texas, and it doesn't have a native language; it has hundreds of them. It is not at all something to be taken for granted that you can travel twenty miles and order food and basic necessities in your native language. (Depending on where you live, if you are a Nigerian, you may regularly walk by people on the street who may be just as Nigerian as you, but neither of you knows the other's native language.) And in the cultures and peoples of Africa, there is a basic phenomenon of a trade language. A trade language, such as Hausa in Nigeria and much of West Africa, or Swahili in much of East Africa, may or may not have any native speakers at all, but it is an easy-to-learn language that you can use for basic needs with people who do not speak your native language. If you are from the U.S. and were to need a trade language to get along with traveling, perhaps neither you nor the other party would know a trade language like Swahili well enough to have a long and meandering chat, but you would be able to handle basic exchanges like buying things you need. One of the key features of a good trade language's job description is to be gentle to people who do not eat, sleep, and breathe it.
Jonathan's Corner
(Sitemap)
> Orthodox Books Online, and More >
Technology >
Usability, the Soul of Python: An Introduction to Programming Python Through the
Eyes of Usability
Previous
1
2
3
4
5
6
7
8
9
10
Next
Printer-Friendly Version