Did anyone else find this chapter challenging?

I am new to programming and thus have moved through this book at a snails pace, but thus far, I have grasped everything and can do all the challenges with ease. This is the first chapter that I have gone through twice, and still do not seem to be prepared to answer the challenge without looking at sources. I can understand all the code from everyones examples, but am having trouble creating my own solution. Does anyone else think that that the end of this chapter hits you with a lot of code and not much explanation? I do love the book, thanks BNR!

If you are new to programming, objectiveC can be most challenging. Ive been a programmer for 20 years and have programmed in almost all major languages, I wanted to learn objectiveC so I bought this book. I recommended it to a friend of mine who was never programmed as well. As a new programmer, there are two hurdles in front of you. The concepts and the syntax. The concepts are pretty much the same throughout all object oriented languages. The syntax differenciates the languages.

ObjectiveC in my opinion has a high degree of complexity. There are other languages out there that have a much less degree of difficulty in their approach to language structure. As I mentioned before, my friend who is new to programming stopped around this stage as well, and moved to python to understand the concepts first and then is going to come back to objective c. Python, Delphi, Ruby are all languages that are much more forgiving and understandable to a beginner for those wanting to grab the concepts. It makes the move to objective C much easier.

I leaned to program using C and pascal, then moved on to C++ and Delphi (object pascal). Now that I have the concepts down pat, understanding the syntax became vastly less difficult in objectiveC. Im on chapter 25 and I can honestly say that objectiveC is a very unapprochable language, I look how other languages approach similar problems and they seem to have a much more simplistic approach in their foundations. However, Im only fighting one battle, the syntax (Language structure).

This of course is from a seasoned programmer who has experiences in many languages but just learning objectiveC. The reasons for its complexity may come more clear as I continue, but its frustrating programming in it knowing how much simpler other languages are. But my goal is to move to the iOS platform, and objectiveC is where you need to be.

My recommendation for you would be the same as my friends. Learn programming in an easier language first, then move to objectiveC. This path is longer but I believe it may give you a greater chance of success in the long run. But of all the books Iā€™ve read over the years. The Big Nerd Ranch guides are by far the best structured and written, I would recommend their books to anyone of any skill level.

Hope this helps.

While I donā€™t disagree with much that richfrag is saying, I am not sure that this is the OP issue.

I found the end of this chapter to not be especially well though out from an instructive point of view. I completely understand what the authors are trying to demonstrate but the way they go about it I think is whatā€™s creating this confusion. I donā€™t know about others but I really hate to simply type in someone elseā€™s code. My brain tends to turn off and I become a stenographer. I get that we need to type some of this in and I did not have issues with past chapters but the end of this chapter had far too much typing with too little payback. Much of this typing was about showing object deallocation and creating randomness. I appreciate the authors getting hands-on to show this rather than just explain it, but all of the typing didnā€™t justify the means. Itā€™s not a huge mental leap to describe deallocation with ARC to begin with. Additionally, there is a bunch of stuff that we typed for no other reason than to create random numbers to fill the array. Again I get what they are doing but I believe, especially to those new to the language, that all of this random code creates unnecessary clutter. In my view I would not use end of chapter nor the challenge questions as an indicator of whether it is better to start with another language. Get it as best you can and move on. You are sure to come across these ideas elsewhere and likely you will find other approaches and experiences to be what makes it click better.

Just wait until you get the iOS to see how much more stuff is overlaid on top of this! You ainā€™t seen nothing yet. :smiley:

I too am a fan of BNR and think this book his the right balance between new and more seasoned programmers. But, it isnā€™t perfect (nothing is) and this portion is the first I have come across in this book that has been a bit of a let down.

2 Likes

Thanks C6silver, I found your answer insightful. As a total noob to objective-c I have been going back and forth on trying to understand everything the first time through and just moving on and trusting that the information will come back around and make sense later. Iā€™m now leaning more towards the latter as this is totally new material to me, and trusting that if I keep studying and learn from different sources it will all start to make sense eventually. I appreciate this community! You guys and gals are the best.

While itā€™s not emphasized in the book, I have had an easier time understanding whatā€™s going on by setting break-points within the programs prior to running them. If you think youā€™ve got an understanding of whatā€™s going on in the code, set a break point at the end of a task within the program. Once it hits the breakpoint, study whatā€™s going on in the ā€œvariables viewā€ in Xcode (at the bottom to the left of the console).

The best analogy to following the book and pressing " run" I can think of is hitting a golf ballā€“you can ā€œgrip it and rip itā€, see that it flew far and landed where you thought it would, but without understanding the mechanics behind the swing in slow motion itā€™s hard to replicate.

I couldnā€™t agree more. Once I finished the chapter I thought Iā€™d visit the forums to see if others had the same experience.

I have >20 years of programming experience and this is my first foray into Obj-C. Iā€™ve been cruising through the book (my wife thinks Iā€™m obsessed) and when I hit this chapter everything slammed to a halt.

