2010 Books In Review

Posted by Brian Mon, 10 Jan 2011 02:04:00 GMT

Well, my goal this year was to cut back my reading and I somewhat succeeded. I only read 44 books in 2010, but I saved a lot of time by not writing reviews for most of them. Here’s the list for the year, with links to the ones I have written a review for at this time.

  1. Open Sources 2.0 Edited By Chris DiBona, Danese Cooper, and Mark Stone
  2. The Mythical Man-Month By Frederick Brooks
  3. The Innovator’s Dilemma By Clayton Christensen
  4. Predictably Irrational By Dan Ariely
  5. The Cluetrain Manifesto By Rick Levine, Christopher Locke, Doc Searls, and David Weinberger
  6. The Greatest Benefit to Mankind: A Medical History of Humanity By Roy Porter
  7. Ender’s Game By Orson Scott Card
  8. Guns, Germs, and Steel: The Fates of Human Societies By Jared Diamond
  9. The Future of Ideas: The Fate of the Commons in a Connected World by Lawrence Lessig
  10. The Stand By Stephen King
  11. Biobazaar: The Open Source Revolution and Biotechnology By Janet Hope
  12. The Drawing of the Three: The Dark Tower #2 By Stephen King
  13. The New Complete Joy of Homebrewing By Charile Papazian
  14. The Complete Stories: Volume 1 By Isaac Asimov
  15. Neuromancer By William Gibson
  16. Count Zero By William Gibson
  17. Mona Lisa Overdrive By William Gibson
  18. In Defense of Food: An Eater’s Manifesto By Michael Pollan
  19. The Waste Lands: The Dark Tower #3 By Stephen King
  20. The Dilbert Principle By Scott Adams
  21. Wizard and Glass By Stephen King
  22. Wolves of the Calla By Stephen King
  23. The Song of Susannah By Stephen King
  24. ‘Salem’s Lot By Stephen King
  25. The Dark Tower By Stephen King
  26. The Red Thread of Passion By David Guy
  27. The Cathedral & the Bazaar By Eric Raymond
  28. NurtureShock By Po Bronson and Ashley Merryman
  29. Capitalism, Socialism, and Democracy By Joseph Schumpeter
  30. Sex at Dawn By Christopher Ryan and Cacilda Jetha
  31. Innovation Happens Elsewhere (Did not finish)
  32. Effective C# By Bill Wagner
  33. More Effective C# By Bill Wagner
  34. Programming in Scala By Martin Odersky
  35. Foundation By Isaac Asimov
  36. Foundation and Empire By Isaac Asimov
  37. Second Foundation By Isaac Asimov
  38. Dr. Kinsey and the Institute for Sex Resarch By Wardell Pomeroy
  39. Pain: The Fifth Vital Sign By Marni Jackson
  40. Programming Perl, 3rd Edition By Larry Wall, Tom Christiansen, & Jon Orwant
  41. Joel on Software By Joel Spolsky
  42. Listening To Prozac By Peter D. Kramer
  43. Songs of Distant Earth By Arthur C. Clarke
  44. Speaker for the Dead By Orson Scott Card

Posted in  | Tags  | 1 comment

From C# To Perl: Readability

Posted by Brian Sat, 08 Jan 2011 23:22:00 GMT

Let’s talk about readability. It’s a fact that code is read far more often than written. Listening to the Perl community, you would think that it is the most readable computer language ever devised. Larry Wall loves to talk about linguistics and applied some of his knowledge on the subject when creating Perl. The result was… interesting.

Waste No Keys

How many keys does your keyboard have? Want to use a language that seems to go out of it’s way to find a use for every one of them? Perl favors terseness over readability to almost a pathological point. This is exemplified in its use of magic variables. You can find a full list of them here. Now imagine reading a code base that uses any significant fraction of them. To be fair many of them are almost never used. Even seasoned Perl hackers would have to look them up. Also, you can see in the documentation that they also have readable aliases. If you are using any of the obscure ones you should probably use the alias instead.

On a related note Perl seems to have inherited from C the almost pathological need to abbreviate. C system code tends to abbreviate variable names to the point of confusion if you aren’t familiar with the codebase. Perl programmers seem to carry this over into non-system code. I’m a big believer in Domain Driven Design, which states as one of its tenets that you should speak the same language as your users. This should carry over into your code. Once again, when I come back to a codebase six months from now I don’t want to have to think about what that abbreviation was for. Sometimes you can save too many keystrokes.

Ambiguity

Perl gurus often seem to highlight the fact that their language is closer to natural language than most. They consider this to be A Good Thing. I don’t. Natural language is messy, ambiguous, and full of nuance. I want my code to be as clean, clear, and straightforward as possible. If this comes at the expense of succinctness, so be it. I’m writing this code once. Others (and me) will be reading it many times. This is one reason any scientific field of study comes with its own jargon. The goal is to eliminate as much of the ambiguity as possible by distancing itself from natural language.

In contrast, the foundation of C#’s syntax comes from the C/C++/Java model. I don’t find anything inherently superior to this syntax (it is pretty dominant though), but one thing it does not suffer from is ambiguity.

TMTOWTDI

This is where I feel readability suffers the most. Perl’s motto of There’s More Than One Way To Do It encourages significant fragmentation of what are built-in concepts in other languages. For example, there are countless different modules to write object-oriented code. Perl5 has a half-assed OO implementation, leaving it up to module writers to provide most of it. This means that you can have considerable Perl experience but stumble upon a code base that looks like nothing you have seen before. A Perl developer using Moose might as well be writing a different a language.

However, this could be an advantage if you wish to define any sort of DSL, something that is difficult at best to do in C#. Most C# programmers who wish to define a DSL are best served to learn Boo), another language that runs on the .NET framework that is much better suited to the purpose. A true DSL is also difficult in Perl though. The closest I have seen so far is something like Moose, which looks like a DSL in parts. To contrast with another language, before learning Perl I was working with Scala, which through the use of some advanced features allows you to easily define a DSL. To a user it simply looks like you defined new keywords.


To a large extent readability comes down to what you are used to so of course C# is more readable to me right now than Perl. However, some of these issues have nothing to do with my lack of Perl experience (such as pathological abbreviating). Some of the Perl community recognizes these problems. There seems to a sharp divide between traditional Perl users and a group that prefers to use what it calls Modern Perl. Put me in the modern camp.

Posted in  | Tags ,  | 6 comments