Chris X Edwards

If you’re an experienced professional computer nerd you have most likely heard of The Mythical Man Month by Frederick P. Brooks, Jr. or at least some reference to something from it. I certainly had. Then I came across some clever wisdom attributed to it and I thought, that’s clever and wise — I should read that book. I’m glad I did!

It was a bit of a historical tour through the culture of software engineering as it was when my grandfather experienced it. But the reason to read it today is that it is quite apposite now too. Some dated examples show that this book was specifically written about software projects of the mid 1960s. They are astonishingly relevant. Nothing new in software! The book is nice and short at 177 pages — perhaps reflecting an era when computer documentation and code alike were much more economical.

I’m going to just jot down my thoughts about interesting passages, a style not unlike the book itself.

I like how Brooks labels this "the world’s largest undocumented computer".

This is funny because it is so true. I think about professionals like lawyers and even engineers who imagine they’re getting to some kind of objective outcome. From my perspective of trying to sway the judge and jury that is a C compiler, I feel like other professions mostly don’t have a clue how serious this perfection requirement is with programming. It is literally inhuman.

Ug. Yes, this is my most oppressive problem in getting computers to do what I want. Today everyone is a system programmer. People (professionals in the business!) desperately want to understand as little as possible about every part of any kind of computer solution. They cling to a morass of frameworks and wrappers and containers and wizards and magic cloud APIs until it’s just a complete mess. Then if they’re really good they proudly present a "solution" that kind of works in some cases… for another few weeks until one of the nodes in their dependency graph dies.

So true! I’ve definitely been the victim of that one. For example, I love the people who criticize my web site and then when I ask to see theirs it does not exist.

This is one of the key principles that this book established in software engineering. I don’t think it is properly taken into account most of the time. As a side note, that quote could be from a lesson on programming modern GPUs.

How he schedules software tasks [p20]:

He points out that this is a larger budget for planning than is typical. Today I feel that most software has no planning whatsoever. I have to say that his ratios are pretty close to my habits. I may even go a bit higher on planning if "thinking about the problem" is included.

Brooks' Law:

I’ve definitely seen that one up close and personal!

He likes well architected software projects and I pretty much agree.

This is the reason why projects mostly conceived by one clever person are often very compelling. And here is why those clever people can often pull off projects that would seem too ambitious.

p 142

Brooks points out that that limitations can be good for software.

Meaning that when constrained by some budget (money, CPU, memory, etc) people get creative. True!

Funny to see examples of things computer people used to obsess over. Things like sorting which modern computer science classes still belabor were once legitimately interesting. He proudly cites a feature of his project that properly deals with leap year dates, something that is taken for granted down to very minute details now.

In describing the typical cost considerations of a computing project in the 1960s, he sounds an awful lot like he’s describing "the cloud".

Etc.

The earlier remark about systems programmers depending on others is related to this too. Today people think nothing of importing billions of bytes of who-knows-what to create a small thing that I can write in in hundreds of bytes. The reason is that they import some magic library which imports another magic library which imports… turtles. But that’s not the end of it. Each magic library in the infinite chain considers itself the comprehensive source for all things related to that functionality, functionality you may only need .01% of!

Which is very hard to find in the world of computing today. I actually tend to find better instincts with respect to this from electrical engineers than CS graduates.

The book encourages detailed written specifications. Unsurprisingly Brooks, who thought to write a book, is a decent writer.

Talking about managerial vs. technical staff provisions:

Hilarious, right? The professionals who created software in the 1960s and 1970s had actual offices. If you’re in a Silicon Valley tech bro mosh pit and you don’t feel like a chump about that, well, you’re less easily aggrieved than I.

Debugging is a two steps forward, one step back sort of process — if you’re good at it. And it is not just debugging. I recently had a demo which caused all progress to come to a grinding halt. I wanted to add more planned features and improvements, but I dare not introduce the showstopping bug that spoiled showing off what I had already attained.

He describes [p149] a "purple wire" technique for hardware debugging in ancient times. They would replace the normal yellow wires with purple wires to make modifications. Once the modifications were present or after enough time elapsed, they would get replaced with yellow wire. That made it easy to see which wires they had just hastily fiddled with hoping to fix things. He tries to come up with a software version of that but it’s a hard problem.

I have to say, I’m pretty good with this one. Mostly out of laziness combined with a deep pessimism that nothing will ever work right on the first try.

