Fabulous Adventures In Coding : Best Of FAIC

References are not addresses

Eric Lippert — Tue, 17 Feb 2009 21:10:00 GMT

[NOTE: Based on some insightful comments I have updated this article to describe more clearly the relationships between references, pointers and addresses. Thanks to those who commented.]

I review a fair number of C# books; in all of them of course the author attempts to explain the difference between reference types and value types. Unfortunately, most of them do so by saying something like "a variable of reference type stores the address of the object". I always object to this. The last time this happened the author asked me for a more detailed explanation of why I always object, which I shall share with you now:

We have the abstract concept of "a reference". If I were to write about "Beethoven's Ninth Symphony", those two-dozen characters are not a 90-minute long symphonic masterwork with a large choral section. They're a reference to that thing, not the thing itself. And this reference itself contains references -- the word "Beethoven" is not a long-dead famously deaf Romantic Period composer, but it is a reference to one.

Similarly in programming languages we have the concept of "a reference" distinct from "the referent".

The inventor of the C programming language, oddly enough, chose to not have the concept of references at all. Rather, Ritchie chose to have "pointers" be first-class entities in the language. A pointer in C is like a reference in that it refers to some data by tracking its location, but there are more smarts in a pointer; you can perform arithmetic on a pointer as if it were a number, you can take the difference between two pointers that are both in the interior of the same array and get a sensible result, and so on.

Pointers are strictly "more powerful" than references; anything you can do with references you can do with pointers, but not vice versa. I imagine that's why there are no references in C -- it's a deliberately austere and powerful language.

The down side of pointers-instead-of-references is that pointers are hard for many novices to understand, and make it very very very easy to shoot yourself in the foot.

Pointers are typically implemented as addresses. An address is a number which is an offset into the "array of bytes" that is the entire virtual address space of the process (or, sometimes, an offset into some well-known portion of that address space -- I'm thinking of "near" vs. "far" pointers in win16 programming. But for the purposes of this article let's assume that an address is a byte offset into the whole address space.) Since addresses are just numbers you can easily perform pointer arithmetic with them.

Now consider C#, a language which has both references and pointers. There are some things you can only do with pointers, and we want to have a language that allows you to do those things (under carefully controlled conditions that call out that you are doing something that possibly breaks type safety, hence "unsafe".) But we also do not want to force anyone to have to understand pointers in order to do programming with references.

We also want to avoid some of the optimization nightmares that languages with pointers have. Languages with heavy use of pointers have a hard time doing garbage collection, optimizations, and so on, because it is infeasible to guarantee that no one has an interior pointer to an object, and therefore the object must remain alive and immobile.

For all these reasons we do not describe references as addresses in the specification. The spec just says that a variable of reference type "stores a reference" to an object, and leaves it completely vague as to how that might be implemented. Similarly, a pointer variable stores "the address" of an object, which again, is left pretty vague. Nowhere do we say that references are the same as addresses.

So, in C# a reference is some vague thing that lets you reference an object. You cannot do anything with a reference except dereference it, and compare it with another reference for equality. And in C# a pointer is identified as an address.

By contrast with a reference, you can do much more with a pointer that contains an address. Addresses can be manipulated mathematically; you can subtract one from another, you can add integers to them, and so on. Their legal operations indicate that they are "fancy numbers" that index into the "array" that is the virtual address space of the process.

Now, behind the scenes, the CLR actually does implement managed object references as addresses to objects owned by the garbage collector, but that is an implementation detail. There's no reason why it has to do that other than efficiency and flexibility. C# references could be implemented by opaque handles that are meaningful only to the garbage collector, which, frankly, is how I prefer to think of them. That the "handle" happens to actually be an address at runtime is an implementation detail which I should neither know about nor rely upon. (Which is the whole point of encapsulation; the client doesn't have to know.)

I therefore have three reasons why authors should not explain that "references are addresses".

1) It's close to a lie. References cannot be treated as addresses by the user, and in fact, they do not necessarily contain an address in the implementation. (Though our implementation happens to do so.)

2) It's an explanation that explains nothing to novice programmers. Novice programmers probably do not know that an "address" is an offset into the array of bytes that is all process memory. To understand what an "address" is with any kind of depth, the novice programmer already has to understand pointer types and addresses -- basically, they have to understand the memory model of many implementations of C. This is one of those "it's clear only if it's already known" situations that are so common in books for beginners.

3) If these novices eventually learn about pointer types in C#, their confused understanding of references will probably make it harder, not easier, to understand how pointers work in C#. The novice could sensibly reason "If a reference is an address and a pointer is an address, then I should be able to cast any reference to a pointer in unsafe code, right?" But you cannot.

If you think of a reference is actually being an opaque GC handle then it becomes clear that to find the address associated with the handle you have to somehow "fix" the object. You have to tell the GC "until further notice, the object with this handle must not be moved in memory, because someone might have an interior pointer to it". (There are various ways to do that which are beyond the scope of this screed.)

