Drinkable Chicken

This started out as a Chicken blog, where I would report my adventures with Chicken Scheme. But these days it's more like a Python blog again. (Which isn't too surprising, given my experience with the language, and the fact that I use it for work and most of my personal projects.)

Heck, it has even been added to Planet Python again, which wouldn't have been the case if I wrote about Scheme all the time.

But really, I want to learn more about Scheme as well, *and* be able to use it in a pragmatic way. I just need a bit of focus. Right now I'm wondering what to look at next. Maybe object systems?

People new (and not so new) to Python are often confused by the fact that the language uses functions in some situations, but methods in others. I see this come up a lot these days. The most recent example is this comment:

Say you have a list, how is a beginning supposed to follow/comprehend the bigger picture when faced with code like this:

mylist = [1,3,2]
print len( mylist )
print sorted( mylist )
print mylist.sort()
print mylist.reverse()
print mylist[0]

Honestly, what is going on here? Why different syntaxes for slightly different ideas?

This gives many people the feeling that OO in Python was added later, or "bolted on", as Taw puts it.

I figure the reasons for the discrepancy are like this:

In 1991, when Python was first released, *pure* object-oriented languages were rare. Sure, there was Smalltalk, but it was fairly obscure. Other languages that called themselves object-oriented, like C++ and ObjectPascal, were actually hybrids; objects were indeed "bolted on" to an existing language.

In this light, it makes sense that Python 0.9.1 did the same. It had built-in types, and user-defined objects. Some of the types, like lists and dictionaries, had methods, possibly because were mutable and therefore contained "state". Other types, like numbers, strings and tuples, did not have methods (and were therefore not "perceived" as objects, even though behind the scenes they were). (In fact, back in the early 90s, the idea of calling a method on a number seemed like a really odd idea (if you were not a Smalltalker :-).)

As a result, in order to take the length of a string or a tuple, you needed a *function* (because you could not call a method on these types). While list and dict could easily have had such a method, for consistency's sake this was omitted; instead, the len() function was to be used on them too.

And so it still is. But the world has changed since then. OO has become much more mainstream, and the notion of using methods for everything is no longer odd, but expected by many. I can understand why someone coming from Ruby (or maybe Java) would wonder why in some cases functions are required, where a method would seem more natural. It makes Python seem inconsistent, when initially the use of len() actually improved consistency.

This is something that *could* have been fixed in Python 3.0, but won't, as far as I understand it. I'm not sure if this is a missed opportunity, or that it will keep Python closer to its original spirit (i.e., a multi-paradigm language).

(Note: I am aware of the __len__ method of course, but honestly, who is really going to use that instead of len()? __len__ is a hook to make len() work, not an alternative for it.)

When I was little, my parents had a Rubik's Cube. I spent lots of time trying to solve it (or even parts of it), with little success. We had a book that was supposed to tell you how, but that didn't help either. (Hey, I was only 9 or so at the time...)

So a while ago I got it into my head to give the Cube another try. Bought one last weekend, and tried to figure it out. So far these videos have been very helpful:

I'm saving it here because it's probably not going to last. :-)

(just a random thought :-)

I sometimes wonder what old folks homes will look like 60 years from now... I imagine it will have scores of 80-somethings with tattoos and piercings drooping from their floppy, wrinkled skin. And the young people taking care of them will be like, WTF were you thinking?

Cubivore for the Gamecube is a rare game, but the price that this seller is asking seems a bit outrageous:

It seems eBay is a better bet in this case...

(If you don't know Cubivore (which is likely), check out this video. There's many more on YouTube, worth watching if you are into odd games. ^_^)

So Python 3000 will have abstract base classes.

As far as I know, in the Python world, an abstract base class used to mean, a base class that cannot be instantiated. Kind of like:

class Foo:
    def __init__(self):
        raise NotImplementedError, "Foo cannot be instantiated"

It would, however, be perfectly possible for an abstract base class to have valid, working methods, to be used by classes inheriting from Foo.

