2010-05-12

And now for something completely different: I just read that some scientists believe ball lightning is a phenomenon caused by transcranial magnetic stimulation (TMS). This doesn't seem consistent with the huge amount of observational evidence that ball lightning is a real physical phenomenon. I want to offer a different hypothesis.

Wikipedia cites a review from 1972 that established the following commonly-claimed properties of ball lightning:

They frequently appear almost simultaneously with cloud-to-ground lightning discharge

They are generally spherical or pear-shaped with fuzzy edges

Their diameters range from 1-100 cm, most commonly 10-20 cm

Their brightness corresponds to roughly that of a domestic lamp, so they can be seen clearly in daylight

A wide range of colors have been observed, red, orange and yellow being the commonest

The lifetime of each event is from 1 second to over a minute with the brightness remaining fairly constant during that time

They tend to move, most often in a horizontal direction at a few metres per second, but may also move vertically, remain stationary or wander erratically.

Many are described as having rotational motion

It is rare that observers report the sensation of heat, although in some cases the disappearance of the ball is accompanied by the liberation of heat

Some display an affinity for metal objects and may move along conductors such as wires or metal fences

Some appear within buildings passing through closed doors and windows

Some have appeared within metal aircraft and have entered and left without causing damage

The disappearance of a ball is generally rapid and may be either silent or explosive

This all seems consistent not with an energy ball but rather with an energy bubble: a highly-charged outer surface layer of ionized particles and a highly oppositely-charged inner layer of ionized particles separated by a highly non-conductive layer -- like a bubble-shaped or topologically-closed capacitor. The attractive forces of the outer layer towards the inner layer act as a "surface tension" that gives the bubble its spherical shape but also highly compresses the central air cavity of the bubble, until the electrostatic attractive force pulling the membrane complex inward is equal to the reactive force of the air pressure inside the bubble pushing outward.

This model explains the following:

The spherical shape of the lightning ball. (In the case of pear-shaped ball lightning, as shown in the "UFO or something?" video below, it is simply two bubbles stuck to each other with a central dividing surface, as frequently observed when blowing soap bubbles.) A surface tension gradient is required to induce the Maraghoni effect for bubble formation, which would be present for an electric field surrounding a plasma. This gradient would also explain the fuzzy appearance of lightning balls.

The tendency of the bubble to be attracted to some objects and surfaces and approach or glide along other surfaces. This can be explained by the difference in electric field potential of the two bubble surfaces relative to the charge of the object or surface in question.

The reports of popping or even explosion when the lightning ball destabilizes. This is the bubble popping, releasing the potentially huge interior air pressure, and causing a powerful arc due to electrical breakdown between the two bubble surfaces

The reports of sulfurous smell after the ball pops. This is the production of ozone from the electrical discharge between the surfaces.

Two questions remain: how would such a bubble form, and what could form the insulating layer?

It turns out that induced current in a fully ionized gas becomes unstable or breaks down in a DC electric field of sufficient strength, i.e. above a critical threshold [Nonlinear Electrical Conductivity of a Fully Ionized Gas, Kun-Mu Chen, 1962]. Thus it is conceivably possible to wedge a layer of fully ionized gas (plasma, with net charge close to zero) between a layer of positive ions and a layer of negative ions, if done with sufficient speed and with sufficient induced field strength that current flow through the insulating layer is eliminated before the charges have a chance to equalize.

As far as bubble formation, a lightning bolt would need to topologically enclose a pocket of air to trigger the phenomenon, though I don't know if it would also require a particular mixture of gasses, air moisture content or other conditions to start with. I hypothesize you might be able to create ball lightning by blowing bubbles in front of a powerful enough van de Graff generator. Can anybody test this?

NOTE: People have created plasmoids in a microwave by using smoke clouds emanating from a just-extinguished match. These are balls of ionized gas, and are not the same as the energy bubbles as I am describing here, but they also differ in properties from ball lightning, such as the fact that they disappear within 30ms of the microwave source being switched off.

UPDATE: I emailed Antonio Pavão (see the video below) to ask him his opinion of this theory, and he said: Thank you for sending your BL energy bubble model for my appreciation. It is an interesting model, but I would suggest a quantitite treatment in order to prove the existence of the "highly-charged outer surface layer of ionized particles and a highly oppositely-charged inner layer of ionized particles separated by a highly non-conductive layer". Recently V. Bichkov has proposed a “quasi-solid-vitrified” cover layer around the BL, but I´m still not sure about his results. The existence of this layer is also claimed in the paper “On phenomenon of light radiation from miniature balls immersed in water” from Torchigin V. P., Torchigin A. V., Institute of Informatics Problems, Russian Academy of Sciences, Nakhimovsky prospect 36/1, 119278, Moscow, Russia. Our model considers a metal core surrounded by an atmosphere of silicon oxides.