When I was a lad flow charts were still something that many people accepted on faith as a good idea. It was pretty easy to see that great software did not often come along with great flow charting so I kept an open mind. Turns out that flow charts were already dead even way back then.

I guess what he’s saying is that von Neumann (who was clearly amazing) created flow charts because he didn’t have a more developed higher language. Flowcharts probably helped inspire the design of modern computer languages which have served to replace them. (Makes you wonder about UML, doesn’t it?)

That should give you a decent sense of what this book is like. If you’re interested in software engineering and how old ideas are often still good ideas, check it out.

I have been very, very busy recently with my job. Finally that hard work is starting to produce some excellent results! And I can now safely reveal some things about my project here.

This summer I have taken an ordinary speedboat and I have turned it into an autonomous vehicle. I take the boat out pretty much every day and some time ago I wrote enough software to finally relieve myself of the chore of actually driving it. Now I basically let the boat drive me around the waterways of Buffalo while I do experiments, collect data, and test the latest hardware and software improvements.

Recently we invited some local journalists to come and check out the progress. They produced some very gracious reports about the project.

This image was taken by J. Viera from Buffalo Business First.

And comes from an article accurately titled A boat is learning how to drive itself on the Erie Canal. That is very true. The Erie Canal turns out to be an ideal test route for my boat.

And then there is this report on WIVB channel 4.

These reporters did a fine job but of course the story is quite a bit more technically complex from an engineering standpoint. Our business plan prevents me from writing detailed instructions on how exactly this marvel was achieved but it is sufficient to say that it is not trivial. If you’re interested in that kind of thing, chat with me in person about it.

We invited the press to check out our work now because it is pretty much the end of the season for guests who are not also interested in a cold weather adventure. That of course means my season is hardly over. As the autumn descends I’m still going to be out on the water every day. Unlike normal boaters, for me the cold is a welcome relief. It is nice to watch the leaves change from day to day. It is not just spectacular scenery — every time I see new color in the trees I think of how my machine learning training sets just improved!

I am well known to be someone who is interested in the future of transportation but my heretical belief is that infrastructure designed for the transportation of the past may not be appropriate for the future. Shocking, right? Well, to understand that exact topic better, I just finished M.G.Lay’s Ways Of The World: A History Of The World’s Roads And Of The Vehicles That Used Them. This book was organized about as well as a collection of several thousand diverse bits of historical trivia can be. There was some interesting etymology. The history lessons were quite interesting to me. Even relatively recent history — in the lifetimes of people I have personally known — has been completely forgotten. For example, 2000km of electric trams in Los Angeles? Yup. Many of LA County’s neighborhoods (e.g. Beverly Hills) were built by rail companies expanding. Actually, I’m sure it was more like 1200 miles at the time but the author really loves metric units and while that was sometimes strange, as a metric enthusiast myself, I give it a thumbs up.

It’s hard to know where to start with this book. Such a profusion of interesting facts! ("Interesting", assuming you care at all about transportation.) All I can do to give a sense of it is record some of the tidbits I found especially interesting.

Here’s a table which I found very interesting and useful for professional reasons but just glancing at the cropped text below gives a sense of the explosion of facts in this book. Every page is like this!

It’s amazing how slow the first speed limits were. (p194) Let’s just say that I would probably have had a lot of speeding tickets if I could take my bicycle back in time. And yes, I’m considering the conditions of those roads.

The railways were at first major sponsors of roads because it allowed people to get to the stations. I guess this is sort of like Xerox (PARC) originally sponsoring office computing and then finding it eradicating much of their core business.

p139 The Baltimore Ohio Railroad seems to originally have been envisoned as a competitor to the Erie Canal. And even more interesting it was envisioned as being horse powered. During its construction, steam was able to demonstrate superiority. The Erie Canal’s days were numbered.

In 1904 cars replaced horses for transporting US presidents. I find that benchmark very interesting. When will the first US president typically ride in an autonomous vehicle?

The British Red Flag Act (of 1865) is interesting. According to Wikipedia it created "a policy requiring self-propelled vehicles to be led by a pedestrian waving a red flag or carrying a lantern to warn bystanders of the vehicle’s approach." I am not even kidding. This actually boosted Britain’s cycling culture for a while.

