Getting started learning about strings

In the last lesson of App Development with Swift, we started learning about the importance of naming things, but all the things we named were numbers of things. Number of dogs, number of cats, etc.

Lesson 3 of App Development with Swift is called Strings, and in it we learn that strings are text, and the reason they are called “strings” is because that word refers to a string of text.

So strings are text instead of numbers. One thing we have to remember, though, is that text doesn’t necessarily just mean letters. Text can contain letters, but it can also contain punctuation marks, symbols, spaces, and even numbers. In this chapter we learn that all of these things are called characters, so in addition to saying a string is a string of text, we could also say it’s a string of characters.

Also, while strings are different from numbers, but they can contain numbers. Here is an example of a string that contains numbers in it as part of the text.

We learned in the previous lesson that the word “let” can be used to set a constant. So here is an example of a constant that’s a number and a couple examples of declaring constants that are strings, with special characters other than just letters.

As soon as we learned what strings were, this lesson got into how you combine strings together, to actually do something with them. We learned that you can join strings together by using the plus sign (+). So that means we can do something like this:

That’s cool. It works. But then we learned about this thing called string interpolation, which the teachers tell us is a way to define a fill-in-the-blanks string, or to use placeholders to construct a string. Here is what the code looks like for a simple string interpolation example in Swift:

After that, we learned that the backslash does other things too, because it basically tells Swift that something special is coming up in the very next character of our code. For example, when we declare a string in Swift, we enclose it in quotation marks, which brings up the question of what to do if our string needs to include quotation marks. We learned that we can use the backslash to escape the quotation marks, like this:

We are told in the lesson that this means the backslash can be referred to as an escape character in Swift. We aren’t exactly told it’s the escape character in Swift, so maybe there are others, I’m not sure.

We also learned that we can use the backslash with the letter “n” to create a new line in our string, so the following would make two lines out of what shows up as one line in our code:

Learning that naming things is important in programming

In Lesson 2 of the App Development with Swift book, we get the message right away that naming things is an important part of programming.

I thought this chapter was pretty cool because the playground exercises were constructed in a way that made it really obvious that giving names to things is a huge part of how we can use code to solve problems. In fact, when you go from the chapter in the iBook to the playground exercise, the first title of the first page there isn’t “Naming,” or anything like that. It’s “Solving Problems.”

That page gives us some good thoughts about solving problems, but as we get into the exercises we learn by actually pushing buttons on a keyboard what kinds of problems can be solved.

First, we’re told to work on this example where somebody is having a pet show and we’re supposed to write down the number of dogs and cats and turtles and so on. When we get started, we don’t know how to name anything, so the writers/teachers tell us just to write code comments saying how many dogs and cats there are and then add up those numbers. Something like this:

The numbers get added up on lines 14 and 17, which is all well and good, but if the number of dogs needs to change from 5 to 6, we have to change that value of 5 in three different places to get ourselves all squared up.

But then we are told that in Swift we can give a name to the number of dogs there are by typing something like the following:

We don’t get told until later in the lesson that using this particular syntax means we are setting these as constants, not variables, but we’re beginners so who cares? What we care about right away is that once we realize we can name things in code like the above, that means we can add them together with code like the below:

With these pieces in place, if we find out there is another dog in the pet show, we can just change the number of dogs from 5 to 6 in the first block of code and our totals will update automatically.

Now if you’re an experienced coder rather than a beginning coder, this will seem really simple and really obvious. But for a beginner, the idea that you would only have to change that number in one place and have the calculated totals updated accordingly is kind of an eye opener. Less work, less typing, less chances to make a mistake. Not to mention, in our example, we’re doing 2 calculations (total animals and total mammals), but what if we were doing 200 different calculations?

We learned a few other things about naming in this lesson. I’ll run over some of them quickly:

  • We learned that the style of writing names like numberOfDogs and numberOfCats is called “camel case,” because the capital letters on all the words except the first word reminded somebody at some point of the humps on a camel.
  • We learned that camel case is the preferred way to name things in Swift.
  • We learned that when we declare a name for something in our code, that’s called a declaration.
  • We learned that when we assign a value to a name, that is called an assignment and that when we do so with the equals sign as in the above code, the equals sign is called the assignment operator.
  • We learned that when we assign a value to a name with the word “let” as we did in the code above, we are declaring a constant, not a variable, and that we will learn about variables later. We are told that a constant is called that because we are supposed to set its value only once and that the value should not change.

