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.

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