Basically what I'm getting at here is that an understanding of the meaning of "addresses" in any language requires a moderately deep understanding of the memory model of that language. If an author does not provide an explanation of the memory model of either C or C#, then explaining references in terms of addresses becomes an exercise in question begging. It raises more questions than it answers.

This is one of those situations where the author has the hard call of deciding whether an inaccurate oversimplification serves the larger pedagogic goal better than an accurate digression or a vague hand-wave.

In the counterfactual world where I am writing a beginner C# book, I would personally opt for the vague hand-wave. If I said anything at all I would say something like "a reference is actually implemented as a small chunk of data which contains information used by the CLR to determine precisely which object is being referred to by the reference". That's both vague and accurate without implying more than is wise.

C# In Depth

Eric Lippert — Mon, 28 Apr 2008 17:19:14 GMT

Good morning, we interrupt our irregular and unscheduled ramblings with this breaking news bulletin: I am pleased to pass on news of the availability of Jon Skeet's new book "C# in Depth".

I had the privilege of being the technical editor of this book. But I've gotta tell you, when I unzipped the files sent from the publisher, the flattery began immediately. The "front matter" placeholder page read:

FOREWORD: To be written by someone really prominent, hopefully – Eric Lippert, perhaps?

Hah! Don't think I went easy on the book because you buttered me up, Jon.

In all seriousness, I was very pleased and honoured to be asked to write the foreword to Jon's excellent book. This was by far the least work and most fun I've had doing technical editing, and the foreword practically wrote itself. Here's what I whipped up:

There are two kinds of pianists.

There are some pianists who play not because they enjoy it, but because their parents force them to take lessons. Then there are those who play the piano because it pleases them to create music. They don’t need to be forced; on the contrary, they sometimes don’t know when to stop.

Of the latter kind, there are some who play the piano as a hobby. Then there are those who play for a living. That requires a whole new level of dedication, skill and talent. They may have some degree of freedom about what genre of music they play and the stylistic choices they make in playing it, but fundamentally those choices are driven by the needs of the employer or the tastes of the audience.

Of the latter kind, there are some who do it primarily for the money. Then there are those professionals who would want to play the piano in public even if they weren’t being paid. They enjoy using their skills and talents to make music for others. That they can have fun and get paid for it is so much the better.

Of the latter kind, there are some who are self-taught, who “play by ear”, who might have great talent and ability but cannot really communicate that intuitive understanding to others except through the music itself. Then there are those who have formal training in both theory and practice. They can explain what techniques the composer used to achieve the intended emotional effect, and use that knowledge to shape their interpretation of the piece.

Of the latter kind, there are some who have never looked inside their pianos. Then there are those who are fascinated by the clever escapements that lift the damper felts a fraction of a second before the hammers strike the strings. They own key levelers and capstan wrenches. They take delight and pride in being able to understand the mechanisms of an instrument that has five to ten thousand moving parts.

Of the latter kind, there are some who are content to master their craft and exercise their talents for the pleasure and profit it brings. Then there are those who are not just artists, theorists and technicians; somehow they find the time to pass that knowledge on to others as mentors.

I have no idea if Jon Skeet is any kind of pianist. But from my email conversations with him as one of the C# team’s Most Valuable Professionals over the years, from reading his blog and from reading every word of this book at least three times, it has become clear to me that Jon is that latter kind of software developer: enthusiastic, knowledgeable, talented, curious and analytical; a teacher of others.

C# is a highly pragmatic and rapidly evolving language. Through the addition of query comprehensions, richer type inference, a compact syntax for anonymous functions, and so on, I hope that we have enabled a whole new style of programming while still staying true to the statically typed, component-oriented approach that has made C# a success.

Many of these new stylistic elements have the paradoxical quality of feeling very old (lambda expressions go back to the very foundations of computer science in the first half of the twentieth century) and yet at the same time feeling new and unfamiliar to developers used to a more modern object-oriented approach.

Jon gets all that. This book is ideal for professional developers who have a need to understand the “what” and “how” of the latest revision to C#. But it is also for those developers whose understanding is enriched by exploring the “why” of the language's design principles.

Being able to take advantage of all that new power will require some new ways of thinking about data, functions, and the relationship between them. It’s not unlike trying to play jazz after years of classical training – or, perhaps, vice versa. Either way, I am looking forward to finding out what sorts of functional compositions the next generation of C# programmers come up with. Happy composing, and thanks for choosing the key of C# to do it in.

Eric Lippert
Seattle, Washington
February 2008

How to not get a question answered

Eric Lippert — Wed, 20 Feb 2008 18:28:00 GMT

Raymond has had lots of great posts over the years on how to not get a question answered. Some of the ways he points out that help ensure that a question goes unanswered are:

Use a difficult or meaningless subject line.
Ask a grammatically unclear question.
Forget to actually ask a question (this is a personal favourite of mine; back when I was working on scripting I would practically daily get an email consisting of a stack trace and a crash report, with no indication whatsoever of what the sender wanted me to do with it. Investigate it? Commiserate? Give career advice?)
Ask an unanswerable question over and over again.

