The Working Programmer - Capturing Important Business Logic
By Ted Neward | April 2013
Given that this is the month of April, that the magazine arrived on your doorstep (or mailbox or e-mail inbox or ... whatever) somewhere on or around April 1, and that said date is often referred to in the United States and other Western nations as “April Fool’s Day,” it seemed appropriate to do a column on languages in which we can capture Important Business Logic. (Note the capitals there; that’s how business people always refer to whatever ridiculous new feature they want, so it’s only appropriate that we refer to it with the same degree of veneration and respect that it deserves.) It’s important to note it’s of utmost importance that when we capture said Important Business Logic, we do so with gravitas and sincerity; this means doing so in a language that the business owners and customer representatives (and most of the marketing department) can understand.
So, it’s with a grave and sincere demeanor that I present to you an important language in your .NET programming toolbox: LOLCODE.
While it has long been the opinion of scientists and dog owners alike that cats can’t really communicate with their owners, cat owners have known for years that they communicate just fine—just ask any cat’s co-residing human whose cat has just informed him that despite the fact it’s 5 a.m., it’s time for the cat to be fed. (For the uninitiated, such activity usually involves loud meows, head butts to the nose, innocent expressions and occasionally a very slight flexing of a feline claw to a sensitive human body part.)
However, ever since cats discovered the mechanical mouse, a quiet revolution has been taking place across the Internet: Cats have steadily improved their ability to communicate by posting pictures of themselves with captions written in what many anthropologists and historians (all of whom are cat lovers—the dog-loving anthropologists and historians having been “unavailable” to comment on this) agree is the fundamental building blocks of all human language. This fundamental language is sometimes referred to imperfectly by humans by the name “LOLspeak.” (Examples of it can be found in your Facebook and Twitter feeds, so don’t pretend you don’t know what I’m referring to.)
Fortunately, well-intentioned cat-owned engineers familiar with the .NET platform have taken to extending this language into the .NET platform; two such endeavors were, in fact, in place, but sadly only one has survived to this day. The first was an implementation based on the Dynamic Language Runtime (DLR) from Martin Maly and John Lam back when the DLR was new (2007), but it seems to have disappeared. The second is a project from around the same time frame, but compiling the code into .NET assemblies rather than interpreting the source directly. That project is hosted at bit.ly/AJeM and, being open source, is easily accessible through Subversion via a single “svn checkout http://lolcode-dot-net.googlecode.com/svn/trunk/” command at your local command-line window. Once built, we can start to explore this amazing and powerful language.
For full details on the LOLCODE language, check out the LOLCODE Web site at lolcode.com, and in particular check out the LOLCODE language specifications, all of which are European Cat Programmers’ Association (ECPA) standards, at lolcode.com/specs/1.2. LOLCODE.NET implements much (if not all) of LOLCODE 1.2, which is the latest LOLCODE standard.
Of course, the first program that anyone ever writes in any new language must be that language’s version of “Hello World,” and our dive into LOLCODE will be no different:
Every LOLCODE program begins with the traditional greeting, “HAI,” and is terminated with the traditional closing, “KTHXBYE.” As with all keywords in LOLCODE, these are case-sensitive and must be typed all uppercase. “VISIBLE” is, as might be inferred, the command to write to the standard output stream, and “BTW” is the single-line comment. (Multi-line comments open with “OBTW” and end with “TLDR.”)
Using the “lolc” compiler built from the LOLCODE.NET source tree gives us a traditional .NET assembly, named (in the traditional fashion of .NET compilers) after the source file, so if the previous code is stored in “hello.lol,” then “hello.exe” contains the Intermediate Language (IL).
I HAS YARN
LOLCODE recognizes that there are only four types in the world: strings (YARN), numbers (NUMBR), Booleans (TROOF) and arrays (BUKKIT), but because cats never commit to anything until the last possible moment, a variable declaration in LOLCODE (using the “I HAS A” syntax) is untyped until the value is assigned to it. More important, because a cat would never be held accountable to a decision even once the decision is made, variables in LOLCODE are flexibly typed, meaning that a variable can hold any value, changing its type as necessary to reflect the new value:
The first line of code declares a variable named “COOLVAR” and assigns it the string (YARN) value THREE. The second line of code sets that same variable to the value 3, of NUMBR type. Any uninitialized variable contains the null value, “NOOB.”
Like keywords, variables are case-sensitive and may use mixed-case, though idiomatic LOLCODE suggests all capitals for clarity. Like C#, variable names must begin with a letter, but can then consist of letters, numbers or underscores.
Reading from the console is done using the “GIMMEH” command, so a second program to greet the user, ask him his name and print it back to him looks like the following:
HAI I HAS A NAME ITZ "Ted" VISIBLE "d00d type in ur name" GIMMEH NAME VISIBLE "d00d ur name is " NAME KTHXBYE
While the l33tspeak in the console isn’t a required part of the language, it’s considered idiomatically correct and good form.
If/then constructs are created by placing “O RLY?” after an expression, using “YA RLY” to define the truth branch of the expression and “NO WAI” for the false branch of the expression, and “OIC” to indicate the end of the if/then construct entirely. Multiple statements can be comma-separated on a single line if this is aesthetically pleasing. If there are more than two possible branches (what other, less feline-friendly languages call an “else if”), then this is given by “MEBBE” blocks defined in between the “YA RLY” and “NO WAI” blocks. Comparison operations are fully listed in the LOLCODE 1.2 specification, but the “SAEM” (equality) and “DIFFRINT” (inequality) operators are likely to be the most commonly used comparisons, as is true of most modern programming languages. For Boolean operations, “BOTH OF <x> AN <y>” give us logical-AND, “EITHER OF <x> [AN] <y>” give us logical-OR, and “WON OF <x> [AN] <y>” give us logical-XOR.
Loops are signified using the “IM IN YR <label>” keyword to begin the loop construct and end with the “IM OUTTA YR <label>” construct; without a terminating condition at the start of the loop construct, given by a “TIL” or “WILE” expression, the loop will run infinitely until terminated by a “GTFO” expression, which returns control immediately after the “IM OUTTA YR” keyword.
Putting all of this together, for example, you have the following program:
HAI I HAS A NAME ITZ "" IM IN YR LOOP VISIBLE "Gimmeh ur name or 'gtfo' to GTFO" GIMMEH NAME SAEM NAME AN "gtfo", O RLY? YA RLY, VISIBLE "L8r!", GTFO NO WAI, VISIBLE "Yo " NAME OIC IM OUTTA YR LOOP KTHXBYE
Notice that the loop “LOOP” is an infinite loop, with no termination condition, using “GTFO” in the “YA RLY” branch of the “SAEM ... O RLY?” conditional to terminate the program in the event the user types in “gtfo” as input.
HOW DUZ I ...
Good programming practice demands that code be segregated into easily consumable units, and LOLCODE wouldn’t be the serious business-ready language that it is without similar capability. By using the “HOW DUZ I” and “IF U SAY SO” keyword pairs, you can define functions that can be invoked to carry out operations:
HAI HOW DUZ I GREET I HAS A NAME ITZ "Ted" VISIBLE "d00d type in ur name" GIMMEH NAME VISIBLE "d00d ur name is " NAME IF U SAY SO GREET KTHXBYE
This will define a single function, “GREET,” that’s then used from the main program to greet the user and echo back his name. Parameters to the function are given by “YR”-name pairs.
I CAN HAZ LIBRAY?
Of course, the real advantage of LOLCODE isn’t in writing the boring and tedious parts of the program (a real cat would never stoop to boring and tedious, of course); instead, LOLCODE’s true advantage lies in capturing the Important Business Logic and exposing it through a Web service or Windows Presentation Foundation (WPF) GUI or something. For this reason, the LOLCODE compiler also supports the ubiquitous “/target:library” option to produce a standard .NET library assembly—doing this, however, still produces a “.exe”-suffixed assembly, with a Main method present in the program, even though the Main simply does nothing. This is actually quite in keeping with other modern languages that assume that the top of the file is the entry point to the program as a whole; LOLCODE is simply taking the extra step of always providing a Main, because one (even though empty) is always present.
Whether compiling as a library or an executable, LOLCODE always wraps the generated code into a class called “Program.” There is no namespace functionality—no self-respecting feline would ever accept a last name, either.
Soon to Be a Mission-Critical Best Practice
While LOLCODE is powerful, unfortunately its acceptance has not yet reached a point where many business analysts and customer representatives understand the benefits of expressing business logic in it. Fortunately, being open source, extensions to the language are easy, and this language is expected to become an industry-standard mission-critical best practice by 2014. For best results, architects are encouraged to demonstrate the power of LOLCODE in hands-on coding sessions, preferably in a meeting with high-level executives with no forewarning or advance notice. Happy coding!
Ted Neward is totally making all of this up, except for the parts about the LOLCODE language—all of that is absolutely true. He has written more than 100 articles and authored or coauthored a dozen books, including “Professional F# 2.0” (Wrox, 2010), but none as a joke like this article is. He is an F# MVP and speaks at conferences around the world. He has been advised by counsel not to publish any means of reaching him, so as to avoid angry letters from architects who followed that last bit of advice, but longtime readers of this column will already know how to reach him.
Thanks to the following technical experts in the Neward family for reviewing this article: Scooter, Shadow, Princess and Mr. Fluff Fluff