Drawing Your Own Conclusions

Functions

2020-08-31T00:00:00+00:00

I’m sharing the September post a day early.

There’s nothing really profound in this one - I’m just continuing to search for visual ways to describe functions.

This one will be included in the free update (well free if you own it already - if not you can buy it now and get the free update once it ships) of A Swift Kickstart.

This book is for folks new to Swift and so I gently start with the classic Hello World function. I’ve implemented it as “Hi World” because it fits better in comic form.

I know that this daring decision might throw you but it really isn’t to challenge years of tradition so much as to fit in large font in small rectangles.

func hi() {
    print("Hi, World!")
 }

Although this is a good and quick example in Xcode playgrounds, Swift playgrounds does not have a console which drives us to quickly include a function that returns a String rather than print it to the console.

func hi() -> String {
	"Hi, World!"
}

By the way, if you haven’t been keeping up with Swift, this might look funny as we don’t need to include the return in a function with only a single expression. In other words we don’t need the following

func hi() -> String {
	// the return in the following line is superfluous
	return "Hi, World!"
}

“But Daniel,” you say, “it looks funny without the return.”

At first it does. Just as it looked funny, for those of us coming from Objective-C to see the return type at the end of the function signature or to not have semicolons at the end of a line.

It will grow on you.

In fact, you’ll wonder why return isn’t just assumed for the last expression of a function that is supposed to return something no matter how many lines it is.

i.e. it feels silly that this is fine:

func hi() -> String {
	"Hi, World!"
}

but this doesn’t compile

func hi() -> String {
	print("This doesn't compile - the next line needs a return")
	"Hi, World!"
}

Anyway, back to the point. We really want functions that take input and produce output. That is the final form of this silly example.

func hi(name: String) -> String {
	"Hi, \(name)!"
}

Here it is in comic form.

As always, let me know what you think.

Parse

2020-08-03T00:00:00+00:00

I had one of those moments last week.

One of those “how did I never see this before” moments.

Although I have a suspicion based on a talk I gave a couple of years ago at NSSpain that it was more of a “I understood this at one time, how did I forget it” moments.

Anyway, I’d reread a part of Paul Chiusano and Runar Bjarnason’s book Functional Programming in Scala. I like and recommend this book even for those of us who don’t code in Scala.

I was implementing an example of a Parser in Swift. Something like this:

struct Parser<A> {
  let parse: (Substring) -> (A, Substring)
}

They have an example of a Random Number Generator in an earlier chapter. You create an RNG that returns a random Int. Then you use map() to transform it into an RNG that returns Doubles or Bools. Then you learn to use flatMap() to return the next five random somethings or the first random something that meets a condition. This is a common example for State patterns.

Later they are looking at Parser combinators and I translated it to Swift as something like the above.

Then I stopped.

This looks a lot like State.

struct State<S, A> {
    let run: (S) -> (A, S)
}

In fact for Random Number Generators we defined a type named RNG and created our Random number generator that returned As as being a typealias Random<A> = State<RNG, A>.

So Parser could be seen as essentially typealias Parser<A> = State<Substring, A> where we replace run with parse.

All of a sudden Parser Combinators felt more like something that belonged to a family and not some new concept.

So that’s why we struggle with these abstractions - at some point we look at a new concept and say, “wait, that looks just like this other thing.”

This month’s comic is not very visual. Just the “mind-blown” emoji because I couldn’t find the “repeatedly smacking myself in the head for not seeing it sooner” emoji.

I love that our understanding of these notions deepens over time.

State

2020-07-06T00:00:00+00:00

I loved this year’s WWDC session Data Essentials in SwiftUI.

It’s an example of the Newton’s Method analogy of how we learn. We have a first impression and use that to get closer and closer to the truth. (I think I first saw this description in Massey’s book on Topology.)

Last year I thought I understood how @State worked.

It’s not that I was wrong - it was more that my understanding was incomplete.

The magic of @State is that it takes a property that is a value type contained in a struct and moves the storage outside of that struct. The struct now contains a reference to that property. This allows a button action to mutate that property without mutating the struct. The value type now behaves like a reference type.

This year’s session showed that it’s even more magical than that.

These structs that conform to the View protocol are very lightweight and might be discarded once they are rendered on screen.

Imagine I have a simple struct like this.

struct MyView: View {
  @State var count: Int = 0
  
  var body: some View {
    VStack {
      Text(count.description)
      Button("Tap here"){
        count += 1
      }
    }
  }
}

Suppose the instance of MyView is rendered and discarded. The user now taps the button. count changes and so MyView must be instantiated again so that it can be updated on the screen.

When the MyView instance is discarded, something needs to hold on to the count reference or we’ll start at 0 again.

SwiftUI holds onto it for us and connects this reference to count to the new instance of MyView. It feels as if MyView never went away.

I’ve tried to capture this magic in the following comic which I’ll be including in the update to my book A SwiftUI Kickstart which I’ll be updating for free this summer.

I love that our understanding of these notions deepens over time.

More Methods and Functions

2020-06-01T00:00:00+00:00

In the previous post I looked at traditional ways of representing functions and asked how we might appropriately represent methods.

With map(), for example, Swift used to implement it as a free function. map() on Array had to accept both the Array it was acting on as well as the function it was applying to every element of the Array. The signature was something like this.

func map<Input, Output>(_ array: [Input], 
                        using transform: (Input) -> Output) -> [Output]

We would call it like this.

map(myArrayOfStrings){string in string.count}

This is the rectangle shape with the funnel at the top where we dump in the Array of Strings and the function and with the funnel at the bottom that returns an Array of Ints. So …

map(["Where", "are", "the", "drawings"]){string in string.count}

returns [5, 3, 3, 8].

In Swift 2 we got protocol extensions and map() for Arrays was implemented in Sequence. Forget about the throws and rethrows, this signature was essentially the following.

func map<Output>(_ transform: (Element) -> Output) -> [Output]

We no longer needed to specify the generic type of the input Array as map() is a member and knows the type is Element.

We also no longer needed to pass in the starting Array as map() has access to everything in self. So here’s how we call this map().

["Where", "are", "the", "drawings"].map{string in string.count}

I experimented with many ways of representing methods and asked for suggestions

Jordan Rose suggested two. One was cartoon style conversation bubbles - which I love. I include these in my talks to allow the code to talk back to me.

His other suggestion (included with his permission) looks like this.

I really like this idea. It feels like the dot notation and communicates input from two directions: one from self and one from the parameters being passed. It also separates these information origins nicely and allows us to chain methods.

This chain was emphasized by the second drawing I was sent.

Lars Christiansen sent me this image of a train. (Also included with permission)

In the second car we see a method that receives its input from the car before and takes no additional parameters. In the next car we see a method that requires both the car before it and additional information for the amount we are increasing by.

Again I love this idea. It’s a simple way to communicate what’s going on.

It also fits nicely with a train-track approach that Scott Wlaschin uses in his wonderful F# talks and writing that you can find on fsharpforfunandprofit.com

Scott gives engaging talks on Functional Programming and uses train tracks to communicate concepts such as map and flatMap.

So I’ve been thinking about drawing comics to illustrate some programming concepts.

Just another medium for communication.

So I’ve been adding ABDCE’s to my Functional Programming Kickstart where ABDCE is “A Badly Drawn Comic Explanation”.

For now I’m using Comic Life 3 and essentially drawing with their basic shapes. Here’s my attempt at functions and methods.

I’m also taking some sketching classes and cartooning classes and hope to replace these with even more poorly drawn comics.

We’ll see how it goes.

Methods and Functions

2020-04-06T00:00:00+00:00

This month I’m inviting you to play along.

I’ve been working on a book about functional programming in Swift. To me that means “and methods too” but I’ve found that’s not obvious.

