Tales from the Evil Empire

Bertrand Le Roy's blog


Bertrand Le Roy

BoudinFatal's Gamercard

Tales from the Evil Empire - Blogged

Blogs I read

My other stuff


August 2009 - Posts

querySelectorAll on old IE versions: something that doesn’t work

(c) Bertrand Le Roy 2005 In today’s post, I’m going to show an interesting technique to solve a problem and then I will tear it to pieces and explain why it is actually useless. I believe that negative results should also be published so that we can save other people from wasting time trying the same thing. So here goes…

A few days ago, a post on Ajaxian proposed a new version of a somewhat old technique to implement querySelectorAll on old versions of IE, using the browser’s native CSS engine. That sounds like a great idea at first, and the hack is quite clever. The idea is to dynamically add a CSS rule to the document that has the selector that you want to evaluate, and an expression that adds the matched elements to a global array.

When I read this, it reminded me of a similar approach that I had tried a few years ago. At the time, we were considering implementing our own selector engine (we had not yet decided to integrate jQuery to our Ajax offerings, which in the end made the whole effort moot) so we explored a number of approaches.

My idea was different in that it doesn’t use expressions at all. It does dynamically create a style rule, but instead of an expression, it just sets a non-existing “foo” style property to the equally arbitrary value of “bar”. It then scans the whole document (using the much decried and IE-specific but very fast document.all) and gets the computed style for each of the elements. We then look for the foo property on the resulting object and check whether it evaluates as “bar”. For each element that matches, we add to an array.

Here’s the code:

(function() {
    var style = document.styleSheets[0] ||
document.createStyleSheet(); window.select = function(selector) { style.addRule(selector, "foo:bar"); var all = document.all, resultSet = []; for (var i = 0, l = all.length; i < l; i++) { if (all[i].currentStyle.foo === "bar") { resultSet[resultSet.length] = all[i]; } } style.removeRule(0); return resultSet; } })();

or, in minimized form:

(function(){var d=document;var a=d.styleSheets[0]||
a.addRule(e,"f:b");var l=d.all,c=[];
for(var b=0,f=l.length;b<f;b++)if(l[b].currentStyle.f)
c[c.length]=l[b];a.removeRule(0);return c}})()

That’s 235 characters, which is not too bad (although not quite #twitcode small).

The first problem with that approach though is that because it’s using the native CSS selection engine in IE, it has the same limitations and quirks. That means no fancy CSS 3 (or even 2) selectors. It also means any IE bug will surface into the result set.

In other words, if you want more selectors than that, you will need to parse the selector string and branch off the code to another, more complete engine whenever something not supported is used. It also means that you need to know what is supported and what isn’t. That could be done through some dynamic discovery but doing so, we are getting into much complexity.

So limited as it is, how does it perform?

I ran the code in a SlickSpeed test (where I removed the selectors that it couldn’t handle) on IE6 and the good news is that despite the document.all scan and the current style computation, it’s more than three times faster than Paul Young’s implementation that got featured on Ajaxian.

But the bad news is that it’s also six times slower than jQuery:SlickSpeedResults

I’m afraid a hack to use the native CSS selection engine of the browser is always going to be slower than an optimized pure JavaScript implementation (to be clear, I’m not talking about native implementations of querySelectorAll, but about hacks such as this which try to surface the feature on older IE versions that don’t have querySelectorAll). Somewhat counter-intuitive, but true.

End of story. Just use jQuery. :)

How to install and configure Visual Studio Team Explorer

One of the challenging aspects of working with TFS as your source control system is very unfortunately the installation of the client software.

Over the past few years, I’ve been managing a number of small and large projects on CodePlex, and while the Subversion bridge has provided a much needed simple choice of client software, TFS remains its native protocol, which makes it still very much relevant to people who do a lot of work there.

But as I said, installing the client software may be challenging.

