Review of The Manga Guide to Biochemistry by Masaharu Takemura

Following highly entertaining The Manga Guide to Statistics, I decided to grab another book in the loose series - The Manga Guide to Biochemistry by Masaharu Takemura.

The book is taking its role as a textbook somewhat more seriously, and is packed with higher ratio of information to manga than the Statistics guide. They obviously had a lot to say, and I'd say they covered it fairly well without any obvious mistakes or oversights. A good amount of it feels poorly integrated into the plot, especially bits towards the end which feel almost like a disconnected appendix.

The plot puts a lot of effort on putting all that information in context, but it still manages to setup some manga romance action - pretty lady professor of biotechnology tries to manipulate high school girl and university student boy tutoring her into realizing their feelings for each other. Oops, spoilers.

Overall, I'd say it does its job pretty well, not just as a novelty item, but arguably even as a legitimate textbook.

tl;dr 4/5 stars

Review of A History of Venice: Queen of the Seas

I keep disregarding over 1000 hours of audiobooks and podcasts already in the queue and adding new titles. I'll probably never go to end of the queue, even listening at 180% speed (the rate keeps increasing every few months) and dropping unpromising books easily aggressively.

Of course as soon as I've seen this book about Venice, it jumped right to the front of the queue, and I'm actually a bit surprised that's the first book specifically about Venice I've ever read.

The book covers long history of Venice - its founding myths and facts, its relations with Byzantines and Karlings, trade connections, evolution of its government, its involvement in attempts to remove kebab, asshole popes, ecclesiastic jurisdiction conflicts, claimants, plots, and its ultimate destruction by the Big Blue Blob.

Surprisingly interesting part was one about all the relic theft, trading, and fabrication going on - subjects strangely under-explored in all games. There's so much DLC potential here.

I feel the book devotes far too much space to time after fall of Venice, which feels about as pointless as including a Berlin tourist guide chapters in a book about World War 2. I guess technically it's a book about city of Venice, not just republic of Venice, but the city without the republic is just a dead historical relic, not worth writing about.

The most obvious missing thing is any kind of serious analysis of randomness amplification design of final system doge elections - instead of straightforward system of just choosing 41 members of Great Council to be electors, they had three stages of taking lots to choose electors, electors choosing next group from which electors were chosen by a lot and so on. The book treats it as paranoid historical curiosity, but this is clearly some next level cryptographic protocol, and I'd love to read serious analysis of it.

tl;dr 4/5 If you like Crusader Kings 2, you're likely to like this book. Not sure who else would this book be for.

Review of The Manga Guide To Statistics by Shin Takahashi

It's been a long time since I last did any book reviews on this blog, or for that matter any other reviews. I usually just use Twitter or G+ for this as it's faster.

Here's a book I bought for the lulz - The Manga Guide to Statistics by Shin Takahashi and it turned out to be better than novelty value I expected.

Plot

The book follows a story: dad invites a cute coworker for dinner, who does some statistics at work for marketing reasons or something like that. The high schooler daughter wants to meet him again because he's cute, so she gets the idea in her head to ask her dad to get someone from work to tutor her in statistics (because she's totally interested in what dad is doing at work, honest) - and the dad obliges except getting some completely different dude as tutor. Basically it would be not out of place in any high school manga, but then again the last one I seriously followed was Aa! Megami-sama back when I was in actual high school million years ago, so what do I know.

The story is not breaking any grounds, but it's way more amusing that in any statistics textbook.

Also I'm reasonably sure that's already more plot than Mad Max: Fury Road had, and that was a really good movie.

Educational Value

The level of statistics in the book is fairly introductory, and unfortunately the book has some annoying mistakes, such as:

• completely incorrect explanation of what it means to reject a null hypothesis (also knows as the most common error in statistics textbooks)
• assuming normal distribution for data which is definitely not normally distributed such as normalized school test scores (also extremely common error)

Most concepts like histograms, distributions, correlations, etc. are explained relatively cleanly, but book's attempt at explaining what chi squared distribution is used for and what's the meaning of independence testing feels like a total miss, and I doubt anybody would have more than just a vague idea what the hell they are just read after that.

There's a bunch of math formulas, and I was not impressed by typography - with parentheses not being correct size to match enclosed content. Of course one could make a valid objection that this is a manga not a math textbook, and it was probably not typeset in TeX, which is fair enough I guess.

Am I the only one annoyed by bad typography here?

Of course this leads to obvious followup issue - is it even possible to teach non-Bayesian concepts like null hypothesis testing at this level beyond just "run this calculations, don't worry what they mean"?

Another problem with the book is that it probably focuses too much on the kind of silly content that predates spreadsheet software like formulas and looking up stuff in distribution tables.

Oh the books also has exercises for the reader and appendix on Excel, which are both potentially useful too.

Summary

Overall I'd say the book is probably not the most amazing textbook, but it'd be a pretty sweet novelty gift. Now non-Bayesian statistics is a particularly messy subject to teach, so I guess other books from the series might do better.

tl;dr 4/5 stars

Review of Ruby Under a Microscope: An Illustrated Guide to Ruby Internals