Roads have always been military artifacts. Outside of the very famous DARPA challenges I can’t believe the military isn’t more conspicuous with its autonomous vehicle agenda (if it even still has one).

It would be interesting to consider freight mode cost effectiveness factoring in maintenance costs of the required paths.

p98 In the mid 1930s, "Idealistically, autobahn construction was seen as a trial mobilization and as embodying Nazi ideals of national character, sprit, strength, and beauty." On p315 we learn that "The autobahn’s chief advocate was Fritz Todt…"; I found that ironic since the word "todt" in German means "dead".

p102 "Following emancipation, Georgia passed legislation allowing convicts to be used for roadwork, a move that ‘revolutionized highway construction in Georgia’. The use of convicts for roadmaking became fairly widespread throughout the United States."

p124 "In 1664 France introduced a further stage system using lighter two-wheeled carts known as chaisses, or shays. In a system known as post travel, travelers supplied their own chaisses and hired horses from the post houses." Doesn’t that sound just like a futuristic electric vehicle battery swap?

p135 I had not realize how profound streetcars were for intensifying the size of cities. In the late 19th century many cities doubled within a decade when this technology arrived.

p144 "The bicycle was defined as the ‘poor man’s carriage’ and initiated humanity to that new twentieth-century right, the freedom of all citizens to travel when and where they please."

p175 The first road "accidents" involving cars were in 1896 — London and New York each got one. The US one involved a car hitting a cyclist.

p199 The decision to drive on the right or left side of the road turns out to be so complex I can’t even begin to summarize it. That stuff you’ve heard about where it’s easy for knights to high five each other or whatever turns out to be only a small part of the picture. Really, it’s way more complicated than I imagined.

p217 Talking about tar, "Like bitumen, it had some popular uses outside roadmaking. For example, in the eighteenth century tar water rivaled soda water in popularity and the presence of tar was thought to improve the taste of wine."

p224 "Because many roads built for royalty used setts rather than rough cobbles, they came to be known as pave' du roi." This shows that not only is infrastructure change possible, it can actually be brought about by rich toffs. You hear that Sergey Brin?

p225 This was a pretty funny reason that contributed to the development of modern paving systems. "Discontented Irishmen had similarly used setts for missiles in 1864 [rioting]. For such reasons, there was a strong official preference for a more coherent and less throwable pavement surfacing."

p233 An interesting tidbit — a researcher in 1897 claimed that Buffalo, NY had more asphalt paving than any city in the world (followed by Berlin). I very much believe that Buffalo, with it’s Niagara power generation and industry, was the Silicon Valley of exactly a century ago.

p239 "Trucks also made it possible to bring good roadmaking materials over much larger distances than had been feasible with horse and cart, a major benefit. For all these reasons the length of the more expensive asphalt rural roads went from zero in 1914 to 16,000km in 1924." This is an example of how the technology that required the major and expensive infrastructure change also provided means for making that exact upgrade. There is a very important lesson here for autonomous vehicles that companies like Waymo refuse to see.

p283 "Some 502 iron bridges — or a peak of 25 percent of all metal bridges — failed in the United States between 1870 and 1890…" Wow. It’s hard to appreciate how new the bridge technology we take for granted now is. In my lifetime when the Coronado Bridge was opened, the kind of technology for making such massive high spans with welded steel could not have been older than, say, FORTRAN is now.

p295 "[A bridge live loading study] had its precedent in earlier live loading studies, which used three hundred workmen to test panels for London’s Crystal Palace in 1851. Stoney’s experiment involved packing Irish laborers onto a weighbridge." Being used as engineering crash test dummies — no wonder those Irish were fond of rioting!

p307 Wikipedia indicates that one of my favorite philosophers, Bertrand Russell, was the first to note something called the Marchetii constant where people always seem to commute/travel about 1 hour per day and have done so since neolithic times regardless of the means of transportation available to them. This book strongly supported this idea. What is important to also acknowledge is that although we (generally) now still do the same hour that tram riders did 100 years ago, what has changed is that a commute in a car is actual hard work — that is why people get paid to drive trucks etc.! Gone are the better days where you could take a nap or read the newspaper. Since the added convenience seems to be mostly taken up with town expansion I can’t see how the car is any kind of enviable progress over electric trams.

p309 The first motel was in San Luis Obispo. It’s funny to think of southern California as having the oldest of anything but there you go. I’ve even stayed in a motel there and it was pretty nice as far as such things go.

