/* no comments (part II) */

In a previous installment, I discussed the quality of English in comments, arguing that the quality of comments influences the reader’s judgment on the quality of the code as well.

That’s not the only thing that can make code harder or easier to understand. Today (anyway, at the time of writing), I was working on something where arbitrary-looking constants would constantly come up. I mean, constants that you wouldn’t know where they’re from unless there’s a comment. A clear comment. Let’s see some of those.

Programming Challenge: Luminance

A few years ago, I posted on my personal web page a number of programming challenges for my friends. This week, I present one of the old challenges: computing luma from RGB triplets using integer arithmetic only.

Python References vs C and C++

As I’ve mentioned before, my new job will ask me to program more in Python than C++, and that’s some what new for me. Of course, I’ve criticized Python’s dismal performance on two occasions, getting me all kind of comments (from “you can’t compare performance like that!” to “use another language then” passing by “bind to external high-performance libraries”).

But it seems that my mastery of Python is still quite inadequate, and yesterday (at the time of writing, anyway) I discovered how Python’s by-reference parameters work. Unlike C or C++ that use explicit syntax to specify what kind of object we’re dealing with (either by value, pointer, or by reference), Python is a bit sneaky.

Suggested Readings: Programming Pearls

Jon Bentley — Programming Pearls — 2nd Ed, Addison-Wesley, 2000, 240 pp. ISBN 0-201-65788-0

(Buy at Amazon.com)

The central theme of this book is efficiency and economy of solutions of programming problems. However, if the book is globally interesting, it would greatly benefit from an update; the proposed programming style—independently of the gist of the solutions— is old school in many respects. The style should probably updated to take modern programming style into account, say, à la Alexandrescu and Sutter for C++.

INT_MAX is a terrible NaN (Safer Integer Types, Part IV)

I came across a lovely bug lately. Integer arithmetic, especially in C and C++ it seems, is error-prone. In addition to the risk of having the wrong expressions altogether (a logic error, one could say), integer arithmetic is subject to a number of pitfalls, some I have already discussed here, here, and here. This week, I discuss yet another occasion for error using integer arithmetic.

Consider this piece of code, one that you have seen many times probably, at least as a variation on the theme:

RetroComputing

There are plenty of web sites and museums dedicated to the computers of yore. While most of them now seems quaint, and delightfully obsolete, there are probably a lot of lessons we could re-learn and apply today, with our modern computers.

If you followed my blog for some time, you know that I am concerned with efficient computation and representation of just about everything, applied to workstation, servers, and embedded systems. I do think that retro-computing (computing using old computers or the techniques of old computer) has a lot to teach us, and not only from an historical perspective.

Suggested Reading: Find the Bug: A Book of Incorrect Programs

Adam Barr — Find the Bug: A Book of Incorrect Programs — Addison-Wesley, 2010, 306p. ISBN 0-321-22391-8

(Buy at Amazon.com)

This short book (306 p, but a quick read) asks us to debug 50 short programs written in 5 different languages: C, Python, Java, Perl, and x86 assembly. The book offers quite verisimilar code snippets, each of which containing exactly one bug; forfeiting the results. Barr proposes a taxonomy of bugs, from the logical bug to the off by one, and we must debug the programs with him.

Suggested Reading: Optimizing Compilers for Modern Architectures

Randy Allen, Ken Kennedy — Optimizing Compilers for Modern Architectures — Morgan Kaufmann, 2002, 790 pp. ISBN 1-55860-286-0

(Buy at Amazon.com)

The book presents all the high-performance and vectorizing optimizations a compiler should be able to perform on source code while using trade-offs from the underlying architecture (with considerations such as the memory hierarchy and the instruction set) and the semantics of the language.

Scary Code

If you code a lot in a week, you’re bound to make some (possibly) amusing typos. Almost every time, the typo is detected by the compiler and an error is issued, but sometimes you manage to (mis)type valid code! And I recently make one of those typo and I started wondering how far we can push this idea in writing really, really, really, really ugly code.

Source-Level Versioning?

When you develop software, you’re always dealing with dependencies, and, if you’re lucky (or have made a quite enlightened choice of dependencies), you don’t have to worry too much about version numbers. But what if you do?