So in this brief post I want to look at methods vs functions both in who they are and in how we talk to them.

I know the classic image for a function but I’m not sure how to represent a method - particularly when it’s time to chain the methods. Your challenge is included at the end of this post.

Suppose I have a simple function that takes a String and returns an Int.

func wordCount(of string: String) -> Int {
    string.count
}

Then we call wordCount() like this:

wordCount(of: "Hello)

Generally, we use a “function machine” to represent this. I used to teach High School Mathematics, and this is what we drew on the board to represent functions.

“Drew on the board?” you ask.

Yes. Search the internet for “blackboard” and “chalk” or ask an older person.

Anyway, the picture looked like this.

Let’s represent composition next. wordCount() was a function (String) -> Int so the next function must take an Int.

As a silly example, suppose, because I live in the US, I want to convert my wordCount() result from Celsius to Fahrenheit. The conversion from C -> F is given by

func inFahrenheit(_ int: Int) -> Double {
    Double(int) * 9 / 5 + 32
}

So to calculate my word count in Fahrenheit, we have to compose these functions

inFahrenheit(wordCount("Hello")

This works nicely in an image.

So that works nicely for functions that take a single input. But what about functions that take two inputs.

For example, here’s a function that increases an Int by another Int amount. We could call it add(), I’ll leave it like this

func increase(_ int: Int,
              by increment: Int) -> Int {
    int + increment
}

I’m less interested in the implementation than I am with the picture. But first let’s call the function.

increase(5, by: 6)

And here’s how we compose it with wordCount()

increase(wordCount("Hello"), by: 6)

The code is now harder to parse but the image still isn’t so bad.

The first parameter falls through from wordCount() and we pass in the additional parameter

The code is cleaner and the methods are more discoverable if we use methods instead of functions.

Add wordCount() as a method in an extension to String.

extension String {
    func wordCount() -> Int {
        count
    }
}

We call it like this.

"Hello".wordCount()

The argument of the function moves out front as the receiver of the message.

I know that “receiver” is very Objective-C of me but it feels more natural for me to think of it that way then the more formal “instance on which the method is called”.

Similarly, we can define our other two functions as methods in an extension of Int.

extension Int {
    func inFahrenheit() -> Double {
        Double(self) * 9 / 5 + 32
    }
    
    func increase(by increment: Int) -> Int {
        self + increment
    }
}

We call them as methods like this.

inFahrenheit()

increase(by: 6)

Notice in this implementation that one of function’s parameters has come inside our method as self.

In other words if we use a function not a method then we have to explicitly pass the information contained in self in the method to the function.

So here’s your challenge.

It is easy to chain methods in code than to compose functions (we’re not using custom operators here).

Here’s what chaining looks like.

"Hello"
    .wordCount()
    .inFahrenheit()

"Hello"
    .wordCount()
    .increase(by: 6)

How should we represent methods and method chaining pictorially? We could just use the function diagrams and include the implied self but that doesn’t feel satisfying.

If you have an idea, please tweet with hashtag #drawingYOCmethods in the next couple of weeks.

Thanks.

References

2020-03-02T00:00:00+00:00

My guest for this first episode is Mikey Ward, a great teacher, presenter, and author and one of the nicest people you’d ever want to meet.

Mikey Ward is an instructor at Big Nerd Ranch, and you can find him on Twitter at @wookiee.

He was incredibly kind and patient to be my first guest in this new venture.

So Mikey, what programming concept are we talking about today?

(Mikey)

I think with your permission I’d like to start with something near to my heart, as it’s something I see both experienced and new programmers struggle with. Object references, and how we use and misuse them.

I suppose that could be an unfairly broad topic, since it really encompasses everything from value vs. reference semantics in Swift to strong reference cycle leaks, but it’s one where I think a little artful discussion could go a long way for folks.

(Daniel)

Great!

Oh wait “artful discussion” - nice.

So you and I are old enough that we remember Objective-C before ARC where he had to manage memory ourselves, in the snow, walking uphill back and forth to the compiler.

In Objective-C if we created a new object with ownership, it’s reference count would be 1.

Now if I’m interested in that object I would have to say how interested. Do I increase its reference count or not. Is my reference strong, weak, unsafe-unretained?

I’m not nostalgic for the old days where we did this work ourself with retain, release, and autorelease, but those who just joined us for Swift where the reference count is handled for us may be missing some of the underlying ideas.

(Mikey)

Exactly! And I think some of the newer Swift developers are leaning on those with lots of experience to help them understand what’s going on, but I feel like there’s a lot of advice out there grounded in the pre-ARC way of thinking.

I think updating our model for ARC’s and Swift’s optimizations is important.

Which leads us to the the trailhead, I suppose. Swift’s Value and Reference types.

There’s a lot that could be said about the stack and the heap but it’s easy to overthink, so let’s step back.

The question is, “when I declare a variable and put a value in it, where in memory does the value actually live?”

For value types such as Int, that value lives inside the variable itself. If I pass a the variable into a function as an argument, the variable (and its contained value) is copied.

For reference types like UIViewController, the variable you create doesn’t keep the entire object inside it. Instead, the object is created somewhere else in memory, and your variable instead only contains knowledge of where in memory the real object is. Specifically, the object’s memory address.

(Daniel)

I like that you’re thinking conceptually of the difference between value and reference types.

This split is clear in Objective-C and types like UIViewController that is implemented in Objective-C that we may create and interact with in Swift.

But some of the Swift value types also end up using the heap as well. Our contract though is simple.

How’s this for an example. I walk in and you’re watching your AppleTV. You are controlling it with your iPhone. In other words, you hold a pointer to the AppleTV.

I sit down next to you and take out my iPhone and connect it to the AppleTV as well.

We each have a reference to the same tv. If you pause the program using your remote, the program I’m watching pauses as well. If I hit the play button then the program you’re watching starts playing again.

Our remotes are talking to the same AppleTV. We have references to the same memory location.

Now, I go to the kitchen and make a sandwich. You say, “that looks good, I’d like one too.”

This time it’s a physical object. I don’t want us connected to the same sandwich. We need our own instances.

I make you a copy of my sandwich and hand it to you.

You take a bite out of your sandwich.

It would creep me out if that meant a bite disappeared from my sandwich. The sandwich is a value type. We each have our own. Changes I make to mine don’t effect yours and vice versa.

(Mikey)

Exactly! Thinking about the stack and the heap is likely to get in the way for most people. What’s more important is thinking about whether my variable contains the entire value (a value type) or just a reference to it (a reference type).

Which simplifies the next step a bit: when I copy a variable of a value type, its entire contents are duplicated, as with “answer” and “fact” in my diagram, or the sandwiches in your example.

But with a reference type, like the Apple TV, copying the remote just means I have two ways to control it.

Copying a reference type variable only copies the reference. Which increases the number of references to the object in question.

So the happy path is that an object stays alive as long as there are references to it. If the reference count of an object reaches zero, the object self-destructs and gives its memory back to the system. I don’t want my AppleTV to explode if both remotes are unpaired from it, but here we are, those are the rules.

The Automatic Reference Counting done by the compiler, and the self-destruction of an object with a reference count of zero, means we rarely have to think about any of this.

But there are strange and complex ways in which these seemingly simple rules can get us in trouble.

(Daniel)

For example, what happens if we have a value type that contains a property that’s a reference type.

Going back to our AppleTV example, what if we don’t have iPhones with us - I know - that makes no sense, but work with me.

So you have a really cool 3D printer that you use to print a remote for the AppleTV.

I come into the room and see you watching television and using your remote and I ask you if I can have the remote.

You think, “no, this is like the sandwich” and you make a copy of the remote and hand it to me. So it’s a different physical remote but it has this reference type inside - this property that, in your remote, points to the AppleTV.

Will my remote point to the same AppleTV?

If we have a value type that contains a reference type, where do these things live?

(Mikey)

Your remote will absolutely point to the same AppleTV, and we’ll have a fun game of Menu Wars. When you copy a value type, you copy everything it contains. Remembering that the remote doesn’t contain the AppleTV itself (though that might be interesting to imagine), the remote only contains a reference to the AppleTV. When the remote is copied, any values and references it contains are copied. The objects at the other ends of those references are not.

And now we get to the nut of it. Experienced developers might be tempted to apply terminology like “stack types” and “heap types” to Swift, but I strongly encourage folks not to try to force the comparison, and to embrace Swift’s terms of art, “value type” and “reference type”.

Thinking about it strictly in those terms helps us to understand what’s happening under the hood of one of Swift’s more interesting design decisions.

Let’s draw a chain of conclusions from what we know so far:

Reference type variables are very small, because they don’t contain any real data, they only contain a reference to somewhere else in memory where the data (which may be a mix of other references and values) actually lives. This means that copying references and passing them into functions is inexpensive. Value type variables contain all of their data (which may include a mix of other values and references) This means that the computational and memory cost of copying and passing around value types is tied to the amount of data that they contain.

So here’s the big question: since several of Swift’s value types like Strings and Arrays can become very big, do we need to be careful about how many times we pass them around and copy them? Would it be better if Strings and Arrays were reference types?

(Daniel)

I agree that the right way to think about value types and reference types is their semantics, but to keep people from making assumptions about memory and performance it might be nice to spend a moment on stack and heap.

A WWDC talk from 2016 titled Understanding Swift Performance helped make this clear for me.

In Objective-C and C based language, primitives are created on the stack while objects are created on the heap and their references are on the stack. (To be pedantic, the exception is blocks which are reference types created on the stack that need to be copied to the heap if they’re going to stay around a while.)

Anyway, we explicitly do not have that clean separation in Swift. As you say, Strings and Arrays are value types and we should understand the contract that that implies. But we can’t reason that value types are kept on the stack and reference types on the heap.

The session showed that Strings are created on the stack but for even fairly small Strings, the characters - i.e. the contents of the String - are stored on the heap. This mixture of getting the contract for value types while the efficiency of the heap is explained in Ben Cohen’s portion of the 2019 WWDC video Modern Swift API Design and Johannes Weiss’ dotSwift talk High Performance systems in Swift

So, for me, the takeaway is that the library authors are aware of the costs of using value types while embracing the semantic benefits. It allows me to worry less about the performance and memory issues while adhering to your points on how we should think about value and reference types.

(Mikey) Right! The videos’ points on the under-the-hood heap storage and copy-on-write features of some of Swift’s standard library types are fun and enlightening, but in the end, are just implementation details. In the end, even though it might feel wasteful to pass a large string or array up and down the stack, the Swift authors have gone to great lengths to make it work fast and efficiently.

This really is a delightful language. Thank you for giving me the opportunity to chat with you about it!

The Plan

2020-01-10T00:00:00+00:00

There are times when I’m teaching, that code is not enough to explain what I’m trying to illustrate.

It turns out that “illustrate” is exactly the word I’m looking for. I draw a picture.

Now in my class it’s often true that the final sketch doesn’t mean much to anyone. It’s the discussion as I draw the picture.

So that’s what I’m going to try to do here.

I’m going to invite a guest to suggest a programming topic and we will have a conversation and try to draw sketches that might help. Then we’ll invite you to contribute your comments and sketches and then we’ll meet one more time to see where we are.

At least that’s the plan for now. I’m sure as we start experimenting we’ll change our mind.

So say we’ve developed pictures of functions and drawn a function machine where the input comes in the top left and the output comes out the bottom right.

Then composition might look like this.

And then maybe we’d talk about how this is equivalent to a single function that essentially wraps the inner workings.

Anyway, that’s the rough idea. We’ll see how it goes.