Category Archives: Programming

Misc Moonpig Provocation

Posted on by

Mark Dominus writes a thought-provoking and entertaining piece on Moonpig. Here are some snippets I found especially interesting and some brief comment:

On ORMs and relational databases:

Right now the principal value of ORM software seems to be if your program is too fast and you need it to be slower; the ORM is really good at that. Since speed was the only benefit the RDB was providing in the first place, you have just attached two large, complex, inflexible systems to your program and gotten nothing in return.

Can’t say I agree, as I find a lot of value in relational databases irrespective of speed (transactions, incredible flexibility of analysis), but still worth mulling over.

On built it yourself versus reuse:

What we should have done, instead of building our own object store, was use someone else’s object store. KiokuDB is frequently mentioned in this context. After I first gave this talk people asked “But why didn’t you use KiokuDB?” or, on hearing what we did do, said “That sounds a lot like KiokuDB”. I had to get Rik to remind me why we didn’t use KiokuDB. We had considered it, and decided to do our own not for technical but for political reasons. The CEO, having made the unpleasant decision to have me and Rik write a new billing system, wanted to see some progress. If she had asked us after the first week what we had accomplished, and we had said “Well, we spent a week figuring out KiokuDB,” her head might have exploded. Instead, we were able to say “We got the object store about three-quarters finished”. In the long run it was probably more expensive to do it ourselves, and the result was certainly not as good. But in the short run it kept the customer happy, and that is the most important thing; I say this entirely in earnest, without either sarcasm or bitterness.

(On the other hand, when I ran this article by Rik, he pointed out that KiokuDB had later become essentially unmaintained, and that had we used it he would have had to become the principal maintainer of a large, complex system which which he did not help design or implement. The Moonpig object store may be technically inferior, but Rik was with it from the beginning and understands it thoroughly.)

Interesting to note there is a genuine trade off with uncertainty in it. If you rely on something external, you may spend longer trying to find the right input to your project and it may be abandoned after you have heavily invested in it. A lot depends on the reusable component.

And finally, on inheritance:

  1. Object-oriented programming is centered around objects, which are encapsulated groups of related data, and around methods, which are opaque functions for operating on particular kinds of objects.
  2. OOP does not mandate any particular theory of inheritance, either single or multiple, class-based or prototype based, etc., and indeed, while all OOP systems have objects and methods that are pretty much the same, each has an inheritance system all its own.
  3. Over the past 30 years of OOP, many theories of inheritance have been tried, and all of them have had serious problems.
  4. If there were no alternative to inheritance, we would have to struggle on with inheritance. However, Roles are a good alternative to inheritance:
    • Every problem solved by inheritance is solved at least as well by Roles.
    • Many problems not solved at all by inheritance are solved by Roles.
    • Many problems introduced by inheritance do not arise when using Roles.
    • Roles introduce some of their own problems, but none of them are as bad as the problems introduced by inheritance.
  5. It’s time to give up on inheritance. It was worth a try; we tried it as hard as we could for thirty years or more. It didn’t work.
  6. I’m going to repeat that: Inheritance doesn’t work. It’s time to give up on it.

I have used inheritance successfully to prevent repeated code but it has only really fitted a few (important) places. Delegation is more flexible than inheritance, but inheritance can be a natural fit for some problems.

Anyway, an interesting read with lots more in it than I’ve commented on (e.g. avoiding floating point rounding errors etc). Read it yourself.

Python tuples are immutable right?

Posted on by

Tuples are immutable, unchangeable right? Well yes – sort of. The issue is easier to illustrate than describe so here goes. If we have a list, we can add new items. E.g.

>>> l = ["apple", "banana", "cucumber"]
>>> l
['apple', 'banana', 'cucumber']
>>> l.append("date")
>>> l
['apple', 'banana', 'cucumber', 'date']

If we have a tuple, we can’t change which objects are contained in the tuple:

>>> t = ("apple", "banana", "cucumber")
>>> t
('apple', 'banana', 'cucumber')
>>> t[3] = "date"

You get TypeError: ‘tuple’ object does not support item assignment

So once you have a tuple, nothing will change, right? It is even called immutable so end of story right? Not quite.

Well try this:

>>> a = ["apple",]
>>> b = ["banana",]
>>> c = ["cucumber",]
>>> t = (a,b,c)
>>> t
(['apple'], ['banana'], ['cucumber'])
>>> b.append("A new banana in my immutable tuple! WAT?!")
>>> t
(['apple'], ['banana', 'A new banana in my immutable tuple! WAT?!'], ['cucumber'])

From the official documentation:

“Objects whose value can change are said to be mutable; objects whose value is unchangeable once they are created are called immutable. (The value of an immutable container object that contains a reference to a mutable object can change when the latter’s value is changed; however the container is still considered immutable, because the collection of objects it contains cannot be changed. So, immutability is not strictly the same as having an unchangeable value, it is more subtle.)” (Data Model) [emphasis added]

Subtle – yes – well said. Which objects are contained in a tuple is fixed – but what those objects are is not. In practice, most tuples are containers of numbers and strings and this potential confusion never arises. Incidentally, even though tuples are immutable, they can’t be used dictionary keys if they contain mutable objects. Try it! E.g.

d = {((1,2), (3,4)): 100}
vs
d = {((1,2), [3,4]): 100}

For more useful explanation of how Python handles variables, objects etc check out: Drastically Improve Your Python: Understanding Python’s Execution Model. It sometimes introduces too many new ideas at once in the example code but is very helpful if you focus on the salient parts of the examples only.

[Added later] See Python tuples: immutable but potentially changing

Eclipse + PyDev problems on Ubuntu 13.10

Posted on by

I wanted the latest eclipse + the latest PyDev. The problem was that PyDev wouldn’t install properly or show up. And no amount of using the Install New Software GUI path helped ;-). The solution was to manually unpack PyDev and put it in the appropriate folder. Should have blogged on this at the time (a week ago) because now I can’t remember all the details. But the following helped: PyDev not showing up in Eclipse

Occurrence Highlighting in Eclipse and PyDev

Posted on by

Eclipse is very useful but configuring it can sometimes be a pain. One change I always make is to change the colour used to highlight occurrences. Occurrence highlighting occurs when you put the cursor in a variable – all occurrences of that variable are highlighted. Unfortunately, the default colour can be hard to see on the side bar so I like to change it from very pale yellow to bright green. To do this: Window > Preferences > General > Editors > Text Editors > Annotations (which is pretty easy to forget). Then change the colour for Occurrences (PyDev). Easy when you know where the configuration is hidden :-).

Interesting programming articles

Posted on by

Here are 4 articles on programming I really liked: