Please note: This has NOTHING to do with pizza coupons nor discount codes. If you want pizza coupons, click here.
Every now and then, I run across the Geek Code, a compact notation for sharing basic profile and personality information.
I recently ran across this again, while looking for something else, and it inspired me to answer these questions:
- Could you define a compact yet robust notation for ordering a pizza?
- Could you order any pizza within an 80-character text message?
- Could you manage a single order with multiple pizzas within an 80-character text message?
Let’s find out…
Please note: This has NOTHING to do with pizza coupons nor discount codes. If you want pizza coupons, click here.
The Geek Code has been around since 1993, as sort of an underground (“geek”) phenomenon.
It uses a specific syntax consisting of core attribute abbreviations to express various aspects of your profile and personality. Each attribute has a specific set of modifiers to express degree, explicit inclusion, explicit exclusion, or the like.
What’s interesting about the Geek Code is that, as long as we all agree to a specific version, it can convey a tremendous amount of information using very few bytes, because each symbol or group of symbols has a specific predetermined meaning.
Moreover, because the Geek Code is text, you could:
- Add it to your e-mail signature
- Post it on your website
- Text it to someone
- Embed it in a QR code, and print the QR code on your business card
- Add it as an attribute to an X.500 / LDAP server
Anything you can do with text, you can do with the Geek Code.
Here is a very basic, sample Geek Code:
—–BEGIN GEEK CODE BLOCK—–
GAT d+ s+:+ a+
——END GEEK CODE BLOCK——
This tells another geek:
- GAT: Geek of All Trades
- d+ I dress OK
- s+:+ I’m a little tall and a little round
- a+ I’m a little bit older than average
There are many other elements that can be added to your Geek Code, but the problem is that it’s no longer being actively maintained, and many of the categories are somewhat dated (e.g. “I watch X-Files whenever possible”)
So, in all, it’s a great piece of internet history, but maybe not completely relevant today.
2. The Pizza Code
Disclaimer: I did some Googling, and wasn’t able to find anything that resembles what I’m presenting below, but if there is already a “pizza code” out there, I apologize – please contact me and we can collaborate.
Once again, I recently ran across the Geek Code, which happens from time to time.
I thought, “what COULD you do with this kind of notation?” In other words, what could you easily describe with “Geek Notation”, that would be fairly standard and easy to maintain?
My first thought: Pizza!
Excluding vendor-specific specialty pizzas, there are a few simple options.
What could you use this for?
My next thought: If you were REALLY adept at “the pizza code”, could you in theory order one via hand-typed text message?
Text messages are 80 or 160 characters in length (think: 1 or 2 lines of text), and are designed to convey lightweight information. People have already developed many dialects of “text speek”, in order to shorten normal English in to a text-message-friendly format – sometimes, so much so, that text speek is almost unreadable.
English: How are you today?
Text: how r u 2da
So the goal of this project is to develop a standardized, compact, pizza notation that one could theoretically use to order a pizza via text message.
3. Designing The Pizza Code
3.1. Project Goals
- Largely vendor-independent
- Allows robust options, like ordering different toppings on each half
- Allows the expression of ALL options, including crust, sauce, cheese, and toppings
- Include some basic error checking
- Exclude collisions – situations where symbols are ambiguous
- Avoid similar or confusing symbols – e.g. ‘l’ and ‘1’ look similar, as do ‘O’ and ‘0’.
- Allow self-healing for unsupported options
3.2. Design Approach
Obviously, the Pizza Code has to be symbolic, and we want to use pure text symbols, just as the Geek Code did.
Rather than specify each option, we can assume that we will always start with a basic prototype. This allows us to represent an entire “default” set of options with one symbol. We can use “P” for pizza:
P = generic pizza
We can start with something simple and generic, like a medium cheese pizza, which has all of the basic elements of a pizza, represented in a “default” mode:
- Medium size
- Regular crust
- Marinara sauce
- Regular amount of sauce
- Mozzarella cheese
- Regular amount of cheese
- No toppings
This means that we can encode 7 values in one symbol! Not a bad starting point:
Rule 1: P = 1 Pizza, medium, regular crust, marinara (regular amount), mozzarella cheese (regular amount) and no toppings.
As we progress, we can use other symbols and modifiers to describe these variables and other aspects of our pizza.
Further, we can assume that syntactically, if we start each pizza with “P”, then the next time we see “P” within the same string, we are describing a net-new pizza – for example, allowing us to concatenate Pizza Codes, and thereby order multiple pizzas with one string.
This gives us Rule 2:
Rule 2: Each “P” represents a new pizza, and any subsequent characters are attributes or modifiers of the most recent “P”, starting new with the next “P”.
As a byproduct of Rule 2, we can safely ignore spaces and line breaks – they can be included for readability, but the system will work the same regardless.
3.3. Encoding Basic Attributes
We’ve already identified that “P” is a basic set of options for a medium cheese pizza.
Remembering my most recent online ordering experience, here is a quick run down of pizza attributes, minus toppings:
- Size: Small, Med, Large, etc…
- Type of Crust: Regular (sometimes called “hand-tossed”), Thin, Pan, Deep Dish
- Type of Sauce: Usually Marinara, but some places also offer Alfredo
- Amount of Sauce: Light, Regular, Extra
- Type of Cheese: Usually Mozzarella, but some places offer a cheese blend, or Feta
- Amount of Cheese: Easy, Regular, Extra
- Bake Time: Some places allow you to specify slightly over or under the normal bake time
Let’s draw a line in the sand, and assume that all of these, for a given pizza, is a “global” option – you can’t order two different crusts or sauces on the same pizza. Although some places may offer this, let’s assume you CAN NOT order more than one kind of cheese, either. We can go back later and allow vendor-specific specialization through a set of vendor-specific options.
For now, we can focus on our core pizza attributes.
Since size is a function of the pizza itself, we can simply make it a modifier. If we start with “P” = “Medium”, then:
- P++ Extra Large
- P+ Large
- P Medium
- P- Small
- P- – Personal
Since not every pizza place offers all of these options, we can assume Medium is always Medium. However, if they don’t offer a personal pizza, maybe this reverts to 1 slice, or to a small. If they don’t offer a small, small reverts to medium. Likewise, if there is no extra large, it reverts to large.
With this scheme, worst case scenario, I could order a P- – and end up with a medium, if that’s the smallest pizza they offer, but that might be much more food than I want. We can check for this and correct it later. Conversely, if I order a P++ and they don’t offer one, I’ll end up with the largest pizza they DO offer, which would still be OK. I can always go back and order another pizza if needed. Again, we can cover this later under logistics.
We need a symbol table for the other attributes.
Unfortunately, we have some possible collisions:
- “C” could stand for “Cheese” or “Crust”
- “T” could stand for “Type” (of something), Bake “Time” or “Topping”
- “S” could be “Sauce”, but maybe we want to be able to order a “Specialty” pizza
At first, the best approach would seem to be to use predefined fields:
P : crust : sauce : cheese : bake_time
Using this notation, your order might look like this:
P+ : r : m- : m+ : +
- Large pizza
- Regular crust (or hand-tossed)
- Easy on the marinara sauce
- Extra mozzarella cheese
- Extra bake time
Although this seems like a good approach, it has a few problems:
- What if you confuse the field for sauce and cheese? You’d end up with EXTRA sauce, and LESS cheese – the opposite of what you want.
- What if you want to omit a field? You could always leave it blank “::”, but then you run the risk of putting something in the wrong field.
- If you put an option in the wrong field, you might end up with something that doesn’t even make sense, such as “m-” in the “crust” field. Rather than discard the option, this leaves you with an unusable pizza – obviously the “m-” meant something, but it can no longer be interpreted correctly.
Even though we are trying to use as few characters as possible, clearly we need to be more specific, and we need codes that make sense as a mnemonic.
For now, we probably need to keep the field separator, so let’s make that Rule 3:
Rule 3: Each Attribute is separated by “:”
Why not use “.” or something else? Although my Android has a “.” on the main alpha keyboard (without shifting), my iPhone doesn’t. Besides, this is a code for geeks, and geeks should know how to get to the “:” symbol.
Using a separator also has the side effect of making the code largely case-insensitive, because we can use branching logic.
Rule 4: all codes are CASE INSENSITIVE
3.4. Attribute Codes
We want all of the codes to be largely mnemonic, and also as forgiving as possible, in the event of a typo or collision.
3.4.1 Crust and Bake Time
Since we are already using “P” with modifiers to specify the size of the pizza, and a +/- modifier for crust doesn’t really make sense, we could combine the bake time with a +/- modifier.
:Cr = Crust
- :CrT Thin Crust
- :CrR Regular Crust (Default, Sometimes called Hand Tossed)
- :Cr Also, Regular Crust
- :CrP Pan Crust
- :CrD Deep Dish
- :CrDD Also, Deep Dish
- :CrXa Vendor specific.
If Omitted, CrR is assumed.
Non-standard crust specification will be ignored, and will default to CrR.
Bake Time Options:
- :Cr+ Extra bake time
- :Cr Regular bake time
- :Cr- Less bake time
Default Bake time is assumed to be :Cr (regular)
Bake time and crust option can be combined:
- :CrP+ Pan crust, extra bake time
- :CrT- Thin crust, less bake time
- :Cr Regular crust, regular bake time (same as omitting)
The “X” code allows each vendor to optionally specify their own crust type or option, for example:
- :CrXc might mean “Cheesy Crust”
- :CrXp might mean “Pretzel Crust”
Not every vendor offers these options, but the “X” code gives each vendor some flexibility to offer their own signature options. Later, if everyone generally agrees with a particular standard, it can be moved in to the main option list – for example, if CrXc becomes commonly used, it might become CrC in later versions of the standard.
Backward-compatibility is important – if multiple vendors are using CrXc, we don’t want them to simply drop this code and start using the new one. Both codes have to be supported for a while:
Rule 5: All future versions of the Pizza Code must be backward-compatible
Finally, we want to avoid collisions with some other code that starts with “C”. For example, if we simply specify “C” = “Cheese”, we have a potential problem, if “Cr” = “Ricotta”. We can’t distinguish between a regular crust and Ricotta cheese.
Rule 6: All attribute codes other than “P” have to be the same length (2 characters)
We want to be able to specify what kind of sauce, but also the amount.
:Sa = Sauce
- :SaM Marinara (Default)
- :Sa Also, Marinara
- :SaA Alfredo
- :SaB BBQ
- :SaXa Vendor-specific
- :Sa+ Extra Sauce
- :Sa Regular Sauce (Default)
- :Sa- Light Sauce
- :Sa- – No Sauce
If not specified, the default is :Sa, which equates to Marinara, regular amount.
Options and modifiers can be combined:
- :Sa- Easy on the Marinara (Same as :SaM-)
- :SaA+ Extra Alfredo sauce
Again, the “X” code allows each vendor to offer their premium / signature sauces.
We want to be able to specify what kind of cheese, and the amount
:Ch = Cheese
- :ChM Mozzarella, Shredded (default)
- :Ch Also, Shredded Mozzarella
- :ChMM Mozzarella chunks, like a Margherita pizza
- :ChF Feta
- :ChB Cheddar Blend
- :ChXa Vendor-specific
- :Ch+ Extra cheese
- :Ch Regular amount of cheese (default)
- :Ch- Easy on the cheese
- :Ch- – No Cheese
If omitted, the default is :Ch, which equates to a regular amount of shredded mozzarella
Options and Modifiers can be combined:
- :ChB+ Extra cheese, cheddar blend
- :ChF- Light cheese, Feta
As with the other options, the “X” code allows the vendor to offer specialty options.
Because all of our option codes are the same length, the position where each occurs within the Pizza Code is irrelevant – except, of course, that it must appear after “P”.
Rule 7: Other than “P”, option codes can be specified in any order.
This means that the following pizzas are all the same:
- P+:Sa-:ChM+:CrP (Note that Ch and ChM are the same)
This is where things get tricky.
We’re on a roll with the attribute codes, so maybe “To” is a good way to specify “toppings”.
Setting aside (for now) that we want to be able to specify two pizza halves with different toppings, how would we specify multiple toppings?
One poor approach would be to use the topping attribute code each time:
- ToO Onions
- ToO Olives (collision)
- ToOl Olives (green or black?)
- ToGo Green olives….. or green onions??
- ToTo+ Extra diced tomatos
Because of the specificity required for each topping, this is going to get cumbersome.
The first problem is to find a canonical way to identify each unique topping – a “taxonomy of toppings”, so to speak.
The first obvious segregation we can perform, is that “specialty” items would be vendor-specific. So, for example, if you wanted a “sushi pizza”, this would be outside of the traditional taxonomy – we can account for this using our established “X” code standard: For example, Xsu might mean “slice up a california roll, and drop that right on my pizza”, to the ONE vendor who does this.
For the so-called “standard” toppings, the first bifurcating characteristic in our taxonomy is “meat’ or “not meat”. Although from a logical perspective, this statement seems almost contradictory, as if combining “meat” and “not meat” might inadvertently result in annihilation followed by a burst of gamma rays, the reality is that we have to account for the comical and ironic fact that the government classifies the tomato (a fruit) as a vegetable for tax purposes.
Likewise, plant leaves, fleshy roots, fruits, nuts, bark, and seeds all fall in to the “not meat” category, and we can save ourselves an existential headache by simply calling all of this stuff, “veggies”.
We already have a category for cheese, eggs (although they SHOULD be) are not currently a “standard” topping on pizza. This eliminates “dairy” as a standard category…
So if we discriminate between “meat” and “veggies”, we have the basis for a taxonomy, and thus a topping lexicon.
What if we want a predefined specialty pizza? For example, although the specific definition varies from vendor to vendor, EVERY vendor has a “Meat” pizza, a “Supreme”, and a “Veggie” pizza.
We need the flexibility to select a predefined configuration such as the above, but also, we need to be able to add or remove toppings.
Setting aside the whole attribute code issue:
- X – Vendor-specific topping (e.g. Xq = Quail’s egg; Xsu = Sushi)
- S – Grouping of specialty toppings (e.g. meats, veggies, supreme, etc….)
- M – Meat topping
- V – Veggie (not meat) topping
This gives us a basic starting point for developing a “codified topping lexicon”. Keep in mind that we want to maintain a mnemonic scheme.
- Sm Meats
- Ss Supreme
- Sv Veggie
- Ssa Spinach Alfredo
- Sca Chicken Alfredo
- Mba Bacon
- MIt Italian Sausage
- MHa Ham (Canadian Bacon)
- MCb Canadian Bacon (Ham)
- MBu Hamburger
- MHb Also, Hamburger
- MPe Pepperoni
- MSt Sliced Steak
- MCh Chicken
- MAn Anchovies (I LOVE ANCHOVIES….. GO WRITE YOUR OWN PIZZA CODE)
Veggie (non-meat) Toppings:
- VPe Peppers (Default – Green)
- VPeB Banana Peppers
- VPeG Green Peppers
- VPeJ Jalapeno Peppers
- VPeR Red Peppers
- VOn Onions (Default white / yellow)
- VOnG Green onions
- VOnR Red onions
- VOL Olives (Default black)
- VOLG Green Olives
- VOLB Black olives (Same as VOL)
- VPi Pineapple
- VTo Diced Tomato
- VMu Mushrooms
- VSp Spinach
So the next question is: How do we string this together?
There are two basic scenarios:
- You pick a specialty pizza, and you add / remove toppings
- You build a pizza from scratch, and you add toppings
So our lexicon has to include the ability to add, remove, or specify extra toppings:
-Topping Remove this topping
+Topping Add this topping
++Topping Add extra of this topping
Because we will always specify +, ++, or – in front of a topping, this gives us a syntactical approach to stringing toppings together.
To be consistent with our 2-character attribute code, let’s put “To” in front of the whole thing…
:To = Toppings
So…. let’s say we start with a Meat loving pizza, drop the hamburger, and add pineapple:
Large Cheese and Pepperoni:
NOW, we have a pizza!
4.1. Two Halves
Let’s say that you want two different toppings on each half of a pizza…
What’s the easiest way to do this?
Simply, specify two topping codes.
IF 1 topping code
Cover entire Pizza with Topping_Set_1
Cover Half1 with Topping_Set_1
Cover Half2 with Topping_set_2
So, let’s say we want a large veggie on one side, and meat-lovers + onion on the other:
Two To codes result in Half1 with topping set 1 and Half2 with topping set 2.
We still have a few things to cover…
5.1. Error Checking – Optional
At the end of the pizza code, there should be an indication of what was requested:
In parentheses, indicate the total number of pizzas of each size within the order. Use “=” for medium.
“(” [n++] [n+] [n=] [n-] [n- -] “)”
For example, if we are ordering 2 large and 1 medium pizza:
Error checking helps us determine what we are buying, to ensure that what we requested is what we should expect.
For maximum ease of use, the checksum should be optional.
Let’s say you’re at your friend’s house….
We need to be able to specify an alternate address.
Note: No address means that your default address will be the delivery address.
:Ad!123 Any Street!!12345
:Ad!401 Nowhere Blvd!104!84842
In the event of a severe disconnect, the pizza vendor can simply call the customer on his/her phone, or text, requesting clarification.
- You text Pizza Code(s) –> Pizza Vendor
- You <– Pizza Vendor texts summary, any discrepancies, address, and price
- You text “yes ” PIN –> Pizza Vendor
- You <– Confirmation
At any time, text “Cancel” to cancel the transaction.
Any transaction > 10 minutes is automatically cancelled without a valid response. You <– Pizza vendor “Cancelled”
In step 2, the pizza vendor confirms what you are requesting.
So if you text:
- 1 Large cheese pizza
- 1 Medium supreme, add green olives
Suppose the vendor doesn’t have green olives for some reason, they might respond:
Type yes PIN to order
This provides you with a chance to review your order. You see that black olives are not available, but you decide to order anyway.
In another situation, maybe you want a personal pizza:
Perhaps the vendor doesn’t offer personal pizza, nor pizza by the slice. Maybe all they have is a medium:
Type yes PIN to order
You quickly see that they don’t offer a personal or small – the smallest they offer is a medium, so you cancel the order:
- :Tin $n dollars tip
- :Tin% n% tip
5.5. Vendor-Specific Items
:Xx = Vendor-specific item or attribute
For example, maybe SuperduperPizza decides to offer wings and breadsticks via the pizza code. You might order them like this:
Although each vendor might have their own codes, maybe at SuperduperPizza, this means:
- Medium pepperoni pizza
- 10 boneless wings
- Cheesy breadsticks
As you can see, extending the pizza code is quite simple. Later, it might make sense to have a completely separate “Wing Code”, or an official set of wing standards within the Pizza Code itself.
5.6. Multiple Pizzas, Same Specification
An integer after “P” indicates the quantity:
- “P2” = 2 medium
- “P3+” = 3 large
- “P4- -” = 4 personal
P4+:To+MPe(4+) 4 large pepperoni pizzas
5.7. Multiple Pizzas, Different Specification
Concatenating Pizza codes:
1 large red onion, green olive, pepperoni
2 medium pan, alfredo, chicken, pineapple
Here are some of my favorite pizzas:
- P+:To+Sca+VPi (Chicken Pineapple Alfredo)
- P+:To+Ssa (Spinach Alfredo)
- P+:CrT:To+MPe+MHa++MBa+VOnR (Thin crust, Pepperoni, Ham, Extra bacon, Red Onion)
- P+:To+MHa+VPi+VMu+VOn (Regular crust, canadian bacon, pineapple, mushroom, onion)
Generate your own pizza code!
6.1. Pizza Code Cheat Sheet