I'm a designer taking a Treehouse course on iPhone app-making and the code part doesn't seem to be sinking in. Any tips or tricks to get myself into that kind of headspace?

October 8, 2012 12:52 PM

I'm a designer taking a Treehouse course on iPhone app-making and the code part doesn't seem to be sinking in. Any tips or tricks to get myself into that kind of headspace?

It's not so much that I can't handle any code at all. I love to sling CSS and rearrange HTML and php but this string stuff is making my brain glaze over and I refuse to accept that. How can I better get my head in this game?

posted by Senor Cardgage to Computers & Internet (9 answers total)

@"Keep going. Ask questions. Keep going. I also recommend going through some of the iOS programming courses on Lynda.com. New concepts are nearly always mighty confusing. Keep going. Get plenty of sleep. You'll get there in the end.";
posted by run"monty at 12:59 PM on October 8, 2012

Just don't give up. Right now you're having trouble with new concepts, but a month from now you'll wonder how the hell you ever thought it was difficult.

Also identify what you're not understanding, research the hell out of it online and then practice until you get it. Whenever one tutorial or explanation isn't making sense, look for another one. If you're learning Objective-C, find an Objective-C book or tutorial set online and work through any problems in those.

You'll get it in the end!
posted by anaximander at 1:02 PM on October 8, 2012

HTML and CSS aren't code; they are markup. I imagine that a good bit of what you're struggling with is the transition from fairly high-level scripting and markup to somewhat lower-level coding -- which involve handling data, rather than the presentation layer -- the latter of which is probably closer to what you're familiar with as a designer. If my hunch is correct, what you need is a better grounding in how data moves through a computer, before you try to learn the syntax of, say, string handling.

I learned to code from reading and working through Kernighan and Ritchie's The C Programming Language. While C may not be terribly useful outside of driver and system coding today, the basic principles of variables, memory handling, and good technique are still foundational to writing programs. K&R's book is short and easy to work through, as a side benefit.

You'll not learn anything about object oriented programming by studying K&R's text, however. OOP is a paradigm/world view for writing programs, often deeply intertwined in modern languages, and iOS development is no exception. Objective-C is similar to "classic" C, but it includes some OOP stuff as well, and once you have a rough handle on C you'll better appreciate how procedural code and objective code differ.
posted by ellF at 1:13 PM on October 8, 2012

Response by poster: My head a splode
posted by Senor Cardgage at 1:15 PM on October 8, 2012

OK -- what part lost you?

The fundamental issue is that you have some experience in editing markup languages, and you want to learn to write code. By way of analogy, you've gone to Home Depot and bought paint and put it on your bedroom wall, and now you're asking how to frame a house.

The two are related, but the skills are different, and the latter is more complex. The stuff in your iOS course that's losing you -- "string stuff" -- is the nuts and bolts of handling data. You're not going to intuit it; you need to start more basically, by learning why data management is the core of programming. Extending our analogy, you don't grab a pile of 2x6s and say, "Ha! I've never built anything! Let's do a gable-roofed barn today!" Instead, you need to start by learning how to operate some tools, how to read a plan, and how to properly construct a wall/roof/whatever.

For the iPhone, coding uses a language called Objective C. Objective C is based on an older language called C, which is actually pretty easy to learn. The biggest difference between C and Objective C is that the latter is "object-oriented" -- meaning that it takes the view that a program is really a collection of "stuff" that "does stuff", rather than "code that the computer walks through from top to bottom". Before you get into why that matters, you need to get your head wrapped around the basics: what does code look like? What do labels like "int", "char", or "string" mean? Why do you have to explicitly name variables with labels ("types", more properly) in C and Objective C?

Does that help to narrow down (a) why you're confused, and (b) how to get un-confused?
posted by ellF at 1:25 PM on October 8, 2012 [1 favorite]

Response by poster: OK that helped. I got ya :)
posted by Senor Cardgage at 1:30 PM on October 8, 2012