I totally understood the concepts introduced as Figure 21.1 and 21.2 - makes total senseā€¦ but when the ā€˜Adding a to-many relationshipā€™ section started the wheels feel off. It started with the NSArray really pointing to a NSMutableArray.

Iā€™m going to continue on in the book and try to supplement this section with other material.

The book has been fantastic - and I hope this is just a minor hiccup in teaching style.

:mrgreen:

Same impression here. Some parts of the code are still a mystery for me. For example :

[quote=ā€œahayesā€]It started with the NSArray really pointing to a NSMutableArray.
[/quote]

I read many times the code and the paragraph about that part, and I still donā€™t understand what the authors meant. I just started a topic about it, hoping to be enlightened.

Iā€™m trying to understand this chapter also. He glossed over some really important topics. I kinda understand the whole idea of creating a copy of your data so no one can actually change it because an array is actually a pointer to a location. However, my gripe is with the example. BNREmployee.m throws errors for me in the valueOfAssets function. I figured out some stuff with the example finally.

The reason for declaring an NSArray and an NSMutableArray is that you want people to have access to get the value of the array out but you donā€™t want them to be able to change it without going through an accessor method. You have two choices you can either add an NSArray of assets which is turned into a mutable copy and sent to the NSMutableArray you declared or you can add directly onto the NSMutableArray one item at a time.

To get the value out it returns a copy of the NSMutableArray as an NSArray which cannot be changed.

I think people should learn the language they want to first because they are more likely to fight through the trials and tribulations associated with programming. You learn from failing over and over and over again. Fail fast and learn from it.

I have the same problem. I went fast through all previous chapters, but stuck here for about a month already. I will re-read the chapter to the 7th time now. Those arrays tricks are a concept that is very hard to understand, even with the code examples provided.

Glad to hear Iā€™m not alone.

Really wish there was more time taken describing what each block of code I was adding did, seemed like a lot of new syntax (mostly for creating the randomness) without much explanation as to what was being done.

Not sure if the best course of action is read and re-read the chapter (and code) until somehow I figure it all out or just move on?

In a word YES.

As a fifty something year old, old programmer I am totally aligned with the old (that word again) way of programming. Or maybe itā€™s an alternative way of programming. Trouble is, I cannot stop my brain trying interpret OO stuff in a procedural fashion. That said, up until now everything has been fine and slowing the material is being absorbed but this chapter required many reads, days away, then a re-read iterated a few times until finally it has now sunk in.

This book is very good, but along with some others, I feel this chapter could be better presented and explained, especially the Main code with a simple note to mention that random numbers and operations are being coded simply to modify the data for demonstration purposes. Please do not tell me Iā€™ve misunderstood that bit otherwise I will return to COBOL forever. Or I might just throw in the towel, grow a ponytail and beard, get tattooā€™ed, enlarge my beer belly, have my ears pierced, buy a Harley and trash the country roads of my English homeland.

The stuff on this forum is generally extremely helpful, so thanks to everyone who takes the time to share!

1 Like

Iā€™m so glad that Iā€™m not the only one. It seems like all the Obj-C issues aside, almost every programming book has a chapter like this, the one where I want to quit because I donā€™t know whatā€™s going on anymore. I think I might not spend too much time beating myself up about it, though, because I want to learn the rest AND get to iOS.

If you are finding this chapter challenging, you need to improve your dexterity working with Abstract Data Types.

The phrase Abstract Data Type means nothing more than a template for creating a piece of data (with hidden internals) and a set of functions designed to control access to that data.

ADT is the acronym for Abstract Data Type.

In OO jargon, an object is nothing more than an instance of an ADT; sending a message to an object is nothing more than invoking a function on an instance of an ADT.

So how do you write code for an ADT? You first start learning a language designed for that purpose, languages such as C, C++, Objective-C, Swift, Java, etc. The most portable and technology neutral languages are C and C++.

Here is an example of an ADT for maintaining a list of unique integers, written all in C.

main.m - Test drive an instance of MyList ADT:

// main.m

#import <Foundation/Foundation.h>
#import "MyList.h"

// --------------------------------------------------------------
//
int main (int argc, const char * argv[])
{
    MyList list = MyListCreate ();
    assert (list);
    
    list = MyListAdd (list, 17);
    list = MyListAdd (list, 19);
    list = MyListAdd (list, 23);
    list = MyListAdd (list, 23);
    list = MyListAdd (list, 29);
    
    assert (MyListLookup (list, 17));
    assert (MyListLookup (list, 29));
    
    assert (!MyListLookup (list, 1));
    assert (!MyListLookup (list, 8));

    void PrintNumber (long, void *);

    MyListPrint (list, PrintNumber, 0);
    
    return 0;
}

// --------------------------------------------------------------
//
void PrintNumber (long number, void *context)
{
    printf ("%s: %ld\n", __func__, number);
}

MyList.h - Interface

//  MyList.h - Abstract data type for a list of unique integers

#ifndef MY_LIST_H
#define MY_LIST_H

// Abstract data type
typedef struct MyList * MyList;

// Create a new list object
MyList MyListCreate ();

// Create a new list from an existing list and a number if the number is not in the list
MyList MyListAdd (MyList, long);

