Interesting find about another self-styled "Y2k Expert"

greenspun.com : LUSENET : TB2K spinoff uncensored : One Thread

SNIP
By the way, the author seems to think this is his third edition of this book. I think he means that it is derived from an earlier book that was itself derived from a book in C. In my opinion this is still a book in C with a light sprinkling of C++ (he even uses some smart pointers, but he forgets to provide a destructor for class that owns dynamic resources.) In conclusion, there are a few interesting ideas scattered through this book but not enough to repay time spent studying it.

SNIP

Despite quite liking the author's Whose Afraid of C++ I have long harboured a suspicion that he is not a C++ programmer. This book confirms that suspicion despite the C++ in the title.

SNIP
However the most expensive resources in most programming projects are the human ones and the coding style that permeates this book does nothing to optimize use of that resource. In truth I think your time could be put to better advantage than in reading this book.

http://www.accu.org/bookreviews/public/reviews/o/o001796.htm

<a href="http://www.accu.org/bookreviews/public/reviews/o/o001796.htm">LINK</a>

Book Review
--------------------------------------------------------------------------------
Optimizing C++ by Steve Heller
ISBN: 0 13 977430 0 Publisher: Prentice Hall Pages: pp416C Price: £35-99
 
Categories: beginner's c++ optimization
Reviewed by Francis Glassborow in C Vu 11-2 (Jan 1999)
 
Despite quite liking the author's Whose Afraid of C++ I have long harboured a suspicion that he is not a C++ programmer. This book confirms that suspicion despite the C++ in the title.

For example on page 356 the author starts a version of main that covers three and a half pages (and there is a single comment - one of the author's optimisations seems to be to save time by not providing any). The function starts by declaring 26 variables, most are not initialised and 24 of them are for built-in types (or pointers to such). He defines at least another 14 variables during the rest of the program. He makes unnecessary assumptions about the size of an int (if it cannot store 884736 as a value, one of his loops goes into undefined behaviour).
All that is bad but the biggest indicator is that the only C++ specifics in his code are an ifstream instance, an ofstream instance, four uses of new and one use of delete and a scattering of uses of fstream member functions. He isn't even consistent. Sometimes he uses memset() and sometimes he iterates through an array of int setting each to zero. He does this in a loop that iterates 884736 times and he is writing about optimisation. Granted that the gain may be small but why did he do it that way in side a time critical section and used memset() elsewhere. We will never know. Perhaps a good optimising compiler identifiers what is happening and sets memory anyway.

The other problem that I have is the very concept that underlies the book. Too many programmers waste inordinate amounts of time hand optimising. To give the author credit, he does advise you to think before starting to work. If you run your tax program once a year, halving it execution time is unlikely to ever repay the programming effort involved in making the change.

However the most expensive resources in most programming projects are the human ones and the coding style that permeates this book does nothing to optimise use of that resource. In truth I think your time could be put to better advantage than in reading this book.

By the way, the author seems to think this is his third edition of this book. I think he means that it is derived from an earlier book that was itself derived from a book in C. In my opinion this is still a book in C with a light sprinkling of C++ (he even uses some smart pointers, but he forgets to provide a destructor for class that owns dynamic resources.) In conclusion, there are a few interesting ideas scattered through this book but not enough to repay time spent studying it.



-- Mystery Guest (Mystery-Guest@sign-in-please.com), June 21, 2000

Answers

From a review of "Who's afraid of JAVA" by the same author:

" Authors can acknowledge whomever they want to but they should realise that some acknowledgements will have a negative impact on some potential readers. Steve is entitled to his opinion of L Ron Hubbard but he must know that many others do not share it. I find it hard to believe that Hubbard's writings contributed anything to Whos Afraid of Java."

-- kermit (colourmegreen@hotmail.com), June 21, 2000.


L. Ron Hubbard?

That figures.

Y2k Fear Mongering & Science Fiction = Identity

-- cpr (buytexas@swbell.net), June 21, 2000.


Speaking of Science Fiction. How about these two "birds of a feather"?

http://www.garynorth.com/y2k/detail_.cfm/5631


1999-07-31 12:41:51 Long before any Nov. 1999 Statement from the IEE


Subject: 

Steve Heller Asks: When the Engineers Die in the Cities, Who Will Rebuild? Answer: People Who Took Out Books.

 Link:

http://www.kiyoinc.com/WRP127 .HTM

Comment: 

Steve Heller coined the term, "iron triangle" -- electricity, telephones, and either banking or water systems.

Here he outlines what he thinks will happen. It's bad.

He suggests buying CD-ROMs and other books for putting together broken pieces of the economy on a local basis.

For those who have figured out what life in the city will be like next year, but who are bothered by guilt feelings about abandoning neighbors in the city, here is your psychological solution: "I shall return . . . with tools." Call this "Y2K MacArthur."

Basically, this is the scene in Wells' The Time Machine, when the time traveller returns for his books. Or the scene in Lucifer's Hammer, where the scientist puts the books into baggies and buries them in the septic pipe, where the destroyers would not look (my favorite scene in the book).

How Things Work would be on my list.

This week, I have been putting 15,000 books on shelves in a library that looks like a barn. I need more "how to" titles. Heller is correct. This is what the Remnant must do for the future.

Assuage your guilt for leaving. Take something with you of limited value today: books on small-scale production. Bring back something of value after the crash. See his page:

http://www.koyo te.com/users/stheller/y2klib.htm

If Infomagic's scenario turns out to be correct, you need this book for comfort: How the Irish Saved Civilization, the story of Irish missions and literacy in the Dark Ages. (For a brief review, click here.) It will provide your marching orders.

As General Oliver P. Smith (Frank Lovejoy) said -- recreated in the 1952 Korean War movie, Retreat, Hell! -- "We're not retreating. We're just attacking from a different direction."

This is in DC WEATHER REPORT (#127).

* * * * * * * * * * *

I think it is going to be very bad. In fact, the best possible case for which there is any hope is another Great Depression. Why do I say this?

Ironically, my main argument for a terrible outcome is based on one of the primary Pollyanna arguments: "They'll work around it. They always do."

The key here is not "it", which we all agree is shorthand for "whatever problems arise because of Y2K failures". No, the key is who "they" are: the engineers who keep our industrial infrastructure running. Yes , they *do* work around it on a regular basis; in fact, that happens every day.

But what would happen if these engineers were not available? Who would work around these problems then? I think the answer is obvious: no one. And what would happen to our civilization in that case? The answer to that is just as obvious: it would cease to function until and unless it were rebuilt.

The reason I'm so concerned about a long-term outage of the infrastructure is that I don't believe that most of the engineers will survive very long after rollover.

To see why I'm so concerned about this, let's start with what I expect to happen soon after rollover. On January first, there'll be a spike of errors in process control systems that will cause widespread power outages, communication outages, and other immediate effects. However, some power companies will manage to keep the power on in many places, and many people will breathe a sigh of relief.

Unfortunately, this relief will turn out to be premature. Over the next several weeks, breaks in the supply chains to the power companies, primarily fuel supplies, will result in a gradual degradation of the infrastructure. Water treatment plants will run out of supplies, hospitals will stop functioning properly due to lack of drugs and other supplies, and this will be repeated in every industry. The economy will grind to a halt.

But the most serious problem, in the north at least, will be frozen pipes. If the power's off for more than a few days in the middle of winter in Detroit, Chicago, New York City, Philadelphia, Pittsburgh, and other northern tier cities, they'll be devastated by frozen water pipes and sewer line backups. Plague will follow shortly. Most of the inhabitants of the northern cities will die within a matter of a few weeks, from cold, disease, fires started in an attempt to keep warm, or random v iolence.

This is bad enough, of course, to qualify as a disaster ranking with the Black Plague, if not the extinction of the dinosaurs. But wait, there's more: Most of the engineers that could actually rebuild the infrastructure, or work around the problems in the remaining infrastructure, live in the cities. If we lose too many of them, we may end up in the sort of devolutionary spiral postulated by Infomagic.

Obviously, there's nothing you or I can do to get the engineers to move out of the cities to someplace safer; the information about how bad it might be is widely available on the Internet, not least via this newsletter. If they haven't fig ured out yet, it's not likely they will.

However, there may be something that we can do to prevent the devolutionary spiral from going all the way down. We can preserve the information on how to restart our industrial infrastructure from a level of technology that does not require working computers.

Of course, this is a gigantic undertaking, but I think it's possible. Ironically, it is partly the availability of small, cheap, fast computers with large storage capacities that makes this even remotely feasible. In particular, laptop com puters that have CD-ROM players can provide access to a gargantuan amount of information while being rechargeable from a small solar panel.

For example, I have recently purchased the entire run of QST magazine, the official journal of the American Radio Relay League, from 1915 to 1994, on a set of about 35 CD-ROMs. I bought this set not because of an academic or hobbyist inter est in the history of amateur radio, but because it contains thousands of articles on how to put together an amateur radio station without recourse to commercially built transceivers.

Why is this important? Because I think it is entirely possible that we will lose our manufacturing capability for electronic products. By "our manufacturing capability", I specifically mean not only U.S. manufacturing, but foreign manufacturing. Since most amateur radio equipment, for example, comes from Japan, even if the United States somehow miraculously gets through Y2K without serious damage, a Japanese Y2K disaster could still interrupt our supplies of that equipment. In su ch a case, knowing how to build and repair amateur radio equipment is likely to be absolutely vital.

Why do I consider amateur radio so important? Because if the experts on any topic who do manage to survive a Y2K disaster are going to be maximally useful, we will need some way to consult them even if they aren't in our immediate vicinity. If infrastructure-dependent communications and transportation are seriously disrupted for any length of time, as I believe they will be, amateur radio will be the only reliable means of communication over any distances farther than you can walk.

Of course, there are many other areas of knowledge that we will have to preserve. One example is the construction and use of metalworking machinery. There is a series of books called "Build Your Own Metal Working Shop from Scrap" , which begins with a charcoal foundry with which you make your own aluminum castings. This series of books is available from "Lindsay Publications"

(http://lindsaybks.com/HomeP age.html),

which also publishes a lot of old, out of copyright, books on practical subjects from the pre-computer era. According to the Popular Mechanics WWW page on this publisher

(http://homearts.com /pm/diybuzz/04bookb1.htm),

"You've got all the pieces here to jump-start a smaller version of the industrial revolution: first make some charcoal, use it to melt and forge metal, build some precise but simple machine tools, use the tools to build bigger and bet ter machine tools, make products for export and domestic consumption, use the hard currency to upgrade industry and infrastructure, and away you go. Come to think of it, we could use some of this right here in the United States."

So that's the good news. If enough people have this kind of knowledge, no matter how badly our infrastructure falls apart, we'll be able to put it back together again eventually. Of course, we have to survive the collapse first, so make su re that you have your food, water, heat, and other necessities taken care of. But once you've done that, you should do your part in trying to preserve the tools that we can use to start everything up again. And get that amateur radio station set up (http://www.koyote. com/users/stheller/ham.htm) so you can share your knowledge with others!



-- Reality Checker (reality@checker.con), June 21, 2000.

Those who have no accomplishments of their own often believe that by tearing down the accomplishments of others, they will look better. Actually, it makes them look like jealous fools.

By the way, for some reason, CPR forgot to sign his own name to this one. I wonder why? To make it look like there is more than one person attacking me?

-- Steve Heller (steve@steveheller.com), June 21, 2000.


Gets kinda obvious don't it? Must be the C&P stuff.

-- Carlos (riffraff@cybertime.net), June 21, 2000.


Funny but "reality checker" posted what looks like a lot of words from Heller and The Gary.

No comment from Heller on that. No comment on the critique from one of his peers on his C++ "expert" status.

Just another blast at CPR.

BOO HOO What ever will I do?

LOL.

-- cpr (buytexas@swbell.net), June 21, 2000.


Francis Glassborow, is to put it politely, a legend in his own mind. What has he written? No books that I can find on Amazon. He is a self-styled expert on C++, who seems to think for some reason that I am not a C++ programmer. I'm sure my employer would be surprised to hear that, as I have written tens of thousands of lines of C++ production code for our flagship product, which is used in a number of VERY large organizations for high-volume production.

As for my piece in Cory's newsletter, if you read it carefully, you will find the word "if" in a number of places, indicating the POSSIBILITY of something happening. I also use the word EXPECT (not KNOW), which again does not indicate certainty. In any event, it has been posted dozens or possibly hundreds of times by Andy Ray or one of the other "debunkers", so I thought by now everyone has seen it. I was wrong in my expectations, as I have already said. So what? What does any of this have to do with anything?

-- Steve Heller (steve@steveheller.com), June 22, 2000.


This one's gone boring.

-- Carlos (riffraff@cybertime.net), June 22, 2000.

" I have written tens of thousands of lines of C++ production code"

Sounds like a very inefficient programmer to me. Any programmer who prides himself on how many thousands of lines he's written is only trying to impress. The number of lines of code doesn't mean diddly.

-- Buddy (buddydc@go.com), June 22, 2000.


Those tens of thousands of lines include a complete custom virtual memory system, a custom language compiler and interpreter, and a replacement for a infrastructure piece that was originally written by someone else and was several times as large before I rewrote it. I write as few lines as possible to accomplish any goal, but I've had a lot of functionality to provide.

-- Steve Heller (steve@steveheller.com), June 22, 2000.


Heller is fast to do the Heller shift and personally attack another Critic of his book (who praise another Heller book). SO, WHEN IS THE LEGEND IN HIS OWN MIND ACCURATE? WHEN HE IS PRAISING OR QUESTIONING HELLER??


NICE "spin shot" from Heller but......FUNNY BUT I DON"T SEE A "HELLER RETORT" to the following. WHY IS THAT? .........WHY ITS "HELLER SOP".


For example on page 356 the author starts a version of main that covers three and a half pages (and there is a single comment - one of the author's optimisations seems to be to save time by not providing any). The function starts by declaring 26 variables, most are not initialised and 24 of them are for built-in types (or pointers to such). He defines at least another 14 variables during the rest of the program. He makes unnecessary assumptions about the size of an int (if it cannot store 884736 as a value, one of his loops goes into undefined behaviour).
All that is bad but the biggest indicator is that the only C++ specifics in his code are an ifstream instance, an ofstream instance, four uses of new and one use of delete and a scattering of uses of fstream member functions. He isn't even consistent. Sometimes he uses memset() and sometimes he iterates through an array of int setting each to zero. He does this in a loop that iterates 884736 times and he is writing about optimisation. Granted that the gain may be small but why did he do it that way in side a time critical section and used memset() elsewhere. We will never know. Perhaps a good optimising compiler identifiers what is happening and sets memory anyway.




-- cpr (buytexas@swbell.net), June 25, 2000.


Mr. Glassborow is entitled to his opinion of the value of my book, of course. However, I have heard from a lot of readers who found the book very valuable. One of them told me that his company had saved millions of dollars by employing some of the techniques in an earlier edition of the book. As for my style, it is true that the particular program he is referring to isn't particularly object-oriented. However, C++ is a language that lends itself to a number of paradigms, not just object oriented programming, as Bjarne Stroustrup, inventor of the language, has pointed out.

On the other hand, much of the book is devoted to algorithms that are expressed much differently in C++ than they could be in C. I know this because they originally were written in C and had to be completely rewritten to use the object oriented facilities of C++.

Therefore, for him to claim that this is not really a C++ book (or that I'm not really a C++ programmer) is ridiculous, especially since he is aware of my "Who's Afraid of C++?" series, which teaches object-oriented programming from scratch in C++.

-- Steve Heller (Steve@SteveHeller.com), June 25, 2000.


Moderation questions? read the FAQ