Monday, 12 May 2014

Java 8 is functional, and fun

When I heard that Java was getting 'lambdas' or, as I prefer to think of them, sort-of-closures, as I was an enthusiastic Smalltalk programmer many years ago, I wasn't that excited.  Being Java, I thought that these lambdas would be dull but reliable, which is what I have come to expect of Java.  I had no complaints, because Java is all about solid, reliable, readable code.  I was mistaken - Java lambdas are extremely powerful and huge fun.

What I really love about Java 8 lambdas is the ability to have them implicitly constructed by method references.  That sounds obscure, but it's one of the most powerful and expressive features of Java 8.

I'll show how this works by showing some Smalltalk code.  This code might be from some sort of user interface, and maps key presses to code.

codeMap := Map new.
codeMap at: $A put: #doThis.
codeMap at: $B put: #doThat.

$A and $B are character constants.  #doThis and #doThat are symbols, which in this code hold the name of methods. So, the following code will work:


onKeyPressed: key

keyHandler perform: (codeMap get: key)

The symbolic method name is looked up using the character supplied and the object 'keyHandler' is passed that method name to run.

It's a very concise way of mapping characters to functions, without the need for hard-coded and verbose 'if' or 'switch' statements.

This was impossible in Java.  Until Java 8.  Now, it's very easy.  Here is an example:

public class KeyHandler {

// Map of  Character to a function which has a single parameter - a KeyHandler Instance

public final static Map<Character,Consumer<KeyHandler>> codeMap = new HashMap<>();

// Put method references into the map
static {
   codeMap.put('A',KeyHandler::doThis);
   codeMap.put('B',KeyHandler::doThat);
}


// The map can be used like this
public void respondToKey(char key) {
    Consumer<KeyHandler> function = codeMap.get(key);
    if (function != null) {
        function.accept(this);
    }
}

private void doThis() {}
private void doThat() {}
}

What's going on here is that Java 8 lambda syntax means that the map construction could have been done like this:

codeMap.put('A', (KeyHandler handler) -> {handler.doThis();});
codeMap.put('B', (KeyHandler handler) -> {handler.doThat();});

The type of 'handler' can be inferred because of the type of codeMap, and single statement lambdas don't need brackets:

codeMap.put('A', (handler) -> handler.doThis());
codeMap.put('B', ( handler) -> handler.doThat());

brackets aren't needed for lambdas with one argument:

codeMap.put('A', handler -> handler.doThis());
codeMap.put('B', handler -> handler.doThat());

These lambdas are treated implementations of the interface Consumer<KeyHandler>.  In Java 7 this code could be written using inner anonymous classes:

codeMap.put('A',new Consumer<KeyHandler>() {
   public void accept(KeyHandler handler) {
       handler.doThis();
   }
});

And so on.  There is the slight matter of the 'Consumer' interface not being available in Java 7, but that doesn't matter for this example.

Java 8 lambdas are much more concise, and, it turns out, can be run-time optimised to be typically much more efficient than inner classes, both in terms of memory and speed.

We are nearly there with explaining the use of method references.  In Java 8 a method reference can be used instead of a lambda if the method is, if renamed, the same as the single method in the interface that the lambda is an instance of.   Well, almost.  Assume it is the case for now.  Suppose we had a method that wanted a Runnable as a parameter:

public void doThing(Runnable runnable) { runnable.run(); }

The KeyHandler methods doThis and doThat have no arguments and no return value, and so they are the same as the Runnable method run().  And so, in Java 8, references to these methods can be used as 'Runnable' instances.

KeyHandler handler = new KeyHandler();
doThing(handler::doThis);

Any method that has no arguments and no return value can be used as a Runnable instance in Java 8.

There is one final step to explain what is going on in the KeyHandler class.  Java 8 can have method references even when there is no instance of the class implementing the method.  There is an obvious case of when this is needed:  static methods.  Static methods aren't run by instances.  Here is an example:

public class Thing {
    public static void printSomething() {
        System.out.println("Hello");
    }
}

The method Thing.printSomething() has no arguments and returns nothing, so it can be used as a Runnable:

doThing(Thing::printSomething);

This will print "Hello".

Now let's give Thing an instance method:

public class Thing {
    public static void printSomething() {
        System.out.println("Hello");
    }
    public void printSomethingElse() {
        System.out.println("Goodbye");
    }
}