The first and main problem here is that Team Explorer, while free, comes in a very unfriendly format: an ISO image of the DVD. I asked the team why they made that weird and less than optimal choice, and apparently there are some technical reasons why a simple msi wouldn’t work. I wasn’t completely satisfied with the explanation (it’s still a bad customer experience) but at least there is hope as the plan is to make it a lot smoother with Visual Studio 2010.

So let’s download that thing. It can be found here:


Just click on the “Download” button and store the file in a local temporary folder. At 387.4 MB it’s a pretty big download (especially when compared with this) but it does contain the Visual Studio shell, which explains it, kind of. So you probably have time for a cup of coffee or two, trip to Seattle’s Best included.

Oh, by the way, to be clear, you do *not* need a version of Visual Studio on the box to install Team Explorer, it is a standalone application, but if you do have one, it will integrate with it.

Now that you have the IMG file, we can extract it. There are several options to extract or burn an ISO, but I’ll use a free one here. We won’t burn the image to a DVD (the only reason I could see why you’d want to do that is if you want to make multiple installs, but you might as well extract the ISO to a network share).

The free option I’ve selected is ExtractNow, which you can download from here:


Click on the “Download ExtractNow!” link on the bottom of the page and run the installer. When it asks you if you want to run it, say yes. The UI is a little weird: what you need to do now is right click on the white surface on the ExtractNow window and select “Add archive”:ExtractNow Add ArchiveThen, navigate to wherever you downloaded the VS2008TeamExplorer.iso file, select it and click the “Open” button. Now click the “Extract” button and wait for the extraction to complete. You should now have a VS2008TeamExplorer folder next to the iso file. You can close ExtractNow and maybe even uninstall it until the next time you need it…

Open that folder and double-click “Setup”. Follow the instructions (the default settings should be fine) and wait for the install to complete. Fortunately, it doesn’t take nearly as long as installing the full VS.

Once this is done, you should be up and running. Let’s launch the shell and connect to a CodePlex project. From the Team Explorer window, click the “Add existing team project button:Team Explorer Add Existing Project

Click on the “Servers” button and then on the “Add” button to add the relevant CodePlex server. The data that you need to enter there can be found on the “Source Code” tab of your project’s site on CodePlex by clicking on Source Control Setup / Visual Studio Team Explorer (right side of the page).CodePlex Project Setup

You can copy the server, port and protocol information into the Team Explorer add server window:Team Explorer Add Server

You can now close that window by clicking OK. You will then get prompted for your username and password. CodePlex also gave you that (notice the “snd\” domain prefix and “_cp” postfix) but let’s make sure that we only have to do this once. To that effect, let’s cancel and go to the Windows user account control panel and click on “Manage your credentials”:User Account Control Panel

Then click on “Add a Windows Credential”. Copy there the server name, your username and your password:Windows New Credentials

Click OK, then switch back to Visual Studio and click OK again. This time, you shouldn’t be prompted for credentials unless you made a typo in the above dialog. You may now click close and then select any number of projects you want to work with:TFS Select Projects

The team explorer window now shows the available projects:Team Explorer Window

If you then double-click “Source Control” under any of the projects, you can explore the contents of the project and map them to a local folder. To do that, first create the target directory from Windows Explorer, then right click a project in the Visual Studio Source Control Explorer and select “Get Latest Version”:Getting Latest Version

You will then be prompted for a local directory to which you want to map the source-controlled remote directory. Select the directory that you just created and click OK.

And… that’s it, you’re all set. You can now open any file or project from the locally mapped folder, check out code, modify it and then check it back in using the Pending Changes window.

I hope this helps.

Walking the tight rope

(c) Bertrand Le Roy 2004 I think today is an appropriate time to write this post, as Rob Conery is leaving Microsoft tomorrow. “Who?”, you might ask. Rob is the author of the excellent MVC Storefront and Kona series where he explored the challenges in building an MVC-bound storefront application. I’ve been working with Rob for a few months on the continuation of that, which will be the subject of this post.