p312 "In many cases the major change effected by road construction was an increase in the number of people traveling by road, rather than improvement in the level of service offered to existing road travelers." In other words, if you love traffic and pollution, build more roads. Works every time. This echoes the excellent book Traffic.

Summary

The cover of O’Reilly’s Effective Modern C++ by Scott Meyers promises "42 specific ways to improve your use of C++11 and C++14". I had a subtly different motivation for reading it: basically general improvement in my knowledge of modern C++.

I actually first learned object oriented programming by teaching myself C++. You would think that since that was in the late 1990s that my decades of C++ experience would be an asset. Turns out, not as much as one would hope. About the time I was doing some heavy duty things with C++ its creators were busy rearranging it. A couple of years ago, I was confronted with some "modern" C++ and I could barely follow along.

In theory, they had made it "easier" of course. In practice, I’m not so sure. (The N4659 C++17 standard is 1622 pages long!) For those of us who know how to use pointers, allocate memory scrupulously, and comfortably micromanage things, messy obfuscatory changes weren’t necessarily comforting. My philosophy is not far from, if you don’t understand what you’re doing, you probably shouldn’t do very much of it. But that is not the new ethos of C++!

Whatever. That’s fine. It can not be contradicted that old C++ was damn inscrutable and harsh. So much so, that I suspect it might be easier to just reimplement what C++ promises in plain old C. Regardless, I do need to be fluent in the modern C++ idioms so when I saw this book, I put it on my wishlist; when I started my new job, a copy was coincidentally lying around in my office! Yea! I figured that maybe I could get comfortable with the modern approach and feel better about the language.

That didn’t exactly happen. I did come to understand the benefits and liabilities of the language features that had been added since I first learned C++ so many years ago. But I didn’t get the feeling that everything is ideal now. Part of the problem is the unsettling tendency that the C++ standards committee will inevitably keep morphing the language making it very hard to get settled for the long term. For example, imagine you had been trying to keep an OS kernel going since 1993 to the present — C++ would have been a disaster.

By reading this book, I was able to fill out my extensive C++ Notes with all the modern bells and whistles. To put it that way is kind of misleading. The modern trappings are far from minor decorative accoutrements, but rather a profound shift in how most practitioners actually write code. I have come to believe that modern C++ programmers have bifurcated into two "classes" (ahem): experts and the non-experts. Putting it simply, the experts write libraries and the non-experts (try to) use them. The experts must know gory hideous details that make old C++ (and very old C) seem simple and charming. The non-experts are doing their best to have no idea how C++ works at all — they just want to get on with their work in some other domain.

Hence new arrivals like auto for assigning types to variables. C++ is, in theory, a strongly typed language. But if auto, in practice, eliminates the need to fastidiously plan data types, then something seems not quite ideal for Team Strong Type. The fact is that auto creates all kinds of horrendous mischief for the aforementioned experts and greatly simplifies things for the non-experts. I know about the mischief because the entire second chapter is dedicated to this topic.

My personal goal was to learn briefly everything involved in what the experts must deal with, but only so that I can make better choices as a more ordinary user of various libraries. For that this book was ideal. I could follow along with about 95% of it but I’ll remember only about 5%. I do, however, believe that my intuition is now much better about modern C++ arcana.

I almost felt sorry for the author — what a terrific intellect wasted on the minutia of this raspy programming language! But I hope he has a good job and is happy with having climbed to the top of this obscure austere intellectual mountain. The book’s organization and writing were very good. What I really appreciated was the author’s humanity. No pretentious bombast here from someone who clearly knows a lot more about a complex topic than any of us little people. The humorous deprecation he unloaded on the language from time to time definitely kept it real and let me know that he understood that someone like me would find a lot of the "simplifications" absurdly complex. If you learned C++ in the stone age like me, this book is good. If you’re one of the hard core folks who writes OpenCV or TensorFlow or something like that, knowing everything in this book probably is mandatory. If you’re simply using OpenCV or TensorFlow, you can probably skip this and muddle through.

Here are some of my favorite bits.

p97 P1 S1: "If there were an award for the most confusing new word in C++11, constexpr would probably win it."

