Always Press “Record.”

Changeup: This week’s assignment involved putting images to the canvas. That’s a fine thing — and if you’ve been experimenting in that area on your own, go ahead and take the rest of the afternoon off, you deserve it. For the rest of you, though, let me put a different challenge to you that will allow us to sum up a lot of what we’ve been doing so far.

Loving, by the way, the images I’m seeing on the walls.

These, though… These are going to be big. A3+ big.

Pick one of the following images and, to the best of your ability, using some of the material we’ve covered so far (RANDOM() functions, FOR() loops, IF() conditionals, palettes, arrays, opacity, and so on),  create some code that produces similar (or similarly-spirited) versions of at least one of these images.  If the original image is exceptionally dense or complex, feel free to focus on one part of that image.  To be printed on a postcard (4X6) borderless page (Selphy printer) on Monday.

Note that these images come from Pinterest, a site where attribution goes to die. Consequently, I have almost no attributions to offer, in spite of the fact that these artists deserve to be acknowledged. Where possible, the name of the file may provide the best hint I could glean from the original pin on Pinterest. Another avenue of pursuit: Look up my page on Pinterest and search backwards. If you want help looking for that information, or if you have that information to share, don’t be shy: Send it to me.

The fine print:

1. Start small. Break down the complexity of the image into its essential “parts.” E.g., the part that has the curves; the part with the straight lines; the part with text from unsent letters to Mark Ruffalo, star of stage and screen.

2. Look for opportunities to let your computer do what it was built to do: Deliver your screenplay to Mark Ruffalo Repeat itself. If there are forty circles on the screen, ask yourself, “Do I have time to draw every one of these circles? Am I to fall into this trap again, like mother warned?” No. Ask your computer to share the burden. “We’re all in this together.”

3. Try not to move on to another section of code until you are confident that the piece you were working on is working properly.  Then pick another small aspect, and focus on it.  Start combining your small, well-built fragments into something bigger.

If you’ve problems, questions, let us know!

Finally:

Ask yourself this: “How many minutes, per day, am I spending on code — whether assigned or self-imposed?”  It should be a number that you can bring home to meet your mom. Or my mom.  (She doesn’t judge, she’s just saying).  A number you wouldn’t be shy about introducing to me. 15 minutes? 20? 30? By this point, thirty minutes a day, every day, would be great. If you’re not coding every day, then repent: It isn’t too late. This whole endeavor is so (SO!) much easier if you force yourself to work through simple puzzles, problems, or build little apps every day. They don’t have to amount to anything: An app that hides circles with squares; an app that draws a randomized pizza pie. Anything will work. If you’re having trouble getting into this habit, please come talk to me.

Moving Towards Awesome

So here we are:  We understand random numbers (“cette idée si simple n’éclate pas dans tous les cerveaux“) and we are literally moments away from forever mastering Conditional Statements.  Why not introduce them to one another?  Why not get this party started?

I’ll just leave this here, and see where you go with it.

Guidelines:  On a single line of 10 figures, I want circles to appear 40% of the time, and squares 60% of the time.  And I want them all to be random shades of grey.

 

See the Pen LRRpBK by Garrison LeMasters (@Garrison) on CodePen.dark

Random Numb3rs

Random number generation (actually, pseudo-random number generation) is a piece of cake.

Typically, we’ll make use of a function called… random(). This function takes an argument, or arguments, and RETURNS a random number according to our needs. Since it is RETURNing a value, we’ll need to have a variable ready to receive it…

var n = random(1);

Easy, huh? This assigns a random number between roughly 0.00001 and 0.99999 to the variable n. Every time I run my code, n will get a different value. We’ll talk about why if we have time in class.

Another approach:

var n = int(random(20));

Little bit more complex, but still a cakewalk. The int() function takes a floating point decimal number (e.g., 4.55341) and turns it into an integer (e.g., a whole number, 4). It does not ROUND the number (although there is a round() function), it just lops off everything after the decimal. To wit:

var x = int(4.99999);

Means x = 4.

So we generate a random number between 0.00001 and 19.99999, and then we turn it into an integer (a whole number). Recall that functions are subject to the rules described by the Order of Operations too: Always solve the functions that are deepest inside parentheses, and move outwards.

Alternatively (and alternatives are always OK — we’re not aiming for efficiency here):

var n = random(20);
 n = int(n);

Finally, consider that we can give the random() function two arguments, a low-bound and a high-bound.

var r = random(1,20);