As this lesson ends, there are some exercises that do a good job of demonstrating the power of using names and values to solve problems that would be difficult to work out on pencil and paper, even with the help of a calculator.

Playground basics and other coding playgrounds from Apple coming soon?

At the end of the previous post, I said I would next be getting out of the Introduction and into Lesson 1 of the App Development with Swift book. The title of Lesson 1 is “Playground Basics.”

Basically what happens in this chapter of the book is you open one of the practice files that was mentioned in the Introduction chapter, a file named 01_PlaygroundBasics.playground. When you click on it to open it, it opens in Xcode, so that’s pretty cool if it’s your first time to do something in Xcode.

Anyway, as you can see above, the file has a .playground file extension, and you quickly find out that means it’s this file that you can both read and type code into. Here is how the authors of the book answer the question “What is a playground?”:

A playground is a place where you can type code and get results right away. You can play and experiment with code without anything getting in your way. A playground can mix parts that explain things (like this text) with live code that you can change.

That’s a pretty accurate description of what I was seeing on my screen, and when you get in there and use these playground things, they are pretty cool. When you type on the left side of the window — if you type Swift code anyway — the results show up on the right side of the window. They call that right side of the window the “results sidebar.”

The writers (I find myself wanting to call whoever wrote this book the teacher) but anyway, the writer/teacher/whoever it is jumps pretty quicky into showing us how to write some code. They say the simplest line of code you can write is to type in a number, so they have an example of a number written there on the left and the same number is spit out into the results sidebar.

On the next page they go into calculations and show you that if you type 34 + 56 + 230 on the left you are going to get the sum of those 3 numbers, 320, on the right. Then they show you that you can also subtract and multiply and divide and some other things like grouping numbers for order of operation with parentheses.

After that, we learn about how to add comments to our code. Apparently in the Swift programming language this is done by adding 2 forward slashes (//) in front of a line of code. We are told that comments are little notes that programmers leave in their code to help other people understand their code when they read it later. Makes sense.

The next page is on debugging and I think it contains some really important information and advice. I hate to quote the whole page here, but it’s a short page and I think I will just quote it all because it’s that good. Here goes:

Programmers make mistakes.
(More often than you might imagine.)

As you write code and build apps, you will make mistakes too.

Don’t panic.

Sometimes things go wrong when writing code which is normal and expected.

Don’t expect everything to come together without errors.

Part of being a programmer is troubleshooting when things go wrong.

The first step is to not freak out. Take a deep breath.

Don’t panic.

An error doesn’t mean you’ve failed or you’re a bad programmer.
It just means there’s a problem in the code that you need to fix.

And that is part of the process.

This seems like good advice. When we are starting something new, regardless of what it is, it’s natural to get discouraged when things go wrong. It’s probably good to remind ourselves that of course we’re not good at some thing if we just started doing that thing. Keeping that in mind is an important part of learning how to do stuff.

But I think the teachers are getting at another more specific point here. I think maybe what they are trying to say is that when it comes to coding in particular, making mistakes is not something that only beginners do. I think they mean when you’re writing code, even when you are very experienced, it’s normal to write code that has mistakes in it. I think it’s great how they make it clear that those mistakes are a normal part of the process, not a sign that you are a bad programmer.

Anyway, after that there is some stuff about errors and then the chapter ends. So far I’m finding the book and the playground text to be well-written and it was good to start writing some code, even if it was very simple code. We have to start somewhere.

This next thing I want to mention is almost slightly off topic, but it’s interesting that the environment we are introduced to in this chapter is called “playgrounds.” I have been hearing about this thing called Swift Playgrounds, which is supposed to be an iPad app for learning to code that’s coming to the iOS App Store this fall. I wonder if the name of the kind of playground used in this chapter is supposed to be Xcode Playgrounds or what. They seem like 2 similar but separate things that maybe share a name, or part of a name.

It doesn’t really matter. I just thought it was interesting. Also, when I went to the Swift Playgrounds website linked above, at the bottom I saw a link to the App Development with Swift book we’ve been talking about here and a link to an Apple website called Everyone Can Code. That site talks about Apple’s approach to coding and helping people learn to code, and it mentions some of the books I downloaded earlier. I guess that means maybe I stumbled onto some of the right stuff to learn from.