I would add that phrasing the question in terms of the attempted solution rather than the underlying problem is a great way to have a question remain unanswered. But I already did that. Today's rant, rather, is:

A great way to not get your question answered is to treat the person that you're asking to share their time and knowledge like they're not a human being.

I understand that this is easy to do.

I understand that when someone is asking a technical question, it is almost always because they're deeply frustrated by their inability to make some important specific complicated thing work the way they'd expect.

I understand that software makers are a big source of frustration in a more general sense. We all use imperfect software every day; little frustrations mentally accumulate in a way that little victories do not.

I understand that programming languages and software in general is often counterintuitive, and that understanding the complex reasoning behind a counterintuitive result is often seemingly of little practical import compared to just getting the problem at hand solved.

I understand that it is very easy to use an email client as an impersonal and automatic information resource something like a search engine, where you just type in your query, you get your result back, and you move on with your day.

I understand that there is an inherent and pervasive bias in pure-text communication which makes statements intended to be good-humoured sound sophomoric, makes statements which were intended to be friendly sound smarmy, makes statements which were intended to be enthusiastic sound brash, makes statements intended to be helpful sound condescending, makes statements which were intended to be precise and accurate sound brusque and pedantic, makes statements which were intended to be positive sound neutral, and makes statements which were intended to be neutral seem downright hostile.

(Boy, do I ever understand that. For over four years I have deliberately tried to pitch the tone of this blog as good-humoured, friendly, enthusiastic, helpful, precise, accurate and positive; I suspect that most of the time I fail badly at most or all of those. Writing is hard.)

I understand all that, from both sides; I've certainly been on both the sending and receiving ends of all of the above, many times.

Which is why I try very hard to be helpful to the complete strangers who send me overtly rude and frequently profane emails capped off with a request for me to to take time out of my day to explain something to them.

I try to see an upset or confused user as an opportunity to make a good impression; sometimes people do a complete 180 when you help them out and are appreciative and grateful. Sometimes they even send an unsolicited note to your manager, which is always pleasant.

But more often, I never hear from them again after their question is answered.

None of this is in their own best interests. It makes the human information sources they rely upon less likely to help them now and in the future.

So, just a friendly reminder. (A friendly, good-humoured, helpful, enthusiastic, positive reminder!) The people you are sending email to about your technical problems are people. It would be smart to briefly introduce yourself, describe your problem without insulting the people who created it, indicate what you've done to attempt to solve it yourself, actually ask for help, and later say thank-you for their time whether they manage to actually help you or not.

It's smart because doing so is in your own best interests.

It would also be nice, but I actually am not particularly concerned about "nice" today. Nice is nice to have I suppose. But not being smart is just dumb.

C++ and the Pit Of Despair

Eric Lippert — Tue, 14 Aug 2007 18:25:00 GMT

Raymond has an interesting post today about two subtle aspects of C#: how order of evaluation in an expression is specified as strictly left-to-right, and how the rules regarding local shadowing ensure that an identifier has exactly one meaning in a local scope. He makes an educated guess that the reason for these sorts of rules is to "reduce the frequency of a category of subtle bugs".

I'd like to take this opportunity to both confirm that guess and to expand upon it a bit.

Eliminating Subtle Bugs

You remember in The Princess Bride when Westley wakes up and finds himself locked in The Pit Of Despair with a hoarse albino and the sinister six-fingered man, Count Rugen? The principle idea of a pit of despair is twofold. First, that it is a pit, and therefore easy to fall into but difficult work to climb out of. And second, that it induces despair. Hence the name.