// Value type for YES or NO - Zero for NO, Nozero for YES
typedef long MyBool;

// Tell if a number is in the list
MyBool MyListLookup (MyList, long);

// Type for print delegate
typedef void (* MyListPrintDelegate) (long, void *context);

// Print the contents of the list with the help of the delegate
void  MyListPrint (MyList, MyListPrintDelegate, void *context);

#endif

MyList.c - Implementation

//  MyList.c - Abstract data type for a list of unique integers

#include <assert.h>
#include <stdlib.h>
#include "MyList.h"

// ------------------------------------------------------------------
//
// A list is simply a sequence of linked integers
struct MyList
{
    long  _number;
    MyList _next;
};

// ------------------------------------------------------------------
//
static struct MyList * _MyListCreate (long, const struct MyList *);

// Create a new list
MyList MyListCreate ()
{
    return _MyListCreate (0, 0);
}

// ------------------------------------------------------------------
//
// Create a new list from an existing list and a number if the number is not in the list
MyList MyListAdd (MyList list, long number)
{
    if (MyListLookup (list, number)) {
        return list;
    }
    else {
        return _MyListCreate (number, list);
    }
}

// ------------------------------------------------------------------
//
// Tell if a number is in the list
MyBool MyListLookup (MyList list, long number)
{
    const struct MyList * node = list;
    while (node && node->_next) {
        if (number == node->_number) {
            return 1; // yes
        }
        node = node->_next;
    }
    return 0; // no
}

// ------------------------------------------------------------------
//
// Print the contents of the list with the help of the delegate
void  MyListPrint (MyList list, MyListPrintDelegate delegate, void *context)
{
    const struct MyList * node = list;
    while (node && node->_next) {
        delegate (node->_number, context);
        node = node->_next;
    }
}

// ------------------------------------------------------------------
//
static struct MyList * _MyListCreate (long number, const struct MyList *next)
{
    struct MyList *list = (MyList)malloc (sizeof (struct MyList));
    assert (list);
    
    list->_number = number;
    list->_next = (struct MyList *)next;
    
    return list;
}

[Accelerate your learning and become a competent programmer: pretty-function.org]

I found that the ā€œhiding mutabilityā€ section of Chapter 22 really helped out with understanding the NSArray vs NSMutableArray thing. Putting both in the header file doesnā€™t seem like it would ever be the right thing to do, so perhaps a better solution (if there ever is a 3rd edition now that Swift is arriving) would be to just do it the way Chapter 22 does from the start with a small ā€œweā€™ll explain laterā€ disclaimer.

Oh yeah. For sure. It wasnā€™t too bad at first fig 21.1 made sense, even 21.2 but 21.3 started a little, errr, off to say the least. It wasnā€™t until the adding-to part that just threw me off completely. Then we implemented accessors to properties, if that even makes sense. That whole section was ill-explained and made little to no sense. I donā€™t think it has anything to do with the amount of years in programming as some here have suggested or anything else, I think it simply has to do with the fact that it was poorly explained. I think Hillegass went off on a tangent when he wrote this part, I think he mightā€™ve forgotten that were not at that level. This is an excellent textbook and Iā€™d highly recommend it to anyone with some experience but I will say this chapter was rather disappointing. I can respect the fact that he wants us to learn in the struggle as thatā€™s been the theme of the book and although it is effective this is virtually impossible to learn without additional resources.

For what is worth: I found this chapter to be the most challenging so far. Also the most cryptic. Iā€™m glad to know Iā€™m not alone.

Anyway, Iā€™m still trying to understand its contents and make it through the challenge.

Iā€™ve had the same experience here. Been working my way through the book and have generally felt like Iā€™m getting it (even though it is pretty challenging) this chapter left me feeling like I must have missed a couple key concepts leading up to it. Iā€™d love to see an update or maybe the authors could post a video breaking this code down a bit more into baby steps.

Gonna forge on and hope Iā€™m not completely lost. Thanks for sharing your experience.

Iā€™m glad Iā€™m not the only one struggling with this chapter. I have been exposed to Objective-C during university (for a short time, granted) and thought I understood the basics. This book has really helped nail the concepts in, but this chapter in particular has been tough to get my head around.

I found it helped me to read the chapter again and step through each line of code using breakpoints - the debugger console is very helpful to see which values get assigned to the different properties and variables, and helps you understand the exact process happening at any given time while the program is running. I would recommend anyone to use breakpoints to step through the code throughout the entire book, as the console has definitely helped me.

Hey guys.
I felt exactly the same with you a month ago and after reread this chapter for like ten times and redo the code three times, something was still confusing. So I decided to skip a little bit before all these confusion kill my interest in coding and moved on to next chapter. Well I have to admit that I met quite a few challenges because of the skipping but then when I moved on to the next book IOS Programming(4th edition), in the opening chapters, I found my confusion disappear little by little. In that book the author spent more time explaining everything. Well if you still are stuck in this chapter, maybe you can skip a little bit and try that book.
Hope my wordsā€™ helping.