Your reply couldn't have been a better demonstration of the author's point. When I noticed the length of your reply, and its tone, I stopped reading it. I have limited time, and I could tell that you weren't considering the audience's limited time (although normally I give major leeway towards comments, which are written on the spur of the moment). There are so many other good things on the Internet that I could read, and there are so many things that I want to write. I just don't have time to put up with reading other people's shit.
What I wrote is fine and not an example of the author's points. You just didn't want to read what I wrote. Okay. My content is not what you want. Okay.
There is another point I omitted (to save space!) that likely is a better explanation of what is really going on: The point goes back to McLuhan's "The medium is the message". So, in particular, the issue is not so much what the author said or what I said but just "the medium".
So, what was "the medium" and its role: The old medium was narrow, if you will, short on 'bandwidth'. So, there were a few huge audiences, and a main goal of ad copy was to reach as large a fraction as possible of one of those huge audiences. Well, that goal was difficult. In rough terms, the technique was to appeal to 'the least common denominator'. And a need was to get the message in a very short ad.
Now with the Internet, the medium has changed. It is no longer the case that the audience does not want to read. Instead the audience does want to read but only relatively narrow content.
The writing lessons he praises are not so much good for writing but at one time were good for some of McLuhan's media.
I was offended by his claim that he had found good lessons for "writing". I've done quite a lot of quite serious writing and much more very serious reading, and for that work his lessons are badly wrong. Here is a current sore spot with me: I'm writing software on Windows and, thus, am using .NET. So far I've collected over 3000 Web pages of documentation on the parts of .NET I am using. Nearly 3000 of those pages are from Microsoft's MSDN Web site of documentation. I've been programming for decades but am new to .NET.
Now for the sore spot about writing: The writing of the .NET documentation has been by a huge margin the worst part of my software project. For me, reading Knuth's TACP was fast and easy, but reading Microsoft's .NET documentation has been a total pain and very inefficient. The main reason for the difficulty is much the same as for the author -- a determination to concentrate on 'writing' styles that refuse to concentrate just on information.