I often think of C++ as my own personal Pit of Despair Programming Language. Unmanaged C++ makes it so easy to fall into traps. Think buffer overruns, memory leaks, double frees, mismatch between allocator and deallocator, using freed memory, umpteen dozen ways to trash the stack or heap -- and those are just some of the memory issues. There are lots more "gotchas" in C++. C++ often throws you into the Pit of Despair and you have to climb your way up the Hill of Quality. (Not to be confused with scaling the Cliffs of Insanity. That's different.)

Now, as I've said before, the design of C# is not a subtractive process. It is not "C++ with the stupid parts taken out". But that said, it would be rather foolish of us to not look at what problems people have typically had with other languages and work to ensure that those exact same problems do not crop up for C# users. I would like C# to be a "Pit of Quality" language, a language where its rules encourage you to write correct code in the first place. You have to work quite hard to write a buffer overrun bug into a C# program, and that's on purpose.

I have never written a buffer overrun in C#. I have never written a bug where I accidentally shadowed a variable in another scope in C#. I have never used stack memory after the function returned in C#. I've done all those things in C++ multiple times, and it's not because I'm an idiot, it's because C++ makes it easy to do all those things accidentally and C# makes it very hard. Making it easy to do good stuff is obviously goodness; thinking about how to make it hard to do bad is actually more important.

Now, given that the design of C# is not subtractive, we have to consider the pros and cons of each decision. Is there any compelling user benefit in a deliberate failure to specify what order functions in an expression are evaluated? The only benefit I can think of is "not breaking some existing users of two existing incompatible implementations by declaring one of the implementations to be wrong", which is the situation that the C standardization committee frequently found itself in, I'm sure. When C# was a new language that wasn't an issue, so we were free to pin that down early. Doing so has compelling benefits; it prevents subtle bugs, and as I'll discuss in a moment, there are other benefits as well.

So, long story short, yes, designing the language so as to prevent certain categories of subtle bugs is a huge priority for us. However, there are other reasons too. For instance:

Uncertainty sometimes has high value but only in special contexts

Like Vroomfondel said, "we demand rigidly defined areas of doubt and uncertainty!" Ideally, those areas should be small and should afford some way for users to eliminate the uncertainty. Nondeterministic finalization is a good example. We deliberately do not specify when and in what order finalizers run because:

the vast majority of the time it makes no difference,
relying on a particular timing or ordering of finalization some small percentage of the time is probably a subtle bug waiting to happen,
specifying it would require us to simplify the implementation to the point where it actually could be specified, thereby destroying much of its value; there is value in that complexity
specifying it ties our hands to make algorithm improvements in the future

But we do provide a mechanism (the "using" statement) whereby if you do need to ensure that a finalizer runs at a particular point, there is an easy syntax for it.

With the possible exception of point 2, the order of evaluation of sub-expressions does not have these problems. It often does make a difference, the implementation is already simple enough that the specification is trivial, and its unlikely that we are going to come up with some incredible improvement in the algorithm which determines what order subexpressions are evaluated in. And if by some miracle we do, the specification does take care to call out that if we can prove that out-of-order evaluation cannot introduce subtle bugs, then we reserve the right to do it.

Uncertainty is hard on the language implementation team

When I am implementing part of the language specification, of course I want great freedom to decide how to implement a particular chunk of semantics. The language specification is not in the business of telling me whether we should be using a hand-written recursive descent parser or a parser-generator that consumes the grammar, etc. But I hate, hate, hate when I'm reading the specification and I'm left with a choice of what semantics to implement. I will choose wrong. I know this, because when I ask you guys what the "intuitively obvious" thing to do is, significant fractions of the population disagree!

Uncertainty is also hard on our testers -- they would like to know whether the language is correct, and being told "the specification is unclear, therefore whatever we do is correct" makes their jobs harder because that's a lie. Crashing horribly is probably not correct. Deadlocking is probably not correct. Somewhere on that spectrum between clearly correct behaviour and clearly incorrect behaviour is a line, and one of testing's jobs is to ensure that the developers produced an implementation that falls on the "correct" side of that line. Not knowing precisely where the line is creates unnecessary work for them, and they are overworked already.

And uncertainty is hard on our user education people. They want to be able to write documentation which clearly describes what semantics the implementation actually implements, and they want to be able to write sample programs to illustrate it.

Uncertainty erodes confidence

And finally, uncertainty erodes confidence in our users that we have a quality product that was designed with deep thought, implemented with care, and behaves predictably and sensibly. People entrust the operation of multi-million dollar businesses to their C# code; they're not going to do that if we can't even reliably tell them what "(++i) + i + (i++)" does!

*****

Next time on FAIC I think I'll talk a bit about a related principle of language design: how we think about issues involving "breaking changes". I'll be expanding upon an excellent article written a couple of years ago by my colleague Neal, so you might want to start there.

Talking About The Weather, Part Two

Eric Lippert — Fri, 03 Aug 2007 17:25:00 GMT

What we’re missing is a phenomenon that probably was described correctly by your high school science teacher, namely, the phenomenon of “latent heat” (which is what I was taught, though “enthalpy” would be the more modern term.)

I said that the temperature of a substance is the average amount of energy in it. I lied; it is possible to add energy to water without changing the temperature. Liquid water requires “extra” energy to vaporize that is not reflected in the temperature of the water. You may recall doing a science experiment which ended up with a graph like this one.

As you can see from the graph, when the water reaches the point where it is about to melt or boil the temperature stops going up for a while, even though more and more energy is being added to the mix. The liquid water requires an extra little boost of energy to liberate the molecule from the liquid. That amount of energy is roughly 540 calories per gram of water thusly liberated.

Let me be very clear on two points here. First, liquid water evaporates at any temperature, not just the boiling point. Obviously puddles dry up even though they are not boiling! The boiling point is simply the point at which the liquid water has so much heat, and the vapor pressure is sufficiently low, that all of it is going to rapidly turn into vapor in short order. And second, with that in mind it should be clear that the 540 calories required per gram of vaporized water is 540 calories per gram no matter what temperature the water is at when it is vaporizing. (There may be some small variation in the latent heat required based on the temperature, but it'll be on the near order of 540 calories per gram in the kind of temperature ranges we're talking about here.)

One way to think about the latent heat is this: liquid water has way more entropy – more randomness – than solid water. The position and speed of each molecule in a liquid is way more random than in a solid. And similarly, water vapor has way more entropy than liquid water. Adding heat makes entropy; it disorders a structure. If you want to make water more entropic by evaporating it, you’re going to have to add a whole load of heat to it to account for the increase in entropy. 540 calories per gram, in fact.

But this process goes the other way too. When you export entropy from water vapor by turning it back into a liquid, those 540 calories per gram have to go somewhere. That entropy is exported from the water in the form of heat. When you put your finger in the steam rising from a boiling kettle, it's the enormous latent heat of the vapor condensing on your relatively cold finger that really scalds you. Even if you happened to be in atmospheric conditions where the condensation happened to a much lower-temperature vapor, the latent heat would still hurt a lot.

So now let’s revisit our look at a nice fluffy cloud. The sun adds 540 calories to a gram of surface water, liberating it into the atmosphere. That gram of water winds its way up into the sky where it hits a region of sufficiently low temperature and high pressure as that it flashes back into liquid form. Without changing the temperature of the water further, 540 calories is suddenly liberated into the bottom of the cloud, heating up the surrounding air. Hot air rises. An updraft forms in the middle of the cloud, sucking some of the water droplets higher into the atmosphere. The cloud gets taller. Eventually the updraft cools off and the cooler air moves outwards and slowly subsides. You'll get a sort of doughnut-shaped circulation of air around the exterior of the cloud as the falling air then gets sucked back in the bottom.

Meanwhile, the bottom of the cloud is getting hotter and hotter from the latent heat of more water evaporated from the lake surface turning back into liquid. The bottom of the cloud has an updraft in it, so it is pulling more and more water vapor from the wet atmosphere below it into the bottom of the cloud. The process is accelerating. If the cloud happens to be over a huge body of warm water then this can accelerate very rapidly.

The latent heat of fusion liberated when a gram of liquid water turns into ice is another 333 calories on top of the 540 calories that was from the latent heat of condensation. Imagine what happens to our cloud if the strong updraft makes the cloud so tall that the extremely cold atmosphere up there glaciates the lifted droplets into a cirrus cloud at the top. Cirrus clouds are made out of ice crystals. The water (now in the form of ice) escapes from the cloud out the top and potentially stays up there for a long time. The ice drifts slowly away from the top of what is now probably looking like a pretty threatening cloud. Essentially the cirrus cloud is extracting all the latent heat from the water, depositing the heat in the cloud, and exporting the resulting coldness out the top in the form of ice.

Now imagine what happens if a bit of the water vapor in the cloud gets cold enough to freeze in the middle of the cloud. It liberates its latent heat of fusion into the updraft, making it stronger. The updraft sucks the ice fragment up through hundreds of meters of cold wetness. When it gets to the top, maybe it is heavy enough to fall back down through more cold wetness in the outer part of the cloud, only to get sucked up by the updraft again when it reaches the bottom. The ice fragment gets bigger and bigger, liberating more and more energy into the updraft as it goes around in vertical circles. Eventually the updraft is not strong enough to hold it up and all that cold gets exported out the bottom of the cloud in the form of hail.

And that is how thunderclouds concentrate massive amounts of energy; they move huge quantities of latent heat that the sun puts into warm surface water into their interiors to power the very updrafts that suck in more vapor from below, concentrating the heat even more. The average heat keeps going up because coldness is exported in the form of cirrus clouds out the top and hail (or cold rain) out the bottom.

Now imagine the effect of hundreds of such clouds forming over a relatively small area. The suction from the updrafts is immense, and easily moves around millions of tonnes of air that we then experience as high winds. And when the updrafts are insufficient to hold the water up, you get torrential rains and hail falling out of the sky. It’s an amazing phenomenon, and it is all thanks to the fact that our planet is almost entirely covered by a substance which has high latent heat and can be solid, liquid and gas in a relatively small temperature and pressure range.

Talking About The Weather, Part One

Eric Lippert — Thu, 02 Aug 2007 17:31:00 GMT

No technology today; just talking about the weather.

I love talking about the weather.

I mentioned the other day that I had just returned from my ancestral homeland on the shores of Lake Huron, the great inland sea of southwestern Ontario. We got some rip-roaring thunderstorms this year. I love thunderstorms on the lake. They are extremely dramatic, particularly at sunset.

Think about this for a minute: even small thunderstorms must move around literally millions of tonnes of air and water, often at high speed. Storms are massive concentrations of energy. Where does the energy come from? How does it get so concentrated?

Coincidentally, I had just started reading Frank Bethwaite’s book “High Performance Sailing”. Bethwaite is not just an amazing sailboat designer, but also a professional meteorologist. As someone who knows next to nothing about the weather I found it fascinating to learn just why it is that thunderstorms are so powerful.

Understanding this phenomenon required me to first be disabused of an incorrect notion that I’ve held probably since the fourth grade. You were probably taught this too, in your elementary school or high school science classes: “the reason clouds form when moist air cools is because cold air can hold less water than warm air”.

Nope. Not true. Your science teacher was wrong. That statement, though arguably not entirely false, is sufficiently misleading as to work against a correct understanding of the weather. Nitrogen and oxygen, the gasses which make up most of the atmosphere, have no ability to “hold” anything. Their molecules are way too far apart to hold onto anything. Furthermore, phenomena such as cloud formation can be explained entirely without this idea, so just based solely upon Occam's razor we should dispense with the notion that the air has something to do with it.

Ironically, the actual situation is not really very difficult to understand. First, consider the behaviour at the molecular level:

A molecule of liquid water will vaporize when its energy is high enough.
Conversely, a molecule of water vapor will condense into liquid when its energy is low enough.

Now consider the aggregate behaviour of zillions of individual molecules. We call the average energy of many molecules the “temperature”. When in gaseous form, that energy manifests itself as the molecules exerting force on their surroundings by slamming into things at high speed. We measure the number of molecules which inhabit a given region at a given temperature by measuring this force, which we call “pressure”.

Since temperature is an average, obviously some of the molecules in the sample will have less energy than average, some will have more. If the temperature is high, then a higher percentage of the liquid molecules will have enough energy to vaporize and a lower percentage of vapor molecules will have low enough energy to condense. A warm puddle of water evaporates faster than a cold puddle of water for this reason. And when you sweat, you cool down -- the warmest water molecules on your skin are evaporating and taking their heat with them, away from you.

Since pressure (at a given temperature) is proportional to how many vapor molecules there are in a given amount of space, it should be equally clear that at high pressure, there are more molecules available to condense than at low pressure. So we should expect that, all else being equal, the higher the vapor pressure, the more condensation we’ll see. “Damp air” – air that has a lot of water vapor pressure - condenses onto a cold window a lot faster than dry air.

With that simple molecular explanation, cloud formation can now be understood with no reference whatsoever to nonsense like “the water-holding capacity of the air”. Why should we mention the air at all? The air has nothing to do with it, aside from the fact that heating up the air also heats up the water vapor in it. Clouds would form equally well if our atmosphere was a mixture of helium and water vapor, or for that matter, just pure water vapor. All that matters is the temperature of the water and the vapor pressure in the region. A cloud is exactly that portion of the atmosphere where the vapor pressure is high enough and the temperature is low enough that a significant quantity of water condenses.

(To be nit-picky, yes, there are other factors. Foreign substances mixed into the liquid water, whether any of the water is in solid ice form, whether the liquid water is in round droplets or flat sheets, and so on, influence the rate of vaporization and condensation as well. My point though is simply that the "holding capacity" of the non-water part of the air is not relevant right now.)

With that in mind let’s look at the larger picture of how a cumulus cloud forms.

The sun heats the surface of a body of water. Say, my beloved Lake Huron. The temperature of the surface rises, so the rate of vaporization increases. Some warm vapor rises until it encounters a region of the atmosphere where the temperature is low enough and the vapor pressure is high enough that the water vapor turns back into liquid water. The liquid molecules combine into droplets which we can see. If the droplets get big enough then they fall back to earth in the form of rain.

That explains clouds and rain but does not explain the phenomenon I’m trying to understand here: why thunderstorms are so energetic. It seems like what we’re doing is moving the energy from the sunlight into the lake surface, then into the atmosphere via evaporation, and then that energy is transferred randomly into to the rest of the atmosphere when the cloud cools and condenses. After all, that’s what “cooling” is – moving heat energy to somewhere else. If this explanation is right then clouds should be dispersing energy, not concentrating it. Something else is going on here. What are we missing?

Next time on FAIC: Entropy!

How to make little girls scream like… well, like little girls

Eric Lippert — Thu, 03 Nov 2005 20:44:00 GMT

[No technology today, so if you're only here for the witty banter about programming languages, skip this one.]

Leah and I spent the week before Halloween volunteering at Nightmare At Beaver Lake, a haunted-house-style attraction that runs along the trails in Beaver Lake Park, just on the other side of Lake Sammamish from Microsoft's main campus. I had never done any kind of acting before whatsoever and it was an enormous amount of fun to learn what scares people.

I was fortunate enough to be given my dream role every night: not just a zombie, but the very first big scare on the trail. As victims came down the trail and rounded a slight corner they saw a fog-shrouded graveyard full of glow-in-the-dark tombstones, and in the distance, a vampire-infested haunted house. They would stop to read the witty saying on the tombstone and then I, in full zombie makeup, lurched out from behind it with a big old RAAARGH!

That worked pretty well, but my co-zombies and I did a lot of fine-tuning as we figured out what scared people and what didn't. We had over 6000 opportunities over the week, so eventually we got it down to a science. As a public service to future aspiring zombies, here's some stuff that we learned works:

Listen to the people coming down the trail. Their conversations will often tell you which people you should go after for maximum scare potential. If someone says "I'm totally scared of things jumping out at me", jump out at them with a huge RAAARGH! If they say "I'm totally scared of things creeping up on me", creep up on them and then right in their ear give a little groan. If they say that they're scared of things following them, follow them. And so on.
I probably heard fifty times a night "you go first, I'm too scared, no, I don't want to be last either" as a group was rounding the corner. If you've got a large party coming down the trail always go for the middle; that's where the most easily scared people are. Also, that way the people in front get scared from behind, the people in the middle get scared from the side, and the people in back get scared from the front. If you go for either end then the people at the other end don't get scared at all. Moreover, the women in the center often link arms. This means that when one of them leaps backwards and screams, they all fall backwards, which is hilarious. (Try not to laugh, it ruins the illusion.)
If you can scare people into running one way, have a second zombie in the woods on the other side to scare them again. Do this as long as it works. We had one little girl, maybe eleven years old who I scared, she screamed and took off down the trail directly towards the other zombie, who jumped out, scared her, she ran back towards me, I jumped out again, she ran the other way, and finally one of the brides of Dracula jumped out from behind yet a third tombstone – it was like playing pinball. And believe me, to freaked out people two zombies and a bride might as well be a horde. You feel totally surrounded.
Creeping up on people is a harder and more dangerous – sometimes people will instinctively swing at you when they are startled, though this didn't happen to me. But it can be very effective. If someone stopped to read the tombstones I would try to very quietly get right beside them so that when they turned to look up and continue the trail, I'd be about six inches from their face.
Making a brief hissing or groaning or gurgling noise to get people creeped out before the RAAARGH! can be highly effective but you've got to get the timing just right. Too long and you'll telegraph your location, too short and it gets lost in the RAAARGH!
You can't startle everyone, they're just coming too fast. We had 2100+ people through in four hours one night. Remember that there are 40 other volunteers down the trail who will try to startle them, and some will succeed. If you miss a chance to startle a group, you can still creep them out while you lurch back to your hiding place.
Sniff at people. It is incredibly creepy to have someone smell you, particularly if they then act hungry.
If you can scream like the nazgul from the TLotR movie, that really works but you get hoarse after four hours of it. (I cannot but one of my co-zombies had a wicked scream.)
Always stay in character. One time I jumped out and scared a woman so badly that she dropped the cell phone she was (inexplicably) holding and took off at a run. Fortunately she ran right into the vampire house, so while the brides and Dracula were freaking her out even more I grabbed the phone, opened it up so that it would light up, and ran around to the exit of the vampire house. But you can't just say "hey lady, you dropped your cell phone, here you go", you've got to lurch towards her, groaning, and hand her the cell phone like a zombie would. Similarly, if you see your friends then stay in character, you can chat with them later. Breaking character ruins it for everyone else.
Speaking of which, if you are an audience member in a haunted house, do not talk on your freakin' cell phone! You're ruining it for everyone else. You wouldn't do that in a movie or a play, so don't do it in a haunted house either.
Teaming up two scary zombies works well, but teaming up a scary monster with a speaking part can also be very effective. In Leah's area she was the little old hillbilly lady on the porch who would engage the victims with humour, and then as soon as they were distracted, her "son", the six-foot-eight guy with the pig's head and the chainsaw would jump out of the shack. This is particularly effective against teenagers who are sassing back to the old lady: they are maximally off their guard.
Finally, a couple things about difficult customers. First, if a customer really, truly is not having a good time, just let them go. Sometimes we got small children, teenagers and even adults who were so scared that they stopped having a good time and had to leave. One girl, maybe thirteen years old, just stood still and started yelling "IWANTMYMOMIWANTMYMOM" over and over again, would not move, and had to be removed by security.
Second, if an idiot teenage boy sees you hide and announces where you are, or you have a "tour guide" who has been on the trail before telling everyone where the scares are then they've already ruined it for themselves and their entire groups. There is nothing you can do to make it scary at that point, so just ignore them, keep hiding, wait for the group to go by, and get the next group.

Anyone else have any suggestions for aspiring zombies?

Through the Looking Glass

Eric Lippert — Mon, 22 Aug 2005 23:00:00 GMT

I'm back, I'm married, we had a fabulous time, and now I'm setting up new machines and figuring out what the heck I'm doing on the C# team. Today, we'll get back into it with some non-tech fun.

A regular flat mirror seems like it ought to be perfectly symmetrical in its operations. So why is it that mirrors produce an image which reverse left and right, but not, say, top and bottom? (A concave mirror, like the inside of a spoon, reverses top and bottom, but let’s worry about only flat mirrors for the duration of this article.) How does the mirror know which way is left-right?

Think about that for a while before you read on. See if you can figure it out for yourself.

Stuck? Try this.

Get a mirror.
Stand in the place where you live.
Now face north.
Think about direction. Wonder why you haven’t before.
Hold the mirror out in front of you with your left hand.
Point east with your right hand.
The “person in the mirror” is still pointing east, and towards the right side of the mirror (from your perspective), but doing so with their left hand while facing south.

Wait a minute. The mirror not only produces an image which reverses left and right but not up and down; apparently it also reverses north and south but not east and west!

It’s more productive to think of a mirror as actually producing an image which reverses front and back. If you’re facing north then “front and back” is the same as “north and south”. If the mirror is on the floor then “front and back” is the same as “up and down”. Note that if you took a movie of someone and flipped the movie film front-back when you showed it, you’d get the same effect.

But why then do we all think of mirrors as reversing left and right, if in fact they reverse front-back? Psychologically, humans see a front-back-reversed human as a left-right reversed human. That image of a south-facing person smiling back at you is not an image of a human being at all. Their DNA spirals the wrong way. All their body fat is made out of indigestible Olestra. Their heart is on the wrong side of the body. If we could somehow create a real being who produced exactly that image, down to the front-back-reversed internal structure, there’s no way that they could produce viable offspring with a non-reversed human.

But none of these is apparent at a glance. Since humans have almost perfect left-right symmetry it is extremely easy to interpret an image of a back-front-reversed human as a left-right reversed human. After all, if you were trying to act to look like the person in the mirror, that’s what you’d do – simply reverse your left and right behaviour. You decide what is “slippable” and what isn’t. If you are trying to look like the image in the mirror looks, you’d ignore all that stuff about your DNA and internal organs and reverse left and right, because that happens to produce the image that looks most similar. If humans had different symmetries then mirrors would not appear to reverse left-right at all, because our psychology would be different.

Imagine a race of super-intelligent fishes that look like eels with a perfectly circular cross-section. Our fishes have a blue fin on one side, a red fin on the other side, one eye in the very front of their face. These eely fishes can swim with their fins rotated in any direction they choose. That’s a weird looking fish, but bear with me. Such a fish looking in a mirror would probably see the back-front reversed image as being not left-right reversed – because, what’s left-right to a symmetrical fish? – but rather as rotated 180 degrees. That’s what a fish would have to do in order to imitate the fish in the mirror. The super-intelligent fish version of this blog entry would be “why do mirrors rotate images?”

Similarly we could come up with bizarre creatures whose various lines of symmetry would cause them to see mirror images as top-bottom reversals. Even more bizarre, suppose human males and females were more or less exactly the same in their outward physical characteristics, except that men had both arms on the right side of their body, and women had both arms on the left side of their body. We’d then be asking why mirrors change sex! And who knows what inhabitants of the planet Cheron would think?

What I Did On My Summer Vacation

Eric Lippert — Tue, 13 Jul 2004 01:09:00 GMT

I'm back, and I've almost made it through the 525 not-automatically-sorted email messages, caught up on my blog reading, and so on. There are a number of interesting technical questions in my backlog that I'll start getting to later this week once I dig myself out of the pile of bug reports that accumulated during my absence.

Until then, again, this was just too precious to not share. If you only want technical stuff, stop reading now.

One of the highlights of my twice-annual return to my ancestral home is spending time with my cousins. My five-year-old cousin Zephy takes great delight in taunting me. Every year she teaches the small army of munchkins that she hangs out with some ditty which is to be shouted repeatedly whenever I come into view. This year it was "Eric is evil! Eric is evil! Eeeeevil!" It's quite the experience, believe me. I suspect that the root of this behaviour has something to do with the fact that I once convinced her that Lake Huron is chock-full of Great Canadian Beaver-Sharks -- giant buck-toothed, flat-tailed sharks which subsist on a diet of driftwood, canoe paddles, wooden sailboats and little girls -- and then repeatedly threatened to throw her in the lake. In retrospect, maybe that wasn't such a good idea.

Her older sister Victoria does not believe in Beaver-Sharks. At one point she and her friend Kelsey ran up to me (ten year old girls run everywhere) to ask if they could borrow my pair of kayaks. "Sure. You can always borrow the kayaks even if I'm not around as long as you tell a responsible adult that you're going out on the lake," I said. Kelsey got a slightly worried look -- "Is my mother a responsible adult?" she deadpanned.

For future reference: unless otherwise noted, all mothers are responsible adults.

And finally, Vic has a "mad crush" on a boy, who will remain unnamed. She wasn't sure what to do about that, and since apparently I'm an internationally recognized expert on getting boys to like you, she asked my advice. I wasn't sure what to say -- the first girl I ever had a mad crush on I ended up dating for seven years, which is probably atypical -- so I've started surveying every 8-12 year old girl that I meet as to what they do about mad crushes. I met an eight-year-old girl named Heather at a barbecue over the weekend and asked her. Her detailed off-the-cuff reply showed that she'd already put a lot of thought into this question, though she had not actually needed to test her theories yet. Allow me to quote from memory:

"There are two things you can do if you have a mad crush on a boy, you can ask him to propose marriage and if he won't, then beat him up, then send him to an island, then surround the island with huge rocks so that he can't escape, then send him Valentine's cards that say 'I HATE YOU!' but if he does propose marriage then you can kiss him and marry him and move into an apartment and have a baby and bake him a cake that says 'YOU ARE MY FAVOURITE BOYFRIEND' in the icing."

Sounds like a good plan! Any current or former 8-12 girls out there who have additional advice for surviving a mad crush (who I suppose happen to also be interested in programming language design if you're reading my blog…) please leave comments and I'll forward them on. Run-on sentences are fine.