I've been digging my way out of an overwhelming pile of book at pace of about 3 a month - a pace at which I have no chance whatsoever to ever catch up with all the absolutely must read stuff. One book I recently found in my pile was a review copy of Ruby Under a Microscope: An Illustrated Guide to Ruby Internals I got a few months ago, which turned out to be by far the best Ruby book I've ever read.

I'm a little jealous of how easy kids have it these days. I learned Ruby internals back in the 1.6 days - that was the time when most programmers have never even heard of this "Ruby" thing (I'm not kidding you here). To learn anything about Ruby internals you had to dig through macro-heavy and very idiosyncratic C codebase (C/C++ codebases tend to be highly idiosyncratic in general, much more than Java or Ruby or Python codebases), and what little documentation there was was mostly in Japanese. And here someone bothered to write a quality book that explains it all, and well just like that. I've learned a lot about 2.0/2.1, JRuby, and Rubinius from it, even if I was already very familiar with 1.8 series (and had some nonzero level of familiarity with others).

I can see two target audiences for this book. First, advanced Ruby programmers who want to learn Ruby internals - to work on one of the Ruby implementations, or write complex C extensions, or to heavily optimize performance of their Ruby apps.

And second, people who want to write their own programming languages. Ruby implementation is uniquely well-suited for study if you're such a person. It's relatively simple, but implements a highly modern language with all the goodies. Studying something like JVM is basically a waste of time - it's a monstrosity implementing a monstrosity, and half of the features you'll absolutely need in your language you'll have to brutally hack into an unsupportive environment, instead of just cleanly implementing them from first principles. And trying to build your language on top of JVM/LLVM or whatnot, while highly pragmatic, robs you of all the learning experience of writing your own first VM - something I believe any serious CS student should go through at least once.

The book itself assumes you're reasonably familiar with Ruby, but nothing out of ordinary, and as far as C goes it assumes you understand pointers, struct declarations, and basic syntax, and that's about it. That makes it surprisingly approachable considering its subject matter, but I found it really useful even already being familiar with all that (or how it was a few years ago at least). It doesn't bore you with compiler theory, but focuses on actual solutions to actual problems, and invites you to think about how things could possibly be solved. Contrary to what you'd expect, it's meant much more for a cover-to-cover reading than as a reference manual - it's over 300 pages, but it's very heavily illustrated, so it doesn't take that much time.

One big weakness of the book was its chapter about Garbage Collection, which spent far too much time on GC theory and far too little about explaining the interesting bits (like write barriers implementations). I don't think it kept up with standards set up by the rest of the book. And of course many subjects could use some elaboration, but you only get that many pages, and its priorities are relatively sensible.

I'm not sure how complete the book is for someone with no prior exposure to Ruby from the inside - it seems to cover all the basics except maybe C extensions (which would require a lot more C knowledge than the book assumes), but even if something you need to know isn't covered, the hardest part is getting started without being overwhelmed by all the interconnected pieces, and the book will definitely give you that.

If you're in one of two audiences I mentioned, it's practically a must read. I don't think it's terribly useful for people who just hack some Ruby on Rails at work, and aren't terribly interested in going deeper. Sample chapter is available on author's website if you're interested.

tl;dr 5/5 stars

Review of Save the Cat by Blake Snyder

"Save the Cat" is a guide on how to be a successful screenwriter in Hollywood. As you might have guessed, I have no such ambition myself, but it's always interesting to get some basic idea what it's like in different parts of the creative world.

The book is extremely focused on practical matters. It gives you minute-by-minute breakdown of what is supposed to happen in a movie when, exactly what plot devices are necessary in what kinds of movies, how to structure each scene with mandatory emotional change and conflict, how to entwine primary and secondary story, how to write, how to pitch your screenplay and so on.

Normally you'd expect similar books to be really vague and full of banal generalities, with maybe a small sprinkling of practical advice. Save the Cat is nothing remotely like that - it's extremely content-dense and provides a framework that seems to be ridiculously specific. In a way, it reminds me of Getting Things Done - another short book with extremely specific framework, that stands completely apart from the ocean of feel-good vagueness which is productivity books.

Anyway, the book is supposedly all the rage in he Hollywood, and I can totally believe that. The problem with it is that  it looks like a really good guide to making totally mediocre movies.

The author - Blake Snyder - is supposedly a huge screenwriter star, but what is his actual filmography? Here's the complete list:

• Stop! Or My Mom Will Shoot - 3.7 on imdb
• Blank Check - 4.7 on imdb

And that's it! So basically he's a talentless hack as far as screenwriting goes, and all his life's achievements seem to be two godawful movies, and yet somehow making millions selling ton of screenplays (none of them ever getting made into movies), and convincing the entire Hollywood that his way is the one true way to make movies. No wonder I like so few movies these days.

