Thursday, December 18, 2008
Wednesday, December 10, 2008
Monday, December 08, 2008
Charles Stross: Glasshouse

The first book I read by Charles Stross was Accelerando, which is a wild ride into the future of mankind, and so-called "posthuman", or "post-singularity" humanity. Accelerando is available as a free download under a CC Attribution-NonCommercial-NoDerivs license. Go read it. It's great.
What I loved about Accelerando was that it was so weird. Every few chapters, the timeline jumps ahead a few years, a couple of decades, or even a century or two, and the setting and characters you'd just barely got used to in the preceding pages change so radically it throws you off like you're being flung out of a rollercoaster. You have to work to reconnect to the story.
Which is not to say, it's hard to read. I hate books that are hard to read. This book isn't exactly what I'd call hard, but it does take some effort to read. However, I really enjoyed putting in that effort. I even enjoyed the recurring sense of disorientation —it was intentional, after all—and the ever-increasing weirdness of human life, or what in the later stages of the book is referred to as 'humanity', more or less, I suspect, for lack of a better term.
Glasshouse is much more accessible than Accelerando, because the setting does not change half as quickly. But the lack of rollercoaster-style disortientation is compensated for by a lot more punch. After reading about the first third (the novel is about 400 pages long), it seriously became impossible for me to put the book down. I finally succumbed to fatigue and fell asleep at 2am (on a work day no less).
Glasshouse is set in the far future. Thanks to 'assembler' technology (replicators to you Treckies), combined with mind/consciousness/memory transfer, humans are essentially immortal. Everyone has a backup to revert to in case of fatal accidents, making death a mere inconvenience. However, as you live for a truly long stretch of time, you are bound to accumulate unpleasant memories, up to a point where they become too much to bear. When that happens, people use the assemblers to have their memories partially or fully erased, and start a new life.
Stross addresses the age-old Sci-Fi question of "what is life?", or "what is human?", but not in the way Asimov and others did. Where Asimov speculated whether man-made automata could aquire sentience, Stross takes the concept of sentient artificial life as granted, and focuses on a different aspect of what makes us human, or rather what makes us us. If our thoughts and memories are what makes each of us unique, what if these memories could be manipulated arbitrarily?
Another question arising in that context is whether someone is responsible for actions he committed, before his memory of these actions was erased. And what would be the point of punishing somebody for something he cannot remember doing?
Throughout the novel, which is written in first-person perspective, Stross manages to convincingly tell the tale from the point of view of somebody who has his memory erased, is killed and restored from backup, brainwashed, and has other ugly things happen to his memory. No mean feat, considering what the stream of consciousness of someone like that must be like, but he pulls it off brilliantly.
By setting the bulk of his novel in a wildlife-preserve-like social experiment, intended to recreate the "dark ages"—that is, the late 20th and early 21st century—he manages to bring another message across. By describing our present day from the viewpoint of an 'enlightened' future human, he holds up a mirror to our society.
Rereading that last sentence, it reads just like the usual generic blather you'd read on any book cover. But this book has honestly been different, at least for me. This was the first time I actually went 'Holy shit, we really do live in a damn restrictive society'.
There is one more point I found remarkable, but I don't want to spoil too much. Suffice it to say that this book has opened my eyes to some issues of gender roles, i.e. women staying at home, men going out to work and the associated problems, better than any other author I've read before.
Lastly, while Glasshouse is not what I'd call a 'hard SF' novel (if you want that, try Eric Nylund's 'Signal to Noise'), there's still a lot of technology in there, especially relating to the 'assemblers'. As much as there is, it's all very well thought through, with all implications of the technology considered. The world the novel is set in really gives the impression of being well-rounded, and is very believable.
All in all, a thoroughly enjoyable book, which I can only recommend, very much, to anybody.
Disclaimer: This post had been lying in my drafts folder for almost a year, so the part where I claim I 'recently' finished the novel only applies for very large values of 'recently'.
Thursday, December 04, 2008
Organic Produce
Sometimes it seems to me like my code grows organically.
I start programming, and when I've got whatever I'm working on to work, I notice redundancies in different parts of my code. Then I start to think about how to abstract those parts, like taking one particular sequence of function calls that occurs at several places, and putting that in a function of its own, which I call from all those places. This makes the calling code shorter and more readable, and more often than not improves reusability, because when somebody wants to add functionality in that particular feature, they just have to deal with one function call (which, if using sensible parameters, is going to fit their requirements).
The way I do this seems natural to me—I could also contend that learning from first hand experience is better than excessive planning beforehand. We all know functions that ended up being impossibly tedious to call because they were over-generalized and were designed to cope with every present and future eventuality, most of which failed to materialize, ever. I've seen this most often with design by committee, where everybody has great ideas, but nobody has the sense to say, stop, we've gone too far.
Anyway.
What I can't deny, though, is the fact that those situations seem to arise more often when I don't plan much beforehand, because a) the problem seems trivial, and/or b) I feel I already have a pretty good idea how I'm going to solve it. So this may just be a consequence of my lack of planning, meaning I'd have discovered the redundancy and potential for abstraction during design, had I taken the time to do any.
I'm still not sure what the answer is. It may lie between the two extremes. One lesson to take away for sure is this: Always, always plan ahead. Even if it means just sitting down for half an hour and going over how you intend to solve the problem in your head. Because, and I can confirm that from personal experience, the amount of time it takes you to fix a design mistake during coding is greater my an order of magnitude than the time it would have taken you to fix it in design.
I start programming, and when I've got whatever I'm working on to work, I notice redundancies in different parts of my code. Then I start to think about how to abstract those parts, like taking one particular sequence of function calls that occurs at several places, and putting that in a function of its own, which I call from all those places. This makes the calling code shorter and more readable, and more often than not improves reusability, because when somebody wants to add functionality in that particular feature, they just have to deal with one function call (which, if using sensible parameters, is going to fit their requirements).
The way I do this seems natural to me—I could also contend that learning from first hand experience is better than excessive planning beforehand. We all know functions that ended up being impossibly tedious to call because they were over-generalized and were designed to cope with every present and future eventuality, most of which failed to materialize, ever. I've seen this most often with design by committee, where everybody has great ideas, but nobody has the sense to say, stop, we've gone too far.
Anyway.
What I can't deny, though, is the fact that those situations seem to arise more often when I don't plan much beforehand, because a) the problem seems trivial, and/or b) I feel I already have a pretty good idea how I'm going to solve it. So this may just be a consequence of my lack of planning, meaning I'd have discovered the redundancy and potential for abstraction during design, had I taken the time to do any.
I'm still not sure what the answer is. It may lie between the two extremes. One lesson to take away for sure is this: Always, always plan ahead. Even if it means just sitting down for half an hour and going over how you intend to solve the problem in your head. Because, and I can confirm that from personal experience, the amount of time it takes you to fix a design mistake during coding is greater my an order of magnitude than the time it would have taken you to fix it in design.