Think Julia: How to Think Like a Computer Scientist

Julia was originally released in 2012 by Alan Edelman, Stefan Karpinski, Jeff Bezanson, and Viral Shah. It is a free and open source programming language.

Choosing a programming language is always subjective. For me, the following characteristics of Julia are decisive:

Julia is a unique programming language because it solves the so-called "two languages problem." No other programming language is needed to write high-performance code. This does not mean it happens automatically. It is the responsibility of the programmer to optimize the code that forms a bottleneck, but this can done in Julia itself.

This book is for anyone who wants to learn to program. No formal prior knowledge is required.

New concepts are introduced gradually and more advanced topics are described in later chapters.

Think Julia can be used for a one-semester course at the high school or college level.

The following typographical conventions are used in this book:

All code used in this book is available from a Git repository on GitHub: https://github.com/BenLauwens/ThinkJulia.jl. If you are not familiar with Git, it is a version control system that allows you to keep track of the files that make up a project. A collection of files under Git’s control is called a “repository.” GitHub is a hosting service that provides storage for Git repositories and a convenient web interface.

A convenience package is provided that can be directly added to Julia. Just type add https://github.com/BenLauwens/ThinkJulia.jl in the REPL in Pkg mode, see [turtles].

The easiest way to run Julia code is by going to https://juliabox.com and starting a free session. Both the REPL and a notebook interface are available. If you want to have Julia locally installed on your computer, you can download JuliaPro for free from Julia Computing. It consists of a recent Julia version, the Juno interactive development environment based on Atom, and a number of preinstalled Julia packages. If you are more adventurous, you can download Julia from https://julialang.org, install the editor you like (e.g., Atom or Visual Studio Code), and activate the plug-ins for Julia integration. To a local install, you can also add the IJulia package and run a Jupyter notebook on your computer.

I really want to thank Allen for writing Think Python and allowing me to port his book to Julia. Your enthusiasm is contagious!

I would also like to thank the technical reviewers for this book, who made many helpful suggestions: Tim Besard, Bart Janssens, and David P. Sanders.

Thanks to Melissa Potter from O’Reilly Media, who made this a better book. You forced me to do things right and make this book as original as possible.

Thanks to Matt Hacker from O’Reilly Media, who helped me out with the Atlas toolchain and some syntax highlighting issues.

Thanks to all the students who worked with an early version of this book and all the contributors (listed below) who sent in corrections and suggestions.

If you have a suggestion or correction, please send email to ben.lauwens@gmail.com or open an issue on GitHub. If I make a change based on your feedback, I will add you to the contributor list (unless you ask to be omitted).

Let me know what version of the book you are working with, and what format. If you include at least part of the sentence the error appears in, that will make it easy for me to search. Page and section numbers are fine, too, but not quite as easy to work with. Thanks!

An assignment statement creates a new variable and gives it a value:

This example makes three assignments. The first assigns a string to a new variable named message; the second gives the integer 17 to n; the third assigns the (approximate) value of \(\pi\) to π_val (\pi TAB).

A common way to represent variables on paper is to write the name with an arrow pointing to its value. This kind of figure is called a state diagram because it shows what state each of the variables is in (think of it as the variable’s state of mind). State diagram shows the result of the previous example.

Programmers generally choose names for their variables that are meaningful—they document what the variable is used for.

Variable names can be as long as you like. They can contain almost all Unicode characters (see Characters), but they can’t begin with a number. It is legal to use uppercase letters, but it is conventional to use only lower case for variable names.

Unicode characters can be entered via tab completion of LaTeX-like abbreviations in the Julia REPL.

The underscore character, _, can appear in a name. It is often used in names with multiple words, such as your_name or airspeed_of_unladen_swallow.

If you give a variable an illegal name, you get a syntax error:

76trombones is illegal because it begins with a number. more@ is illegal because it contains an illegal character, @. But what’s wrong with struct?

It turns out that struct is one of Julia’s keywords. The REPL uses keywords to recognize the structure of the program, and they cannot be used as variable names.

Julia has these keywords:

You don’t have to memorize this list. In most development environments, keywords are displayed in a different color; if you try to use one as a variable name, you’ll know.

An expression is a combination of values, variables, and operators. A value all by itself is considered an expression, and so is a variable, so the following are all legal expressions:

When you type an expression at the prompt, the REPL evaluates it, which means that it finds the value of the expression. In this example, n has the value 17 and n + 25 has the value 42.

A statement is a unit of code that has an effect, like creating a variable or displaying a value.

The first line is an assignment statement that gives a value to n. The second line is a print statement that displays the value of n.

When you type a statement, the REPL executes it, which means that it does whatever the statement says.

So far we have run Julia in interactive mode, which means that you interact directly with the REPL. Interactive mode is a good way to get started, but if you are working with more than a few lines of code, it can be clumsy.

The alternative is to save code in a file called a script and then run Julia in script mode to execute the script. By convention, Julia scripts have names that end with .jl.

If you know how to create and run a script on your computer, you are ready to go. Otherwise I recommend using JuliaBox again. Open a text file, write the script and save with a .jl extension. The script can be executed in a terminal with the command julia name_of_the_script.jl.

Because Julia provides both modes, you can test bits of code in interactive mode before you put them in a script. But there are differences between interactive mode and script mode that can be confusing.

For example, if you are using Julia as a calculator, you might type

The first line assigns a value to miles and displays the value. The second line is an expression, so the REPL evaluates it and displays the result. It turns out that a marathon is about 42 kilometers.

But if you type the same code into a script and run it, you get no output at all. In script mode an expression, all by itself, has no visible effect. Julia actually evaluates the expression, but it doesn’t display the value unless you tell it to:

This behavior can be confusing at first.

A script usually contains a sequence of statements. If there is more than one statement, the results appear one at a time as the statements execute.

For example, the script

produces the output

The assignment statement produces no output.

When an expression contains more than one operator, the order of evaluation depends on the operator precedence. For mathematical operators, Julia follows mathematical convention. The acronym PEMDAS is a useful way to remember the rules:

In general, you can’t perform mathematical operations on strings, even if the strings look like numbers, so the following are illegal:

But there are two exceptions, * and ^.

The * operator performs string concatenation, which means it joins the strings by linking them end-to-end. For example:

The ^ operator also works on strings; it performs repetition. For example, "Spam"^3 is "SpamSpamSpam". If one of the values is a string, the other has to be an integer.

This use of * and ^ makes sense by analogy with multiplication and exponentiation. Just as 4^3 is equivalent to 4*4*4, we expect "Spam"^3 to be the same as "Spam"*"Spam"*"Spam", and it is.

As programs get bigger and more complicated, they get more difficult to read. Formal languages are dense, and it is often difficult to look at a piece of code and figure out what it is doing, or why.

For this reason, it is a good idea to add notes to your programs to explain in natural language what the program is doing. These notes are called comments, and they start with the # symbol:

In this case, the comment appears on a line by itself. You can also put comments at the end of a line:

Everything from the # to the end of the line is ignored—it has no effect on the execution of the program.

Comments are most useful when they document non-obvious features of the code. It is reasonable to assume that the reader can figure out what the code does; it is more useful to explain why.

This comment is redundant with the code and useless:

This comment contains useful information that is not in the code:

Three kinds of errors can occur in a program: syntax errors, runtime errors, and semantic errors. It is useful to distinguish between them in order to track them down more quickly.

We have already seen one example of a function call:

The name of the function is println. The expression in parentheses is called the argument of the function.

It is common to say that a function “takes” an argument and “returns” a result. The result is also called the return value.

Julia provides functions that convert values from one type to another. The parse function takes a string and converts it to any number type, if it can, or complains otherwise:

trunc can convert floating-point values to integers, but it doesn’t round off; it chops off the fraction part:

float converts integers to floating-point numbers:

Finally, string converts its argument to a string:

In Julia, most of the familiar mathematical functions are directly available:

This first example uses log10 to compute a signal-to-noise ratio in decibels (assuming that signal_power and noise_power are defined). log, which computes natural logarithms, is also provided.

This second example finds the sine of radians. The name of the variable is a hint that sin and the other trigonometric functions (cos, tan, etc.) take arguments in radians. To convert from degrees to radians, divide by 180 and multiply by \(\pi\):

The value of the variable π is a floating-point approximation of \(\pi\), accurate to about 16 digits.

If you know trigonometry, you can check the previous result by comparing it to the square root of two divided by two:

So far, we have looked at the elements of a program—variables, expressions, and statements—in isolation, without talking about how to combine them.

One of the most useful features of programming languages is their ability to take small building blocks and compose them. For example, the argument of a function can be any kind of expression, including arithmetic operators:

And even function calls:

Almost anywhere you can put a value, you can put an arbitrary expression, with one exception: the left side of an assignment statement has to be a variable name. Any other expression on the left side is a syntax error (we will see exceptions to this rule later).

So far, we have only been using the functions that come with Julia, but it is also possible to add new functions. A function definition specifies the name of a new function and the sequence of statements that run when the function is called. Here is an example:

function is a keyword that indicates that this is a function definition. The name of the function is printlyrics. The rules for function names are the same as for variable names: they can contain almost all Unicode characters (see Characters), but the first character can’t be a number. You can’t use a keyword as the name of a function, and you should avoid having a variable and a function with the same name.

The empty parentheses after the name indicate that this function doesn’t take any arguments.

The first line of the function definition is called the header; the rest is called the body. The body is terminated with the keyword end and it can contain any number of statements. For readability the body of the function should be indented.

The quotation marks must be “straight quotes”, usually located next to Enter on the keyboard. “Curly quotes”, like the ones in this sentence, are not legal in Julia.

If you type a function definition in interactive mode, the REPL indents to let you know that the definition isn’t complete:

To end the function, you have to enter end.

The syntax for calling the new function is the same as for built-in functions:

Once you have defined a function, you can use it inside another function. For example, to repeat the previous refrain, we could write a function called repeatlyrics:

And then call repeatlyrics:

But that’s not really how the song goes.

Pulling together the code fragments from the previous section, the whole program looks like this:

This program contains two function definitions: printlyrics and repeatlyrics. Function definitions get executed just like other statements, but the effect is to create function objects. The statements inside the function do not run until the function is called, and the function definition generates no output.

As you might expect, you have to create a function before you can run it. In other words, the function definition has to run before the function gets called.

To ensure that a function is defined before its first use, you have to know the order statements run in, which is called the flow of execution.

Execution always begins at the first statement of the program. Statements are run one at a time, in order from top to bottom.

Function definitions do not alter the flow of execution of the program, but remember that statements inside the function don’t run until the function is called.

A function call is like a detour in the flow of execution. Instead of going to the next statement, the flow jumps to the body of the function, runs the statements there, and then comes back to pick up where it left off.

That sounds simple enough, until you remember that one function can call another. While in the middle of one function, the program might have to run the statements in another function. Then, while running that new function, the program might have to run yet another function!

Fortunately, Julia is good at keeping track of where it is, so each time a function completes, the program picks up where it left off in the function that called it. When it gets to the end of the program, it terminates.

In summary, when you read a program, you don’t always want to read from top to bottom. Sometimes it makes more sense if you follow the flow of execution.

Some of the functions we have seen require arguments. For example, when you call sin you pass a number as an argument. Some functions take more than one argument: parse takes two, a number type and a string.

Inside the function, the arguments are assigned to variables called parameters. Here is a definition for a function that takes an argument:

This function assigns the argument to a parameter named bruce. When the function is called, it prints the value of the parameter (whatever it is) twice.

This function works with any value that can be printed.

The same rules of composition that apply to built-in functions also apply to programmer-defined functions, so we can use any kind of expression as an argument for printtwice:

The argument is evaluated before the function is called, so in the examples the expressions "Spam "^4 and cos(π) are only evaluated once.

You can also use a variable as an argument:

The name of the variable we pass as an argument (michael) has nothing to do with the name of the parameter (bruce). It doesn’t matter what the value was called back home (in the caller); here in printtwice, we call everybody bruce.

When you create a variable inside a function, it is local, which means that it only exists inside the function. For example:

This function takes two arguments, concatenates them, and prints the result twice. Here is an example that uses it:

When cattwice terminates, the variable concat is destroyed. If we try to print it, we get an exception:

Parameters are also local. For example, outside printtwice, there is no such thing as bruce.

To keep track of which variables can be used where, it is sometimes useful to draw a stack diagram. Like state diagrams, stack diagrams show the value of each variable, but they also show the function each variable belongs to.

Each function is represented by a frame. A frame is a box with the name of a function beside it and the parameters and variables of the function inside it. The stack diagram for the previous example is shown in Stack diagram.

The frames are arranged in a stack that indicates which function called which, and so on. In this example, printtwice was called by cattwice, and cattwice was called by Main, which is a special name for the topmost frame. When you create a variable outside of any function, it belongs to Main.