This is the easiest way to use random() because it is so similar to how we think and talk. “Pick a random number between 1 and 20.”  Note that when you ask me for a random number between 1 and 20, though, I’m unlikely to respond “15.335129”.  So we often need to add one more step:

r = int(r);

Or, in one simple step:

var r = int(random(1,20));

FOR LOOPS

By this week, we’ve touched on several important concepts:

(0) Variables are virtual boxes in which we can store — and retrieve — assigned values. More than this, though, variables are easily operated upon: We can increase, decrease, and otherwise change their values very easily. And since a variable is really just a dedicated address of computer memory, we can count on the computer to reliably store the values of millions of variables simultaneously.

(1) Our second concept, program flow, refers to the way a computer “reads” a program as it executes it. If you think of a program as a large map, program flow is the way we control how the computer moves across the map: The routes it takes, the speed it adopts, the number of times it repeats a trip.

(2) Finally, Conditional Statements refer to code whereby the computer “tests” an expression to see if it is TRUE. If it is TRUE, then the program may alter variables, update a graphic, take a detour to a new part of the program, or even stop the program altogether. If that expression is FALSE, then (typically) the program just continues as before.

A common Conditional you will write in your code, for example, is called a timer. Imagine that you’ve written a game where the player has 5 minutes to disarm a bomb. A simple timer is at the heart of that game. As soon as the game begins, your code makes note of the time. And then, once a second or so, a line of code might ask “Have 5 minutes or more passed since this countdown began?” That is our Conditional.

If the answer is no, nothing happens.  (Timers are easy to write because all computers contain clocks, and those clocks are constantly updated automatically.)

Eventually, though, the answer will be yes. On an alarm clock in your bedroom, that conditional then executes a chunk of code that turns on a radio or emits a shrill scream. In your game, that code probably starts playing an explosion animation, and then ends the game.

A Timer is just a conditional statement with a wristwatch.

With this in mind, then, it is time to explain FOR LOOPS.

For loops combine all three of these concepts and come up with a really useful tool. Where would I use a FOR loop?

1. Imagine a program that draws a series of buildings in a city block, draws starships in an armada, draws guns on a startship, populates a church with a dozen zombies, calculates likely voter responses in an election, or animates bars on a chart. Every one of those were built with FOR LOOPS.

2. Another common scenario: Imagine you’ve written software to pilot an autonomous car. Two important steps: A. Identify every nearby car on the road; B. Using a FOR LOOP, examine the distance between our car and each nearby vehicle. What is the distance between our car and Auto A? What is the distance between our car and Auto B? Auto C? And so on.

3. In a more banal sense, FOR LOOPS are the mechanism used to fill-up (“populate”) an application’s drop-down menus with items from a list (a catalog, also “an array”) of stuff. Think of all the fonts on your computer. Before you can use a drop-down menu to choose a font, the computer has to build a catalog of those fonts, and then use a for loop to cycle through each entry in that catalog, adding each one in turn to the font menu.

That’s a partial list, but it will do for now. Just bear in mind that FOR LOOPs have many different uses.

Frankly, the best way to figure out FOR loops is to watch them work. Before I give you some examples, though, let’s look at the structure of this function and explain it a bit. It may seems tricky, but there is nothing obscure about the logic: It is really fairly simple.

Here, we’ll make use of code that is typical of the programs I write when I want to learn how something works. It is essentially a program that documents its own execution.  You may want to copy it into P5 and let it run.  Remember that you should set P5 so that it runs in the editor, and not in the browser, in order to see the console log more easily.

var helper = 0;
var loopLimit = 3;

console.log("FOR LOOP begins HERE");
for (var T = 0; T < loopLimit; T = T + 1) {
    console.log("* * * * * * * * * * * *");
    console.log("... chunk " + T + " starts ...");
    console.log("... current T value: " + T);
    console.log("... dummy variable was: " + helper);
    helper = helper + 1;
    console.log("... dummy variable now: " + helper);
    console.log("... chunk " + T + " finished ...");
}
console.log("FOR LOOP EXITED HERE.");

Try changing some of those values in order to gain more insight.

Here’s another way of approaching it:  In the section that follows, I walk through this single line of code:

for (var N=0; N<10; N=N+1) {
 // interior chunk
}

The FOR LOOP has 3 separate lines crammed into a parenthetical:
a. declaration and assignment of value;
b. conditional;
c. increment variable.

But there is more to it than that. Watch how it executes:

