Dreaming in Code

Since I had Jury duty the past few days, I picked up the book Dreaming in Code and read it through. It goes pretty quickly, actually. (Actually, I tried the online access at the jury waiting area to bide the time, but it was kind of shoddy and very unreliable)

The book stirred up a bunch of thinking in my head – not sure how much that’s worth or not, but it definitely got the juices flowing.

Before I started it, I’d heard “It’s a horrible rip on the OSAF”, so I half expected to see some kind of nasty commentary along those lines. The reality is that it’s a long, example laden story that’s is an expansion of Knuth’s quote “Software is hard”. Yeah, I cringed at some of the examples, and the way they were written, I think I was supposed to in some cases. I was one of the avid OSAF watchers early on, and recall the whole time through the repository (or not) development with David/Rys McCusker, and his now-gone “treedragon” wiki/blog thing.

One of the most interesting little sidelines (chapter, really) goes into this sort of scoot-around-it topic that never quite asks the question of “should we have not followed the von neuman/turing programming metaphor all this time?”. In reading through it, I wonder if our (that’s a grand global “our”, for the record – not something specific I’m doing) forays into web services are the initial stabs at learning to code to somewhat different metaphors. Certainly multiprocessors have pushed things a touch, but the real kick has been moving into the world were multi-systems are reasonable and expected – even if each of those individual systems is a more classic “von neuman” style compute setup.

There was also some extended half-chapter about Alan Kay and Smalltalk – hinting that his expectation of “object oriented programming” was something significantly more than we’re seeing today. The quote that made me think this was something along the lines of “I never quite envisioned C++” (thank god! I think), but the verbiage around it actually made me think a little more of that poor-bastard technology of Apple’s OpenDoc. “Data and everything you need for it all together”. Not quite, I know – but maybe something conceptually more than properties and methods.

I’m sure there’s more piled up in my rear-brain, waiting for a good night’s sleep to come pounce and give me ideas. It’s a pretty decent book, and a good read for an in-depth understanding of “why software is hard”. Like anyone else, I’d love to say “Yeah, well I’d have done it differently” – and in some cases I think that’s true – but I would have just run in to other problems too. Maybe as bad, maybe worse, maybe not so bad. Certainly it leaves me thinking that small teams and one-person shops can really do the most in programming, when it comes right down to it. And I think I know a few good examples, too.

Published by heckj

Joe has broad software engineering development and management experience, from startups to large companies. Joe works on projects ranging from mobile to multi-cloud distributed systems, has set up and led engineering teams and processes, as well as managing and running services. Joe also contributes and collaborates with a wide variety of open source projects, and writes online at https://rhonabwy.com/.

<span>%d</span> bloggers like this: