Ziplock bags considered harmful?


Thanks to the wonderful DVD produced by the curator here (thanks much, David), I was taking a happy trip down memory lane tonight reading all the nerdy calculator stuff I had "in the flesh" in my younger days.

Then I happened upon a small note in the Feb 78 version of HP Key Notes wherein HP recommended against using "plastic film" (a.k.a. Saran Wrap) to cover calculator keyboards in dusty environments. Something about the new types of plastics reacting with the plastics in the keyboard.

While they suggested to use one of the "seam lock" bags (a.k.a. Ziplocks), they made sure to mention that the calculator should be removed from the bag once you left the dusty environment.

So, what's the experience here? I have a couple of Voyagers sitting in Ziplocks here. Am I asking for trouble?


Ziplocks are made of polyethylene and it’s pretty inert stuff. Back in the day (1978), there were all sorts of weird stretch films. A lot of these products used PVC as the base for the film and the plasticizers used in these products could and would leech out and attack the styrenic materials used in the calculator. They reacted rather badly to heat as well, accelerating the migration.

Most stretch films today are based on LLDPE (linear low density polyethylene), but there still some PVC and PVDC (Saran) films out there, so it is still good advice to stay away from wrapping your calculator in stretch wrap.

Don’t leave calculators for extended periods in sealed bags when they are exposed to fluctuating temperatures. Desiccant packs are a good idea to prevent condensation in those situations.

The fastest way I know of to kill a calculator is this formula:

Water + Batteries = Calculator Death

Electrolysis has claimed many a Voyager and Pioneer with their tight pc traces and ESD shielding. Of course, being run over by cars doesn’t help either. Ask me how I know...


"Run over by cars" makes a fun test for robustness of solder mask on a pcb, though!


"Ziplock bags considered harmful?"?

Patrick, you forgot the "with apologies to Edsger Dijkstra." :-;




I was wondering if I was being too subtle. Obviously not for this crowd!


Edsger Dijkstra? I missed the reference.... I looked up this famous professor, but missed any reference to the Ziplock....



if dr. mike didn't get either then i guess i'm in good company.

about bags: i've kept my 41 in various types of sandwich bags for years and have had no ill efects from it. dust, on the other hand is pretty serious in an irreplaceable keyboard. that dessicant idea sounds good - and if it is usless it is at least harmless. i am going to do it next time i re-bag.



Dijkstra was considered to be "the" philosopher of computer science. He suggested many of the great ideas that ended up being the mainstay of the profession, usually in very short but extremely insightful papers. One of them (in 1968) was titled "Go To Statement Considered Harmful" and was the impetus for structured programming to take hold. Of course it took HP a while longer to get there (until the 28C) with its handheld calculators.



In 1987, while I was taking a course in programming languages, some of us students decided to see if we could get Dykstra to autograph a copy of the letter ("GoTo Statements Considered Harmful" was actually a letter to the editor) to give to our instructor at the end of the semester. I made a nice enlarged photocopy of the letter, and sent it to Dykstra at the University of Texas requesting that he autograph it for our instructor, who was a big fan of structured programming. About two weeks later, the copy was returned, with the name "EDSGER DIJKSTRA" neatly printed at the top in block letters. To this day I don't know if that was his actual signature, or if he printed his name so as to not have an actual signature, or if he just had a secretary do it.

If anyone would like the exact reference, drop me an e-note. I have the letter in my files at work.



Thanks, Katie! A very important individual whose name I'd not heard (that I remember... I don't even know exactly how to pronounce it!).

No wonder he kept things so "short and simple".... it probably started in grade school when the teachers couldn't spell his name....

Amazing, though, what he contributed: lots of terms (STACK), etc.; structured programming (getting rid of GO TO), etc. I guess his many papers are even available on the net!



The manuscripts of Edsger W. Dijkstra can be found at <a href=></a>


Amazing what great conversation a tiny note in a small, quarter century old HP calculator magazine will generate...

I'm not positive of this, but I believe someone quite recently (last 5 years?) has published an article in the computer science journals with a title along the lines of "Case Statement Considered Harmful". Of course, they were paying homage to Dr. Dijkstra in titling their article this way, but also clearly trying to piggyback on the notoriety of the "Go To" article/letter to the editor.

The gist of this new article was that the typical case statement (or "switch" in C/C++) is anathema to modern object oriented ideas. When a new "type" is introduced into a program, each and every legacy case/switch statement that pertains to switching on types needs to be revisited and a new case appended. In contrast, uses of virtual functions in an OO environment completely gets around the need to go back and modify legacy code.

While this argument has substantial merit, personal experience from building large (multi-million line) systems tells me that you can't totally avoid this problem. If, for example, an object that is part of a large type tree saves it's state in an ASCII or binary file, when you go to read that object back into memory there is an inevitable case/switch statement needed to distinguish which type of object to instantiate based on certain discriminators embedded in the file.

My advice to programmers at my company is to limit case/switch statements as much as possible, but don't think you are going to eliminate them altogether.

On the other hand, they better not write even a SINGLE "Go To" in their code ... or ... I ... get .... very .... very .... Muh ... Muh .... MAAADDDD!


We're quite far from HP stuff here, but let's say I play the role of the baddy here, advocating a reasonable use of GOTO !!
After taking the journey to OOP and back, I'd say the G*** word was very very useful in circumstances like error trapping such as :

(create big packet of objects - call it A)
(is there an Error ? -> Goto "A")
(lots of processing)
(create big packet of objects - call it B)
(is there an Error ? -> Goto "B")
(lots of processing)
(create big packet of objects - call it C)
(lots of processing)
(cleanup objects in C)
"B" :
(cleanup objects in B)
"A" :
(cleanup objects in A)

Note : objets in packet A, B and C are not related to each other and include global OS entities.

I'm sure there is a politically correct way to OOP-ize it, but simplicity is of the essence to create bulletproof code.
Objects should correspond to concepts, not artifacts to make the compiler do the right thing.


Yes, we are getting way off HP land here ... mea culpa.

My last word on this is that you have hit the nail on the head, GE. Our coding standards allow for a single use of goto in our code, and that is to jump down to the bottom of a function to a label with the specific name "cleanup:". The intent is that the code you find there releases any transient resources amassed by the function and that you would jump there only in case of error conditions.

And... as a weak attempt to justify this extra entry to the thread ... let me just say that my Voyagers are back in their ziplock bags, thanks to the comforting feedback I've received from all of you.


I tend to favour gotos when I'm defining something like a state machine, where I think if() or switch() statements and state variables might cloud what's going on. I'll also use them for performance where I need it.

So, I'm perfectly happy to use gotos where they're appropriate, but I don't see that this is an example of that. Is this not equivalent to the example you cite?

if (!error) {
if (!error) {

Most OOP languages support exception handling, which is specifically intended to let the programmer deal with run-time errors and other unusual conditions in a controllable way, and to allow them to use special syntax to indicate that that's what they're doing. So, you might have something like:

  try {
try {
try {
finally {
finally {
catch (error) {
...handle the error, if you like...
finally {

Just to be different, I've thrown in some actual error handling, although that's not necessary.

Ultimately, the two problems with goto that give some people in the software realm apoplexy are:

  • it increases the chances that control will jump to a piece of code that's not ready to take over, because (for example) variables are uninitialised or out of scope, or the stack is in an untidy condition;

  • it clouds the reason why program control is being transferred elsewhere, which can be made more obvious by the use of all the other keywords that are either 'restricted goto' (such as a switch statement) or 'goto with knobs on'
    (such as subroutine calling).

This second point is especially important, because it increases the comprehensibility of a piece of code, and ultimately most programs are coded for human readability first, and machine readability second. It also makes it easier to analyse the code for flaws, and makes refactoring tools more useful.

Note also that the Dijkstra's proscription of goto originated in the 1960s, when uncontrolled gotos just had to be used a lot, because commonplace programming languages didn't have a lot of other options for transferring control. In part, we now have many features in our programming languages, such as lexical scope, switch statements, continuations, exception handling, and type-based method dispatch, because of the discussion he started.


A GOTO to an error exit can be a wonderful thing. Often times it is MUCH clearer than any other way of breaking out of a bunch of contorted, nested, structured gobbledegook.


Well . . . sure!

That's why there's a warning like

"This is not a toy! Keep out of reach of children!"

on all plastic bags . . .


Possibly Related Threads...
Thread Author Replies Views Last Post
  HP 39gII considered annoying, part 1 Pete Wilson 6 1,617 05-22-2013, 05:08 AM
Last Post: Gilles Carpentier
  forum message deletion feature considered harmful Eric Smith 60 7,366 10-30-2005, 02:32 AM
Last Post: Massimo Gnerucci (Italy)

Forum Jump: