iPhreaks

The iPhreaks Show is a weekly group discussion about iOS development and related technology by development veterans. We discuss Apple, tools, practices, and code.

Subscribe

Get episodes automatically

174

174 iPS Structs and Mutability with Chris Eidhof


1:15: Introduction: Chris Eidhof

2:05: Structs in Swift

  • Blog post
  • Functional programming inspiration
  • Mutations in structs can be positive

3:55: Problems that can be solved

  • Unexpected changes, unexpected mutations
  • Make mutable opt-in

8:15: When mutating can be useful

  • Change an element at a specific index
  • Struct copies are very expensive

11:15: Benchmarks

15:30: New Data and Updates

  • Strategies for communicating changes in state

23:00 Writing simple code

27:00: ObjectiveC.io

33:00 Other projects

Picks:

The Retro Mac Cast (Andrew)

68KMLA.org Forums (Andrew)

Twin Cities Startup Week (Jayme)

Eli Document Picker (Rod)

Functional Swift (Rod)

Michael Vey Fall of Hades (Chuck)

Webinar Jam (Chuck)

Get a Coder Job (Chuck)

Kyle Fuller (Chris)

Links:

Hired.com

Chris on Twitter

This episode is sponsored by

comments powered by Disqus

TRANSCRIPT

Charles:        Hey everybody and welcome to episode 175 of the iPhreaks Show, this week on our panel we have Andrew Madsen.

Andrew:       Hello from Salt Lake City.

Charles:        Jaim Zuber.

Jaim:             Hello from Minneapolis.

Charles:        I’m Charles Max Wood from Devchat.tv and this week we have a special guest, I should have ask how to say your name so I’m gonna guess, it’s Chris Eidhof?

Chris:            Yeah. That’s right. Hello from Berlin, Germany.

Charles:        That’s long ways away. Do you wanna introduce yourself?

Chris:            Sure. Yeah. Hello everybody, I’m Chris, I make this side code objective.io. I think many people know it, not many people know how to pronounce it. I don’t know what’s the right pronunciation but that’s how we pronounce it. We used to write this magazine for two years and then we wrote free books about Swift and Coredata. These days, we run a video series called Swift Talk.

Charles:        Interesting. We brought John today to talk about structs and mutations in Swift, you wrote a blog post about that, I will make sure that winds up in the show notes. Do you wanna give us a brief explanation of what’s in there and then we can pick it apart from there.

Chris:            Yeah. It depends a bit from where you’re coming from but structs behave differently from classes for example and also from classes in Objective C or classes in Swift. One thing is that if you define a struct with a select variable like x=5 then you cannot really mutate it anymore.

                    It says that x will always be the value 5. Structs are all about values. If you define a variable as a var variable, then you can mutate it. This is the same with arrays in Swift which are also structs. You cannot really modify an array, that’s defined with flex, only arrays that are defined with var.

                    The way to modify things defined with var is by using mutating methods on structs and these are a bit strange because only when you mark a method as mutating you can modify things and Swift draws at least a little bit of inspiration from Functional Programming.

                    Functional Programming is a very popular thing and a lot of functional programmers say that mutation is bad. That’s what my post was about. Saying that mutations instructs aren’t as bad as everybody thinks and that they’re actually really nice and that you still have all these benefits of Functional Programming. In my post, I try to look at how mutation works and what the effects are.

Jaim:             I think we’ll get into using structs and value types and Swift. I’d like to talk about some of the problems that this solves. What are some problems with mutating things and of course, where I’m coming from, where I think a lot of our listeners are coming from is I’ve done Objective C for a long time and Swift is still relatively in this thing and it’s requiring a little bit of a shift in my thinking. You really have value types but they’re primitives. It came from C basically.

                    Generally, the things you’re working with and your Objective C code are instances of classes and they’re always reference types. What are some of the problems having mutable state can cause?

