1 2 Fizz 4 Buzz

#16 - Putting the Fun in Function

2012-03-06T15:05:00.000-07:00

Kotlin has functions. Whodathunk? You've been seeing them since the first code samples but perhaps we should put it to real use.

fun fizzBuzz(i : Int) : String {
    return when (i%15) {
      0 -> "FizzBuzz";
      5,10 -> "Buzz";
      3,6,9,12 -> "Fizz";
      else -> i.toString();
    }
}

fun main(args : Array<String>) {
  for (i in 1..100) {
    println (fizzBuzz(i));
  }
}

The function deceleration syntax is very reminiscent of Pascal, the third programming language I ever learned (various BASICs and Action! were the first two). These differ from C[#/++] and Java in several ways.

One difference is that there are only three letters for fun, rather than all 8 for function. Even with IDE code completion, f [ctrl+space] [Enter] is still three keystrokes. I guess they could put in an extra space to save one, but then I'de be compelled to count [ctrl+space] as two keystrokes (even though it is one cord).

The next difference is that the type follows the symbol name. This is more of a western approach to surnames than the typical braces and semicolons approach which places the type before the symbol, if you consider the type of the symbol to be the family name of the symbol. In a sense, placing the identity of the symbol above that of it's role.

One other quirk is that there are no primitive types in Kotlin, or there are no object types of primitives (via the Int type deceleration on the first line). Actually there are object primitive types, but they are the nullable primitive types. Except that you use a capitalized name, which implies they are Object types, which they are unless they happen to have a nullable modifier on the object type, which makes it a different type rather than a modification of the original type. So to express this in a particle physics metaphor this is an anti-quirk to a Java quirk, which means they annihilate each other. Except they are quirks not quarks, so a strange quark, or quirk, is left over. Which only matters when comparing it to a particular implementation platform. Charming.

Finally, unlike Pascal there are no procedures. Everything is a function, even if it returns Nothing. The closest analog to a procedure would be a function with no declared return type, which is then implied to mean Tuple0, a tuple with zero members, which appears as of the writing of this post to be disctinct from Nothing. Remember, {ε} ≠ ∅. Isn't math fun?!

FizzBuzz 15 - Technically Correct (But Oh So Wrong)

2012-02-28T15:05:00.000-07:00

I am going to keep with my theme idea for "FizzBuzz" counts. These solutions are the ones that make your eyes bleed or make you brace for impact. Technically this solution is correct, but it is oh so wrong. This solution is in Text. Not Tex, Text.

1
2
Fizz
4
Buzz
Fizz
7
8
Fizz
Buzz
11
Fizz
13
14
FizzBuzz
16
17
Fizz
19
Buzz
Fizz
22
23
Fizz
Buzz
26
Fizz
28
29
FizzBuzz
31
32
Fizz
34
Buzz
Fizz
37
38
Fizz
Buzz
41
Fizz
43
44
FizzBuzz
46
47
Fizz
49
Buzz
Fizz
52
53
Fizz
Buzz
56
Fizz
58
59
FizzBuzz
61
62
Fizz
64
Buzz
Fizz
67
68
Fizz
Buzz
71
Fizz
73
74
FizzBuzz
76
77
Fizz
79
Buzz
Fizz
82
83
Fizz
Buzz
86
Fizz
88
89
FizzBuzz
91
92
Fizz
94
Buzz
Fizz
97
98
Fizz
Buzz

If you ever interview with me and attempt this answer, be forewarned: I will make you present a complete solution. Even if it takes the whole time I have allotted. The only recovery would be to change your answer to a one liner.

However, if you use a specific "interpreter" this is, indeed, source code that will solve the problem. On Linux and Mac one popular solution is cat. More advanced candidates would use mode or less. Those candidates I would send to the IT department to vet (since this is evidence of command line aptitude) but I keep them off of the programming team. The interpreter on Windows is type, and I am not sure where I would send candidates who knew that answer.

#14 - Express Yourself

2012-02-24T15:05:00.000-07:00

When creating a new language the designers really need to look at the cool features from current languages and steal the best parts. But you need to be cautious about not just picking up fashions. Remember: fashion is what you look at 20 years later and say "That looks so ugly."

But the reality is that only time will tell what is simply fashion and what is not.One of the cooler features of Ruby is that everything is an expression. Control structures included. That may be why ruby lacks the three expression for loop. That and a mild aversion to semi-colons. I'de post this code in Ruby, except that the new kid on the block is Kotlin, and everyone loves to play with the new kid.

fun main(args : Array<String>) {
  for (i:Int in 1..100) {
    println (
      when (i%15) {
        0 -> "FizzBuzz" 
        5, 10 -> "Buzz"
        3, 6, 9, 12 -> "Fizz"
        else -> i
      })
  }
}

This is only a mild variation from the previous solution. Instead of printing out the results inside the when blocks the whole result of the when block is printed out. Structures like this figure into some of the design decisions like making the case statements only one expression. Evert expression on Kotlin returns a value. Even if it returns Nothing (and there is a language construct for Nothing).

Hopefully the "everything is an expression" thing isn't just fashion. Ideally when you come back in 20 years (or 20 weeks) and see yourself using control structures as expressions you won't ask yourself "What was I thinking?"

#13 - When in St. Petersberg

2012-02-21T15:05:00.000-07:00

That was a short break. Basically I wasn't liking the structure I was forcing myself into. Once I get a large corpus of solutions I can look into formatting, but in the mean time I will focus on stuff that entertains me, free of schedule constraints or themes.

But last Tuesday JetBrains publicly released the beta of Kotlin, their entry into the alternative not-just-JVM languages. There are several very interesting features of this language. And best of all it runs in an IDE I use on a daily basis: IntelliJ Idea. Since this will be the first of several posts, I will first present the solution that most of them will build on.

fun main(args : Array<String>) {
    for (i in 1..100) {
        when (i%15) {
            0 -> println("FizzBuzz");
            5,10 -> println("Buzz");
            3,6,9,12 -> println("Fizz");
            else -> println(i);
        }
    }
}

Instead of a switch statement Kotlin has a when statement (lines 3-8). This is for the most part syntactic sugar, but real sugar not the high fructose code syrup sold to public school programming students. At first blush it looks like changing the word when for switch and some other changes in the case blocks. And in this example, it is all the same. But it is denser and hence reads better.

First, you will not that there is no implicit fall-through. Each case statement matches up to exactly one expression (and that expression can be a multi-expression block). To fall through the rest of the switch you must explicitly use the continue statement. And even then it will simply continue to evaluate itself against the conditions rather than jump to the next block. So the old-school switch drop throughs which were the source of some mysterious bugs are not longer explicitly allowed.

Second, because of the single use structure of the blocks, multiple cases are combined into one comma-separated expression. This is possible because there is no possibility of fall-through between each label.

Finally, the default case (denoted by the else case) is required except in instances when "the compiler can prove that all possible cases are covered with branch conditions".

For this solution, I took advantage of the 15 number pattern in FizzBuzz and simply switched on the mod of 15. There is one case for a FizzBuzz, two for a Buzz, and four for a Fizz. Everything else falls into the else block. This actually reads fairly close to the text description of the problem statement.

The IntelliJ team writing Kotlin is based mostly in Russia. The name Kotlin is from the name of an island near St. Petersberg, which is not really that close to Rome.

This isn't Dr Scholl's, going on hiatus.

2012-02-13T22:00:00.000-07:00

This blog project isn't quite "gelling" like I expected it to mentally, so I am going to take a hiatus of indeterminate length. Too many different ideas that don't come down to a focal point just yet. I think the real problem is that I really need to plan all 100 entries into themed blocks, kind of like what I doing with repetition.

The whole Fizz for languages, Buzz for longer elaborations, and FizzBuzz for esoteric languages was a novel setup, the content of the number entries was letting me down. So if and when I come back to this, I will at least go at it with an entire roadmap (if not text and worked solutions) rather than a rough idea. However I see this more as a fast paced conference presentation about "Everething you need to know about programming I can show you in FizzBuzz" with 100 variations in 50 minutes, across multiple languages. But that may be because I prefer speaking to writing.

I do have some code in the hopper that abuses Java language features. I will post some of those in April as it keeps with the American theme of April Fools Day.

And the title is a reference to a really annoying shoe inserts ad.

Fizz 12 - A Snake, Hiding in the Whitespace (Python)

2012-02-09T15:05:00.000-07:00

For this Fizz, I have decided to tackle one of the other preferred languages at Google: Python. Since there is enough to talk about with Python I decided to do a relatively straight port of the first FizzBuzz I posted.

for i in range(1, 101) :
    if i%15 == 0 :
    	print "FizzBuzz"
    elif i%5 == 0 :
    	print "Buzz"
    elif i%3 == 0 :
    	print "Fizz"
    else :
    	print i

Like most "scripting" languages there is not a whole lot of overhead and ceremony in this code sample. Lots of items are implied via their absence. The namespace has a nice default, the main procedure to call is simply the statements at the root of the parse tree. And there is a large set of functions available in the default namespace.

Another unique feature of Python that is white space is significant. Very significant. There are no opening and closing braces to group the control structures. You must indent deeper than that parent control structure and maintain that indentation for multiple statements as a part of that structure. In essence, the "good practice" of indenting nested control structures is hard wired as a requirement into the grammar of the language.

But the most relevant part of Python in relation to the current subject of discussion is how it loops. The calculations and decisions in this example are merely syntactical variations of what we have seen before. Python lacks a three expression loop seen in braces-and-semi-colon languages. Instead it relies on an "iterator" based loop where the decisions about what the next item is and deciding when to stop is encapsulated inside an object called an Iterator. In this case, the range function returns an iterator that returns the numbers from one to one hundred in order. Ignore the fact that the second argument in the function is actually greater than one hundred. Software is rife with off by one errors.

On last point. The indentations must be consistent within the control structure. In other words if you start indenting four more spaces than you had before then each statement in the control structure must have the same amount of indentation. Whether they be tabs or any number of spaces. And you can even mix tabs and spaces, if you are consistent. This example mixes tabs and spaces for the print statements. So, applying the FizzBuzz hypothesis we can conclude that typical programmers can do indentation consistently. The real question is if they will (and they won't because everyone has seen enough evidence to the contrary).

#11 - Define Recursion: See Recursion

2012-02-07T15:05:00.000-07:00

There is one last principal form of repetition remaining to be discussed. This form of repetition is the bane of many first year Computer Science majors and dreaded only more by the professors and TAs who must answer these questions that are best paraphrased as "I just don't get it." That principle? Recursion. I have found no more precise and snarky answer than found in this stackoverflow answer:

If you understand recursion, you're done. Otherwise go read this StackOverflow question...

The link, of course, is back to the very same question.

public class FizzBuzz11 {

  public static void main(String[] arg) {
    recurse(100);
  }

  public static void recurse(int num) {
    if (num > 0) {
      recurse(num - 1);
      if (num % 15 == 0) {
        System.out.println("FizzBuzz");
      } else if (num % 5 == 0) {
        System.out.println("Buzz");
      } else if (num % 3 == 0) {
        System.out.println("Fizz");
      } else {
        System.out.println(num);
      }
    }
  }
}

There are no control structures traditionally associated with repetition in this sample. No for loops of any stripe, no while or do/while. Not even a GOTO statement (that would be harmful). What does do the repetition is the call to the recurse method at line 9. That line, of course, is in the very method that it is calling. A snake eating it's own tail.

Of course, a snake will never be able to fully consume itself. This is assuming it could get over the pain of biting it's own tail, which is about as bad as the anguish felt by many students experiencing their first semester of programming. At some point things will either hurt too much or the snake's stomach will get too full. This is called the "base case" where a simple answer is known and we can unwind the stack.

There are a lot of really neat intricacies that can be used with recursion, but this task is much to simple to demonstrate them in this form. The form used for this recursion is to count backwards (line 10) from the last answer needed (line 4), stop when we hit zero (line 9), and when unwinding the stack calculate the answer for the number at hand (lines 11 to 18). There is no work done both before and after the recursion, only after. There is no multiple winding and unwinding of the stack, just one dive in and out. And there is no use of the returned values from the recursion, in fact there is no return value at all.

All of this aligns with my experience with recursion seen 'in the field.' Simple recursion can be handled by anyone deserving to be paid market rates. But you throw in the more interesting cases (as a computer scientist would consider interesting) you are better off shipping it in a binary compiled format. Because if the typical developer is given a chance to mess with the source code, they will break something. Until the point they suddenly understand it.

Buzz 10 - How Many Times?

2012-02-02T15:05:00.000-07:00

I'm going to be changing up my plan for Buzz entries. I had intended on writing 500-1500 essays tangentially related to the FizzBuzz at hand (much like my tiny e-book on Amazon) but I see several problems with it. First, it can ruin the natural progression of solutions if I hold out one solution for a particular post I have planned. Second, it will ruin the the general feel of this blog, going from technical to random life experiences and then back. Third, writing that much text on a deadline is kinda hard with my current life balance. Really, should 1st graders have homework? Even if it is reading with a parent 20 minutes a night?

So here is the new Buzz plan... for each Buzz I will revisit a language introduced in a previous Fizz entry, and re-work a number entry not in that language using some of the unique features of the language. For this first entry the selection is limited, but actually relevant to the current numeric theme, especially since Groovy has so many ways to do repitition.

100 times {
  int i = it+1
  if ((i % 3 == 0) && (i % 5 == 0)) {
    println "FizzBuzz"
  } else if (i % 3 == 0) {
    println "Fizz"
  } else if (i % 5 == 0) {
    println "Buzz"
  } else {
    println i
  }
}

Lines one and two are the focus for this post, because the rest of it is a simple transliteration to standard Groovy.

On first reading, it does what it says. Repeat the enclosed block 100 times. But in the syntax sugar and details of the API are some common assumptions. First, what the current count is matters, but there is no explicit variable for that. Each closure without an argument block gets a single variable it that you don't need to declare and just exists. Kind of like this in methods. (And when is some programming language going to introduce that?)

The next assumption is what number to count from. You would think that counting from 1 would be sensible. But Groovy uses zero based arrays, like nearly all popular languages, so instead it starts all couting from zero. Line 2 is an optimization so we don't have to extend our math into the rest of the method.

The rest is pure syntactic sugar. When a symbol that could be a method trails an object with no punctuation it is presumed to be a method call in Groovy. And when a single closure follows a method call, whether or not it is in the argument list, it is added to the argument list of the method. The integer 100 is boxed up to a java.lang.Integer class. And via the Meta-Object-Protocol we can graft in a random times method onto the Ingeger class even though it doesn't exist in the plain JDK.

The end result is something that looks a little bit more like a spoken sentence, but not too close.

Fizz 9 - Fire Ready Aim (Dart)

2012-01-31T15:05:00.001-07:00

For this Fizz I choose one of the most recent languages: Google's Dart. While trolling Google Plus I found this solution by Yosuke Sato.

// fizz buzz
main() {
  for(int i=0;i++<100;)
    print((i%3==0?"Fizz":"")+(i%5==0?"Buzz":"")||i);
}

This is a fairly dense rendering of FizzBuzz and gets right to the point without much ceremony: one loop, one single print statement, and a minimum of braces and parenthesis based on operator order of precedence.

Things get interesting when we encounter the short-circuit or operator. On the left we have a string type, and on the right we have an integer type. Java would reject this out of hand because short-circuit logical operations can be applied only to boolean primitive types. Dart, however, has more in common with JavaScript, and uses an entirely different approach. First the left hand side is evaluated, and what matters is if it is false-equivilant value: false, null, zero, or the empty string. The && operator will return the left side if it is negative, and the || operator will return the right hand side if the left is negative. With boolean values you get simple solutions. With string and integer types you get more interesting uses. Such as using || to resolve defaults and the && operator to null-check complex objects.

As an aside, the dartlang.org sample compiler will refuse to run this FizzBuzz in checked mode. In unchecked mode it will complain about the types. Perhaps it does have more in common with Java than I realized at first.

#8 - Do while I'm doing

2012-01-26T15:05:00.000-07:00

Now that we have examined the while loop in C style languages, it's time to consider the while loops delinquent little brother: the do-while loop. This is a fairly unique control structure that requires a keyword both at the beginning and the end of it's structure. Kind of like the try-catch clause, except that you only try once but you do the loop at least once, and then consider whether you continue or not. This does have one slight advantage in readability: if you decide not to continue you are right at the code block you will evaluate next.

public class FizzBuzz08 { 
  public static void main(String[] args) { 
    int i = 1; 
    do {
      if ((i % 3 == 0) && (i % 5 == 0)) { 
        System.out.println("FizzBuzz"); 
      } else if (i % 5 == 0) { 
        System.out.println("Buzz"); 
      } else if (i % 3 == 0) { 
        System.out.println("Fizz"); 
      } else { 
        System.out.println(i); 
      } 
    } while (i++ < 100); 
  } 
}

This code isn't dramatically different from the previous entry where the while loop was considered. The body is still on lines 5 through 13, and the first expression is on line 3.

The differences come in the second and third expression. I combined both of them on line 14 for stylistic reasons. First, the order of the expressions would not have been maintained since the increment would occur before the test. I then moved the post increment into the while test expression so we can use the less than operator instead of the less than and equal. One less keystroke. Although since I am programming in Java I don't know why I worry about minimizing keystrokes.

This loop is not a direct decomposition of a for loop. The loop body will always be evaluated once regardless of the truth of the expression. So this is not a good case of the always evaluate logic. So if a do-while smells like a simple while, typical developers can code it correctly. However whether they can use the always evaluate aspect correctly is up for debate.

#7 - Decomposed Loop

2012-01-24T15:05:00.000-07:00

It's hard to take a look at a programming solution to FizzBuzz from an absolute ground state. There are at least three concepts that need to be working at a basic level for a solution to be sensible: repetition, decisions, and calculation. To analyze any of those three aspects you need two of them standing fairly unchanged while one of them is decomposed.

First I shall decompose the nature of the solution by changing the basic ways a loop can be constructed. Given the prevalence of C and Java as arguably the most popular language in programming language for over a quarter century the three expression for loop is something that any professional or accomplished amateur should understand instinctively. But what does that three expression loop look like when decomposed in a semantically similar fashion??

public class FizzBuzz07 {
  public static void main(String[] args) {
    int i = 1;
    while (i <= 100) {
      if ((i % 3 == 0) && (i % 5 == 0)) {
        System.out.println("FizzBuzz");
      } else if (i % 5 == 0) {
        System.out.println("Buzz");
      } else if (i % 3 == 0) {
        System.out.println("Fizz");
      } else {
        System.out.println(i);
      }
      i++;
    }
  }
}

The three expression for loop actually has four parts. The part that often gets ignored is the loop body, expressed by lines 5 through 13 and is not counted in the three expressions. Since C and Java have zero based arrays, we could call this the zeroth expression.

The first expression sets initial values and variables and is seen in line 3. Strictly speaking this is not a proper decomposition since the scope of the variable in this decomposition could extend beyond the loop body, if there were expressions other than the loop. The second expression is a test, and is found inside the while expression on line 4. The last expression is found on line 14, executed after the content of the body.

As an aside, the last entry on Ceylon didn't feature a three expression loop because Ceylon doesn't support the syntax. That was the position Groovy once took but later relented when it added the "classic for loop" in it's 1.5 release. However, Ceylon and Groovy both have a while loop construct. So by applying the FizzBuzz Hypothesis we can see that programmers don't need a nice neat for loop expression. But it sure looks prettier with one.

Fizz 6 - This or That (Ceylon)

2012-01-19T15:05:00.000-07:00

Ceylon is a new JVM language being created by Red Hat and Gavin King. You may recognize that last name. Gavin also created Hibernate, a data library that underlies many e-commerce sites and is integrated (at the default option) into Grails. Ceylon puts a lot of emphasis into how it handles types, so it seemed like a natural language feature to abuse.

interface Fizz {}
interface Buzz {}

class CFizz() satisfies Fizz {
  shared actual String string = "Fizz";
}

class CBuzz() satisfies Buzz {
  shared actual String string = "Buzz";
}

class CFizzBuzz() satisfies Fizz & Buzz {
  shared actual String string = "FizzBuzz";
}

Fizz|Buzz|Natural fizzIt(Natural i) {
  if ((i % 3 == 0) && (i % 5 == 0)) {
    return CFizzBuzz();
  } else if (i % 5 == 0) {
    return CBuzz();
  } else if (i % 3 == 0) {
    return CFizz();
  } else {
    return i;
  }
}

shared void FizzBuzz06() {
  for (i in 1..100) {
    print(fizzIt(i).string);
  }
}

The particular typing feature I am using is called "Union Types." When you declare a type as TypeA|TypeB (note the pipe between the two types) you are telling the Ceylon compiler that you will have either TypeA or TypeB, it doesn't matter. And you won't have TypeC (for this example TypeC is not a TypeA or TypeB). Without this construct I would be forced to declare the return type of fizzIt to be an Object and hope no stray classes like Klang shows up.

There also exists Intersection Types (TypeA&TypeB) which means that the type is both of TypeA and TypeB without having to create some other interface that joins the two. Instead of createing a new interface RunnableFuture<V> you would just have Runnable&Future<V> without the need for a third class. Throw in stuff like RunnableScheduledFuture<V> which could have been declared as Runnable&Delayed&Future<V> and the code savings start piling up.

Buzz 5 - The FizzBuzz Hypothesis

2012-01-17T15:05:00.000-07:00

For the Buzz entries I intend to write something more involved. These entries will have a FizzBuzz solution, but the text will only be about FizzBuzz. And if you check various dictionaries the act of talking 'about' FizzBuzz gives me a lot of latitude to talk about practically anything tangentially related.

Today, however, I intend to stay fairly close to FizzBuzz itself. What I want to talk about is something I will call "The FizzBuzz Hypothesis:"

Given a particular language feature or programming technique, if it cannot be shown as an integral part of a FizzBuzz solution then the typical programmers will not be able to use it correctly.

This statement is worth deconstructing from multiple angles. First there is the logical structure of the hypothesis:

¬r → ¬q

where r is the ability to express the programming language feature or technique in the form of FizzBuzz and q is typical programmers using it correctly. This also implies something by negation. If typical programmers are using a language feature correctly then there must be some way to make it integral to a FizzBuzz solution, and if it can be proven that there is no such FizzBuzz solution then clearly the typical programmer isn't using it correctly, all other evidence notwithstanding. Also note the word choice here. I did not say properly or effectively, I said correctly. There are proper and effective ways to do things that are not correct. I am reminded of this every day I watch my children do chores around the house.

There is also the question of what I mean by the typical programmer. Since there is a high amount of variability on the high end of the "mean average programmer" the mean pulls up the average such that more than half of the programmers are less than average. There is also the possibility of a "median" programmer, where half the programmers are better or worse. This too has its faults, because that means that half of the programmers may not be able to even program a FizzBuzz solution. Given a large enough sample set that may be true, but I don't think we are talking about anyone who has sat through a LOGO class in elementary school or hand coded some HTML. When I say "typical programmer" I mean someone within one or two standard deviation of the mean. I am also assuming that programming ability is a Poisson distribution. (I think I've just demonstrated everything I can remember from one semester of college statistics for technical majors.)

Now why do I express the law as a double negative implication? I blame the self-esteem driven coddling I received in public schooling. When you are failing you are "not succeeding" and when you are rebelling you are "not conforming." Everything is expressed as the desired outcome, and rather than using an antonym the desired word is used, with a negation in front of it. As a good Computer Science major I spent a few weeks in propositional logic. This math subset has a lot of theorems. And one of them is is Transposition, where we can swap the order of the implication as long as we negate both sides. Taking a desired statement, and adding two negations and still have it mean something is really cool.

This them begs the question, if a typical programmer is using a language feature or pattern correctly then it can be expressed as a fundamental part of a FizzBuzz solution then why don't I say it like that? The problem is we start with the hypothetical typical programmer. Next, we would need to see them use the language feature or pattern correctly. And only then can we conclude an integral FizzBuzz solution exists. I don't like this formulation because we start with end results looking backwards rather than a prediction looking forward. We would start with real programmers correctly using real technologies and concluding something arbitrary and contrived. But if we start with something arbitrary and contrived we can project onto real programmers and real situations without waiting for those real situations to occur. Much like concluding that a ball will hit the ground without dropping it. This is especially useful for technologies that have not seen widespread use. By starting with the technology we can then use this hypothesis as a lens to examine potential technologies a priori rather than as a post mortem.

The reason I came to formulating this hypothesis is because of the depths of thinking I went to while contemplating the various parts of this project. Part of that was reflecting on why it was a good interview question for testing programming skills. Not design, engineering, or architecture skills, but programming skills in the raw. It's a bit like the NFL combine. Before players are drafted by professional teams the teams get all of the top candidates together and test basic skills. How fast can you run, how much can you bench press. Let’s see you catch balls, see you throw balls, and see how smart are you. (No kidding, the NFL sits them down for an IQ test. And offensive tackles tend to be smarter than the quarterbacks, and way smarter than the wide receivers.)

But what makes FizzBuzz a good proxy for programming aptitude? FizzBuzz has three key aspects to most solutions: repetition, calculation, and decision. And these three aspects pretty much sums up most of what programming is about. There are some exceptions, and most of those interactions are hidden behind APIs calls. So if a programming language feature or pattern doesn't help you repeat, calculate, or decide, what good is it for programming?

For this entry I am going to use the FizzBuzz Hypothesis to answer a question that has bothered me since the Java programming language has been released: why is there both a short circuted and fully evaluated boolean operator in the Java Programming Language? And can you use both meaningfully?

public class FizzBuzz05 {

  static boolean lessThan100(int val) {
    return val < 100;
  }

  static boolean printNumber(int val) {
    System.out.print(val);
    return true;
  }

  static boolean maybeFizz(int val) {
    if (val % 3 == 0) {
      System.out.print("Fizz");
      return true;
    } else {
      return false;
    }
  }

  static boolean maybeBuzz(int val) {
    if (val % 5 == 0) {
      System.out.print("Buzz");
      return true;
    } else {
      return false;
    }
  }

  public static void main(String[] a) {
    int num = 0;
    while (lessThan100(num++) &&
      maybeFizz(num) | maybeBuzz(num) || printNumber(num)) {
      System.out.println();
    }
  }

}

Most of this solution is spent writing a method that makes the key point more readable. There are four different methods that do four separate things required by the solution. One method tests if the number is less than one hundred. One method prints out the number that is passed in. One method when passed in a number divisible by three prints out "Fizz." And there is one last helper method that does the same as the last, except testing for 5 and printing "Buzz." If the Fizz or Buzz methods print out a value, then they return true. If no value was printed, false is returned. None of these helper methods print a new line; that will be the task of the main method. You may be wondering where the helper method is that prints out "FizzBuzz". The reason we don’t need one is the point of this particular exercise.

The magic happens in line 33, a group of three of the helper methods joined by two different boolean or operators. The first one is the fully evaluated or "bitwise" version and the other is the short circuited or "logical" version. According to operator precedence we work with the bitwise operator and work that one first. When going through the loop both sides of this operator will be evaluated, regardless of the results. So in the cases where we have a number evenly divisible by three and five we will get both sides of the expression evaluated, even though we know after fizz that the result will be true.

The second operator, of lower precedence, is the logical or short circuit operator. If either of the methods on the left hand side had printed out their FizzBuzz value then we would be getting a true result on the left side. By short circuit rule we would not evaluate the right hand side and no value would have been printed. This is a good thing, because the method will always print a number regardless of what it is. If we print out Fizz or Buzz or FizzBuzz we are not supposed to print out a number at all. But if neither of the methods return true and no other values have been printed out then we need to print out the number. Since the left hand side is false in those cases the right hand side is evaluated. And as a side effect of the evaluation the number is printed.

So there, in one single expression, we have both a fully evaluated and short circuited logical or operator. It looks like typical developers can use this correctly.

#4 - Wrap the Math in a Method

2012-01-12T15:05:00.001-07:00

Sometimes I think I was born to program, other times I think it's a giant cosmic coincidence. When I was in fifth grade my school got lucky and someone donated 15 VIC-20 computers complete with cheapo CRTs. Because of this all of the fifth graders learned how to program basic that year. All of the fifth graders, not just the nerds. In junior high school there was a computer elective as well, which I took at the earliest possible time. Then when I got into high school I was in for a rude shock: you need to be a Junior to take a computer programming class. Two whole years without official credit for goofing off on a computer. What was more awesome was that it was an honest to goodness programming class instead of that survey class I had in junior high.

So I did what any other socially awkward nerd would do: I asked the teacher if I could get an exception. And I got that exception, and took the class the second semester. The class was well within my capabilities as I had to endure complaints from other students that I was a curve buster with my 105% score in the class (when adding in extra credit). It was the only time I have ever been accused of "busting the curve." But it wasn't all ice cream and lollipops. The teacher didn't always like the way I coded the solutions, particularly the fact I never used procedures. My programs were all one long stream of instructions. Just like a VIC-20 basic program, except there were no line numbers. My thinking was if you are only going to call a procedure at one point in the code then why type all those extra keystrokes? Mr. Shepard was not impressed.

public class FizzBuzz04 {

  public static void main(String[] args) {
    for (int i = 1; i <= 100; i++) {
      System.out.println(theValue(i));
    }
  }

  public static String theValue(int i) {
    if ((i % 3 == 0) && (i % 5 == 0)) {
      return "FizzBuzz";
    } else if (i % 5 == 0) {
      return "Buzz";
    } else if (i % 3 == 0) {
      return "Fizz";
    } else {
      return Integer.toString(i);
    }
  }
  
}

I hope Mr. Shepard is impressed now. This actually does, believe it or not, improve the readability and maintainability of the code. It pulls out the biggest third of the problem (doing ugly math) and keeps the other two thirds (counting to one hundred and printing out stuff) in a nice neat package.

In the main method the function it calls is a wondrous and magical black box. Data goes in, answers come out. This is a fundamental abstraction that actually allows a lot of magical code to work. Consider encryption. Do you know about congruence in number theory? What? Numbers have theories?! And what's that about the Chinese remainders? Don't know, and since I have a procedure I can call I don't care.

It's magic.

Fizz 3 - Elvis Has Left the Building (Groovy)

2012-01-10T15:05:00.000-07:00

Whenever I count "Fizz" in this series I will examine a language that has yet to be examined before. There is no shortage of candidates but the trick will be to keep the languages choices relevant and readily verifyable (this could be tricky). Ideally I will be able to consider a feature that is relatively unique to that language or family of languages.

For this post I will examine the Groovy programming language. Picking a relatively unique feature for Groovy is a fairly hard prospect since it tries to pull all the best parts from all other languages. It is based on Java, so it's a C like curly brace language. It compiles to JVM byte code. It is object oriented, but strives to delay it's method dispatch as late as possible, enabling multiple dispatch method invocations as seen in Common Lisp. It uses closure like blocks much like you would see in Ruby.

There are a lot of neat tricks in Groovy so I see myself coming back to this language later in this series. But perhaps the most unique feature of Groovy, or the one feature that it has gone the furthest to popularize, then it would be the "Elvis Operator:" ?: a C style ternary operator with the middle operand removed.

for (int i = 1; i <= 100; i++) {
  String answer = ""

  if (i%3 == 0) {
    answer += "Fizz"
  }

  if (i%5 == 0) {
    answer += "Buzz"
  }
  
  println answer ?: i
}

This isn't the most idiomatic Groovy code for this solution. It is intended to demonstrate just the Elvis operator with all other awesomeness removed. I have a three statement solution that shows other Groovy features such as blocks and ranges. But for the purpose of this post we should focus just on the unique feature. There, on line 12 of the verbosely expressed code, is the Elvis operator. Why is it called Elvis? If you rotate it clockwise the question mark kind of forms Elvis Presley's hair just above his eyes.

But what does it do? It clearly has no hips to shake suggestively since he is being expressed from the nose up. Elvis picks the first "true" item it sees and returns only that item. Mode technically, the left hand side of the operator is evaluated for "groovy truth," and if it returns negative (null, false, zero, or empty string in most cases) then the right hand side of the operator is returned. If the left had side matches any other value, then the left hand side of the operator is returned.

This roughly equates to the C style statement x ? x : y. If the middle operator leaves the building, along with the white space, you are left with the Elvis operator: x ?: y. Even though Elvis has left the building, his legacy remains.

#2 - Is That Your Final Answer?

2012-01-05T15:05:00.000-07:00

When it comes to minor tweaks in the presentation of the problem, there is more than one way to make "the smallest change." Rather than printing out the result immediately we can defer the printing and keep an answer in a variable, changing it as needed.

public class FizzBuzz02 {
 public static void main(String[] args) {
  for (int i = 1; i <= 100; i++) {
   String answer = Integer.toString(i);
   if (i % 3 == 0) {
     answer = "Fizz";
   }
   if (i % 5 == 0) {
     answer = "Buzz";
   }
   if ((i % 3 == 0) && (i % 5 == 0)) {
     answer = "FizzBuzz";
   }
   System.out.println(answer);
  }
 }
}

This example allows two important changes, actually. The first is the introduction of a variable, and the changing of the variable Once we are done deciding what the result should be we can then print out the result of the variable.

The second important change is that we can consider each condition on its own. Since the most general cases are considered first and then the most specific are considered later. Since the most specific one is considered last, it can overwrite the previous answer. When you add these two items together, you can see that the variable will be set once, twice, or four times. Never three.

Another way to think of this is a game show. Rather than playing Jeopardy, where only the first answer given is accepted, we are playing Who Wants to Be a Millionaire, where the last answer given is accepted. Contestants routinely change their answers but the only answer that matters is the last answer.

#1 - Common But Boring

2012-01-03T15:05:00.000-07:00

Over the next year or so I intend on blogging 100 solutions to the FizzBuzz problem. Each solution will vary in either technique or language, sometimes both. The various "FizzBuzz" posts will also have various themes based on where the number lands. The "number" days will simply be a solution with the prose around it focusing on the solution itself.

To start things off I thought it was best to focus on one of the more common answers. This solution will be written in Java, which as of this writing was the #1 language on the TIOBE index in December of 2011. This is merely evidence that it one of the most common languages.

public class FizzBuzz01 {
 public static void main(String[] args) {
  for (int i = 1; i <= 100; i++) {
   if ((i % 3 == 0) && (i % 5 == 0)) {
    System.out.println("FizzBuzz");
   } else if (i % 5 == 0) {
    System.out.println("Buzz");
   } else if (i % 3 == 0) {
    System.out.println("Fizz");
   } else {
    System.out.println(i);
   }
  }
 }
}

This is not a perfectly straightforward translation of the problem statement into a solution. Without a lot of preparatory code you cannot directly translate the problem statement into code in the order it is presented in the problem statement.

This sample is about as simple as it can be done in Java. The only portion worth commenting on is how it transcribes the solution. Rather than going in the order the clauses are stated in the problem statement we consider the conditions from the last one first. This changes it from a set of "except" statements into a series of simpler if-then-else statements.

This is of the more common solutions (only considering correct solutions) presented by job candidates when asked this question in a job interview. It is also one of the most boring solutions.