Response by poster: Also I wrote a ton of Basic in 1985, but thats almost certainly irrelevant here.
posted by Senor Cardgage at 1:31 PM on October 8, 2012

Best answer: I'm going to apologize in advance if this is not the kind of abstract explanation that is useful to you, and if it's just more confusing, of course I hope you just ignore it. Also, I'm going to gloss over some details and corner-cases and exceptions that later down the line you might think "hey, wait, that thing Jeb said is not totally true" just because it's going to make this story a lot more clear.

I've seen a lot of people trying to get into lower-level programming struggle with the fact that It's All Just Data. I think the fact that you've programmed BASIC before is totally relevant, as is the fact that you've done CSS/PHP/HTML. Those tools make your life easy, by pretending that it's not All Just Data. But it is. The lower-level tools you are learning to use now remove that illusion, and the sooner you grasp that, the easier it will be. Have you ever seen The Matrix? Do you remember that part when Cypher is showing Neo those computer screens with all the green symbols on them?

Neo: Do you always look at it encoded?

Cypher: Well you have to. The image translators work for the construct program. But there’s way too much information to decode the Matrix. You get used to it. I…I don’t even see the code. All I see is blonde, brunette, red-head. Hey, you uh… want a drink?

Ok, let's try to put aside the fact that I just used a horrible Matrix analogy to explain this. If anything, it should help establish that I am the type of huge nerd you can trust on this sort of topic. But the point is, the image translators and the construct program are browsers, the PHP interpreter, and so on. You don't get to use those any more.

In those worlds, you have a sort of highly-complex, fairly opaque Machine, and you can feed different things to it: styles, image files, text, etc. In the case of HTML, you have markup, and the machine for it is the browser. Unfortunately, this is rather difficult to discuss on the Ask Metafilter codebase. But imagine this: you have a div, it's class is "foo". The contents of the div are "bar". The browser never gets confused about that. There's no way for the class to become bar, say. You start writing styles for the foo class and they show up there. Easy.

Similarly, you load up an image in an img tag with src="whatever.png". The data in that image is always an image, the browser takes that whole thing as one big instruction: load up this data, it's a png, draw it somewhere. You never have a problem where the browser starts writing all kinds of 1s and 0s or raw hex to the screen when you try to load an image, it would actually be fairly tricky to get the browser to do this, because it's segregated off the image data as an image for you, and it handles it specially.

At the same time, what the browser does is fairly opaque to you. Internet Explorer version X draws a border 1px lower than the other browsers: you don't get to see into the complex rendering model that Internet Explorer uses to do this, you just have to find a workaround. You trust that somewhere in Internet Explorer, there's some code that translates HTML layout rules into actually drawing stuff on the screen, and somebody there either made a mistake or interpreted the spec differently than the other guys, but you don't have any control over it. Javascript gives you an error code. Ok. That's it. There's no deeper level to go to.

In lower-level programming, like iOS programming, everything is reversed: the machine you are using is the computer, and it is fairly simple. Everything that goes into it is the same: your code gets compiled into a bunch of data and loaded into memory. You load other resources like images and strings into memory. You read and write data from memory. All memory is a huge long list of numbered numbers. Address0: 0. Address1: 0...and so on. There's literally nothing else. All you can do is get numbers at a specific address, put numbers at a specific address, or do arithmetic and comparison tests with numbers.

Everything else is just the computer munching down the list of instructions in your code and jumping around in memory. There are no tricks. There's nothing opaque. It's complicated, in the sense that a huge ball of string is complicated. It's all just string, twisted around more string, no matter how long it takes to unravel.

In Xcode, you can always see what the computer is doing: you can watch it march through instruction by instruction and say "Ok, if the value in memory here is 3, jump over here." The language, Objective-C, hides a little of this from you, for ease, but not much, compared to something like PHP.

And so the reason your Objective-C tutorials are littered with things like NSString *string = [NSStringFromSomeOtherThing thing]; is because as far as the computer is concerned It's All Just Data. "thing" is just an address. It just means "written over here in memory location 1234 is something I might want to look at again. When I say 'thing', look there and give me the number." But it's just numbers.