Chris:            Yeah. It’s a very good question. One of the biggest problem is that there might be unexpected changes in your state. It’s nice that you can mutate things and I think mutation is a really good thing to have but it’s not so nice if you don’t expect mutation.

                    I think every Object C programmer knows that you shouldn’t be mutating NSArray or an NSMutableArray while you’re iterating through it because iterating will break and your code will blow up. This is something that you learn. Here, you make a mistake once or in my case, a couple of times then you’ll ignore it, you learn it and you don’t make that mistake again.

                    That’s in a way easy to see. You’ll look at your for loop and you see where it crashes and then all is good but it becomes a bit harder when one part of your code is expecting that your object doesn’t change and another part of your code somewhere far away is mutating it especially when you’re doing A-Sync stuff.

                    One of the problems with that is that A-Sync mutation often is not a problem. Sometimes it crashes your app. It becomes really hard to debug. In Objective C, the designers of foundation, they knew this. There is already NSArray and NSMutableArray and there is NSString and NSMutableString.

                    This is one solution but it’s not really perfect. Let’s say you have a method and it takes an NSData and it’s mutable data. It works because NSMUtableData is a subclass of NSData. Within that method, however, you just see the NSData. It’s under the hood to mutable but you don’t know within the methods. You have to be very careful and always make copies before you start relying on the fact that things are immutable.

                    The Swift designers said, “We’ll do it completely differently and we’ll make immutable the default so it’ll make mutable opt in if you use var then we don’t have any of these problems and everything is always copied by defaults.” They added some optimizations to make it faster and it sorted the other edge of the spectrum. It also has its problems but it’s at least a bit safer.

Jaim:       That’s a good point. There are two approaches for why anything is non mutable are unofficial. One, as you’ve mentioned, it allows the compiler to reason about things like they know this will never change. The compiler can do do all sorts of beep voodoo in order to make our code run faster and smaller, anything like that.

                    In our own code, you also mentioned this case where if you’re doing multi credit code and you’ve got an array, I’m not going to modify anything in my For Loop but maybe some other code is going in there and modifying the arrays about that point. At that point, if you’re being a lazy buddy, you’ll just copy the array before you do anything which can cause also the other problems.

                    If you can have a compiler guarantee that this object is not gonna change, you have a lot more confidence that you’re not gonna blow something up because the compiler is looking it help for that stuff for you. That’s the benefit but what you’re getting at is mutating is valuable too. What are the cases where mutating is usable? I barely use mutating, keyword and a struct. What are some good use cases for it?

Chris:            Basically, any time you wanna change something. If you consider array, in Swift if you just say, let x equals some array, he cannot change x. It’s immutable. But if you would’ve set varx=some array, you can change. For example, change an element at a specific index.

                    All of these operations, they’re not magical, they’re just implemented with mutating. That is a signal to the compiler that you’re gonna change the value. Anytime you have a struct and you wanna change a value, you have to do this mutating or write a mutating function or subscript or whatever. Otherwise, you cannot even change the struct. If you don’t wanna use mutating, you have to return completely new struct values. That would be very inefficient.

Andrew:            What parts of the making new struct values is inefficient?

Chris:            The way that structs work is their value types. This means that whenever you create in new variable or whenever you pass a struct to a function or method, it creates a copy. That is super expensive. Creating all these copies is really expensive and the compiler has this optimization called copy-on-write. This allows the compiler to remove a lot of unnecessary copies. It only does a minimal or only when you start changing your struct, it actually makes a copy.

                    If you use a mutating keyword, you can mutate in place. For example, if you would implement quick sort which we only did in school and afterwards we never had to do it again. If you wanted to do an in place quicksort, then you can do that with the mutating keyword and it would be much harder if you would return a new array because a new array gets allocated and it would be very inefficient.

                    It allows you to be a little bit more efficient and it also allows you to write more natural code because we just want to say, “x that depends five.” Instead of saying, “array by a pending element.”

