Sunday, April 20th, 2014

The Golem and the Jinni
The Golem and the Jinni by Helene Wecker

My rating: 3 of 5 stars

This book does not lend itself to an effusive review.

It’s fine, really. It has an interesting premise. The occasional-flashback story structure is useful for building to the climax. The characters are more-or-less likable.

It’s fine.

It could be so much more than it is, though. The prose is, at best, workmanlike: it gets the job done but is utterly forgettable, sentence after sentence.

The setting could could have propelled the story to greatness: a look at at pre-20th century New York’s immigrant communities and class system through the eyes of two total outsiders. But it’s not to be. There’s almost no difference between the Jewish characters and the Syrian characters except that one group drinks tea and schannps while the other drinks coffee and araq.

Similarly, the opportunity to have a meditation on the nature of free-will is squandered by just shrugging it away. The nature of western theology is winked at but unexplored.

The book even proposes multiple (possibly conflicting) magic systems without really delving into it.

So, maybe all that’s fine. It’s clearly intended to be a fairy-tale and fairy-tales are free to leave all of that sort of thing behind. But this is a fairy-tale without the wonder. And when you’ve stripped out the complexities and questions and wonders of life, history, and magic — you’re not left with much.

This book is largely competent and it’s a not-unenjoyable way to pass a few hours. But — with cookie-cutter characters, cardboard settings, and a disdain of complexity — it never really rises up to be anything else.

I wouldn’t try to stop anyone from reading it, but nor would I recommend it in our world that’s overflowing with fantasy books.

The Future of the Mind: The Scientific Quest to Understand, Enhance, and Empower the Mind
The Future of the Mind: The Scientific Quest to Understand, Enhance, and Empower the Mind by Michio Kaku

My rating: 1 of 5 stars

I can’t abide futurism. The best science fiction postulates an imaginary future society with imaginary future technologies and explores the present through a fantastical lens. Futurism, on the other hand, postulates that imaginary future because “why not?”.

Futurism is little more than making extravagant predictions while hand-waving away the very real technical issues that stand between the present and that predicted future. In my field of computer programming, we often tell stories of “the sufficiently advanced compiler”: a theoretically-possible program that be able to understand what we mean when we write computer programs and not just what we say and will use that understanding to rewrite programs to be faster and more correct than we could ever manage on our own.

It should be needless to say that this sufficiently advanced compiler does not really exist, even though the only thing standing in its way is sufficiently clever engineering. It turns out that sufficiently clever engineering is really hard.

Similarly, futurism pretends that all of their fantastical technical advances are just a matter of that same kind of sufficiently clever engineering. “This is theoretically possible, therefore we’re guaranteed to figure it out, and I don’t need to worry about the how because it’s just engineering.” is the song of the futurist — and once they’ve established that one or two fantastic technologies are inevitable they can pile advancement on top of advancement on it until you end up with future predictions that are barely distinguished from fairy tales.

It is, or (at least) should be, obvious that this book is a work of futurism. It has the word “future” in the title and everything. But, I’d hoped that Dr. Kaku’s experiences with actual physics would drive him to ground the work in the reasonable if not the possible.

Unfortunately, Dr. Kaku is extremely excitable. Excitability certainly has its place in science. I like my popular scientists to exude a sense of and wonder, but I’m also pleased when they can barely keep themselves from jumping up and down because science is just so cool. Unfortunately, Kaku quickly moves from excitement to breathlessness as moves without pause from wonder to wonder that neuroscience is making possible.

Well, might make possible.

Well, might show is theoretically possible.

One day.

It’s an engineering problem. Let’s assume it’s real and see what happens next.

And so on and so forth.

At one level, it’s exhausting. He never slows down to let you marvel at the mysteries of the brain or the Herculean efforts that researchers are making in order to unlock them. At another level, it’s extremely frustrating as he completely sacrifices the near-term in favor of looking centuries ahead. By focusing solely on the far-future potential (beaming consciousness around the solar system? Really?), he’s giving short-shrift to the work-a-day scientists who are relentlessly plugging away at the enigmas that are in front of them today.

But then again, I suppose: what should I expect from a theoretical physicist?

Dr. Kaku’s prowess as a theoretical physicist may also lead into the second most problematic part of this book (aside from my distaste for futurism in general): “I’m not an expert in this, but…”.

The most glaring example of this is when Kaku admits that he does’t know what he’s talking about but decides to try to define “consciousness” anyway. That’s the entire second chapter of the book, “Consciousness – A Physicist’s Viewpoint”. Instead of being embarrassed about trying to define something that the actual experts in the field have struggled with, he instead builds large portions of the book on top of this scaffolding.

Indeed, he seems quite proud of his definition. He gives it a name, “the space-time theory of consciousness” and refers to it by name again and again. I have my doubts about his theory of consciousness.

I don’t think it’s entirely wrong, but I also don’t think it’s entirely useful. I was also put off by the way he pokes fun at the homunculus argument (which more-or-less posits that there’s a “little person” in the brain driving our bodies) and then almost immediately names an imaginary “CEO” as the consciousness in his definition. I’ve read the entire book and I can’t really tell you the difference between Kaku’s CEO and the discredited homunculus.

