Skip to main content

5 reasons why I don't like e-readers for programming

As a developer, I probably see things a lot differently than your average Kindle or Nook novel reader. I am much more concerned with the information supplied and rely less on the prose and more on the ability to allow a book to be reviewed by my colleagues. Recently, I bought a book (Advanced CORBA Programming in C++) and read it e-cover-to-e-cover on my smartphone. There were lots of positives which can really be summarized by the convenience in being able to pick up the novel anytime in the convenience of my handheld device. That said, here are 5 reasons why I don't think e-readers are ready for prime time for programming books.

  • They don't allow printing - E-reader companies may balk at the idea of trying to support network printer drivers because they feel that people will be likely to print out an entire book and make copies at will. I find this to be unreasonable, because I feel at most a programmer would want to print out a few code examples or beefy definitions at worst, not entire books. E-readers should allow for a limited subset of printer drivers, or perhaps sell licenses for printing APIs to printer companies (i.e. HP, Canon).

  • No copy-paste - These days, most books come with an accompanying website containing all code examples for users to use. However, this shouldn't be a means to an end when it comes to legally reproducing passages of a novel. What if I want to copy and paste a passage for a conference paper, providing the appropriate citation? What if there are only snippets of code that I want to copy and paste and not entire passages? E-readers and e-reader clients on smartphones and tablets don't even offer the option to copy and paste at all because they don't seem to have this concept of a generic clipboard.

  • Lending options are limited - Typically, I like to discuss a particular book with some of my teammates so that we can collaborate and share comments and ideas in a particular coding book. However, in Nook and Kindle these lending options are very limited, and it shouldn't be necessary to have to force my colleagues to buy a separate copy on their own.

  • Code examples are flawed - Translating code examples from print to E-reader is still not perfect. Though I have not seen the process performed with my own eyes, I find that it is not rigorous enough to double check what happens in the aftermath of a translation to digital format. Translations cause certain operators to be interpreted into something else, code examples appear in various font sizes, and the treatment of code examples as text cause weird hyphenation to occur in unexpected places.

  • Ownership headaches - In July 2009, Amazon, without any warning, deleted copies of 1984 and Animal Farm from the Kindles of particular owners within the US due to the invalid rights of the publisher. The victims received refunds for their copy, but they lost any bookmarks and highlights that they made during reading. This begs me to wonder, who really owns these books? What keeps Amazon or B&N from randomly deleting my copy of a book with all the notes and bookmarks? What if one of these companies is out-competed by the other and goes broke; do the books all get erased from memory forever? These are all issues that owners of paper novels never have to encounter.

Of course, one could make several other arguments for not having an e-reader in general. There is the hassle of having to recharge the e-reader, the possibility that the reader will become damaged through some unfortunate event and rendering it unusable, and all the other nuances that come with replacing a paper format with an electronic piece of equipment.

All things considered, I feel that programming-specific issues as described above regarding e-readers will be rectified. The idea of storing my library of programming books right from my tablet or smartphone is too powerful a concept to ignore: during travel and at dead-times I love the idea of being able to crack open a programming book and learn. Sites like Safari already do an excellent job translating their books to digital, but of course these books are limited to O'Reilly books which may or may not be the best books available. I am optimistic of what lies ahead in terms of resources for programmers, but right now that time is not ripe.


Popular posts from this blog

Software Design Principles - SOLID

The SOLID software design principles weren't called SOLID while I was in grad school, but the concepts were there in my Object Oriented Design course. They're worth mentioning here, primarily because I think once you start coding and become dangerous, it's one of the best ways to stay organized once you incorporate it into your daily coding routines, and it even changes your way of thinking for the better:

Matlab and MySQL

I had a lot of data in a MySQL database that I wanted to analyze. I had a copy of Matlab, so I figured the best way to look at this all would be to plot this data and use some GUI elements to go through various combinations. After some Googling, I found this database connector that seemed to do the trick. I downloaded the files, configured mex to use MSVC 2008, built the connector, then I was able to successfully connect over the network! I ran into two problems, though: The connector does not support fetching columns of type TIMESTAMP, and With the magnitude of data (about 180k rows), access times were really slow. I was able to solve problem #1 by changing my columns to DATETIME, which was supported. I'm still trying to figure out problem #2. It may come down to importing all the data directly into Matlab.

The TL;DR guide to git

While in the past I've held a pretty high opinion to using mercurial for version control, the majority of version control these days seems to done in git.  Here were the commands I found most useful to get productive with git right away. # Clone a repository from an origin, i.e. my github MaskingUtils repository git clone # Add a file after it's been updated to stage it for commit, or add a new file git add filename # Commit the file to local repo git commit # Push the file to the origin so the rest of the team can see it git push # List all locally tracked branches git branch git branch --list # Get a list of all branches from the remote git branch -r # Create branch locally git branch develop # Push the branch to the origin repository to make sure it is tracked there git push --set-upstream origin develop # Pulls latest from all local branches tracked from origin; won't pull non-tracked branches git pull --all # Fetch the branch