Jaim:             I’m curious. You mentioned the optimization that Swift uses. You know, from my days it’s a C++ programmer, I just learned that a compiler was so much smarter than I was. That I didn’t worry much about what type of struct I was using because the compiler would throw most that out. I’m not sure how far Swift is caught up with that but at least cases where I’m using a struct because that’s ready to reason about this but the compiler can break that down into primitives and do all sorts of different weird voodoo.

                    Are there any benchmarks between doing a bunch of struct copies or doing the immutable thing where we’re doing the Ruby and optimization versus just a struct in place? Have people depend by doing any benchmarks?

Chris:            Yeah. I think people are doing benchmarks. I don’t know if there is any official place for that. It’s a double head sword this Copy-on-write thing. Most of the time, the compiler will do things that are great and they will remove a lot of unnecessary copies but sometimes it doesn’t and it can be really hard to debug and it’s can be very counter intuitive.

                    For example if you have an array, you can get all this copy and write optimizations and you can mutate things in place. If you put that array into a dictionary, then you completely lose that. This is something the Swift team wants to fix but it’s really hard to know this and to detect this unless you start profiling yourself. There are many more of these cases where it’s hard to figure out.

                    For example, if you’re doing a For Loop and you’re changing some struct value inside the For Loop, most of the time that’s gonna be way more efficient than doing it the functional way which is also very nifty says, Swift reduce or something like that. It can be very tricky to debug this performance because it’s hidden away. I don’t know what good strategies are for that.

Jaim:             No, I get what you’re saying. If you have larger data structures and you’re mixing and matching mutable on immutable. For large, if you have to change things. It can cause problems. If you make a thing immutable, you have you rebuild everything every time especially if you’re doing it a lot. I can definitely see where that would create some performance problems.

Chris:            Yeah. Exactly.

Jaim:             I definitely agree. If you’re mixing and matching, you have a big dictionary with an array to watch the immutable. Maybe other things are depending on that and you just wanna do it in place. Where developing client apps, which they have state, state exist and it gets updated sometimes people need to check on what they’re doing. I agree with you.

Chris:            Yeah. For me, I’ve been investigating the behavior of Swift for quite a while and my understanding is still slowly growing. The more I realize how it works, the more I realize how difficult it is and how complicated. On the other hand, most of the time it’s just fine and performance is not something to worry about until you actually have a problem there.

                    Don’t do things that are too stupid, then everything is gonna be fine. It’s interesting to see how this really cool technique that they have, for example Copy-on-write, which seems like it magically solves everything. In the end, all struct causes some issues.

Jaim:             Yeah. It’s something that solves a lot of problems. They’ll give most of our applications reasonable performance that was super fine with it but you’ve brought up some edge cases where they can seem go a riot or in a hurry.

Chris:            Yeah. Just to go back to the benefits. We talked a bit about the problems but in the end, the cool thing about structs is that they are value types and they are copied everywhere. You don’t really have to worry about making those copies yourself and it really helps in writing safer code. I found that a whole class of bugs just doesn’t happen because of that.

                    Even though in Objective C or when you’re into facing of Objective C or you like it or Coco, you have to use classes a lot. The times where you can use structs, they’re really powerful and they can really help for the simplicity of your code.

Jaim:             I’m maybe having a hard time asking this articulately but there are also times when you really want the fact that some state has changed to be communicated across parts of your program. You fetch new data from the network and update some model data with new information you’ve got and you want your UI to be updated to display that.

                    There are ways for solving that problem that we’ve all done in Objective C that I think are common or using reference types which allows us to use patterns that maybe don’t work if we’re using value types and it does seem you wanna use value types for your model data so you do that. What are some strategies for communicating when you have had a change in state?

