I filled in the Durham University staff survey yesterday, which got me once again rather miffed about the way that postdoctoral positions work within this university, but also more generally. A good number of the questions were of the "can you do your work within normal working hours?", "do you have enough resources to do your job?", "do you feel stressed by work?" and so on. Answers: no, no, and yes. But while this "dialogue" is all very well in principle, there's nothing that can actually be done about these things: research positions are funded to do research in a particular area and if that's a lot of work for one person, tough. And if you don't manage to do it, also tough: no permanent position for you, matey. So hurrah for the new touchy-feely Durham University, but if they stump up University funds for the needed extra manpower to make my post a full success, I'll eat a hat of anyone's choosing.

Read more…

I've been using Python for maybe 4 or 5 years now. On the whole, the experience has been very positive: big pluses include the excellent (although rather stylistically disjoint) standard library; built-in collection types and list comprehensions; the experience, at least, of finding that duck typing actually "sort of works"; and the clean syntax. However, the "elegant" indentation-based scoping for which it's so famous is, all told, a very bad idea, regardless of what die hard Pythonistas may tell you.

Let's start with a consideration of syntax --- the most visceral feature of a language. Syntax is the most immediate feature of a language, and you know right from the start whether or not you like the feel of it. User interfaces appear secretly everywhere, from the symbols chosen to represent particular quantities in algebra to the syntactic sugar aspects of a programming language. Some experienced coders, especially those who know several languages well, may dismiss syntax-worrying as pointless and superficial, but I'm not so sure: a good syntax makes it not only fast to code up common tasks, but it will also emphasise the structure of an algorithm at a glance and be based on a few consistently applied core concepts. This is a lot more than lily gilding. Strictly, I can do anything in any Turing complete language, so the whole point of a good language is that it makes code for its target tasks readable, elegant and extensible: syntax plays a major role here. Python does well from this point of view: you can see right away that this is a language which doesn't render your own code unreadable when you go for a whole week without reading it. Contrast Lisp or Perl, or PHP: all serious languages suffering from serious syntactic defects (okay, so the most serious is the least heavily used... but that's got a lot to do with it having the worst syntax).

Read more…

It's an oft-recited design principle when building object-oriented software that you should always protect a class' data members by making them private and only accessing them via public "get" and "set" methods. The mechanism by which this is achieved varies according to the language, but the idea is the same: if you access your data via methods rather than directly, then you have a lot more flexibility for refactoring later, without breaking your class interface. A less appreciated fact is, that as for pretty much every simple rule, there are a plethora of quite reasonable exceptions. In this article I'll focus on one such exception --- how maintaining object relationships with the Java Hibernate persistency framework is best done by directly accessing data fields and keeping them private! One characteristic of passing from being a novice programmer to being an experienced developer is learning to make decisions based on the logic behind such 95% rules rather than sticking rigidly to the letter of the law just because. It's a bit like in kung fu films --- the more styles you know, the better you're equipped to deal with difficult situations! The main class of exceptions in this case is where your object is little more than a glorified data container. If you're really sure that the current variables will forever be the relevant ones or, if not, that method wrappers will do little to protect you from refactoring anyway, then there's little point in typing all those extra lines and parentheses.

Read more…

As of version 1.5, or "5" as the marketing people have it, Java has been equipped with covariant method return values. Not a particularly obvious name, is it? What this means is that if a method of class Base returns an instance of class RetBase, then a derived class of Base (let's call it Derived) can implement a method with the same signature which returns a derived class of RetBase, rather than a RetBase itself (let's call it RetDerived).

All very well, but does this solve any problems?

Read more…