This is challenging for a number of reasons.

First, Rob’s are large shoes to fill (he’s a 12, I’m an 11). That’s fine, I’m just going to do things my way and try to have as much fun as possible (and communicate that if I can).

Second, the focus of the application has changed and that is a much more important challenge. Rob built this as a learning tool, as much for him as for his readers.

In the team that I’m now a part of, we have taken that Kona code as the basis to build something that will hopefully be more like a real world application. We are still very much in an exploratory mode (hence our attempts at migrating the application to NHibernate and SQLite) but our ultimate goal is to provide an application that people can download and build a business on, with a focus on simplicity and extensibility.

Fine, you may say, but why build something new instead of contributing to existing applications? Well, the very short answer is that we are also going to do that. One of the things we are already doing is to work with various application developers on reusing things like the plug-in engine and what sharing opportunities that brings.

But I can already hear some of you saying “oh so you’re not just building an application, what you’re really doing is building yet another framework”. To which I’m tempted to answer with another question: what do you mean “another”? Where is my Django-style application-level framework for ASP.NET? But that may sound like I’m downplaying the great efforts that many people are putting towards exactly that. I clearly am not. Actually, if you are working on something like that and we’re not already talking, I would love to know about it. I want to know how we can help.

A total n00b’s guide to migrating from a custom data layer to Nhibernate: so many choices

(c) Bertrand Le Roy 2005 One of the great things about NHibernate is its vibrant community and ecosystem. So many people are using it or building other libraries on top of it that you can be pretty sure that there is always a reasonable solution to any problem you might face. Or several.

This means of course that there are lots of choices you can make about how you use NHibernate. While this is essentially a good thing, too many choices can be intimidating when starting to use a technology.

In this post, I’ll present some of the first choices you are going to have to make for your NHibernate code. I’ll explain the choices that our team made for our own migration and an attempt at explaining why you would make different choices depending on the particular context of your application.

1. Database first or object first?

That’s an easy one.

If you already have a database, it’s database first.

If you already have both, all you have to do is build the mappings.

If you already have an object model, it depends how much you care about the shape of your database. NHibernate has reasonable defaults so you might be able to get away with object first and reasonably fuzzy mappings (or even a generated mapping). The obvious advantage of that approach is that you’ll be able to easily move database engines without having to rewrite anything but your web.config.

If you need more control over the shape of the database, you might be able to achieve just that by making your mappings more explicit but still keep generation of the database from NHibernate.

If that’s still not enough control, just don’t generate the database, and instead manually maintain database, objects and mappings.

In our own project, we had the database already, but we want to abstract ourselves of a particular engine eventually, so we are moving from a database first approach to an object first approach. Extensions to the application will have to work independently of the database engine (because the app itself is), so it will have to be object first for them.

2. To lazy-load or not to lazy-load?

Lazy loading is the practice of delaying the loading of an object until the moment when it is actually used for the first time. If you have a collection of blog post objects for example, and those objects each have a property that is their collection of comments, you won’t want those comments to be queried from the database unless you are actually going to use them.

Lazy loading is obviously a good thing, but you also must know that it can get you in trouble. So it can be a dangerous tool, but its usefulness far outweighs the danger.

I’ve also mentioned in the previous post that lazy loading requires the use of dynamic proxies and that these in turn require that you run in higher trust than medium. Well, several commenters pointed out that this isn’t exactly true.

Lazy loading of collection properties does not require the generation of dynamic proxies at all because NHibernate can set the value of those properties directly to a list type that already implements lazy loading. It is only in the case of lazy loading of properties or 1-1 associations that the proxy generation will be necessary. In other words, if your database schema only has 1-N and N-N associations or if you don’t mind eager loading on your 1-1’s, NHibernate can run in medium trust with no problem. This is the approach we are currently using in our application. We will revise it if necessary.