Chris:            That’s a good point. Structs make this both very easy and very difficult. If you’re used to things like KVO, then it’s gonna be different. The patterns like KVO, they work pretty well and they serve this really well. There is also some issues with it. If you for example have your model data and you forgot to subscribe, then you might have initialized a class making some assumptions.

                    At some points, the assumptions don’t hold anymore. You have to be very careful also when you use classes and reference types for your model data. Value types, they can solve this problem a little then there are other problems. Let’s say you have a table view controller which displays people and you’re gonna model people as the structs. You have this person struct, you put lots of persons in an array.

                    The cool thing is that you can then observe that array instead of observing every individual person. Whenever something changes, if a person gets added to the array. Also, if somewhere deep inside the person’s struct, let’s say the element zero to person’s address street changes then the entire array gets a notification. There’s this sat that you can use on a variable, on an array variable for example.

                    Basically, you get this notification that something changed in your array. Unlike KVO, you don’t know what changed. You’re gonna get a notification, something in the array changed, and then you can listen to that. The upside issue is that whenever anything changes, you do get this notification no matter how deep inside that array or inside the values in the array.

                    The downside issue is you don’t have any granular notification. You have to compute the difference or something to really update your table view. In that sense, value tabs can make it a lot easier but also more tricky to solve these problems.

Andrew:            It sounds to me like maybe this is one of those things where we’ve got the internal of the good idea with the value types but some of the larger patterns around are yet to be established. I think there is talk of work to be done on swift in terms of replacing things like KVO because right now I don’t know if there’s really a good direct replacement for some of the problems that were solved with KVO but maybe that’s just part of working in a brand new language with a lot of good ideas and a lot of work to be done.

Chris:            Yeah, absolutely. There are definitely problems that KVO solves that aren’t solved in Swift and likewise, things like meta programming or key-value coding, it’s the same story that’s said there.

For example, things like value types, they do really solve a lot of these problems but in a very different way. When I started learning Swift, I didn’t really understand why I would need all of that and why I would need to solve my problems differently.

                    To be fair, I didn’t really understand how value type works and it took quite a while but now I really like them and I think I would really miss them if I would have to go back to Objective C. I think it’s not so easy to see the advantages unless you’ve been working with them for a while, at least that was my experience.

Andrew:            I think I’m actually in the middle of that experience with probably less real Swift experience than you have and of course you’ve been writing about it and stuff. I’m still in the, well, I don’t fully understand how to make use of some of these new ideas that are in Swift. I’m still trying to get my mind around them and figure  out how I can use them in real apps to make my code better.

Chris:            Yeah, I’m the same way. I maybe have a little bit more experience but I’m still trying to figure out how to apply everything and how to improve my code and make my code simpler. That’s also a really hard thing because if you really use all these nice Swift features, it’s gonna be very hard for somebody who doesn’t know those features to come to my code base and understand them.

                    For me, this is one of the hardest problems of writing simple and clean codes because you want to basically use all of the established features of the language but not too many because then new comers will not understand. I find it really hard to find a good balance there. Do you have the same problems?

Jaim:             Definitely. I think they’re magnified for me because my full time job is lead instructor teaching people Swift but many of them have never programmed before. Certainly, I can’t just go wild with every cool, high level feature that Swift offers. It becomes really hard to introduce these new people to the code but at the same time I want to use them in a way that students can learn and understand and how to make use of Swift, the things that make Swift special.

Chris:            Yeah. That sounds really difficult. I like teaching people who are very experienced because I find it really hard to imagine and go back to the beginner’s mind set. I think it sounds like a very difficult job.

Andrew: It is but it’s also fun. You get to see people go from knowing nothing to having their mind open and start being able to do all kinds of stuff. It’s pretty cool and pretty quick and they get excited about it. Certainly not all bad.