p109: "Yes, yes, ancient history: Mesopotamia, the Shang dynasty, FORTRAN, C++98. But times have changed, and the rules for special member function generation in C++ have changed with them. It is important to be aware of the new rules, because few things are as central to effective C++ programming as knowing when compilers silently insert member functions into your classes."

p149: "But I’ve shown you C++98 code, and that reeks of a bygone millennium. It uses raw pointers and raw new and raw delete and it’s all just so… raw."

p158: "No matter how far you dig into [move and forwarding semantics], it can seem that there’s always more to uncover. Fortunately, there is a limit to their depths. This chapter [5] will take you to the bedrock."

p170: "That’s the kind of behavior that can drive callers [of member functions] to despair — possibly to violence."

p181: "This leads to behavior that’s intuitive only if you’ve spent so much time around compilers and compiler-writers, that you’ve forgotten what it’s like to be human."

p181: "That function will [do a bad thing], your compilers will throw up their hands in exasperation, possibly punishing you with long and incomprehensible error messages as an expression of their displeasure."

p191: "If you’ve never seen anything like this [code] before, count your blessings."

p195: "The resulting error message is likely to be, er, impressive. With one of the compilers I use, it’s more than 160 lines long. … The more times the universal reference is forwarded, the more baffling the error message may be when something goes wrong."

p205: "The motivation for the SSO is extensive evidence that short strings are the norm for many applications." [Good for many applications written by normal programmers?]

p219: "[You may believe] Only loser C++98 programmers use raw pointers and delete. That may be true, but it’s irrelevant because you do, in fact, use raw pointers, and they can, in fact, be deleted out from under you. It’s just that in your modern C++ programming style, there’s often little sign of it in the source code." [Some hints about the degree to which C++ hides the truth.]

p239: "When bind was unofficially added to C++ in 2005, it was a big improvement over its 1998 predecessors. The addition of lambda support to C++11 rendered std::bind all but obsolete, however, and as of C++14, there are just no good use cases for it." [That was an easy one! I missed it completely!]

p248: "Instead, you have to call a timeout-based function — a function such as wait_for. In this case, you don’t really want to wait for anything, you just want to see if the return value is [deferred], so stifle your mild disbelief at the necessary circumlocution and call wait_for with zero timeout…"

p252

[If someone told me this syntax was a joke, that would be easier to believe, but no, it’s real modern C++ — at least for programmers who wouldn’t just use 1e7.]

p263: "The first issue with this approach is what’s sometimes termed a code smell: even if the code works, something doesn’t seem quite right."

p291: "Because you’re a C++ programmer, there’s an above-average chance you’re a performance freak. If you’re not, you’re still probably sympathetic to their point of view. (If you’re not at all interested in performance, shouldn’t you be in the Python room down the hall?)"

Here is a parody image I made for my C++ notes long ago that is supposed to be humorous, a joke.

But now that I look at it, the humor is really too dry — C++ is so ridiculous that this is a very plausible book! (And my notes show an earnest attempt at starting that project.) Modern C++ is a mess. Meyers' book has shown me that my misgivings about it (which are very similar to Linus Torvalds') are not completely unrealistic. I feel that C++ is too muddled and baroque to compete with truly helpful (but generally slower) languages like Python (or even Bash) for simple prototyping or organizational tasks. I feel like it loses to C on performance by definition. For me none of the "features" of C++ make programming "easier" than programming in C. I am thankful that I had the good sense and luck to start my serious programming education by reading K&R cover to cover. To me C++ seems an unnecessary monstrosity. I think this mess is sadly shackled to (and evolving away from) the one fact that completely exonerates C++ as brilliant and sane, and the reason I’ll continue to happily use it with a smile on my face: at least it’s not Java!

I just finished the latest 900 page monster from Neal Stephenson. There may be some slight spoilers in this review, but probably nothing the dust jacket doesn’t say and it might also help make the reading more interesting. This review has turned out much longer than I expected, but if long form reading isn’t your thing, Neal Stephenson is not for you. I am a huge fan and I will always read everything this guy writes, but I have to say, I probably won’t recommend this particular book to people who are not committed fans. The reviews at the world’s largest bookstore, for example, seem rather disappointed. They basically all say stuff like, "Long time fan but, meh."