The first way to achieve medium trust lazy-loading is to generate the proxies at build-time instead of dynamically at runtime. Caveat with this approach is that the generated proxies will be specialized to a dialect, which might or might not be a problem. You may be able to mitigate that problem by building dialect-specific versions for all databases that you target, but this is definitely less convenient than the entirely dynamic approach.

The second approach is to fix the code of the proxy factory that you are using to work in medium trust, which is entirely achievable but clearly not for n00bs. Apparently patches are on their way here and this could make the whole problem go away in the near future.

And the last and lamest approach is to disable lazy loading entirely.

3. What dynamic proxy factory to use?

Once you’ve decided that you’re going to use lazy loading and are going to need dynamic proxies, you still have to decide which proxy factory you’re going to use. Three choices are available out of the box: Castle, LinFu and Spring.

If you want to work with Castle.ActiveRecord or Castle.Windsor, Castle is the obvious choice.

If you want to work with Spring, Spring is obviously what you should use.

If you are not using Castle or Spring, or have no idea what you want, LinFu can be a reasonable default.

In our application, because we don’t need dynamic proxies for the moment, we haven’t had to choose.

3. XML, attributes or fluent mappings?


XML mappings are the default but some people dislike XML’s verbosity. There is also a fair amount of repetition and magic strings involved. Refactoring won’t propagate automatically to the mapping files. Advantages include that it’s the most mature approach and that it doesn’t require any additional dependency.

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
    namespace="Nhib.Models" assembly="Nhib">

  <class name="Product" table="Products">
    <id name="SKU">
      <generator class="uuid.hex" />
    <property name="ProductName"/>
    <property name="BasePrice" />


It is possible to use attributes through Castle to specify the mappings instead. This is very easy, involves minimal repetition and a less magic strings than XML. On the other hand, doing the mapping on the objects themselves means less separation of concerns as the objects and the mappings are in the same place. It also means buying into the whole active record approach and giving up POCOs.