Jaim: Yeah. That’s the problem with working with a language that’s not tied in a language. You see it’s a small language, you can learn it pretty quickly. I guess there’s a great example, good to get a lot of weird things we’ll see but a small language, you have one way in doing doings that are opinionated, here’s how you do it. With other language that have been around are growing and Swift is becoming rather large, it’s opinionated on how to do things but it lets you use a control like mutating.

                    That’s always the challenge. If you’re working with the big language that has a lot of features, which ones do you use? Do you go with the believe again feature that you know is not necessary? You could do it just fine the other way. My approach is I try to keep things simple if I can and use the more esoteric features when they’re writing a clear benefit where I’m not dealing with the same thing where you have someone that use that feature coming on this equal base and annoyed to use it because that’s a real problem because code spend for people on Earth to understand too.

Chris:            Yeah. Absolutely. I think this goal of writing simple code, even that like when you try to write simple code for me, it’s really hard because what is simple code? I think that really depends on the person who’s reading. In many cases, it’s almost impossible to say, “This is simpler and this is simpler,” because it really depends on who’s reading it.

                    For me, sometimes I think the For Loop is a lot simpler and sometimes I think a map over an array is a lot simpler. There were big many people who will disagree me and they will be right as well. I think it’s very hard to find the balance there.

Jaim:             Most languages other than Swift that Swift developers are write again or use for a For Loop, they’ve been around forever. Map has also been around for a long time but it’s widely used and for language that most Swift developers are using. If you’ve been a functional programming for a long time, you’re very familiar with map. Most of us started doing bittorrent core procedural stuff where you just For Loop everything. That’s more common pattern even though mapping is very powerful to write approach in a lot of cases.

Chris:            Yeah, exactly. What kind of issues did you guys have with structs so far when using them? Did you have any issues?

Andrew:       I think the biggest issue I’ve had is so far most of my work in Swift has been in code bases that were mostly Objective C where I was adding Swift to an existing project instead of starting from scratch. Although I imagine running somebody’s same problems even from scratch Swift project. Basically, if your Swift code need to interact with Objective C at all or especially past value into it, it becomes difficult to use structs because they don’t bridge into Objective C. I suppose they minimally bridge into Objective C now in Swift 3.0 but not in a way that your Objective C code can really use them.

Chris:            Absolutely. I remember last year at Swift Summit in San Francisco, there was a talk by Andy Matuschak and he explains some of these problems. He had some really good solutions as well but it wasn’t beautiful.

Andrew:       Right. I think maybe just in some degree that’s a price that has to be paid if we’re going to keep using Objective C and Swift together. One can hope that someday, Objective C is not in the picture and we don’t have this problem but for now, it’s still a real thing.

Chris:            Yeah. I think it’ll stay like that for quite a while. All of UIKit is written in Objective C. I think it’ll take a really long time before we start not worrying about bridging anymore.

Andrew:       Yup. All of UIKit is written in Objective C and I was just looking at the documentation for the new UI feedback generator which is API for using the topic engine. It’s, I think, only for the new topic engine in the iPhone 7. It’s probably the newest API we have right now in terms of it being public and of course it’s all still Objective C.

Chris:            Yeah. I think as far as I’ve heard outside of the Swift team, people are in 3D, writing Swift inside out but at least not until there is API stability. It’ll take quite a while. We probably won’t have any Swift frameworks.

Andrew:       2018 though. We can hope.

Jaim:             Chris, there is probably more to talk about value types but I wanna talk to you a little bit about objective c.io, perhaps I pronounced that wrong.

Chris:            Any pronunciation is fine. I’ve heard every possible pronunciation. They’re all good.

Charles:        Just munch a bunch of sounds together.

Jaim:             Can you tell us a little bit about how this got started?

Chris:            Yeah. 5 years ago, I just moved to Berlin and I wanted to go to a conference on iOS development and there was none. The only conferences there were were in German and I’m not a native speaker and you don’t really wanna go to a German speaking conference.

I asked around and there was nothing and then I organized my own conference because if nobody does it you have to do it yourself.

