In our last substack, we discussed one of modern bartending’s biggest flaws, the recipe. If you missed it and want to catch up you can read the piece here. We suggested that the major shortcomings of the recipe could be solved by applying a concept from computer science - the DSL.
What exactly is a Domain Specific Language - how does it compare to a General Purpose Language? In the words of one of our developers:
A Domain Specific Language is a programming language where you forgo having general capabilities in order to be very good at expressing a smaller set of precise concepts.
Let’s look at its real-world analogue with mixology. Want to make a rum and coke?
Domain-Specific:
Grab a glass.
Fill with ice.
Pour 2 oz of rum.
Top off with coca cola.
General:
Collect the appropriate mols of water and carbon dioxide.
Freeze some of the water into ice.
React some of the water with some of the carbon dioxide to make glucose (if this sounds tedious, it is. Plants do this all day long and they take forever to grow).
Caramelise some of the glucose.
Blend the caramelised glucose into some of the water, and saturate the mixture with the remaining carbon dioxide to make it fizzy. This gives us a rudimentary cola (we could improve it by chasing down some phosphorous for acid, or nitrogen to trial and error Coke’s secret ingredient, but we still have rum to make, so we’ll keep it simple).
Break most of the remaining glucose down into smaller parts called pyruvates, and synthesise them into ethanol. Boil it down to a concentrate with 40% ABV (alcohol percentage by volume), and you will have a pretty gross yet functional rum on your hands (if this sounds tedious, it is. We essentially enslave millions of yeast colonies daily to perform this process for us, before they suicide via denaturation in their own toxic excretions).
The first recipe is preferable for the domain of bartending, and is how most recipes currently appear. Though if you wanted to build a table, a skyscraper, or a sandwich, you would need more options for both materials and functions.
One of the benefits of using a DSL is that it is machine-readable. This will be useful for automating processes and computing data down the line. Computers don’t indulge in frivolity. They don’t do sales or persuasion. They don’t have ego (at least at the time of writing). All they do is manipulate data in deterministic fashion.
If you’ve ever spoken to a cocktail connoisseur you’ll realise the challenge of creating this language. Nevertheless after a few days of deconstruction and first principles thinking we had our Eureka moment.
We applied the model to several recipes and found that it worked. We tested it with some absurd edge cases, and they fit flawlessly! With the core structure designed, we got to work on the variables, and eventually had a functioning model.
Remember the Food Network recipe for the Long Island Iced Tea?
Here’s the BahaBar version.
So far we have managed to distill the entire lexicon of bartending jargon into four objects with ten or so parameters.
Drink: What the bartender makes
Drinks can have ‘n’ number of vessels. Important for ‘bomb’ shots i.e. Sake Bombs, Jagerbombs, or Hand Grenades. Each vessel will have its own sub-recipe, enabling complexity to match even the most daring bartender’s imagination.
Vessel: Glassware used in the drink
Vessels are named uniquely to reflect their style and shape.
Vessels have a size status - denoting capacity and measured in liquid ounces, milliliters, or cubic centimeters.
Vessels have a temperature status - warmed, room, or chilled.
Vessels have an ice status - empty, cubed ice, crushed ice, or (x) ice.
Layer: Discrete layers in the vessel
Each layer has a function applied to it. From basic to most complex - poured, stirred, shaken, blended, heated, (x).
Each layer has a calculable density, which informs the layer’s
Order - lower density layers should float on top of higher density layers.
Ingredient: Combined to make a layer.
Ingredients have ‘Alcohol by volume’ status, or ABV.
Density
Colour
Carbonation
We are currently working to apply this model to a real-world menu. We will assess how it affects training, cocktail quality, and the overall onboarding process for new hires. Our hypothesis is that bartenders will learn recipes faster, and with improved memory retention. We expect they will produce drinks more accurately, consistently, and with greater speed. This will facilitate tighter inventory control and improved customer service.
In part three we will evaluate the results of an experiment with a client - one of the top-rated restaurants in The Bahamas, The Shipyard.
