March 26, 2006

Note to self - Python properties are non-polymorphic.

Properties are just one application of Python ubiquitous proxying. The properties are created as wrappers over get/set methods:
class C(object):

def __init__(self, value):
self._value = value

def _get_value(self):
return self._value

value = property(_get_value)

# all is fine, value calls C._get_value:

assert C(10).value == 10

Here is what's happening: an instance of a property class is created and a reference to C._get_value is stored in it. Next time c.value is referenced, the property calls the original method.

The problem is, the reference is bound to the particular class C, and so if you inherit from it, you should not expect the property to be rebound to the ancestor class'es method:
class D(C):

def _get_value(self):
return self._value + 1

# now, this still calls C._get_value:

assert D(10).value != 11

The properties are thus non-polymorphic. There is one way to make them such by introducing late binding,
class C(object):

...

value = property(lambda self: self._get_value())

but I personally find it cumbersome.

March 24, 2006

Moore's law as a social amplifier

The hardware world lives by the Moore's law of constant speed up. The software world is following the same trail, but there is significant difference - hardware measurably increases performance while staying on the same line. Dragster style if you like. Compared to this software is a bunch of beer cans hanging off the racer's bumper:

It makes a lot of noise. So much noise, 90% of the humanity can hear it, for God's sake.

More stuff can be added as the car's engine gets more powerful. What for ? Heck, why not ? After all, people prefer dancing pigs.

It can hardly choose the way. As the principal architecture remains the same, the algorithms remain the same, people have no need in extending body of knowledge and software thus becomes a self-fulfilling prophecy.

It passes everything at such a great speed, there's no way to ever see what's in it. Who cares, next year pack will be better. Likewise, when you are inside the can, all you can see is wind. Speed, more speed !

Anyhow, the question here is - are people strong enough, knowledgeable enough and not the least - moral enough to deal with Moore's law, to use such a powerful engine ? Are they using it and for what ?

My answer is - Moore's law is a great social amplifier.

It gives you incomprehensible powers. And then it's up to you. Dancing pigs, be it. Just riding the can, good. Sending a billion worth of ads with a single click ? Yes, sadly you can do that. Moreover, as computers control everything, everything becomes a beer can. Attitudes change in all industries, and this is sad, as there are areas which cannot be sped up at that rate (if at all).

But !

You can always take off and observe the way where it's all going. Or may be even forget about the race and do some beer can art (that's what I personally prefer).

On average though, having more power means less thinking and more chaos. Secure about the future ?

March 21, 2006

Do you really need Python ?

I love Python, it's wonderful. But what does in do in fact ? It limits the things you can do in different, previously unseen ways. It shifts your development paradigm big time. It gives you different ways to express your ideas.

But what happens if you stick to Python (or any other language or technology in fact) ? You become dependent on it to get something done. Yes, in this developer-tool symbiosis you do gain a lot, in a short run. But in the long run it ends with useless comparisons like "Ruby is better than Python", or "Java is better than C++", where each party protects its own investments.

I argue that languages and technologies do not matter, it's your development virtue which makes things, not the syntactic constructs or deployment schemes. It's like with math - you have a handful of simple facts and more or less simple rules, and how far you can go only depends on you. There is no reason why you can't build good stuff in Python, C++, Forth or Visual Basic, although the particular schematics will be different for sure.

Therefore, instead of praising Python, why not simply enjoying it while it lasts ?

March 19, 2006

What makes the code unmanageable ?

And so you keep writing good code and everybody else do, and then bah ! you look at (somebody else's) code and do feel that you would never want to touch that. The question is - what exactly makes the code such - horrible, scary, ugly and in general unmaintainable ?

To simplify, let's say we have a team that has set up the formatting, naming and other style rules beforehand. Will it save from ugly code ? No (but it undoubtedly helps). And so we have a group of professionals who have agreed on what a good code is, looking at the bad code they wrote.

If there is something wrong with the code itself (which basically means that all the members agree on its low quality, including the author), then the rules must have not covered everything and legal code is bad.

Now, given the code is not idiotic, it has indentation, theOnlyTrueNames, interfaces and whatnot, what about it turns others away ?

March 18, 2006

Out of all project artifacts, what is the last thing you want to lose ?

Consider this - there are a lot of things subject to configuration management. If there is a disaster and all the artifacts start disappearing one by one - what's the last thing you want to lose ?

Well, source code is one of the players. As this is the ultimate goal of the software project, it's clearly a winner, so let's pick the next runner up.

Source code history, versions repository ? Not unless you do some serious branching.

Backups ? Who needs them if there are originals ?

Architecture ? Documentation ? Can be recovered more or less easily as soon as the team is intact.

Test results, planning, meeting records ? Unlikely...

And so I argue that the next worst thing to lose would be the list of bugs and here is why:

  1. There are hundreds of unrelated items. There is no way anyone could keep any significant part of the list in one's head.
  2. There are no rules by which they can possibly be recovered.
  3. Each item was produced by more or less hard knock, sometimes even from an angry customer. Going through this again would be painful.
  4. Each defect is a ...uhm... defect, something that's not right with the project, something that should bug you until you fix it. And now you know that the thing just became a can of worms and there is no way to fix it.