Each parameter refers to the same value as its corresponding argument. So, part1 has the same value as line1, part2 has the same value as line2, and bruce has the same value as concat.

If an error occurs during a function call, Julia prints the name of the function, the name of the function that called it, and the name of the function that called that, all the way back to Main.

For example, if you try to access concat from within printtwice, you get a UndefVarError:

This list of functions is called a stacktrace. It tells you what program file the error occurred in, and what line, and what functions were executing at the time. It also shows the line of code that caused the error.

The order of the functions in the stacktrace is the inverse of the order of the frames in the stack diagram. The function that is currently running is at the top.

Some of the functions we have used, such as the math functions, return results; for lack of a better name, I call them fruitful functions. Other functions, like printtwice, perform an action but don’t return a value. They are called void functions.

When you call a fruitful function, you almost always want to do something with the result; for example, you might assign it to a variable or use it as part of an expression:

When you call a function in interactive mode, Julia displays the result:

But in a script, if you call a fruitful function all by itself, the return value is lost forever!

Output:

This script computes the square root of 5, but since it doesn’t store or display the result, it is not very useful.

Void functions might display something on the screen or have some other effect, but they don’t have a return value. If you assign the result to a variable, you get a special value called nothing.

To print the value nothing, you have to use the function show which is like print but can handle the value nothing.

The value nothing is not the same as the string "nothing". It is a special value that has its own type:

The functions we have written so far are all void. We will start writing fruitful functions in a few chapters.

It may not be clear why it is worth the trouble to divide a program into functions. There are several reasons:

One of the most important skills you will acquire is debugging. Although it can be frustrating, debugging is one of the most intellectually rich, challenging, and interesting parts of programming.

In some ways debugging is like detective work. You are confronted with clues and you have to infer the processes and events that led to the results you see.

Debugging is also like an experimental science. Once you have an idea about what is going wrong, you modify your program and try again. If your hypothesis was correct, you can predict the result of the modification, and you take a step closer to a working program. If your hypothesis was wrong, you have to come up with a new one. As Sherlock Holmes pointed out,

For some people, programming and debugging are the same thing. That is, programming is the process of gradually debugging a program until it does what you want. The idea is that you should start with a working program and make small modifications, debugging them as you go.

For example, Linux is an operating system that contains millions of lines of code, but it started out as a simple program Linus Torvalds used to explore the Intel 80386 chip. According to Larry Greenfield, “One of Linus’s earlier projects was a program that would switch between printing “AAAA” and “BBBB”. This later evolved to Linux.” (The Linux Users’ Guide Beta Version 1).

A module is a file that contains a collection of related functions. Julia provides some modules in its Standard Library. Additional functionality can be added from a growing collection of packages (https://juliaobserver.com).

Packages can be installed in the REPL by entering the Pkg REPL-mode using the key ].

This can take some time.

Before we can use the functions in a module, we have to import it with an using statement:

The ThinkJulia module provides a function called Turtle that creates a Luxor.Turtle object, which we assign to a variable named 🐢 (\:turtle: TAB).

Once you create a turtle, you can call a function to move it around a drawing. For example, to move the turtle forward:

The @svg keyword runs a macro that draws a SVG picture. Macros are an important but advanced feature of Julia.

The arguments of forward are the turtle and a distance in pixels, so the actual size depends on your display.

Another function you can call with a turtle as argument is turn for turning. The second argument for turn is an angle in degrees.

Also, each turtle is holding a pen, which is either down or up; if the pen is down, the turtle leaves a trail when it moves. Moving the turtle forward shows the trail left behind by the turtle. The functions penup and pendown stand for “pen up” and “pen down”.

To draw a right angle, modify the macro call:

Chances are you wrote something like this:

We can do the same thing more concisely with a for statement:

This is the simplest use of the for statement; we will see more later. But that should be enough to let you rewrite your square-drawing program. Don’t go on until you do.

Here is a for statement that draws a square:

The syntax of a for statement is similar to a function definition. It has a header and a body that ends with the keyword end. The body can contain any number of statements.

A for statement is also called a loop because the flow of execution runs through the body and then loops back to the top. In this case, it runs the body four times.

This version is actually a little different from the previous square-drawing code because it makes another turn after drawing the last side of the square. The extra turn takes more time, but it simplifies the code if we do the same thing every time through the loop. This version also has the effect of leaving the turtle back in the starting position, facing in the starting direction.

The following is a series of exercises using turtles. They are meant to be fun, but they have a point, too. While you are working on them, think about what the point is.

The first exercise asks you to put your square-drawing code into a function definition and then call the function, passing the turtle as a parameter. Here is a solution:

The innermost statements, forward and turn are indented twice to show that they are inside the for loop, which is inside the function definition.

Inside the function, t refers to the same turtle 🐢, so turn(t, -90) has the same effect as turn(🐢, -90). In that case, why not call the parameter 🐢? The idea is that t can be any turtle, not just 🐢, so you could create a second turtle and pass it as an argument to square:

Wrapping a piece of code up in a function is called encapsulation. One of the benefits of encapsulation is that it attaches a name to the code, which serves as a kind of documentation. Another advantage is that if you re-use the code, it is more concise to call a function twice than to copy and paste the body!

The next step is to add a len parameter to square. Here is a solution:

Adding a parameter to a function is called generalization because it makes the function more general: in the previous version, the square is always the same size; in this version it can be any size.

The next step is also a generalization. Instead of drawing squares, polygon draws regular polygons with any number of sides. Here is a solution:

This example draws a 7-sided polygon with side length 70.

The next step is to write circle, which takes a radius, r, as a parameter. Here is a simple solution that uses polygon to draw a 50-sided polygon:

The first line computes the circumference of a circle with radius \(r\) using the formula \(2 \pi r\). n is the number of line segments in our approximation of a circle, so len is the length of each segment. Thus, polygon draws a 50-sided polygon that approximates a circle with radius r.

One limitation of this solution is that n is a constant, which means that for very big circles, the line segments are too long, and for small circles, we waste time drawing very small segments. One solution would be to generalize the function by taking n as a parameter. This would give the user (whoever calls circle) more control, but the interface would be less clean.

The interface of a function is a summary of how it is used: what are the parameters? What does the function do? And what is the return value? An interface is “clean” if it allows the caller to do what they want without dealing with unnecessary details.