Apparently this isn't the case any longer. If I read PEP 3119 correctly, in Py3K-speak, an abstract base class is a way to trick isinstance() and issubclass() into believing that a given class derives from another class, when this actually isn't the case. For example:

>>> list.__bases__
(<class 'object'>,)
>>> object.__bases__
()

list derives from object, which in turn derives from nothing else. But:

>>> issubclass(list, collections.Sequence)
True

In other words, list *pretends* to derive from Sequence, but it really doesn't, and so any methods defined in Sequence will not be inherited by list.

Filtered through my old-school-Python-riddled brain, this implies the following:

• abstract base classes mean something different now, and
• they break isinstance and issubclass, and
• methods defined in the ABC cannot be used by the "subclass".

Seriously, the more I read about Python 3.0, the harder it becomes for me not to be appalled. The language makes a heroic effort at fixing warts and problems and trimming fat, but at the same time it's becoming more and more complex.

I'd love to be proven wrong though. I like Python a lot, and I am (and have been) worried about what it's evolving into. But maybe Python 3.0 will actually be easy and intuitive to use, like the Python of old, and all the overly complex stuff will stay in the back rather than get in the way. I guess time will tell. (Or maybe I'm misunderstanding things... feel free to point that out. :-)

(This is mostly a matter of personal preference, of course -- for the last few years I've been gravitating toward languages with little syntax, that allow powerful new constructs to be written in the language itself. Think Scheme and Io. Python, however, has steadily been moving in the other direction.)

In which I react to some of the comments on my "Who needs code samples?" post.

Rather than quoting people, I will reply to some of the general ideas outlined in the comments. After this post, it's case closed; this whole discussion has taken up way too much energy and time already.

Sample code contains implementation details, while formulas deal with the abstract concept (rather than a specific implementation).
No disagreement there. It would have been better if the book had given both formulas and example code. In an ideal situation, it would also have tried to abstract away some concepts (data storage, etc), or at least separate them from the actual algorithm. OTOH, this might not always have been possible, as performance is an issue as well.

Suggestions to look at SICM:
I have looked at this book before, but gave up on it before long. One of the reasons might have been the abudance of formulas; another is that I am not particularly interested in physics.

Competent programmers know how to read these formulas. Computer science is programming. Reading math formulas is a useful skill for programmers. You need a degree in CS to be a good programmer. (etc)
Here I refer to my previous posts about the relevance of math in everyday programming tasks.

The formulas described in the original article are not particularly difficult.
Probably, but they still require context to read them. In short: ||v1-v2|| requires that you know what v1 and v2 are, what || stands for, what subtraction means in this context. By contrast, vector1 - vector2 is a bit longer, but much clearer. My point is that I neither need nor want to know the context to read these particular formulas, because they have no relevance to my work.

Strong anti-math sentiment:
I believe this is related to the fact that some people love to shoehorn programming into the mathematics branch. It just doesn't belong there; the math needed and taught in CS courses has little relevance to the real world (hence the vast numbers of CS graduates that are unprepared for a real programming job). This causes resentment.

In my case, there are other reasons why I object very strongly to the notion of "math is a requirement to be a programmer". In fact, when I was ~16, I wanted to become a programmer, so studying computer science seemed a logical step; then was told that you needed to be good at math. This struck me as odd, since I had been tinkering with programming and it required very little math, but hey, people must know what they're talking about, right? So I went on to do something else, keeping on programming as a hobby. I sold some of my homebrew programs. No math required. Eventually I landed a job as a programmer. Still no math required. That was 10 years ago; in the meantime I've written all kinds of software, very few of which need any advanced math.

This notion ("you need to be good at math to be a programmer") almost stopped me from realizing my dream. I figured it must have stopped others as well, and still does, so I will do everything I can to fight this myth.

Formulas are a great way to express abstract concepts; their notation is really just another "language" one needs to learn.
This is true, but I'm unsure if learning this "language" will benefit me much (other than saving me from the scorn of Reddit readers ;-). Aside from that, the notation has problems... but that's a different story.

Code examples in Haskell:
Haskell is interesting, but it does strike me as math notation disguised as a programming language. It suffers from some of the same problems: conciseness to the point of being unreadable, and little usefulness in the real world. That said, maybe someday I will make a serious attempt at learning it properly.

:::

All this discussion has distracted from the fact that I don't hate math, and am not particularly bad at it either. I just would prefer code samples in many cases. That's all. I'm now going back to my coding. :-)

Looking at the comments on my previous post and the subsequent Reddit thread, it seems that many implicit assumptions are made, some of them dubious at best. Without going into all of them, I will say this:

• It's possible to know areas of math relevant to computer science, and to dislike mathematical formulas at the same time. It's quite reasonable to be unfamiliar with areas that you don't encounter in everyday programming.
• Computer science may be mostly math, but computer science != programming. It plays an important role, but in most programming jobs, most CS concepts are rarely touched upon.

There's also a more dangerous set of assumptions shining through the whole discussion. It comes down to this: "Programming is computer science. Computer science is math. The more advanced math you know, the better a programmer you are. If you cannot do something rudimentary like reading a mathematical formula, then you don't know math, and therefore you cannot be a competent programmer."

If you want to believe that (or a variant thereof), be my guest, but it's simply not true. Unless you redefine "programming" to mean "100% computer science", rather than all that messy stuff that people do in the real world. You know, with GUIs, web apps, databases, SQL, dynamic languages, design, unit testing, refactoring, ...? Oh wait, you probably *don't* know. My bad. :-)

Wow, my previous post sure stirred up some controversy (by my blog's standards at least ;-). As I write this, the comments are still pouring in. (Also see the Reddit thread, which is probably where all these new commenters come from.)

But really, what I was trying to say is quite simple:

• I am a programmer.
• I am *not* a mathematician (obviously :-).
• If given a choice, I would much rather see the code sample (which I can understand) than the formula, although in an ideal situation you'd have both.

For some reason, some people seem to take "I don't like to read mathematical formulas" to mean that I know next to nothing about math. This assumption is not necessarily true. Nowhere did I mention anything about my background, other than the fact that I am not a mathematician. (For the record, I studied economics in college.)

Anyway, whatever my background, seeing convoluted (and even not-so-convoluted) mathematical formulas tends to intimidate me (much like it intimidates *everybody else* who doesn't have a strong grasp of this stuff). Not because I am inherently unable to, but because I lack the knowledge about what most of these symbols and constructs mean, in the given context. As I am a programmer rather than a mathematician, I prefer code samples.

Some people are apparently offended by this. Take, for example, this eloquent rebuttal. "How can you forget stuff like the meaning of Σ or Π as accumulators?" Gee, let me see... maybe because I have never needed it in my job as a programmer? You learn it. You don't use it. You forget about it. (The formula, that is, not the concept.)

Let's take the vector example in the original article. Some seem to think it's ridiculous that I would prefer the code over the formula. But tell me... why in the world should I know vector notation? Or why would I want to, in the first place? I've been programming since 1985, and I have *never* needed vectors. I guess I haven't been doing any real work!

For some reason I never needed differential equations either when I was trying to debug a GUI app or write an SQL query. And all this time I thought I was an actual programmer! Silly me!

Now, I am not trying to downplay the importance of computer science, or the importance of math in computer science. There are certain areas of programming that are strongly math-related, and wouldn't exist without it. I also believe that having a decent grasp of math makes one a better programmer. ¹) It's important... but not to the point where you have to be a math major in order to be a competent programmer!

Many (or even most) areas of math are completely irrelevant to my day-to-day work. While this is not true for everyone, it is true for the vast majority of programmers. So I don't like to read mathematical formulas. How does that affect my skills in designing a GUI, writing an object system, debugging a database, optimizing a query, writing unit tests with good coverage, refactoring a code base, ...?

Anyway, in my next post I'll react to some of the more reasonable replies to my post. :-)

¹) And so does a decent grasp of philosophy, sociology, linguistics, art, organization skills, emotional intelligence, ...