I heard about Scala a while back and got excited about it, but it wasn't until I started reading Programming in Scala by Martin Odersky (creator of the language) et al. that I realized what an absolutely brilliant language it is. I'm not even halfway through this book and my take on it so far is that I have wasted an immense amount of time in the half my programming career that I have focused predominantly on Java.

The exciting thing is that Scala produces standard (and valid) JVM bytecodes, which (I believe) can be compiled to Javascript by GWT, work fine with Google App Engine, and can be cross-compiled to Dalvik bytecodes for use on Android. I'm excited to try Scala with each of those platforms.

At the same time as being really excited about Scala, I wanted to document here my initial growing pains with using the language. I am finding Scala to be awesome in concept, but a little frustrating in practice, at least initially. The reasons for that include:

Poor IDE support compared to Java -- no Shift-Alt-R for rename in Eclipse, for example, and compilation takes a few seconds longer than Java which can be a bit frustrating when you don't know the language well and you're having to try a zillion things to get something to work. I know there's a daemon version of the compiler that shortens compilation from cold to warm startup time, but I think the latest versions of Eclipse uses it and the Netbeans IDE purports to have moved to it in the latest release -- but it still feels like it takes as long as a cold startup of the compiler (8 secs for a Hello World program), which is unacceptable in my opinion for incremental hacking. (Update, see below)

There is a slight impedance mismatch between Java and Scala libraries, e.g. Scala implements its own collections framework, and things can get a little confusing if you try to mix Scala code with Java code that heavily relies on collections. (Of course you can always call all the Java methods to handle collections, but then you can't rely on Scala's nice syntax for working with the contents of collections, so the code looks different.) Best to stick with 100% one or the other probably. (Update, see below.)

I'm starting to discover a couple of tiny warts in Scala that are due to trying too hard to map onto the Java/JVM world. I had heard they exist, but now have experienced a couple of them. Nothing major and the benefits of the language will probably outweigh this in the long run, but it was something interesting to note.

Thinking in functional style screws with your brain -- it feels really really good, like a hard workout, but it hurts like a hard workout too. I have already adopted lots of functional paradigms in my own programming from previous forays into the FP world (in Lisp, Scheme and Haskell) and I'm a much better programmer for it, but I still need to change my algorithm design paradigms significantly to be really good at using Scala the way it potentially can be used. The lack of FP features is one of my biggest complaints about Java, so this is all welcome frustration.

The syntax is close enough to Java but subtly different enough that the syntax screws with your brain too if you have done a lot of Java. I haven't learned to "see" the name:Type parameter syntax without thinking about it yet, for example, so my subconscious keeps thinking of name as Type and Type as name, and I just get confused until my conscious brain talks my subconscious out of it :-) There are a lot of subtle differences between the two languages that have this effect.

The language encompasses a huge number of older-but-not-mainstream as well as new (as in modern) language features, absorbing the best parts of a number of languages, including ML, Scheme, Haskell, Erlang and C#, mixed into a Java-like syntax in a (surprisingly) mostly self-consistent way. However to fit all that into the language, one of the most remarkable things that Scala accomplishes is that it deconstructs the Java syntax, builds several layers of abstraction and generalization below them, and then re-builds the syntax on top of these generic layers so that the syntax is not a special case, but rather the application of a general prinicple. For example, a method call a.b(c) and an operator expression (x - y) can only be called in those ways in Java, but in Scala you could write x.-(y) or (a b c) to achieve the same effects, because infix operators are just method calls, and you can define methods using symbols. This deconstruct-generalize-reconstruct pattern is pervasive in the difference between Java and Scala, affecting everything from type inference to the handling of built-in types (int etc.) to even control flow: you can define your own control flow operators (for, while, if, try-catch etc.) -- they are just functions operating on blocks.

All in all despite the frustrations with inadequate IDE support and some minor Java/Scala impedance mismatch warts, I think my main problem with Scala right now is just unfamiliarity. It takes me 10 times longer to write anything in Scala -- but I write sometimes 10 times less code, so maybe it's worth it. As I get proficient in the language I'm sure I'll become more productive. I just hope I can learn to switch back and forth without too many brain thinkos. (Similarly, I switched to Dvorak years ago and going back to qwerty just confuses me now :-) )

scala-io is being rewritten and has a number of issues in its current (Scala-2.7) incantation. It's better in Scala-2.8 but it's being totally reworked and made more Scala-esque for Scala-2.9 in this incubator project.