In this example, r belongs in the interface because it specifies the circle to be drawn. n is less appropriate because it pertains to the details of how the circle should be rendered.

Rather than clutter up the interface, it is better to choose an appropriate value of n depending on circumference:

Now the number of segments is an integer near circumference/3, so the length of each segment is approximately 3, which is small enough that the circles look good, but big enough to be efficient, and acceptable for any size circle.

Adding 3 to n guarantees that the polygon has at least 3 sides.

When I wrote circle, I was able to re-use polygon because a many-sided polygon is a good approximation of a circle. But arc is not as cooperative; we can’t use polygon or circle to draw an arc.

One alternative is to start with a copy of polygon and transform it into arc. The result might look like this:

The second half of this function looks like polygon, but we can’t re-use polygon without changing the interface. We could generalize polygon to take an angle as a third argument, but then polygon would no longer be an appropriate name! Instead, let’s call the more general function polyline:

Now we can rewrite polygon and arc to use polyline:

Finally, we can rewrite circle to use arc:

This process—rearranging a program to improve interfaces and facilitate code re-use—is called refactoring. In this case, we noticed that there was similar code in arc and polygon, so we “factored it out” into polyline.

If we had planned ahead, we might have written polyline first and avoided refactoring, but often you don’t know enough at the beginning of a project to design all the interfaces. Once you start coding, you understand the problem better. Sometimes refactoring is a sign that you have learned something.

A development plan is a process for writing programs. The process we used in this case study is “encapsulation and generalization”. The steps of this process are:

This process has some drawbacks—we will see alternatives later—but it can be useful if you don’t know ahead of time how to divide the program into functions. This approach lets you design as you go along.

A docstring is a string before a function that explains the interface (“doc” is short for “documentation”). Here is an example:

Documentation can be accessed in the REPL or in a notebook by typing ? followed by the name of a function or macro, and pressing ENTER:

Docstrings are often triple-quoted strings, also known as multiline strings because the triple quotes allow the string to span more than one line.

A docstring contains the essential information someone would need to use this function. It explains concisely what the function does (without getting into the details of how it does it). It explains what effect each parameter has on the behavior of the function and what type each parameter should be (if it is not obvious).

An interface is like a contract between a function and a caller. The caller agrees to provide certain parameters and the function agrees to do certain work.

For example, polyline requires four arguments: t has to be a turtle; n has to be an integer; len should be a positive number; and angle has to be a number, which is understood to be in degrees.

These requirements are called preconditions because they are supposed to be true before the function starts executing. Conversely, conditions at the end of the function are postconditions. Postconditions include the intended effect of the function (like drawing line segments) and any side effects (like moving the turtle or making other changes).

Preconditions are the responsibility of the caller. If the caller violates a (properly documented!) precondition and the function doesn’t work correctly, the bug is in the caller, not the function.

If the preconditions are satisfied and the postconditions are not, the bug is in the function. If your pre- and postconditions are clear, they can help with debugging.

The floor division operator, ÷ (\div TAB), divides two numbers and rounds down to an integer. For example, suppose the run time of a movie is 105 minutes. You might want to know how long that is in hours. Conventional division returns a floating-point number:

But we don’t normally write hours with decimal points. Floor division returns the integer number of hours, rounding down:

To get the remainder, you could subtract off one hour in minutes:

An alternative is to use the modulus operator, %, which divides two numbers and returns the remainder.

A boolean expression is an expression that is either true or false. The following examples use the operator ==, which compares two operands and produces true if they are equal and false otherwise:

true and false are special values that belong to the type Bool; they are not strings:

The == operator is one of the relational operators; the others are:

There are three logical operators: && (and), || (or), and ! (not). The semantics (meaning) of these operators is similar to their meaning in English. For example, x > 0 && x < 10 is true only if x is greater than 0 and less than 10.

n % 2 == 0 || n % 3 == 0 is true if either or both of the conditions is true, that is, if the number is divisible by 2 or 3.

Both && and || associate to the right, but && has higher precedence than || does.

Finally, the ! operator negates a boolean expression, so !(x > y) is true if x > y is false, that is, if x is less than or equal to y.

In order to write useful programs, we almost always need the ability to check conditions and change the behavior of the program accordingly. Conditional statements give us this ability. The simplest form is the if statement:

The boolean expression after if is called the condition. If it is true, the indented statement runs. If not, nothing happens.

if statements have the same structure as function definitions: a header followed by body terminated with the keyword end. Statements like this are called compound statements.

There is no limit on the number of statements that can appear in the body. Occasionally, it is useful to have a body with no statements (usually as a place keeper for code you haven’t written yet).

A second form of the if statement is “alternative execution”, in which there are two possibilities and the condition determines which one runs. The syntax looks like this:

If the remainder when x is divided by 2 is 0, then we know that x is even, and the program displays an appropriate message. If the condition is false, the second set of statements runs. Since the condition must be true or false, exactly one of the alternatives will run. The alternatives are called branches, because they are branches in the flow of execution.

Sometimes there are more than two possibilities and we need more than two branches. One way to express a computation like that is a chained conditional:

Again, exactly one branch will run. There is no limit on the number of elseif statements. If there is an else clause, it has to be at the end, but there doesn’t have to be one.

Each condition is checked in order. If the first is false, the next is checked, and so on. If one of them is true, the corresponding branch runs and the statement ends. Even if more than one condition is true, only the first true branch runs.

One conditional can also be nested within another. We could have written the example in the previous section like this:

The outer conditional contains two branches. The first branch contains a simple statement. The second branch contains another if statement, which has two branches of its own. Those two branches are both simple statements, although they could have been conditional statements as well.

Although the non-compulsory indentation of the statements makes the structure apparent, nested conditionals become difficult to read very quickly. It is a good idea to avoid them when you can.

Logical operators often provide a way to simplify nested conditional statements. For example, we can rewrite the following code using a single conditional:

The print statement runs only if we make it past both conditionals, so we can get the same effect with the && operator:

For this kind of condition, Julia provides a more concise syntax:

It is legal for one function to call another; it is also legal for a function to call itself. It may not be obvious why that is a good thing, but it turns out to be one of the most magical things a program can do. For example, look at the following function:

If n is 0 or negative, it outputs the word, "Blastoff!" Otherwise, it outputs n and then calls a function named countdown—itself—passing n-1 as an argument.

What happens if we call this function like this?

