Machines I

Congratulations! You’ve arrived at the final boss of programming. Not necessarily because it’s hard, but because it’s the most important and powerful tool.

I’ve explained how a computer just executes exactly what you type, no more and no less. I’ve explained how you can tell it to repeat a block of code as often as you need. The computer will oblige—without fault. Finally, I’ve shown you how to collect values into a bag, and that any complex program is just bags within bags.

What comes next? What more could we do? We can take the final step towards a “full program”.

All the code examples so far did one thing. They calculated a value. They printed all usernames. They converted highscores to a better value.

In a sense, we created small “machines” for one purpose.

• We feed input to our machine
• It will change it (in the same way every time)
• And then spit back some output.

Because that’s what a machine does. A coffee machine doesn’t refuse to work because it “doesn’t feel like it today”. It also doesn’t suddenly want oil instead of coffee beans as input. A machine always wants the same input and produces the same output.

To get a full program … you simply create many machines and chain them together!

One machine to log in users. Another machine to display their account details. Another machine to load the web page, add interactive buttons, change the colors, etcetera. Every tiny thing your code must do, is a tiny machine that calls other machines.

Define a machine

As always, we need to tell the computer where a machine starts and ends. Like if-statements and loops, we …

• Write a header (with the name of the machine)
• And then indent the code to form a block below it

This … does nothing.

Of course not, because we merely created the machine. Just like buying a coffee machine and placing it on your table does not automatically make coffee appear 😉

To execute it, we need to turn it on and press its buttons. In other words, we need to …

Use a machine

To execute a machine, write use MACHINENAME

Now you can see the power of machines. We can call them from anywhere! We can execute them as often as we want, from any location in the code. We never need to repeat ourselves again!

Just by starting the machine, it happily executes everything inside. And we can call it anywhere, anytime, just by saying its name.

Hopefully, you see the consequences of this. While coding, you can …

• Create very simple machines that do one simple thing. (Which reduces mistakes and makes code easy to read.)
• Call them when needed to get complex behavior

Exercise

Rewrite the loop below to use a machine instead.

Try it yourself first. You can just edit the code block directly. When ready, view my solution below.

Getting output from a machine

When you use a coffee machine, what output do you get? Coffee. When do you get it? At the end.

Programming machines are no different. They do their magic, transforming some data, until they get a final result. This result is given back to whoever called the machine. That’s the output.

This means it is just a value we can play with! We can store the result of a machine in a variable, use it in calculations, whatever.

Machine Name

 => 

Value

This is how you chain machines together. You call one and save the result, then use it however you like. Later on, somebody else might call that machine and use its final output.

Many languages do not “automatically” output the last value. Instead, you must type something like return VAL.

Why? This explicitly returns a value from the machine.

Again, this might feel strict and annoying, but it’s actually good. Forcing programmers to type something fully is often done on purpose. To ensure you don’t accidentally ask the code to do something you didn’t intend.

Functional programming

This may all sound obvious now.

• “Of course you want code to be small and simple!”
• “Of course you never want to repeat yourself and type code twice!”

But many programmers only learn the value of this after years of messing around. They spent years writing bad, slow, hard to read code. (I was one of them. That’s why I’m telling you this now.)

Experienced programmers will tell you that they create machines for everything, all the time. If you code well, every machine is “obvious”.

In other languages, these are called a function or a definition. I chose the word “machine” because it’s more descriptive and intuitive. It explains exactly what it does and how you use it.

This practice is, therefore, called functional programming. Instead of putting your code in one long file, you split it into many tiny “functions” ( = machines). Sometimes, crucial parts of your code are just 5 simple lines of code.

But just using machines isn’t enough.

Notice how we haven’t given input yet. The machines just do the exact same thing every time now! Our machine twoSquared will, as expected, always output the square of two. What if we want to square any number?

Yes, we still need two things:

• A way to provide input
• One extra principle for actually using machines well.

Let’s talk about that in the next chapter …