Skip to main content

Book Review - The Victorian Internet

I just finished reading The Victorian Internet: The Remarkable Story of the Telegraph and the Nineteenth Century's Online Pioneers by Tom Standage. (I read most of it on my iPhone using the Kindle app.) The book was first published in 1998, and it's a great read about the development and impact of the telegraph. Of course, there are a lot of uncanny similarities between the development of the telegraph and that of the Internet. It's really interesting to imagine what living in a world before the telegraph must have been like: information could only travel as fast as a messenger on a horse, train, or steamship. 

The book is not targeted at a technical audience and I was disappointed that there was not enough said about how messages got relayed through the telegraph network -- what was the routing protocol? There is some discussion of different signaling methods and Morse code, of course, as well as the many variations on Morse's telegraph design (including some really far-out designs that included multiplexing multiple operators over a single wire, essentially using TDMA to avoid conflicts).

There is some interesting discussion on the precursor to the electric telegraph, namely optical telegraphs, which amounted to networks of towers placed on hilltops using visual signals to convey information. These were fairly widespread in Europe in the 18th century and in some places it took a while for the electric telegraph to supplant them.

Some interesting tidbits are strewn throughout the book:
  • A wide range of crazy schemes were devised to compress and encrypt information sent via telegraph, especially for business purposes. This caused problems for telegraph operators who were more prone to introducing errors when keying in unfamiliar strings of letters, and decreased the sending rate as well. At one point the ITU imposed a 15-letter limit on code words and required that they be composed of pronounceable syllables. This led to bogus code words like "APOGUMNOSOMETHA" (I am proud to report that Google offers zero results for this word -- I guess I just Googlewhacked it).
  • There was a 19th century equivalent of the DNS: in Britain, individuals and companies could reserve a special "telegraphic address" that allowed others to send them a message without knowing their real, physical address. These were assigned on a first-come, first-served basis and each telegraph office had a giant book listing all of the addresses that had been registered.
  • It took years for the telegraph to be recognized as anything other than a novelty. Morse and others struggled to convince the governments of US and Britain that they should invest in the development and deployment of the telegraph; early demonstrations did not convince U.S. Senators who (obviously) couldn't read strips of paper printed in Morse code.
  • The original Transatlantic telegraph cable took years to complete, and broke four times while the ships were laying it out. It failed after only a few months of use.
  • A period of fifty years elapsed between the development of the telegraph and the telephone.
Among many others. It's a good read, short and sweet, and makes me want to outfit my DSL router in an oiled wooden box with brass dials and steam valves, like a good steampunk retrofit.






Comments

  1. Ah, but you missed the most important premonition in the book -- of the risks of monopoly carriers, a sort of telegraph neutrality issue. An unholy alliance between Western Union and one of the "wire services" created a news monopoly. After reading the book, I tracked down a contemporary NYT article that tells the story. I posted it here. This relates the testimony before Congress of the gentleman who would provide the financial backing to Alexander Graham Bell, in part at least because he feared for the future of the republic in a world in which a monopoly carrier could control the content of the news. Read it -- this is exactly what we should be worrying about today.

    ReplyDelete
  2. Matt
    I read that book, too, recently. A friend of mine lent it to me, hardbound. I loved it. Great observations!

    ReplyDelete

Post a Comment

Popular posts from this blog

Why I'm leaving Harvard

The word is out that I have decided to resign my tenured faculty job at Harvard to remain at Google. Obviously this will be a big change in my career, and one that I have spent a tremendous amount of time mulling over the last few months.

Rather than let rumors spread about the reasons for my move, I think I should be pretty direct in explaining my thinking here.

I should say first of all that I'm not leaving because of any problems with Harvard. On the contrary, I love Harvard, and will miss it a lot. The computer science faculty are absolutely top-notch, and the students are the best a professor could ever hope to work with. It is a fantastic environment, very supportive, and full of great people. They were crazy enough to give me tenure, and I feel no small pang of guilt for leaving now. I joined Harvard because it offered the opportunity to make a big impact on a great department at an important school, and I have no regrets about my decision to go there eight years ago. But m…

Rewriting a large production system in Go

My team at Google is wrapping up an effort to rewrite a large production system (almost) entirely in Go. I say "almost" because one component of the system -- a library for transcoding between image formats -- works perfectly well in C++, so we decided to leave it as-is. But the rest of the system is 100% Go, not just wrappers to existing modules in C++ or another language. It's been a fun experience and I thought I'd share some lessons learned.

Why rewrite?

The first question we must answer is why we considered a rewrite in the first place. When we started this project, we adopted an existing C++ based system, which had been developed over the course of a couple of years by two of our sister teams at Google. It's a good system and does its job remarkably well. However, it has been used in several different projects with vastly different goals, leading to a nontrivial accretion of cruft. Over time, it became apparent that for us to continue to innovate rapidly wo…

Running a software team at Google

I'm often asked what my job is like at Google since I left academia. I guess going from tenured professor to software engineer sounds like a big step down. Job titles aside, I'm much happier and more productive in my new role than I was in the 8 years at Harvard, though there are actually a lot of similarities between being a professor and running a software team.

I lead a team at Google's Seattle office which is responsible for a range of projects in the mobile web performance area (for more background on my team's work see my earlier blog post on the topic). One of our projects is the recently-announced data compression proxy support in Chrome Mobile. We also work on the PageSpeed suite of technologies, specifically focusing on mobile web optimization, as well as a bunch of other cool stuff that I can't talk about just yet.

My official job title is just "software engineer," which is the most common (and coveted) role at Google. (I say "coveted&quo…