I wonder if some of the imagery went over people’s heads. For example, there’s a main character named Elmo Shepherd. Funny name right? Well, he turns into the ruler of an afterlife kind of place and they call him "El", you know, the word for god in Hebrew. And "Shepherd"? That lays it on a bit thick as I read it. And there is all kinds of religious and mythological and linguistic symbolism dripping from the pages. But do people care? Do they even get it? Having carefully read Genesis (et al), I understood a lot of it and I didn’t get the feeling that this was a style I really would like to see way more of. A lot of the dialog and prose was styled after religious texts which may not really be the best way to win popularity contests or make easy reading. My typical pace for a Stephenson book is around 250 pages a day but this one was about a quarter of that.

For me, it was worth reading and thought provoking even though I came away pretty sure the premise was faulty. Still, this was a mixed bag and there were some nice gems. As with Seveneves, Neal roughly split the book into a few main sections each with different settings and plot arcs.

I can be a cranky personality to be sure, but Neal’s frustration and rage at the modern American Idiocracy was so itellectually brutal that I can tell that he, like a lot of people, definitely needs a hug. Remember back when I figuratively kick the State of Indiana in their collective testicles for being disgusting hypocrites? (Any Hoosier reading this knows what I mean and that I’m obviously not talking about them and other people who possess sufficient literacy to actually read the Bible.) Ya, well, Neal goes on a similar rampage against his heartland boyhood home (Iowa) that makes my disgust seem quite jolly.

He actually fictionalizes a Libertarian "utopia" which is called Ameristan, exactly as if the Taiban live there. Exactly. It is populated by charactures of absurd Murican batshit insanity that would be ridiculous if it were not for the fact that we’re already half way there.

Throughout this section I couldn’t help but hum to myself this little hilarious song I composed.

(You know the tune — go ahead, "turn it up".)

Now throw in the major symbolism of part three — the God character, El, throws down the diety, Dodge/Egdod, to a place pre-industrial Christian simpletons might imagine Hell to be like. This parallels a famous character of the Bible who is cast down by God from "Heaven". Here Neal attempts full castration of Ameristanis, for Dodge, the main character who is actually the good guy hero, is basically Satan. Alrighty then.

I will say that if there is anything that can make me sympathetic to the Ameristani view that coastal elites are tedious swine, it is reading about rich people. Ug. I’m completely with Teddy Roosevelt who said…

I wish Neal would return to writing about underdogs who prevail despite their lot in life (e.g. Snowcrash, Zodiac, etc.). Writing about a guy lucky enough to make a living in the video game world is not helping me care. The fact that he’s also a billionaire who literally succeeds Yahweh makes me even more apathetic. Is this like one of those deals where Hollywood can’t make interesting movies because of (among other reasons) Chinese pressure? Maybe Neal can’t portray the richest man in the world as a villain because that guy is a personal friend of Neal’s and/or owns the world’s largest bookstore.

Despite the problems, reading this was not at all unenjoyable. My favorite memorable thing is the word "miasma" which Stephenson uses as an oh so perfect drop in replacement for "internet". I’m totally using that from now on. Another one is "din" to describe the flood of email and notifications clamoring for your attention. Another brilliant linguistic insight: the prose subtly asks the reader to consider the semantics of the modern "Submit" button. Chapeau, Neal. Nice.

In some places I felt the futurology was a little off. For example in this passage which I otherwise agreed with and loved, "Pete lowered the phone into the sweet spot of his reading spectacles and wrestled fruitlessly with its UI, which had been terrible twenty years ago." Really? We’re going to use these crap phones for 20 more years? Ya, probably; I guess we’re cursed for a long time. Sigh.

A character refers to a place like a "digital North Korea", I guess referring to the fact that North Korea is poor and poorly lit. But if this is set in the future, that’s making a big assumption about how tenaciously that country will cling to dim backwardness. Again, could happen.

Another character had a house key. Come on now. I have digital locks on my house now. Remember, house keys are utterly obsolete. Now!

The vague futurology with respect to autonomous vehicles is probably deliberate. This on page 518.

And when I read this, I was wondering about the composition of this "used market" — who wanted such obsolete tech? Whatever.

I was, however, encouraged to see (on p572) autonomous watercraft get some love — one character moves to a houseboat on a lake and, "When she was really in a hurry she could do the commute in a robot boat or robot car." Yea! I am making that happen personally!

Speaking of things I do professionally, one of the main characters is hired and given an HR category of "Weird Stuff"; I totally get it because that is exactly the department I must work in.

