Register FAQ / Rules Forum Spy Search Today's Posts Mark Forums Read
Go Back   MacRumors Forums > Apple Systems and Services > Programming > Mac Programming

Reply
 
Thread Tools Search this Thread Display Modes
Old Feb 27, 2006, 12:05 PM   #1
zimv20
macrumors 601
 
zimv20's Avatar
 
Join Date: Jul 2002
Location: chicago
should new programmers learn procedural before object?

after a bit of time in this thread, where an assignment for a C++ class was being written procedurally, i started wondering how to best teach new programming students.

let's assume the ultimate goal is to make developers who are skilled in large-scale, object-oriented projects.

what do people think of the following?

1. procedural techniques make the transition to OO more difficult. for the above goal, starting with OO is preferred.

2. even OO projects require some degree of procedural knowledge, so:
a. start with procedural, then move to OO
b. start with OO, then introduce procedural once the OO skills are solid

3. procedural techniques are the basis of all coding and should be taught first:
a. with a procedural-only language, such as C
b. with a language capable of both styles, such as C++ or java

i think it's a crime to teach procedural programming and C++ simultaneously to new programmers. then again, i learned C well before C++ was even invented, so perhaps my own bias is tainting my opinion.

thoughts?
__________________
Oct 2011: check out my band's first album @ boxsetauthentic.com
zimv20 is offline   0 Reply With Quote
Old Feb 27, 2006, 12:17 PM   #2
bousozoku
Moderator emeritus
 
Join Date: Jun 2002
Location: Gone but not forgotten.
I'd rather someone go with OO programming as the first actual implementation. However, I'd want them to understand how to create objects on paper and further, how to turn them into either OO or procedural code. That would probably keep them from programming anything their first year but considering the compromises I've seen at that level, it would be time well spent.

At that point, the student could be taught both discplines concurrently. (You can't teach someone two different things simultaneously. You would have to switch. )
bousozoku is offline   0 Reply With Quote
Old Feb 27, 2006, 12:29 PM   #3
zimv20
Thread Starter
macrumors 601
 
zimv20's Avatar
 
Join Date: Jul 2002
Location: chicago
Quote:
Originally Posted by bousozoku
I'd want them to understand how to create objects on paper and further, how to turn them into either OO or procedural code.
are you saying you'd teach design first? i think that's a great idea.

Quote:
(You can't teach someone two different things simultaneously. You would have to switch. )
__________________
Oct 2011: check out my band's first album @ boxsetauthentic.com
zimv20 is offline   0 Reply With Quote
Old Feb 27, 2006, 01:12 PM   #4
bousozoku
Moderator emeritus
 
Join Date: Jun 2002
Location: Gone but not forgotten.
Quote:
Originally Posted by zimv20
are you saying you'd teach design first? i think that's a great idea.


I've dealt with far too many who've been rushed into coding, for one reason or another. If they were my students, they would be well-versed in design before they coded and ran anything.

The current system used at most schools is that you design a little, code a little, compile and fix until it runs, run it and fix it until it runs properly. This is fine for a 64 KB programme/module. It's not fine for a 80 MB application.

How many applications sold commercially use a scrolling text interface? The number is near zero. Yet, the first thing taught is how to create such a programme without a thought to design. If you turned in an essay in such condition, you'd not receive the grade you thought you'd deserved for the work you'd put into it.

Design is everything.

I'm not just saying that any TUI or GUI is acceptable. Macromedia does a terrible job of making their applications powerful, yet inaccessible. Adobe's applications work virtually the same, yet you don't struggle to find the controls and options. Borland programming tools are famous for ease of use, while Microsoft's distance you further from getting the job done. Is a checkbox simpler than remembering to add /VSSE2 or some such to a line of options? Of course, it is.

Simplicity of thought engenders efficiency. Design is everything.
bousozoku is offline   0 Reply With Quote
Old Feb 27, 2006, 01:29 PM   #5
zimv20
Thread Starter
macrumors 601
 
zimv20's Avatar
 
Join Date: Jul 2002
Location: chicago
Quote:
Originally Posted by bousozoku
Design is everything.
i agree.

i have a friend who's interested in programming and we talk a lot about it. one thing i told him recently is how, in well-designed, large-scale OO projects, the class files themselves aren't that meaty. aside from the typical constructor / accessor / modifier methods, the methods that do anything typically do a small bit, hiding the bulk of the work by using other objects.

i then stressed that the power of such a project is the relationships among the objects as found in the design, and that's where one must go to understand the project as a whole.

i've found that the number of developers who can abstract and design is rather small indeed.
__________________
Oct 2011: check out my band's first album @ boxsetauthentic.com
zimv20 is offline   0 Reply With Quote
Old Feb 27, 2006, 01:41 PM   #6
Soulstorm
macrumors 68000
 
Soulstorm's Avatar
 
Join Date: Feb 2005
Quote:
Originally Posted by bousozoku
I've dealt with far too many who've been rushed into coding, for one reason or another. If they were my students, they would be well-versed in design before they coded and ran anything.

The current system used at most schools is that you design a little, code a little, compile and fix until it runs, run it and fix it until it runs properly. This is fine for a 64 KB programme/module. It's not fine for a 80 MB application.

How many applications sold commercially use a scrolling text interface? The number is near zero. Yet, the first thing taught is how to create such a programme without a thought to design. If you turned in an essay in such condition, you'd not receive the grade you thought you'd deserved for the work you'd put into it.

Design is everything.

I'm not just saying that any TUI or GUI is acceptable. Macromedia does a terrible job of making their applications powerful, yet inaccessible. Adobe's applications work virtually the same, yet you don't struggle to find the controls and options. Borland programming tools are famous for ease of use, while Microsoft's distance you further from getting the job done. Is a checkbox simpler than remembering to add /VSSE2 or some such to a line of options? Of course, it is.

Simplicity of thought engenders efficiency. Design is everything.
I couldn't agree more to that.

And as for the first question, I should say that my first language was C++. I didn't learn C first and then moved to C++. Instead, I learnt C++ all the way from the ground up. Guess I didn't have a choice, since our university was teaching us C++ from the first semester.

Anyway, what I want to say is that even in C++ there is procedural programming, and I recommend anyone to start teaching that. If anyone wants to be sure his/her students learn things the best way possible, he/she just has to ensure that before starting explaining what is an object and how does it work, students must have fully grasped the knowledge of making a program in C++ without the use of objects.

In my opinion, objects in OOP can be intimidating to people who don't have the proper teachers, or books. My introduction to objects was made with a teacher who told us that a class is just what a species is in real-life nature.

For example, lets take as a class the Human class. I am Soulstorm, object of a Human class, and my variables are eyes, nose etc, and there are some functions that although they are the same for all the objects of the Human class, each person handles them differently according to the variables given.

I don't know about you, but I found that a very clever approach to introduce new programmers to OOP.

Also, if your ultimate goal is to make students to become OOP programmers, if you don't start with an OOP programming language first, it will be very difficult for the student to learn 2 languages with a slightly or entirely major syntax, and logic.

As far as OOP is concerned, i think that C doesn't introduce the student to the OOP features C++ or Obj-C has, so if the ultimate goal is proffessional OOP, the learning of C nearly as good as useless to me.

I know there are many people who don't have the same opinion though.
Soulstorm is offline   0 Reply With Quote
Old Feb 27, 2006, 01:51 PM   #7
iMeowbot
macrumors 601
 
iMeowbot's Avatar
 
Join Date: Aug 2003
The only reason people have problems switching from procedural to OO is that OO is almost invariably taught poorly. Students have their heads stuffed with terminology instead of some nice clear explanations of what the darned things do.

Adding to the frustration is the vapid promise that OO will magically make everything reusable, when OO really has little to do with that. Reusability comes from planning ahead, and objects don't help a whit unless the programmer has already learned how to do that.
iMeowbot is offline   0 Reply With Quote
Old Feb 27, 2006, 01:53 PM   #8
zimv20
Thread Starter
macrumors 601
 
zimv20's Avatar
 
Join Date: Jul 2002
Location: chicago
Quote:
Originally Posted by Soulstorm
My introduction to objects was made with a teacher who told us that a class is just what a species is in real-life nature.
that's a pretty popular method, i've used it many time.

but the guy who i learned a lot of this stuff from summed up the transition from C to C++ this way: "you get extensible data types, and your functions can live with your variables".

that actually helped me a lot.

Quote:
As far as OOP is concerned, i think that C doesn't introduce the student to the OOP features C++ or Obj-C has, so if the ultimate goal is proffessional OOP, the learning of C nearly as good as useless to me.
interesting, thanks for that. i would agree that teaching C++ too quickly after C will simply lead to confusion. i started learing C in 1985, but didn't get on a C++ project until 1992, so i had a ton of procedural programming in C by then.

if C++ is going to be the language for teaching both, then i agree that a differentiation must be made between object and procedural. and i agree that some of the lessons of procedural, such as top-down coding, do help in an OOP environment.
__________________
Oct 2011: check out my band's first album @ boxsetauthentic.com
zimv20 is offline   0 Reply With Quote
Old Feb 27, 2006, 02:12 PM   #9
zimv20
Thread Starter
macrumors 601
 
zimv20's Avatar
 
Join Date: Jul 2002
Location: chicago
Quote:
Originally Posted by iMeowbot
The only reason people have problems switching from procedural to OO is that OO is almost invariably taught poorly. [...] Reusability comes from planning ahead, and objects don't help a whit unless the programmer has already learned how to do that.
excellent points.

this goes back to that abstraction issue. afaic, some people have it and most don't. reusability cannot happen w/ bad abstraction. hell, most projects don't even survive to the point where anyone would want to reuse parts.

should we discuss the abysmal success rate of s/w projects?
__________________
Oct 2011: check out my band's first album @ boxsetauthentic.com
zimv20 is offline   0 Reply With Quote
Old Feb 27, 2006, 04:07 PM   #10
MarkCollette
macrumors 65816
 
MarkCollette's Avatar
 
Join Date: Mar 2003
Location: Calgary, Canada
I would teach procedural first, then OO. OOP is not some be all, end all. There are some (well, many, many) problems that are best solved with an OOP approach, and there are some that are best solved with a procedural approach.

Most business applications merely input, store, and output data. Nothing is really calculated, and nothing has to execute for any long duration of time. These can be modelled easily with an OO framework.

But, most scientific or engineering problems are highly procedural, or at least if you want to solve the problems with the fastest CPU execution, then a procedural approach is best. Heck, the thread you referenced, where someone had to calculate prime numbers, is a prime (couldn't resist) example of this.

So, I don't think that OO should come first, to try to reduce some learning curve from one approach to another.

As for the focus on design, all I can say is "thank god!" But, even there, you'll probably have to teach some rudimentary procedural and OO techniques first, so they have a working set of skills for which they can effectively design.
MarkCollette is offline   0 Reply With Quote
Old Feb 27, 2006, 04:12 PM   #11
zimv20
Thread Starter
macrumors 601
 
zimv20's Avatar
 
Join Date: Jul 2002
Location: chicago
Quote:
Originally Posted by MarkCollette
there are some that are best solved with a procedural approach.
i agree with you, and it was with this thought that i qualified the original question for OOP to be the end goal.

Quote:
a procedural approach is best. [...] to calculate prime numbers
not sure i agree here, especially going with the solution i'd suggested about saving off the primes already calc'ed, which calls for a bit of organization. i definitely see some OO design in there. and the procedure for testing a prime isn't really that complex, just a couple lines of codes.

however, if i were to go the recursion route, that might change my thinking.
__________________
Oct 2011: check out my band's first album @ boxsetauthentic.com
zimv20 is offline   0 Reply With Quote
Old Feb 27, 2006, 05:02 PM   #12
admanimal
macrumors 68040
 
Join Date: Apr 2005
Quote:
Originally Posted by zimv20
are you saying you'd teach design first? i think that's a great idea.


I don't think it's that simple. You can't really design something when you have no idea how it will be built. At the very least, designing a program requires you to know what classes, variables, methods, etc. are. And you have to have at least a rudimentary knowledge of how different design decisions affect the computational complexity. Even the fact that you can only do one thing at a time isn't obvious to someone with no programming experience.

For these reasons, I really think it is necessary to strike a balance between teaching design and actual programming. You can't really teach one without the other.

As for starting with OOP vs. procedural, I would definitely go with procedural. OOP is basically just procedural with additional design considerations which are difficult to grasp at first and can distract from the task of learning basic programming constructs. I don't think you can do OOP effectively without being comfortable with breaking a program into functions anyway. Once the students are ready for writing serious programs with serious designs, then OOP can come in. (Not that you can't write a serious program without OOP).

Last edited by admanimal; Feb 27, 2006 at 05:11 PM.
admanimal is offline   0 Reply With Quote
Old Feb 27, 2006, 05:06 PM   #13
weg
macrumors 6502a
 
weg's Avatar
 
Join Date: Mar 2004
Location: nj
Quote:
Originally Posted by zimv20
thoughts?
I transitioned from GW-BASIC (my first lines of code ;-)) to Pascal, from there to C, C++, Perl, Java, SML and finally OCaml. Currently I'm writing code mainly in C++ and OCaml. It might seem strange, but I think functional languages are ideal to start with, because they are closer to what people now from school (in mathematics, you have no concept of a "state"). It might even be a good idea to use Mathematica as a first language... just to teach the concepts.

It doesn't make any sense to talk about design before the student understood the basic concepts. Think about what crappy houses you'd design if you knew nothing about statics.
__________________
- weg
weg is offline   0 Reply With Quote
Old Feb 27, 2006, 05:27 PM   #14
MarkCollette
macrumors 65816
 
MarkCollette's Avatar
 
Join Date: Mar 2003
Location: Calgary, Canada
Quote:
Originally Posted by zimv20
i agree with you, and it was with this thought that i qualified the original question for OOP to be the end goal.
Sorry, I think I read up until your link to the other thread, then read that thread, and when I came back, just read everyone else's posts, and not the rest of yours. In short, my post was retardedly redundant

So, as for the question you were asking, I'd just use C++. But, I'd start with the procedural C subset of C++. So, that would mean using printf instead of cout, but would allow syntax like "Coordinate topLeft;" instead of having to do the old C "struct Coordinate topLeft;". Also, they could use both /* */ and // comments. And they'd get the stricter typing that C++ offers, including the bool datatype.

Later, it's just a small step to flip structs to classes, so the technical hurdle is as small as possible, so they can focus on the mental paradigm shift.


Quote:
Originally Posted by zimv20
not sure i agree here, especially going with the solution i'd suggested about saving off the primes already calc'ed, which calls for a bit of organization. i definitely see some OO design in there. and the procedure for testing a prime isn't really that complex, just a couple lines of codes.

however, if i were to go the recursion route, that might change my thinking.
Those prime number algorithms are more of teaching aids for programming in general, then actual algorithms one would use if the goal was to find primes. Once you start using any of the sieve algorithms, you start building up tables of information that you wouldn't want encumbered by objects. Well, you might want a vector, but you wouldn't want the elements of the vector to be objects.
MarkCollette is offline   0 Reply With Quote
Old Feb 27, 2006, 05:27 PM   #15
AlmostThere
macrumors 6502a
 
Join Date: Feb 2005
Location: The royal throne of kings, the sceptred isle, the other Eden, the fortress built
Quote:
Originally Posted by weg
It doesn't make any sense to talk about design before the student understood the basic concepts. Think about what crappy houses you'd design if you knew nothing about statics.
Tend to agree with this if learning is part of education (rather than as part of job training).

Build a good understanding of memory, pointers and function pointers. You can then wrap pretty much any programming philosophy around those building blocks.

As a follow up, you are nicely poised to demonstrate how different languages utilise and express those same features natively and how the same problem can be approached in many different ways.
__________________
Join the army of the dead: http://www.urbandead.com
AlmostThere is offline   0 Reply With Quote
Old Feb 27, 2006, 05:28 PM   #16
zimv20
Thread Starter
macrumors 601
 
zimv20's Avatar
 
Join Date: Jul 2002
Location: chicago
Quote:
Originally Posted by admanimal
I don't think it's that simple. You can't really design something when you have no idea how it will be built. At the very least, designing a program requires you to know what classes, variables, methods, etc. are.
we need to consider different levels of design. from what i've quoted, it seems to me that you're thinking about a level design that's removed from coding by only a step or two. at that level, yes, language considerations could come heavily into play.

but there are higher levels where the language doesn't matter as much, if at all. indeed, i've done design sessions of the domain with the end users, who often don't know anything about coding (actually, the ones who do make it more difficult, because they zero right in on the code, which is out of scope at this point).

these design sessions can be very fruitful if done correctly. they can produce an accurate representation of the business, which is what they're meant to do. at this level, the business doesn't change its procedures if the IT department decides to switch from C++ to java.

another level is architectural. though i view this as possibly the highest level of design, it does concern itself with implementation technologies and does depend on the language. for example, when considering interprocess communication, i'd use CORBA for a C++ project, but consider RMI for a java one. this would be part of the architectural spec.

however, if i've done the work of designing the services available, details such as methods available would not change based on the underlying language. ints are still ints and extendible data types are available in both C++ and java, among other languages.

this stuff is hard to learn, but of vital importance in large projects and to success. i do believe that teaching it early on, perhaps even before some hands-on programming, could be useful to a number of people.

in the end, some developers can design, and some can't. starting with design would help both groups, imo.

Quote:
Even the fact that you can only do one thing at a time isn't obvious to someone with no programming experience.
it's also not true, especially in large-scale projects where a number of services run simultaneously. for example, the database is its own process.

even within a single program, there's multi-threading. but that's not really a design consideration.

Quote:
OOP is basically just procedural with additional design considerations
i don't agree with that. imo, the thought processes behind procedural and OOP are markedly different, and that's why so many programmers have trouble making the transition, hence the thread topic.

the best programmers know both, know when to use each, and can combine them.
__________________
Oct 2011: check out my band's first album @ boxsetauthentic.com
zimv20 is offline   0 Reply With Quote
Old Feb 27, 2006, 05:34 PM   #17
zimv20
Thread Starter
macrumors 601
 
zimv20's Avatar
 
Join Date: Jul 2002
Location: chicago
Quote:
Originally Posted by MarkCollette
I'd just use C++. But, I'd start with the procedural C subset of C++. <chomp>
this seems a reasonable approach.

Quote:
Those prime number algorithms are more of teaching aids for programming in general
you bring up a good point. this is a good example of a problem which can be solved using each approach, and it could be taught that way. "remember when we did prime numbers using procedural techniques? now let's approach the problem with OO".
__________________
Oct 2011: check out my band's first album @ boxsetauthentic.com
zimv20 is offline   0 Reply With Quote
Old Feb 27, 2006, 05:37 PM   #18
MarkCollette
macrumors 65816
 
MarkCollette's Avatar
 
Join Date: Mar 2003
Location: Calgary, Canada
This reminded me of an old thread asking a similar question. Here was my post there.
MarkCollette is offline   0 Reply With Quote
Old Feb 27, 2006, 05:48 PM   #19
zimv20
Thread Starter
macrumors 601
 
zimv20's Avatar
 
Join Date: Jul 2002
Location: chicago
Quote:
Originally Posted by MarkCollette
This reminded me of an old thread asking a similar question. Here was my post there.
some good stuff, yeah. i haven't read the thread, so perhaps you mentioned them later, but i'd add:
- linked lists
- trees
- debugging

...as more prerequisites to starting to learn computer science and real programming.
__________________
Oct 2011: check out my band's first album @ boxsetauthentic.com
zimv20 is offline   0 Reply With Quote
Old Feb 27, 2006, 06:38 PM   #20
admanimal
macrumors 68040
 
Join Date: Apr 2005
Quote:
Originally Posted by zimv20
...snip...

i don't agree with that. imo, the thought processes behind procedural and OOP are markedly different, and that's why so many programmers have trouble making the transition, hence the thread topic.

the best programmers know both, know when to use each, and can combine them.
I agree that the thought process behind OOP is very different than procedural. But I think that most of that thought goes into the design as I mentioned. The differences in actual language syntax are pretty trivial and everything ultimately comes down to the same basic programming constructs (which is why I think they are so important to master before you worry too much about OOP ideas).

I should qualify my previous post by saying I was thinking mostly in the context of what a student would be doing in classes. As projects become more and more complex, the differences in design methodologies become much more apparent.
admanimal is offline   0 Reply With Quote
Old Feb 27, 2006, 06:39 PM   #21
gekko513
macrumors 601
 
gekko513's Avatar
 
Join Date: Oct 2003
Go straight to OO. And start out with a drawing Applet in Java. It's more fun.
gekko513 is offline   0 Reply With Quote
Old Feb 27, 2006, 06:43 PM   #22
admanimal
macrumors 68040
 
Join Date: Apr 2005
Quote:
Originally Posted by gekko513
Go straight to OO. And start out with a drawing Applet in Java. It's more fun.
Noooo! I was a teaching assistant in an intro to programming class that used Java. And some of the first programs the students had to write were Applets. This just confused everybody. Why make the students worry about things like event-driven programming when they can't even effectively use a for-loop yet? By the time I graduated, they had stopped using Applets completely in the intro class and just stuck to text I/O.

I should say that this was a liberal arts college, so some of these students really had no clue about programming or really computers in general. I think perhaps the standards can be different depending on how advanced the students in the intro class are likely to be. (For more advanced students, starting with something fun like a drawing Applet may in fact be better)
admanimal is offline   0 Reply With Quote
Old Feb 27, 2006, 06:58 PM   #23
whooleytoo
macrumors 603
 
whooleytoo's Avatar
 
Join Date: Aug 2002
Location: Cork, Ireland.
Send a message via AIM to whooleytoo
Just to add yet another 2 cents:

Since the topic related to new programmers, rather than software designer or engineer, the first thing I think a newcomer should have a firm grasp of computer architecture and programming concepts such as the various basic and advanced data types & collections, pointers, memory management (whether manual in C/C++ or 'automatic' as in Java).

Any fledgling developer is going to be starting at or near the bottom of any organisation anyway, so having to implement a more senior engineer's design a) is a good way to see actual designs first hand, and b) experience first hand the potential issues & pitfalls in software implementation.

Another thing I'd recommend, is NOT to stick to just one language / development environment. IMO, knowing a lot isn't nearly as valuable as being able to learn quickly. Being open to new development environments can expose you to new design methodologies as well.

In defiance of what my Software Engineering lecturer told me in university, I don't subscribe to his notion of Design -> Implement -> Game over. The reality is many software companies are small, under funded and over promising; staff are hired and lost; and thus specifications and schedules tend to be quite "flexible", in reality.

In this kind of industry, it's not uncommon (even with a good initial design) to have to go back to the design phase time and again.
__________________
Mac <- Macintosh <- McIntosh apples <- John McIntosh <- McIntosh surname <- "Mac an toshach" <- "Son of the Chief"
whooleytoo is offline   0 Reply With Quote
Old Feb 27, 2006, 06:58 PM   #24
zimv20
Thread Starter
macrumors 601
 
zimv20's Avatar
 
Join Date: Jul 2002
Location: chicago
Quote:
Originally Posted by admanimal
everything ultimately comes down to the same basic programming constructs (which is why I think they are so important to master before you worry too much about OOP ideas).
i think we're more or less agreeing, then. imo, a lot of the OO power comes from the interaction of the objects, and i suppose that means that proper OO code tends to reflect the design, which means it's coded that way. hadn't thought of it in those terms before.

Quote:
I should qualify my previous post by saying I was thinking mostly in the context of what a student would be doing in classes. As projects become more and more complex, the differences in design methodologies become much more apparent.
gotcha.
__________________
Oct 2011: check out my band's first album @ boxsetauthentic.com
zimv20 is offline   0 Reply With Quote
Old Feb 27, 2006, 07:36 PM   #25
gekko513
macrumors 601
 
gekko513's Avatar
 
Join Date: Oct 2003
Quote:
Originally Posted by admanimal
Noooo! I was a teaching assistant in an intro to programming class that used Java. And some of the first programs the students had to write were Applets. This just confused everybody.
I suspect that is mostly because the exercises weren't adjusted to fit newbie students.

I'm not talking about making event driven AWT or SWING Applets as first exersises, but drawing things is a lot more fun than text.

The text based I/O programming courses didn't feel like real programming to me at the time (high school). The first Java course with Applets at uni, on the other hand, was great fun.

Last edited by gekko513; Feb 28, 2006 at 03:43 AM.
gekko513 is offline   0 Reply With Quote

Reply
MacRumors Forums > Apple Systems and Services > Programming > Mac Programming

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
thread Thread Starter Forum Replies Last Post
Best book to learn Cocoa and Objective C? valiar Mac Programming 44 Nov 11, 2011 01:30 PM
Do I have to learn other programming languages before Objective C? v2club iPhone/iPad Programming 8 Apr 25, 2011 07:16 PM
Shall I learn C before learning Objective-C KeeeeenW iPhone/iPad Programming 17 Nov 15, 2010 12:49 PM
Book for learning XCode and Objective C glhiii iPhone/iPad Programming 2 Feb 5, 2010 01:50 PM
should i drain the battery before installing the new firmware update? senorian iPhone 19 Sep 12, 2008 12:45 PM


All times are GMT -5. The time now is 01:01 AM.

Mac Rumors | Mac | iPhone | iPhone Game Reviews | iPhone Apps

Mobile Version | Fixed | Fluid | Fluid HD
Copyright 2002-2013, MacRumors.com, LLC