Now the book is really nicely written, and its advice might be extremely helpful to new screenwriters for all I know. At least some of the advice rings true, but then vast majority of examples he gives are from either old mediocre movies everybody already forgot about (and I've never seen) or more recent mediocre movies, some of which I've seen but can recall only vaguely. The only success criteria for the author seem to be box office sales (and both of his awful movies made about $30m each in States). If you put together all sentences about movies which were actually good, that's going to be less than a page, probably.

Anyway, it's a great book for an aspiring scriptwriter, or for an aspiring self-help book writer. For someone who loves movies, it's just too depressing.

Review of Elcenia: Summons by Alicorn

I really enjoy reading fanfiction, and Luminosity - two Twilight fanfic novels by Alicorn were among the best I've ever read, so I was quite enthusiastic to give Elcenia - original fantasy fiction series by Alicorn - a try as well. The main reason I didn't do that much earlier was because it's not finished, and I'd hate to wait or years for updates like it's another Game of Thrones or Order of the Stick.

Unfortunately I've been quite disappointed with it. There's a huge diffecence between writing fanfics within established world and with established characters and writing completely original fiction - even if it's "alterative universe" fanfic the author can start with established reality and characters, and spends all story points on just tweaking them a bit and focusing on the actual storyline. In Summons the author had to establish a completely new universe, a lot of new characters, create a plot, and everything else - and it felt quite flat overall.

I think the universe established in the book has a lot of potential, and it's probably the strongest aspect of the book. Both worlds are much more strongly filled by very powerful magic than a typical fantasy universe, and it includes a lot of magic of practical kinds. There are some unanswered issues here.

First - what role nonmagical people have in their worlds, if Magic can solve just about any problem easily? By comparison Tolkien-style magic is potentially ridiculously powerful but extremely rare and often quite subtle, so it causes few problems; and D&D-style magic is battle-oriented and follows "linear warriors / quadratic wizards" progress, so there are inherently very few powerful wizards, and their core competence is close to useless for solving everyday's problems not involving fighting monsters. Magic in Elcenia's setting is far more practically-oriented - but then doesn't that make pretty much all other human activities worthless? It doesn't even require any major investment of studying time to get a lot of results, that much special magical talent, or any kind of mana (other than sleep and food) - as it turns out you can become a ridiculously overpowered wizard pretty much overnight with a very simple ritual.

And second - if the act of summoning someone from another world is so trivial there, why nobody ever tried that before? Anyway, these issues are no more serious than the kind of nitpicking people can make with just about any fantasy series - and for all I know they might have good explanations somewhere down the way - and I feel that the universe is a strong point here.

A much bigger problem are characters. The book throws such a huge number of them at the reader, most with minimal characterization. The usual solution for that would be to focus on a very small group of characters first, then once the reader is comfortable with them to shift a few people in and a few people out of the focus - the kind of storytelling the first few books of Song of Ice and Fire do (then it sort of fails in books 4 and 5, especially with Meereen fail, but that's a completely unrelated issue).

Pretty much every time a character from a few chapters ago was mentioned I was completely lost who the hell was that - or even what was that character's species, gender, or home world since names are of very little help - it's fine to have completely alien naming system, but why not have some kind of gender endings and very distinct names for dragons etc. to help the reader a little? (there are some attempts at such system, but it maybe affects 10% of characters only).

That's another difference between fanfics and original fiction. In a fanfic you can throw as many characters at the reader as you wish, since most of them are known already (even if in a different version), or if not they at least fit in reader's mental image of the world somehow. If someone was described as "first-year Muggleborn Ravenclaw witch" that already gives you a huge amount of context for what they might be like, and what their relationships with different groups of characters (like teachers, racist Slytherins, etc.) might be. Or if the work takes place in a "realistic" setting, you can can usually take advantage of the tropes, and understand what it means when someone is a donut-loving fat white cop near retirement age. In original fiction in a fantasy world neither of these cluthes work, so you have to be really careful about how you present the characters so they don't overwhelm the reader.

It gets a bit better towards the end, when the rate of characters introduction slows down a bit and most get at least some action to help the reader understand who they are and what they are like.

And then there's plot... (I hopefully avoided major spoilers) That I feel is by far the weakest point of the book. There's something like five inexplicable and mostly unrelated major magical technology breakthroughs during relatively short timespan of the book, there are two romantic subplots, first of them ended out of nowhere, and then the second one started out of nowhere, charaters behave in ways that don't make much sense (going back to the point where there are too many characters but they receive very little characterization so it's impossible to figure out what their personalities are). There's also the "OMG, I must drop everything now and help the sick" subplot, which was way way more hilarious in Harry Potter and the Method of Rationality when Harry was wondering if vegetables might or might not be sentient. There are also some off-screen deaths and other major events happening with no relation to anything.

I wouldn't count any of that "unrealistic", it just feels more like we're watching a National Geographic program about Elcenia, and that's just stuff that happens to take place during filming, not like it's a real story the author wanted to tell.

tl;dr 2/5 stars. Just read Luminosity instead, even if you didn't like Twilight at all. Everybody should read Luminosity.

7 Languages in 7 Weeks

I got Bruce Tate's "Seven Languages in Seven Weeks: A Pragmatic Guide to Learning Programming Languages" book ages ago, but like with all books which require significant active effort it gathered dust on my bookshelf for quite some time. Now that I've read it and did all the recommended exercises I must say it's absolutely awesome!

The book introduces 7 diverse programming languages, and for each of them it skips generic hello world nonsense, and dives directly into what makes each of them special.

Each chapter was a lot of fun even though I had some (or pretty massive) amount of experience with some of the languages in the book.

I put my solutions to the exercises on my github in case you're interested, but I recommend not looking at them until you try to solve them yourself.

1. Ruby

Ruby is the most questionable inclusion in the book, since of the kind of people who read programming books for fun, every one of them already knows Ruby. Fortunately the book mostly focuses on metaprogramming, so it won't be too boring for most people who know some basic Ruby.

Another good thing are all the "compare how solves " exercises scattered throughout the book - small but important things you don't normally notice about languages.

2. Io

This is by far my favourite chapter. Io has absolutely insane programming model vaguely resembling message passing.

In "normal" Smalltalk-style message passing the basic operation is:

send(receiver object, message identifier, list of evaluated arguments passed by value)

Ruby, Javascript and all other proper object-oriented languages all do more or less the same thing with some minor complications.

What Io does is completely reversing this:

send(receiver object, sender's lexical context, message s-expession)

If receiver wants to evaluate arguments in the s-expressions (OK, it's not literally s-expression, it's just the best analogy I could come up with, call them ASTs if you wish) - which it does 99% of the time, it sends them back as new messages to sender's lexical context. And there they're evaluated by lexical context object (which doesn't have particularly much to do with sender object).

For "normal" messages it's syntactic-sugared sufficiently that you don't have to think about it.

fib := method(n,
  if(n <= 2, return 1)
  return(fib(n-1) + fib(n-2))
)

Here, since method(n, body) has multiple arguments, first argument is evaluated (in sender's lexical context) and assigned to n, then body is evaluated.

But how do you implement high-order methods? Why, by subclassing sender's lexical context of course. I'll let the awesomeness of this sink in for a bit.

Here's Matrix foreach method I wrote for one of the exercises (it's not directly anything they're ask for, so it's technically not a spoiler):

Matrix foreach := method(
  args := call message arguments
  xi := args at(0) name
  yi := args at(1) name
  vi := args at(2) name
  msg :=  args at(3)
  ctx := Object clone
  ctx setProto(call sender)
  for(i,1,xsize,
    for(j,1,ysize,
      ctx setSlot(xi, i)
      ctx setSlot(yi, j)
      ctx setSlot(vi, get(i,j))
      msg doInContext(ctx)
    )
  )
)

First, since method( ) has only one argument (function body), there's no automatic evaluation. Instead we parse argument, extracting names for the first three, and msg for the last.

Then we subclass sender's lexical context into ctx, set some variables in it with setSlot message, then send msg (body which was passed to our foreach as 4th argument) to ctx. Why does it work? That's because evaluating anything is sending a message to some lexical context. Our entire function body is one big message consisting of a sequence of smaller messages like yi := args at(1) name and ctx := Object clone.

Unfortunately the book focuses mostly on prototype-based programming part of Io, while Javascript and even Ruby do that much just as well. The brilliant insanity hidden within Io is barely scratched. I recommend playing with it a lot more than the book recommends.

3. Prolog

If the first thing which comes to your mind when someone mentions Prolog is sudoku solvers, you're right! If you've never done any Prolog, it's a fun few evenings to spend.

Sadly in my experience programming in Prolog is about as practical as "programming in SQL" or "programming in XSLT". It's not really a programming language, it only pretends to be one. If someone took good ideas of Prolog and implemented them as an extension for a real programming language, it might be getting somewhere.

4. Scala

It feels like modern version of Ocaml in so many ways. Not only it's statically-typed mostly-functional somewhat-object-oriented language, they've thrown everything including a kitchen sink into the language and added such massive amounts of syntactic sugar for each of its features it all looks really weird and gets you thinking that there's surely some simpler syntax which does most of these things just fine.

Scala seems to have significantly less awful standard library than Ocaml - I'm not really a big fan of Java libraries so many people fawn over so much, but just about anything beats the pile of mess Ocaml standard library is.

Scala's syntax, while it won't be winning many converts, is still the best I've ever seen in an Ocaml-like language. Its feature set also looks like mostly a nice improvement over what Ocaml has.

So I'd recommend giving it a serious look if you're an Ocaml programmer.

5. Erlang

I blogged about my first impressions of Erlang a few years ago, and giving it another go didn't really change that much.

It's the Ocaml Symptom all over again - it was developed in isolation from the mainstream programming world, so its standard library is awful mess, syntax is awkward as hell, and all the small things other languages get right (like having string type, or ^D to exit) it gets totally wrong. In this case it was isolation at Erlang not in the academia, but it's a very similar problem.

Now by throwing some significant effort and abandoning concern for backwards compatibility you could probably turn languages like Erlang and Ocaml into something actually good, but nobody seems to have any intention of doing so.

This shouldn't stop you from playing with it a bit, but using Erlang in production environment? I don't think so.

6. Clojure

Lisp is my favourite language I never actually use. Clojure is trying to do something vaguely similar to RLisp - being a sensible Lisp integrated with an object-oriented environment in existing VM (Ruby's vs JVM). And just like RLisp Clojure also attempts to fix one of the worse aspects of Scheme and such traditional Lisp dialects - far too many completely worthless parentheses.

It makes some very different choices too, and that's part of the beauty of Lisp - you can stretch the concept of Lisp really far, and it's still Lisp in the end.

Anyway, If I accidentally win a few billion drachmas somehow, I'll hire a bunch of people to turn RLisp into a real programming language.

7. Haskell

Haskell is a wonderful programming language - I'm surprised it's not used more in psychology as it'd make for some really great case studies in Stockholm Syndrome.

Here's a stylized history of Haskell design, in which they've been digging themselves deeper and deeper with each decision:

• Traditional static typing doesn't handle high level functions well, so let's add a really sophisticated type system.
• Our new sophisticated type system requires too much typing, so let's add type inference.
• Type inference cannot handle programs with mutable state, so let's remove all mutable state.
• Without mutable state we cannot actually do much, so let's add monads.
• Nobody understand monads, so let's make hundreds of tutorials "explaining" monads in terms of containers, astronauts, dragon liars, and high grade nuclear waste.
• and so on

What's surprising is how many Haskell programmers don't understand that monads are simply a hack to make I/O in Haskell bearable, they seriously think monads are the greatest thing ever which should be ported to programming languages that don't really need them, and everything else Haskell did as a part of general digging itself deeper and deeper is the One True Way to Program.

Disregarding that rant, while monads (and comonads, and arrows, and the rest of such insanity) have no place in any sane language, they are fun to play with for a bit.

Summary

I really recommend this book. It's not meant as a way to learn any particular programming language (and except for Ruby and arguably Scala/Clojure, none of them are remotely suitable for production use), it's a celebration of diversity of programming languages.

Or at least it will give you better arguments for your rants.

Richard Dawkins' The Ancestor's Tale - audiobook review

I don't really read paper books much. Hours of staring at computer and reading blogs and other stuff online are enough effort for my laser-powered eyes. More often than not when I want to read a book, I get an audiobook version of it. Yes, audio has a lot of problems, like lack of searchability, and difficulty of just skimming through less interesting bits. And virtually all audiobook recordings are way too slow. Fortunately my wonderful MP3 player supports increasing audiobook speeds. Side effects include everyone sounding considerably higher-pitched than they really do, but that's something you can really get used to it. By the way - is there any way to avoid that? I know that the most naive algorithm of resampling the original audio wave changes pitch and speed at the same time, and that's what seems to be used, but there surely have to be some smarter ways, right? Especially since I wouldn't really mind even higher speeds.

So, today's audiobook review is Richard Dawkins's The Ancestor's Tale. The audiobook version is unfortunately abridged, what's the dumbest solution to low audiobook speed problem you can think of. MP3 player manufacturers should really do something about it. Or surely there must be some programs out there to speed up audiobooks without making it unreasonably high-pitched right? At least for The Pirate Bay's version, as opposed to DRMed versions.

Humans

Anyway, the book starts with extremely long and boring preface explaining what the book is going to be about. I'm pretty sure many people will just turn it off before the real material starts. Then there are 40 concestor steps - concestor being what's more commonly known as most recent common ancestor of some clade of organisms. Yes, if you want that explained, go ahead and listen to the book preface. Or read some Wikipedia.

Then we move back concestor after concestor, and tell a story of what happened to organisms that split from our branch at that time. The first stories are about Neolithic Revolution, and Behavioral Modernity - two major changes on the way from humans being more sophisticated chimpanzees to humans as we know them. I find the notion of sudden rise of Behavioral Modernity extremely dubious - it disagrees with any molecular evidence, and the only proposed mechanism - acquisition of language - is highly dubious. Our best evidence suggest Neanderthals could most likely speak just as well as us (their FOXP2 gene is identical to ours and anatomy of their speech organs seems to allow speech), what pushes language way back to our common ancestor with Neanderthals, at least 660 thousand years ago. If that was so, it would render all theories of language-behaviour connection completely ridiculous. If Neanderthals couldn't speak, our best estimate for acquisition of language is around 200 thousand years ago, about the time Homo sapiens arose.

In the audiobook Dawkins acknowledges the problem, but postulates that maybe around 50 thousand years ago (supposed time of Behavioral Modernity revolution) language became "more advanced" as opposed to old and primitive kinds of language - this radically disagrees with the data, as modern languages take just one generation of children to reach full complexity and richness, as attested by Nicaraguan Sign Languages and all world's creoles. Yes, I'm going to argue with Dawkins a lot, about things that's not directly related to biology.

In the early chapters Dawkins talks a lot about human culture. An amazingly cool idea is that sheep and alikes "domesticated" grasses. Here's how it supposedly happened - sheep graze on grasses and other plans, what's individual grass plants are not too happy about. But - grasses take grazing reasonably well, while most other plants are far more devastated. As the result sheep give grasses marginal advantage over other plants - sure you're hurt, but the competition is hurt more, and now you have more sunlight, soil, water etc. for yourself. Isn't that great?

Something similar might have happened with domestication, and there's a very interesting domestication story - about tame silver foxes. You know the list of domesticated animals, right? Wolves (aka dogs), boars (aka pigs), aurochs (aka cows) and so on. Foxes are very definitely not on the list - few carnivores are for that matter. So how hard would it be to take a random wild species like a fox, and domesticate it into a pet? It turns out just a couple of decades by selecting for tameness. No genetic engineering or advanced biotechnology necessary. You could run this experiment on your own, given enough money for food and keeping a few hundred animals of whatever kind you want. As a side effect, selection for tameness seems to select for a variety of different characteristics useful for domestication, such foxes behave a lot more like dogs than like wild foxes. It will obviously take longer with species that breed slower than foxes, like most primates. That was your first thought, wasn't it? Domesticated marmosets!

Actually am I reviewing the audiobook or just randomly talking about various subjects vaguely related to it? Oh well, that's my blog, so you know what to expect, and staying on topic it is not! So I want to say I think Jared Diamond's argument that Europeans "had to" win the race because of geographical opportunities makes a lot less sense if you look at the data. The argument goes something like this - there are only 14 species of large domesticated animals. Therefore, there are only 14 species of large domesticable animals, and every animals that wasn't domesticated was obviously impossible to. This is bullshit, as silver foxes prove - just a couple of decades of effort, and you add another animal to the list. OK, it's not a "large" animal, so it doesn't count according to Diamond's criteria, but it proves that domesticated and easily domesticable are nowhere near the same thing.

Oh, and it's not like there weren't any other large animals elsewhere in the world. The Earth was full of them. Not only large land masses like Afroeurasia (silly name, but it makes sense here, as animals can walk from one end of it to another easily, climate issues notwithstanding), but also in Americas, and even on many small islands like Madagascar (elephant bird) and New Zealand (moa). The ones in Eurasia and Africa were just best at not getting extinct, probably by being exposed to Homo for millions of years, as opposed to suddenly.

Dawkins talks about it a lot, not just in the first chapters but all through the books. One amusing idea of his is the "wild Homo sapiens". What does it even mean? We're certainly not wild since the Neolithic Revolution, and arguable we never were. A simple question - do humans form a single species? That's an absurd question, of course they do, after all they can and do interbreed.

But isn't the criterion interbreeding in the wild? Do you know any wild Homo sapiens? Even modern hunter-gatherers are most emphatically not wild, with all the "contamination by civilization", and it's difficult position to claim that Paleolithic humans were really wild. Dawkins gives an example of a pair of grasshopper species that can interbreed perfectly well in zoos, but in the wild they never do so because they use incompatible mating songs. And according to him - how is it different from different groups of humans not interbreeding due to incompatible language and religion? Yes! Dawkins pretty much blames religion for development of human races.

Did I mention how the book doesn't bother with disclaimers, or political correctness, and whenever Dawkins disagrees with someone, he pretty much calls them names - with traditional British eloquence rather than common blogger vulgarity like I do, but it's pretty much the same thing. Oh by the way if you want some solid evidence that religion is a good barrier to human interbreeding, apparently European Ashkenazi Jews rate of interbreeding with surrounding European population, without any geographical or linguistic barriers, purely religious ones, was barely 0.5% per generation - a Jewish person was 200 more likely to mate with another Jew than with a non-Jew. It can be realistically imagined that with addition of some linguistic and geographic isolation barriers between tribes might have been much more significant, leading to a situation where an impartial observer might call different human tribes "distinct species". Of course this situation isn't permanent, and for example intermarriage rate for modern American Jews is 47%, far higher than historical rate even just a couple of decades ago. This makes such barriers temporary at worst, not enough to cause speciation, but plausible partial explanation of the origin of races.

Yes, Dawkins does talk about races. One of his claim about reality of races is how much different observers agree who belongs to which race. Like Colin Powell, who is supposedly "black". By the way, he doesn't look the slightest bit "black" to me - he's a total whitey to me, and Obama is obviously mixed race, not "black". But what do I know, I'm not American. By the way at various stages of history English-speaking people used to believe Irish, or Jews, or Southern Europeans, or Central/Eastern Europeans, or Middle Easterners, or Hispanics, or Indians etc., were "distinct races", even though they're all obviously totally white to me. Oh wait, they still believe Middle Easterners and Hispanics are "distinct races". Silly Americans. There's even plenty of Japanese people who look quite white-ish to me, even though most don't. So I don't really buy the "interobserver agreement" argument.

Dawkins talks a lot about how we shouldn't be giving to much weight to labels like species, and higher clades like phyla. There's plenty of cases like ring species, and gradual divergence of distinct clades where such thinking leads to unnecessary confusion.

Before humans

Wow, I wrote so much and I didn't even get to concestor 1 - of us, Common Chimpanzee, and Bonobo. Numeration starts from concestor 0 - ancestor of all humans. I'm not following the audiobook chapter by chapter - Dawkins talks about human issues a lot, all throughout the book. So first, I don't really buy the idea that there's some relevance of "a common ancestors of all living humans", supposedly living just a few thousand years ago, by statistical argument. Because humans reproduce sexually, we have a gene pool, and it doesn't really matter if there was such an individual or not. Imagine there's an island with 1 man and 10 women. That guy will be the common ancestor of everyone on the island starting from the next generation, but that very much does not mean all the genetic divergence only starts then. Perhaps the women are from 10 different places is the world, isolated for tens of thousands of years - genetic divergence would go hundreds of thousands years back. This is an exaggerated example, but with sufficient mixing of gene pool the time of one of the most recent common ancestors can easily be orders of magnitude than the time of the last genetic divergence.

This is less of a problem for earlier concestors. But there's a second problem. Dawkins claims there are only 40 concestors on our road from humans to concestor of all currently living organism. But that's just limits of our knowledge. It's quite likely that a few more concestors will be inserted around our merger with other Eukaryota, and then with Archaea and Bacteria. Or perhaps not. There are fairly strong limits on our knowledge of evolution that far back.

I think Dawkins commits something I'm going to call the "cladistic fallacy" - the idea that for example humans cannot possible be more closely related to Bonobo than to Common Chimpanzee, just because Bonobo and Common Chimpanzee have a common ancestor not shared by humans. This is technically defensible position, and well calibrated molecular clocks will confirm it - but how many years in the past we shared an ancestor is not a meaningful measure of relatedness!

For one, the same number of years doesn't mean the same number of generations - otherwise you would be equally related to your brother and your nephew, just because your last common ancestor in both cases is the same - that's obviously nonsense. More importantly, different evolutionary lines can diverge at different rates.

One example is Canine transmissible venereal tumor, a single-celled parasite of canines that evolved from dog tumor tissue hundreds or thousand years ago. Yes, it's a different species by all means. But it would be ridiculous to say dogs are more closely related to CTVT than to let's say coyotes. Sure, genetic clock says so, but that's not a meaningful measure of relatedness. CTVT is not a canine mammal is any meaningful sense of the word. Another such parasite is DFTD. There's also an arguable case of HeLa (Helacyton gartleri) - a similar species derived from humans - but in this case we could ignore it as a artificially created. A less drastic example are hippos and whales - yes, technically hippos are "more closely related" (as measured by time) to whales (Cetacea) than to any other Artiodactyla, but is it really the best measure? By the way, it's not really mentioned in the book, but there's an interesting even though most likely false theory that humans are more closely related to orangutans than to Chimpanzees, using similar arguments. Read if you're curious, even if it's unlikely.

Dawkins also panics for a moment about the problem of comparing all species against all others. Hippos and pigs both look like perfectly good Artiodactyla, so if you naively assume that it's a proper clade and try to just take one of these species for genetic comparisons, you might get different family trees. I understand his point, but DNA sequencing is getting ridiculously cheaper at exponential rate (I mean, genuinely not just metaphorically exponential). When the book was released apparently humans and mice were the only two mammals with fully sequenced genomes. Not any more. Right now there are at least 10 fully sequenced mammalian species. And you don't even need full sequences for genetic tree reconstruction, just a selection of a small number of representative genes will give a pretty decent approximation. It's funny how quickly books about biology get outdated.

Most of the audiobook is about different animal groups, and interesting things about them. Like how Deuterostomia (that's you) can be thought of as upside-down Protostomia (like insects). And how to explain Cambrian explosion - is it just an artifact, or was it real? How to explain the paradox of sex - why do you throw away half of your genes when you make children, instead of just cloning yourself and doubling your genetic success? How truly irreducible complexity (which we haven't found at all, so don't worry) would be a good evidence of directed panspermia, as opposed to creationism. About endosymbiosis, fish lungs, Platypus's bill, some theories on origins of life, and a lot more. Half of the stories are excluded from the abridged audiobook, unfortunately, so go on get a paper version if you want to get them all.

That's more or less what the book talks about. It's not the best Dawkins ever (especially the overly long preface annoyed me), but it's pretty decent Dawkins. Highly opinionated (and I don't always agree with his opinions), eloquent, and about something extremely interesting. It's definitely popular science, so hardly any biological background is needed. Enjoy.

Wicked Cool Ruby Scripts are not so wicked cool

I got a review copy of Wicked Cool Ruby Scripts by Steve Pugh. I had my hopes up, as I quite enjoy reading cookbook-style books on programming - they are digestible in small pieces, what works great with my Internet-induced attention deficit, and they are mines of useful tidbits of programming knowledge.

Unfortunately Wicked Cool Ruby Scripts didn't do it for me. The subtitle says "Useful scripts that solve difficult problems", but most of the scripts were targeting trivial toy problems instead, like playing rock, paper, scissors with a computer (why would anybody do that), or reimplementing grep... not terribly useful. I'd say maybe 20% of the scripts do something useful that isn't a one-liner.

Now that on its own wouldn't be enough to give the book a bad review - I might have written a few Library-of-Congress-fuls of Ruby scripts already, so basics are obviously boring to me, but there are more beginners around than people like me, so beginner books are very useful to them. But there's a second problem that bothers me a lot - it's not said anywhere but the book is clearly targeted at Windows system administrators. The scripts instead of following Unix conventions like input from STDIN and arguments, output to STDOUT, errors to STDERR and so on, ask for all the input interactively or load it from predefined files, dump errors on STDOUT, and save output to predefined files.

For example here's a script which prints all IP addresses between a starting and ending one. They way it's implemented in the book is:

class IP
  # Code here is perfectly fine
end

print "Input Starting IP Address"
start_ip = gets.strip

print "Input Ending IP Address: "
end_ip = gets.strip

i = IP.new(start_ip)

ofile = File.open("ips.txt", "w")
ofile.puts i.succ! until i == end_ip
ofile.close

But that's horrible! This script is only useful for anything when manually operated. The entire point of scripts is that they can be building blocks of bigger scripts!

The proper way would be:

class IP
  # ...
end

raise "Usage: #{$0} start_ip end_ip" unless ARGV.size == 2
start_ip, end_ip = *ARGV

i = IP.new(start_ip)
puts i.succ! until i == end_ip

That is - input from command line arguments, output to stdandard out. Unlike script in the book, this can be used as a building block for something bigger.

I'd say the book was a great idea, but a wasted opportunity. I'd only recommend it for beginner Windows administrators, for everybody else it's either too basic, or teaches some seriously bad practice.

Practical Ruby Projects review

A few weeks ago I got a review copy of "Practical Ruby Projects: Ideas for the Eclectic Programmers" by Topher Cyll. The main part of the book consists of eight thematic chapters: MIDI music, SVG animation, pocket change problem, turn-based strategy engine, turn-based strategy GUI in Cocoa, genetic algorithms, implementing Lisp in Ruby (what probably got me the review copy), and parsing with RParsec. But don't worry about that, they are only pretexts for demonstrating various genuine issues that you will stumble upon in your Ruby coding and various interesting techniques. In a way the book reads a lot like a typical programming blog, with all the "I had this strange problem while coding something, and I solved it in this incredibly cool way, I hope it's useful to you too" stuff.

The book is very high on code and pretty low on bullshit and beginner filler (which unfortunately plagues so many books these days), so it won't be wasting your time. I was surprised by how many solutions presented in the book were almost identical to what I've done in my projects, like world map implementation in the book's Cocoa app and my jrpg, which uses Python and PyGame/SDL but is surprisingly similar in structure. The part that was most interesting to me was the last chapter with RParsec tutorial, but the book was overall very enjoyable to read.

If you want me to review any other good books, go ahead and send them ;-)

Mary Sue Fortress

I recently found a copy of "Digital Fortress" by that guy who wrote Da Vinci Code lying around. Now as I was a bit tired with writing thesis, I grabbed it and started reading. And I must say - it's the worst book I've read since high school. Well, the worst first few chapters at least, because I couldn't make myself go any further than that.

Now I'm not going to flame it due to having less clue about cryptography than Internet Explorer team about CSS. Or for having absolutely no clue about languages and trying to sound smart by saying random crap about them (yeah, because Chinese-speaking person cannot tell Japanese text for Chinese). What I am going to fflame it is rampant Mary Sue'ism.

Basically the main two characters are Mary Sue and Wesley Crusher. Basically they are simply the most intelligent, cool, popular, beautiful, flawless and what-not characters ever, just because the author was too lame to use realistic characters. I wonder how did he even got someone to publish his book, as far as I can tell he would be banned on average Xena/Gabrielle alt forum writing such crap.

Ok, now the citation time for the Mary Sue:

The guard admired Mary Sue as she began her walk down the cement causeway. He noticed that her strong hazel eyes seemed distanttoday, but her cheeks had a flushed freshness, and hershoulder-length, auburn hair looked newly blown dry. Trailing herwas the faint scent of Johnson's Baby Powder. His eyes fellthe length of her slender torso -- to her white blouse with thebra barely visible beneath, to her knee-length khaki skirt, andfinally to her legs . . . Mary Sue's legs.
Hard to imagine they support a 170 IQ, he mused tohimself.
He stared after her a long time. Finally he shook his head ass she disappeared in the distance.

And the Wesley Crusher:

Wesley Crusher. The only man Mary Sue'd ever loved. The youngest full professor at Georgetown University and a brilliant foreign-language
specialist, he was practically a celebrity in the world of academia.
Born with an eidetic memory and a love oflanguages, he'd mastered six
Asian dialects as well as Spanish, French, and Italian. His university
lectures on etymology and linguistics were standing-room only, and he
invariably stayedlate to answer a barrage of questions. He spoke with
authority and enthusiasm, apparently oblivious to the adoring gazes of
his star-struck coeds.
Wesley Crusher was dark--a rugged, youthful thirty-five with sharp green eyes
and a wit to match. His strong jaw and taut features reminded Mary of
carved marble. Over six feet tall, Wesley Crusher movedacross a squash court
faster than any of his colleagues couldcomprehend. After soundly
beating his opponent, he would cool off by dousing his head in a
drinking fountain and soaking his tuft ofthick, black hair. Then,
still dripping, he'd treat hisopponent to a fruit shake and a bagel.

But of course it's not like the characters do not have any flaws:

In Mary Sue's eyes, Wesley Crusher was as close to perfect as she could imagine. He only had one unfortunate quality; every time they went out, he insisted on picking up the check. Mary Sue hated seeing himlay down a full day's salary on dinner for two, but Wesley Crusher was immovable. Mary Sue learned not to protest, but it still bothered her. I make more money than I know what to do with, she thought. I should be paying.

I rest my case.

And I'm not going anywhere close to Da Vinci Code or any other stuff by that guy. I'd much rather spend my time with Harry/Draco slash than that.