Re: Malcolm's new book


"Kelsey Bjarnason" <kbjarnason@xxxxxxxxx> wrote in message news:30ldo4-727.ln1@xxxxxxxxxxxxxxxxxxxxxxx
On Fri, 03 Aug 2007 19:16:10 +0000, Richard Heathfield wrote:

Kelsey Bjarnason said:

<snip>

All I can say is I'll take ugly code that works
over pretty code that's broken, any day.

I'll take readable code that doesn't *quite* work over unreadable code
that does work, any day. Readable code can be fixed.

If it's unreadable and works, it still works - you can ignore it. :)

My problem with code such as Malcolm's is more fundamental; if he's made
this egregiously bad decision here, what other egregiously bad decisions
has he made elsewhere, ones which are not necessarily so easy to spot?

Bugs is one thing; we all have those. This, to me, is more like using
void main(); there's absolutely no good reason for it, and a coder who
does it probably has other bad habits - just how much can you actually
trust anything he's written, without an in-depth analysis which, in
theory, you shouldn't have to perform were it professionally done in the
first place?

If the writer says "here I am departing from the offical standard" then either the standard writers are utter fools, or there has to be quite a strong argument that he is making a mistake. I am not wedded to the idea that my choice on size_t is the right one.
However there are some thigns you fail to appreciate. For instnace I suggest using negative sizes to indicate "data fialed to compress". This has the advantage that the algorithm can never inflate data by more than four bytes. There are of course other ways of indicating this, which may be better.

Another thing you fail to appreciate is that compressed data is inherently a binary format, and ought to be a portable binary format. So the size integer has to be stored as a fixed number of bytes, with fixed endianness. So a size_t, with size unknown, isn't an appropriate type. It makes a promise that might not be fulfilled. If you are determined to pass in a size_t nevertheless there are of course ways round this, like storing the number of bits before the size, but that's the sort of detail and complication that is not appropriate for the type of book it is.

However you draw the conclusion that because you disagree with the decision over size_t, there are weaknesses, which you lack the ability to discover, within the rest of the work. That seems to me pure bluster.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

.