What is wrong with UUIDs and GUIDs

Introduction

Universally Unique Identifiers (UUIDs) otherwise known as Globally Unique Identifiers (GUIDs) are 128-bit numbers that are often used to identify information. In its canonical representation, a UUID looks like this: 2205cf3e-139c-4abc-be2d-e29b692934b0.

The Wikipedia entry for Universally Unique Identifier (⬀) says that they are for practical purposes unique and that while the probability that a UUID will be duplicated is not zero, it is so close to zero as to be negligible. Wikipedia then does the math and shows that if 103 trillion UUIDs are generated, the chance of duplication among them is one in a billion.

Despite the infinitesimally small chances of receiving a duplicate UUID, there exist programmers out there who are afraid of this actually happening, and who will not hesitate to suspect duplicate UUIDs as being responsible for an observed malfunction rather than first look for a bug in their code. Clearly, these folks do not understand the meaning of infinitesimally small chance, so let me try to explain it:

Infinitessimally small chance means practically impossible to happen, and the practically part is only mentioned for scientific correctness: practically, you can disregard the word practically and consider it as simply impossible to happen.

Great. Now, let me tell you why I hate UUIDs.

On scripting languages

Foreword

Historically, the difference between scripting languages and real programming languages has been understood as the presence or absence of a compilation step. However, in recent decades the distinction has blurred; from time to time we have seen:

• Interpreters for languages that were originally meant to be compiled.
• Compilers for languages that were originally meant to be interpreted.
• Scripting engines internally converting source code to bytecode before interpreting it.
• Real languages compiling to bytecode which is then mostly interpreted and rarely converted to machine code.

So, compiled vs. interpreted does not seem to be the real differentiating factor; nonetheless, we can usually tell a scripting language when we see one. So, what is it that we see?

Mandatory disposal vs. the "Dispose-disposing" abomination

This article started as a stackoverflow answer, and then I copied it over here to expand on it.

For a discussion of the same issue but in java-oriented terms, see this stackoverflow answer of mine: Is overriding Object.finalize() really bad? http://programmers.stackexchange.com/a/288724/41811

There is this practice which is unfortunately very prevalent in the C# world, of implementing object disposal using the ugly, clunky, inelegant, ill-conceived, and error prone idiom known as IDisposable-disposing. MSDN describes it in length, and lots of people swear by it, follow it religiously, write walls of text discussing precisely how it should be done and precisely how it works, and precisely how they arrived at this particular way of doing it, etc.

(Please note that what I am calling ugly here is not the object disposal pattern itself; what I am calling ugly is the particular idiom of implementing an extra Dispose method with a bool disposing parameter.)

This idiom was invented under the assumption that the invocation of IDisposable.Dispose() is something optional, or in any case something which might be OK to forget, in combination with the fact that it is impossible to guarantee that our objects' destructor will always be invoked by the garbage collector to clean up resources.  So, people tend to make their best effort to invoke their IDisposable.Dispose() methods, and in case they forget, they also give it one more try from within the destructor. You know, just in case.

Assertions and Testing

So, since we do software testing, we should quit placing assert statements in production code, right? Let me count the ways in which this is wrong:

(TL;DR: skip to the paragraph containing a red sentence and read only that.)

1. Assertions are optional.

Each programming language has its own mechanism for enabling or disabling assertions. In languages like C++ and C# there is a distinction between a release build and a debug build, and assertions are generally only enabled in the debug build. Java has a simpler mechanism: there is only one build, but assertions do not execute unless the -enableassertions (-ea for short) option is specified in the command line which started the virtual machine. Therefore, if someone absolutely cannot stand the idea that assertions may be executing in a production environment, they can simply refrain from supplying the -ea option; problem solved.

Benchmarking code written in Java or C# (or any GCed, JITted, VM-based language)

Sometimes we need to measure the time it takes for various pieces of code to execute in order to determine whether a certain construct takes significantly less time to execute than another. It sounds like a pretty simple task, but anyone who has ever attempted to do it knows that simplistic approaches are highly inaccurate, and achieving any accuracy at all is not trivial.

Back in the days of C and MS-DOS things were pretty straightforward: you would read the value of the system clock, run your code, read the value of the clock again, subtract the two, and that was how much time it took to run your code. The rather coarse resolution of the system clock would skew things a bit, so one trick you would at the very least employ was to loop waiting for the value of the system clock to change, then start running your code, and stop running at another transition of the value of the system clock. Another popular hack was to run benchmarks with interrupts disabled. Yes, back in those days the entire machine was yours, so you could actually do such a thing.

Nowadays, things are far more complicated. For one thing, the entire machine tends to never be yours, so you cannot disable interrupts. Other threads will pre-empt your thread, and there is nothing you can do about it, you just have to accept some inaccuracy from it. Luckily, with modern multi-core CPUs this is not so much an issue as it used to be, but in modern VM-based languages like Java and C# we have additional and far more severe inaccuracies introduced by the garbage collection and the jitting. Luckily, their impact can be reduced.

In order to avoid inaccuracies due to jitting, we always perform one run of the code under measurement before the measurements begin. This gives the JIT compiler a chance to do its job, so it will not be getting in the way later, during the actual benchmark.

Intertwine: Normalizing Interface Invocations

This post has been superseded by a new post in 2022
See michael.gr - Intertwine

This is a C# project that I did back in 2011. It consists of a (rather informal) white paper which describes the project, and a zip file containing the source code in the form of a Microsoft Visual Studio solution.

Here is the abstract:

A mechanism is proposed for converting (entwining) method call invocations of any interface to a general purpose single-method normal form, and converting back (untwining) from the normal form to interface invocations, so that operations can be performed on the normal form in a way agnostic to the interface being invoked. The normal form is a delegate in C# or a functional interface in Java, realized as object AnyCall( int selector, object[] parameters ). A DotNet implementation is provided in C#, though the discussion also applies to Java.

And here is the table of contents:

• Abstract (page 1)
• The Problem (page 1)
•  Why messages are bad (page 2)
•  What is missing (page 2)
• The Solution (page 2)
• A hand-crafted solution (page 3)
• Automating with Intertwine (page 6)
• Appendix 1: A note about Dynamic Proxies (page 6)
• Appendix 2: An example: Interface multicasts (events) (page 7)
• Appendix 3: Things to fix (page 8)

Download the white paper: Intertwine v2.1.pdf
Download the source code: Intertwine v2.0.zip