On Sturgeon’s Law and the Retro movement

Sturgeon’s law (called by Theodore Sturgeon himself “Sturgeon’s Observation”) is that “Ninety percent of everything is crap.”

This implies that, given that overall quality levels have remained the same, as much “good” material has been produced in the last ten years as has been produced overall in the last year; and as much “good” material in the last fifty years as overall material in the last fifty years.

Humans tend to remember the high points (the “good” material, or in rare cases the exceptionally bad material) much more easily than they remember the mediocre.

Thus we have the belief that all modern games are bad, because they are compared with the best games of the last thirty years; that all modern movies are bad, because they are compared with the high points of movie making since WW2. That all books are bad, because modern bodice-rippers are compared with To Kill a Nightingale and Catch-22.

It’s not really true. We overlook the crap and think the great games are representative of their periods. We overlook the modern classics-in-the-making and elevate the titles that have been proven by time.

There’s nothing inherently wrong with a “retro” view, because the older titles really are as good or better than the new ones, but we shouldn’t overlook excellent new material when it comes along – particularly when the best of it learns lessons from the “retro” titles, giving a richer and more nuanced view overall.

“Learning Python”: A quick review

My voyages into the Python programming language have largely been courtesy of a text called “Learning Python”, written by Mark Lutz and published by O’Reilly and Associates.

It has to be said: as a text for an experienced programmer learning Python, it’s severely lacking. For a beginning programmer, it’s probably worse.

Its main problem is that it seems to have trouble deciding what it is: a reference or a tutorial. The text is written largely in a tutorial style, going over the details of the language. However, the chapters are arranged largely as a reference, with each component of the language given a chapter or two to itself. Actual programming exercises are left to the end of the section, where each “Section” consists of the set of chapters covering a particular component of the language.

Control constructs, for example, are not introduced until well after page 300 of the eText. They’re introduced after a hundred or so pages introducing you to how Python runs programs (summary: a bytecode) and another couple of hundred introducing the fundamental types.

The net result is that you read hundreds of pages of text without writing a single line of code beyond retyping the chapter examples. I have an above-average memory, but remembering a hundred pages of text in detail without using its contents is not something I would regard as a good pattern for teaching. You learn programming by writing code, and there is precious little of that in this text.

Another minor point is that it uses as its reference version of python the 3.x stream, whereas most of the Python code and libraries available today are from the 2.x stream. As Python 3.x is not entirely compatible (in either direction!) with Python 2.x, you spend most of your time focusing on a version of Python that is just not used very much. It does actually lay down the differences between versions whenever they crop up, but the reference version is 3.x.

Altogether I can’t recommend it. As soon as I find a better text I’ll do a similar review. For now your best bet is probably www.learnpython.org.

Python considered Pretty Good

One of the things I’m spending spare minutes on while looking for a job is filling in gaps in my resume with skills that employers are asking for that I’m currently lacking. The main things I’m looking at are Puppet – a widely used Configuration Management system – Python, a scripting language that’s been around for some years, and Powershell, Microsoft’s recent foray into decent scripting languages. The fact that all 3 start with “P” is an interesting but meaningless coincidence.

Puppet looks very straightforward offhand; it uses a configuration model very similar to Nagios, which I’ve been using for years. Powershell¬† I’ve used somewhat previously, but don’t know enough to code extensive projects. However, I’ve mainly been looking at Linux based positions so Powershell is the last of the three I’ll be concentrating on.

That leaves Python.

I’ve had the first edition of O’Reilly’s “Learning Python” decorating my bookshelf for some years without really cracking the spine. Recently I picked up the 4th edition as an ebook and have been working my way through it. The book takes a LONG time to get moving. It spends at least fifty pages telling you good reasons to learn the language and how to fire up the scripting engine. However, I’m starting to get into the meat of it now.

I have to say I’m impressed.

For some time my default scripting language has been a bastard mishmash of Bourne shell and awk. Awk can be remarkably powerful due to its associative arrays; the feature was inherited into Perl and also (as it turns out) as “dictionaries”, Python.

Python has a remarkably powerful set of basic types. In addition to the standard integer, floating point, string, boolean and so forth, it has arrays (natch), dictionaries (associative arrays, indexed by object), sets (collections of objects with no duplicates) and tuples, which are basically constant arrays that can be used as indices in dictionaries and representatives of sets. There are also a bunch of standard types in the shipped libraries to handle fractions, complex maths and fixed-point arithmetic. And others (such as files and function references).

There’s also some very nice syntactic sugar constructs that can be applied to make code powerful while still remaining fairly readable.

The very powerful core idea, however, is the extent to which Python combines the idea of types associated with objects rather than variables, and operator polymorphism.

This means that a basic function can be redefined to operate with a different class as long as the class has operations corresponding to the operators used by the class. In a language like C or Perl, if you want to pick a maximum value, your function has to be defined for each class:

int max(int var1, int var2)
{
    return (var1>var2) ? var1 : var2;
}

This needs to be defined separately for each type, so you have the same basic code for integers, floating point, and any other relevant types. Generally speaking, it also needs to be defined for each combination of types (depending on how strongly the language is typed).

In Python the type is associated with the object, so as long as you have your operators overloaded with the right types, you can simply call the function with the relevant arguments. The function looks at the object types, picks out the function or code that performs the correct comparisons, and does the job. It’s an extremely powerful approach.

In any case, I’m still working my way through the book so it will be a while before I’m fully familiar with the language. Liking it so far, however…

(The title of this article is a very indirect reference to¬†Dijkstra’s classic letter “goto considered harmful.” It’s been quite a while since I saw an actual goto in code, although modern languages have mechanisms that do similar things in a less horrible way.)