aporem.net

Over a long period I’ve become frustrated about my blogging progress. I’ve confined myself first to two posts per week and then to one. Confined in order not to fall behind with posts and to keep a constant blogging rate. As seen today, it was an utter catastrophe.
I don’t have time, commitment or inspirations to have a fixed schedule. This is a private blog after all. Hence, in productive times I had too many interesting articles piled up to blog about and had problems deciding what should go in. And in times when IT news trickled in slowly, I couldn’t keep up with the self-imposed rate.

Therefore, I decided that from now on, I post at a more flexible schedule, whenever something comes up.

I know the title a little bit tongue in cheek since it appeared on O’Reillynet but this article explains the Model View Controller design pattern far better than the entry in Wikipedia.

Although I don’t think that this assumption holds for non-programmers and hence the Wikipedia article hence suites those particular needs better.

There is a nice example of a well forged jargon word that turned out to mean the exact opposite of its English origin: ‘synchronous’ — it means ‘locking’ in programming, which is ‘asynchronous’ (i.e. executed on different points in time) in spoken English.

But in contrast to the author, I accept that jargon and the spoken language it’s based on can differ to a great extent. They evolve differently and finally can become languages by themselves. The best example I think is Latin and medicine. While the language itself is dead, the jargon lives on.

Perhaps this will also be the fate of IT jargon.

Fun to read: Does Your Programming Language Have Magic Powers?

The post is a response to The Problems of Perl: The Future of Bugzilla and dissects with ease the fallacy in the statement that maintaining projects written in Perl is harder than in any other language (in this case Ruby, PHP or Python): there is no such mechanism that can by itself enforce good coding principles. Educating people improves the maintainability of a project, nothing else!

On the other hand, I see the problems faced by Bugzilla. Their base of contributors adept in Perl is clearly dwindling and thus maintenance is harder. But this does not have to be a bad thing for a full grown project. Since it’s more or less feature complete and serves the needs reliable, why bother and introduce new bugs in working code?

Instead of a rewrite from scratch, it would be easier to refactor the code, write an extensive test-suite and eventually integrate a web framework (perhaps Catalyst?).
After all, are 80,000 lines of code really necessary to achieve all of Bugzilla’s features?

Colin Percival is right. You have to think before you code.

It is especially true in situations where arbitrary measures are applied to quantify the progress made on a project. It is common knowledge of programmers that lines of code do not measure progress. It is equally agreed upon that management usually nevertheless enforces the use of this measure.

So is doing research or working on the software design bad for you as a programmer? — You should know better. The more fun programming is for you, the less significant become such hurdles.