1. Declare a “disposable” variable “N” (Disposable because it will get thrown away when we’re done with the loop!)
3. Set N to 0 (or any starting value you need);
4. Execute a conditional: Is N < 10? (or any limit you want to set);
5. In this case, YES IT IS: The code in the interior chunk is now open to us!
6. When finished with the interior chunk, we leap backwards, returning to the FOR line;
7. Since we finished the second part, we can now move to the third!
8. So: Add ONE to N’s current value.
9. And then BACK to the CONDITIONAL, again.
10. Less than 10? Yep. Interior code opens up to us.
11. Do the interior. Finished? Back to the end of the FOR LOOP.
12. N = N + 1! Now back to the CONDITIONAL.
13. Less than 10? Yup! Interior code, here we come…
14. Until finally, one day, N=N+1 meant than N == 10.
15. So when N was 0, 1, 2, 3, 4, 5, 6, 7, 8, AND 9, we dropped into the interior code.
16. But now, at N==10, N is no long < 10. So we dump out of the FOR LOOP without performing the interior block again.

Finally, here are a few graphic uses of the FOR LOOP.

 

See the Pen ForLoopOne by Garrison LeMasters (@Garrison) on CodePen.dark

And:

See the Pen ForLoopTwo by Garrison LeMasters (@Garrison) on CodePen.

Conditionals

One of the most powerful forms of flow control within a computer program is the Conditional Statement.

What Does It Do?

At its core, a Conditional Statement always does the same thing: It asks a single True or False question.

If the answer to that question is True — and only if it is true — then the computer proceeds down a special temporary path, path B; when it is finished with path B, unless told otherwise, it then returns to path A.

If the answer was false, then the computer never even sees path B — we simply continue down path A, as if nothing happened.  

We can "nest" these statements (put one If() inside another); we can evaluate expressions inside these statements, including boolean operators; and if we want, we can add an additional "secret path" — path C — that the computer only uses if the conditional evaluates as FALSE (instead of TRUE).

What Does It Look Like?

Here's a pseudo-code version of a conditional chunk

Walk();
if (the weather is pleasant) then {
  whistleTune();
}
lookForFlowers();

Here, no matter the weather, I'm going to begin by calling the function Walk(), and I'm going to finish by calling the function lookForFlowers().

If the weather is pleasant, however, then I'm also going to whistle a tune in between those steps. Of course, if the weather is unpleasant, I won't be whistling at all…

Additional Complexity: Nesting

I can NEST my If() statements — that is, put some If() statements inside of other If() statements — just like we do in our daily thought. I can also combine two statements into one line using boolean logic.

Let's go to the video tape:

if (IHavePossession == true) {
  var playerName = findNearestTeammate();
  if (playerName wants ball AND playerName is open) {
    pass playerName the basketball;
    set IHavePossession to FALSE;
  }
}

While If() statements normally only matter if the statement it evaluates is true, I can also add an ELSE statement, which makes the If() statement take a different path when the answer is FALSE. For example:

if (hasGraffiti == false){
  if (numberOfCops == 0){
    spray graffiti();
    go celebrate();
  } else {
    add wall to To Do list();
    return home();
  }
} else {
  take a picture of wall();
  if (hungry) {
    lookForPizzeria();
  }
  return home();
}

This one is a bit more complex: Nested If()s, both with ELSEs. In this code, then, I check to see if the wall already has graffiti sprayed across its surface. If it does, then I take a picture. I then ask, am I hungry, and look for a pizzeria if that is TRUE. Regardless, I end by returning home.

If there was no graffiti, though, I then ask: Are there 0 cops? If that is TRUE, too, then I spray graffiti and celebrate. Note that I only get to spray graffiti when the answers to both of those questions were positive — otherwise, I'll never touch those interior chunks.

If there was no graffiti BUT there were cops in the area, then I add the wall to my To Do List and return home().

Making Sense of What You've Seen

Conditionals always evaluate for the truth of an expression, even if it seems like they don't. Here's an example.

if (today is not windy) {
  reduce kite prices;
}

As far as P5JS is concerned, that statement actually reads:

f it is TRUE that today is not windy, then { reduce kite prices }. Converting this into a few lines of P5JS, here's what we might see:

// wind speed of 20 or greater
// means it is "windy"
var windy = 20;

// run an imaginary function to
// find out current speed of wind
// via online data. Let's pretend
// that it returns the wind speed,
// expressed in miles per hour.
var currentWindSpeed = checkWindSpeed();