What does "Thing::printSomethingElse"  mean?  It's an instance method, but no instance is given.  It has no arguments and returns nothing, so it looks like a Runnable.  It isn't.  There is a hidden argument in this method reference.  That hidden argument is the instance that will run the method.

Thing:printSomething else, is, in fact a possible implementation of Consumable<Thing> (or any other interface with a single method that takes a Thing as parameter and returns nothing).

This is how this method reference can be used:

First, we define a new method:

public void doThing(Thing instance,Consumable<Thing> function) {
    function.apply(instance); 
}

Now we use it:

Thing instance = new Thing();
doThing(instance,Thing::printSomethingElse);

This will print "Goodbye".

Finally, we can see what the method references are all about in the KeyHandler class.  They indicate what instance methods are to be used, and also that an actual instance must be supplied.  That's why they are effectively Consumable instances and not Runnable instances even though the methods they refer to have no arguments and return nothing.

So, I finally get to code my Smalltalk idiom in Java!
 

Tuesday, 6 May 2014

Why not Scala?

Scala is a very powerful and relatively new language that runs on the Java runtime - the "Java Virtual Machine" (JVM).  It's getting a lot of positive publicity, and it seems that it is gaining acceptance.  However, I'm really cautious about using it in any major project that is expected to be run and maintained for years.  Why?  There are many reasons, here are a few:

1. Complexity.

Scala is BIG language.  It combines object-orientation with functional styles and seems to include almost every possible thing that a programming language can do.  Some (far from all) the programming idioms currently in Scala (2.11.0) are:

declarative matching
case conditions
case classes
value classes
'for' comprehensions
xml embedding
dynamic method calls
generics
type range syntax
implicit methods
implicit classes
parameter placeholders
method references
special 'apply' method
currying
tuples
destructuring binds
traits
relative imports
package objects
named arguments
partially applied functions
lazy values
type aliasing
'operator' overloading

I have been programming and keeping up as best I can with programming for over 30 years, and, to be honest, I'm not sure what a few of these mean.

I do like many of these features: Implicit methods are a neat way to add functionality to existing classes by invisibly transforming such classes into new classes with new functions:

// Here is a silly example