The day after that conference, we were sitting outside with some of the speakers, Pete Steinberger and Florian Kugler and Daniel Eggert. We were talking about writing a blog together. After thinking about it for a week more, I managed to convince the other two, Daniel and Florian to call it a magazine. That really helped in finding the format. We decided to have a magazine with monthly issues.

We were really lucky that we immediately started working with Nathalie. He was our copy editor because none of us are native English speakers either. We started writing and we had this person there who would make sure that our English is correct. Daniel, who worked at Apple, he just knew so much.

                    At that time, I was relatively inexperienced and Florian was even more inexperienced. We had Daniel correcting all of our technical stuff. Nathalie’s correcting our English. We teamed up with the designer to make a nice design. When we launched it, it really hit a sweet spot because it was longer articles, well edited and well designed and all the people who are involved contributed to it.

                    If one of us would’ve been missing, it would’ve been a very different thing and probably not nearly as good. It was the right time, right place, right people then we took it from there.

Andrew:       It turned out really well. I think most of our listeners, I think most of iOS developers in general have heard of obejctivec.io and have read it and benefited from it. I certainly have. I haven’t read every single article and every single issue but the ones that have interested me have just been really well done. I’m glad that that happened.

                    Sometimes, I think it’s really easy to have a cool idea with some friends and you talk about doing it but it’s a lot harder to actually make it happen and turn it into a success and takes a lot of work.

Chris:            Yeah. I think it was. Well, thank you. We were really lucky. At that time, when we started, Florian and me had a bit of extra time and we were lucky to be working with Daniel who just knew so much. In the beginning we would write the articles and Daniel would send them back and say, “No, no, no, no, no. It’s all wrong.” Going through that and trying to figure out what was correct and how things really works. I was just learning so much.

                    I think having these people around for all of us was a really great experience and we were also so lucky to have all these guest authors. We basically, out of the blue, would email people, cold email people saying, “Hey, do you wanna write for us?” So many great people said yes and wrote. It was a really good thing to do but it also caused a lot of effort. At some point, we ran out of ideas and inspiration and we decided to put it on hold.

Andrew:       Great. I was going to ask you about that. You did 24 issues. The last one was last year, some time, and which was about audio. I spent the last five years working on audio apps so that one was particularly interesting to me and that was good but then you’re not doing the magazine but you’re doing other cool stuff now.

Chris:            Yeah, exactly. We wanted to do some books. Two years ago when Swift came out, I realized, “Oh my God, now we can do a functional programming.” I just really wanted to write this book about functional programming in Swift. I managed to convince Florian and Vouter, my co-authors to do it with me. I felt the obligation to show people what kind of cool stuff you can do with functional programming.

                    It’s definitely not a silver bullet and it’s definitely not a solution for everything but there is some really nice things that you can take away from it. We started writing the book and that basically is a full time thing. It’s a lot of work to write a book and because it worked pretty well, we started writing more books. A while ago, we realized that we wanted to do more regular things again.

                    A book is a really big project and takes a long time and we wanted to ship more often and do quicker things. Generally, Florian and I said, “Let’s do videos.” And we experimented for a long time with different formats and different ways of doing everything. We found that short discussion like videos worked well for us. We ended up making Swift Talk. It’s been really fun and I don’t know how long we can keep that up but we have a lot of ideas still.

Jaim:             What other types of products are you working on other than video?

Chris:            The last months were full time book writing and then making videos. The last two years, mostly been doing that. Writing books, making videos, researching Swift and sometimes we give workshops. We wrote some Mac apps. Our last app was written in Swift, it’s called Scenery and before that we wrote a Mac app called Decksets. I’m not really involved in the daily development of that anymore.

                    There’s one more thing. A week from now, we’re organizing a small conference called The Functional Swift Conference and we organized it two times before, three times, I think two times in Brooklyn. This edition is going to be in Budapest. It’s just something I do with two friends, Agnes and Brandon. The conference is for free.

We don’t pay anything. We don’t make anything. Basically no money involved and it’s just a hobby thing to get all the functional Swift people together and have a few nice days in Budapest.

Jaim: For spending this hour talking about mutating, how did they let you win the conference?

Chris: That’s my secret plan. I organized the conference so they’ll have to let me in. I’m gonna tell the functional people that they should be mutating more which is basically the opposite of what they wanna hear.

Jaim: I wanna see a gopro in that room.

Chris:            Maybe to come back to that topic for just a little bit. In the beginning, we talked a little bit about mutating and how these global effects can be dangerous to your codes. If you’re mutating things globally, especially when you’re mutating something in a very different place from where you’re using it, this can lead to unexpected cases.

The big thing with Swift structs is that the mutating is only local. It’s never global. You’re only mutating the local variable and you’re not mutating any other variables. That’s why it has all the benefits of mutating but none of the drawbacks.

Jaim:             That’s a good point because if you’re creating a function that you pass on something, you create a function, you return it. If it’s a reference type, you have to worry about what they’re doing with that, if you’re using it internally. If it’s a struct, you don’t have to worry about it, they can do whatever they want with it. In mutating, they can change values or do whatever their heart’s content but you don’t have to worry about it.

                    It’s off to somewhere else, they made a copy of it and that keeps your own code safer. That’s one case where you can mix and mash up, that’ll be a good benefit setting the best of both worlds in those cases.

Chris:            I think, in a lot of algorithms, mutation is a very natural thing and a very normal thing. You only expect it to be local and you don’t expect steady mutation changes global state. I think that Swift structs all this is exactly that. You have local mutation but you’re not changing global state. Basically, the way that you can naturally express algorithms without the complications.

Andrew:       If people wanna learn more, Chris, how can they do that? Like they wanna learn how to actually apply this to their code.

Chris:            Yeah. There are definitely a lot of things you could do. First of all, it’s just working with structs like working with arrays, looking at differences between let and var and seeing what happens. The Swift programming guy has a lot of good information on this. If you wanna go more into the detail about how this stuff works below the hood, you can either look at the compiler which is probably, unless you know C++, it’s not as easy.

                    You could of course read one of my books, I think Advanced Swift would probably be the best one for that. We’re updating it right now and it should be finished in one or two weeks. Maybe by that time the episode is public, it’s already out. Reading is just one thing and it can help a little bit but in the end just playing around with it and working with it will definitely give you the best understanding.

Charles:        Alright. Let’s go ahead and get to some picks. Andrew, do you have some picks for us?

Andrew:       Yeah. I’ve got I think really just one pick today. I’m gonna continue with my recent Retro Mac. I have two picks. I just thought a better one. My recent retro mac picks are gonna continue. My first pick is actually a podcast called the RetroMacCast which I just started listening to recently but it has been around since 2006 which is a long life for a podcast.

                    They’re up in a 400, they’re episode numbers are into 400s right now but they’re still doing it. There’s two guys that plugged old Macs and talked about them and have guests on. It’s pretty fun and interesting if you’re into that sort of thing and I’ve been enjoying it lately.

                    My second pick is along the same line, it’s actually some forums. They are called the 68k MLA.org forums. 68k meaning 68 Mac which is Macs before powerpc and MLA stands for Macintosh Liberation Army. This are forums with a bunch of old Mac enthusiasts. The thing I really like about them is there are real technical experts there. I’ve been working on a Mac plus and having a hard time getting it to boot from an external drive.

                    I asked a question there and immediately got an answer from a guy about how is some deficiency in a certain version of the Mac plus ROM that didn’t support a certain scuzzy command because this scuzzy standard wasn’t finalized and it’s just really esoteric stuff. It’s 30 years obsolete and they still know the stuff. Pretty cool resources if you’re doing anything with the old Macs. Those are my picks.

Charles:        Awesome. Jaim, what are your picks?

