Yes.
For detailed guidance, buy Aaron Hillegass's book Cocoa Programming
for Mac OS X, and go through it from beginning to end, doing every
exercise and every challenge. I have done that with the first two
editions and am about to do it with the third, and I promise you it's
a good way t
That's the best roadmap I've ever seen.
On May 14, 2008, at 6:19 PM, Erik Buck wrote:
The obstacles, misconceptions, and prerequisite concepts that need
to be mastered when learning Cocoa vary dramatically based on the
past experience of the learner. I am a very experienced Cocoa
progr
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Michael Ash
Sent: Saturday, May 17, 2008 1:56 AM
To: Cocoa Developers
Subject: Re: Guidance for Cocoa's steep learning curve
On Fri, May 16, 2008 at 10:57 PM, john darnell
<[EMAIL PROTECTED]> w
I agree with this, and I think a lot of people end up getting stuck at
this intermediate stage. Apple has a great "dictionary" and they have
decent "My name is Bob" material. They have little quality material in
the middle. This is where the books fill in. Personally speaking I
spent a lot of time
On Sat, May 17, 2008 at 5:53 PM, Torsten Curdt <[EMAIL PROTECTED]> wrote:
>> Imagine picking up a dictionary for a foreign language you don't
>> speak
>
> That is a very good analogy. For my situation I would take it even a step
> further
>
>
> Let's say I am fluent in Italian and Spanish alre
Imagine picking up a dictionary for a foreign language you don't
speak
That is a very good analogy. For my situation I would take it even a
step further
Let's say I am fluent in Italian and Spanish already. I've even had
one year of French in school.
I am bored to death going throug
On Fri, May 16, 2008 at 10:57 PM, john darnell
<[EMAIL PROTECTED]> wrote:
> And, what I hear from this august crowd is a consensus that the
> references are difficult to understand, but necessarily so--that they
> ought to be that way.
That's not really it. It's not that they should be difficult t
On Fri, May 16, 2008 at 11:22 AM, Scott Ribe <[EMAIL PROTECTED]> wrote:
>> Forward references are what the concepts docs are for, but for some
>> reason, they don't seem to be serving that purpose for some people.
>> I'm not sure why.
>
> I get the feeling that some people never notice the "Compani
> Forward references are what the concepts docs are for, but for some
> reason, they don't seem to be serving that purpose for some people.
> I'm not sure why.
I get the feeling that some people never notice the "Companion Guides"
section at the top of the class references. They're right there at
On May 16, 2008, at 10:50 AM, Jens Alfke wrote:
but there are still a lot of concepts and details to learn, and many
times their topology does not reduce to a directed acyclic graph
(i.e. you can't present them in order without forward references.)
Jens, I was going to bring up the concept o
On 16 May '08, at 7:57 AM, john darnell wrote:
And, what I hear from this august crowd is a consensus that the
references are difficult to understand, but necessarily so--that they
ought to be that way.
I see your point, but I think you're phrasing it in a way that sounds
overly contentious
Tutorial examples don't really belong in API docs. Their ultimate
goal is to state the purpose and usage as directly as possible so the
developer can get what they need and move on. Continuously sifting
through tutorial information and examples would be quite tedious and
redundant for the
> And, what I hear from this august crowd is a consensus that the
> references are difficult to understand, but necessarily so--that they
> ought to be that way. This is a debate that has been going on since I
> bought my first CP/M computer back in the early eighties. I doubt we
> will resolve i
orn.
Thanks for the lively discussion.
John
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Michael Ash
Sent: Friday, May 16, 2008 9:32 AM
To: Cocoa Developers
Subject: Re: Guidance for Cocoa's steep learning curve
On Fri, May 16, 2008 at 10:19 PM, john
On 16 May '08, at 7:19 AM, john darnell wrote:
Sigh. Your attitude reminds me of a conversation I once had with a
fellow programmer. When I was encouraging her to add more
documentation
to the code, she replied, jokingly, "If it was hard for me to write,
then it should be hard for them to
On Fri, May 16, 2008 at 10:19 PM, john darnell
<[EMAIL PROTECTED]> wrote:
>
> Sigh. Your attitude reminds me of a conversation I once had with a
> fellow programmer. When I was encouraging her to add more documentation
> to the code, she replied, jokingly, "If it was hard for me to write,
> then
On May 16, 2008, at 9:30 AM, john darnell wrote:
I don't mean to be mean, but I agree with Joseph; most Apple
documentation is really, really poor.
*No, that's not correct.* The documentation is extensive, and
comprehensive, but unless you already know what you are reading about,
it might as w
> Sigh. Your attitude reminds me of a conversation I once had with a
> fellow programmer. When I was encouraging her to add more documentation
> to the code, she replied, jokingly, "If it was hard for me to write,
> then it should be hard for them to read."
>
> The sad thing is that you are not j
Sigh. Your attitude reminds me of a conversation I once had with a
fellow programmer. When I was encouraging her to add more documentation
to the code, she replied, jokingly, "If it was hard for me to write,
then it should be hard for them to read."
The sad thing is that you are not joking...
> I have found this to be true on most every product's documentation; not
> just X Code. It is easily understood after five years of experience.
> The beginner struggles with the concepts, the locutions, the native
> phrases that the experienced programmer understands.
I feel the need to chime
On Fri, May 16, 2008 at 9:30 PM, john darnell
<[EMAIL PROTECTED]> wrote:
> I don't mean to be mean, but I agree with Joseph; most Apple
> documentation is really, really poor.
>
> *No, that's not correct.* The documentation is extensive, and
> comprehensive, but unless you already know what you ar
malc crawford
Subject: Re: Guidance for Cocoa's steep learning curve
On 15 May '08, at 6:33 PM, Joseph Ayers wrote:
> What is absolutely
> baffling is dealing with NSTableView. The documentation absolutely
> sucks. How does one map table rows and columns
> on NSMutableArr
The NSTableView is based on the MVC paradigm which has existed for
quite some time. A method you implement gets called to return the
value for each cell (more or less). So if you have a table with forty
cells, then at least 40 times the method will get called. After I
started looking at it
On May 15, 2008, at 6:33 PM, Joseph Ayers wrote:
Imagine growing up on Excel and then dealing with NSTableView.
How did this Cocoa NSTableView architecture evolve. Where is the
history?
When I first started with Cocoa I spent (and I still spend) a lot of
time in code for NSTableView (and
Regarding the question on how NSTableView works -- there are examples
of Table Views in the Aaron Hillegass book "Cocoa programming for Mac
OS X". Also, there are literally hundreds of questions and answers on
Table Views in the archives of this mailing list. When I get stuck on
how to do s
On May 15, 2008, at 6:33 PM, Joseph Ayers wrote:
The documentation absolutely sucks. How does one map table rows and
columns on NSMutableArrays and NSMutableDictionaries. How does one
map the Rows and Columns of a "dataSource" on a NSTable view?
And here's another increasingly prevalent pr
On 15 May '08, at 6:33 PM, Joseph Ayers wrote:
What is absolutely
baffling is dealing with NSTableView. The documentation absolutely
sucks. How does one map table rows and columns
on NSMutableArrays and NSMutableDictionaries. How does one map the
Rows and Columns of a "dataSource"
on a NST
I think what is missing here is some history. I'm working on an APP to
make a series of arbitrary measurements
(i.e. positions, distances angles, shapes) on each of the frames of a
movie. On some movies I might want to make
three position measurements, on others I want to make 4 angle
measuremen
On 15 May '08, at 5:03 PM, mmalc crawford wrote:
My guidance for Cocoa's alleged "steep learning curve" is, "Why are
you making it steep?"
It reminds me of the clichéd joke: "Doctor, it hurts when I do
this." "Well, don't do that."
I agree. There are so many questions on this list from pe
On May 15, 2008, at 3:39 PM, Bruno Sanz Marino wrote:
The really first step with a language is allways to write code and
forget the "GUI" and the "buttons and windows" .Then when you
know what are you doing and you can do what you want to do (like a
painter), you can think in the "GUIS
I come from Java, and before, for web and for Windows and i am learning
Cocoa for "Iphone" purposes mainly
For me the biggest issue is to learn the libraries and frameworks (all
these tons of objects)
Cocoa is long away from the "pure c" Win32 library (of microsoft
windows)...But the true is
> then there's not that much new in Objective-C/Cocoa IMHO.
Exactly. Deferred-release makes reference counting easier. Looser more
dynamic typing makes certain things more convenient & more concise.
Delegation keeps the single-inheritance hierarchy shallow and
comprehensible. The handful of powerf
On May 14, 2008, at 8:33 PM, Scott Ribe wrote:
=== If you are primarily an experienced C++ programmer (In my
experience you will have the hardest time)
(2) I will have to personally disagree with this.
I wonder, seriously, if it doesn't depend somewhat on whether or not
you're
a really
On 15 May '08, at 8:21 AM, colo wrote:
I get messages and oop [Sender Dosomething] or in Ruby
@sender.dosomething. OOP was easy for me as thats how I already
thought code would be like. Of course I am still learning but I fail
to see why Cocoa syntax could be any different than Ruby.
Um, beca
> Let me take this opportunity to once again shamelessly plug my C tutorial:
>
>http://masters-of-the-void.com
>
> which covers most of this (it doesn't cover pointers to functions and
> bitwise operations), especially memory management and pointers.
Shameless plug but oh so nice of a Tu
Am 15.05.2008 um 03:19 schrieb Erik Buck:
2) Learn C and at least learn to recognize low level operations like
bit manipulation, pointers, intrinsic types, pointers to pointers,
pointers to functions, etc. Without this, you will be lost and
dangerous when writing Cocoa programs in Objective
Lets add to this fun madness. Nice simple clean tutorials like this
http://cocoadevcentral.com/d/learn_objectivec/
Could cocoa parts in the frame work be summed up like that as well?
How many "examples" or paragraphs and or pages of text does it take to
finally drill down the Cocoa method into you
> if you've spent a lot of time abusing void * to
> hack runtime dynamism into C++
Or if you've done it the right way, with templates--was more what I was
thinking...
1-5 are all very good points. Much of what's been said here belongs in an
intro document somewhere...
--
Scott Ribe
[EMAIL PROTE
On 14 May '08, at 10:16 PM, David Wilson wrote:
3) Instance methods (with the -) are virtual functions. Class
methods (with the +) are static functions.
Class methods aren't exactly like static functions, because they're
still dynamically dispatched and can be overridden by subclasses.
A
On Wed, May 14, 2008 at 11:33 PM, Scott Ribe <[EMAIL PROTECTED]> wrote:
>>> === If you are primarily an experienced C++ programmer (In my
>>> experience you will have the hardest time)
>>
>>
>> (2) I will have to personally disagree with this.
>
> I wonder, seriously, if it doesn't depend somewhat
>> === If you are primarily an experienced C++ programmer (In my
>> experience you will have the hardest time)
>
>
> (2) I will have to personally disagree with this.
I wonder, seriously, if it doesn't depend somewhat on whether or not you're
a really good C++ programmer...
--
Scott Ribe
[EMAI
On May 14, 2008, at 8:19 PM, Erik Buck wrote:
I would just like to add the following:
(1) It also depends upon prior framework experience as to how easy or
difficult it will be to dive into Cocoa. I learned event-driven
programming very early and had the advantage of either using or
a
The obstacles, misconceptions, and prerequisite concepts that need to
be mastered when learning Cocoa vary dramatically based on the past
experience of the learner. I am a very experienced Cocoa programmer.
I am also an author of the thickest Cocoa Programming book and have
another Cocoa
43 matches
Mail list logo