if (currentWindSpeed &lt; windy) {
  doPriceReduction();
}

But let's say that the checkWindSpeed() function doesn't work, so we start using checkWeather(). checkWeather(), however, returns a far squishier (less easily quantified) response: "windy", "fair", "nice", "its raining men!", "WTF?", "Did you see that?", etc.

We don't want to know the specifics — there are too many of them — we just want to see if it is NOT windy!

Here's one way:

var n = "windy";
var weatherNow = checkWeather();

if (weatherNow != n) {
  doPriceReduction();
  console.log("Uh-oh.");
} else {
  playSound("cha-ching.mp3");
}

In this case, if weatherNow has any value except for "windy", we'll do a price reduction and see "uh-oh" in the console. If it is "windy", however, we hear a cash register sound.

Evaluation

So what can be evaluated inside those parentheses?

In effect, if (ANYTHING)!

BUT: What can actually be evaluated as TRUE?

Ah, good question. Truthfully, only some things. Look: These ideas are not necessarily self-evident or intuitive. Understanding how conditionals really work means giving in and embracing a logic system that feels a bit alien at first. If you have to, accept this logic first as a matter of faith, and worry about making sense of it later. (Or, wait… isn't that basically a line from Invasion of the Body Snatchers? Hmmm.)

Here's some examples for your consideration.

conditional … evaluates as

if (0) … false

if (1) … true

if (2) … true

if (1-1) … false

if (TRUE) … true

if (False) … false

if ("")… false

if (49-1 == 48)… true

if (49-1 != 40)… true

if (49-1 &gt; 49)… false

Note that the "double equals sign" is called "equivalence" here: It is used when we are ASKING about a value. The "equals sign" is only used when we are actually assigning a value to a variable.

Assigning value:

var n = 10;

Asking about value:

if (n == 10) {
// true chunk
}

Too Many Questions

You will always want to write this, and it will always cause trouble, because this conditional (below) will actually evaluate as TRUE, even though we know 10 is not 100. Why do you suppose this is the case?

var a = 10;
var b = 100;
if (a = b) {
  // will evaluate as true.
  // why?
}

And a special case:

if (false === false) {
  // wait, what?
  // Sigh. Just a special case. You must
  // use 3 ='s when comparing boolean values.
}

Sigh. The three equals signs just mean "equivalence," but you use them when comparing something to a boolean value. Wait… you might not want to read this next one.

Did you enjoy that? Here's a weirder one:

var b = false; // assignment of false to b
if (b === true === false) {
  // This code chunk will run
  // only if the above is true.
  // So will it run?
  // Yes.
  // Yes it will.
  //
  // The statement
  // "b is true"
  // IS a false statement, because
  // we set b to false.
  // so...
  // "b is true IS false" is a TRUE
  // statement.
  // so...
  // the conditional is set to true.
}

No being, just bits

A final example:

var d = color(255,200,15);
if (d) {
  // ... detour
  // code ... will it run?
}

In this case, If(d) is evaluated as TRUE.

Which would prompt any sane person to ask "Wait, how can color be true?" Good question. The answer is a good reminder of what is really happening in our code, rather than the metaphors we use to explain things.

The computer is not saying the "state of being" of the color "is" TRUE. This is not a metaphysical problem. The computer has no capacity (as I understand it) to evaluate a state of being. (This is why so many of our conversations about autonomous cars "choosing" whom to kill in an accident are sophomoric distractions from more important questions).

Pace just about everyone's belief, If() is evaluating a single bit (or a collection of bits, or a series of actions performed on a collection of bits). When we say "If (8), do X," we are asking, at the atomic level, "Are there any positive bits in the binary equivalent of 8, which is 1000." The answer: Yes, there is one bit that has a TRUE value, followed by three FALSE values. Which means, in the end, If(8) is TRUE.

Understanding Custom Functions

This explanation is intended for anyone who isn’t sure they understood our short examples of custom functions.  If you are comfortable with this concept, this material is optional.

This material should be considered as a “draft” of the final copy.

Recall that I described the “vocabulary” that comprises a programming “language” (like P5JS) as the content of a virtual “dictionary:” Every programming language has a dictionary that lists all of the words in that language, and shows what they do. That dictionary may be relatively modest in size (as in P5JS, or JavaScript, or Python) or it may be fairly large (as English, or Tamil). In either case, however, those dictionaries are finite and ultimately limited.  In this way, human languages and programming languages feel fairly similar, fairly solid and unchanging.

There are some notable differences. Human languages are predictably flexible. They can be extended “officially,” for example: The publishers of the venerable Oxford English Dictionary add a few “new words” every year.  And even though this event seems always to generate some excitement online, we can’t help but feel it isn’t as simple as saying “X is a real word now” or “there is no such word as X.”

In other words, that excitement is probably a bit tongue-in-cheek because the way we use language is so unfathomably variable and unpredictable that the idea of limiting vocabulary to a dictionary, or grammar to a book on English grammar, for example, seems ludicrous.  In this way, I think, whereas computer programming languages maintain active and definitive dictionaries that can make your program come alive, for human languages, dictionaries seem to be where words go to die.  It is where they lose a tiny fraction of the flexibility that human beings relish in language.

Consider the complex words that emerge from some quarters of the rap community: These terms often have complex, challenging, and context-bound meanings that defy the print-dictionary-permanance of hyper-literate dictionary culture. To my knowledge, the term “bling,” for example, is first rapped on Dana Dane with Fame (1987), from whence it made its way into a bubbling, dynamic, and mostly-undocumented living language. It is approximately two decades later, when the word is added to publications like Merriam Webster’s Dictionary of the English Language (2006), that the word, in effect, dies: Its flexibility and legitimacy were effectively ruined by the “eternal truth” promised by print. Think, for example, of how painful it was the first time you saw an anchor from Fox News use the term; or when you heard the word used in advertising copy from Sprint or OneMobile.

Adding terms to the vocabulary of a particular computer language is never as nuanced and open-ended as it is for human languages, but it can happen on different levels, too: It may be that the standards body overseeing that language issues an official directive adding a function (i.e., a “word”) to that language.  Imagine a language (let’s call it DataSort) is initially designed to be used for the manipulation of simple text data.  It is fast, and there are only 50 words in its vocabulary, so it is easy to learn.  But as it gets older and more popular, its developers realize that data is becoming more likely to include audio and image information.  DataSort’s users already knew that:  Until that moment, programmers had probably been dealing with this fact on their own, as each one wrote her own custom functions to handle MP3 files and JPGs.

But this meant that there were essentially thousands and thousands of dialects of DataSort, all of which were barely different, but different enough to cause confusion (if you were to submit a data set developed through DataSort for your thesis, for example, everyone would need to know which version of DataSort you’d used to develop that data set; moreover, we’d probably want to be able to reproduce your exact outcomes… but that is less likely if everyone is using their own ephemeral flavor of a language).  So in order to make things uniform, DataSort’s maintainers decide to add official functions that play audio files, video files, or compress images more efficiently.  Suddenly, where everyone had to add a dozen custom functions, we can delete that code and leave that space empty:  The language has expanded, and those new terms are safely out of our way, inside the programming language itself.

When, Why, Where to use custom functions

The first and best reason to write a custom function is just to get code out of your way, so that you can work on other code.  Even if the code you put into that function doesn’t “deserve” its own function (that is, even if that function only gets called ONCE), and therefore doesn’t save any resources by being abstracted into a custom function.  Sometimes cleaning things up is reason enough to adopt a custom function.  Imagine a snippet of code that looks like this:

function draw() {
 do calculation 1;
 do calculation 2;
 do calculation 6;
 subtract calculation 1 from calculation 6;
 show the highest value of calculation 2 so far;
 // now I need to visualize this data...
 //
 }

If you are writing that code, then you are faced with a cluttered desk: Those first 5 lines (in this example) work great, but now you have to write code that is entirely unrelated — a dashboard, a visualization. Here’s how you might clean your desk:

function draw() {
 annoyingCalculations();
 // now I need to visualize this data...
 //
 }

function annoyingCalculations() {
 do calculation 1;
 do calculation 2;
 do calculation 6;
 subtract calculation 1 from calculation 6;
 show the highest value of calculation 2 so far;
 console.log ("Done with the annoyingCalculations() function!");
 // as soon as this last line completes, we'll 
 // bounce right back to where we left off in the draw() loop 
 //-- like we never left.
 }

There’s more to it than that, but that’s the basic stuff: Give the function a name, stick the code inside, and then call the function. Easy peasey lemon squeezy. Of course, the are other reasons to write custom functions than just making your code easier to look at…

From our perspective, as artists writing relatively straightforward programs in JavaScript, P5JS, and Processing/Java, we can add as many custom functions as we like to our code with almost no detectible penalty in code execution (in speed; in available resources). But there are no free lunches: You have to write the functions, after all, and so your time and patience are taxed. As is usually the case, then, the trick is to write code that is flexible and reusable without being overly complex and difficult to maintain.

Let’s say I’m writing code for the dashboard in an autonomous car for UBER, for example. When I’m just getting started, let’s say, I spend all my time test-driving my code (and my car) around inside a huge warehouse. There’s a dashboard in the car for test-drivers, but I don’t have time for that initially. I’m supposed to show potential dangers and obstacles, but for now my visualization just draws ellipses on a map for goals, and draws rectangles to indicate obstacles. rect() and ellipse() are built in, after all: oldLadyCrossingStreet() is not.

After my initial development, though, I need to make things clearer to people testing the car. Early on, my pseudo-code looked like this:

 If there is a pothole, rect();
 If there is an old lady, rect();
 If there is broken glass on the road, rect();
 If there is a duck and ducklings, rect();

Now, of course, that isn’t as useful as it was in the testing warehouse. I could just remove rect() and replace it with all the code required to draw each object… but that would mean that each of those “IF” statements would be separated from all of the others by potentially hundreds of lines of code dedicated to just drawing shapes, and I want to keep those close to one another (for the sake of making it easier to edit and understand my code).

Instead, then, I could create a new function for each of those conditions:

function pothole(){
 // draw a pothole
 // indicate relative depth?
 }

function duckAndDucklings() {
 // draw animated mother duck and ducklings
 // as they cross the street
 }

Then I would have, roughly:

 If there is a pothole, pothole();
 If there is an old lady, drawOldLadyCrossingStreet();
 If there is broken glass on the road, shatteredGlass();
 If there is a duck and ducklings, duckAndDucklings();

Hmmm. 4 new functions. Hmmmm. That probably isn’t the best use of my time. How often do I think I’ll see a mother duck with her ducklings? More to the point, is it really useful to the Uber tester to distinguish between an old lady and a bunch of ducks? I mean, I really should avoid both, right? They are, in essence, the same thing.

So I “abstract” information from the situation, and instead of 4, develop just two custom functions that make use of the two categories I see as useful: In this case, I’ll call them “tempPhysicalObstacleIcon” and “lifeFormIcon”.

function tempPhysicalObstacle() {
 // draw wavy lines on the screen
 // or maybe a caution sign
 // if car gets close, flash once
 }

function lifeFormIcon() {
 // draw a skull with crossbones,
 // animate it to draw attention to it
 // sound buzzer if we get too close
 }

See how those different functions work for more than 1 situation? I.e., we need to do the same things when we see glass on the road or a pothole: Exercise caution. Why spend extra time distinguishing between them?

In fact, the code elsewhere in my imaginary car will probably be similar: The car’s AI will likely be allowed to distinguish between low-level obstacles (glass on the road) and dangerous obstacles (a river; a lake). If need be, after all, I can drive through broken glass, and probably be OK. But my car needs to avoid the river no matter what. These are abstractions that simplify the world “just enough” to write code for it. In the above example, I’ve abstracted — or simplified — the world “just enough” to write only 2 custom functions instead of 4.

Plugging in your custom functions

So where do I insert my custom functions? Anywhere. Literally. You can put them at the start of your code, at the end; you can put them in a seperate file altogether; you can even put them in a file on a different server on a different continent. You’d have to load that file in at the beginning of your program, of course, but the point is that JavaScript is not weighed down by the conventions of literacy, like we are. We like to start at the top of a page and move down; we expect events listed near the top are either more important or more temporally-distant than events at the bottom, which are frequently either less important or more recent. In any event, though, we take the physical position of information as an important (if variable) indicator of value, truthfulness, utility, order, likelihood, and so on. Books taught us that. Newspaper journalism (remember the “inverted pyramid” so valued by print journalism?) taught us that.

Inside of any particular function, physical order typically does matter. There, things (usually) proceed line by line, in consecutive order. BUT if we are just looking at the functions themselves, there is no order. Only setup(), and then draw(), and then draw(), and then draw()… The computer never just wanders into a random function to see what is inside.  It stays out until ordered to do otherwise.  If other functions get called, they always get called explicitly: Where they are on the page doesn’t matter.

Site Update

I’ve just returned from scenic Indiana.  Around 3PM today, I will be able to post the reference material that I was unable to post during the past 3 days:  Flow control (custom functions), conditionals (if/then), and loops (for/next).  There are some recommended exercises at the end, too.