Jaim: Today, this week, during this week it’s the Twin City startup week where they showcase everything that was happening in the startup community up here in Minneapolis-St. Paul. It’s a great event. There’s a lot of big events.

They will actually fly people out. If you’re interested, check it out. They will book you a ticket and reimburse you. Most people who listen to this program would qualify. Every place, we’re looking for more development talent. We’ve got lot of cool things. We’ve got huge companies like target doing incubators. There’s lot of cool things happening.

                    If you want a free trip to Minneapolis in September, weather is beautiful in September, fall is awesome. Don’t worry about that. Maybe next year. Check it out. I’ll put the link in the show notes. It’s a cool event and it happens all over the place. That’s my pick.

Charles:        Alright. Rod, what are your picks?

Rod:             Yeah. Can you hear me?

Charles:        Yeah. By the way, Rod’s back.

Rod:             Yeah. Sorry I came in late. I had another phone call and just wasn’t able to get right on. Anyway, I wanted to pick everything that Chris has done. I’ve really enjoyed the books, Functional Programming in Swift was a fun read. Thank you Chris for writing all that stuff.

                    I’d also like to pick UI Document Picker New Controller. I’ve just put that in my app and I was able to rip out my Dropbox dependency and use iCloud drive and everything to work with. Those are my picks.

Charles:        Awesome. I’ve got a couple of picks. The first one is a book. I just finished it last night. I’ve been listening to it on Audible. It is called Michael Vey: Fall of Hades. It’s the next book in that series. I really enjoyed them. I’ve really enjoyed the books all the way through. If you’re looking for something, it’s young-adult fiction. I guess there were some other popular series of young-adults as well like The Hunger Games and stuff. It’s kind of on that level as far as reading level goes and the complexity of the plot line. They’re fun books and I really enjoyed them. I’m going to pick those.

I’m also gonna pick Webinar Jam. This is a software that I’ve been using for a while now to put together webinars and online conferences. I switched off of CrowdCast mainly because I couldn’t get high definitions recordings off of it. Webinar Jam uses Hangouts On Air.

                    Since Hangouts On Air record HD, I can get HD or pretty darn close. I’ve been doing webinars all last week and this week and I’m going to continue to do them. The ones through the end of the year are focused on finding a job. If you want to check that out, go to getacoderjob.com and check it out. The picks are Webinar Jam and I guess Get a Coder Job.

                    I’m hoping to make some good progress on that book over the next few weeks. Keep an eye out for that as well. It’s a book and it’s gonna be the webinars series as an online course. If you’re trying to find a job, if you’re new to programming, this is pretty much directly toward you. Chris, what are your picks?

Chris:            Yeah. I have three of them. I don’t know if that’s too much. I just wanna give a shout out to some less well known developers. Maybe you can start with Carole. He is writing these data structures in Swift and he’s really pushing Swift to the limit. He has his open source implementation of a B3. It’s just really cool to have a look at it and try to fully understand it. I don’t fully understand it but anytime I look at it and try to read about it and learn about data structures and about how Swift works.

The second one is about Rick and he’s writing a Gameboy Assembler in Swift. He is writing the parser and also I think an executor to run Gameboy assembly code. I don’t know if in the end you can run full Game Boy games but it’s all written in Swift and it works on a Mac or on iOS.

The final one is just Kyle Fuller’s GitHub repository. GitHub profile, he makes a lot of cool stuff and he has a lot of interesting things around web development for Swift and making things more standard. Anytime I look at his GitHub profile, there is some kind of new cool projects. It’s just somebody to keep an eye on.

Charles:        Alright. Anyway, thank you for coming. This was a really fun discussion and it’s kind of a different way of doing things, I think, than most of the panel does them. Those trade-offs are definitely things to think over and figure out how that can affect your code. We’ll go and wrap up the show. We’ll catch you all next week.

Chris:            Thanks for having me.

x