If all you’re going to do is reduce the idea down to an ineffable “CEO”, what’s the point? And how can you build so much of your book on this topic?

Finally, Dr. Kaku’s insistence that so many wonderful things (“reverse-engineering the brain”, making full brain copies, beaming our consciousness to the stars on beams of light, controlling robots with our brain as if they were our bodies, etc.) are only a century out (two centuries out at most) seems perfectly analogous to the claims that useful fusion reactors are only fifty years away — claims that have been made continuously for over fifty years.

A scientist’s skepticism should require him to justify these claims with far more than he even attempts.

Ultimately, I found this book extremely unsatisfying. The interesting work being done today would make a fascinating book, but Kaku races past them to instead dive into limp science fiction which offers neither the technical rigor of the best “hard” sci-fi nor the reflection of our own society offered by “soft” sci-fi.

I can only recommend it as a reminder to not read non-fiction books with the word “future” in the title. They rarely go well.

Saturday, March 29th, 2014
Quote: James Mickens - To Wash It All Away [PDF]
Similarly, if a Web page thinks than an object should be initialized, but the object has no initialization method, the browser shouldn’t laugh about it and then proceed under the assumption that the rest of the page is agnostic about whether its objects are composed of folly.
Tuesday, February 25th, 2014

I was recently asked: “What does it mean to be a developer? What are some traits that you think successful developers should have?”.

I certainly don’t have the answers for a question like that. But I do have opinions. I shared them with my friend, but I think it may also be worthwhile to share them with you as well.

Ultimately, “being a developer” comes down to one thing: a developer writes code. This, of course, is a pretty broad definition.

Because it’s so broad, there are a lot of paths to being a developer. Traditionally, you might think of analytic “mathy” people being developers. And that’s certainly true, and it’s where the roots of the industry lie. But creative “artsy” people can also be great developers. And, because the world is not easily broken up into two sets of people, there are all sorts of other kinds of people who can excel at software development.

But different people can approach the field different ways and look for different goals. It takes a hard-core mathematician to work up solid and correct encryption software, but that person may not be the most suited for building something like Facebook’s recent Paper app. Some people will like to work out their software on paper before ever opening a text editor so they know exactly what they’re building. Others like to explore and make mistakes and figure it out as they go.

Because I’m only one person, I can really only talk about what it means for me to be a developer. I’m not a representative sample by any means and your mileage may vary.

And I, without question, fall on the side of building things as I go and learning and exploring. When I was in school, I noticed that there tended to be two sorts of students in lectures (and here I will pretend that the world is, in fact, easily broken up into two sets of people): those who would raise their hand and ask “What about when you do {X}+{Y}+{Z}?” and those who would just type “{X}+{Y}+{Z}” into their laptops to see what would happen.

I was definitely in the latter set. One of the things that I love about computers so much is the way they make it so easy to just try and see. They make it so easy to just try and fail. And when you try and see and try and fail enough times, eventually you learn something. And then it’s on to the next thing. And then the next.

And sure, there’s a ton of advantage to reading and taking classes and what have you. The good part of a CS education isn’t so much that it teaches you to program (which schools do poorly and only because it’s necessary), but because it gives you a good idea for the shape of problems: so when you find a new problem that sort of looks like problem {A} but also looks a little like problem {B} when you squint, you know what to Google for.

I find that programming, at its best, is a creative endeavor: it’s taking a problem and figuring out how to solve it within a set of constraints. And a lot of that can be taking different solutions for similar problems and squishing them together. Sometimes it works, sometimes it doesn’t: but it’s almost always fun.

So when I try to come up with the things that I think make me a good developer (and again, there are so many different kinds of developers that this cannot possibly be representative), the list starts to look like:

  • Experiment. Try things. Fail. Learn. Repeat.
  • Tinker. Try new technologies, languages, techniques. It’s not about developing mastery: it’s about seeing the shape of the industry so when a new problem appears, you have a wide body of experience to be able to say “Hmm. I think if we combine technology {A} with service {B}, it might get us close to a solution.”
  • Read. Read about all the things there are to tinker with. Read about directions and new ideas and exciting people. Read all the things that the best developers are writing about their craft. Sometimes they’ll be right. Sometimes they’ll be wrong. But they’re always full of exciting ideas about the industry’s history, future, practices, failures, and so much more. There’s no substitute for experimentation and tinkering, but there’s just so much to learn and so little time that we have no choice but to follow in the footsteps of giants.
  • Always Be Coding. Developers love programming. It’s in the blood. It’s one of the most fun things you can do. Create things. Throw them away or ship them, it doesn’t matter. Then create some more.

There’s so much about programming, so many areas to focus on. And I don’t have advice about any of that, because all I know to do is to chase all of it. Like a dog chasing a car, you’ll never catch it: but that’s just not the point.

Good luck.

Monday, December 9th, 2013
Link: The Verge: The Desolation of Smaug