The execution of countdown begins with n = 3, and since n is greater than 0, it outputs the value 3, and then calls itself …​

 The execution of countdown begins with n = 2, and since n is greater than 0,
  it outputs the value 2, and then calls itself …​

  The execution of countdown begins with n = 1, and since n is greater than 0,
   it outputs the value 1, and then calls itself …​

   The execution of countdown begins with n = 0, and since n is not greater than
    0, it outputs the word, "Blastoff!" and then returns.

  The countdown that got n = 1 returns.

 The countdown that got n = 2 returns.

The countdown that got n = 3 returns.

And then you’re back in Main.

A function that calls itself is recursive; the process of executing it is called recursion.

As another example, we can write a function that prints a string \(n\) times.

If n <= 0 the return statement exits the function. The flow of execution immediately returns to the caller, and the remaining lines of the function don’t run.

The rest of the function is similar to countdown: it displays s and then calls itself to display s \(n-1\) additional times. So the number of lines of output is \(1 + (n - 1)\), which adds up to \(n\).

For simple examples like this, it is probably easier to use a for loop. But we will see examples later that are hard to write with a for loop and easy to write with recursion, so it is good to start early.

In Stack Diagrams, we used a stack diagram to represent the state of a program during a function call. The same kind of diagram can help interpret a recursive function.

Every time a function gets called, Julia creates a frame to contain the function’s local variables and parameters. For a recursive function, there might be more than one frame on the stack at the same time.

Stack diagram shows a stack diagram for countdown called with n = 3.

As usual, the top of the stack is the frame for Main. It is empty because we did not create any variables in Main or pass any arguments to it.

The four countdown frames have different values for the parameter n. The bottom of the stack, where n = 0, is called the base case. It does not make a recursive call, so there are no more frames.

If a recursion never reaches a base case, it goes on making recursive calls forever, and the program never terminates. This is known as infinite recursion, and it is generally not a good idea. Here is a minimal program with an infinite recursion:

In most programming environments, a program with infinite recursion does not really run forever. Julia reports an error message when the maximum recursion depth is reached:

This stacktrace is a little bigger than the one we saw in the previous chapter. When the error occurs, there are 80000 recurse frames on the stack!

If you encounter an infinite recursion by accident, review your function to confirm that there is a base case that does not make a recursive call. And if there is a base case, check whether you are guaranteed to reach it.

The programs we have written so far accept no input from the user. They just do the same thing every time.

Julia provides a built-in function called readline that stops the program and waits for the user to type something. When the user presses RETURN or ENTER, the program resumes and readline returns what the user typed as a string.

Before getting input from the user, it is a good idea to print a prompt telling the user what to type:

A semi-colon ; allows to put multiple statements on the same line. In the REPL only the last statement returns its value.

If you expect the user to type an integer, you can try to convert the return value to Int64:

But if the user types something other than a string of digits, you get an error:

We will see how to handle this kind of error later.

When a syntax or runtime error occurs, the error message contains a lot of information, but it can be overwhelming. The most useful parts are usually:

Syntax errors are usually easy to find, but there are a few gotchas. In general, error messages indicate where the problem was discovered, but the actual error might be earlier in the code, sometimes on a previous line.

The same is true of runtime errors. Suppose you are trying to compute a signal-to-noise ratio in decibels. The formula is

In Julia, you might write something like this:

And you get:

This is not the result you expected.

To find the error, it might be useful to print the value of ratio, which turns out to be 0. The problem is in line 3, which uses floor division instead of floating-point division.

Calling the function generates a return value, which we usually assign to a variable or use as part of an expression.

The functions we have written so far are void. Speaking casually, they have no return value; more precisely, their return value is nothing. In this chapter, we are (finally) going to write fruitful functions. The first example is area, which returns the area of a circle with the given radius:

We have seen the return statement before, but in a fruitful function the return statement includes an expression. This statement means: “Return immediately from this function and use the following expression as a return value.” The expression can be arbitrarily complicated, so we could have written this function more concisely:

The value returned by a function is the value of the last expression evaluated, which, by default, is the last expression in the body of the function definition.

On the other hand, temporary variables like a and explicit return statements can make debugging easier.

Sometimes it is useful to have multiple return statements, one in each branch of a conditional:

Since these return statements are in an alternative conditional, only one runs.

As soon as a return statement runs, the function terminates without executing any subsequent statements. Code that appears after a return statement, or any other place the flow of execution can never reach, is called dead code.

In a fruitful function, it is a good idea to ensure that every possible path through the program hits a return statement. For example:

This function is incorrect because if x happens to be 0, neither condition is true, and the function ends without hitting a return statement. If the flow of execution gets to the end of a function, the return value is nothing, which is not the absolute value of 0.

As you write larger functions, you might find yourself spending more time debugging.

To deal with increasingly complex programs, you might want to try a process called incremental development. The goal of incremental development is to avoid long debugging sessions by adding and testing only a small amount of code at a time.

As an example, suppose you want to find the distance between two points, given by the coordinates \(\left(x_1, y_1\right)\) and \(\left(x_2, y_2\right)\). By the Pythagorean theorem, the distance is:

The first step is to consider what a distance function should look like in Julia. In other words, what are the inputs (parameters) and what is the output (return value)?

In this case, the inputs are two points, which you can represent using four numbers. The return value is the distance represented by a floating-point value.

Immediately you can write an outline of the function:

Obviously, this version doesn’t compute distances; it always returns zero. But it is syntactically correct, and it runs, which means that you can test it before you make it more complicated. The subscript numbers are available in the Unicode character encoding (\_1 TAB, \_2 TAB, etc.).

To test the new function, call it with sample arguments:

I chose these values so that the horizontal distance is 3 and the vertical distance is 4; that way, the result is 5, the hypotenuse of a 3-4-5 triangle. When testing a function, it is useful to know the right answer.

At this point we have confirmed that the function is syntactically correct, and we can start adding code to the body. A reasonable next step is to find the differences \(x_2 - x_1\) and \(y_2 - y_1\). The next version stores those values in temporary variables and prints them with the @show macro.

If the function is working, it should display dx = 3 and dy = 4. If so, we know that the function is getting the right arguments and performing the first computation correctly. If not, there are only a few lines to check.

Next we compute the sum of squares of dx and dy:

Again, you would run the program at this stage and check the output (which should be 25). Superscript numbers are also available (\^2 TAB). Finally, you can use sqrt to compute and return the result:

If that works correctly, you are done. Otherwise, you might want to print the value of sqrt(d²) before the return statement.