class MyString {
def hello {
    println("hello")
}

implicit def toMyString(s: String) = new MyString

// Now "abcd".hello will print "hello" - effectively a new method .hello has been added to all strings where 'toMyString' is in scope.

However, this ability to tweak what code can do in hidden ways can lead to source that is extremely hard to follow.  Also, what can be done by a developer will end up being done by someone in a development team if that team is of any but the smallest size.  I know from experience.

2. What does Scala code do?

Here is an example of normal Scala code:

val x = myFunction()

What is going on here?  All we can see is a function call.  What kind of thing is 'x'?  What can it do?  The problem here is that Scala can infer types based on whatever is assigned to a value or variable.  You could write:

val x: String = myFunction()

Assuming, of course, myFunction returned a String, but this isn't necessary, and inference of type is standard practice.  But, if someone changes the return type of myFunction() at the point of its definition, you may have no idea that this has happened until a program has been run.  Look at the following code:

def getMyValue() = 1

val result = getMyValue() + getMyValue()
println(result)

When run, this will print "2"

Now, change the function:

def getMyValue() = "1"

When run, this will print "11"

Type inference is an example of where I think Java is doing things the right way.  Java insists on the type of a variable being described when the variable is defined:

String x = myFunction()

Any change in the result type of the function will be immediately caught at this point in the code by the compiler.  Java 8 allows for type inference to be used to reduce the amount of code needed to describe lambdas. 

Java 7:

Runnable code = new Runnable() { public void run() { System.out.println("run!"); }};

Java 8:

Runnable code = () -> System.out.println("run!");

That the lambda (the bit after "=") represents a Runnable, and the code should be seen as the body of a "run" method is inferred from the type of the variable "code". 

Java has the contract between function developer and function user explicit at the point of use.  This leads to clearer code.

3. Scala changes.

You can run positively ancient compiled Java code on the most modern Java VM.  a Java GUI program written from the early days of Java will still compile, and still run.  Java code doesn't die.

Scala is younger, and already a significant part of the language and libraries - the Actor system for parallel code - has been deprecated and replaced by a newer library, resulting in the need for migration work.  The new library (Akka) is a great system, but developers of significant and long-term projects really don't want to have to face this kind of change to keep up-to-date with bug-fixes and new features.  At least I don't!  Java's slow adoption of new idioms can be a real advantage for this kind of development, where stability is vital.

4. Who uses Scala?

In spite of it's frequent discussion, the actual use of Scala seems to be very small.  The TIOBE site monitors the volume of information on many Internet sites about different languages.  As expected, Java and C dominate.  Over recent years JavaScript and Objective C have grown hugely.  Scala is down below the decimal point of a percentage, somewhere between Fortran and Prolog. This does not directly indicate the quality of Scala, but it does show that getting Scala developers for a major project can be difficult and expensive.

It could be justifiably said that I'm not helping Scala with this attitude.  But I have to face the fact that software development for large and long-term projects isn't about taking a charitable approach to development languages and tools.  It's about delivering stability, reliability, and long-term maintainability.  It's about being justifiably dull!

Saturday, 3 May 2014

Why Java?

I have been a programmer most of my life.  I fell in love with programming as a young teenager.  I learned BASIC, because, then, everyone learned BASIC.  I progressed through Fortran, Algol, COBOL, and various assemblers... but that was decades ago.  Now I program mainly in Java, with occasional use of Scala. 

Java has a reputation of being clumsy, boring and out-of-date.  That's wrong.  Java has changed the way programming is done, and for the better.  Java has been around a long time, and it's worth looking back to how most programming was done at the time Java appeared.

The most widely used development languages were C and C++, and they were used for all kinds of development projects, from the writing of hardware drivers to office software and databases.  It's possible to program clearly and robustly in C and C++, but it's also very easy to end up making disastrous errors.  The reason why errors are so easy is because C/C++ provides a recipe for pretty much direct use of hardware.  What seems to the programmer to be abstractions are in really nothing more than conveniences of syntax - making raw use of resources look structured.  An example is C arrays:

int store [100];

This looks like an array of 100 integers, but it's not really.  It's simply an area of memory that your program now knows about.  It C it's perfectly acceptable to refer to the 200th element of 'store', and even to write data into it.  C compilers can be set to check for this kind of thing, but that's not part of the language.  Compare this with Pascal

var store: Array 1..100 of Integer;

The compiler and program know what this is: an array of integers.  Try and access store[101] and you will get an error. 

Pascal is C with seatbelts.  It can be much safer because restrictions on what can be done can be designed into the language, and many dangerous operations can be checked at compile time, even though they will also result in safe reporting of a mistake when the program is running (although, to be fair, such checks can be turned off to improve program speed).

C/C++ has been a disaster for software safety and security.  It's use is the primary reason why we suffer from computer viruses and security holes. 

Another real problem with C/C++ is portability.  Compiled programs are almost always limited to one type of computer, and one operating system.  Write a C program for Windows and you aren't going to be able to run it by default on MacOS/X or Linux.   This is a real problem, as there are countless legacy systems written in C/C++ that cannot be moved to modern platforms as it would be too expensive to re-write them.

There were many portable and safe languages around at the time Java was invented - LISP and Smalltalk, for example - but these didn't make an impact on C/C++ development because they were so different in style.  Java copied C/C++ syntax so was relatively easy for developers to pick up. 

Java provided safety, in that it had a carefully managed and garbage-collected memory management, and there were many layers of security built-in, so that use of resources on a machine had to be carefully approved for code that was delivered over the network.  This hasn't always worked, but it's always been far safer than the C/C++ approach. 

But, best of all, Java was extremely portable.  Today, I routinely develop and test Java applications on Windows for deployment on Linux and Solaris, and there are no platform-specific problems.  This has made transition to modern 64-bit machines effortless - I haven't had to do anything but download 64-bit versions of the Java runtime.

When I have worked in a programming team, Java has been extremely useful because of the clarity of the syntax: code is not subject to the obfuscation that can be achieved in C/C++ through the use of macros and operator overloading.  Java syntax may look simplistic, but its explicitness is valuable.

Finally, Java has managed to combine safety with very high performance.  The 'hotspot' automated run-time compiling and tuning technology means that none of the traditional ways of manually optimising code are necessary, and instead developers can concentrate on clarity and functionality. 

Java's compatibility includes the ability to continue to run ancient (in IT terms) code on modern Java runtimes.  Java is one of the safest languages to use if you expect to be supporting an application for a decade or two, without the need to recompile all your applications.

