Iron Update: Week 6 | Swift Rules, Objective-C Drools!

No, not really. I’m firmly of the “different tools for different jobs” school, and try to see the pros and cons of whatever language, OS or hardware I’m using. I’m sure if we had learned Objective-C first, my feelings would be reversed. This week we tackled Objective-C by recreating previous projects that had been completed in Swift. Objective-C does have more online help, tutorials, Stackoverflow posts and so on. Pointers negate the need for delegation, in some situations, which is convenient. The lack of optionals is also nice. I’m sure that there are other things that are easier to do in Objective-C, but we haven’t run across them yet. The lack of tuples, the limitations of switch statements, and only being able to iterate over an array only if you use an object gave me some trouble when trying to translate a project that relied heavily on all three. String interpolation is awkward, and not really interpolation, but not impossible.  On a positive note – and this is language independent – I have a better grasp on segues and alternatives, and how all the pieces work together. Several of our previous assignments have been completed entirely programmatically – no storyboard – and replicating that work in another language is also helpful for understanding the pieces.

We also teamed up for pair programming for all the assignments this week, which didn’t go very smoothly. It may have been better to call it a team or group project, than pair programming. Several of the groups that paired off ended up with one student doing the majority of the work, trying to explain what they were doing as they were learning themselves. That isn’t to say that anyone’s particular strategy to solve the problems were more “correct” than another approach – there is no one true way – just that many of the groups were more tutoring than they were pair programming. If the goal is to have students help each other learn, a better tactic might be to teach half of the class one technique, and the other half another technique. Then, match students from the different groups, so they can teach what they learned to their partner. Pair programming should, ideally, be where one partner writes the code, and the other directs and proofreads. This works best when the partners have an equivalent knowledge of the language, or a senior programmer can coach a junior. The key point is that both partners need at least a basic knowledge of the language, and a firm grasp of OOP and the logic needed to complete the assignment.


Sun [8 hours]: Final day of Weekend Launch

Mon [12 hours]: Intro to Objective-C and pairings to recreate first assignment

Tues [10 hours]: Code-based layout, sessions and delegates in Objective-C

Wed [8 hours]: AVFoundation in Objective-C and another assignment translation

Thur [11 hours]: Reviewed the previous night’s assignment, they paired off to work on an entirely new project in Objective-C, utilizing APIs

Fri [8 hours]: Guest lecture was a no-show, so we spent the time working on our weekend assignment with our partners

Sat [0 hours]: Family time

Weekly Scrum:

Bright bulb: When you have a good partner, and can split up the work and have someone to help you figure out errors, it can make a project go much more smoothly.

Dim bulb: Objective-C still isn’t my friend, but I’m getting more comfortable. I’m familiar with the basics of pointers from Java and C, and their are some benefits, but they can be a serious pain when you haven’t used them in years.

Blocker: It’s really difficult to teach someone how to do something in a new language, when you are still trying to figure it out for yourself.

Tags: , , ,