The final version of the function doesn’t display anything when it runs; it only returns a value. The print statements we wrote are useful for debugging, but once you get the function working, you should remove them. Code like that is called scaffolding because it is helpful for building the program but is not part of the final product.

When you start out, you should add only a line or two of code at a time. As you gain more experience, you might find yourself writing and debugging bigger chunks. Either way, incremental development can save you a lot of debugging time.

The key aspects of the process are:

As you should expect by now, you can call one function from within another. As an example, we’ll write a function that takes two points, the center of the circle and a point on the perimeter, and computes the area of the circle.

Assume that the center point is stored in the variables xc and yc, and the perimeter point is in xp and yp. The first step is to find the radius of the circle, which is the distance between the two points. We just wrote a function, distance, that does that:

The next step is to find the area of a circle with that radius; we just wrote that, too:

Encapsulating these steps in a function, we get:

The temporary variables radius and result are useful for development and debugging, but once the program is working, we can make it more concise by composing the function calls:

Functions can return booleans, which is often convenient for hiding complicated tests inside functions. For example:

It is common to give boolean functions names that sound like yes/no questions; isdivisible returns either true or false to indicate whether x is divisible by y.

Here is an example:

The result of the == operator is a boolean, so we can write the function more concisely by returning it directly:

Boolean functions are often used in conditional statements:

It might be tempting to write something like:

But the extra comparison with true is unnecessary.

We have only covered a small subset of Julia, but you might be interested to know that this subset is a complete programming language, which means that anything that can be computed can be expressed in this language. Any program ever written could be rewritten using only the language features you have learned so far (actually, you would need a few commands to control devices like the mouse, disks, etc., but that’s all).

Proving that claim is a nontrivial exercise first accomplished by Alan Turing, one of the first computer scientists (some would argue that he was a mathematician, but a lot of early computer scientists started as mathematicians). Accordingly, it is known as the Turing Thesis. For a more complete (and accurate) discussion of the Turing Thesis, I recommend Michael Sipser’s book Introduction to the Theory of Computation.

To give you an idea of what you can do with the tools you have learned so far, we’ll evaluate a few recursively defined mathematical functions. A recursive definition is similar to a circular definition, in the sense that the definition contains a reference to the thing being defined. A truly circular definition is not very useful:

If you saw that definition in the dictionary, you might be annoyed. On the other hand, if you looked up the definition of the factorial function, denoted with the symbol \(!\), you might get something like this:

This definition says that the factorial of 0 is 1, and the factorial of any other value, \(n\), is \(n\) multiplied by the factorial of \(n-1\).

So \(3!\) is 3 times \(2!\), which is 2 times \(1!\), which is 1 times \(0!\). Putting it all together, \(3!\) equals 3 times 2 times 1 times 1, which is 6.

If you can write a recursive definition of something, you can write a Julia program to evaluate it. The first step is to decide what the parameters should be. In this case it should be clear that factorial takes an integer:

If the argument happens to be 0, all we have to do is return 1:

Otherwise, and this is the interesting part, we have to make a recursive call to find the factorial of n-1 and then multiply it by n:

The flow of execution for this program is similar to the flow of countdown in Recursion. If we call fact with the value 3:

Stack diagram shows what the stack diagram looks like for this sequence of function calls.

The return values are shown being passed back up the stack. In each frame, the return value is the value of result, which is the product of n and recurse.

In the last frame, the local variables recurse and result do not exist, because the branch that creates them does not run.

Following the flow of execution is one way to read programs, but it can quickly become overwhelming. An alternative is what I call the “leap of faith”. When you come to a function call, instead of following the flow of execution, you assume that the function works correctly and returns the right result.

In fact, you are already practicing this leap of faith when you use built-in functions. When you call cos or exp, you don’t examine the bodies of those functions. You just assume that they work because the people who wrote the built-in functions were good programmers.

The same is true when you call one of your own functions. For example, in Boolean Functions, we wrote a function called isdivisible that determines whether one number is divisible by another. Once we have convinced ourselves that this function is correct—by examining the code and testing—we can use the function without looking at the body again.

The same is true of recursive programs. When you get to the recursive call, instead of following the flow of execution, you should assume that the recursive call works (returns the correct result) and then ask yourself, “Assuming that I can find the factorial of \(n-1\), can I compute the factorial of \(n\)?” It is clear that you can, by multiplying by \(n\).

Of course, it’s a bit strange to assume that the function works correctly when you haven’t finished writing it, but that’s why it’s called a leap of faith!