So to do essentially anything with it, you need to give the computer more instructions, like "well, I want to print this out for a human to read, so I want you to take each of the numbers and draw the corresponding letter on the screen. 65=A, 66=B, and so on." That's not a fake example: all that nonsense in NSString with stringWithCString, StringWithUTF8String or whatever are literally telling the computer which table of number-to-letter mappings should be used, because of course in our infinite wisdom we made up like twenty different lists.

Now, remembering this won't make your brain not glaze over, and it won't necessarily make anything any easier, but it does mean you can always figure it out. It might take forever, it might be incredibly fiddly, but there is nothing magical that can happen. If you don't understand how [NSMagicalObject initWithOtherMagicalThing:zomg] works, you can always figure it out. Even if you don't have sources, you can play with putting data in there and see what comes out. You can step through the assembly in Xcode. Alllll the other stuff, all the object names, classes, selectors, categories, methods, etc. are just little extra decorations to help the humans organize their thoughts in a way the compiler can understand. But none of it does any tricks that you can't do without them. You can always, say, force a bunch of data into memory and then tell the computer to it's an NSString. You can always make your own rules about what number in memory should be what letter. If the data's not organized right, the computer will crash. You can say "hey, this data over here is actually part of the program, start executing it." There's rarely a reason why you would do this, and most of the time when this happens, it's because you did it by mistake (you will do this by mistake all the time), but it at least shows that there's nothing magic. The computer will always do exactly the set of fundamentally simple and comprehensible things you tell it to do.

Naturally, because the computer can only do very simple things (albeit at mind-boggling speeds), it is incredibly sensitive to how the data is organized in memory. So most of the mistakes you will make will be misorganizing the data in one way or another. Passing the wrong type of object to another method, is basically saying "start executing these instructions, don't worry, the instructions will be valid and logical and the data will be organized along these lines" and having that be wrong. You jump into the middle of some image data and start executing it, for instance. Or you pass a string that contains the characters "145" instead of a memory address that contains the numerical value 145 (In the computer's memory, the value 1 is represented as 0000000000000000000000000000001. The most common number used to refer to the symbol '1' represented as 000000000000000000000000011111. For compactness, we write these in hexadecimal as 0x01 and 0x1F, which mean the same thing, you are probably familiar with this from writing out RGB colors in HTML/CSS.)

All this stuff about Objective-C being object-oriented vs. some other language that's not only come down to the language giving you some handy shortcuts to organize things, but the fundamental picture is unchanged.

I bring this up because I know other people have struggled with it, and then they have a sort of "aha" moment. People at different levels will think "well, what the compiler does is magic" or "well, this is object-oriented, I don't really know how they make object systems" or window toolkits or whatever large complex piece of software it is they are working with. I think it's an important trick to keep in your mind that we don't always mean the same thing when we say something is "complex", and that this type of software writing is complex; it is the kind of complexity that grows from very many simple things being done very many times: New York City built from Lincoln Logs. There's (essentially) nothing the Objective-C runtime or the Apple libraries are doing that you couldn't do yourself, if you had enough time. The individual things are always simple. It's deterministic. You can always get it. It's just going to take longer.
posted by jeb at 5:10 PM on October 8, 2012 [9 favorites]

Best answer: jeb nails the foundational stuff well. Awesome summary.

I found that jumping into OOP languages was more complicated than learning C first; C is small, relatively simple, and covers ALL of the major "data" topics that jeb alludes to or uses examples for -- stuff like NSString *string being a pointer, for example. (What the hell is a pointer? Why do I need one? What does it even MEAN to point at a memory location when I try to assign a value to a variable? K&R will, by dint of working your way through it, teach you this stuff; this is the base from which you can begin to connect jeb's concepts with the pragmatic coursework you're struggling with.)

There are probably other ways, but in my experience, great coders operate on both theoretical and functional levels simultaneously. Programming is part art, part craft.
posted by ellF at 8:48 PM on October 8, 2012 [1 favorite]