public class Product : ActiveRecordBase {
    public string SKU { get; set; }
    public string ProductName { get; set; }
    public double Price { get; set; }
Update: Gauthier Segay pointed out that it's not exactly true that you have buy into the whole Castle active record approach. More info here: 



Finally, the favorite approach du jour is Fluent NHibernate. That approach still keeps mappings nicely separated but has several other advantages.

First, it’s code, which opens up a lot of dynamic scenarios.

Second, it’s strongly-typed. That means that refactoring will work, that you will get compile-time checks and IntelliSense.

Third, it uses Lambdas and a fluent interface, and those are so cute… On the other hand, if you find those alien, it might not be such a win. On the other other hand, it’s a good occasion to learn something new and cool.

public class ProductMap : ClassMap<Product> {
    public ProductMap() {
        Id(p => p.SKU).GeneratedBy.UuidHex("B");
        Map(p => p.ProductName);
        Map(p => p.Price);

In our application, we have chosen XML mappings for now to minimize the number of dependencies and because choosing the most mature approach also means learning is more incremental. We might revise that decision if and when the disadvantages become too much of a problem and as we learn more.

4. HQL, criteria, lambdas, ActiveRecord or Linq?


HQL is the Hibernate Query Language and is the default way of querying in NHibernate. It works and is mature but it is a text format, which means no static verification, refactoring or IntelliSense.

“select p from Product as p where p.ProductName like 'boot%'”

There are a few alternatives to HQL though. Let’s first talk about native SQL. It is possible to send native SQL from NHibernate but you should really only do that if you need to use a specific native feature of your database. While the possibility exists, it is not a relevant choice here.


The NHibernate session object has a CreateCriteria method that exposes a fluent querying interface. You can use it with expressions, but this is deprecated, or you can use it with restrictions, which are very similar but more current.

.Add(Restrictions.Like("ProductName", "boot%");

This API tends to be relatively verbose and is not completely strongly typed but it may be more appropriate than HQL for simple queries.


The nhlambdaextensions project provides a strongly-typed alternative to the restrictions described above through the use of Lambda expressions. This is a strong choice that comes close to Linq but it does require yet another dependency.

.Add<Product>(p =>

If you chose to use Castle ActiveRecord, you can still query using HQL, but you also get basic repository-like operations directly on your data classes out of the box.

FindAll(typeof(Product), Restrictions.Like("ProductName", "boot%"));

Finally, you can use an implementation of Linq to query NHibernate. This is Linq, for NHibernate. In other words, pure, distilled WIN: strong typing, compile-time checks, etc. The problem is that it is still a work in progress (and an additional dependency).

from product in session.Linq<Product>()
    where product.startsWith("boot",
StringComparison.CurrentCultureIgnoreCase) select product;

Linq to NHibernate can be obtained from NHibernate Contrib or as part of Fluent NHibernate.

For the moment, our application uses CreateCriteria with restrictions for simple queries, and HQL in places. Again, the motivation here is to minimize the dependencies.


I hope this post will be helpful for NHibernate beginners such as myself to make the right first choices.

Next time, we’ll really start digging into our transition from our old custom data layer.

A total n00b’s guide to migrating from a custom data layer to Nhibernate: getting started

(c) Bertrand Le Roy 2003(Screencast can be found at the end of the post)

To be clear when I say “total n00b”, I’m not talking about you, dear reader, I’m talking about me. The last time I wrote any serious data access code was circa 2002. Since then, I got hired by the Evil Empire and started developing new tools to make it easier to build demos of Northwind master-details. I jest, I jest. Or do I?

So let me explain what I’m going to talk about in this and future related blog posts. We have this e-commerce application that Rob started and that we’re going to continue developing. Last time Rob touched the data access, he wanted to experiment with going back to less abstraction and to working directly with that interesting data-centric Domain Specific Language, you know, SQL. So he went ahead and played with that T4-driven DAL generator. It was interesting as an experiment, and Rob’s blog series is all about experimenting publicly, but let’s face it, that data access didn’t fly much farther than that. To be clear, I’m not saying that Rob was to blame for our sucky data access layer, but the truth is that we have had this franken-DAL from the nineties in the code for a few months now and it needs replacing. So what do we do?

First, we look around and find out what other people out there are doing. We could go for the Microsoft flavor of ORM, EF, but we’re not going to do that (at least not yet) and will instead go for the one that is the most widely used by the community as of today, and that is, I believe, NHibernate. The home page for the project itself can be found at http://nhforge.org and the best place to get started is probably the tutorial section of that site: http://nhforge.org/doc/nh/en/index.html#quickstart.

In this first post, I’ll just play with the library and try to get a list of products to display on a page. In future posts, I’ll look at the actual app and start migrating it. For this time, because I’m just trying to get to grips with a library I don’t know, it’s going to be quick and it’s going to be dirty. Definitely don’t take any of what you are about to see as best practices. Ever.

The first step is to add the NHibernate and dependencies to the project. The library can be downloaded from SourceForge (http://sourceforge.net/projects/nhibernate). Nhibernate is itself under LGPL but it comes with the following dependencies:

You may not care too much about that, but your boss and his lawyer might… Technically, all you need to add to the project is a reference to the NHibernate dll and the others will follow.

Once the reference has been added to our project, we can start configuring. This can be done in a variety of manners but the easiest is to do it through web.config. The basic configuration for NHibernate consists in the connection string, the SQL dialect and the proxy factory to use. Because we don’t want to repeat ourselves and because I prefer my connection strings to live in the connection strings section of web.config, I’ll use a “connection.connection_string_name” setting instead of a “connection.connection_string” setting:

<hibernate-configuration xmlns="urn:nhibernate-configuration-2.2">
    <property name="connection.connection_string_name">
</property> <property name="dialect">
</property> <property name="proxyfactory.factory_class">
</property> </session-factory> </hibernate-configuration>

The proxy factory factory class stuff looks a little intimidating and a little over-architected from just looking at it (a factory factory? To create proxies?) but it’s not as bad as it looks. What this is doing is declaring what library to use to generate dynamic proxies for our data classes. It is a good thing that NHibernate is open to multiple providers here, and the good news is this is probably the first and last time you need to know about this. Just make a choice if you care (and know why you care), or use this one (licensed under LGPL) if you don’t.

But what is a dynamic proxy, you may ask? First and foremost, it is a proxy class that will be used in place of the POCO class that you will provide to represent your data. Its purpose is to intercept all calls into the object’s properties, both getters and setters, and to handle things like lazy loading. The dynamic aspect of it is that those proxy classes are dynamically generated, usually using Reflection.Emit. This means that until .NET 4.0 is here, using lazy loading in NHibernate will prevent the application from running in medium trust. More on that in future posts, but know that lazy loading is not mandatory and can easily be disabled from the mapping file.

The next thing to do is to grab the NHibernate configuration in order to create a session out of it. The configuration can be built from the web.config data like this:

var nhconfig = new NHibernate.Cfg.Configuration().Configure();

A session is the mediator between your code and Nhibernate. According to the documentation, it is a “short-lived object representing a conversation between the application and the persistent store”. Its lifetime is usually the same as the lifetime of the request. Here’s how you can create a session:

var session = nhconfig.BuildSessionFactory().OpenSession();

With all that we are pretty much set-up but we are still lacking any data. Let’s fix that and attempt our first mapping. I’m going to use a simplified version of the product database we have in the commerce app (which is none other than AdventureWorks). In there, I have a Products table that looks like this:

Products Table

We don’t have to map everything in that table so we won’t (yet). Instead, we’ll create a simple and incomplete class to represent a product:

public class Product {
    public virtual string Sku { get; set; }
    public virtual Guid SiteID { get; set; }
    public virtual string Name { get; set; }
    public virtual double BasePrice { get; set; }

Notice how all fields are virtual here. This, again, is done so that a dynamic proxy class that overrides those properties can be created.

Now we have the O (object) and the R (relational), so let’s do the M. The mapping is an XML file that we’ll put next to our Product class:

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
    namespace="Nhib.Models" assembly="Nhib">

  <class name="Product" table="Products">
    <id name="Sku">
      <column name="SKU" sql-type="nvarchar(50)" not-null="true"/>
      <generator class="uuid.hex" />

    <property name="SiteID"/>
    <property name="Name">
      <column name="ProductName"/>
    <property name="BasePrice" />


The mapping class is named like the Product class, with a “.hbm.xml” extension. It is also configured to build as an embedded resource so that Hibernate can reflect on it at runtime. This is done by setting the Build Action in the properties of the file in Project Explorer:


And we’re done as far as setup is concerned. Now all that remains to do is to actually query and display that data.

Because I’m just playing with the framework at this point, I’ll just query from the Index controller action:

var nhconfig = new NHibernate.Cfg.Configuration().Configure();
using (var session = nhconfig.BuildSessionFactory().OpenSession()) {
    var query = session.CreateQuery("select p from Product as p");
    ViewData.Model = query.List<Product>();

UPDATE: Ayende is right to attract my attention to the fact that building a session factory is an expensive operation and so you should treat it as a singleton. In other words, create the factory once and store it in a static variable. For the sake of the simplicity of the example, I'm leaving the code above, but again, don't do this at home... 

And finally, let’s render this from the view:

<% foreach (var p in Model) { %>
    <li><%= Html.Encode(p.Name) %> - $<%= p.BasePrice %></li>
<% } %>

The results look like this:

Product rendering


I hope this gives a good idea of how simple it is to get started with NHibernate, because it really is. I knew near to nothing about it and almost didn’t have to fight the framework to get it running. Seeing the first successful rendering on my very first CTRL+F5 was very encouraging.

In a future post, I’ll show how this applies to a real-world application and how we migrated such an application from its existing data layer to one that uses NHibernate.

The source code can be downloaded from here: NHibGettingStarted.zip (warning: all files provided under their respective licenses).

… and here’s the screencast:

The symmetrical universe

(c) Bertrand Le Roy 2005 Warning: this post is devoid of contents.

During one of the very first classes of my Bachelor of Science in Physics, I got struck with a particular piece of information that sounded like a revelation to me:

If a problem exhibits a certain symmetry, the solutions to this problem do not necessarily exhibit that same symmetry, but the set of solutions always does.

The example my professor was using to illustrate this is the following. Imagine you have the four summits of a square and you want to find how to connect each point to all of the others using lines, but the total length of those lines must be as small as possible.

The problem itself has mirror symmetry, central symmetry and rotational symmetry with an angle of 90 degrees. In other words, the four summits are perfectly equivalent and can be exchanged without changing the problem in any way.

Now here’s the weird thing. There are two solutions, which are themselves less symmetrical than the problem itself and that look something like this:How to minimally connect the summits of a square

Notice how rotating any one of those by an angle of 90 degrees doesn’t keep it unchanged, but instead gives the other solution. In other words the set of solutions (those two solutions together) has exactly the same symmetries as the problem itself although each one of them separately doesn’t.

This is more far reaching than it seems and is nothing else than the phenomenon called spontaneous symmetry breaking that has been keeping a good number of physicists busy during the 20th century and the beginning of the 21st. Because there is only one universe that we can observe, whenever a physical process has the same characteristics as the above problem, the physical world has to choose one of the solutions and “break” the symmetry of the problem.

Now in any physical process, the experimental conditions are never perfect and small perturbations are likely to push the system to this or that particular solution so there is nothing super-weird about what’s happening here.

But there are phenomena where an external nudge to the system can’t explain the symmetry breaking: the ones that are at the origin of the universe. Cosmologists are actually still debating explanations to why the universe is so dissymmetrical (the arrow of time, the four fundamental forces, the inhomogeneity of matter, etc.) whereas the equations that seem to describe it are so symmetrical.

Many plausible explanations do exist, such as that our observable universe is part of a bigger “multiverse”. The weaker versions of this idea still consider a connected symmetrical universe that is one big multidimensional space-time continuum with different local regions where symmetry is broken in all possible ways. But why do we need the connectedness at all? Is it even an option? If you look at the square problem above, those two solutions are entirely disconnected and you couldn’t find a connected symmetrical solution if you tried. Why would the multiverse then need to be connected?

This leads us to the strongest version of the multiverse concept, the Mathematical Universe Hypothesis. The idea behind this is to attribute reality to all mathematical structures and to postulate that our observable universe is just one of this infinite number of structures (in an interesting case of taking the map for the territory).

Mathematical structures have this interesting property that they exist independently of culture, the human mind and even physics. Group theory for example could be discovered in any universe and would yield the exact same list of finite groups. In other words, they have lots of the qualities we associate with the reality of our own physical universe. Going from that to the idea that our physical world is just emerging from that primordial mathematical soup is quite tempting.

Now of course, it has been objected that such an idea is not testable or falsifiable and thus cannot be called scientific. That is absolutely true. But it does have that Occam’s razor quality of simplifying some of the apparent complexity of our universe. It also has the advantage of being an entirely naturalistic hypothesis to the origin of the universe if you’re into that sort of thing.

All this to give you an idea of the rush of ideas that went through my 20 year old brain at the precise moment when that professor showed us those two simple diagrams that you see above, oblivious at the time that those ideas that seemed so new and original to me had actually already been invented and debated a couple of years earlier. I felt at this instant the raw explanatory power of science and also its ability to extend its influence way beyond its self-imposed limits of testability. It is without a doubt the most powerful instrument of thinking and the best catalyst of ideas that the human mind has invented.

More Posts