I was delighted when one of the tech savvy computer nerd characters does (on p457) exactly what I’ve been saying that fictional elite hackers should occasionally do for true realism: she refers to a man page! Man pages will never die!

All that stuff is the warm up. The real meat of the story is the tech nerd dream of uploading one’s brain into a computer and achieving immortality. For the record, I personally am not one of those tech nerds. And one of the main reasons I am not is because I’m just too aware of the problems. For me it’d be no less sensible to want to transmogrify myself into a sentient hovercraft full of eels. Nope don’t want that either, but we can all see that’s probably a foolishly unrealistic goal.

Neal is no dummy and ironically the best criticism of the book’s major premise is found right in the book. I was thinking about this exact problem right up until I read it described quite well on page 336.

Nice pun there at the end, Neal, but hey, what about that? I didn’t notice this major flaw ever really getting resolved. I had to just flip a "fiction override" switch in my brain at that point and carry on with disbelief sufficiently suspended.

Although that quote only hints at philosophical problems, those are definitely troublesome too. For example the afterlife basically consists of starting anew in a brain structured like the one you had while alive, but entirely ignorant of earthly life. If your brain contains memories, why would scanning selectively omit your personal identity? And then, philosophically, what’s the point of that exercise? It is functionally a twin of you, not you. Maybe some intuitions and know-how were preserved, but memories of the old world are strangely absent. If you are not going to persist, really, why bother? You know what else is a lot like you but is not you, yet often persists after your death? Progeny. Much easier.

Ok, fine. If heaven is distinct but inspired by residual ideas and imagery lurking in people’s brains when they die, why are there not more things like special forces commandos or orcs or droids or Lego minifigs or porn stars or television sets or soft drinks or automobiles, etc. Surely that stuff is weighted into people’s neural networks just as much as the Game Of Thrones imagery which seems to dominate the afterlife’s decor. Come on, let’s be real — if the brain scan picked up anything, all inhabitants of the afterlife simulation would be in constant anguish until they could be admiring and fondling a telephone.

An even bigger problem I had is that I never quite understood exactly how this brain simulation morphed into a simulation of a space shared by many brain simulations, a different data structure created initially by the first of the simulated brains. So did the necessarily exacting reproduction of the brain spontaneously start to do double duty as a platform for hosting a very complex virtual world model? Let me tell you, those things are very different! Achieving them by chance (i.e. without explicit programming) seems very unlikely. Waving the magic wand of "quantum computing" seems pretty tepid. Might as well also throw in some string theory to tie that plot together.

One thing that seemed to go completely unexplored (but feel free to chat about it at your next philosophy club meeting — free of charge) was the question of how would people’s attitudes change about the afterlife when they were presented with a plausible system for preserving human brain processes indefinitely? It sure would rob the vague normal religion mumbo jumbo of a lot of its charm. I think it would be very hard to even pretend to care about a deceased relative’s "real" soul off in "real" heaven when you can plainly see their technology-enabled soul doing the stuff they used to do when they were alive (i.e. staring at their telephone).

The final problem I’ll mention is one that seemed a pretty serious plot defect. Even if people lost their clear memories of their personal identities when their brains were scanned and simulated, why would the "real" world maintainers of the system not want to communicate with the dead? We know they can visualize the dead "soul" activities so they must know where some of those qubits are in the computing systems. Just inject some interesting Easter eggs for the citizens of heaven to find. Eventually one character manages to do this but in a really oblique overly complex way. Why not just spell something out on the ground with rocks and see if some of the Heavenites remember how to read?

And then there was the end section which was a grand D&D-style quest with lots of sword fighting and mana magic. Uh huh. I don’t mind that genre, so fine. While I was reading that I kept fondly thinking about a really good book I read that was actually quite similar but way, way better. One of my favorite novels ever in fact. Same high quality writing. Same middle ages knight fight stuff. The most epic questing ever. Cool characters (one unforgettably named "Mountain of Skulls" — how cool is that?). Superb complex intrigue. No dopey deus ex machina Hogwarts magic. And an incredible alternate universe spin on actual fascinating real history. That book was the Mongoliad, written by Neal and his pals. Damn Neal, you’re a tough act to follow! But if anyone can surpass Neal Stephenson, it is Neal Stephenson — I’ll keep giving him a chance to do that for as long as he’s willing to try.