 Java 8 allows for functional programming, increasing the power of Java to make use of parallel processing, with all the automation and safety that is typical of the Java language.

Java may not be the most elegant language, but it's status one of the most widely used (if not the most widely used) language is richly deserved.


Sunday, 13 April 2014

Criticising Islam - do you need to read the Koran?

I'm in an interesting situation.  Two people I respect and admire have dramatically opposing views on the subject of Islam.  My friend Qasim Rachid is a spokesperson for the Ahmadiyya Muslim Community, a large international group of Muslims with humane and secular beliefs.  Then there is Richard Dawkins, who needs no introduction.

They came into conflict last year over whether or not it's reasonable to criticise Islam without having read the Koran.  To summarise, Richard said "yes" (in a typically controversial way), but Qasim said "no".

Both are right.  Let me try and explain why I think this.

The difficulty here is that a religion and the associated culture aren't a single thing; far from it.  A religious culture can be divided into at least three things:

1. The holy books, or doctrines, or scriptures.  These have usually been written some time ago and are generally considered to be the place to look to settle disputes about beliefs or commandments.

2. The culture.  This consists of activities and traditions that have become associated with a religion, such as ceremonies, types of food, codes of dress and so on.

3. The believers.

None of these in isolation define a religion.  A religion is a combination of what certain books say, what believers believe, and what believers do.  These factors can come together in very complex ways.

For example, the doctrines of the Catholic Church are very clear - contraception is forbidden: This is in no doubt.  Yet, in the USA, the overwhelming majority of Catholics are happy to use contraception.  So, the question "What is the Catholic view of contraception?" doesn't have a simple answer, because it depends whose views you are talking about.

So, is it reasonable to criticise Islam without reading the Koran?  That depends entirely on which Islam you are talking about.  If it's Islam 1, the holy books, then it isn't reasonable, because you have no evidence on which to base any criticism.  But, if it's Islam 3, the believers, then it can be reasonable, because the believers can be clear about what Islam means to them, and then you can criticise their Islam.

Religion type 3, the believers' religion, is what actually matters most, because that determines the impact of a religion in society.  In some (but by no means all) Western societies Catholicism's approach to contraception is relatively harmless, as no-one takes much notice.  In those societies Catholicism's approach to contraception isn't something that needs to be urgently addressed.

So, does it make sense to talk about a true version of a religion?  I doubt it, because of this composite nature of religion.  What it is like to be a member of a religion can vary considerably depending on where and when you are a member.  This is why I have a problem with those who insist that moderate or liberal versions of religions 'aren't true' in some way, and uses that to dismiss moderates.  It just doesn't make sense.

This seems to me to raise the question of how relevant it might be to take into account the contents of the books of a religion when discussing the social effects of that religion.

If my believer friends will forgive me for this, I'm going to use an analogy to try and help explain what I mean.  There are rules of the road, which, in the UK, are combined in the "Highway Code".  These explain what a driver is expected to know to be a good and safe driver.  They are the "doctrines" of driving.  Ask almost anyone who drives if they are a good and safe driver, and they will say "yes".  Ask them if they believe in the doctrines of the road, and they follow those doctrines and they will say "yes", but if you watch people drive generally, you will get a different picture.  Just consider the number of people who drive over legal speed limits in the UK - it's vast.  It's likely that the traffic police take this into account, and only prosecute really fast drivers on motorways (not that I am recommending breaking the law!).  And yet, few if any of those people who drive fast will consider themselves lawbreakers.  To them, the speed limit might be "interpreted" as meaning "don't drive too fast".

Two people can say that they follow the law, and they believe in the law, and in their minds they are both right, and yet their behaviour might be very different. If you want to find out what it means to be a driver in the UK, you have to watch the behaviour of drivers.  You won't get what it means to be a driver by reading the Highway Code, at least not by only doing that.

If you want to see what it means to be a believer, you have to watch the behaviour of believers.  You won't get what it means to be a believer by reading only the holy books.  Furthermore, you can't say who is a "true believer" based on those books any more than you can say who is a "true driver" by pointing at the Highway Code.  It doesn't help to point at the words in a holy book and insist that all believers believe that any more than you could point at a speed limit and say that all drivers believe in that.  All you can do is get evidence - observe.

Surely the point of criticising religion politically is to decrease suffering and oppression, and these are reduced when moderate versions of religions replace fundamentalist versions.  This is why I welcome engagement and co-operation with moderate and humane versions of religions, such as Ahmadiyya Islam, because it's vastly better than fundamentalist Islam; and has distinctly positive aspects such as the active promotion of secularism and freedom of belief (including none).

I am a certain atheist - I disagree with the view of reality of Islam, no matter what version, but when it comes to making the world a better place, I have no hesitation in praising the efforts of people such as Qasim Rachid, who is trying to reduce prejudice, suffering and oppression.  To reject his Muslim identity (as Sam Harris seems to have done), to talk about false and true believers, seems to me to be churlish and counter-productive.

However, I also agree, to an extent, with Richard Dawkins - it isn't vital to read the books of a religion to criticise the behaviour of believers.  But I would add this:  reasonable criticism should surely be based on all the evidence, at least all the evidence that is easily available, and both the Bible and Koran are easily available.

Why I support Chris Stedman

(Chris doesn't know I'm writing this - I hope he doesn't mind, and that I get facts right).

I have read something recently criticising Chris Stedman's work, and suggesting it's some sort of giving in to religion.  I really value what Chris does, and I certainly don't see it as giving in.

Chris Stedman is an out gay atheist who works as a humanist chaplain, and on various 'interfaith' projects, which involve people of different faiths (and none) combining their efforts to help mutual understanding and encourage respectful dialogue.

Some see Chris' stance as 'accommodationist': implying that he is conceding factual or moral ground to religious beliefs.  At least according to my understanding, this is not only wrong, but would be counter-productive to Chris' efforts, because what he is trying to do is to help acceptable and understanding of atheists, not the dilution of atheist beliefs.  There is a parallel situation that might help explain this: Chris' efforts also help acceptance of homosexuality, because he is an out gay man, and that acceptance would not be helped at all if Chris said that he "wasn't really very gay".

Talking to and co-operating and befriending religious people doesn't have to be about giving up beliefs or even pretending you have.  It's about not judging others based on labels.  It's about allowing humanity to be more important that doctrine.  In the end, it's about what we want society to be like.  Do we want anger and hate, or do we want civilized argument between people who will actually listen to each other?

Monday, 17 March 2014

The Discovery of Gravitational Waves from the Origin of the Universe

Today's discovery of gravitational waves from the origin of the universe is the most important discovery in science since that of DNA.  I'll try explain why.  But first, I have to admit that I am not an expert physicist.  If you want the technical background go to someone who really knows what is going on, such as Sean Carroll - http://www.preposterousuniverse.com/blog/2014/03/16/gravitational-waves-in-the-cosmic-microwave-background/ I hope Sean writes a book on this, as his ability to explain such complex ideas is exceptional.  However, I'll try and give some idea.

Gravity curves space and time, as revealed by Einstein's work on General Relativity.  The reason why gravity pulls and diverts objects is because of this curvature.  Newton said that unless acted on by a force objects will move in straight lines.  Objects in a gravitational field move in the equivalent of straight lines in curvy space - these lines are called 'geodesics'.  Think of the surface of the Earth - the most direct route between two points at different longitudes away from the equator is not a straight line, but a curve called a 'great circle'.  'Great circles' are geodesics.  Following these 'curvy straight lines' is why objects are diverted by gravity.

As well as describing this curvature of space, Einstein also showed that changes in gravity travel at the speed of light, not instantly.  If the Sun vanished, it would take 8 minutes for the Earth to start to leave orbit, for example.

If you have curvature and that curvature can change, and the change has a speed limit, then you can get waves.  Suppose the gravity of the Sun could be turned on and off.  If this happened then pulses of gravity would travel out from the Sun's position.  If you have two objects orbiting each other, the constant change in position of the sources of gravity results in waves.

We know that gravitational waves exist because waves carry away energy and we can predict how quickly this will happen.  When the objects orbiting each other are very dense indeed, like neutron stars, then they will lose a lot of gravitational energy as waves, and their orbits will decay, and we have seen this happen.

Gravitational waves in the cosmic microwave background are such an amazing discovery because the cosmic microwave background is a microscope.  The microwave background is the light released when the universe first became transparent, when electrons stopped flying around and joined up with atomic nuclei.  This happened about 379,000 years after the origin of the universe.  The microwave background is extremely smooth, which is strange because the expansion of the universe is so fast that widely separated areas of the background can never have come into contact, to smooth out any differences.  So why is it so smooth?  One answer is inflation - the idea that the region of the universe that we can see started off extremely small and so was in contact, and then expanded incredibly fast, smoothing out any differences.  This expansion was so great that tiny quantum fluctuations became big enough to create the unevenness needed to allow gravity to collect gas together to build galaxies. Subtle fluctuations in the microwave background reveal what went on at a quantum scale.   So, gravitational wave effects in the microwave background show us ripples in gravity at a quantum scale, and the only way we can think of that these ripples have become big enough for us to see is if the ripples were blown up enormously because of inflation.

The cosmic microwaves take us back to hundreds of thousands of years after the origin.  We can see no further back because before that the universe wasn't transparent to light.  But, just about everything is transparent to gravity and gravitational waves.  When we see the gravitational waves we are looking back to the instant when our universe began, perhaps around the Planck time: 10-44 seconds - probably the shortest time that makes sense in our universe.  This not only confirms the idea of inflation, but it should allow us to get some idea of what happened at the very beginning of the timeline of our universe.

Thursday, 6 March 2014

The case for religious same-sex marriage

I'm not one of those who say that religion cannot do good.  In the UK there is a history of churches working to help the poor and oppressed, forming and supporting communities that were of benefit to those included.  But now mainstream faiths are stuck in a reactionary rut when it comes to equality, and their resistance to moral progress results in real suffering, suffering that can and should be avoided.

The matter of equality I am talking about here is homosexuality: sexual attraction and love between two consenting adults of the same sex.

Love and sexuality is a core part of the lives of most people.  Their romantic and sexual relationships help define who they are and form an important way that they bond with others in society.   Rejection of the validity of same-sex relationships is a strong factor in excluding people from participating in the rituals and institutions that, for most people, help them to be accepted as full and equal members of society.

The refusal to allow same-sex religious marriage denies many people the right to fully engage with their religious beliefs.  Some may share the belief that the appropriate place for sexual activity is between loving couples within marriage, but the denial of marriage for such people forces them to choose between celibacy and what they consider to be sinful fornication - a choice that heterosexuals don't have to make.  And so, homosexual believers are not only labelled as sexually disabled by their religions but also told that the only sexual relationships they could ever have is sinful.

Just imagine what this can do to youngsters.  Those entering the confusing time of puberty and with their first feelings of love and desire are being told by their religious culture that they are lesser people, that they haven't grown up fully in the way that God wants, that their loves can never be blessed, that their sexuality is forever sinful.  This can do great psychological harm both directly and indirectly, because being labelled as inferior by their culture makes such youngsters easy targets for bullies.  Bullying of homosexual youngsters happens on an epidemic scale in the UK, and associated with that bully are both depression and suicides.  Religions should not be providing the basis for bullying and misery of youngsters.  They should be preaching virtues, the virtues of love and equality, and they should be preaching against prejudice with all their power.

Religions can claim the inferiority of same-sex relationships in many ways.  One of those is naturalness, and yet homosexuality is widespread in nature, just like heterosexuality.  But then so is killing and suffering.  Naturalness should never be a criterion for what is good, and moral.  Another way is based on Bible texts, but that has no solid foundation as modern Christianity rejects much that is in the Bible as outdated and irrelevant.  Yet another way is to point out that homosexuality cannot give rise to children, and yet there are no fertility tests necessary for heterosexual weddings, and many couples are married when their is no possibility of children being produced.  Same-sex couples are said by some to be inappropriate situations for children to be raised, even if acquired by adoption.  The evidence is against this, but, anyway, the question of adoption is not relevant to the question of marriage.

Christians should consider the words of Jesus: "Let the little children come to me, and do not hinder them, for the kingdom of God belongs to such as these."  Don't hold back youngsters from Jesus (or Mohammed, or the Buddha) because of who they will love and desire.  Let them know that they are fully loved in all respects, and the Church will, if they want it, provide the same foundation for their loving sexual relationships as it does for those who love the opposite sex.  

In the play "8", a dramatisation of the fight for equality against California's Proposition 8, a mother points out that little girls don't dream of civil partnerships.  They don't - they dream of marriage, with all its ceremony and its acceptance.  Let their dreams not be in vain.  Let couples who love each other share fully in your culture whatever that culture may be.