After the excitement wears off of any good idea, you’re usually left with a giant pile of “oh crap, how will the xyz part work?” Like when you get your shop entirely organized into totes only to find that tent that's 15 inches too long. Such it is with Fruit Coder.

To see what we have planned out and what we don’t, let’s make a list of everything we want to do:

Flow control

This part is easy. The puck (marble, or another object) moves down the screen, activating any component it lands on. Single threading is modeled by one puck at a time. Multithreading, when we get there, by multiple pucks.

if, else, and else-if

This part also seems easy. The puck hits the if statement, activating it. The boolean expression in the if statement executes, and the puck either skips the attached block, or gets indented and works its way through. The expression may be as simple as a Boolean literal, or as complex as a triple nested and/or/not combo.

Herein lies our first headscratcher: one frustration with stepping through code is that you generally don't get to see the parts of a Boolean expression executing. The debugger just keeps sitting on the same line while you punch F7 repeatedly. Because we want to make this obnoxiously simple, it would be great if the puck activated each part of the expression. However, this probably isn't practical, as it would look like an out-of-control sing-along, with the puck hopping left and right (the execution order being b -> c -> a -> d).

A good compromise is to have each part of the Boolean expression light up as it's being evaluated, and play a nice loud boxing bell if it evaluates to true, or a buzzer if false. The background of each sub-expression turns green or red depending on the result.

This compromise should mostly work, but it leaves one big gotcha: calling functions from within the if statement. The puck needs to enter each function, but we don't want the puck hopping around. We could just make it impossible to nest a function in there, but that would be a huge disservice to the players. Learning that the return value of a function gets evaluated just like a variable is an important concept. But, since we don't really have functions all that well defined, we'll leave a mental note here and hope for a eureka moment.

Since each if block gets indented, a slide or conveyer belt to outdent seems pretty natural. This also makes else's easy: it can just be a slide to outdent.

switch/case

For now, we're going to skip switch/case, since it's just a cleaner way of writing if/else-if. We may add it later, but it seems like the sort of thing young developers can easily learn when pursuing their next language.

Next post: for loops and functions.