macOS Learning C to learn Obj C

[cybrscot]

As many of you know, I'm currently learning C, from a book. My end goal is to learn obj c, so I can begin writing some apps for the iphone/ipod touch. Everybody has told me that I should learn C first, then move on to Obj C as it is based on C.

My book is about 600 pages, and is a very good book, but my question is....

Since I intend to really only use/write in Obj C, how much of C do I need to learn first, before I move on to Obj C? Do I need to be an expert in C? Or can I omit some chapters of this book that may possibly have nothing to do with Obj C??
Thanks
Scott

 

[Sydde]

As many of you know, I'm currently learning C, from a book. My end goal is to learn obj c, so I can begin writing some apps for the iphone/ipod touch. Everybody has told me that I should learn C first, then move on to Obj C as it is based on C.

My book is about 600 pages, and is a very good book, but my question is....

Since I intend to really only use/write in Obj C, how much of C do I need to learn first, before I move on to Obj C? Do I need to be an expert in C? Or can I omit some chapters of this book that may possibly have nothing to do with Obj C??
Thanks
Scott

The most important thing us to understand what you are doing. C itself is just a language, I learned C from the context of previously learning BASIC, machine code, Pascal and HyperTalk. What you are learning is programming technique more than C per se. But if you learn things that seem to fall outside the scope of Cocoa/Objective-C, bear in mind that Mac OS and iOS do make use of procedural C for many things, some of which you cannot do in Objective-C. You may be able to skim, but you should probably not skip. At least understand the material, you may need it at some point (except perhaps for the content relating specifcally to the standard Unix libraries).

 

[jared_kipe]

Depends on the book I guess. If you are reading Learn C on the Mac, which I'm not sure of its length, I'd suggest reading all of it. You will by no means be a C expert after it.

The thing about learning C is that it will not only help you because Objective-C is based on C, but also because it gives you insight on how the inner workings of any program is actually achieving what it is doing.

The less C you learn, the more forum threads you will end up making about "why this is", or "that memory bug", or "this crash".

 

[chrono1081]

As others have stated its important to know why something is doing what it is doing.

Whenever you learn programming, always learn one major language really well. This helps tremendously when switching to another language. All concepts are mostly the same, but the syntax is different.

If you know how programs work in one language, its easy to apply the same concepts to another language.

One more thing, you don't have to memorize every single piece of syntax. That usually comes over time. Its important though to be aware of features and how they work so that you can reference back to them when you have a need to use them. As a programmer you will reference ALL the time.

 

[lee1210]

This has come up at least a dozen times. Generally there is some debate about the "right" place to start, but generally the conclusion is "start something". You've already started working on C. The knowledge will not be wasted, you aren't burning time. I'd just stick with it. All C is Objective-C, so you're not going to write some C and have it fail when you're working on Objective-C.

The main reason people encourage starting directly with an Object-Oriented language is so you learn to think in Objects immediately, and don't have "hang ups" from a purely procedural language. I don't know if this is a serious problem or not, but it's not insurmountable even if it is. When I moved to OOP from non-OOP i was just excited about a new way to do things, I wasn't really concerned that i wasn't going to "do OOP right".

If you have any aspirations to do anything other than OS X/iOS programming ever in your life, i'd stick to C for now and learn it well. Knowing the ins and outs, and why certain things crash in certain ways, how to do it yourself even if you don't have to in higher level languages, etc. is quite valuable in my opinion. Even if you have no such aspirations, I don't think knowing some C before you delve into Objective-C will really prevent you from picking up the OOP concepts, even if you might be slightly tainted by your procedural-only leanings.

-Lee

 

[larswik]

Scott, you and I are in the same boat and I have asked this before.

I am reading 'Learning C for the Mac', also a good book. I am almost finished with my 370 page book and I wrote a real ugly code looking Console BlackJack game last week (but it works) and posted it here. Stay the course and finish your C book. You can breeze through the C book and skip over things you don't feel apply, and then struggle in the Objective C book later. Or you can really spend the time learning-C and breeze through Objective-C later.

Here was my thread about finishing up C and some good advice from the folks here. https://forums.macrumors.com/threads/1067946/

Don't rush yourself to the GUI wonderland. Stay the course.

-Lars

 

[balamw]

The main reason people encourage starting directly with an Object-Oriented language is so you learn to think in Objects immediately, and don't have "hang ups" from a purely procedural language. I don't know if this is a serious problem or not, but it's not insurmountable even if it is.

If I were starting from scratch I'd probably start with Kochan's Objective C 2.0 book for exactly this reason. Then I'd add a C book by the time he's done with Foundation and moving into Cocoa. I think he does a great job in the book of building from scratch.

Part of it is that the I/O stuff most books start with (i.e. Hello World) is quite different in Objective-C/C++ than it is in straight C. I think it's important to learn about s/f/printf, but it can wait until later when you might need it. Basic cout, cin type constructs or NSLog are (IMHO) easier to grasp for those who didn't grow up in the age of punchcards and teletypes and transition better to their GUI counterparts.

B