After factorial, the most common example of a recursively defined mathematical function is fibonacci, which has the following definition (see https://en.wikipedia.org/wiki/Fibonacci_number):

Translated into Julia, it looks like this:

If you try to follow the flow of execution here, even for fairly small values of n, your head explodes. But according to the leap of faith, if you assume that the two recursive calls work correctly, then it is clear that you get the right result by adding them together.

What happens if we call fact and give it 1.5 as an argument?

It looks like an infinite recursion. How can that be? The function has a base case—when n == 0. But if n is not an integer, we can miss the base case and recurse forever.

In the first recursive call, the value of n is 0.5. In the next, it is -0.5. From there, it gets smaller (more negative), but it will never be 0.

We have two choices. We can try to generalize the factorial function to work with floating-point numbers, or we can make fact check the type of its argument. The first option is called the gamma function and it’s a little beyond the scope of this book. So we’ll go for the second.

We can use the built-in operator isa to verify the type of the argument. While we’re at it, we can also make sure the argument is positive:

The first base case handles nonintegers; the second handles negative integers. In both cases, the program prints an error message and returns nothing to indicate that something went wrong:

If we get past both checks, we know that n is positive or zero, so we can prove that the recursion terminates.

This program demonstrates a pattern sometimes called a guardian. The first two conditionals act as guardians, protecting the code that follows from values that might cause an error. The guardians make it possible to prove the correctness of the code.

In Catching Exceptions we will see a more flexible alternative to printing an error message: raising an exception.

Breaking a large program into smaller functions creates natural checkpoints for debugging. If a function is not working, there are three possibilities to consider:

To rule out the first possibility, you can add a print statement at the beginning of the function and display the values of the parameters (and maybe their types). Or you can write code that checks the preconditions explicitly.

If the parameters look good, add a print statement before each return statement and display the return value. If possible, check the result by hand. Consider calling the function with values that make it easy to check the result (as in Incremental Development).

If the function seems to be working, look at the function call to make sure the return value is being used correctly (or used at all!).

Adding print statements at the beginning and end of a function can help make the flow of execution more visible. For example, here is a version of fact with print statements:

space is a string of space characters that controls the indentation of the output:

If you are confused about the flow of execution, this kind of output can be helpful. It takes some time to develop effective scaffolding, but a little bit of scaffolding can save a lot of debugging.

As you may have discovered, it is legal to make more than one assignment to the same variable. A new assignment makes an existing variable refer to a new value (and stop referring to the old value).

The first time we display x, its value is 5; the second time, its value is 7.

State diagram shows what reassignment looks like in a state diagram.

At this point I want to address a common source of confusion. Because Julia uses the equal sign (=) for assignment, it is tempting to interpret a statement like a = b as a mathematical proposition of equality; that is, the claim that a and b are equal. But this interpretation is wrong.

First, equality is a symmetric relationship and assignment is not. For example, in mathematics, if \(a=7\) then \(7=a\). But in Julia, the statement a = 7 is legal and 7 = a is not.

Also, in mathematics, a proposition of equality is either true or false for all time. If \(a=b\) now, then \(a\) will always equal \(b\). In Julia, an assignment statement can make two variables equal, but they don’t have to stay that way:

The third line changes the value of a but does not change the value of b, so they are no longer equal.

A common kind of reassignment is an update, where the new value of the variable depends on the old.

This means “get the current value of x, add one, and then update x with the new value.”

If you try to update a variable that doesn’t exist, you get an error, because Julia evaluates the right side before it assigns a value to x:

Before you can update a variable, you have to initialize it, usually with a simple assignment:

Updating a variable by adding 1 is called an increment; subtracting 1 is called a decrement.

Computers are often used to automate repetitive tasks. Repeating identical or similar tasks without making errors is something that computers do well and people do poorly. In a computer program, repetition is also called iteration.

We have already seen two functions, countdown and printn, that iterate using recursion. Because iteration is so common, Julia provides language features to make it easier. One is the for statement we saw in Simple Repetition. We’ll get back to that later.

Another is the while statement. Here is a version of countdown that uses a while statement:

You can almost read the while statement as if it were English. It means, “While n is greater than 0, display the value of n and then decrement n. When you get to 0, display the word Blastoff!”

More formally, here is the flow of execution for a while statement:

This type of flow is called a loop because the third step loops back around to the top.

The body of the loop should change the value of one or more variables so that the condition becomes false eventually and the loop terminates. Otherwise the loop will repeat forever, which is called an infinite loop. An endless source of amusement for computer scientists is the observation that the directions on shampoo bottles, “Lather, rinse, repeat”, are an infinite loop.

In the case of countdown, we can prove that the loop terminates: if n is zero or negative, the loop never runs. Otherwise, n gets smaller each time through the loop, so eventually we have to get to 0.

For some other loops, it is not so easy to tell. For example:

The condition for this loop is n != 1, so the loop will continue until n is 1, which makes the condition false.

Each time through the loop, the program outputs the value of n and then checks whether it is even or odd. If it is even, n is divided by 2. If it is odd, the value of n is replaced with n*3 + 1. For example, if the argument passed to sequence is 3, the resulting values of n are 3, 10, 5, 16, 8, 4, 2, 1.

Since n sometimes increases and sometimes decreases, there is no obvious proof that n will ever reach 1, or that the program terminates. For some particular values of n, we can prove termination. For example, if the starting value is a power of two, n will be even every time through the loop until it reaches 1. The previous example ends with such a sequence, starting with 16.

The hard question is whether we can prove that this program terminates for all positive values of n. So far, no one has been able to prove it or disprove it! (See https://en.wikipedia.org/wiki/Collatz_conjecture.)

Sometimes you don’t know it’s time to end a loop until you get half way through the body. In that case you can use the break statement to jump out of the loop.

For example, suppose you want to take input from the user until they type done. You could write:

The loop condition is true, which is always true, so the loop runs until it hits the break statement.

Each time through, it prompts the user with an angle bracket. If the user types done, the break statement exits the loop. Otherwise the program echoes whatever the user types and goes back to the top of the loop. Here’s a sample run:

This way of writing while loops is common because you can check the condition anywhere in the loop (not just at the top) and you can express the stop condition affirmatively (“stop when this happens”) rather than negatively (“keep going until that happens”).

The break statement exits the loop. When a continue statement is encountered inside a loop, control jumps to the beginning of the loop for the next iteration, skipping the execution of statements inside the body of the loop for the current iteration. For example:

Output:

If i is divisible by 3, the continue statement stops the current iteration and the next iteration starts. Only the numbers in the range 1 to 10 not divisible by 3 are printed.

Loops are often used in programs that compute numerical results by starting with an approximate answer and iteratively improving it.

For example, one way of computing square roots is Newton’s method. Suppose that you want to know the square root of \(a\). If you start with almost any estimate, \(x\), you can compute a better estimate with the following formula:

For example, if \(a\) is 4 and \(x\) is 3:

The result is closer to the correct answer (\(\sqrt 4 = 2\)). If we repeat the process with the new estimate, it gets even closer:

After a few more updates, the estimate is almost exact:

In general we don’t know ahead of time how many steps it takes to get to the right answer, but we know when we get there because the estimate stops changing:

When y == x, we can stop. Here is a loop that starts with an initial estimate, x, and improves it until it stops changing:

For most values of a this works fine, but in general it is dangerous to test float equality. Floating-point values are only approximately right: most rational numbers, like \(\frac{1}{3}\), and irrational numbers, like \(\sqrt 2\), can’t be represented exactly with a Float64.

Rather than checking whether x and y are exactly equal, it is safer to use the built-in function abs to compute the absolute value, or magnitude, of the difference between them:

Where ε (\varepsilon TAB) has a value like 0.0000001 that determines how close is close enough.

Newton’s method is an example of an algorithm: it is a mechanical process for solving a category of problems (in this case, computing square roots).

To understand what an algorithm is, it might help to start with something that is not an algorithm. When you learned to multiply single-digit numbers, you probably memorized the multiplication table. In effect, you memorized 100 specific solutions. That kind of knowledge is not algorithmic.

But if you were “lazy”, you might have learned a few tricks. For example, to find the product of \(n\) and 9, you can write \(n-1\) as the first digit and \(10-n\) as the second digit. This trick is a general solution for multiplying any single-digit number by 9. That’s an algorithm!

Similarly, the techniques you learned for addition with carrying, subtraction with borrowing, and long division are all algorithms. One of the characteristics of algorithms is that they do not require any intelligence to carry out. They are mechanical processes where each step follows from the last according to a simple set of rules.

Executing algorithms is boring, but designing them is interesting, intellectually challenging, and a central part of computer science.

Some of the things that people do naturally, without difficulty or conscious thought, are the hardest to express algorithmically. Understanding natural language is a good example. We all do it, but so far no one has been able to explain how we do it, at least not in the form of an algorithm.

As you start writing bigger programs, you might find yourself spending more time debugging. More code means more chances to make an error and more places for bugs to hide.

One way to cut your debugging time is “debugging by bisection”. For example, if there are 100 lines in your program and you check them one at a time, it would take 100 steps.

Instead, try to break the problem in half. Look at the middle of the program, or near it, for an intermediate value you can check. Add a print statement (or something else that has a verifiable effect) and run the program.

If the mid-point check is incorrect, there must be a problem in the first half of the program. If it is correct, the problem is in the second half.

Every time you perform a check like this, you halve the number of lines you have to search. After six steps (which is fewer than 100), you would be down to one or two lines of code, at least in theory.

In practice it is not always clear what the “middle of the program” is and not always possible to check it. It doesn’t make sense to count lines and find the exact midpoint. Instead, think about places in the program where there might be errors and places where it is easy to put a check. Then choose a spot where you think the chances are about the same that the bug is before or after the check.

English language speakers are familiar with characters such as the letters of the alphabet (A, B, C, …​), numerals, and common punctuation. These characters are standardized and mapped to integer values between 0 and 127 by the ASCII standard (American Standard Code for Information Interchange).

There are, of course, many other characters used in non-English languages, including variants of the ASCII characters with accents and other modifications, related scripts such as Cyrillic and Greek, and scripts completely unrelated to ASCII and English, including Arabic, Chinese, Hebrew, Hindi, Japanese, and Korean.

The Unicode standard tackles the complexities of what exactly a character is, and is generally accepted as the definitive standard addressing this problem. It provides a unique number for every character on a world-wide scale.

A Char value represents a single character and is surrounded by single quotes:

Even emojis are part of the Unicode standard. (\:banana: TAB)

A string is a sequence of characters. You can access the characters one at a time with the bracket operator:

The second statement selects character number 1 from fruit and assigns it to letter.

The expression in brackets is called an index. The index indicates which character in the sequence you want (hence the name).

All indexing in Julia is 1-based—the first element of any integer-indexed object is found at index 1 and the last element at index end:

As an index you can use an expression that contains variables and operators:

But the value of the index has to be an integer. Otherwise you get:

length is a built-in function that returns the number of characters in a string:

To get the last letter of a string, you might be tempted to try something like this:

But you might not get what you expect.

Strings are encoded using the UTF-8 encoding. UTF-8 is a variable-width encoding, meaning that not all characters are encoded in the same number of bytes.

The function sizeof gives the number of bytes in a string:

Because an emoji is encoded in 4 bytes and string indexing is byte based, the 5th element of fruits is a SPACE.

This means also that not every byte index into a UTF-8 string is necessarily a valid index for a character. If you index into a string at such an invalid byte index, an error is thrown:

In the case of fruits, the character 🍌 is a four-byte character, so the indices 2, 3 and 4 are invalid and the next character’s index is 5; this next valid index can be computed by nextind(fruits, 1), and the next index after that by nextind(fruits, 5) and so on.

A lot of computations involve processing a string one character at a time. Often they start at the beginning, select each character in turn, do something to it, and continue until the end. This pattern of processing is called a traversal. One way to write a traversal is with a while loop:

This loop traverses the string and displays each letter on a line by itself. The loop condition is index <= sizeof(fruit), so when index is larger than the number of bytes in the string, the condition is false, and the body of the loop doesn’t run.

The function firstindex returns the first valid byte index. The keyword global before index indicates that we want to reassign the variable index defined in Main (see Global Variables).

A segment of a string is called a slice. Selecting a slice is similar to selecting a character:

The operator [n:m] returns the part of the string from the n-th byte to the m-th byte. So the same caution is needed as for simple indexing.

The end keyword can be used to indicate the last byte of the string:

If the first index is greater than the second the result is an empty string, represented by two quotation marks:

An empty string contains no characters and has length 0, but other than that, it is the same as any other string.

It is tempting to use the [] operator on the left side of an assignment, with the intention of changing a character in a string. For example:

The reason for the error is that strings are immutable, which means you can’t change an existing string. The best you can do is create a new string that is a variation on the original:

This example concatenates a new first letter onto a slice of greeting. It has no effect on the original string.

Constructing strings using concatenation can become a bit cumbersome. To reduce the need for these verbose calls to string or repeated multiplications, Julia allows string interpolation using $:

This is more readable and convenient than string concatenation: greet * ", " * whom * "!"

The shortest complete expression after the $ is taken as the expression whose value is to be interpolated into the string. Thus, you can interpolate any expression into a string using parentheses:

What does the following function do?

In a sense, find is the inverse of the [] operator. Instead of taking an index and extracting the corresponding character, it takes a character and finds the index where that character appears. If the character is not found, the function returns -1.

This is the first example we have seen of a return statement inside a loop. If word[index] == letter, the function breaks out of the loop and returns immediately.

If the character doesn’t appear in the string, the program exits the loop normally and returns -1.

This pattern of computation—traversing a sequence and returning when we find what we are looking for—is called a search.

The following program counts the number of times the letter a appears in a string:

This program demonstrates another pattern of computation called a counter. The variable counter is initialized to 0 and then incremented each time an a is found. When the loop exits, counter contains the result—the total number of a’s.

Julia provides functions that perform a variety of useful operations on strings. For example, the function uppercase takes a string and returns a new string with all uppercase letters.

As it turns out, there is a function named findfirst that is remarkably similar to the function find we wrote:

Actually, the findfirst function is more general than our function; it can find substrings, not just characters:

By default, findfirst starts at the beginning of the string, but the function findnext takes a third argument, the index where it should start:

The operator ∈ (\in TAB) is a boolean operator that takes a character and a string and returns true if the first appears in the second:

For example, the following function prints all the letters from word1 that also appear in word2:

With well-chosen variable names, Julia sometimes reads like English. You could read this loop, “for (each) letter in (the first) word, if (the) letter is an element of (the second) word, print (the) letter.”

Here’s what you get if you compare "apples" and "oranges":

The relational operators work on strings. To see if two strings are equal:

Other relational operations are useful for putting words in alphabetical order: