Cocoa et al as HCI usability problem
-
The very good , interesting and informative debate in this list
concerning the accessibility of the programming environment to new
users has it seems to me incresingly polarised between those who
think the documentation more or less adequate and those like me who
for whatever reason, have great difficulties making use of the
facilities.
I think this debate relates to the same concerns and battles we had,
and in many cases are still having about computer usability, namely
the effective design of human-computer interfaces, aka HCI.
It is ironic that we are having this debate within an Apple
programmer's mailing list. Apple has been celebrated for the
usability of its machines and long may it continue to be so. However,
Apple has been less celebrated for the humanity of its programming
interface having, in my experience of Macs from the Lisa onwards,
seemingly taken the attitude that its programmers were hobbyists,
geeks essentially, who because of their enthusiasm would successfully
negociate their way into the machine's innards. That said, the 9
tomes of "Inside the Macintosh" documentation of the programmer's
workshop were pretty good once you got into them but there was a lot
less to get into then than there is today.
This question of volume of documentation and system size and
complexity is significant to our debate. It is pertinent to quote
what one of the great programming pioneers, Dijkstra said about PL/1:
That it
" must be like flying a plane with 7,000 buttons, switches, and
handles to manipulate in the cockpit. I absolutely fail to see how we
can keep our growing programs firmly within our intellectual grip
when by its sheer baroqueness the programming language - our basic
tool, mind you! - already escapes our intellectual control". ("Humble
Programmer", see Prgramming Methodology 1978).
Well I think that the sheer size and complexity of Cocoa et al comes
close to being an aeroplane cockpit and one which we are largely
expected to learn to use from engineering manuals essentially
concerned with listing the identity, composition and location of
components,(not to mention the various incarnations of Xcode and
Interface Builder). I am not saying that tremendous pains have not
been taken to create a robust coherent system nor to document it.
There have. Also there are many who have succeeded in mastering the
system. Some will have done so through having grown up with it from
early days, others will have had the fortune to attend (expensive)
traning courses, and others still will have done so through dint of
talent, perspicacity and hours of hard work. So mastery is possible.
But I am not stupid nor a shirker nor a complete novice and I expect
that the same can be said for most people who have had and are
continuing to have horrendous dificulties in getting to use the
system. It is clear that the programing interface to the Mac has
serious usability issues.
I cannot help touting one recent example. To specify the outlets etc
between a class definition and Interface Builder on Leopard we are
told to type the name of the class into a field and that thereafter
IB will make the appropriate links with Xcode. It took me ten minutes
of doing it this way and that before I realised that IB would only
make the connections AFTER one had typed in the class name AND saved
IB! We know from HCI research that it is little things like this
which most frequently cause users to give up and never touch the
equipment again.
Now, of course, as programmers we are well used to wasting hours
hacking through the underbrush to discover that to switch on the
machine we need to hold down Alt-Escape with the right hand whilst
depressing a button round the back of the machine with the left.
(That was how in the 70s one turned on some of the PCs at Leicester
Poly!). But what a waste of time and effort and how demoralising and
off-putting to anyone but the most obstinate programmer. I deferred
having a go at Cocoa for about three or four years because I knew it
would be a struggle and these last five months or is it six have been
horrorshow.
Let me state two principal facts.
1. Designing good user interfaces is hard.
2. Designing good user interfaces is expensive.
It is hard because every human being is an individual,
because there is seemingly a lot to learn
and because there are limits to the complexity we can handle.
It is expensive because the design of good HCI is primarily an
empirical activity centered on user testing.
The question is then whether we and possibly apple should do anything
about it.
Julius
http://juliuspaintings.co.uk -
Julius,
You could change Apple for just about any other vendor, and Cocoa for
just about another GUI/system interface, and your argument will still hold.
(Have you ever tried programming X11 with just XLib C calls? Nasty stuff
that....)
Also, please don't confuse the language, Objective-C in this case, with
the frameworks/system interface. Objective-C is a very small language,
and it is easy to keep the main things in mind. PL/1 is another matter
altogether.... (So is C++ if you think about it.)
Cocoa is much larger, but the same could be said of C and XLib
respectively. Not to mention that on X you have many different GUI
toolkits to choose from to abstract away the complexity of XLib: Xt, Qt,
Tk, XAW, Motif, GNUStep, Gnome, KDE, etc., etc.
Modern computer systems are complex. There are many, many options of the
programmer. If modern computer systems lacked this complexity, and if
the published interfaces did not have APIs available so that programmers
could make adequate use of this complexity, then we'd be stuck where we
were in the early '80s, having to roll our own library for everything.
I don't think you can expect to lose the learning curve in any
programming interface. APIs expose complexity, and at the same time,
cover it up. Imagine if you had to implement your own
Model-View-Controller paradigm for your GUI widgets before you could
start making your own applications? That is the situation that you'd be
in with something like XLib, or even the old Macintosh Toolbox. Today,
that complexity is abstracted away rather neatly by the Cocoa framework,
just as it would be on X if you used Motif or Qt or some other toolkit.
If you do want to just jump in and start writing code, then perhaps you
should look into Python or some other "scripting" language. They do an
even better job of hiding the complexity.
I also don't find any great difficulty in using Apple's documentation.
The conceptual documents cover the concepts, and the reference
documentation serves as a reference. No, I don't think you should learn
to use Cocoa just from the conceptual documents, but I'm sure it is
possible.
The simple fact of the matter is that documentation, just like a GUI,
cannot be all things to all people. Programmers and those interested in
programming are a particularly eclectic bunch. We each come at Cocoa for
the first time with different experience, different reference points,
and different expectations. One set of documentation cannot be expected
to handle all of the possible permutations of programmer knowledge and
experience. For this reason, other books exist written by third parties
to cover those gaps or target different audiences.
In summary, I think it is a problem of all programming documentation and
programming interface regardless of the platform or language, and I
don't really see a way for a single vendor to resolve the issue, not do
I think they really should.
Well, I'll shut up, now.
Cheers,
Jason -
There are conventions and metaphors of human computer interfaces.
Apple used to provide interactive training programs to explain the use
of a mouse to customers in stores. My own father who is a brilliant
scientist could not initially master double-click and fifteen years
later frequently double clicks when a single click is adequate. To
follow up on the theme of the first post, the Attitude Direction
Indicator (ADI) is a critical cockpit instrument that is absolutely
obvious and second nature to a pilot, but most people off the street
would need an explanation to understand its use.
The point is that we are not born knowing how to interact with
computers. We are trained, and sometimes the training is so thorough
and internalized that later we can't imagine any other way to
interact. It is also clear that there have been both evolutionary
and revolutionary changes to HCI. The acceptance of changes depends
on how easy it is for humans to fit the changes into existing
metaphors and/or adopt new metaphors and/o perceive the improvement if
any that change may provide. I remember the time when existing
command line users and even DOS junkies could not understand why
anyone would want to use a mouse. They could not perceive any
advantage to a mouse, and their internalized metaphors for interfacing
with computers did not include graphical user interfaces. Many others
could not understand why anyone would use a command line interface.
Now relate this to Cocoa. Smalltalk stepped into a vacuum in the
early 1970s and invented a whole new set of metaphors for
programming. Smalltalk's metaphors started with object oriented
programming but included Model-View-Controller and many of the object
oriented patterns such as decorators, composition, and hierarchies,
that we still use and document today. Objective-C mixes Smalltalk
with C, and Cocoa/NeXTstep started by incorporating many of the
venerable Smalltalk metaphors and patterns. Cocoa did not stand
still. There have been refinements and adaptations to accommodate and
exploit the C side of Objective-C too.
If you, the programmer, are unfamiliar with the metaphors used by
Cocoa, you are a bit like the DOS junkie who can't understand the
point of a GUI. In some respects, the more invested and internalized
you are with other metaphors, the harder it is for you to accept
Cocoa. Take heart. There aren't many DOS junkies left. For an
interesting but probably irrelevant parallel, it took from about 1984
when the Mac was released to about 1993 when the general public
started using GUIs. There is a correlation to the fact that it took
from about 1997 when Apple started selling Cocoa technology to 2006 or
so when Apple's developers embraced it. The GUI pre-existed the Mac
by 8 years or so. NeXTstep pre-existed Cocoa by about 8 years or so.
Cocoa is the most consistent, elegant, and productive software
development technology I have ever used, and I have used a lot. Cocoa
uses key metaphors and design patterns ubiquitously. If the
programmer is either unaware of the metaphors or does not see their
utility, it will be difficult to use Cocoa. If a programmer fails to
grasp a particular pattern, the whole framework may be
incomprehensible because the pattern is most likely used throughout.
The attributes of Cocoa that make it so consistent and elegant are
exactly the same attributes that I think newbies are complaining
about. The newbie complains that the reference documentation mentions
delegates or tags or data sources or the responder chain or key value
coding or bindings or targets or actions etc. without defining them.
This is exactly like a newbie complaining that clicking and dragging
and selecting and double clicking are used throughout a GUI but not
explained in the documentation for every application. Once the GUI
metaphors are internalized, it is unnecessary at best and annoying at
worst to keep encountering mouse based selection explained in every
user's guide. The consistent application of the metaphors makes the
GUI easy to use. The consistent use of metaphors makes Cocoa easy to
program. BUT YOU MUST UNDERSTAND THE METAPHORS FIRST in both cases. -
Just to add some insight, when reading the Cocoa documentation, it's
very helpful when a developer also has some degree of exposure to
Interface Builder. Take heart, though, as Interface Builder is just a
click away.
Once you have an idea how things somewhat work within Interface Builder
and have seen it simulate the interface within Interface Builder or run
it in a sample application, lots of things in the documentation begin to
make sense, especially the date picker.
[As a caveat, the date picker class is a very easy one for me to
understand at face value, as I wrote a UI widget and class very much
like it using THINK Class Library almost 15 years ago that was used in
an industry leader's software product, and I'm a frequent development
user of date/time technologies with respect to internationalization.]
As Aaron Hillegass says in the starting pages of his Cocoa intro book,
and I'm paraphrasing, programming is hard, and if you don't get it
immediately, it doesn't mean you're not smart; it just means you need
some more time working through the examples.
By the way, you really should build and try out the examples installed
under the /Developer path. Build them, add breakpoints in strategic
places, make changes, incorporate their code in your own, rewrite it as
needed to suit your own needs, and you'll be happier. -
On Sun, May 18, 2008 at 10:39 AM, Erik Buck <erik.buck...> wrote:
> Cocoa is the most consistent, elegant, and productive software development
> technology I have ever used, and I have used a lot. Cocoa uses key
> metaphors and design patterns ubiquitously. If the programmer is either
> unaware of the metaphors or does not see their utility, it will be
> difficult to use Cocoa. If a programmer fails to grasp a particular
> pattern, the whole framework may be incomprehensible because the pattern is
> most likely used throughout.
I have to second this. Cocoa certainly has its quirks, but it seems to
have far fewer of them than any other toolkit (especially any other
GUI toolkit) that I've ever worked with.
I daresay that 90% of the problems that I've seen with Cocoa usage
(either my own or that of others) is born out of the programmer
fighting the system. It's very easy to get an idea in your head about
how something "must" work, and because we're dealing with
Turing-complete languages here we can generally make something work
even if it requires taking a sledgehammer to the problem. And, of
course, when we're done forcing the round peg into the square hole,
we're frustrated that the toolkit didn't make it easy for us.
With Cocoa, there seems to a be a very simple guiding principle: If
you're frustrated because the system isn't letting you do what you
want, rethink what you want to do and how you want to do it. A lot of
thought and design has gone into Cocoa; it's worth respecting all of
that design and asking yourself, when you're fighting the frameworks,
if it's really the frameworks that are doing the wrong thing in that
instance- because, at least in my experience, chances are it's the
programmer.
--
- David T. Wilson
<david.t.wilson...> -
On 18 May '08, at 4:33 AM, Julius Guzy wrote:
> Apple has been less celebrated for the humanity of its programming
> interface having, in my experience of Macs from the Lisa onwards,
> seemingly taken the attitude that its programmers were hobbyists,
> geeks essentially, who because of their enthusiasm would
> successfully negociate their way into the machine's innards.
"Hobbyists"? I think "professionals" is more accurate — especially
since in the early days of the Mac you had to spend hundreds of
dollars to become a developer and get access to tools and documentation.
I can see your point about obsessive hackers having the stamina to
overcome complicated APIs, but any platform vendor's main objective in
developer tools is to target professional developers who will create
the products that make the platform attractive to customers.
"Professional" doesn't necessarily imply a big company; I refer
equally to startups and indie outfits, anyone seriously devoted to
creating a product.
In Apple's defense, the task of implementing a sophisticated GUI on
such limited computers was extremely difficult. The top goals were
usability, decent performance, and affordable price. That left no
leeway for making the APIs themselves easy to use — the niceties we
take for granted like object-oriented programming would have used up
way too much of that 128k of RAM and 64k of ROM.
(Yes, some of the first GUIs were written in the first OOP language,
Smalltalk. But the Xerox computers that ran Smalltalk-80 cost $10,000
or more; the ones that ran it with any kind of decent performance (the
"Dorado") cost $50,000 and were basically supercomputers. They all had
ten times as much RAM as the first Mac, and had custom CPUs with
programmable microcode optimized for Smalltalk. Even so, performance
was much worse than the original Mac, and the GUI was much cruder and
harder to use. I'd already been using Smalltalk-80 when the first Mac
came out, and the Mac's speed and aesthetics were just jaw-dropping.)
Anyway.
I have to say I find this whole discussion frustrating. The attitude
of some people seems to be that writing computer programs, of
arbitrary complexity, should be as easy as using a word processor.
That's a Utopian goal at best, and more generally just naïve. Of
course we should be trying to make the APIs and tools and
documentation more useable; that's a constant task, and a very
difficult one, and one Apple's doing a good job at. (The complexity
under the hood is terrifying, and it's already been covered up enough
that in an hour an experienced developer can throw together an app
that fifteen years ago would have sold for $100.)
Face it, any sort of serious creative endeavor is hard! There's no way
around it. And the hardest part is learning the techniques and tools.
If you wanted to build a robot, play Vivaldi on the violin, design a
house, paint landscapes, or cure Ebola, you'd have to accept that it
would take months or years of serious study, that the tools and
documentation would sometimes be hard to use, and you'd have to put up
with frustration before you mastered the skills.
Why on earth is writing the best GUI applications in the world
supposed to be trivial by comparison? Maybe I'm taking this too
personally, but I sense a subtext that some people think the task of
software design itself is somewhat trivial, more like programming a
VCR than like architecture or painting or chemistry.
"Problems worthy of attack
Prove their worth by hitting back." [Piet Hein]
—Jens -
Well what can you do. Not sure why but lately many newcomers have
been showing up and complaining about Cocoa's difficulty. I'm not
sure if they've done GUI work before, but I remember my days with
PowerPlant and spending a massive amount of time just creating the GUI
and the code to back it. Perhaps this is what gave me the sense of
how much time Cocoa saves. It's easy to take things like webviews for
granted. I can guess the amount of code Apple wrote to back those to
work out of the box is pretty massive and complicated.
If programming was just drag and drop and clicking some option boxes
users could just write their own programs. But the fact is
programming is far more complicated than that (and probably will be
for a long time) and making such a framework would take a decade or
more, by which time it would be obsolete and outdated.
For professionals the GUI is a smaller part of development thanks to
time saved by Cocoa. If I have to write my own controls from scratch,
I will as it's what programmers do, write code. But I'm thankful 99%
of the time I can use something from Cocoa that comes with much of the
code already done for me.
I guess some people are upset Cocoa doesn't do enough, or all, of the
work for them. I'm more of the people happy Cocoa does any work for
me at all. If it saves me time, it's a good thing.
On May 18, 2008, at 10:41 AM, Jens Alfke wrote:
> "Hobbyists"? I think "professionals" is more accurate — especially
> since in the early days of the Mac you had to spend hundreds of
> dollars to become a developer and get access to tools and
> documentation.
>
> I can see your point about obsessive hackers having the stamina to
> overcome complicated APIs, but any platform vendor's main objective
> in developer tools is to target professional developers who will
> create the products that make the platform attractive to customers.
> "Professional" doesn't necessarily imply a big company; I refer
> equally to startups and indie outfits, anyone seriously devoted to
> creating a product.
>
> In Apple's defense, the task of implementing a sophisticated GUI on
> such limited computers was extremely difficult. The top goals were
> usability, decent performance, and affordable price. That left no
> leeway for making the APIs themselves easy to use — the niceties we
> take for granted like object-oriented programming would have used up
> way too much of that 128k of RAM and 64k of ROM.
>
> (Yes, some of the first GUIs were written in the first OOP language,
> Smalltalk. But the Xerox computers that ran Smalltalk-80 cost
> $10,000 or more; the ones that ran it with any kind of decent
> performance (the "Dorado") cost $50,000 and were basically
> supercomputers. They all had ten times as much RAM as the first Mac,
> and had custom CPUs with programmable microcode optimized for
> Smalltalk. Even so, performance was much worse than the original
> Mac, and the GUI was much cruder and harder to use. I'd already been
> using Smalltalk-80 when the first Mac came out, and the Mac's speed
> and aesthetics were just jaw-dropping.)
>
> Anyway.
>
> I have to say I find this whole discussion frustrating. The attitude
> of some people seems to be that writing computer programs, of
> arbitrary complexity, should be as easy as using a word processor.
> That's a Utopian goal at best, and more generally just naïve. Of
> course we should be trying to make the APIs and tools and
> documentation more useable; that's a constant task, and a very
> difficult one, and one Apple's doing a good job at. (The complexity
> under the hood is terrifying, and it's already been covered up
> enough that in an hour an experienced developer can throw together
> an app that fifteen years ago would have sold for $100.)
>
> Face it, any sort of serious creative endeavor is hard! There's no
> way around it. And the hardest part is learning the techniques and
> tools. If you wanted to build a robot, play Vivaldi on the violin,
> design a house, paint landscapes, or cure Ebola, you'd have to
> accept that it would take months or years of serious study, that the
> tools and documentation would sometimes be hard to use, and you'd
> have to put up with frustration before you mastered the skills.
>
> Why on earth is writing the best GUI applications in the world
> supposed to be trivial by comparison? Maybe I'm taking this too
> personally, but I sense a subtext that some people think the task of
> software design itself is somewhat trivial, more like programming a
> VCR than like architecture or painting or chemistry.
-
On May 18, 2008, at 12:41 PM, Jens Alfke wrote:
> Maybe I'm taking this too personally, but I sense a subtext that
> some people think the task of software design itself is somewhat
> trivial, more like programming a VCR than like architecture or
> painting or chemistry
... well it *should* be. It probably *will* be some day (in the
distant future). but not today. Like any other technical profession,
it takes intensive research and studying (as you more or less said). I
share your frustration with some of the sentiment shown here.
An employer of mine was shocked - SHOCKED - to learn that the Great
and Powerful Cocoa did not automagically make a (statically-drawn)
graph in a custom view (which is all he originally asked for) fully-
interactive as in Excel with no extra development effort. He was even
more shocked (yes, SHOCKED) to learn that such an interactive view
would take a single developer months (probably a year or more) to
approach the lofty level of sophistication he described. He expected
it in a few weeks.
His words: "I thought Cocoa was the most advanced platform out
there." It sounded accusatory. I laughed and explained that the best
damned bricks and two-by-fours in the world won't suddenly self-
assemble and become a mansion. Drawing a pie chart is a far cry from
Excel graphs on steroids. That's a bit harder. Besides, I heard
steroids shrink your bullet points.
In short, I believe Cocoa is a victim of its own superiority.
People seem to expect:
"Computer, reconfigure the main deflector to transmit the entire
contents of Wikipedia in the form of tachyon bursts using a
triaxilating frequency on a covariant subspace band."
< The computer chirps happily, and those backward, planet-bound
savages now know all about our great nations: http://en.wikipedia.org/wiki/Principality_of_Sealand
>
--
I.S. -
begin rant:
Oh me oh my the poor newcomers to Cocoa. Sorry folks back in the days
of 360 mainframes there were manuals and they were inscrutable.
But if you took the Winston Churchill aproach and spent some blood,
sweat, toil and tears you would probably become a 1/2 decent
assembler language programmer.
Same with Obj- C - if you know C you can grok Obj-C in at most a week
- less if you are experienced. You won't be a master of it for a year
or so of serious programming.
But that's true of acquiring literacy in any field.
Finally in this spoon fed age of sound bytes and simplistic and
thoughtless political and economic panacea's in a world far more
complex that when I grew up (70 years ago)
you newbies to Cocoa need to do what the docs provide you with.
RTFM! and sweat it out. Or else take the blue pill! Sheesh they all
want pay for no work!
rant ends:
On 18-May-08, at 1:56 PM, Michael Vannorsdel wrote:
> Well what can you do. Not sure why but lately many newcomers have
> been showing up and complaining about Cocoa's difficulty. I'm not
> sure if they've done GUI work before, but I remember my days with
> PowerPlant and spending a massive amount of time just creating the
> GUI and the code to back it. Perhaps this is what gave me the
> sense of how much time Cocoa saves. It's easy to take things like
> webviews for granted. I can guess the amount of code Apple wrote
> to back those to work out of the box is pretty massive and
> complicated.
>
> If programming was just drag and drop and clicking some option
> boxes users could just write their own programs. But the fact is
> programming is far more complicated than that (and probably will be
> for a long time) and making such a framework would take a decade or
> more, by which time it would be obsolete and outdated.
>
> For professionals the GUI is a smaller part of development thanks
> to time saved by Cocoa. If I have to write my own controls from
> scratch, I will as it's what programmers do, write code. But I'm
> thankful 99% of the time I can use something from Cocoa that comes
> with much of the code already done for me.
>
> I guess some people are upset Cocoa doesn't do enough, or all, of
> the work for them. I'm more of the people happy Cocoa does any
> work for me at all. If it saves me time, it's a good thing.
>
>
> On May 18, 2008, at 10:41 AM, Jens Alfke wrote:
>
>> "Hobbyists"? I think "professionals" is more accurate — especially
>> since in the early days of the Mac you had to spend hundreds of
>> dollars to become a developer and get access to tools and
>> documentation.
>>
>> I can see your point about obsessive hackers having the stamina to
>> overcome complicated APIs, but any platform vendor's main
>> objective in developer tools is to target professional developers
>> who will create the products that make the platform attractive to
>> customers. "Professional" doesn't necessarily imply a big company;
>> I refer equally to startups and indie outfits, anyone seriously
>> devoted to creating a product.
>>
>> In Apple's defense, the task of implementing a sophisticated GUI
>> on such limited computers was extremely difficult. The top goals
>> were usability, decent performance, and affordable price. That
>> left no leeway for making the APIs themselves easy to use — the
>> niceties we take for granted like object-oriented programming
>> would have used up way too much of that 128k of RAM and 64k of ROM.
>>
>> (Yes, some of the first GUIs were written in the first OOP
>> language, Smalltalk. But the Xerox computers that ran Smalltalk-80
>> cost $10,000 or more; the ones that ran it with any kind of decent
>> performance (the "Dorado") cost $50,000 and were basically
>> supercomputers. They all had ten times as much RAM as the first
>> Mac, and had custom CPUs with programmable microcode optimized for
>> Smalltalk. Even so, performance was much worse than the original
>> Mac, and the GUI was much cruder and harder to use. I'd already
>> been using Smalltalk-80 when the first Mac came out, and the Mac's
>> speed and aesthetics were just jaw-dropping.)
>>
>> Anyway.
>>
>> I have to say I find this whole discussion frustrating. The
>> attitude of some people seems to be that writing computer
>> programs, of arbitrary complexity, should be as easy as using a
>> word processor. That's a Utopian goal at best, and more generally
>> just naïve. Of course we should be trying to make the APIs and
>> tools and documentation more useable; that's a constant task, and
>> a very difficult one, and one Apple's doing a good job at. (The
>> complexity under the hood is terrifying, and it's already been
>> covered up enough that in an hour an experienced developer can
>> throw together an app that fifteen years ago would have sold for
>> $100.)
>>
>> Face it, any sort of serious creative endeavor is hard! There's no
>> way around it. And the hardest part is learning the techniques and
>> tools. If you wanted to build a robot, play Vivaldi on the violin,
>> design a house, paint landscapes, or cure Ebola, you'd have to
>> accept that it would take months or years of serious study, that
>> the tools and documentation would sometimes be hard to use, and
>> you'd have to put up with frustration before you mastered the skills.
>>
>> Why on earth is writing the best GUI applications in the world
>> supposed to be trivial by comparison? Maybe I'm taking this too
>> personally, but I sense a subtext that some people think the task
>> of software design itself is somewhat trivial, more like
>> programming a VCR than like architecture or painting or chemistry.
-
For the record, my comments weren't about it being difficult; it's
about the documentation not providing the information needed to use it.
It's a beautiful API, as you say with tons of work done to implement
these reusable constructs. The documentation is voluminous, but in too
many cases just repeats the name of the method or rephrases the method
name. The examples stop just when they were getting to a line that
would illustrate how to use the construct. And most of the items don't
have an example.
Tutorials to me are pretty much useless, as I am not looking for a
"step by step" cookbook to just getting something working, but rather
a discussion of the why. How many times have we seen a tutorial say
something like "control-drag from the textfield to the File's Owner
object?" (just a random example). OK, I can do that, but it is a waste
of my time - it's like paint-by-number when trying to learn art. Take
the "Currency Converter With Bindings" much-touted tutorial; it
actually uses a method that is deprecated.
It's my eagerness to explore and understand all of this rich
collection of functions that frustrates me when the documentation
doesn't go into enough depth.
If I thought the API itself had problems, I would just give up. I have
heard people, very successful Java programmers, say they "didn't care"
for Obj-C/Cocoa. Not me - I want to learn all I can. I have no Java
books and six Cocoa books. I think this API is the coolest thing ever.
Thus the frustration with the documentation.
But I am still very very hesitant to put another NSPopUpButton on my
interface, because of the complete absence of guidance on how to
implement the thing, and the many days it took to get a single one
working, and even now I have no idea why it works - one of the random
combinations of checkboxes and popup choices did the trick.
I can do target/action and outlets - I want to learn bindings. If it's
a single-term binding, I can do it now.
I'm just going to finish Aaron's third edition, which arrived two days
ago, and see if anything has changed in things like model key paths,
isa-swizzling and so forth.
> Well what can you do. Not sure why but lately many newcomers have
> been showing up and complaining about Cocoa's difficulty.
-
Johnny Lundy wrote:
> Tutorials to me are pretty much useless, as I am not looking for a "step
> by step" cookbook to just getting something working, but rather a
> discussion of the why. How many times have we seen a tutorial say
> something like "control-drag from the textfield to the File's Owner
> object?" (just a random example). OK, I can do that, but it is a waste
> of my time - it's like paint-by-number when trying to learn art. Take
> the "Currency Converter With Bindings" much-touted tutorial; it actually
> uses a method that is deprecated.
>
> It's my eagerness to explore and understand all of this rich collection
> of functions that frustrates me when the documentation doesn't go into
> enough depth.
Have you read the Cocoa Fundamentals Guide?
http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals
/Introduction/chapter_1_section_1.html
Much of what you seek is explained therein. If the Guide makes no sense
to you, I'd suggest picking up some basic books on OO programming and
design patterns. Read them, then come back to the Cocoa Fundamentals Guide.
Cheers,
Jason -
As a (relatively) newcomer to Cocoa and generally far less experienced than
most of the people that have responded so far, here are my 2 cents.
Cocoa and Objective-C are no more difficult or obscure than any other
popular OO framework out there. I made the transition from .NET as easily as
I had done (to .NET) before from Java. The only stumbling block I
encountered is that Xcode and Interface Builder don't work like Eclipse or
Visual Studio. The separation between the Model, View and Controller is far
more distinct than in any other tool I've used, so my mental model was
problematic at first.
There only minor stumbling blocks for a Cocoa newbie and these are
differences of culture...mostly. Cocoa offers a much better development
experience and provides avenues for better design practices as long as you
don't try to write code as if you're writing it for Windows.
Apple's documentation is often verbose and pedantic but there are excellent
free alternatives online and very good books. Cocoa methods and classes are
clearly and fully named, by convention and you don't really have to rely too
much upon the documentation later. The learning curve is steep, especially
for those used to Java or .NET or any other development platform, but the
benefits are much greater.
The only thing I miss from the Windows world is the plethora of free custom
controls...
On Sun, May 18, 2008 at 2:33 PM, Julius Guzy <julius...>
wrote:
> The very good , interesting and informative debate in this list concerning
> the accessibility of the programming environment to new users has it seems
> to me incresingly polarised between those who think the documentation more
> or less adequate and those like me who for whatever reason, have great
> difficulties making use of the facilities.
>
> I think this debate relates to the same concerns and battles we had, and in
> many cases are still having about computer usability, namely the effective
> design of human-computer interfaces, aka HCI.
>
> It is ironic that we are having this debate within an Apple programmer's
> mailing list. Apple has been celebrated for the usability of its machines
> and long may it continue to be so. However, Apple has been less celebrated
> for the humanity of its programming interface having, in my experience of
> Macs from the Lisa onwards, seemingly taken the attitude that its
> programmers were hobbyists, geeks essentially, who because of their
> enthusiasm would successfully negociate their way into the machine's
> innards. That said, the 9 tomes of "Inside the Macintosh" documentation of
> the programmer's workshop were pretty good once you got into them but there
> was a lot less to get into then than there is today.
>
> This question of volume of documentation and system size and complexity is
> significant to our debate. It is pertinent to quote what one of the great
> programming pioneers, Dijkstra said about PL/1: That it
> " must be like flying a plane with 7,000 buttons, switches, and
> handles to manipulate in the cockpit. I absolutely fail to see how we can
> keep our growing programs firmly within our intellectual grip when by its
> sheer baroqueness the programming language - our basic tool, mind you! -
> already escapes our intellectual control". ("Humble Programmer", see
> Prgramming Methodology 1978).
>
> Well I think that the sheer size and complexity of Cocoa et al comes close
> to being an aeroplane cockpit and one which we are largely expected to learn
> to use from engineering manuals essentially concerned with listing the
> identity, composition and location of components,(not to mention the various
> incarnations of Xcode and Interface Builder). I am not saying that
> tremendous pains have not been taken to create a robust coherent system nor
> to document it. There have. Also there are many who have succeeded in
> mastering the system. Some will have done so through having grown up with it
> from early days, others will have had the fortune to attend (expensive)
> traning courses, and others still will have done so through dint of talent,
> perspicacity and hours of hard work. So mastery is possible. But I am not
> stupid nor a shirker nor a complete novice and I expect that the same can be
> said for most people who have had and are continuing to have horrendous
> dificulties in getting to use the system. It is clear that the programing
> interface to the Mac has serious usability issues.
>
> I cannot help touting one recent example. To specify the outlets etc
> between a class definition and Interface Builder on Leopard we are told to
> type the name of the class into a field and that thereafter IB will make the
> appropriate links with Xcode. It took me ten minutes of doing it this way
> and that before I realised that IB would only make the connections AFTER one
> had typed in the class name AND saved IB! We know from HCI research that it
> is little things like this which most frequently cause users to give up and
> never touch the equipment again.
>
> Now, of course, as programmers we are well used to wasting hours hacking
> through the underbrush to discover that to switch on the machine we need to
> hold down Alt-Escape with the right hand whilst depressing a button round
> the back of the machine with the left. (That was how in the 70s one turned
> on some of the PCs at Leicester Poly!). But what a waste of time and effort
> and how demoralising and off-putting to anyone but the most obstinate
> programmer. I deferred having a go at Cocoa for about three or four years
> because I knew it would be a struggle and these last five months or is it
> six have been horrorshow.
>
> Let me state two principal facts.
> 1. Designing good user interfaces is hard.
> 2. Designing good user interfaces is expensive.
>
> It is hard because every human being is an individual,
> because there is seemingly a lot to learn
> and because there are limits to the complexity we can handle.
>
> It is expensive because the design of good HCI is primarily an empirical
> activity centered on user testing.
>
> The question is then whether we and possibly apple should do anything about
> it.
>
> Julius
>
>
>
> http://juliuspaintings.co.uk
>
-
I'm also wondering if many of the people finding Cocoa difficult are
also lacking OO programming experience. The docs teach Cocoa really
well but if you're unfamiliar with OO design and concepts the Cocoa
docs are going to be very daunting.
On May 18, 2008, at 3:28 PM, Jason Stephenson wrote:
> Have you read the Cocoa Fundamentals Guide?
>
> http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals
/Introduction/chapter_1_section_1.html
>
> Much of what you seek is explained therein. If the Guide makes no
> sense to you, I'd suggest picking up some basic books on OO
> programming and design patterns. Read them, then come back to the
> Cocoa Fundamentals Guide.
-
On May 18, 2008, at 22:38, P Teeson wrote:
> begin rant:
>
> Oh me oh my the poor newcomers to Cocoa. Sorry folks back in the
> days of 360 mainframes there were manuals and they were inscrutable.
> But if you took the Winston Churchill aproach and spent some blood,
> sweat, toil and tears you would probably become a 1/2 decent
> assembler language programmer.
I see - ignorance is bliss :-p
I have been writing a LOT of assembler code the early days and have a
strong C and OOP background - it should be a piece of cake, right?
Well, and you know what - the basics are! When you just need reference
documentation - well, then you are OK as well. But there is A LOT to
cover in the middle where your "RTFM" just sound like mockery.
I think what we are seeing now is (or will is) that (probably also
because of the iPhone) Cocoa programming is becoming more popular.
Just looking around me... the number of people (I know) that know how
to write a Cocoa program is -let's not make a comparison- ...but it's
tiny! This is changing and ...like or not - more newbies will hit this
list. Period! People coming from the Java and the .Net world. A world
that has a LOT more coverage on the net.
When you come from that world. You find yourself asking questions like:
"Someone must have done this before! Nothing on the blogosphere? No
articles?"
"The mail sending API is deprecated in Leopard - without an
alternative? WTF!"
"People say XCode is great - they can't have worked with Eclipse/
Idea. Where are my refactoring tools??"
Of course I have also been asking question that ARE explained in
Apple's docs. Guilty as charged! But - well, I just did not find them!
Now I think everyone on this list is probably picky about good UI -
for a good reason. Using your app should preferably be possible
without reading a big manual. Actually that is also one of the best
goals when designing a framework or API. (Not saying Cocoa does not
fit this shoe!) ...but this also applies to documentation. Just saying
- I searched for things and didn't find them. Knowing that I am not
entirely stupid this could mean there is room for improvement.
Reacting like "I don't get you newbies - I can work with it just fine"
is like saying "What's do you mean by you 'would like to use the
mouse'? I am happy with the terminal". (That said I am a command line
guy :-o )
If so many voices say "it's hard" ...there might be at least some
truth in it. And this is not the normal "I learn a new language/
framework" thing. Good programming is hard - I think we all know that.
But that is really not the point here (I think).
Frankly speaking I hope this discussion will resolve itself after a
while. I personally have the feeling that cocoa resources on the net
are increasing. Also I have high hopes for learning a couple of things
during WWDC :) (see you there!)
That said: Sweat of not - I still like getting into it :) Maybe you
guys just have to cut us newbies some slack. Maybe we are just
spoiled ;)
cheers
--
Torsten -
On 18 May 2008, at 14:36, Jason Stephenson wrote:
>Yes,
> (Have you ever tried programming X11 with just XLib C calls? Nasty
> stuff that....)
superDooperExtraSpecialHighIntensityOpenWindowAndDoLotsOfWonderfulThings
IfYouSetTheParametersRightWidget.
> Also, please don't confuse the language, Objective-C in this case,I don't think I mentioned Objective C in that missive.
> with the frameworks/system interface. Objective-C is a very small
> language, and it is easy to keep the main things in mind. PL/1 is
> another matter altogether.... (So is C++ if you think about it.)
> Cocoa is much larger, but the same could be said of C and XLibIt has been true for quire a long time now that learning a computer
> respectively. Not to mention that on X you have many different GUI
> toolkits to choose from to abstract away the complexity of XLib:
> Xt, Qt, Tk, XAW, Motif, GNUStep, Gnome, KDE, etc., etc.
>
> Modern computer systems are complex. There are many, many options
> of the programmer. If modern computer systems lacked this
> complexity, and if the published interfaces did not have APIs
> available so that programmers could make adequate use of this
> complexity, then we'd be stuck where we were in the early '80s,
> having to roll our own library for everything.
>
> I don't think you can expect to lose the learning curve in any
> programming interface. APIs expose complexity, and at the same
> time, cover it up. Imagine if you had to implement your own Model-
> View-Controller paradigm for your GUI widgets before you could
> start making your own applications? That is the situation that
> you'd be in with something like XLib, or even the old Macintosh
> Toolbox. Today, that complexity is abstracted away rather neatly by
> the Cocoa framework, just as it would be on X if you used Motif or
> Qt or some other toolkit.
language is child's play compared with learning the api and how to
use it. And modern systems are more complex and at the same time
conceptually a lot simpler than earlier systems would be if they had
tried to do the same job.
>
> If you do want to just jump in and start writing code, then perhaps
> you should look into Python or some other "scripting" language.
> They do an even better job of hiding the complexity.
As yet I have not worked with Python but I am familiar with PHP and
especially Perl
I am also familiar with c, java, prolog, pascal, .......
From that point of view my favourite programm of all time was
Hypercard untill Apple started making it fancy and finally destroyed
it by selling it to people who had no idea of the amazing things one
could so quickly prototype in it.
>well this is precisely the point I made, that the debate has been
> I also don't find any great difficulty in using Apple's
> documentation. The conceptual documents cover the concepts, and the
> reference documentation serves as a reference. No, I don't think
> you should learn to use Cocoa just from the conceptual documents,
> but I'm sure it is possible.
polarising between those who find the documentation adequate if not
best ever and people like myself who despite their best efforts have
so far found it an uphill struggle.
>Precisely. In my view the documentation is by and large a very good
> The simple fact of the matter is that documentation, just like a
> GUI, cannot be all things to all people. Programmers and those
> interested in programming are a particularly eclectic bunch. We
> each come at Cocoa for the first time with different experience,
> different reference points, and different expectations. One set of
> documentation cannot be expected to handle all of the possible
> permutations of programmer knowledge and experience. For this
> reason, other books exist written by third parties to cover those
> gaps or target different audiences.
list of what is to be found and its components and how it relates to
other components and subsystems. And I think that an awful lot of
care has gone into its production. With regard to the books, we're
touching on a sore point. I have the Quartz book which is pretty
good, the Hillglass which i hate but can't do without, the Kochan
which I like a lot because clear and suscinct, the Anguish et al.
often rewards the occasional dip, an O'Malley that I think I opened
once, ditto Trent and McCormack, the Feiller OS X developer's guide
was a nice read, and then there are the (for me) just awful vermont
recipies. Of course the best book of the lot here is still the
Kerningham and Ritchie and a book which has nothing to do with cocoa
or c but raises the spirits when necessary: Seggern's Practical
Handbook of Curve Design and Generation.
Tthe fact is that there will be others like me who do not find it
easy to get into cocoa. At this stage I'll not be jumping ship but
believe me I've had sleeples nights about it. Mainly i'll not do it
because although I'm far from attack speed I can just about open a
few windows and pump bit map images to the screen, have menus and
buttons and get mouse and tablet input and hopefully will soon be
able to write to and from disk, and if i'm really lucky i might even
be able to archive system state! in short, I am just about able to do
the things I need to and I am actually progressing the technology
that this current program of mine is supposed to deliver. In short
the investment is beginning to pay off. But getting this far has been
the most difficult piece of learning I've ever done in my life.
>
> In summary, I think it is a problem of all programming
> documentation and programming interface regardless of the platform
> or language, and I don't really see a way for a single vendor to
> resolve the issue, not do I think they really should.
Well, there is a problems with the documentation and if it does not
get resolved then people will end up unable to write the code. I mean
what is the point in loosing people who actually want to program this
machine and are willing to put oodles of effort into doing it?
Julius
http://juliuspaintings.co.uk -
On Sun, May 18, 2008 at 8:41 PM, Julius Guzy
<julius...> wrote:
> Well, there is a problems with the documentation and if it does not get
> resolved then people will end up unable to write the code. I mean what is
> the point in loosing people who actually want to program this machine and
> are willing to put oodles of effort into doing it?
There's been a lot of discussion on the list lately about how Cocoa
has been so hard for people to learn, but not a lot of useful
specifics or follow-up. People haven said "the API is bad because it
refers to all these terms you're already supposed to know and I don't
know them!", and then when someone says "Did you read the conceptual
documentation?" the response is a resounding... silence. I think this
is part of why those veteran Cocoa developers are often less than
sympathetic.
You say it's the most difficult piece of learning you've done in your
life, but I wonder how you went about it. It may be that the problem
is not so much in the documentation itself, as in the
"meta-documentation" - that is, guiding newbies to the appropriate
documentation in the appropriate order. Unfortunately, that can of
course be frustrated by the types who jump right in and start reading
APIs with abandon and then complain that they don't understand certain
terminology or concepts. (Not that I'm accusing you in particular of
doing this, your comment just happened to spark this response).
So, it'd be interesting to hear from people what they actually *tried*
with respect to learning from the documentation and why it failed.
Clearly the documentation worked for a large percentage of the veteran
developers on the list - personally, I own one Cocoa book, and I think
I made it through about a quarter of it before giving it up as useless
because the API was well written and conceptual documentation covered
the questions that arose. I wonder if this has more to do with a
difference in approach to the documentation than anything else.
--
- David T. Wilson
<david.t.wilson...> -
On 18 May 2008, at 17:41, Jens Alfke wrote:
>well there you are. Precisely.
> On 18 May '08, at 4:33 AM, Julius Guzy wrote:
>
>> Apple has been less celebrated for the humanity of its programming
>> interface having, in my experience of Macs from the Lisa onwards,
>> seemingly taken the attitude that its programmers were hobbyists,
>> geeks essentially, who because of their enthusiasm would
>> successfully negociate their way into the machine's innards.
>
> "Hobbyists"? I think "professionals" is more accurate — especially
> since in the early days of the Mac you had to spend hundreds of
> dollars to become a developer and get access to tools and
> documentation.
>Like me for instance.
> I can see your point about obsessive hackers having the stamina to
> overcome complicated APIs, but any platform vendor's main objective
> in developer tools is to target professional developers who will
> create the products that make the platform attractive to customers.
> "Professional" doesn't necessarily imply a big company; I refer
> equally to startups and indie outfits, anyone seriously devoted to
> creating a product.
>To my knowledge during these discussions nobody has suggested this
> I have to say I find this whole discussion frustrating. The
> attitude of some people seems to be that writing computer programs,
> of arbitrary complexity, should be as easy as using a word
> processor. That's a Utopian goal at best, and more generally just
> naïve.
least of all I. There is nothing about programming computers that
does not require a fair bit of knowledge of how to get around the
machine. I do not think it naive of me to raise serious questions
regarding usability given that i have made huge and increasingly
successful efforts to get into this system so I can do some heavy
duty programming. From that point of view the debate has been quite
informative regarding the documentation and how to use it, even
though I still find it exceptonally hard.
> Of course we should be trying to make the APIs and tools andWell if it were doing as good a job as you think it is then I for one
> documentation more useable; that's a constant task, and a very
> difficult one, and one Apple's doing a good job at. (The complexity
> under the hood is terrifying, and it's already been covered up
> enough that in an hour an experienced developer can throw together
> an app that fifteen years ago would have sold for $100.)
would not have lived through the nightmare of the last five or six
months struggle.
>done it
> Face it, any sort of serious creative endeavor is hard! There's no
> way around it. And the hardest part is learning the techniques and
> tools. If you wanted to build a robot,
> play Vivaldi on the violincan't
> , design a house,done it
> paint landscapes,sometimes
> or cure Ebola,next week
> you'd have to accept that it would take months or years of seriousabsolutely!!! years and years
> study,
> that the tools and documentation would sometimes be hard to use,been there, done it , still have not mastered the skills bit.
> and you'd have to put up with frustration before you mastered the
> skills.
>What have I said that should make anyone suppose I think designing
> Why on earth is writing the best GUI applications in the world
> supposed to be trivial by comparison? Maybe I'm taking this too
> personally, but I sense a subtext that some people think the task
> of software design itself is somewhat trivial, more like
> programming a VCR than like architecture or painting or chemistry.
>
> "Problems worthy of attack
> Prove their worth by hitting back." [Piet Hein]
software is trivial?
Julius
http://juliuspaintings.co.uk -
On 18 May '08, at 6:15 PM, Julius Guzy wrote:
> I do not think it naive of me to raise serious questions regarding…
> usability given that i have made huge and increasingly successful
> efforts to get into this system so I can do some heavy duty
> programming.
> Well if it were doing as good a job as you think it is then I for
> one would not have lived through the nightmare of the last five or
> six months struggle.
If you want to talk about this in terms of HCI usability, then you
need to play by those rules and _not_ describe the problem
anecdotally, just in terms of your own experience. Typically when this
happens, it's a programmer designing a user interface according to his
own preferences, which are often very different from those of a
mainstream computer user.
In this case it sounds like the opposite — you seem to be finding
Cocoa a lot more difficult to learn than most do. It definitely
shouldn't take months of struggle. (CoreAudio or Security, maybe. Not
AppKit.)
I don't know why that would be, and I don't mean it as a value
judgment. Different people have different learning styles. Maybe the
docs aren't matching yours. As others have pointed out, it would be
good to have more details on what you think the docs are missing.
One thing that does seem to apply to a number of other people asking
questions on this forum is a seeming lack of ability to experiment and
figure out answers oneself. Writing code is engineering, but debugging
it and figuring out how an API works is more like a science — and
understanding how to experiment, and draw conclusions from evidence,
are vital skills.
—Jens -
On 19 May 2008, at 1:56, David Wilson wrote:
> On Sun, May 18, 2008 at 8:41 PM, Julius GuzyThe silence on my part is that I understood that bit of the
> <julius...> wrote:
>
>> Well, there is a problems with the documentation and if it does
>> not get
>> resolved then people will end up unable to write the code. I mean
>> what is
>> the point in loosing people who actually want to program this
>> machine and
>> are willing to put oodles of effort into doing it?
>>
>
> There's been a lot of discussion on the list lately about how Cocoa
> has been so hard for people to learn, but not a lot of useful
> specifics or follow-up. People haven said "the API is bad because it
> refers to all these terms you're already supposed to know and I don't
> know them!", and then when someone says "Did you read the conceptual
> documentation?" the response is a resounding... silence. I think this
> is part of why those veteran Cocoa developers are often less than
> sympathetic.
>
documentation.
In fact the conceptual stuff is largely a doddle. I've been familiar
with it for some time now and it doesn't give me trouble.
So I wouldn't have much to say about it except that it does have a
tendency to make things seem more exciting than they actually are.
For instance I can refer here to the idea of dynamic typing which
still requires us to have the header files present in the calling
file which isn't exactly in the enthusiastic spirit of how it's
talked about.
Indeed many of my problems with dynamic typing came about because I
took the enthusism at face value.
>Well I do do a lot of jumping right in. Always done it.
> You say it's the most difficult piece of learning you've done in your
> life, but I wonder how you went about it. It may be that the problem
> is not so much in the documentation itself, as in the
> "meta-documentation" - that is, guiding newbies to the appropriate
> documentation in the appropriate order. Unfortunately, that can of
> course be frustrated by the types who jump right in and start reading
> APIs with abandon and then complain that they don't understand certain
> terminology or concepts. (Not that I'm accusing you in particular of
> doing this, your comment just happened to spark this response).
>
Normally I find it the quickest way of becoming familiar with the
language of the particular tribe i getting to know.
After that of course I set myself a small problem, e.g. open a
window, write hello world, open another window, draw something etc.
That for me is a natural way of proceeding. The real difficulties
have come about because of the need for precise answers to relatively
simple questions. What was one of these that took up a fair bit of my
time once....
>... exactly. That's a problem. You identify it correctly.
> So, it'd be interesting to hear from people what they actually *tried*
> with respect to learning from the documentation and why it failed.
>
It is difficult without keeping a diary or something like it to
remember the questions.
I tried to do this several times because I thought I might put up
some web pages about it and the discipline would serve to knock the
stuff into my head. However giving a good explanation is a lot harder
than one might at first suppose and besides, the exigencies of time
got the better of my good intentions.
>Well this is exactly how things seem to pan out. Those who have been
> Clearly the documentation worked for a large percentage of the veteran
> developers on the list - personally, I own one Cocoa book, and I think
> I made it through about a quarter of it before giving it up as useless
> because the API was well written and conceptual documentation covered
> the questions that arose. I wonder if this has more to do with a
> difference in approach to the documentation than anything else.
>
doing this for some time like the documentation they have. No doubt
once I become a bit more adept I will too. But right now......
All the best
Julius
http://juliuspaintings.co.uk -
On May 18, 2008, at 5:03 PM, Johnny Lundy wrote:
> Take the "Currency Converter With Bindings" much-touted tutorial; it
> actually uses a method that is deprecated.
this actually is a prime example of why tutorials are few and far
between in the Apple doc. They require significant upkeep.
This is on the list to be updated but has (unfortunately) been pushed
out more than once. -
where you feel this to be the case, PLEASE file bugs
(bugreporter.apple.com) or feedback.
it is all taken seriously.
On May 18, 2008, at 5:39 PM, Î?ικόλας ΤουμπÎλης wrote:
> Apple's documentation is often verbose and pedantic but there are
> excellent
> free alternatives online and very good books. Cocoa
-
On 19 May 2008, at 2:34, Jens Alfke wrote:
>Well, in the present case I only have my own experience to go on. I
> On 18 May '08, at 6:15 PM, Julius Guzy wrote:
>
>> I do not think it naive of me to raise serious questions regarding
>> usability given that i have made huge and increasingly successful
>> efforts to get into this system so I can do some heavy duty
>> programming.
> …
>> Well if it were doing as good a job as you think it is then I for
>> one would not have lived through the nightmare of the last five or
>> six months struggle.
>
> If you want to talk about this in terms of HCI usability, then you
> need to play by those rules and _not_ describe the problem
> anecdotally, just in terms of your own experience.
dived into this debate because someone else was expressing
difficulties and he or she was being told in essence that they should
not have been finding it hard at all because in reality everything in
the garden was rosy. So I just thought to respond with expressions of
solidarity.
> Typically when this happens, it's a programmer designing a userSorry, no comprendo.
> interface according to his own preferences, which are often very
> different from those of a mainstream computer user.
In my original missive I was equating the problems of HCI design with
the problems of designing manuals for engineers.
>Well I don't know how much more difficult I find learning it than
> In this case it sounds like the opposite — you seem to be finding
> Cocoa a lot more difficult to learn than most do. It definitely
> shouldn't take months of struggle. (CoreAudio or Security, maybe.
> Not AppKit.)
others have.
It would be interesting to find out.
I have perhaps expressed my true feelings more than others because
I'm not going to loose out on any jobs by admitting to a few
difficulties. On the other hand maybe everyone here has had very few
difficulties in learning this quite enormous body of knowledge. I did
ask in an earlier missive how others came to learn the system and
there seems to have been the usual mix of starting early or going on
training courses or having talent and working hard.
>Yes but I like others have programs to write and very little time to
> I don't know why that would be, and I don't mean it as a value
> judgment. Different people have different learning styles. Maybe
> the docs aren't matching yours. As others have pointed out, it
> would be good to have more details on what you think the docs are
> missing.
do it in. So yes, I think that would be a very good idea. I don't
know who else would be interested in contributing an hour or so a
week to the general good but if there were a consensus then I think I
might.
>Yes. That's what programmers do.
> One thing that does seem to apply to a number of other people
> asking questions on this forum is a seeming lack of ability to
> experiment and figure out answers oneself. Writing code is
> engineering, but debugging it and figuring out how an API works is
> more like a science — and understanding how to experiment, and draw
> conclusions from evidence, are vital skills.
>
Julius
http://juliuspaintings.co.uk -
On May 18, 2008, at 7:39 PM, Julius Guzy wrote:
> So I wouldn't have much to say about it except that it does have a
> tendency to make things seem more exciting than they actually are.
> For instance I can refer here to the idea of dynamic typing which
> still requires us to have the header files present in the calling
> file which isn't exactly in the enthusiastic spirit of how it's
> talked about.
> Indeed many of my problems with dynamic typing came about because I
> took the enthusism at face value.
The header issue was just the compiler getting confused. It would
happen with most frameworks and C based languages. ObjC objects can
do all kinds of magical things like class posing, dynamic methods,
ect. But the compiler needs basic information so it knows how to pass
args and whatnot. Cocoa or ObjC can't fix this. You can message an
object without having any info about the method, but you have to be
sure the compiler will put the args where the method will expect
them. And to do that it needs to know the arg types.
> Well I do do a lot of jumping right in. Always done it.
> Normally I find it the quickest way of becoming familiar with the
> language of the particular tribe i getting to know.
> After that of course I set myself a small problem, e.g. open a
> window, write hello world, open another window, draw something etc.
> That for me is a natural way of proceeding. The real difficulties
> have come about because of the need for precise answers to
> relatively simple questions. What was one of these that took up a
> fair bit of my time once....
Ask away here, that's what the list is for. I don't think anyone here
can claim they've never asked a stupid programming question before.
Everyone at one time or another has a bad day when they forget how to
do something simple and can't remember where they saw the docs
covering it. Hopefully you won't get rude people responding with RTFM
and such.
> Well this is exactly how things seem to pan out. Those who have been
> doing this for some time like the documentation they have. No doubt
> once I become a bit more adept I will too. But right now......
My best advice is to keep working at it, trying out classes just to
learn how to make them work (and how to make them not work). Browse
the class listing and the methods in each class, often times you'll
find a method you never knew about and could really use. Soon things
will click and you'll wonder why it was so hard just a week before.
Kind of like those posters with all the weird patterns on them that
you stare at for hours until finally the 3D shapes pop out and you see
them. After that you can see them every time and wonder why it was so
hard the first time.
Keep making prototype programs like the dynamic typing one and try out
new things, and feel free to ask "simple" questions here. I often
times will make prototype programs and keep them. When I forget how I
got something to work I just look through my prototypes to remind me
and to grab code from. -
For what it's worth, something about the OS X Cocoa docs' arrangement
has never quite clicked with me. In part it might be an excess of
hyper text, too many pages to click through, breaking up the stream
of thought. (I wish XCode's doc viewer had some kind of keyboard
shortcut for clicking the 'next' or 'previous' links, rather than
having to scroll, find the link, and click on it. Surely it's
consistent enough to be automated?) I also get annoyed with
programming docs on Windows for the same reason - too much linky-
jumpy, too much documentation appearing to be little more than links
to yet other pages.
I found the arrangement of the NeXTStep docs to be a bit more
conducive to study. For one thing, the class reference docs were more
independently useful. Today the NSWindow class reference contains
method descriptions, but little context to help you make sense of
them. That context is in the Window Programming Guide For Cocoa,
which is itself 22 separate HTML pages, some of which are long
('Window Layering and Types of Window'), some short ('Handling Events
in Windows'). Some of the pages in the guide hardly seem long enough
to merit their own page. (That kinda bugs me. When a section gets its
own TOC entry, and its own page, but its only a short paragraph, I
think it leads the reader to feel a bit shortchanged, as if useful
information was left out. Worse, there might be relevant information
that is hiding elsewhere in the docs.)
In the NeXTSTEP days, a lot of that context information would be up
the top of the class reference file, so it was a self-contained unit
of information. There was also a set of Concepts documents that tied
things together, but there was a pretty high likelihood that a
question about a class could be answered simply by bringing up the
class reference rtf file. Need to know about NSWindow? Bring up
NSWindow.rtf.
Nowadays, the answer could be on any of a hundred pages, but probably
not in the class' own reference page.
(The NeXT docs were mostly set in Times, too, which I found easier to
read than the current near-universal use of sans serif.)
Your mileage may vary, of course. And I may be looking back through
rose-colored memories. I can't say the current arrangement is an
error or a case of bad design, it's just that I think the old
fashioned way worked better for my brain.
At the very least, before I got my hands on a NeXT box of my own I
was able to learn a fair amount from the NeXTStep Reference books,
two fat volumes consisting of the class reference files and little
else. The concepts material was in another volume. Nowadays, the
class reference files have largely been stripped down to
documentation of the methods, with little additional info, so there
would be little benefit from printing and binding them all together. -
On Sun, May 18, 2008 at 8:41 PM, Julius Guzy
<<email_removed>> wrote:
> Tthe fact is that there will be others like me who do not find it
> easy to get into cocoa. At this stage I'll not be jumping ship but
> believe me I've had sleeples nights about it. Mainly i'll not do it
> because although I'm far from attack speed I can just about open a
> few windows and pump bit map images to the screen, have menus and
> buttons and get mouse and tablet input and hopefully will soon be
> able to write to and from disk, and if i'm really lucky i might even
> be able to archive system state! in short, I am just about able to do
> the things I need to and I am actually progressing the technology
> that this current program of mine is supposed to deliver. In short
> the investment is beginning to pay off. But getting this far has been
> the most difficult piece of learning I've ever done in my life.
As an author of two books about Cocoa programming, it breaks my heart
to read the above quote. I don't write Cocoa books for the money.
There isn't much money to be made. I do it precisely because I want
to share the joy and satisfaction of Cocoa programming. It is my
profession and my hobby. I share my experiences and knowledge for the
same reason anybody encourages others to join in a shared interest.
Reading about "...sleepless nights..." and "...the most difficult
learning I've ever done in my life", I despair that the universe has
tilted on its axis and all is not right with creation.
The brief description of the application being developed follows:
1) Open a few windows
2) pump a few images to the screen
3) have menus
4) have buttons
5) get mouse and tablet input
6) write to and from disk
7) Archive APPLICATION state
All of the described features are implemented in the Sketch example
application that comes with the developer tools. /Developer/Examples/
AppKit/Sketch Sketch also provides undo, redo, rulers, marque
selection, keyboard events handling, copy & paste, drag & drop,
inspectors, and more. Many veteran Cocoa programmers learned from
the much more voluminous Draw example that preceded Sketch.
There are of course more detailed and focused examples focusing on
image processing and tablet input etc.
What precisely was difficult to learn? The books I write are intended
to ease the learning curve. If you describe your difficulties
sufficiently, I might be able to alleviate them for the next person. -
On May 18, 2008, at 8:39 PM, Julius Guzy wrote:
> Well this is exactly how things seem to pan out. Those who have been
> doing this for some time like the documentation they have. No doubt
> once I become a bit more adept I will too. But right now......
This is going to sound bitchy, but it's hard for me to have any
sympathy for vague complaints about the docs or the usability of
Cocoa. There have been a few times when I wasn't reading the
documentation thoroughly enough, or have had a question about
implementation that wasn't answered by looking at example code, and
have consulted the Apple listservs. (My bad)
There have been far fewer times when an obscure feature from one of
the more advanced APIs has not worked as it should. (Apple's bad)
But I can't think of a single time when I've been unable to figure out
where to look for guidance on a problem, or have been unable to
interpret that guidance.
For bird's-eye overviews, Apple posts things like this:
http://developer.apple.com/leopard/overview/graphicsandmedia.html
They also have resources broken down by category for hierarchically-
minded folks:
http://developer.apple.com/referencelibrary/
Once you narrow down what it is you want to do, Apple provides
"Getting Started" guides which give you the background you need:
http://developer.apple.com/referencelibrary/GettingStarted/GS_GraphicsImagi
ng/
That will lead you to deep guides like this:
http://developer.apple.com/documentation/GraphicsImaging/Conceptual/OpenGL-
MacProgGuide/
If you need to see a piece of code in action, Apple provides a wealth
of Example files both on the web and in your /Developer folder.
Even if you need to have a video, step-by-step instructions and
associated sample code, Apple's still (!) got your back:
http://developer.apple.com/mac/codingheadstarts.php
And finally, if you're not hierarchically-minded, there's Google (just
specify site:developer.apple.com after your search terms), and the
fact that the Reference Library is generously hyperlinked. Apple has
put a huge amount of effort into making Cocoa and its related
technologies easy to use and extremely well documented, and in my
opinion, it shows.
The only thing I can think of that would be better than Apple's online
docs would be if an Apple engineer would physically sit down and walk
you through something personally. And of course, Apple does that as
well. It'll cost you a bit more (plane fare & WWDC ticket), but if you
need to have your hand held, they'll do it.
So if you're going to complain about the docs, I would suggest that
you get very very specific, because Apple is truly bending over
backward to make it easy for you.
- ben -
Am 19.05.2008 um 04:08 Uhr schrieb Michael Vannorsdel:
> Hopefully you won't get rude people responding with RTFM and such.
Actually, I don't understand why an RTFM kind of answer is perceived
as rude. I'm really happy when I get an RTFM *with a link* to the
appropriate document.
Also, I often just don't answer at all, since an RTFM may not be well
received and I don't have the time to write a more elaborate answer.
Oh well.
Andreas -
On May 18, 2008, at 3:56 PM, <cocoa-dev-request...> wrote:
> On Sun, May 18, 2008 at 8:41 PM, Julius Guzy
> <julius...> wrote:
>> Well, there is a problems with the documentation and if it does
>> not get
>> resolved then people will end up unable to write the code. I mean
>> what is
>> the point in loosing people who actually want to program this
>> machine and
>> are willing to put oodles of effort into doing it?
>
> There's been a lot of discussion on the list lately about how Cocoa
> has been so hard for people to learn, but not a lot of useful
> specifics or follow-up. People haven said "the API is bad because it
> refers to all these terms you're already supposed to know and I don't
> know them!", and then when someone says "Did you read the conceptual
> documentation?" the response is a resounding... silence. I think this
> is part of why those veteran Cocoa developers are often less than
> sympathetic.
I would self-describe myself as a newbie, and feel compelled to chime
in on this discussion. The odd thing is, one can read the conceptual
docs and not see what is obvious to others, In my own experience, in
the very beginning, I would wend my way through the conceptual docs
dull eyed - yes, I was reading words, but the concepts escaped me.
For me, much of the learning comes in the pursuit of making code
work. Eventually the wonderful AHA moments happen. After which, when
I go back and read the conceptual docs again I smile - in a proud and
embarrassed way -- for suddenly parts make complete sense. And so, I
find I need to revisit the docs, over and over. In this regard,
addressing the discussion here regarding the quality of the docs is
quite a bit influenced by how much one already knows.
I have for the past few days been struggling to find a way to append
an attributed string to the end of text view. I resisted the
temptation to ask the list. I did look all through the docs. I read
loads of conceptual material about the text system (architecture,
layout, containers, storage, and many of the class references). I did
find an example in the text architecture document (Simple Tasks) for
using replaceCharactersInRange:withString: to append a string to the
end of the text view. I actually had trouble finding info on this
method (it is a part of NSText, which I had developed a notion of
that it was better to use its subclasses rather than itself
directly). That aside, there was no
replaceCharactersInRange:withAttributedString: But then it struck me
-- inheritance. What else does an NSTextView inherit from? What about
its storage? And by pursuing that, the answer became clear and the
solution utterly trivial. In fact, the way to do this is so
painfully obvious now that I am embarrassed to mention here that I
spent the better part of two days trying to figure this out. But this
is the plight of the programmer new (or relatively) to Cocoa.
Hopefully I will retain some humility from this experience.
The key to learning is to have fundamental ideas fall into place.
Before enough of that happens, even easy problems loom large. The gap
between the accomplished Cocoa programmer and the newcomer is the
context of their respective knowledge -- a context that makes problem
solving either more or less difficult, and that makes the docs either
useful or not.
My point in writing is that veteran Cocoa developers do need to have
some sympathy and compassion -- that we aspiring developers don't
have the patterns, and so what is obvious to you isn't obvious to us,
even if the docs say so.
On the other hand, aspiring developers need to understand that
learning involves struggle. And that having read the docs once or
twice isn't good enough. And also to understand that learning is
sometimes circular -- one needs to go round and round because so much
of the system is inter-related My advice: experiment! I must also
admit that I read and read about a Nib's File's Owner, but it wasn't
until I made a bunch of small apps that did nothing but display a
window (all done in various ways) that the idea finally sunk in.
That said, one of the huge barriers to climbing the Cocoa/Objective-C/
CF app development learning curve is that there is so very much to
learn. The deeper I get into it, the bigger the sea seems to become
(I am now trying to use Security Framework to manage passwords on a
keychain -- no small mountain here!).
BTW: I download PDFs of the Apple docs (from developer.apple.com) ...
and access those quite often. Using Preview, it is easy to search for
a term. I find I often have several open all at the same time, and
need to cross-reference what I am reading in order for solutions to
problems to appear.
Anyway, not sure if I have added anything meaningful...just sharing
my experience. -
Nothing wrong with saying "you should read such and such". But RTFM
is the condescending way of saying it (just look what it stands for).
Would be like asking someone where the restroom is and getting "look
at the building directory, you blind clueless moron". My point was
about posts that are belittling and snipe because the question was
simple.
On May 18, 2008, at 8:42 PM, Andreas Mayer wrote:
> Actually, I don't understand why an RTFM kind of answer is perceived
> as rude. I'm really happy when I get an RTFM *with a link* to the
> appropriate document.
>
> Also, I often just don't answer at all, since an RTFM may not be
> well received and I don't have the time to write a more elaborate
> answer. Oh well.
-
Some people have said they didn't know where to start (or their
questions lead myself and others to believe that is the case).
One of the conceptual documents that I found most useful was the Cocoa
Fundamentals Guide
http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals
/Introduction/chapter_1_section_1.html
Even if you know OO programming (or maybe especially if you do) you
should read it to find out how cocoa uses OO. Depending on your
background it is possible that some OO concepts that cocoa uses are
the same as what you've used before but it was called AAA and cocoa
calls it BBB.
Don't worry if you don't understand everything at first, just work
with what you do. I would also suggest that after you've been
programming with cocoa a month or two you go back and read it again.
And maybe even again after that. Keep doing that until you read it and
go "yeah done that", "that too", "and that". You can download the PDF
and use Preview to read it (preview has the advantage of remembering
that last page you were on) or print it out if you learn better off of
dead trees.
As for the order of what to learn there is a good post by Chris Hanson
about it
http://www.cocoabuilder.com/archive/message/cocoa/2007/6/4/184167
This is similar to the path I've taken and it works (actually, still
in the Cocoa Bindings part and haven't had a reason to start Core Data
at this point).
Just for those who may need some help finding the conceptual
documentation (obviously most people on this list know this but I
thought I'd state the obvious for those just firing up Xcode for the
first (or second) time), first on the API pages there is usually
(thought not always) an item at the bottom of the box in the upper
right corner called Companion Guide that deals with the info for that
API.
In general the conceptual docs are called guides, so you won't find
them by searching for 'conceptual'. The people on this list refer to
them as conceptual but Apple calls them guides. To look for all of
them in the Xcode documentation window select the 'Title', 'Core
Library', and 'Contains' tags under the toolbar and type 'guide' in
the search box.
The search field here is pretty basic, you only get one search term so
you won't, for example, get to search for 'guide cocoa' as it will
look for the full string not two separate strings. The google powered
search at http://developer.apple.com/ will do better but will not be
limited to the titles, for example.
I don't have a CS degree and would qualify, as one poster deridingly
called early mac programmers, as a hobbyist. I have approached
learning cocoa seriously and actually study it; via the documentation,
books, open source code, example code, programmer blogs, this lists
archives, creating test projects, and working on a full application
(slowly, this all comes out of my spare time after all).
Yes it would be nice if the docs could explain every api in exactly
the way that I am going to need to use it but that is not realistic.
At this point I am confident that for most any cocoa (or even non
cocoa) api I can use it from the api reference and the guides when I
need to. Things really do start making sense.
Anyway, interesting thread and sorry for rambling.
--Nathan -
> From: ben syverson <ben...>
>
> This is going to sound bitchy, but it's hard for me to have any
> sympathy for vague complaints about the docs or the usability of
> Cocoa.
That does sound bitchy. I mean, it's fair enough to say that people
ought to be providing specific feedback and constructive complaints.
But to have _no_ sympathy? That's harsh.
Real people are having real problems getting into Cocoa. I don't see
the kind of repeated commentary about poor documentation and
difficult APIs in the C#/.NET forums or Java forums. It comes up
once in a blue moon, but not with the reliability I've seen here, nor
is there nearly the kind of practiced, organized defense seen here
(which again suggests a certain regularity to the complaints).
I had a big long reply (even longer than this one :) ) written to
Julius's initial post under this subject and detailing many of my
concerns and complaints about Objective-C, Cocoa, and the
documentation, but decided the better of posting it. However, I'll
say this: I agree that at least for me, the fundamental issue is that
from a "usability" point of view, Objective-C, Cocoa, and the
associated documentation leave something to be desired. I found
Julius's comments regarding "usability" to be right on the mark, at
least in the general sense.
There's no question in my mind that Cocoa is a nice framework, and
that the entire environment provides some good productivity-enhancing
features. But it's also clear that those benefits are only really
available to someone who has already invested a lot of effort in
learning it. The "rule of least surprise" doesn't apply; maybe it
does to the framework, but not to the documentation and definitely
not to the tools.
I contrast that with my experiences moving to C#/.NET and Java from
the Win32 C++ world. Now, at least with .NET it is true that to some
extent, I benefitted from having a fair amount of Win32 expertise.
Some of the paradigms map closely, and that helped. But there's a
lot in .NET that is entirely new, and that was easy and fun too. And
Java was completely foreign to me when I started using it. In
neither case did I find myself feeling like I'd just entered a whole
new world where, until you had gone through the entire hazing
process, one could never really be effective as a programmer.
.NET and Java were _fun_. They are still fun. I love writing code
for either platform. I ported one simple .NET application to Cocoa
and haven't had any interest in writing any more Cocoa code at all.
I'd love to see the Mac succeed as a platform. But frankly, I think
you already have to be a pretty hard-core Mac fan, and _really_ want
to see your software on the Mac, to be motivated to spend a lot of
time with Cocoa. Until programming in Cocoa is fun for _everyone_,
not just the few who have made it through the gauntlet, I don't see
it attracting a large following.
Those who love the Mac, and who love Cocoa, ignore this kind of
feedback, provided to them on a regular basis, at their peril.
> [...] But I can't think of a single time when I've been unable to
> figure out
> where to look for guidance on a problem, or have been unable to
> interpret that guidance.
For what it's worth, it's not (to me) a matter of not being able to
figure it out at all. It's how much effort is required to figure it
out.
MSDN is sprinkled with code samples. Everywhere. Granted, some of
them are kind of silly, and some of them are just plain wrong. But
on the whole, they are pretty good. More to the point, they exist
for pretty much _every_ documented API element. Class methods,
properties, events, fields. All have a dedicated doc page that
includes some sample code (in many cases, a single sample is shared
among multiple elements...but that's just efficient doc writing).
Contrast to the Cocoa docs, where a single class is documented in
just one web page, with practically no sample code at all and
incredibly brief descriptions of each element.
Oddly enough, the same complaint can be made for Sun's docs for Java,
but I haven't found that to be nearly as great a degree of a problem
there. It's hard for me to put my finger on exactly what the
difference is, but I'd guess that at least partly it has to do with
the fact that Sun's docs include frames with navigation panes that
help orient you within the API, so that as you jump around you have
some idea of what classes are related to what and why. The Java
tutorials also seem more to the point.
I know that given time, I can figure pretty much anything out. But
in the Cocoa docs and API, it can sometimes be a real chore.
As an example, I found myself wanting to exclude an area from my
clipping region. Nothing complicated: I had a rectangular area, and
I wanted to draw everywhere _except_ a specific sub-rectangle. The
docs were quite prideful as to how, since Cocoa clipping uses the
NSBezierPath, you have practically infinite control over clipped. No
doubt this boasting was reasonably accurate (*). And yet, even as it
hints tantalizingly at the idea that there's a way to do this (see
"Modifying the Current Graphics State"), it doesn't quite get you there.
(*) And that's another thing...nowhere else have
I seen documentation that wastes so much time
explaining why _their_ API and paradigm is superior.
Why all the proselytizing? Just tell me how to get
the damn job done! I get it...Apple thinks that
there's no better way to write software than using
Cocoa. Stop hitting me over the head about it!
I was finally able to, after reading documentation in three different
places that discuss NSBezierPath, connect the dots so to speak and
figure out how the heck to get NSBezierPath to do what the docs
hinted it could do.
For that matter, why is the entire NSBezierPath API based on
"append"? Why isn't there just a "remove" semantic too, that
internally translates to the appropriate "append" behavior?
It's not that it's not possible to do what I wanted to do, or even
that Cocoa is lacking in functionality (at least in that area), or
even that the docs fail to include enough information to figure it
out. It's just that the docs seem to spend a lot of time discussing
either incredibly basic things, or incredibly complex things, and
failing to cover some of the more typical use cases.
So often when reading the MSDN docs and Sun's tutorials, I find code
samples and use explanations that are pretty close to what I'm trying
to do. Reading the Cocoa docs, as a person not writing really
complex programs, I find myself thinking "well, that's
interesting...but what about the kinds of things the other 98% of the
programming world wants to do?"
And to barely touch on another point of dissatisfaction, I'll point
out that least in Xcode 2.4, I found the Help topics for IB to be
fairly useless, as they appeared to be written for a previous version
of IB and often described things that were simply not even present in
the version I was using. A similar issue came up when I tried to use
Apple's docs to learn how to add my own Help for my program, only to
discover that the tool it referred to had nothing to do with the tool
currently in use.
Finally, the Cocoa fanatics would do well to not only recognize that
these dissatisfactions with the environment are not limited to just a
handful of malcontents (if you think you spend an inordinate amount
of time addressing these complaints now, just wait until if and when
the Mac is actually a popular programming platform), but to recognize
that individual complaints are somewhat varied.
For example, while I tend to agree with the issues raised about the
documentation, it doesn't bother me nearly as much as some of the
fundamental issues around Objective-C. Having spent so much time
using languages like C++, and later C# and Java, I get annoyed when
the language tells me that I need to start dealing with OOP concepts
such as object construction manually. Especially when this means
that in spite of the language encouraging me to write an appropriate
"init" method (the closest thing to a constructor Obj-C seems to
have), it turns out that for my sub-classes instantiated by IB,
that's never actually called. Duh.
I also find the dynamic nature of the language to be a liability, not
a feature. I keep hearing people say "sure, the compiler can't tell
you that method call is incorrect, but that's the cost of having such
a dynamic language", but then when pressed they are unable to
describe why that dynanism is beneficial. The vast majority of
software is easily written without that sort of capability, and with
much stronger compiler support for code correctness.
I realize there are plenty of people who love Obj-C. Heck, I'd guess
that most of the people reading this email love it. But you have to
understand that you're a fairly homogenous, isolated audience.
And as long as you guys keep insisting that there's nothing wrong
with the environment, and that people "just need to get used to it"
and "then they'll love it", you're not going to get the kind of
developer excitement needed to ensure the kind of developer support
required to get the Mac really into the mainstream. At a minimum,
market growth is going to happen a LOT more slowly than it could
otherwise.
And yes, it's fair to ask for specific, actionable criticism that can
be used to improve the documentation. But the fact is, when you're
knee-deep in trying to decipher the documentation and the API, it's
hard to remember to take the kind of notes that would be useful in
reconstructing the difficulties encountered. By the time I got my
little Cocoa program working, I was just so happy to finally be done
with it, the last thing I wanted to do was spend a bunch of time
trying to remember what was so painful about it and submitting all of
that information to Apple.
Yes, I agree it would have been better for me to do that. But I've
got other things to do, and frankly given the utter lack of sympathy
I found in the Mac development community for the issues I was going
through, I didn't find myself very motivated to spend my own time
trying to improve things. If Apple and the existing dev community
doesn't care, why should I?
Phew. I got rid of one long reply, only to eventually write
another. I guess I really needed to get that off my chest. Suffice
to say, I have not found the experience of writing Mac software
nearly as pleasurable as writing .NET or Java software. It's only
marginally better than the experience of writing to more primitive
platforms, and that's only because the Cocoa framework itself
counterbalances the awkward aspects of the rest of the environment.
As long as the existing Mac dev community, and especially Apple's own
developer support staff, fails to understand this, the Mac just isn't
going to attract people to write code just for the sake of writing
code. And people writing code just for the sake of writing code is
one of the biggest ways a platform gains strong developer support.
Pete -
For clipping tasks like this, NSBezierPath is a very poor cousin to
Apple's old technology for this - Regions. With regions one could
trivially obtain union, intersection, difference and xor of complex
shapes using the built-in APIs. Neither NSBezierPath nor the
underlying Quartz routines it calls upon have the equivalent
operations. OK, Regions were intrinsically pixel-oriented (scanline)
entities and maybe it's just too hard to offer this sort of thing
generically with bezier paths, but I for one feel this is a glaring
hole in the functionality of Quartz (and, since the rasterizing code
*already* has to search for self-intersections and so on, in fact the
private code must be very close to having an implementation of this
right there - they just need to clean it up, flesh it out and make a
public API for it).
For the case of excluding an area from the clip region you can
eventually force it to do the job by combinations of winding rules,
path reversals and appends, but for other graphics work these are a
very blunt instrument. The "append" terminology is the only one
NSBezierPath has because that's all it can do - append more paths. It
cannot subtract ("remove") one path from another. If the paths
intersect you can get an xor or a union effect depending on the
winding rule, but never a subtraction. It's a royal PITA.
Here's one method I have in a category on NSBezierPath that *might*
address the clipping situation that you have. However, since there's
no public method to GET the current context's clip path, this works
using the bounding box of that path instead, which may not be
applicable in every case. Once again, I know there's a private API for
this but for some inexplicable reason, Apple do not expose it in the
public headers, even though without it this sort of thing is downright
awkward, yet commonly required.
- (void) addInverseClip
{
// this is similar to -addClip, except that it excludes the area
bounded by the path instead of includes it. It works by combining this
path
// with the existing clip area using the E/O winding rule, then
setting the result as the clip area. This should be called between
// calls to save and restore the gstate, as for addClip.
CGContextRef context = [[NSGraphicsContext currentContext]
graphicsPort];
CGRect cbbox = CGContextGetClipBoundingBox( context );
NSBezierPath* cp = [NSBezierPath bezierPathWithRect:*(NSRect*)&cbbox];
[cp appendBezierPath:self];
[cp setWindingRule:NSEvenOddWindingRule];
[cp setClip];
}
G.
On 19 May 2008, at 3:03 pm, Peter Duniho wrote:
> As an example, I found myself wanting to exclude an area from my
> clipping region. Nothing complicated: I had a rectangular area, and
> I wanted to draw everywhere _except_ a specific sub-rectangle. The
> docs were quite prideful as to how, since Cocoa clipping uses the
> NSBezierPath, you have practically infinite control over clipped.
> No doubt this boasting was reasonably accurate (*). And yet, even
> as it hints tantalizingly at the idea that there's a way to do this
> (see "Modifying the Current Graphics State"), it doesn't quite get
> you there.
> I was finally able to, after reading documentation in three
> different places that discuss NSBezierPath, connect the dots so to
> speak and figure out how the heck to get NSBezierPath to do what the
> docs hinted it could do.
-
Is there any reason to use the cast on cbbox, instead of using
NSRectFromCGRect(cbbox), which does the same thing but wraps it up
nicely in an easy-to-read fashion?
From the docs:
> NSRectFromCGRect
> Returns an NSRect typecast from a CGRect.
>
>
> NSRect NSRectFromCGRect(CGRect cgrect) { return (*(NSRect
> *)&(cgrect)); }
>
> Return Value
> An NSRect typecast from a CGRect.
>
> Declared InNSGeometry.hSee Also
> • NSRectToCGRect
> • NSPointFromCGPoint
> • NSSizeFromCGSize
Cheers,
Andrew
On May 18, 2008, at 11:20 PM, Graham Cox wrote:
> For clipping tasks like this, NSBezierPath is a very poor cousin to
> Apple's old technology for this - Regions. With regions one could
> trivially obtain union, intersection, difference and xor of complex
> shapes using the built-in APIs. Neither NSBezierPath nor the
> underlying Quartz routines it calls upon have the equivalent
> operations. OK, Regions were intrinsically pixel-oriented (scanline)
> entities and maybe it's just too hard to offer this sort of thing
> generically with bezier paths, but I for one feel this is a glaring
> hole in the functionality of Quartz (and, since the rasterizing code
> *already* has to search for self-intersections and so on, in fact
> the private code must be very close to having an implementation of
> this right there - they just need to clean it up, flesh it out and
> make a public API for it).
>
> For the case of excluding an area from the clip region you can
> eventually force it to do the job by combinations of winding rules,
> path reversals and appends, but for other graphics work these are a
> very blunt instrument. The "append" terminology is the only one
> NSBezierPath has because that's all it can do - append more paths.
> It cannot subtract ("remove") one path from another. If the paths
> intersect you can get an xor or a union effect depending on the
> winding rule, but never a subtraction. It's a royal PITA.
>
> Here's one method I have in a category on NSBezierPath that *might*
> address the clipping situation that you have. However, since there's
> no public method to GET the current context's clip path, this works
> using the bounding box of that path instead, which may not be
> applicable in every case. Once again, I know there's a private API
> for this but for some inexplicable reason, Apple do not expose it in
> the public headers, even though without it this sort of thing is
> downright awkward, yet commonly required.
>
> - (void) addInverseClip
> {
> // this is similar to -addClip, except that it excludes the area
> bounded by the path instead of includes it. It works by combining
> this path
> // with the existing clip area using the E/O winding rule, then
> setting the result as the clip area. This should be called between
> // calls to save and restore the gstate, as for addClip.
>
> CGContextRef context = [[NSGraphicsContext currentContext]
> graphicsPort];
> CGRect cbbox = CGContextGetClipBoundingBox( context );
>
> NSBezierPath* cp = [NSBezierPath
> bezierPathWithRect:*(NSRect*)&cbbox];
> [cp appendBezierPath:self];
> [cp setWindingRule:NSEvenOddWindingRule];
> [cp setClip];
> }
>
>
> G.
>
> On 19 May 2008, at 3:03 pm, Peter Duniho wrote:
>
>> As an example, I found myself wanting to exclude an area from my
>> clipping region. Nothing complicated: I had a rectangular area,
>> and I wanted to draw everywhere _except_ a specific sub-rectangle.
>> The docs were quite prideful as to how, since Cocoa clipping uses
>> the NSBezierPath, you have practically infinite control over
>> clipped. No doubt this boasting was reasonably accurate (*). And
>> yet, even as it hints tantalizingly at the idea that there's a way
>> to do this (see "Modifying the Current Graphics State"), it doesn't
>> quite get you there.
>
>
>> I was finally able to, after reading documentation in three
>> different places that discuss NSBezierPath, connect the dots so to
>> speak and figure out how the heck to get NSBezierPath to do what
>> the docs hinted it could do.
-
Yes, it's not available pre 10.5
G.
On 19 May 2008, at 4:31 pm, Andrew Merenbach wrote:
> Is there any reason to use the cast on cbbox, instead of using
> NSRectFromCGRect(cbbox)
-
> FROM : Peter DunihoThat's odd. I see endless complaints about WPF and Microsoft's half
> DATE : Mon May 19 07:03:25 2008
>
> [deleted]
> Real people are having real problems getting into Cocoa. I don't see
> the kind of repeated commentary about poor documentation and
> difficult APIs in the C#/.NET forums or Java forums. It comes up
> once in a blue moon, but not with the reliability I've seen here, nor
> is there nearly the kind of practiced, organized defense seen here
> (which again suggests a certain regularity to the complaints).
hearted support and poor documentation.
> [deleted]The exact same thing could be said about object oriented programming.
> There's no question in my mind that Cocoa is a nice framework, and
> that the entire environment provides some good productivity-enhancing
> features. But it's also clear that those benefits are only really
> available to someone who has already invested a lot of effort in
> learning it. The "rule of least surprise" doesn't apply; maybe it
> does to the framework, but not to the documentation and definitely
> not to the tools.
The benefits are only really available to someone who has already
invested a lot of effort in learning it. Object oriented patterns are
very surprising to people who haven't learned the basics, so I guess
the "rule of least surprise" doesn't apply to object oriented
programming.
>Let's see... C++, Java, and C# all share very similar syntax. All are
>
> I contrast that with my experiences moving to C#/.NET and Java from
> the Win32 C++ world. Now, at least with .NET it is true that to some
> extent, I benefitted from having a fair amount of Win32 expertise.
> Some of the paradigms map closely, and that helped. But there's a
> lot in .NET that is entirely new, and that was easy and fun too. And
> Java was completely foreign to me when I started using it. In
> neither case did I find myself feeling like I'd just entered a whole
> new world where, until you had gone through the entire hazing
> process, one could never really be effective as a programmer.
strongly typed bondage and discipline languages. Two wrap the Win32
you already knew and the other has three commonly used GUI frameworks
that are all primative and "lowest common denominator" meaning that
you were unlikely to find anything surprising.
Here are some interesting comparisons between Cocoa and .Net from
the .Net Addicts Blog: http://dotnetaddict.dotnetdevelopersjournal.com/tags/?/cocoa
> [deleted]Many of us love Cocoa _in spite of_ Apple. I have been using NeXTstep/
> I'd love to see the Mac succeed as a platform. But frankly, I think
> you already have to be a pretty hard-core Mac fan, and _really_ want
> to see your software on the Mac, to be motivated to spend a lot of
> time with Cocoa. Until programming in Cocoa is fun for _everyone_,
> not just the few who have made it through the gauntlet, I don't see
> it attracting a large following.
Openstep/YellowBox/Cocoa since 1988 which was 2+ years before Windows
3.1 was released with all of the glories of Win16. Apple acquired the
technology that became Cocoa, stopped selling its predecessors, and
sat on it for 7 to 10 years with no significant enhancement and some
downgrades.
Furthermore, Java was in part inspired by Objective-C. See [http://virtualschool.edu/objectivec/influenceOnJava.html
] for quotes from Patrick Naughton, JamesGosling, and BillJoy. The
early Java frameworks were lobotomized versions of Openstep. C# was
created so that Microsoft could own something like Java after embrace
and extend was halted in court. C# is incrementally better than Java
as second systems often are.
> [deleted]Great! We have other posters complaining that the documentation
> As an example, I found myself wanting to exclude an area from my
> clipping region. Nothing complicated: I had a rectangular area, and
> I wanted to draw everywhere _except_ a specific sub-rectangle. The
> docs were quite prideful as to how, since Cocoa clipping uses the
> NSBezierPath, you have practically infinite control over clipped. No
> doubt this boasting was reasonably accurate (*). [deleted]
>
> (*) And that's another thing...nowhere else have
> I seen documentation that wastes so much time
> explaining why _their_ API and paradigm is superior.
> Why all the proselytizing? Just tell me how to get
> the damn job done! I get it...Apple thinks that
> there's no better way to write software than using
> Cocoa. Stop hitting me over the head about it!
>
doesn't explain "why" often enough. I am glad you were able to figure
out a 2D graphics system that is identical to PDF and has existed in
Postscript and text books for 30+ years. I am not sure Cocoa
documentation is the best place to learn about general 2D graphics,
winding rules, bezier paths, graphics contexts, etc. I think you
might find interesting similarities in WPF too.
> [deleted]I guess your conception of how 2D graphics should work just doesn't
> For that matter, why is the entire NSBezierPath API based on
> "append"? Why isn't there just a "remove" semantic too, that
> internally translates to the appropriate "append" behavior?
match the way 2D graphics have been conceived, implemented, and
documented for 30+ years. Just out of curiosity, if Apple enhances
the frameworks to implement your superior approach, won't that
surprise developers who have been educated from all those text books.
We wouldn't want to violate the principal of least surprise just
because we have discovered a better implementation would we ?
> [deleted]Apparently the docs don't spend enough time explaining incredibly
> out. It's just that the docs seem to spend a lot of time discussing
> either incredibly basic things, or incredibly complex things, and
> failing to cover some of the more typical use cases.
basic things. I would also think that doughnut shaped clipping paths
are hardly typical cases. Oddly though, I think there was a
transparent view example that used a doughnut shape. Does anybody
remember?
> [deleted]I agree. All forms of Apple help are useless. Apple used to provide
> And to barely touch on another point of dissatisfaction, I'll point
> out that least in Xcode 2.4, I found the Help topics for IB to be
> fairly useless, [deleted]
Digital Librarian which was yet another superior NeXTstep/Openstep
legacy that Apple killed. Some third party replacements exist
including appkido: http://homepage.mac.com/aglee/downloads/appkido.html
>Language preference is a preference. It's subjective. Some people
> Finally, the Cocoa fanatics would do well to not only recognize that
> these dissatisfactions with the environment are not limited to just a
> handful of malcontents
> [deleted]
> Having spent so much time
> using languages like C++, and later C# and Java, I get annoyed when
> the language tells me that I need to start dealing with OOP concepts
> such as object construction manually. Especially when this means
> that in spite of the language encouraging me to write an appropriate
> "init" method (the closest thing to a constructor Obj-C seems to
> have), it turns out that for my sub-classes instantiated by IB,
> that's never actually called. Duh.
will never like Objective-C. Apple now supports Python and Ruby
bridges to Cocoa. There used to be a supported Java bridge to Cocoa,
but it apparently wasn't used much. I foresee no huge technical
obstacle to a C# bridge to Cocoa.http://www.mono-project.com/CocoaSharp]
C++ and Objective-C can be mixed via Objective-C++.
> I also find the dynamic nature of the language to be a liability, notThere are many explanations for why dynamic languages are beneficial.
> a feature. I keep hearing people say "sure, the compiler can't tell
> you that method call is incorrect, but that's the cost of having such
> a dynamic language", but then when pressed they are unable to
> describe why that dynanism is beneficial. The vast majority of
I am certainly able to describe a few. The trend is clear. C# is
more dynamic than Java which is more dynamic than C++. Ruby, Python,
etc. are all very dynamic. Smalltalk is the original object oriented
language and is very dynamic. Start another thread about the benefits
of a dynamic object oriented language and how Cocoa leverages the
dynamism and I will surely participate.
>Sigh. All of the languages discussed are Touring Complete and
> software is easily written without that sort of capability, and with
> much stronger compiler support for code correctness.
therefore any of them can solve any solvable problem. The benefits of
one approach over another will surely depend on the problem. In my
experience, Cocoa is about the most elegant way a GUI can be
implemented, and Cocoa is only possible because of language dynamism.
>Some people actually prefer to write software with Cocoa and Objective-
> [deleted]
> As long as the existing Mac dev community, and especially Apple's own
> developer support staff, fails to understand this, the Mac just isn't
> going to attract people to write code just for the sake of writing
> code. And people writing code just for the sake of writing code is
> one of the biggest ways a platform gains strong developer support.
>
> Pete
C. Some do it just for the sake of doing it. Others produce
commercial software. There are plenty of testimonials about the
legendary productivity of Cocoa programmers. I have often heard it
said that nobody writes Windows software because they enjoy it. That
has certainly been my experience. I guess my experience is just the
opposite of yours. -
It's an inline fonction, so code compiled using this function will
properly work on pre 10.5 versions of the OS.
Le 19 mai 08 à 08:34, Graham Cox a écrit :
> Yes, it's not available pre 10.5
>
> G.
>
>
> On 19 May 2008, at 4:31 pm, Andrew Merenbach wrote:
>
>> Is there any reason to use the cast on cbbox, instead of using
>> NSRectFromCGRect(cbbox)
>
-
On May 19, 2008, at 12:03 AM, Peter Duniho wrote:
>> From: ben syverson <ben...>
>>
>> This is going to sound bitchy, but it's hard for me to have any
>> sympathy for vague complaints about the docs or the usability of
>> Cocoa.
>
> That does sound bitchy. I mean, it's fair enough to say that people
> ought to be providing specific feedback and constructive
> complaints. But to have _no_ sympathy? That's harsh.
No, you misread me. I wrote that I have no sympathy for *vague*
complaints. I'm sympathetic to people like yourself who have "specific
feedback and constructive complaints."
I think when all is said and done, most of this discussion can be
chalked up to taste. For example, I hate C++. It's ugly, doesn't fix
the problems in C, and implements a style of OOP that I find unusable.
Java is basically the same as C++, and seems relegated these days to
the ghettos of CS101 and JSP. C# is yet another knock-off of C++. It's
all down to opinion, but if those were the only three languages out
there, I wouldn't write code.
The Obj-C way makes much more sense to me. Even the syntax itself
encourages program to be more readable -- would you rather encounter
something like this:
imgWatermarkScale(image, rect, false, 0.5, true);
...or this, which tells you exactly what it's doing?
[image scaleToFit:rect cropToRect:NO withQuality:0.5 andWatermark:YES];
And when would you use dynamic typing? For me, it's just about every
day. NSArray and NSDictionary can contain a mixed bag of any kind of
object. Imagine you have an app where users can select multiple items
of different types -- images and sounds -- so they can copy + paste
them. What if you want them to be able to hit the "Rotate Right"
button with multiple items selected, even though it only makes sense
for images?
for (id anObject in userSelection) {
if ( [anObject respondsToSelector:@selector(rotateInDegrees:)] )
[anObject rotateInDegrees:90];
}
Now if you add a new type named Movie to the app, all you have to do
is implement the rotateInDegrees: method for the Movie class, with no
change at all to your "Rotate Right" code.
Of course, you should only use dynamic features when you need them --
most of the time, it's nice to have the compiler tell you that you're
passing the wrong kind of object to the fourth argument of method XYZ.
Anyway, I could go on and on about how much I love Obj-C. I would
encourage you to keep at it. It really shouldn't be such a massive and
torturous investment of time -- just start with simpler apps and
slowly increase the complexity...
- ben -
Ah, OK, I'd missed that.
But it raises another question I've been vaguely meaning to ask the
list, but which is pretty minor, so I haven't so far bothered:
If I declare a C function as static inline inside a .m file (just to
be clear, it's C function, not an Obj-C method) does it get inlined?
Someone told me very authoritatively recently that it wouldn't be
compiled inline if it's within a .m file, so the inline keyword was
redundant. I couldn't find anything documenting that either way.
G.
On 19 May 2008, at 5:51 pm, Jean-Daniel Dupas wrote:
>
> It's an inline fonction, so code compiled using this function will
> properly work on pre 10.5 versions of the OS.
>
> Le 19 mai 08 à 08:34, Graham Cox a écrit :
>
>> Yes, it's not available pre 10.5
>>
>> G.
>>
>>
>> On 19 May 2008, at 4:31 pm, Andrew Merenbach wrote:
>>
>>> Is there any reason to use the cast on cbbox, instead of using
>>> NSRectFromCGRect(cbbox)
>>
>
-
I would be really surpise if it is not. (and the "Show assembly" Xcode
command tell me that I'm right). I think their is no garantee that the
function will be inlined, as the "inline" keyword is just a compiler's
hint, but the NS_INLINE macros is defined like this:
static __inline__ __attribute__((always_inline))
And I'm pretty sure that a function declared like this will really be
inlined and the compiler will not create any symbol for it (except if
you explicitly tell it to create symbol for inline functions). It it
failed to inline it, the compiler will raise an error (try to create a
recusive function with this attribute, and one with only the inline
keyword for example).
You can try to run 'nm' on AppKit. There is nothing like
"NSRectFromCGRect" in the symbol list (And i have also some app that
use this function and run without issue on 10.4).
IMHO, the "Obj-C does not support inline" statement come from the
fact that it's not possible to inline a method (and it's also
meaningless, as it will break the dynamic nature of the language).
Le 19 mai 08 à 10:45, Graham Cox a écrit :
> Ah, OK, I'd missed that.
>
> But it raises another question I've been vaguely meaning to ask the
> list, but which is pretty minor, so I haven't so far bothered:
>
> If I declare a C function as static inline inside a .m file (just to
> be clear, it's C function, not an Obj-C method) does it get inlined?
> Someone told me very authoritatively recently that it wouldn't be
> compiled inline if it's within a .m file, so the inline keyword was
> redundant. I couldn't find anything documenting that either way.
>
>
> G.
>
>
> On 19 May 2008, at 5:51 pm, Jean-Daniel Dupas wrote:
>
>>
>> It's an inline fonction, so code compiled using this function will
>> properly work on pre 10.5 versions of the OS.
>>
>> Le 19 mai 08 à 08:34, Graham Cox a écrit :
>>
>>> Yes, it's not available pre 10.5
>>>
>>> G.
>>>
>>>
>>> On 19 May 2008, at 4:31 pm, Andrew Merenbach wrote:
>>>
>>>> Is there any reason to use the cast on cbbox, instead of using
>>>> NSRectFromCGRect(cbbox)
>>>
>>
>
>
-
On May 19, 2008, at 1:19 AM, ben syverson wrote:
> On May 19, 2008, at 12:03 AM, Peter Duniho wrote:
>
>>> From: ben syverson <ben...>
>>>
>>> This is going to sound bitchy, but it's hard for me to have any
>>> sympathy for vague complaints about the docs or the usability of
>>> Cocoa.
>>
>> That does sound bitchy. I mean, it's fair enough to say that
>> people ought to be providing specific feedback and constructive
>> complaints. But to have _no_ sympathy? That's harsh.
>
> No, you misread me. I wrote that I have no sympathy for *vague*
> complaints. I'm sympathetic to people like yourself who have
> "specific feedback and constructive complaints."
Sorry if I wasn't making my point clear. That is, while I think it's
reasonable to tell people that they are better heard if they can
state their complaints in a specific way, I think that even those who
are unable for whatever reason to do so still deserve some reasonable
amount of sympathy, rather than dismissal. It should be clear from
the volume of push-back that not all is well in Cocoa-Land, even if
the complaints are sometimes vague.
Sympathy is in short supply in the world today. Surely it wouldn't
hurt folks to offer at least some sympathy even to the people who are
making only vague complaints. :)
> I think when all is said and done, most of this discussion can be
> chalked up to taste. For example, I hate C++. It's ugly, doesn't
> fix the problems in C, and implements a style of OOP that I find
> unusable. Java is basically the same as C++, and seems relegated
> these days to the ghettos of CS101 and JSP. C# is yet another knock-
> off of C++. It's all down to opinion, but if those were the only
> three languages out there, I wouldn't write code.
I don't understand these comments. C++ works fine for a great many
OOP tasks, and it certainly addresses the basic lack of inherent
support for OOP that C has (so surely it "fixes" that "problem").
But more importantly, Java and C# are very different in their
approach from that of C++. It's not true at all that "Java is
basically the same as C++", and C# is a "knock-off" of Java, not C++.
Java's use is MUCH more widespread than you seem to realize. The
fact that it's cross-platform is a HUGE benefit and that benefit is
applied in practically every problem space in at least some way. I
think it's likely that the only reason it's not applied more broadly
on the Mac is the fact that Apple's Java implementation is years
behind the current standard.
Though, in light of the evangelism Apple gives Cocoa, maybe that's
not a big surprise. After all, if the Mac Java implementation _were_
up-to-date, it'd probably be the platform of choice for coding on the
Mac.
That'd be great for the Mac, but not so great for the Cocoa
evangelists. It's hard to understand the neglect Java has seen on
the Mac, except as a way to try to steer more people towards Cocoa.
> The Obj-C way makes much more sense to me. Even the syntax itself
> encourages program to be more readable -- would you rather
> encounter something like this:
>
> imgWatermarkScale(image, rect, false, 0.5, true);
>
> ..or this, which tells you exactly what it's doing?
>
> [image scaleToFit:rect cropToRect:NO withQuality:0.5
> andWatermark:YES];
I'm indifferent to the two. Frankly, even "in the olden days" I
never had that much trouble remembering the parameters for important
functions, and never had much trouble finding the details for the
lesser-used ones. In the current day and age of context-sensitive
code editors, whether the _code_ has the information or not is
irrelevant. It's available instantly. Ooops...Xcode doesn't really
do well here; oh well, suffice to say, when I'm coding C# and Java
it's not a big deal.
But as long as we're talking trivial things like formatting, I really
dislike the fact that chaining results in Obj-C is so clumsy. In C+
+, Java, and C# I can just start typing with the object I have and
the initial operation, and keep on going. But Obj-C insists that I
have as many open brackets to start with as I'm going to have
operations. The editor could help with this, but at least for Xcode
2.4 it doesn't. So I wind up feeling like the language is really
getting in my way, rather than just letting me breeze through the code.
But really, I'm pretty agnostic to the syntax. If the mechanics of
Obj-C were more to my liking, the actual syntax would be irrelevant
to me. Named parameters or not? Doesn't matter much to me either way.
> And when would you use dynamic typing? For me, it's just about
> every day. NSArray and NSDictionary can contain a mixed bag of any
> kind of object. Imagine you have an app where users can select
> multiple items of different types -- images and sounds -- so they
> can copy + paste them. What if you want them to be able to hit the
> "Rotate Right" button with multiple items selected, even though it
> only makes sense for images?
>
> for (id anObject in userSelection) {
> if ( [anObject respondsToSelector:@selector(rotateInDegrees:)] )
> [anObject rotateInDegrees:90];
> }
>
> Now if you add a new type named Movie to the app, all you have to
> do is implement the rotateInDegrees: method for the Movie class,
> with no change at all to your "Rotate Right" code.
In Obj-C, if the object doesn't respond to the selector, doesn't it
just fail silently? I'd think in Obj-C you wouldn't even bother to
check whether it responds to the selector, unless you had a "Plan B"
you wanted to use when it didn't.
But ignoring that for a moment, how is this example any different
from a Java or C# class implementing an interface that declares a
"rotateInDegrees" method? The equivalent C# code would look
something like this:
foreach (object anObject in userSelection)
{
IRotatable rotater = anObject as IRotatable;
if (rotater != null)
{
rotater.rotateInDegrees(90);
}
}
or if you like briefer:
foreach (object anObject in userSelection)
{
if (anObject is IRotatable)
{
((IRotatable)anObject).rotateInDegrees(90);
}
}
You could even use LINQ so that the enumeration itself only pulled
out the things that implemented IRotatable. Then it's a simple one-
line loop.
Oh, and as an added benefit: because interfaces are treated like
types and you're not dealing with method signatures directly, there's
none of this "oops, you forgot to include the trailing colon in the
selector name" business (you can probably guess, I've run into that
at least once :) ). The compiler prevents that from happening.
Which is all a long way of saying, the message-sending paradigm in
Obj-C isn't required for the example you give. This is my point.
With a strongly-typed language that includes run-time type
information (something that's even available in some C++
implementations for that matter), you don't need to have a whole
message-dispatching system for your function-calling.
So this message-dispatching thing in Obj-C must have some other
benefit. Granted, it's never really been explained to my
satisfaction to me, so I can't necessarily represent the argument
correctly. But the gist as I understand it is that because the
language is so flexible, you can swap in whole new classes at run-
time to override existing library behaviors.
That's just not something I've ever felt a need to do, and frankly it
sounds like a code-maintenance nightmare. But at the very least, if
this _is_ the argument in favor of Obj-C, I'd love for someone to
give me a real-world, mainstream example where the same end result
can't be accomplished in a reasonable manner using a more
conventional language.
If that's not the argument in favor of Obj-C, well...then I'm still
waiting to hear what benefit this message-dispatching paradigm
provides over other languages.
> Of course, you should only use dynamic features when you need them
> -- most of the time, it's nice to have the compiler tell you that
> you're passing the wrong kind of object to the fourth argument of
> method XYZ.
Likewise, interfaces aren't something you use _everywhere_ in Java
and C#. You use them only when you need them. The difference is
that in Java and C#, the compiler "always" (*) knows whether what
you're doing is reasonable or not. In Obj-C, the compiler can
believe it's reasonable only for it to turn out that it's not (I
refer you back to my complaint about the lack of true constructors).
(*) And yes, I'm fudging a bit here, since in Java and C# you can
always write code that uses casting to hide from the compiler that
you've done something boneheaded. But even in that case, at least
you get an exception thrown at run-time, rather than having your code
fail silently.
> Anyway, I could go on and on about how much I love Obj-C. I would
> encourage you to keep at it. It really shouldn't be such a massive
> and torturous investment of time -- just start with simpler apps
> and slowly increase the complexity...
I should be clear: it's not that I hate Obj-C. I didn't intend for
my comments to turn into a "my language is better than yours" fight,
and I hope and expect we can wrap that digression up here.
Not only do I not hate Obj-C, it's not even that it took me a long
time to learn it. The really tricky things I ran into had to do with
integrating what happened in IB with what's going on in Xcode and my
own code. The language itself is relatively easy to pick up, and I
hope I haven't given the impression that that's the part I've been
having trouble with.
There's nothing wrong with Objective-C per se. It's a perfectly
workable language.
It's just that I've recently become accustomed to a different
programming style, one that I find more appropriate for general-
purpose, everyday programming. I've been programming for nearly 30
years. C# for the last five or so, and Java more recently. For most
of my career, I've had to deal with systems where there was a long
laundry list of conventions that one had to follow, and it's not that
I didn't get used to them or couldn't navigate them.
It's just that today, in the 21st century, when there are languages
like Java and C# (and I gather Delphi, and maybe some others that I
haven't used) that rather than expecting you to learn and know these
conventions, simply impose them on your code for you so that you can
get on with worrying about the parts of code that the compiler
_can't_ deal with, I feel like I'm stepping backwards in time when
I'm writing Obj-C code.
I still remember the first time I saw a NeXT cube. Very cool
machine, and I drooled all over it (well, figuratively anyway). But
that was nearly 20 years ago. What was state of the art back then,
well...today? Not so much. So sure, in a general discussion about
perceived shortcomings in Apple's preferred development environment,
a mention or two of these relatively minor problems with Obj-C might
come up. :)
But actually, in spite of the turn that this reply takes, that's not
really the point of the message I wrote before. As you can see from
my comments above, Obj-C isn't where the problem lies. I find it
awkward and a little dusty. But it has all the basic features I've
come to expect from an OOP language, and it's not what caused me all
the headaches when I got into Cocoa.
Rather, my point was simply to reinforce that a) I agree that there
really is a usability problem with respect to the programming
environment (of which Obj-C plays a relatively small part, with the
docs and the tools playing a much larger part), and b) it seems as
though there is an intractable problem with respect to much (most?
all?) of the Cocoa development community insisting that there's no
problem, in spite of the fact that for such a small community there's
a surprising amount of bandwidth consumed by the question of whether
there's a problem or not.
Pete -
>
> That'd be great for the Mac, but not so great for the Cocoa
> evangelists. It's hard to understand the neglect Java has seen on
> the Mac, except as a way to try to steer more people towards Cocoa.
>
Cocoa is a framework, Java a language. Apple provided a Cocoa/Java
bridge to let developpers choose there prefered language to use Cocoa,
and bet what, almost nobody choose Java. That's why the bridge is no
collapsing slowly.
> In Obj-C, if the object doesn't respond to the selector, doesn't it
> just fail silently? I'd think in Obj-C you wouldn't even bother to
> check whether it responds to the selector, unless you had a "Plan B"
> you wanted to use when it didn't.
>
> But ignoring that for a moment, how is this example any different
> from a Java or C# class implementing an interface that declares a
> "rotateInDegrees" method? The equivalent C# code would look
> something like this:
>
> foreach (object anObject in userSelection)
> {
> IRotatable rotater = anObject as IRotatable;
> if (rotater != null)
> {
> rotater.rotateInDegrees(90);
> }
> }
>
> or if you like briefer:
>
> foreach (object anObject in userSelection)
> {
> if (anObject is IRotatable)
> {
> ((IRotatable)anObject).rotateInDegrees(90);
> }
> }
>
It's different because there no informal protocol in C#, so you have
to create a interface for each optional method you want to add to your
object, and then declare that you implement each interfaces in your
class declaration.
Yes, it's possible to achieve the same things, but it's not as easy
and natural. -
> Date: Mon, 19 May 2008 02:35:12 -0400
> From: Erik Buck <erik.buck...>
>
>> [...] It comes up
>> once in a blue moon, but not with the reliability I've seen here, nor
>> is there nearly the kind of practiced, organized defense seen here
>> (which again suggests a certain regularity to the complaints).
> That's odd. I see endless complaints about WPF and Microsoft's half
> hearted support and poor documentation.
WPF is hardly all of .NET. If this discussion were about some
specific area of Cocoa, that might be a relevant comparison.
But it's not. There's a difference between an entire development
environment having problems, and some relatively new and (so far)
little-used library within that environment having problems. I'm not
talking about the latter.
>> [deleted]
>> There's no question in my mind that Cocoa is a nice framework, and
>> that the entire environment provides some good productivity-enhancing
>> features. But it's also clear that those benefits are only really
>> available to someone who has already invested a lot of effort in
>> learning it. The "rule of least surprise" doesn't apply; maybe it
>> does to the framework, but not to the documentation and definitely
>> not to the tools.
> The exact same thing could be said about object oriented programming.
> The benefits are only really available to someone who has already
> invested a lot of effort in learning it. Object oriented patterns are
> very surprising to people who haven't learned the basics, so I guess
> the "rule of least surprise" doesn't apply to object oriented
> programming.
I have no idea why you think your reply is relevant to what I wrote.
I'm not talking about the framework, and you quoted the stated that
made that clear.
Just because the language and framework require some justified
investment in time learning, that's no reason for the documentation
and tools themselves to be that way. Those are pieces of software
just like any other software, and the same rules of usability apply.
>> I contrast that with my experiences moving to C#/.NET and Java from
>> the Win32 C++ world. Now, at least with .NET it is true that to some
>> extent, I benefitted from having a fair amount of Win32 expertise.
>> Some of the paradigms map closely, and that helped. But there's a
>> lot in .NET that is entirely new, and that was easy and fun too. And
>> Java was completely foreign to me when I started using it. In
>> neither case did I find myself feeling like I'd just entered a whole
>> new world where, until you had gone through the entire hazing
>> process, one could never really be effective as a programmer.
> Let's see... C++, Java, and C# all share very similar syntax. All are
> strongly typed bondage and discipline languages. Two wrap the Win32
> you already knew and the other has three commonly used GUI frameworks
> that are all primative and "lowest common denominator" meaning that
> you were unlikely to find anything surprising.
You don't seem to be reading what I wrote. First of all, .NET isn't
simply a wrapper for Win32 and I already pointed that out. Yes, some
of it is. Lots of it is not, and even the parts that are not, are
not difficult to pick up (or at least weren't for me).
C++ doesn't "wrap" Win32 at all (though I gather there are now newer
libraries that expose Win32 as C++). The Win32 API as I used it from
C++ is strictly C, and is not "wrapped" at all.
And frankly, I'd hardly call AWT or Swing (perhaps the third you're
thinking of is AWT) "primitive". Especially Swing, which contains
full-blown MVC components. Only AWT is "lowest common denominator".
SWT and Swing build on OS-level functionality in a very rich fashion,
albeit using different strategies.
Since you didn't get it when I wrote it the first time, here it is
again, more clearly: both .NET and Java were foreign entities when I
started using them, but offered programming environments and
documentation that were much more helpful to me than what I've found
with Cocoa.
> Many of us love Cocoa _in spite of_ Apple. I have been using
> NeXTstep/
> Openstep/YellowBox/Cocoa since 1988 which was 2+ years before Windows
> 3.1 was released with all of the glories of Win16. Apple acquired the
> technology that became Cocoa, stopped selling its predecessors, and
> sat on it for 7 to 10 years with no significant enhancement and some
> downgrades.
Well, at least we can agree on the fact that Cocoa is 10 years behind
the industry today. :)
> [...] Great! We have other posters complaining that the documentation
> doesn't explain "why" often enough. I am glad you were able to figure
> out a 2D graphics system that is identical to PDF and has existed in
> Postscript and text books for 30+ years.
Why in the hell should I have to learn PDF or Postscript just to do
basic region manipulation? And even if you think I should, how is
the sarcasm productive?
> [...] I guess your conception of how 2D graphics should work just
> doesn't
> match the way 2D graphics have been conceived, implemented, and
> documented for 30+ years. Just out of curiosity, if Apple enhances
> the frameworks to implement your superior approach, won't that
> surprise developers who have been educated from all those text books.
> We wouldn't want to violate the principal of least surprise just
> because we have discovered a better implementation would we ?
Again with the abusiveness.
The fact is, even Apple's own clipping paradigm supported
intersections and removals, as do plenty of other graphical APIs.
It's simply false to claim that the way that NSBezierPath is used in
Cocoa for clipping is representative of some uniform paradigm used in
the last 30 years of graphics APIs.
Look: if there's something about the way paths work that precludes a
simple implementation of region subtractions, fine. Just say so.
But don't go pretending that using paths for clipping regions is a
ubiquitous or even mainstream approach. There's plenty of precedent
for alternatives such as I'm talking about.
> [...] There are many explanations for why dynamic languages are
> beneficial.
> I am certainly able to describe a few.
Well?
As I mentioned in another message, I'd love to see a clear
explanation of why the message-dispatching paradigm used by Cocoa is
so beneficial to common scenarios. And in particular, why does it
justify giving up such code-correctness aids as true constructors?
Surely I don't need to start a whole new thread just to have that
simple question answered.
> [...]
>> software is easily written without that sort of capability, and with
>> much stronger compiler support for code correctness.
> Sigh. All of the languages discussed are Touring Complete and
> therefore any of them can solve any solvable problem.
Turing-Completeness isn't the point. I'm not talking about any
arbitrary solution to problems. I'm talking about an example of
where the Cocoa solution is demonstrably, significantly superior to
what's possible in a different language, for a problem that comes up
on a regular enough basis to base a whole language choice on that
kind of scenario.
> The benefits of
> one approach over another will surely depend on the problem. In my
> experience, Cocoa is about the most elegant way a GUI can be
> implemented, and Cocoa is only possible because of language dynamism.
Yes, that's the party line. I've heard that so many times before.
But I've yet to see an actual example of why that's true. That's not
to say no such example exists. But I wish someone would actually
"put up" and show the example. What is it about the message-
dispatching paradigm that makes Cocoa so much more elegant for coding
a GUI than other commonly used languages?
> Some people actually prefer to write software with Cocoa and
> Objective-
> C. Some do it just for the sake of doing it. Others produce
> commercial software. There are plenty of testimonials about the
> legendary productivity of Cocoa programmers. I have often heard it
> said that nobody writes Windows software because they enjoy it. That
> has certainly been my experience. I guess my experience is just the
> opposite of yours.
Anyone who says absolutes like "nobody writes Windows software
because they enjoy it" is a complete and utter fool. It takes but
one example to prove them wrong. Certainly in my own case, I found
that .NET renewed a joy in me about programming that I hadn't felt in
years (and no, I don't think it's flawless...believe it or not, it's
possible to love a programming environment and still recognize its
shortcomings).
The fact is, I know a lot more people who love .NET programming than
who love Cocoa programming. This is mainly a function of platform
popularity, naturally. But still, the idea that you can't enjoy
Windows programming is just stupid. As long as Apple and the Cocoa
community continue to believe that .NET and the Visual Studio IDE
can't be fun to use, they'll never get the point.
I am not doubting at all that Cocoa is an environment that lots of
people find useful or even enjoyable. My point is that there are
people who act as though anyone making any critical comments about
Cocoa and everything surrounding it have absolutely no valid points
to make, and that those people are wrong to act in that way.
Frankly, you are doing a great job of proving my point. Your
comments are every bit as dismissive, abusive, and information-free
as what I'm talking about. You mischaracterize my own statements and
then proceed to knock your newly constructed straw-man down, you
sarcastically imply that I'm an idiot for having trouble with the
API, and you fail to directly address specific questions asking for
information about what specific benefits the Cocoa paradigm provides
over "more conventional" languages. At the same time, you refuse to
believe that there's any room for improvement over the current
situation.
No one is trying to take your favorite language away here. We're
just trying to point out how things could be made better for the
occasional developer who _hasn't_ been doing Cocoa for twenty years
and who might come along and try to write a program that runs on a Mac.
Pete -
On 19 May 2008, at 5:21, : Nathan Kinsinger
<nkinsinger...> wrote
> Subject: Re: Cocoa et al as HCI usability problem
>
> I don't have a CS degree and would qualify, as one poster deridingly
> called early mac programmers, as a hobbyist. I have approached
> learning cocoa seriously and actually study it; via the documentation,
> books, open source code, example code, programmer blogs, this lists
> archives, creating test projects, and working on a full application
> (slowly, this all comes out of my spare time after all).
I am very sorry if I had given the impression I thought deridingly of
early mac programmers as hobbyists.
Nothing could be further from my mind. What I actually said in the
original posting was:
" However, Apple has been less celebrated for the humanity of its
programming
interface having, in my experience of Macs from the Lisa onwards,
seemingly taken the attitude that its programmers were hobbyists,
geeks essentially, who because of their enthusiasm would successfully
negociate their way into the machine's innards."
I am attributing those thoughts to early apple and even then only
partially and hopefully a little ironically.
Also I don't disparage hobbyists. On the contrary there is plenty to
celebrate.
I then follow the above quote by saying
"That said, the 9 tomes of "Inside the Macintosh" documentation of
the programmer's
workshop were pretty good once you got into them but there was a lot
less to get into then than there is today."
i.e. intending to mean that contrary to the impression I had got, the
mac of the programmer's workshop era actually did take the trouble to
produce some very good material.
So again, very sorry to have given the wrong impression.
To be absolutely clear: I think anyone able to navigate the
intricacies of Cocoa et al must be a pretty savvy programmer.
Julius
http://juliuspaintings.co.uk -
On May 19, 2008, at 3:26 AM, Jean-Daniel Dupas wrote:
>> That'd be great for the Mac, but not so great for the Cocoa
>> evangelists. It's hard to understand the neglect Java has seen on
>> the Mac, except as a way to try to steer more people towards Cocoa.
>
> Cocoa is a framework, Java a language. Apple provided a Cocoa/Java
> bridge to let developpers choose there prefered language to use
> Cocoa, and bet what, almost nobody choose Java. That's why the
> bridge is no collapsing slowly.
Java is not just a language. It's a framework too. As for the Cocoa/
Java bridge, I had no idea it existed. If I'd known, I would have
tried it.
I presume from your comment about "now collapsing slowly" that it's
no longer a fully-supported technology.
That said, as I've said repeatedly now, while I have my complaints
about Objective-C, that's not really what keeps Cocoa programming
from being fun for me.
> It's different because there no informal protocol in C#, so you
> have to create a interface for each optional method you want to add
> to your object, and then declare that you implement each interfaces
> in your class declaration.
Optional methods rarely appear in isolation. They represent some
behavior shared by a variety of objects, and most frequently as part
of a whole package.
But even so, what's so bad about having to declare an interface? In
Obj-C, I wouldn't hard-code a string in my code anyway; at a minimum,
I'd declare a constant that represents that string, and it's possible
in some cases I'd even initialize a selector variable to store the
actual selector. So it's not clear that you'd save that much typing,
if any. I surely wouldn't.
And using a formal interface provides compile-time code verification
that just isn't possible with the message-dispatching scheme.
I just don't see how declaring an interface and then using it is so
inferior to an informal protocol that it justifies the entire message-
dispatching paradigm, especially given that there are in fact
advantages to the former. At best, it's a wash.
(Besides, both Java and C# support via reflection functionlity that
that would allow this exact kind of informal protocol/interface
approach, were it truly necessary and significantly better).
I'm sorry, but this particular example is just plain weak. I'm
looking for a _compelling_ justification for the message-dispatching
paradigm, not an example that saves you a line or two of code every
now and then.
Pete -
>
> Actually, I don't understand why an RTFM kind of answer is perceived
> as rude. I'm really happy when I get an RTFM *with a link* to the
> appropriate document.
>
> Also, I often just don't answer at all, since an RTFM may not be
> well received and I don't have the time to write a more elaborate
> answer. Oh well.
>
Though somewhat outside the central topic, this is an important
point, especially for newbies. It's rare that I respond with an
"RTFM"; it's only when I really, truly believe the person has
demonstrated themselves to be outright lazy. Most of the time, when I
suspect they didn't read the manual (because I can remember the exact
place I read the answer since I did so a number of times), I harp on
using the magical thing called a search engine. Some people do seem
terminally inept at merely *searching* for a definition. It's called
"cross-referencing".
Regardless, when I see someone who fights when they're told to do
their homework , I usually place them on my ignore list (whether I was
the one they fought or not). It's a cautionary tale any list member
should take note of because, while few will outright say it, most of
the experienced members will do exactly that. If you don't have time
to search and can't accept being reminded to do so, we don't have time
to bother with you and you will be ignored.
Nothing to do with Cocoa or this list specifically ... it's been
like that as long as I can remember on every technical mailing list.
The resounding theme: do your research because we're not going to do
it for you.
--
I.S. -
>> That'd be great for the Mac, but not so great for the Cocoa
>> evangelists. It's hard to understand the neglect Java has seen on
>> the Mac, except as a way to try to steer more people towards Cocoa.
>
> Cocoa is a framework, Java a language.
The comparison is not as wrong as you say. Java is essentially the
language plus the runtime. People usually refer to Java as a platform
- as you don't really can't get one with without the other. That's why
there is also is the "Java Platform API Specification"
http://java.sun.com/j2se/1.4.2/docs/api/
...which essentially should be OK to compare to Cocoa.
> Apple provided a Cocoa/Java bridge to let developpers choose there
> prefered language to use Cocoa, and bet what, almost nobody choose
> Java. That's why the bridge is no collapsing slowly.
That's a bit simplified IMO. It's also a question of marketing and
dynamics that are way beyond the scope of Cocoa vs Java alone.
Just because something gets popular and something else gets abundant
does not make a statement about the quality of one or the other.
That's said - I am not taking any sides here ..if there are any :)
cheers
--
Torsten -
On Mon, May 19, 2008 at 6:10 PM, Peter Duniho <peted...> wrote:
> It should be clear from the volume of push-back that
> not all is well in Cocoa-Land, even if the complaints are sometimes vague.
This is absurd. Every programming system I have ever encountered that
rises above the level of masochistic hobbyists experiences complaints
like this, and in similar volume. There are *always* people who have
trouble with the learning curve. Now, I certainly think things could
be improved on this front, but the existence or even the volume of
these complains is not evidence of anything other than that this
platform actually attracts programmers who aren't using it just
because it's hard.
> I don't understand these comments. C++ works fine for a great many OOP
> tasks, and it certainly addresses the basic lack of inherent support for OOP
> that C has (so surely it "fixes" that "problem").
I think, and I have spoken to a lot of people over the years who agree
with me, that C++'s "fix" is vastly worse than the disease. C++ is not
OOP in any real sense of the word (see Alan Kay's famous remark on
this if you don't know what I mean) and any similarity to real OO
languages such as Objective-C is only superficial.
> In Obj-C, if the object doesn't respond to the selector, doesn't it just
> fail silently?
No, you are thinking of messaging nil. If you send a message to an
object that it doesn't respond to, it throws an exception.
> Oh, and as an added benefit: because interfaces are treated like types and
> you're not dealing with method signatures directly, there's none of this
> "oops, you forgot to include the trailing colon in the selector name"
> business (you can probably guess, I've run into that at least once :) ).
> The compiler prevents that from happening.
If this bothers you that much in ObjC then merely add
-Wundeclared-selector to your compiler warning flags.
> Which is all a long way of saying, the message-sending paradigm in Obj-C
> isn't required for the example you give. This is my point. With a
> strongly-typed language that includes run-time type information (something
> that's even available in some C++ implementations for that matter), you
> don't need to have a whole message-dispatching system for your
> function-calling.
This makes no sense. If you support this kind of dispatch then you
*have* a whole message-dispatching system, no matter what you call it.
Java and C# ultimately support the same messaging semantics as ObjC,
albeit vastly more verbosely in the more complicated cases, and has
similar machinery underneath it making it all happen.
> So this message-dispatching thing in Obj-C must have some other benefit.
> Granted, it's never really been explained to my satisfaction to me, so I
> can't necessarily represent the argument correctly. But the gist as I
> understand it is that because the language is so flexible, you can swap in
> whole new classes at run-time to override existing library behaviors.
>
> That's just not something I've ever felt a need to do, and frankly it sounds
> like a code-maintenance nightmare. But at the very least, if this _is_ the
> argument in favor of Obj-C, I'd love for someone to give me a real-world,
> mainstream example where the same end result can't be accomplished in a
> reasonable manner using a more conventional language.
Write the following method in Java or C#:
- (void)setColor: (NSColor *)color {
[[[self undoManager] prepareWithInvocationTarget: self] setColor: mColor];
[mColor release];
mColor = [color retain];
}
If you can't guess, [self undoManager] returns an instance of NSUndoManager.
For added fun, think about how you would implement NSUndoManager
itself. I'm sure it's possible in these languages, but the language is
going to get in your way a lot, both in the writing and the using.
Or even implement something as simple as the Cocoa responder chain,
trivial in ObjC, in one of these more "mainstream" languages.
> Likewise, interfaces aren't something you use _everywhere_ in Java and C#.
> You use them only when you need them. The difference is that in Java and
> C#, the compiler "always" (*) knows whether what you're doing is reasonable
> or not.
Even with your caveat, this is insane. No compiler can stop you from
writing unreasonable code. It may be able to stop you from writing
code that treats an object as something it's not, but that is only one
tiny corner in an enormous universe of unreasonableness. This is, of
course, the fundamental point of contention between statically and
dynamically typed languages. Us dynamic advocates know that the
compiler can detect these things, we just don't care. You treat these
bugs like any other bugs, and you catch them in testing. Sure, it's
convenient to catch them when you compile instead, but is it worth the
enormous loss of flexibility? The people on this side say no. If you
disagree, that's fine, but realize that it's a fundamental matter of
opinion, not simply that your compilers are able to catch all your
errors and ours are not.
> It's just that today, in the 21st century, when there are languages like
> Java and C# (and I gather Delphi, and maybe some others that I haven't used)
> that rather than expecting you to learn and know these conventions, simply
> impose them on your code for you so that you can get on with worrying about
> the parts of code that the compiler _can't_ deal with, I feel like I'm
> stepping backwards in time when I'm writing Obj-C code.
Funny, that's how I feel every time I see Java code. The universe of
OO languages has tilted strongly toward dynamic duck-typing of late.
This is something that Smalltalk started and ObjC lead by a long way,
but most OO languages you run into these days are this way. Java and
C# are an odd anachronism from that point of view.
Mike -
Regarding the arrangement of the docs:
I find it much easier to read the guides, and oftentimes also the
reference documentation, from a web browser rather than in Xcode's
documentation window. If I'm using Xcode, I will usually have the doc
window open. However, I'll very often have the guide(s) for the
particular subject(s) that I'm studying open in various tabs in my
browser as well.
If you have installed Xcode or the Documentation in the usual places,
then the following two URLs will get you to the main documentation
starting pages:
Core Reference
file:///Developer/Documentation/DocSets/com.apple.ADC_Reference_Library.CoreReference.docset/Contents/Resources/Documents/referencelibrary/index.html
Tools Reference
file:///Developer/Documentation/DocSets/com.apple.ADC_Reference_Library.DeveloperTools.docset/Contents/Resources/Documents/referencelibrary/index.html
If you don't get much joy from Xcode's viewer, then I'd suggest trying a
web browser instead. Also, you can always download the PDFs and print
them if you prefer something on paper.
For What It's Worth,
Jason -
Boy, I've been really refraining myself from jumping into the fray
here. It's an interesting discussion which has been handled
respectfully, but it seems to me that we've reached the point of
diminishing returns on this. I think the lines have been drawn, and
most people have chosen one side of the line or the other and I don't
think there's much convincing going on.
About 2-3 years ago, we had a similar discussion on this list, which
got rather heated and it got kind of nasty (with some of the blame for
that clearly falling on me), but since that argument I've been
primarily a lurker here, and have become a little gunshy about issues
like this. Nonetheless, I feel a need to put in a few comments. Before
I do that, I'll throw my bias up front - I think Apple, for the most
part, is doing an excellent job on the documentation. There is room
for improvement in places, but given the enormity of the job and the
target audience, I think they're doing great. I rarely have problems I
can't get an answer to either in the documentation or, when that
fails, from one of the helpful people here or one of the blogs
maintained by one of the people here.
I think what we are seeing is a combination of cultural and
technological (or, perhaps, architectural) differences coming to the
surface thanks to the influx of new programmers to our platform.
Unlike many of the Cocoa developers on this list, I have one foot
squarely in the other world - a good chunk of my income comes from
large corporate (think Fortune 100) clients, and I work regularly in a
number of language and on a number of platforms including .Net and
Java. I think this gives me closer to an objective view of the
situation than most, though I clearly still have my biases.
In many ways, Cocoa/Obj-C is an oddity, and certainly the approaches
that Microsoft, Sun, and Apple have taken with their development tools
is different. Microsoft has architected .NET, especially (but not
only) Visual Basic, to lower the bar for learning the most common and
most basic tasks by hiding some of the complexity involved. They
market heavily to large corporate and governmental entities that you
don't need experienced programmers, you can just send someone out to
certification and they'll be able to write whatever you need. They
push the "ROI" of doing that, since a junior tech makes less than an
experienced programmer. I'm not making this up, their Enterprise
salesforce uses this type of argument excessively with large corporate
clients: Because .Net is eaiser, they argue, it's cheaper.
And it's true, that to design a very simple application in VB or C# is
phenomenally easy, but there are tradeoffs. They've changed the shape
of the curve, but not the amount of work it takes to become truly
proficient, and I've made a lot of money over the years cleaning up
(or rewriting) programs written by people with little or no experience
other than a certification class. No matter what salespeople will tell
you, you can't remove the requirement of experience to become a truly
competent programmer, but you can make a programmer who hasn't gained
that competence unaware of their ignorance. I would argue that that is
one side-effect of Microsoft's approach. That combined with the fact
that the sheer number of .Net programmers out there means that almost
any specific task you need to do has been done by somebody else, so
with some decent Google skills, you can avoid learning to do the hard
stuff for quite some time since you can probably find a blog post or
code sample somewhere instead of writing your own code.
With Cocoa, there's a bunch of hard stuff right up front that you
can't avoid. I found that it took a while to "get it" when I first
came to the platform. I was primarily a C, C++, and Java programmer,
and I very quickly understood the steps to do basic things, but I
didn't always understand why I was doing it. Then, after a few months
of pretty regular use, I had this "aha!" moment and it literally all
fell in place, my brain formed a gestalt from all the various pieces I
had been playing with. In that one moment, Cocoa went from being hard
to being the easiest platform I knew... it was like getting to the top
of a hill, and then getting to ride a bicycle down the other side.
It's a steeper mountain (learning curve), and it seems much harder
until you reach the top, but it's much easier as come down the other
side. Probably a silly metaphor, but it feels right to me.
Now, I need to say this, because people often misinterpret comments
like the ones I've just made: I'm NOT bashing .NET. I'm just stating
that the architects have taken a different approach in the
construction of the language and libraries, and that there are
consequences to that approach. There are phenomenal .Net programmers
out there. But, Cocoa is NOT .NET and it's NOT Java, and some of the
differences are very fundamental and abstract. You really need to
approach learning it with the mindset that you don't know anything -
you have to learn from the ground up, and in some cases unlearn what
you think you know. Don't assume you know anything other than the
fundaments of programming (loops, conditionals, variables, etc.). Do
not fall into the trap of assuming you know how to do something simply
because you may have done it in a different language.
After a year of using Cocoa regularly, come on back and let us know
your feelings about the differences in the platforms, because at that
point, you'll actually have a good basis for making the comparison.
And it's completely possible that you'll still prefer .Net or Java,
but at least you will have an informed opinion. Until you've taken the
time to really grok Cocoa - and it does take some time - you really
are judging based on criteria that may not be appropriate or valid.
Here's an example: Over the course of this discussion, people have
asked questions like "Why do you like Xcode when Visual Studio is
better?" Well, it's because Xcode is well-suited to programming in
Cocoa and Visual Studio is well-suited to programming in .Net. Some of
the things that are in VS but aren't in Xcode are things that you miss
because you are still thinking like a .Net programmer. Same goes for
Eclipse and Java. Not that there isn't room for improvement in Xcode,
but don't assume that because you used a feature in Eclipse or .Net
that it is "missing" in Xcode, it could very well be left out
intentionally. A "kitchen sink" approach is not always the best
approach, and I think that's something the Apple engineers really do
understand - Objective-C has been around for roughly 20 years and has
not experience the kind of bloat that C++ and Java have.
Give it a little time. In the meantime, if you have specific problems
and can't find a solution in the documentation or by googling, then
post a question here. I guarantee that you will get help if you are
moderately respectful and have done at least a minimal amount of
research on your own. People here are tremendously helpful (as I can
attest from first-hand experience), but they're not going to do your
work for you.
Jeff -
I like Cocoa. Like any language it has a learning curve, but I enjoy
traipsing around in Cocoa-Land, and it's not that hard to learn if you
put some work into it. If you have a problem, you can ask it here;
that's what this mailing-list is for. If Apple thought their
documentation was perfect for everyone, they probably wouldn't have a
list for people to ask questions. I think it would be nigh-impossible
to write documentation that fits everyone's needs, so the obvious way
out is to give a brief description, plus description of simple tasks,
provide lots of useful examples, and have mailing lists to ask about
things you're unsure on.
The guys on this list are really helpful.
Just my 10 cents.
Lincoln Green
<Isildur.lincoln...>
http://www.binkworks.com/ -
I have followed this discussion closely because as a veteran developer
who started on Mac OS back in the nineties and then gone to Win32 and
a bit with PHP, Tango, .NET (both web and mobile/desktop), Cocoa has
been very difficult to *get into*. Every technology I've been able to
get into easily because I could discover the tech in my own time.
Cocoa is not like that. You have to grok the whole foundation first
before you can do anything.
So I've got a business I'm running writing software for mobile
platforms and I do a lot of coding myself for WinMobile as well as
managing several project leads for BlackBerry and other platforms. I
want to get into Cocoa and *learn* it by trying simple useful things
first and then going forward in my spare time. With all other
languages and frameworks I've used you can do that and not feel
overwhelmed. The Cocoa docs are not conducive to that. I have
purchased Aaron's book and that helped a lot - except it was out of
date and didn't follow any of the new tools (which I have to use due
to the Cocoa platform I'm working with) - so while I could see it
being great for what I needed it was useless for now.
I'm not against hard work to learn a new platform/language. Its a
challenge and I love it. The problem I have is that the docs as
written do not work for learning Cocoa in your spare time even if you
plan to go full-time to Cocoa in the future (that's my goal - move my
WinMobile dev to my other engineers and then move myself to Cocoa full-
time, but I can't just drop my projects now). And I think this quote
from Peter Duniho explain exactly why:
> MSDN is sprinkled with code samples. Everywhere. Granted, some of
> them are kind of silly, and some of them are just plain wrong. But
> on the whole, they are pretty good. More to the point, they exist
> for pretty much _every_ documented API element. Class methods,
> properties, events, fields. All have a dedicated doc page that
> includes some sample code (in many cases, a single sample is shared
> among multiple elements...but that's just efficient doc writing).
>
> Contrast to the Cocoa docs, where a single class is documented in
> just one web page, with practically no sample code at all and
> incredibly brief descriptions of each element.
I agree with much of what Peter wrote in his post, though not his
conclusion that Cocoa can't be fun. I've watched one of my Cocoa devs
who is very fluent in Cocoa and it can be fun. Once you grok
everything and get that "Aha" moment, its fun to work with. But until
then its like pulling teeth.
Part of the issue I feel is that some people need examples along with
the reference. Sample code is great, but I don't want to have to open
sample project after sample project to just figure out a few things
that could've been shown in 5 lines of sample code in the docs. Its
also now separate from the docs which mentally makes it harder to
connect.
Just like some people are visual learners and some people are audial
learners, some of us do not do well with overly wasteful with
paragraphs of chit-chat. I don't want a seminar; I want to know what
the class is for, what its methods do, and give me some simple
examples on how one would use them. And explain WHY it works that way
and so on.
Again Peter wrote much of what I wanted to write:
> As an example, I found myself wanting to exclude an area from my
> clipping region. Nothing complicated: I had a rectangular area, and
> I wanted to draw everywhere _except_ a specific sub-rectangle. The
> docs were quite prideful as to how, since Cocoa clipping uses the
> NSBezierPath, you have practically infinite control over clipped. No
> doubt this boasting was reasonably accurate (*). And yet, even as it
> hints tantalizingly at the idea that there's a way to do this (see
> "Modifying the Current Graphics State"), it doesn't quite get you
> there.
And finally, I think the issue Peter had with finding Cocoa non-fun
were not due to Cocoa itself. For one thing, I think XCode 3.0 makes a
huge difference in the "fun" of Cocoa - the tools are a huge deal and
make a big first impression to new developers and it sounds like he
used XCode 2.4 which I didn't care for much. Second, the doc issue and
the difficulty in getting started with those docs negatively colored
his feelings on Cocoa.
So my advice to Scott and the Apple docs team:
1) Be less verbose. Get to the point.
2) Provide a doc tree so we newbies can find our way around the docs
better while in XCode.
3) Provide simple sample code within each method. It doesn't have to
be production quality. Just give me an example so I can connect what
you're writing. You have the Research Assistant which is 90% of the
way there, but again it points me to a collection of sample projects
which I have to download, setup, find the code I'm looking for. I've
now spent 30 minutes looking for sample code that on MSDN would take
no extra time.
BTW - for those new to Cocoa - grab XCode 3 and use the new Research
Assistant as except for sample code, it really solves many issues I've
had with learning Cocoa.
Alex Kac - President and Founder
Web Information Solutions, Inc. - Central Texas Microsoft Certified
Partner -
I don't think you're understanding what he's saying or at least taking
it to the wrong extreme. I'm reading his comment that the docs talk
about how great their API is, not explaining the concepts.
In my last post I said the docs can be too verbose. I *want* the docs
to explain why to me, but they don't have to write a novel. Also I do
not think we have to be 2D graphics API experts having read multiple
2D graphics system books and being experts in there to just understand
how to do basic clipping, although that is what you're suggesting below.
I think your response is one reason so many people who try to provide
feedback on why they find something hard in Cocoa or hard with the
docs get discouraged. You're email to Peter is condescending and
arrogant. You're the super Cocoa dev who's been around since NeXT and
so we must be ignorant or wrong.
Just take the feedback and know that not everyone learns or works the
way you do. The fact that XCode 3 has improved the docs, has improved
the docs UI, and so on shows that feedback helps.
>> (*) And that's another thing...nowhere else have
>> I seen documentation that wastes so much time
>> explaining why _their_ API and paradigm is superior.
>> Why all the proselytizing? Just tell me how to get
>> the damn job done! I get it...Apple thinks that
>> there's no better way to write software than using
>> Cocoa. Stop hitting me over the head about it!
>>
> Great! We have other posters complaining that the documentation
> doesn't explain "why" often enough. I am glad you were able to figure
> out a 2D graphics system that is identical to PDF and has existed in
> Postscript and text books for 30+ years. I am not sure Cocoa
> documentation is the best place to learn about general 2D graphics,
> winding rules, bezier paths, graphics contexts, etc. I think you
> might find interesting similarities in WPF too.
Alex Kac - President and Founder
Web Information Solutions, Inc. - Central Texas Microsoft Certified
Partner
"The optimist proclaims that we live in the best of all possible
worlds; and the pessimist fears this is true."
-- James Clabell -
On May 19, 2008, at 12:42 PM, Alex Kac wrote:
> Every technology I've been able to get into easily because I could
> discover the tech in my own time. Cocoa is not like that. You have
> to grok the whole foundation first before you can do anything.
I don't agree with this. You have to grok it all before you work
optimally, perhaps, but that's true of any language. But you will
never grok it all if you don't work with it, make mistakes, etc. You
make it sound like a huge catch-22 in which nobody could ever learn
Cocoa without spending a year contemplating their navel first. ;)
> I'm not against hard work to learn a new platform/language. Its a
> challenge and I love it. The problem I have is that the docs as
> written do not work for learning Cocoa in your spare time even if
> you plan to go full-time to Cocoa in the future (that's my goal -
> move my WinMobile dev to my other engineers and then move myself to
> Cocoa full-time, but I can't just drop my projects now).
I'm curious as to why you (and obviously several others) believe this
is true - I'd like some concrete examples of what's preventing the
Cocoa Documentation from letting you learn it effectively in your
spare time. I'm not doubting you, I just think it would be interesting
to isolate what the factors are that make it work for some and not
others, because I learned Cocoa before Aaron's book was first
published almost exclusively from the NeXT documentation in my spare
time while working 60+ hours a week at a software company in the Bay
Area during the height of the dot com explosion, with a wife who was
working the same kind of hours at a software company, and with four
kids under the age of four. Believe me, spare time was at a premium in
my life when I learned Cocoa from the official documentation.
The documentation and tools today are better than they were then
because so much was in flux with the whole Rhapsody / Yellow Box
switchover from NeXT, there was a lot of uncertainty and more changes
than the doc team could keep up with. It wasn't easy - as I stated in
an earlier e-mail, I spent a lot of the first few months without a
clear picture of what I was doing at times, but to say the docs "do
not work for learning Cocoa in your spare time" is an overly broad and
patently untrue statement. Perhaps they don't work for you, with your
schedule and your way of learning, but I guarantee you that many of
the people on the list learned primarily from the very same
documentation you claim can't be used effectively for learning. The
thing that is true (I think) is that the "big picture" is more
important with Cocoa than with most other languages, so it's more
intimidating to dive in and it takes longer before you get a comfort
level.
Also, I realize that on many other platforms, it is common to see code
samples sprinkled through the API documentation/ For example, the
header of the Iterator class might show a code sample about how to
iterate using an iterator. I can see how coming from that background
could lead you to think Apple's API documentation is deficient. It's
really just that Cocoa documentation isn't set up that way - it's more
modular. To say that Cocoa doesn't have code examples is wrong. It has
them - plenty of them - they're just not in the API documentation.
Most classes have links to the relevant guides and conceptual
documentation where the code is. It's sort of like MVC, but - there's
a modularity and clear division of documentation based on the purpose
it serves; once you understand the way its set up and know where to
look for what you need, it's more than adequate. -
Hi,
Sincerely, I am coding under windows with Win32/Qt/Corba/Lua and others for a living, I use MSDN every day, I read their example very often.
Well Qt has a very usable API and a good documentation and good examples and we have access to the sources...
But on the Win32/Microsoft front, I don't think that the doc is so well written at all, and they had a lot more money to put it behind this task.
Ok, hopefully you can find a lot of useful stuff on lot of web site (code guru...), but the Microsoft documentation suck, sincerely.
I agree that the Cocoa doc 2/3 years ago was not good at all, that's true. Now the doc team has made a very nice job and the doc has a lot improved. A lot of conceptual text.
You can start easily. Obviously, they can make it better,it need time.
something like :
xcode documentation --> Cocoa --> Getting Started
et voila
and you start reading the doc, you can print it and read it in the public transport to do it in your spare time... :) Maybe people are to used to code without understanding it with the help of code completion...
I suppose that Apple need to put more people on this front to get it better, but it would reduce their business profit :(
I was reading in public transport, every day, the documentation of NeXTSTEP 0.8 18 year ago, that's funny :) I agree that at this time it took me 6 months to get the Aha! moment, but I didn't have a NeXT computer at work, hence reading the documentation was the sole thing I was able to do.
Have fun
Gerard
> I'm not against hard work to learn a new platform/language. Its a
> challenge and I love it. The problem I have is that the docs as
> written do not work for learning Cocoa in your spare time even if you
> plan to go full-time to Cocoa in the future (that's my goal - move my
> WinMobile dev to my other engineers and then move myself to Cocoa full-
> time, but I can't just drop my projects now). And I think this quote
> from Peter Duniho explain exactly why:
>
>> MSDN is sprinkled with code samples. Everywhere. Granted, some of
>> them are kind of silly, and some of them are just plain wrong. But
>> on the whole, they are pretty good. More to the point, they exist
>> for pretty much _every_ documented API element. Class methods,
-
> Date: Mon, 19 May 2008 19:50:57 +0800
> From: "Michael Ash" <michael.ash...>
>
> [...] the existence or even the volume of
> these complains is not evidence of anything other than that this
> platform actually attracts programmers who aren't using it just
> because it's hard.
The platform attracts programmers who aren't using it? What does
that even mean? If the programmers aren't using it, how did the
platform attract them?
In any case, it takes a pretty blind eye to claim that the volume of
complaints is in no way related to problems.
>> [...]
>> Oh, and as an added benefit: because interfaces are treated like
>> types and
>> you're not dealing with method signatures directly, there's none
>> of this
>> "oops, you forgot to include the trailing colon in the selector name"
>> business (you can probably guess, I've run into that at least
>> once :) ).
>> The compiler prevents that from happening.
>
> If this bothers you that much in ObjC then merely add
> -Wundeclared-selector to your compiler warning flags.
Never even heard of that flag. Why isn't it the default?
This is a decent example of the kinds of usability issues we're
talking about, and frankly that one looks pretty easy to fix.
>> Which is all a long way of saying, the message-sending paradigm in
>> Obj-C
>> isn't required for the example you give. This is my point. With a
>> strongly-typed language that includes run-time type information
>> (something
>> that's even available in some C++ implementations for that
>> matter), you
>> don't need to have a whole message-dispatching system for your
>> function-calling.
>
> This makes no sense. If you support this kind of dispatch then you
> *have* a whole message-dispatching system, no matter what you call it.
> Java and C# ultimately support the same messaging semantics as ObjC,
> albeit vastly more verbosely in the more complicated cases, and has
> similar machinery underneath it making it all happen.
Maybe I'm misinformed about how message-dispatching in Objective-C
works. But AFAIK, it's nothing like the direct invocation and v-
table mechanisms that exist in C# and Java. It's the exact opposite
of "similar".
> Write the following method in Java or C#:
>
> - (void)setColor: (NSColor *)color {
> [[[self undoManager] prepareWithInvocationTarget: self]
> setColor: mColor];
> [mColor release];
> mColor = [color retain];
> }
>
> If you can't guess, [self undoManager] returns an instance of
> NSUndoManager.
In C#:
void setColor(NSColor color)
{
undoManager.prepareWithInvocationTarget(this).setColor(mColor);
mColor = color;
}
or more likely (following the "property" semantic):
NSColor color
{
set
{
undoManager.prepareWithInvocationTarget(this).color =
mColor;
mColor = value;
}
}
Your point being? If you think your example is useful in presenting
your claim, you'll need to be a lot more specific.
> For added fun, think about how you would implement NSUndoManager
> itself. I'm sure it's possible in these languages, but the language is
> going to get in your way a lot, both in the writing and the using.
I've implemented undo in C# and had no problem with the language
getting in my way. If anything, I found that C#'s support for
anonymous methods and delegates made it much easier than it would
have been in C++ (not that it would have been all that hard in C++).
> Or even implement something as simple as the Cocoa responder chain,
> trivial in ObjC, in one of these more "mainstream" languages.
It's trivial in C# too. Most likely, it'd be implemented as a
"handleable" event, with each responder subscribed to the event, and
invocation halted after the first subscribed delegate actually
handling the event. But it wouldn't be hard to do it based on
interfaces instead (and in Java, that's pretty much the best way to
do it, it not having events or delegates), and that implementation
would look a lot more like Obj-C (in that the invoker would simply
enumerate the responders until it found the one that implements the
interface it needs).
>> Likewise, interfaces aren't something you use _everywhere_ in Java
>> and C#.
>> You use them only when you need them. The difference is that in
>> Java and
>> C#, the compiler "always" (*) knows whether what you're doing is
>> reasonable
>> or not.
>
> Even with your caveat, this is insane.
Yes, using words like "absurd" and "insane" to describe the person
with whom you're discussing the issues is a really mature, productive
way to engage them.
> No compiler can stop you from
> writing unreasonable code. It may be able to stop you from writing
> code that treats an object as something it's not, but that is only one
> tiny corner in an enormous universe of unreasonableness.
You're missing the point. For things that the compiler _can_ do
easily, it _should_. The lack of true constructors in Obj-C is an
example of this.
> This is, of
> course, the fundamental point of contention between statically and
> dynamically typed languages. Us dynamic advocates know that the
> compiler can detect these things, we just don't care. You treat these
> bugs like any other bugs, and you catch them in testing. Sure, it's
> convenient to catch them when you compile instead, but is it worth the
> enormous loss of flexibility? The people on this side say no. If you
> disagree, that's fine, but realize that it's a fundamental matter of
> opinion, not simply that your compilers are able to catch all your
> errors and ours are not.
Well, I'm still waiting for someone to show me how that flexibility
is used. You are certainly doing a great job of stating the same
party line I've heard countless times already. But you're also
failing to provide a compelling example of how this flexibility comes
into play in the real world. Again, this is not only typical, it's
characteristic of _every_ single time I've heard the party line stated.
It's really hard to take the "flexibility" argument seriously when no
one's willing or able to back that up with a real example.
By the way, nothing would make me happier than to see a truly
compelling example. Hard though it may be to believe, I _want_ to
like Cocoa and Objective-C. I just hate being talked down to. The
proof is in the pudding, and I want pudding.
And finally, in spite of the attention I've given your reply, the
fact is (as I have now stated several times), the language is NOT the
big deal here! Yes, there are things about it that annoy me. But I
can easily get over those things. Languages come and go, and they
all offer fundamentally the same kinds of behaviors, albeit sometimes
in very different ways. I've never met a computer language that I
had trouble learning, and Objective-C isn't going to be the first.
My real issue has to do with the overall usability of the development
environment, and very few of the issues in that respect come from the
language. They are more to do with the tools and the documentation.
So, debate me on the language if you like, but it's really not what
concerns me.
Pete -
On May 19, 2008, at 1:33 PM, Peter Duniho wrote:
> NSColor color
> {
> set
> {
> undoManager.prepareWithInvocationTarget(this).color =
> mColor;
> mColor = value;
> }
> }
Are you sure about this? I'm just a little surprised to see that C#
API has an UndoManager with exactly the same syntax as Cocoa. Or were
you just demonstrating the syntax similarities between C and C#? -
> Date: Mon, 19 May 2008 09:32:01 -0400
> From: Jeff LaMarche <jeff_lamarche...>
> Subject: Re: Cocoa et al as HCI usability problem
>
> [...] In many ways, Cocoa/Obj-C is an oddity, and certainly the
> approaches
> that Microsoft, Sun, and Apple have taken with their development tools
> is different. Microsoft has architected .NET, especially (but not
> only) Visual Basic, to lower the bar for learning the most common and
> most basic tasks by hiding some of the complexity involved.
I agree with this statement. However, the conclusion is flawed.
As an accomplished programmer myself, part of what makes C#/.NET
programming so fun is the way that the language hides the
complexities that aren't important to me. The framework and the
language both encapsulate some fairly deep implementation details
that are powerful, and yet I don't have to waste time thinking about
them when I write code.
Philosophies will differ, but the fact that an environment is
approachable by beginners doesn't preclude its being favored by
experts. Some experts may love to always see the nitty-gritty
details, but plenty of others appreciate an environment where they
can stop worrying about them and instead apply their many years of
programming experience to the non-repetitive parts of their
implementations.
I hesitate to call .NET or especially Java "beautiful", but the fact
is even with whatever warts they have, there is a certain sense of
beauty that comes from having details common to every implementation
pushed down under the surface so that the programmer doesn't need to
think about them with every line of code they write.
Cocoa has beauty in its own way, and I want to emphasize that the
framework itself is certainly not an area of significant concern to
me, but the environment involves a lot more button-pushing, toggle-
flipping, etc. than it really needs to. Inasmuch as that causes me
to waste time doing things that the tools should be doing for me, I
find that undesirable.
Pete -
Peter Duniho wrote:
> In C#:
>
> void setColor(NSColor color)
> {
> undoManager.prepareWithInvocationTarget(this).setColor(mColor);
> mColor = color;
> }
> Your point being? If you think your example is useful in presenting
> your claim, you'll need to be a lot more specific.
[...]
> Well, I'm still waiting for someone to show me how that flexibility
> is used. You are certainly doing a great job of stating the same
> party line I've heard countless times already. But you're also
> failing to provide a compelling example of how this flexibility
> comes into play in the real world. Again, this is not only typical,
> it's characteristic of _every_ single time I've heard the party line
> stated.
You've translated the Objective-C syntax into C# syntax, but the point
of the question is to think about what prepareWithInvocationTarget()
does. How would you write that method in C#?
In Objective-C, after you call -prepareWithInvocationTarget: on an
NSUndoManager, it then accepts _any_ message call of any kind. It is
completely and totally dynamic. It accepts messages from your
application which weren't defined and didn't exist when the
NSUndoManager class was compiled. The undo manager accepts the
message, saves the target and method invocation with an arbitrary
number of arguments and is able to re-invoke it later on the original
target when the user asks you to Undo.
This is an example of what a dynamic message dispatch mechanism can do
for you. How would you implement that in a direct invocation or v-
table environment? Of course Undo is still doable in Java or C#: these
are all turing equivalent languages, but how much code would it take
and how complicated would it be for the programmer using the undo
management library to define this-is-something-to-undo?
Hope this helps,
- Greg -
On May 19, 2008, at 1:33 PM, Peter Duniho wrote:]
> Your point being? If you think your example is useful in
> presenting your claim, you'll need to be a lot more specific.
undoManager.prepareWithInvocationTarget(this).setColor(mColor);
I could be wrong, but in C#, wouldn't this UndoManager need to be
defined beforehand as responding to setColor, and any other method
that could require undo?
NSUndoManager doesn't. It doesn't have to be coded to handle
setColor, or any other method that you might want to have undone. -
> Date: Mon, 19 May 2008 11:42:39 -0500
> From: Alex Kac <alex...>
> Subject: Re: Cocoa et al as HCI usability problem
>
> [...]
> I agree with much of what Peter wrote in his post, though not his
> conclusion that Cocoa can't be fun.
I hesitate to even mention this, as I've written tons already and
probably should ease off.
But I want to be clear: my conclusion isn't that "Cocoa can't be
fun". I see vicariously that it _can_ be fun and take as granted
that the statement "Cocoa can't be fun" is obviously false.
My conclusion is rather that for me, Cocoa _hasn't_ been fun, for
me. And (as I've mentioned previously) this really isn't the fault
of Cocoa, and it's barely the fault of Objective-C. It's really more
to do with the tools and documentation. Improve those, and the fun
factor goes WAY up.
I admit, I haven't looked at Xcode 3. Perhaps now that it's been out
for awhile, it's time to take a look (assuming it'll run on 10.4).
I'm encouraged by your statement that it's a lot better than 2.4.
Thanks,
Pete -
On Mon, May 19, 2008 at 1:33 PM, Peter Duniho <peted...> wrote:
> Maybe I'm misinformed about how message-dispatching in Objective-C works.
> But AFAIK, it's nothing like the direct invocation and v-table mechanisms
> that exist in C# and Java. It's the exact opposite of "similar".
You're misinformed about how message-dispatching in Objective-C works.
It's very analogous to a v-table in c++ and related languages; I
believe there's just a touch more run-time information stored in the
table.
--
- David T. Wilson
<david.t.wilson...> -
On May 19, 2008, at 10:33 AM, Peter Duniho wrote:
> In any case, it takes a pretty blind eye to claim that the volume of
> complaints is in no way related to problems.
I would expect that the volume of complaints is pretty much directly
related to the over 100.000 downloads of the iPhone SDK that happened
over the last several weeks. Who can look at that number and not
expect to hear from a lot of confused programmers trying to learn [1]
a new language, [2] a new framework and [3] a new OS at the same time?
Programmers have been productive on this platform (language, tools,
OS) for years and years. The tools, technologies and documentation is
better than ever. Are there still things that could be better? Of
course there is, but would that not always be true?
Whenever you, as a programmer, try to make this jump to a new platform
you have to suppress the urge to complain about everything that isn't
exactly like your old environment, or everything that you don't
understand right away. This is just like traveling to a different
country. Things that are different are not necessarily bad, and it
typically takes a while to understand why things work the way they do
(Take it from me, I just moved to the US). The point of traveling is
experiencing new things to learn from and get inspired by, and the
same holds true for learning about new environments as a programmer.
We welcome input from new users to our platform. It's great to have an
influx of new people come with fresh ideas. Please file bug reports
for any concrete problems you find or suggestions that you have:
<http://developer.apple.com/bugreporter/>
j o a r -
On May 19, 2008, at 10:48 AM, Greg Titus wrote:
> You've translated the Objective-C syntax into C# syntax, but the
> point of the question is to think about what
> prepareWithInvocationTarget() does. How would you write that method
> in C#?
Well, it was a poorly stated question then. His primary presentation
asked how I'd write the code he posted, not the supporting
implementation details.
> In Objective-C, after you call -prepareWithInvocationTarget: on an
> NSUndoManager, it then accepts _any_ message call of any kind. It
> is completely and totally dynamic. It accepts messages from your
> application which weren't defined and didn't exist when the
> NSUndoManager class was compiled. The undo manager accepts the
> message, saves the target and method invocation with an arbitrary
> number of arguments and is able to re-invoke it later on the
> original target when the user asks you to Undo.
Thanks. That certainly makes the example more clear, and make more
sense.
That said, because of the existence of reflection in C# and Java,
similar functionality isn't really that difficult in those
languages. It's trivial to take any arbitrary class or instance of a
class and invoke any arbitrary named method with an arbitrary number
of arguments, immediately or later as necessary.
I would agree that in the light you've offered, the NSUndoManager
offers a somewhat more compelling use case than previous examples.
But it's not true that the C# or Java version would be significantly
different. They would be only slightly more verbose (though yes, I
admit...they would be more verbose, albeit slightly).
Pete -
On May 19, 2008, at 10:52 AM, David Wilson wrote:
> On Mon, May 19, 2008 at 1:33 PM, Peter Duniho <peted...>
> wrote:
>> Maybe I'm misinformed about how message-dispatching in Objective-C
>> works.
>> But AFAIK, it's nothing like the direct invocation and v-table
>> mechanisms
>> that exist in C# and Java. It's the exact opposite of "similar".
>
> You're misinformed about how message-dispatching in Objective-C works.
> It's very analogous to a v-table in c++ and related languages; I
> believe there's just a touch more run-time information stored in the
> table.
Well, "similar" and "analogous" and "touch more information" are all
kind of vague words, and we can disagree on wether they are analogous
or similar or not. I don't think the mechanisms are very similar at
all. To nail things down:
A v-table implementation means that the class of an object contains an
array of function pointers. A call to a method compiles down to "call
function #3". This means that both the caller and the callee both need
to know the mapping that virtual method foo() is the third item in the
v-table. Which means that the caller needs to be able to see all the
class information for the receiver and all superclasses of the
receiver to perform that mapping. Changing the order or number of
virtual methods in any superclass results in all code that calls
methods on that class needing to be recompiled because the v-table
indices change. The benefit is that at runtime this simple index
lookup then call is very fast.
Objective-C uses a method dispatch hash table. A method name is
converted to something called a selector at compile time, and that
selector is a unique one-to-one mapping to the method name. (So there
is a "foo" selector with some unique value and at runtime you can
convert the selector to the method name and vice versa.) The class of
an object contains a hash table that allows you to look up a function
pointer based on a selector. A call to a method compiles down to "look
up selector X in this object's hash table and call it". The linker
performs the uniquing of method names to selectors, so when compiling
the caller doesn't need to know anything at all about the class of the
receiver. The penalty to all this flexibility is that at runtime the
hash table lookup isn't quite as fast as the v-table simple index.
Hope this helps,
- Greg -
On May 19, 2008, at 11:00 AM, Peter Duniho wrote:
> That said, because of the existence of reflection in C# and Java,
> similar functionality isn't really that difficult in those
> languages. It's trivial to take any arbitrary class or instance of
> a class and invoke any arbitrary named method with an arbitrary
> number of arguments, immediately or later as necessary.
>
> I would agree that in the light you've offered, the NSUndoManager
> offers a somewhat more compelling use case than previous examples.
> But it's not true that the C# or Java version would be significantly
> different. They would be only slightly more verbose (though yes, I
> admit...they would be more verbose, albeit slightly).
Something directly like NSUndoManager simply can't be done reasonably
in Java. My knowledge of C# is not strong enough to make such a claim.
Java simply does not have a mechanism for "capture an arbitrary method
+ argument set". Any such proxy object in Java is going to have to
either be a subclass of the class being proxied OR the set of methods
+arguments to be captured would have to be defined in an interface.
Even with such a solution in place, the developer is still going to
have a lot of manual work ahead of them to provide all of the store-
and-forward mechanisms for each possible capturable method. And any
methods that are not to be captured are going to have to be
implemented as pass through.
Sure, you could go down that path, but it would be way way beyond
"slightly more verbose". It would be prohibitively more verbose.
Thus, I would expect that a solution in this space in Java would be to
use a completely different pattern better suited to the statically
bound nature of Java.
b.bum -
On May 19, 2008, at 11:00 AM, Peter Duniho wrote:
> On May 19, 2008, at 10:48 AM, Greg Titus wrote:
>
>> You've translated the Objective-C syntax into C# syntax, but the
>> point of the question is to think about what
>> prepareWithInvocationTarget() does. How would you write that method
>> in C#?
>
> Well, it was a poorly stated question then. His primary
> presentation asked how I'd write the code he posted, not the
> supporting implementation details.
I agree. It could have been stated a lot better.
>> In Objective-C, after you call -prepareWithInvocationTarget: on an
>> NSUndoManager, it then accepts _any_ message call of any kind. It
>> is completely and totally dynamic. It accepts messages from your
>> application which weren't defined and didn't exist when the
>> NSUndoManager class was compiled. The undo manager accepts the
>> message, saves the target and method invocation with an arbitrary
>> number of arguments and is able to re-invoke it later on the
>> original target when the user asks you to Undo.
>
> Thanks. That certainly makes the example more clear, and make more
> sense.
>
> That said, because of the existence of reflection in C# and Java,
> similar functionality isn't really that difficult in those
> languages. It's trivial to take any arbitrary class or instance of
> a class and invoke any arbitrary named method with an arbitrary
> number of arguments, immediately or later as necessary.
>
> I would agree that in the light you've offered, the NSUndoManager
> offers a somewhat more compelling use case than previous examples.
> But it's not true that the C# or Java version would be significantly
> different. They would be only slightly more verbose (though yes, I
> admit...they would be more verbose, albeit slightly).
I've worked in Java quite a bit in the past, and I disagree, but more
to the point: I've never done significant work in C# before, so if
that's an environment you are familiar with and you are willing, I'd
very much like to see what prepareWithInvocationTarget: would look
like in that language.
NSUndoManager's Objective-C implementation looks something like this:
// all we need to do here is save a pointer to the target object in
our instance variables temporarily
- (void)prepareWithInvocationTarget:(id)target
{
_target = target;
}
// this method is a part of the introspection done by the Obj-C
runtime on looking up info on what method to call, if we have a
target, act as if we are that target as far as the runtime is concerned
- (NSMethodSignature *)methodSignatureForSelector:(SEL)aSelector
{
if (_target)
return [_target methodSignatureForSelector:aSelector];
else
[super methodSignatureForSelector:aSelector];
}
// the Obj-C runtime calls this method when it doesn't find a pre-
existing defined method for a selector called upon you. The normal
behavior is to throw an exception. Here we'll just re-direct the
target of the message invocation back to our target, and save the
invocation in a list. Then nil out our temporary target variable.
- (void)forwardInvocation:(NSInvocation *)anInvocation
{
[anInvocation setTarget:_target];
[_undoStack addObject:anInvocation];
_target = nil;
}
// Call invoke on all the NSInvocation objects that we've saved.
They'll perform message calls on all their original targets.
- (void)undo
{
[_undoStack makeObjectsPerformSelector:@selector(invoke)];
}
Now in the real NSUndoManager there is a little more complication
because there are multiple steps of undo supported and so on, but this
is really all the code that you need to support a really powerful and
general concept.
Hope this helps,
- Greg -
On May 19, 2008, at 1:42 PM, Peter Duniho wrote:
> I agree with this statement. However, the conclusion is flawed.
You are welcome to your opinion, even if "flawed" ;)
Seriously, though, from some of your comments, I'm not sure that I
communicated my "conclusion" very well, because you seem to think I
was putting .Net down as somehow inferior to Cocoa. I tried to be
careful not to say that because I don't think it's true and even if I
did, it wouldn't have been relevant to the discussion that was going
on. I do like Cocoa better, which I readily admit, but the two
frameworks have different guiding principles and that causes each one
to have different strengths and weaknesses. I picked out one specific
weakness in the .Net approach because it seemed relevant to the
discussion at hand and because I hoped it might help people coming
from that background to adjust to a different way of learning and
understand WHY they were having a hard time learning. I wasn't saying
".Net is flawed, Cocoa is perfect" or anything of the sort, I just
didn't feel that a laundry list of shortcomings of the two frameworks
was relevant to the discussion at hand and wouldn't have helped to get
my point across. And my point was simply, "Cocoa is different", which
was in response to a lot of complaints on the list lately which seemed
to me motivated by people making judgments or having expectations
based on assumptions that aren't valid when dealing with Cocoa.
I originally started addressing your specific points, but after re-
reading my responses, I just don't think it's productive to argue the
mertis of the two environments here, so I deleted it. The two
frameworks are different, on that we can agree, I think. We both have
worked with both of them, you like one better, I like the other. I'm
not interested in proving to you that Cocoa is better, I'm only trying
to help people coming from .Net to Cocoa see that the differences
between the two go deeper than method and class names. There are
fundamental conceptual differences in the way they are built and
documented and clinging to what they know from one can be an obstacles
to learning the other. -
On May 19, 2008, at 12:27 PM, Jeff LaMarche wrote:
>
> On May 19, 2008, at 1:11 PM, Alex Kac wrote:
>
>> However I believe that 99% of the complaints given - including mine
>> - are due to that really high hill.
>
> I do not disagree with you there. It's a challenge, and frustrating
> at times, and once you reach the peak and start down the other side,
> you very quickly forget how hard it was :)
I know that feeling very well. My feedback is aimed solely at being
able to provide a viewpoint to Apple about how they could help new
developers get past that high hill. I really feel they could do it.
>> Now imagine you have little time to climb that hill every day. It
>> takes a long time and you get tired of fighting up that hill.
>> That's where I think Apple can do some work. Books like Erics and
>> Aaron's help immensely. Honestly the best dev books I ever read
>> were Inside Macintosh. Why can't we have an Inside Cocoa book?
>
>
> Believe me, I can imagine that: I learned Cocoa in my spare time at
> a point in my life where I had very little spare time. If you have
> less time to spend per day, it's going to take more days to get to
> the top of the hill. That's a truism, and I'm not sure that it can
> be changed all that much by better documentation.
I think it can be. I'm not saying that all the docs have to be, but I
think a "Cocoa 1" and "Cocoa 2" and so on set of docs would be very
helpful. It can start out a lot like Hillegass's books and move on
quickly to a reference/sample code mixture much like IM had. That
would help immensely. Sometimes the fact that the docs are so
volumnuous and *seemingly* unorganized to the untrained eye is the
biggest docs issue.
>
>
> As for "Inside Cocoa", I'm not sure it's an entirely fair example.
> The documentation problem is an order of magnitude more complex than
> it was in the days of the classic Mac Toolbox.
>
> But I would argue that the various "Guides" combined with the API
> references (and maybe the sample code as well) really ARE the same
> thing as the old Inside Macintosh, there's just an awful lot more of
> it (and there's no Pascal to be found anywhere). I would guess if
> you took all the "Guides" from the dev website, it would constitute
> tens of thousands of pages, or at least far more than all seven
> volumes of the original IM. I think the problem is more organization
> and volume.
OK - so lets have at least the basic AppKit in there for an Inside
Cocoa. If I can buy .NET and Win32 or even Java framework books that
are like IM why not something for Cocoa?
>
>
> Are you going to WWDC, by any chance? That's a huge opportunity to
> move forward more quickly.
Yes. I will be there. Primarily for iPhone work. And that, btw, makes
all this so much harder. I can't ask questions about any of it. MS
always has private lists for beta NDA SDKs.
--
Alex Kac - President and Founder
Web Information Solutions, Inc. - Central Texas Microsoft Certified
Partner -
Am 19.05.2008 um 13:11 Uhr schrieb Peter Duniho:
> I just don't see how declaring an interface and then using it is so
> inferior to an informal protocol that it justifies the entire
> message-dispatching paradigm, especially given that there are in
> fact advantages to the former. At best, it's a wash.
This is (part of) a method that handles an AppleScript command send to
the application.
One possible argument is the color to be used for display:
- (id)handleDisplayCommand:(NSScriptCommand *)command
{
NSDictionary *args = [command evaluatedArguments];
NSString *colorName = [args objectForKey:@"color"];
NSColor *color;
...
if (colorName) {
SEL colorSelector = NSSelectorFromString([colorName
stringByAppendingString:@"Color"]);
if ([[NSColor class] respondsToSelector:colorSelector]) {
color = objc_msgSend([NSColor class], colorSelector);
}
}
...
}
This way you may use any color name that NSColor supports.
You can even just add colors by declaring a category on NSColor and
adding the appropriate method.
No changes required in the code above.
I don't have much experience in C++, Java or C#, so I can't comment on
those. But I *do* know, that I like it very much that I'm able to do
things like that above.
Andreas -
On May 19, 2008, at 11:21 AM, Greg Titus wrote:
> [...]
> I've worked in Java quite a bit in the past, and I disagree, but
> more to the point: I've never done significant work in C# before,
> so if that's an environment you are familiar with and you are
> willing, I'd very much like to see what
> prepareWithInvocationTarget: would look like in that language.
First, I'll address some other observations about the code I posted:
yes, I was simply showing what the equivalent syntax would be. .NET
doesn't have an NSUndoManager per se, with identical semantics to
Cocoa's. Without a clear question, I really didn't know what it was
Michael was proposing I write so I answered as best I could at the time.
And yes, for it to work exactly as I wrote my response, in C# you
would have to have your NSUndoManager compiled for a specific class,
so that it had the appropriate overloads for how it would be used.
However, _with_ reflection we can do much of the same kinds of things
that Obj-C does, without knowing in advance the classes that might
use the NSUndoManager class.
One advantage I see in Cocoa is that, because classes may respond to
selectors that they didn't even declare, NSUndoManager can simply set
a temporary variable, and then catch a selector to be saved away for
later invocation. This makes the reflection aspect ("introspection"
in Objective-C) more transparent.
An approach in C# that is still reasonably close to the Obj-C version
would be to instead pass a method name and an array of arguments (so,
the syntax isn't identical, but comparable):
undoManager.prepareWithInvocationTarget(this, "setColor", object
[] { mColor });
Then the method would look something like this (warning: email code,
uncompiled, untested):
void prepareWithInvocationTarget(object target, string name,
object[] args)
{
Type[] argTypes = new Type[args.Length];
MethodInfo targetMethod;
for (int iarg = 0; iarg < args.Length; iarg++)
{
argTypes[iarg] = args[iarg].GetType();
}
targetMethod = target.GetType().GetMethod(name, argTypes);
// save targetMethod and args in an appropriate data
structure for
// later retrieval and invocation
// ...code omitted for brevity
}
In reality, I would (and have) more likely implement an undo manager
that uses anonymous methods. Then all you're saving to your undo
state is a delegate that does what you want (assumes the "property"
semantic I posted):
undoManager.AddUndo(delegate { color = mColor; });
This is more idiomatic in C# and wouldn't need all that messy
reflection stuff. Executing the undo is a simple matter of invoking
the delegate that was passed, a simple one-line operation that reads
like a method call (note that the use of the name "delegate" is very
different in C# than in Cocoa...C# "delegate" is more like a function
pointer than an actual object to which some selector has been
delegated).
I don't understand the comments saying that you can't do something
similar in Java. Java has the same kind of reflection features that
C# has. The anonymous method approach wouldn't work, as Java doesn't
have anything equivalent to C# delegates, but Java does have
interfaces and using those with anonymous types in lieu of anonymous
methods is a common Java idiom that works well.
Pete -
On Mon, May 19, 2008 at 1:33 PM, Peter Duniho <peted...> wrote:
Well, I'm still waiting for someone to show me how that flexibility is used.
I'll take that challenge. :-)
The flexibility of the Objective-C language & runtime allow me to intercept
messages sent in either direction, and route them through a "bridge"
function that translates them to a foreign language. In this case, the
language is Perl, but I don't intend to brag here - as I understand it, the
Ruby and Python bridges have similar capabilities.
Because Perl is dynamic, I can create a "default" method that intercepts any
unknown messages. This Perl method passes the class and method names as
string arguments, and that's exactly what the runtime functions take. Once
I've queried the runtime to find the correct Class and Sel structures to
use, and a description of arguments and return types, the rest is a SMOP -
using libffi to build a stack frame and make the call to the message
dispatch function.
A similar process happens in reverse. Perl classes can be registered with
the Objective-C runtime. The IMP (implementation function) for any method
that's implemented in Perl is the same - a single dispatch method I've
written that examines the "self" and "_sel" arguments, and dispatches the
call to the appropriate Perl method.
Because both Perl and Objective-C are dynamic, I wrote a single "bridge"
function for each direction, and that's all I needed to write to support
calling any method on any class, whether it's known at compile time or not.
That's the easy stuff. :-)
You can also create an Objective-C subclass of a Perl super class. You'll
need to create a header with an @interface for the Perl class, and you'll
get a warning when compiling it because there's no @implementation available
at compile time. But, if your subclass is defined in a bundle and loaded
dynamically after the Perl superclass has been compiled and registered with
the runtime, the runtime sorts out the inheritance correctly when the
subclass is loaded - because the superclass is registered dynamically, by
name.
As I understand it, the Python bridge (and maybe others) has an "injector"
feature that allows you to inject a Python interpreter and command console
into any Cocoa app, while the app is running, whether the app was built with
them not. Since everything is dynamic, you can look around and manipulate
objects and properties by name. In essence, you can add a plugin interface
to an app - whether it wants one or not. :-)
Note that I'm not trying to say these kinds of things *can't* be done in C++
or Java. I'm just saying that, to support things like the ability to refer
to random (possibly unknown) methods and properties, by name, would require
a lot more work to implement in C++ or Java.
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net -
Am 19.05.2008 um 13:11 Uhr schrieb Peter Duniho:
> I just don't see how declaring an interface and then using it is so
> inferior to an informal protocol that it justifies the entire
> message-dispatching paradigm, especially given that there are in
> fact advantages to the former. At best, it's a wash.
I'm so used to the Objective-C/Smalltalk way that I admit I haven't
thought this through, but two things come to mind:
* Objective-C allows you to create categories, effectively modifying
a class's interface at runtime. This is handy for adding methods that
more naturally belong to an existing class rather than as, for
example, static methods in a utility class: [myString endsWithAVowel]
rather than [MyStringUtils stringEndsWithAVowel:myString]. Categories
also allow you to add a behavior to an internal node in a class
hierarchy, and thus to that class's existing and future descendants --
an annoying problem to solve when the only way you have of modifying a
class is by subclassing.
* Interface Builder is sometimes given as an example of an app that
would be more difficult to write in, say, Java. I haven't thought
through exactly how I would write it in Java, so I'm not prepared to
argue this case just yet. I suspect I would have to do it by
bypassing some of the very protections that Java gives me.
--Andy -
On Mon, May 19, 2008 at 6:03 AM, Peter Duniho <peted...> wrote:
> And as long as you guys keep insisting that there's nothing wrong with the
> environment, and that people "just need to get used to it" and "then they'll
> love it", you're not going to get the kind of developer excitement needed to
> ensure the kind of developer support required to get the Mac really into the
> mainstream. At a minimum, market growth is going to happen a LOT more
> slowly than it could otherwise.
I don't see that as a particularly bad thing. I don't want to see my
platform of choice suddenly awash with apps written by people who
don't want to take the time to understand the whole picture. I'm
pretty sure such apps would be less likely to conform to the HIG, and
less likely to have been properly profiled for performance.
Hamish -
On May 19, 2008, at 12:51 PM, Andy Lee wrote:
> * Interface Builder is sometimes given as an example of an app
> that would be more difficult to write in, say, Java.
It's not - I did this in a past life, with Control-drag to form
connections, "nib" archive files and all that.
Best,
__jayson
Circus Ponies NoteBook - Organization for a Creative Mind
www.circusponies.com -
> Date: Mon, 19 May 2008 20:31:02 +0200
> From: Andreas Mayer <andreas...>
>
> This is (part of) a method that handles an AppleScript command send to
> the application.
> One possible argument is the color to be used for display:
>
> - (id)handleDisplayCommand:(NSScriptCommand *)command
> {
> NSDictionary *args = [command evaluatedArguments];
> NSString *colorName = [args objectForKey:@"color"];
> NSColor *color;
>
> ...
>
> if (colorName) {
> SEL colorSelector = NSSelectorFromString([colorName
> stringByAppendingString:@"Color"]);
> if ([[NSColor class] respondsToSelector:colorSelector]) {
> color = objc_msgSend([NSColor class], colorSelector);
> }
> }
>
> ...
> }
>
> This way you may use any color name that NSColor supports.
In .NET, you'd just call Color.FromName().
More generally, as before, any code that is simply checking
"respondsToSelector" and then calling the specific selector, that can
easily be implemented in C# or Java using reflection (assuming
there's not a better, more idiomatic approach in those languages, as
often there would be). And situations when one would need this are
generally far and few between (i.e. not common enough to dictate an
entire language paradigm), especially when a class has the foresight
to implement that kind of functionality already.
I appreciate the example. It's certainly reasonably elegant and to
the point, and it's more "real world" than some of the other ones
(bridging Cocoa to another language? yeah, right...a) it's not like
you can't interface between languages with other languages, and b)
this is not the kind of thing one is going to see in general
application code). But not the sort of compelling "we really need
the language to be this way otherwise it just doesn't work" example I
was hoping for.
Thanks,
Pete -
On May 19, 2008, at 4:29 PM, Jayson Adams wrote:
> On May 19, 2008, at 12:51 PM, Andy Lee wrote:
>
>> * Interface Builder is sometimes given as an example of an app
>> that would be more difficult to write in, say, Java.
>
> It's not - I did this in a past life, with Control-drag to form
> connections, "nib" archive files and all that.
Oh. It was probably C++ then.
--Andy -
Le 19 mai 08 à 22:36, Peter Duniho a écrit :
>> Date: Mon, 19 May 2008 20:31:02 +0200
>> From: Andreas Mayer <andreas...>
>>
>> This is (part of) a method that handles an AppleScript command send
>> to
>> the application.
>> One possible argument is the color to be used for display:
>>
>> - (id)handleDisplayCommand:(NSScriptCommand *)command
>> {
>> NSDictionary *args = [command evaluatedArguments];
>> NSString *colorName = [args objectForKey:@"color"];
>> NSColor *color;
>>
>> ...
>>
>> if (colorName) {
>> SEL colorSelector = NSSelectorFromString([colorName
>> stringByAppendingString:@"Color"]);
>> if ([[NSColor class] respondsToSelector:colorSelector]) {
>> color = objc_msgSend([NSColor class], colorSelector);
>> }
>> }
>>
>> ...
>> }
>>
>> This way you may use any color name that NSColor supports.
>
> In .NET, you'd just call Color.FromName().
>
> More generally, as before, any code that is simply checking
> "respondsToSelector" and then calling the specific selector, that
> can easily be implemented in C# or Java using reflection (assuming
> there's not a better, more idiomatic approach in those languages, as
> often there would be). And situations when one would need this are
> generally far and few between (i.e. not common enough to dictate an
> entire language paradigm), especially when a class has the foresight
> to implement that kind of functionality already.
>
> I appreciate the example. It's certainly reasonably elegant and to
> the point, and it's more "real world" than some of the other ones
> (bridging Cocoa to another language? yeah, right...a) it's not like
> you can't interface between languages with other languages, and b)
> this is not the kind of thing one is going to see in general
> application code). But not the sort of compelling "we really need
> the language to be this way otherwise it just doesn't work" example
> I was hoping for.
See NSDistributedObject and more generaly NSProxy for example. -
On May 19, 2008, at 12:08 PM, Peter Duniho wrote:
[...]
> However, _with_ reflection we can do much of the same kinds of
> things that Obj-C does, without knowing in advance the classes that
> might use the NSUndoManager class.
>
> One advantage I see in Cocoa is that, because classes may respond to
> selectors that they didn't even declare, NSUndoManager can simply
> set a temporary variable, and then catch a selector to be saved away
> for later invocation. This makes the reflection aspect
> ("introspection" in Objective-C) more transparent.
Right. I'm glad you see that. Another place to look for the same type
of thing is Distributed Objects in Obj-C. It's another piece of the
frameworks that use the ability to catch invocations "in flight". In
that case, in order to serialize the method and arguments, send the
data across the network or between threads, unserialize on the other
side, and invoke in that other machine/process/thread.
> An approach in C# that is still reasonably close to the Obj-C
> version would be to instead pass a method name and an array of
> arguments (so, the syntax isn't identical, but comparable):
>
> undoManager.prepareWithInvocationTarget(this, "setColor",
> object[] { mColor });
>
> Then the method would look something like this (warning: email code,
> uncompiled, untested):
>
> void prepareWithInvocationTarget(object target, string name,
> object[] args)
> {
> Type[] argTypes = new Type[args.Length];
> MethodInfo targetMethod;
>
> for (int iarg = 0; iarg < args.Length; iarg++)
> {
> argTypes[iarg] = args[iarg].GetType();
> }
>
> targetMethod = target.GetType().GetMethod(name, argTypes);
>
> // save targetMethod and args in an appropriate data
> structure for
> // later retrieval and invocation
> // ...code omitted for brevity
> }
Thanks very much for the example. The same sort of facility (getting
method from name) is available in Objective-C, of course, and Andreas
Mayer replied on the list an interesting example of how he uses that
in AppleScript handling. What C# seems to be missing is the reverse
facility (going from a compiled method call back out to name +
arguments), which my sample NSUndoManager code demonstrated.
Interestingly, given your earlier remarks about the desirability of
compile time checking, in Objective-C [[undoManager
prepareWithInvocationTarget:self] setColor:mColor] is type checked.
The compiler knows about the -setColor: method declaration it has seen
and can check that mColor is an appropriate type. (Because Obj-C still
lets you call any method on any object the result of bad typing here
will be a warning rather than an error, but Obj-C programmers
generally learn to pay attention to and fix all warnings.) Whereas I
suspect that when you are using the reflection facilities in C# in the
way you are above, that there is no type checking being performed. Is
that correct?
That is one of the advantages of having the dynamism built into the
language runtime rather than a reflection API built on top. Another
advantage is that code can be written that doesn't need to know
whether reflection is being used or not. In the Distributed Objects
case, for instance, it is very common to pass around proxies as
arguments to code that doesn't have any idea that the methods it is
calling on those argument objects actually get forwarded somewhere
else entirely.
> In reality, I would (and have) more likely implement an undo manager
> that uses anonymous methods. Then all you're saving to your undo
> state is a delegate that does what you want (assumes the "property"
> semantic I posted):
>
> undoManager.AddUndo(delegate { color = mColor; });
>
> This is more idiomatic in C# and wouldn't need all that messy
> reflection stuff. Executing the undo is a simple matter of invoking
> the delegate that was passed, a simple one-line operation that reads
> like a method call (note that the use of the name "delegate" is very
> different in C# than in Cocoa...C# "delegate" is more like a
> function pointer than an actual object to which some selector has
> been delegated).
Like I said earlier, I don't know C#, but this doesn't appear to me
what the code would actually look like. The trouble is that the whole
point is we want to be able to undo a previous -setColor: call. If
mColor is a reference to the "this" object's current color, then at
the time that the undo happens, the value of the reference "mColor"
will be the _new_ color, not the old color that we want to restore. So
that line of code will just set it to itself. What is needed is to
store the mColor value as it is at the time the anonymous delegate is
created, not at the time the delegate is executed. Is it possible for
an anonymous method to have its own instance variables (in this case,
to store the old color)? From looking at the docs it doesn't appear
to. Nor does it seem possible to do so with named method delegates.
> I don't understand the comments saying that you can't do something
> similar in Java. Java has the same kind of reflection features that
> C# has. The anonymous method approach wouldn't work, as Java
> doesn't have anything equivalent to C# delegates, but Java does have
> interfaces and using those with anonymous types in lieu of anonymous
> methods is a common Java idiom that works well.
Only with fixed signatures, though. If you wanted to undo (made up
example): -setColor:inPattern:atPatternOffset:withAlpha:... then you
better hope that your interface includes some similar signature. There
are significant flexibility limitations to that approach.
- Greg -
On May 19, 2008, at 3:36 PM, Peter Duniho wrote:
> I appreciate the example. It's certainly reasonably elegant and to
> the point, and it's more "real world" than some of the other ones
> (bridging Cocoa to another language? yeah, right...a) it's not like
> you can't interface between languages with other languages, and b)
> this is not the kind of thing one is going to see in general
> application code). But not the sort of compelling "we really need
> the language to be this way otherwise it just doesn't work" example
> I was hoping for.
You mean the "Cocoa is the only One True Language, and this is why you
MUST use it" example?
Come on, obviously you can do anything you want to do with any of the
languages that have been mentioned. I think you may be expecting too
much from Cocoa & Obj-C. It's just a framework and language. It's one
that I think offers lots of helpful time-savers, and to me, looks
prettier and is easier to interpret than others. But that's a personal
call. If you really hate it, don't use it. I certainly don't use C++
or any of its derivatives like Java and C#.
However, if you want to develop for the Mac or iPhone, your best bet
is to learn Cocoa & Obj-C. I really don't think it's that difficult,
and I think Apple has made it pretty easy for you. If you're going to
sink your teeth into a new environment, you should expect a few
growing pains, such as figuring out clipping paths (which really
aren't tricky at all once you see how they work -- and Apple does
provide example code).
When I'm coding, I have at least three apps open -- Xcode, Firefox and
TextWrangler. If I need to remember the methods available in a class,
I switch to FF and Google the class within Apple's site. If I still
need clarification, I switch to TextWrangler and do a multi-file
search (I like TW's multi-search a little bit better than Xcode's, and
it helps me keep my search separate from my Xcode windows) for the
method or class in my /Developer/Examples/ directory. 99% of the time,
there is an example in Examples that does something close to what I'm
trying to do, and the search helps me find those exact lines of code.
I often do this sequence even on methods/classes I've used many times
before, because it reminds me of all the details, and sometimes
reminds me of an alternate method/class that is actually a better fit.
Anyway, that's my last word on this. I've used this thread as
procrastination from real work for too long already. :)
- ben -
Le 19 mai 08 à 22:36, Peter Duniho a écrit :
>> Date: Mon, 19 May 2008 20:31:02 +0200
>> From: Andreas Mayer <andreas...>
>>
>> This is (part of) a method that handles an AppleScript command send
>> to
>> the application.
>> One possible argument is the color to be used for display:
>>
>> - (id)handleDisplayCommand:(NSScriptCommand *)command
>> {
>> NSDictionary *args = [command evaluatedArguments];
>> NSString *colorName = [args objectForKey:@"color"];
>> NSColor *color;
>>
>> ...
>>
>> if (colorName) {
>> SEL colorSelector = NSSelectorFromString([colorName
>> stringByAppendingString:@"Color"]);
>> if ([[NSColor class] respondsToSelector:colorSelector]) {
>> color = objc_msgSend([NSColor class], colorSelector);
>> }
>> }
>>
>> ...
>> }
>>
>> This way you may use any color name that NSColor supports.
>
> In .NET, you'd just call Color.FromName().
>
> More generally, as before, any code that is simply checking
> "respondsToSelector" and then calling the specific selector, that
> can easily be implemented in C# or Java using reflection (assuming
> there's not a better, more idiomatic approach in those languages, as
> often there would be). And situations when one would need this are
> generally far and few between (i.e. not common enough to dictate an
> entire language paradigm), especially when a class has the foresight
> to implement that kind of functionality already.
>
> I appreciate the example. It's certainly reasonably elegant and to
> the point, and it's more "real world" than some of the other ones
> (bridging Cocoa to another language? yeah, right...a) it's not like
> you can't interface between languages with other languages, and b)
> this is not the kind of thing one is going to see in general
> application code). But not the sort of compelling "we really need
> the language to be this way otherwise it just doesn't work" example
> I was hoping for.
>
> Thanks,
> Pete
And as we are here, note also that Key-Value-Coding uses dynamic
properties of the language.
OK, implementing valueForKey: and setValue:forKey: is probably easy
using introspection.
So now, have a look at KVO and bindings. You can add an observer to
any model object (even to object that was compile before KVO was
implemented) and when any accessor is call on this model object, the
observer will receive a notification.
How it works ? Easy, when you register an observer, the Cocoa
framework dynamically create a proxy class, and dynamically change the
type of your model object into this proxy class, so any call perform
on your model will now be caugth by this proxy. Note that the runtime
does not create a new instance, it really change the type of the
instance you're using (that's dynamic typing). -
On May 19, 2008, at 4:36 PM, Peter Duniho wrote:
> But not the sort of compelling "we really need the language to be
> this way otherwise it just doesn't work" example I was hoping for.
I wonder -- just thinking out loud now -- if this standard is too high
for Objective-C to meet. I also wonder if the question couldn't be
turned around.
Objective-C is a combination of C and Smalltalk -- two very permissive
languages with particular philosophies, both successful in their own
ways. It would have required a conscious design decision to add
stricter compile-time checking. I would ask whether that extra
strictness is so compelling that "otherwise it just [wouldn't] work"
-- basically a variation of this question:
<http://www.mindview.net/WebLog/log-0025>
> This became a puzzle to me: if strong static type checking is so
> important, why are people able to build big, complex Python programs
> (with much shorter time and effort than the strong static
> counterparts) without the disaster that I was so sure would ensue?
A *lot* of robust and successful software, commercial and otherwise,
has been written and lovingly maintained in Objective-C, so clearly at
some level it does work. Could the same have happened if NeXT had
never existed and Apple had bought the C++-based Be instead? Maybe,
which is why I hesitate to argue that the Objective-C way is "better."
--Andy -
On May 19, 2008, at 2:05 PM, Greg Titus wrote:
> On May 19, 2008, at 12:08 PM, Peter Duniho wrote:
> [...]
>> However, _with_ reflection we can do much of the same kinds of
>> things that Obj-C does, without knowing in advance the classes
>> that might use the NSUndoManager class.
>>
>> One advantage I see in Cocoa is that, because classes may respond
>> to selectors that they didn't even declare, NSUndoManager can
>> simply set a temporary variable, and then catch a selector to be
>> saved away for later invocation. This makes the reflection aspect
>> ("introspection" in Objective-C) more transparent.
>
> Right. I'm glad you see that. Another place to look for the same
> type of thing is Distributed Objects in Obj-C. It's another piece
> of the frameworks that use the ability to catch invocations "in
> flight". In that case, in order to serialize the method and
> arguments, send the data across the network or between threads,
> unserialize on the other side, and invoke in that other machine/
> process/thread.
Well, except that this would generally be implemented by the
framework, no?
In .NET, it supports remote invocations, and this uses (in part)
reflection, but the application writer never needs to know the gory
details. I agree that reflection is slightly more awkward than
what's been presented in terms of Objective-C's message paradigm, and
I accept that as a benefit for the authors of the framework. But the
end-user doesn't need any of this, or even need to care how it's
implemented. Imposing a particular language on the end-user in order
to support the framework author doesn't seem compelling to me.
> Thanks very much for the example. The same sort of facility
> (getting method from name) is available in Objective-C, of course,
> and Andreas Mayer replied on the list an interesting example of how
> he uses that in AppleScript handling. What C# seems to be missing
> is the reverse facility (going from a compiled method call back out
> to name + arguments), which my sample NSUndoManager code demonstrated.
Well, I didn't show the invocation code because it's trivial. You
just use the MethodInfo object along with the target instance and the
saved parameters to call the MethodInfo.Invoke() method.
> Interestingly, given your earlier remarks about the desirability of
> compile time checking, in Objective-C [[undoManager
> prepareWithInvocationTarget:self] setColor:mColor] is type checked.
> The compiler knows about the -setColor: method declaration it has
> seen and can check that mColor is an appropriate type.
With reflection, you can have type checking, though it's more
explicit. With the anonymous method (as I said, more idiomatic in C#
anyway), type checking is implicit.
> (Because Obj-C still lets you call any method on any object the
> result of bad typing here will be a warning rather than an error,
> but Obj-C programmers generally learn to pay attention to and fix
> all warnings.) Whereas I suspect that when you are using the
> reflection facilities in C# in the way you are above, that there is
> no type checking being performed. Is that correct?
There's no compile-time type checking with reflection, that's correct
(though you can certainly include run-time type checking if you want
to ensure your program doesn't blow up :) ). That's certainly one
reason to avoid reflection if it's not necessary (and it wouldn't be
in this particular example...I offered the reflection example as a
way of illustrating the more general point).
The fact is, often there are better alternatives to reflection in
C#. I simply presented reflection as a "closest match" to the
specific Objective-C functionality being shown.
> That is one of the advantages of having the dynamism built into the
> language runtime rather than a reflection API built on top. Another
> advantage is that code can be written that doesn't need to know
> whether reflection is being used or not. In the Distributed Objects
> case, for instance, it is very common to pass around proxies as
> arguments to code that doesn't have any idea that the methods it is
> calling on those argument objects actually get forwarded somewhere
> else entirely.
I haven't had time to look at the Distributed Objects example.
However, I suspect that there are equivalent idioms in C#/.NET that
don't require the end-user (that is, the application writer) to know
about reflection. The reflection aspect would be "under the hood".
>> In reality, I would (and have) more likely implement an undo
>> manager that uses anonymous methods. Then all you're saving to
>> your undo state is a delegate that does what you want (assumes the
>> "property" semantic I posted):
>>
>> undoManager.AddUndo(delegate { color = mColor; });
>>
>> This is more idiomatic in C# and wouldn't need all that messy
>> reflection stuff. Executing the undo is a simple matter of
>> invoking the delegate that was passed, a simple one-line operation
>> that reads like a method call (note that the use of the name
>> "delegate" is very different in C# than in Cocoa...C# "delegate"
>> is more like a function pointer than an actual object to which
>> some selector has been delegated).
>
> Like I said earlier, I don't know C#, but this doesn't appear to me
> what the code would actually look like. The trouble is that the
> whole point is we want to be able to undo a previous -setColor:
> call. If mColor is a reference to the "this" object's current
> color, then at the time that the undo happens, the value of the
> reference "mColor" will be the _new_ color, not the old color that
> we want to restore.
Sorry, you're right. Typo on my part. The actual code would look
like this:
NSColor colorPrev = color;
undoManager.AddUndo(delegate { color = colorPrev; });
The local variable "colorPrev" would be "captured" and stored as part
of the anonymous method. For a given instance of the anonymous
method, it will have the value exactly as it was at the moment that
the anonymous method was created (i.e. at the time that AddUndo() was
called).
> So that line of code will just set it to itself. What is needed is
> to store the mColor value as it is at the time the anonymous
> delegate is created, not at the time the delegate is executed. Is
> it possible for an anonymous method to have its own instance
> variables (in this case, to store the old color)?
Captured variables are essentially instance variables for the
anonymous method.
> From looking at the docs it doesn't appear to. Nor does it seem
> possible to do so with named method delegates.
>
>> I don't understand the comments saying that you can't do something
>> similar in Java. Java has the same kind of reflection features
>> that C# has. The anonymous method approach wouldn't work, as Java
>> doesn't have anything equivalent to C# delegates, but Java does
>> have interfaces and using those with anonymous types in lieu of
>> anonymous methods is a common Java idiom that works well.
>
> Only with fixed signatures, though.
Not really. Using an anonymous type in Java in lieu of an anonymous
method in C#, you can use local variables (declared "final") in a
similar fashion as that used to capture variables in C#. So you'd
just need a single interface, and then reference the necessary local
variable data from within an anonymous type implementing that interface.
I've yet to run into anything in Java where I could have used an
anonymous method in C#, but couldn't get an anonymous type to work in
a similar fashion in Java. I find the anonymous method syntax more
elegant, but the Java approach is workable and generally feature-
identical.
Pete -
On May 19, 2008, at 2:20 PM, Jean-Daniel Dupas wrote:
> And as we are here, note also that Key-Value-Coding uses dynamic
> properties of the language.
Yes, it does.
> OK, implementing valueForKey: and setValue:forKey: is probably easy
> using introspection.
Likewise reflection. And in .NET, the same kind of binding
functionality is fully supported. The basic version uses something
like KVC, but with reflection to grab the property and associated
event. I don't use .NET binding very much, but I know there's also a
more strongly-typed version of binding that doesn't rely on naming
conventions or reflection.
> So now, have a look at KVO and bindings. You can add an observer to
> any model object (even to object that was compile before KVO was
> implemented) and when any accessor is call on this model object,
> the observer will receive a notification.
Likewise .NET. Most bindable objects implement the appropriate
"PropertyChanged" event for notification, but of course an object
that only has the property can go through a notifier proxy that
handles the same work.
So, in this case, the .NET fallback is more like Cocoa's standard
approach, while the more typical case has more direct support
straight from the object itself.
Again, there are subtle differences, but the two environments offer
basically the same behavior with very little difference to the end-
user writing the code.
Pete -
This is not a helpful attitude to take when this discussion is going
so well.
Please, either be helpful or don't take part.
scott
moderator
On May 18, 2008, at 4:38 PM, P Teeson wrote:
> begin rant:
>
> Oh me oh my the poor newcomers to Cocoa. Sorry folks back in the
> days of 360 mainframes there were manuals and they were inscrutable.
> But if you took the Winston Churchill aproach and spent some blood,
> sweat, toil and tears you would probably become a 1/2 decent
> assembler language programmer.
>
> Same with Obj- C - if you know C you can grok Obj-C in at most a
> week - less if you are experienced. You won't be a master of it for
> a year or so of serious programming.
> But that's true of acquiring literacy in any field.
>
> Finally in this spoon fed age of sound bytes and simplistic and
> thoughtless political and economic panacea's in a world far more
> complex that when I grew up (70 years ago)
> you newbies to Cocoa need to do what the docs provide you with.
>
> RTFM! and sweat it out. Or else take the blue pill! Sheesh they all
> want pay for no work!
>
> rant ends:
> On 18-May-08, at 1:56 PM, Michael Vannorsdel wrote:
>
>> Well what can you do. Not sure why but lately many newcomers have
>> been showing up and complaining about Cocoa's difficulty. I'm not
>> sure if they've done GUI work before, but I remember my days with
>> PowerPlant and spending a massive amount of time just creating the
>> GUI and the code to back it. Perhaps this is what gave me the
>> sense of how much time Cocoa saves. It's easy to take things like
>> webviews for granted. I can guess the amount of code Apple wrote
>> to back those to work out of the box is pretty massive and
>> complicated.
>>
>> If programming was just drag and drop and clicking some option
>> boxes users could just write their own programs. But the fact is
>> programming is far more complicated than that (and probably will be
>> for a long time) and making such a framework would take a decade or
>> more, by which time it would be obsolete and outdated.
>>
>> For professionals the GUI is a smaller part of development thanks
>> to time saved by Cocoa. If I have to write my own controls from
>> scratch, I will as it's what programmers do, write code. But I'm
>> thankful 99% of the time I can use something from Cocoa that comes
>> with much of the code already done for me.
>>
>> I guess some people are upset Cocoa doesn't do enough, or all, of
>> the work for them. I'm more of the people happy Cocoa does any
>> work for me at all. If it saves me time, it's a good thing.
>>
>>
>> On May 18, 2008, at 10:41 AM, Jens Alfke wrote:
>>
>>> "Hobbyists"? I think "professionals" is more accurate — especially
>>> since in the early days of the Mac you had to spend hundreds of
>>> dollars to become a developer and get access to tools and
>>> documentation.
>>>
>>> I can see your point about obsessive hackers having the stamina to
>>> overcome complicated APIs, but any platform vendor's main
>>> objective in developer tools is to target professional developers
>>> who will create the products that make the platform attractive to
>>> customers. "Professional" doesn't necessarily imply a big company;
>>> I refer equally to startups and indie outfits, anyone seriously
>>> devoted to creating a product.
>>>
>>> In Apple's defense, the task of implementing a sophisticated GUI
>>> on such limited computers was extremely difficult. The top goals
>>> were usability, decent performance, and affordable price. That
>>> left no leeway for making the APIs themselves easy to use — the
>>> niceties we take for granted like object-oriented programming
>>> would have used up way too much of that 128k of RAM and 64k of ROM.
>>>
>>> (Yes, some of the first GUIs were written in the first OOP
>>> language, Smalltalk. But the Xerox computers that ran Smalltalk-80
>>> cost $10,000 or more; the ones that ran it with any kind of decent
>>> performance (the "Dorado") cost $50,000 and were basically
>>> supercomputers. They all had ten times as much RAM as the first
>>> Mac, and had custom CPUs with programmable microcode optimized for
>>> Smalltalk. Even so, performance was much worse than the original
>>> Mac, and the GUI was much cruder and harder to use. I'd already
>>> been using Smalltalk-80 when the first Mac came out, and the Mac's
>>> speed and aesthetics were just jaw-dropping.)
>>>
>>> Anyway.
>>>
>>> I have to say I find this whole discussion frustrating. The
>>> attitude of some people seems to be that writing computer
>>> programs, of arbitrary complexity, should be as easy as using a
>>> word processor. That's a Utopian goal at best, and more generally
>>> just naïve. Of course we should be trying to make the APIs and
>>> tools and documentation more useable; that's a constant task, and
>>> a very difficult one, and one Apple's doing a good job at. (The
>>> complexity under the hood is terrifying, and it's already been
>>> covered up enough that in an hour an experienced developer can
>>> throw together an app that fifteen years ago would have sold for
>>> $100.)
>>>
>>> Face it, any sort of serious creative endeavor is hard! There's no
>>> way around it. And the hardest part is learning the techniques and
>>> tools. If you wanted to build a robot, play Vivaldi on the violin,
>>> design a house, paint landscapes, or cure Ebola, you'd have to
>>> accept that it would take months or years of serious study, that
>>> the tools and documentation would sometimes be hard to use, and
>>> you'd have to put up with frustration before you mastered the
>>> skills.
>>>
>>> Why on earth is writing the best GUI applications in the world
>>> supposed to be trivial by comparison? Maybe I'm taking this too
>>> personally, but I sense a subtext that some people think the task
>>> of software design itself is somewhat trivial, more like
>>> programming a VCR than like architecture or painting or chemistry.
-
> Date: Mon, 19 May 2008 15:51:07 -0400
> From: Andy Lee <aglee...>
>
> * Objective-C allows you to create categories, effectively modifying
> a class's interface at runtime.
C# provides "partial" class implementations for when you want to
split functionality across multiple module files (one use of
categories). When doing this, you have complete access to the
class's private and protected members, and the implementation is
truly part of the class.
When you are accessing only the public API for a class, C#'s
extension methods provide the same sort of syntax, but via static
methods that the compiler handles so as to make them look like they
are part of the original class.
Someone else addressed the IB implementation question, in a far more
authoritative way than I could have, so I'll leave that one alone.
Pete -
Le 20 mai 08 à 00:06, Peter Duniho a écrit :
> C# provides "partial" class implementations for when you want to
> split functionality across multiple module files (one use of
> categories).
As you wrote, this is one use of categories. However, it is not this
usage that makes categories so powerful. It is the possibility to add
methods to classes for which you don't have source code (i.e., that
have been compiled by someone else). C# partial classes require you to
have all of the class source code (all the "partial" chunks) when
compiling your class.
> When you are accessing only the public API for a class, C#'s
> extension methods provide the same sort of syntax,
Yes, but the semantic is completely different. In C#, extension
methods are actually not instance methods or class methods : no
dynamic binding takes place at invocation time. All is statically
resolved at compile time. It is syntactic sugar for static "methods".
Philippe Mougin
http://www.fscript.org -
On May 19, 2008, at 6:06 PM, Peter Duniho wrote:
>> Date: Mon, 19 May 2008 15:51:07 -0400
>> From: Andy Lee <aglee...>
>>
>> * Objective-C allows you to create categories, effectively modifying
>> a class's interface at runtime.
>
> C# provides "partial" class implementations for when you want to
> split functionality across multiple module files (one use of
> categories). When doing this, you have complete access to the
> class's private and protected members, and the implementation is
> truly part of the class.
>
> When you are accessing only the public API for a class, C#'s
> extension methods provide the same sort of syntax, but via static
> methods that the compiler handles so as to make them look like they
> are part of the original class.
Interesting. When you say static methods, do you mean methods that
cannot access instance internals? What does self (or this, or
whatever) refer to in those methods?
> Someone else addressed the IB implementation question, in a far more
> authoritative way than I could have, so I'll leave that one alone.
Yeah, maybe I should have left it alone too. :) IB is better fodder
for advocating languages with reflection/introspection than dynamic
messaging.
--Andy -
> I appreciate the example. It's certainly reasonably elegant and to
> the point, and it's more "real world" than some of the other ones
> (bridging Cocoa to another language? yeah, right...a) it's not like
> you can't interface between languages with other languages, and b)
> this is not the kind of thing one is going to see in general
> application code). But not the sort of compelling "we really need
> the language to be this way otherwise it just doesn't work" example I
> was hoping for
From what I gather, this feature of Obj-C provides two major things
you're missing:
1) It makes things more elegant and simpler. Yes, Java and C# can do a
lot of what Obj-C can do, but you said so yourself it would require
more code and be less elegant. Take any app of sophistication and this
translates to a lot of saved code and time since it adds up.
2) Many of the examples you're looking for are not so much in people's
apps, but in AppKit itself meaning that AppKit would have had to be
far more complex, big, and clunky if not for this feature.
So it may be a relatively minor thing in that other languages can do
what this does, but it makes a difference throughout Cocoa programming.
Alex Kac - President and Founder
Web Information Solutions, Inc. - Central Texas Microsoft Certified
Partner -
I think one of the issues here is you're comparing .NET - which is not
the primary Windows framework - to Cocoa - which is. They are
comparable and many people do compare them, but truthfully most
commercial software on Windows will not be written with .NET while
most on OS X will be Cocoa.
.NET is pushed by Microsoft for IT apps and custom apps, not for
commercial apps even though there are some. I have used .NET and
really really like it, but I simply view Cocoa and .NET as two
frameworks for different purposes. Yes, Cocoa can be used for custom
IT apps much like .NET, but .NET is optimized for that purpose.
That is why if I want to customize the UI or behavior more in .NET its
harder to do than in MFC or plain Win32, while building a completely
standard boring app is easier in .NET by far. Its why .NET hides so
much from the programmer, and why Cocoa doesn't. Cocoa is an OO
version of Win32 in conception (not by any other comparison) because
Windows *runs* on Win32 and the vast majority of commercial apps are
in Win32 C/C++ with MFC or native code and the same can be said for
Cocoa and OS X. As such, with it being the primary OS framework/API,
it has to allow the developer easier access to the nitty gritty.
So Obj-C/Cocoa is more elegant than Win32, MFC, and .NET. So .NET is
easier in a few ways. I don't think any of that is a negative towards
the other frameworks. Just remember their purpose.
> Well, except that this would generally be implemented by theAlex Kac - President and Founder
> framework, no?
>
> In .NET, it supports remote invocations, and this uses (in part)
> reflection, but the application writer never needs to know the gory
> details. I agree that reflection is slightly more awkward than
> what's been presented in terms of Objective-C's message paradigm, and
> I accept that as a benefit for the authors of the framework. But the
> end-user doesn't need any of this, or even need to care how it's
> implemented. Imposing a particular language on the end-user in order
> to support the framework author doesn't seem compelling to me.
Web Information Solutions, Inc. - Central Texas Microsoft Certified
Partner
"There will always be death and taxes; however, death doesn't get
worse every year."
-- Anonymous -
On May 19, 2008, at 4:33 PM, Alex Kac wrote:
> 2) Many of the examples you're looking for are not so much in
> people's apps, but in AppKit itself meaning that AppKit would have
> had to be far more complex, big, and clunky if not for this feature.
Don't underestimate the utility of being able to make use of Objective-
C's dynamic features outside of the core frameworks like AppKit and
Core Data.
There's a long history in the Cocoa community of building new dynamic
functionality atop the core frameworks. For example, NSUndoManager
itself only became part of the Foundation framework with Mac OS X.
Prior to Mac OS X, it was EOUndoManager and was implemented in the
Enterprise Objects Framework (EOF), which was a separate product.
(EOF was originally created by Jack Greenfield, of current Microsoft
"Software Factories" fame, while he was at NeXT.)
One of the things I did several years back was implement a mechanism
whereby -can<Action>: methods were invoked automatically by a generic -
validateMenuItem: implementation. It can be done in Java or C# (I
actually did it for a Cocoa-Java application) but it was much easier
to prototype and get the bugs out of in Objective-C.
Also several years back -- on Jaguar, before Cocoa bindings existed --
I implemented my own bindings-like mechanisms atop key-value coding
and property change notifications. (That I did in Objective-C.)
Again, this was very easy thanks to the combination of rich
information at runtime and a type system that didn't get in the way.
So while the dynamism and reflection supported by Objective-C are
useful to the frameworks that make up Cocoa, they're also very useful
when writing software atop Cocoa. Using the same design patterns and
functionality as the frameworks helps ensure your own software will
fit in well and be approachable by those who work on it next.
-- Chris -
On May 20, 2008, at 01:49, Alex Kac wrote:
> I think one of the issues here is you're comparing .NET - which is
> not the primary Windows framework - to Cocoa - which is. They are
> comparable and many people do compare them, but truthfully most
> commercial software on Windows will not be written with .NET
Huh? That is not my experience.
> .NET is pushed by Microsoft for IT apps and custom apps, not for
> commercial apps even though there are some. I have used .NET and
> really really like it, but I simply view Cocoa and .NET as two
> frameworks for different purposes. Yes, Cocoa can be used for custom
> IT apps much like .NET, but .NET is optimized for that purpose.
What are "IT apps"? This is a weird distinction.
Sorry, don't buy that. -
On May 19, 2008, at 8:15 PM, <cocoa-dev-request...> wrote:
> Don't underestimate the utility of being able to make use of
> Objective-
> C's dynamic features outside of the core frameworks like AppKit and
> Core Data.
I'm not. But my point is that in most of our apps you'll find one or
two key things we can show can be done so much nicer with the dynamic
feature and Peter keeps asking about them, whereas you can just look
at AppKit and find a huge set of examples.
> So while the dynamism and reflection supported by Objective-C are
> useful to the frameworks that make up Cocoa, they're also very useful
> when writing software atop Cocoa. Using the same design patterns and
> functionality as the frameworks helps ensure your own software will
> fit in well and be approachable by those who work on it next.
Agree completely - but for the purposes of this discussion the point
is that AppKit is the biggest "wow" example for Obj-C dynamism. I
pointed this out because it *seems* that while Peter keeps asking for
examples none wow him.
Alex Kac - President and Founder
Web Information Solutions, Inc. - Central Texas Microsoft Certified
Partner
"You cannot build a reputation on what you intend to do."
-- Liz Smith -
Am 19.05.2008 um 22:36 Uhr schrieb Peter Duniho:
> But not the sort of compelling "we really need the language to be
> this way otherwise it just doesn't work" example I was hoping for.
There is no such example. As was already pointed out, you can do the
same things in every touring complete language.
So it's mostly a matter of what style you prefer.
> In .NET, you'd just call Color.FromName().
You go to great length to explain to us that everything is possible
in .NET, too.
What I'd be more interested in is: Are people actually *writing* such
code in .NET? Because we do so all the time.
Anyway - if the capabilities are as similar as you say, what's the
problem here? Just the square brackets? :)
Andreas -
With you 100% on all this below.
Been having trouble coming up with something useful to add to all
these discussions about Cocoa & Apple Developer Documentation .. what
you said below sums a lot of it up.
These points really resonate for me:
++ "explaining why _their_ API and paradigm is superior"
++ "but what about the kinds of things the other 98% of the
programming world wants to do?"
I try to submit documentation feedback when I can...
cheers list
On May 19, 2008, at 5:03 PM, Peter Duniho wrote:
>> From: ben syverson <ben...>
>>
>> This is going to sound bitchy, but it's hard for me to have any
>> sympathy for vague complaints about the docs or the usability of
>> Cocoa.
>
> That does sound bitchy. I mean, it's fair enough to say that people
> ought to be providing specific feedback and constructive
> complaints. But to have _no_ sympathy? That's harsh.
>
> Real people are having real problems getting into Cocoa. I don't
> see the kind of repeated commentary about poor documentation and
> difficult APIs in the C#/.NET forums or Java forums. It comes up
> once in a blue moon, but not with the reliability I've seen here,
> nor is there nearly the kind of practiced, organized defense seen
> here (which again suggests a certain regularity to the complaints).
>
> I had a big long reply (even longer than this one :) ) written to
> Julius's initial post under this subject and detailing many of my
> concerns and complaints about Objective-C, Cocoa, and the
> documentation, but decided the better of posting it. However, I'll
> say this: I agree that at least for me, the fundamental issue is
> that from a "usability" point of view, Objective-C, Cocoa, and the
> associated documentation leave something to be desired. I found
> Julius's comments regarding "usability" to be right on the mark, at
> least in the general sense.
>
> There's no question in my mind that Cocoa is a nice framework, and
> that the entire environment provides some good productivity-
> enhancing features. But it's also clear that those benefits are
> only really available to someone who has already invested a lot of
> effort in learning it. The "rule of least surprise" doesn't apply;
> maybe it does to the framework, but not to the documentation and
> definitely not to the tools.
>
> I contrast that with my experiences moving to C#/.NET and Java from
> the Win32 C++ world. Now, at least with .NET it is true that to
> some extent, I benefitted from having a fair amount of Win32
> expertise. Some of the paradigms map closely, and that helped. But
> there's a lot in .NET that is entirely new, and that was easy and
> fun too. And Java was completely foreign to me when I started using
> it. In neither case did I find myself feeling like I'd just entered
> a whole new world where, until you had gone through the entire
> hazing process, one could never really be effective as a programmer.
>
> .NET and Java were _fun_. They are still fun. I love writing code
> for either platform. I ported one simple .NET application to Cocoa
> and haven't had any interest in writing any more Cocoa code at all.
> I'd love to see the Mac succeed as a platform. But frankly, I think
> you already have to be a pretty hard-core Mac fan, and _really_ want
> to see your software on the Mac, to be motivated to spend a lot of
> time with Cocoa. Until programming in Cocoa is fun for _everyone_,
> not just the few who have made it through the gauntlet, I don't see
> it attracting a large following.
>
> Those who love the Mac, and who love Cocoa, ignore this kind of
> feedback, provided to them on a regular basis, at their peril.
>
>> [...] But I can't think of a single time when I've been unable to
>> figure out
>> where to look for guidance on a problem, or have been unable to
>> interpret that guidance.
>
> For what it's worth, it's not (to me) a matter of not being able to
> figure it out at all. It's how much effort is required to figure it
> out.
>
> MSDN is sprinkled with code samples. Everywhere. Granted, some of
> them are kind of silly, and some of them are just plain wrong. But
> on the whole, they are pretty good. More to the point, they exist
> for pretty much _every_ documented API element. Class methods,
> properties, events, fields. All have a dedicated doc page that
> includes some sample code (in many cases, a single sample is shared
> among multiple elements...but that's just efficient doc writing).
>
> Contrast to the Cocoa docs, where a single class is documented in
> just one web page, with practically no sample code at all and
> incredibly brief descriptions of each element.
>
> Oddly enough, the same complaint can be made for Sun's docs for
> Java, but I haven't found that to be nearly as great a degree of a
> problem there. It's hard for me to put my finger on exactly what
> the difference is, but I'd guess that at least partly it has to do
> with the fact that Sun's docs include frames with navigation panes
> that help orient you within the API, so that as you jump around you
> have some idea of what classes are related to what and why. The
> Java tutorials also seem more to the point.
>
> I know that given time, I can figure pretty much anything out. But
> in the Cocoa docs and API, it can sometimes be a real chore.
>
> As an example, I found myself wanting to exclude an area from my
> clipping region. Nothing complicated: I had a rectangular area, and
> I wanted to draw everywhere _except_ a specific sub-rectangle. The
> docs were quite prideful as to how, since Cocoa clipping uses the
> NSBezierPath, you have practically infinite control over clipped.
> No doubt this boasting was reasonably accurate (*). And yet, even
> as it hints tantalizingly at the idea that there's a way to do this
> (see "Modifying the Current Graphics State"), it doesn't quite get
> you there.
>
> (*) And that's another thing...nowhere else have
> I seen documentation that wastes so much time
> explaining why _their_ API and paradigm is superior.
> Why all the proselytizing? Just tell me how to get
> the damn job done! I get it...Apple thinks that
> there's no better way to write software than using
> Cocoa. Stop hitting me over the head about it!
>
> I was finally able to, after reading documentation in three
> different places that discuss NSBezierPath, connect the dots so to
> speak and figure out how the heck to get NSBezierPath to do what the
> docs hinted it could do.
>
> For that matter, why is the entire NSBezierPath API based on
> "append"? Why isn't there just a "remove" semantic too, that
> internally translates to the appropriate "append" behavior?
>
> It's not that it's not possible to do what I wanted to do, or even
> that Cocoa is lacking in functionality (at least in that area), or
> even that the docs fail to include enough information to figure it
> out. It's just that the docs seem to spend a lot of time discussing
> either incredibly basic things, or incredibly complex things, and
> failing to cover some of the more typical use cases.
>
> So often when reading the MSDN docs and Sun's tutorials, I find code
> samples and use explanations that are pretty close to what I'm
> trying to do. Reading the Cocoa docs, as a person not writing
> really complex programs, I find myself thinking "well, that's
> interesting...but what about the kinds of things the other 98% of
> the programming world wants to do?"
>
> And to barely touch on another point of dissatisfaction, I'll point
> out that least in Xcode 2.4, I found the Help topics for IB to be
> fairly useless, as they appeared to be written for a previous
> version of IB and often described things that were simply not even
> present in the version I was using. A similar issue came up when I
> tried to use Apple's docs to learn how to add my own Help for my
> program, only to discover that the tool it referred to had nothing
> to do with the tool currently in use.
>
> Finally, the Cocoa fanatics would do well to not only recognize that
> these dissatisfactions with the environment are not limited to just
> a handful of malcontents (if you think you spend an inordinate
> amount of time addressing these complaints now, just wait until if
> and when the Mac is actually a popular programming platform), but to
> recognize that individual complaints are somewhat varied.
>
> For example, while I tend to agree with the issues raised about the
> documentation, it doesn't bother me nearly as much as some of the
> fundamental issues around Objective-C. Having spent so much time
> using languages like C++, and later C# and Java, I get annoyed when
> the language tells me that I need to start dealing with OOP concepts
> such as object construction manually. Especially when this means
> that in spite of the language encouraging me to write an appropriate
> "init" method (the closest thing to a constructor Obj-C seems to
> have), it turns out that for my sub-classes instantiated by IB,
> that's never actually called. Duh.
>
> I also find the dynamic nature of the language to be a liability,
> not a feature. I keep hearing people say "sure, the compiler can't
> tell you that method call is incorrect, but that's the cost of
> having such a dynamic language", but then when pressed they are
> unable to describe why that dynanism is beneficial. The vast
> majority of software is easily written without that sort of
> capability, and with much stronger compiler support for code
> correctness.
>
> I realize there are plenty of people who love Obj-C. Heck, I'd
> guess that most of the people reading this email love it. But you
> have to understand that you're a fairly homogenous, isolated audience.
>
> And as long as you guys keep insisting that there's nothing wrong
> with the environment, and that people "just need to get used to it"
> and "then they'll love it", you're not going to get the kind of
> developer excitement needed to ensure the kind of developer support
> required to get the Mac really into the mainstream. At a minimum,
> market growth is going to happen a LOT more slowly than it could
> otherwise.
>
> And yes, it's fair to ask for specific, actionable criticism that
> can be used to improve the documentation. But the fact is, when
> you're knee-deep in trying to decipher the documentation and the
> API, it's hard to remember to take the kind of notes that would be
> useful in reconstructing the difficulties encountered. By the time
> I got my little Cocoa program working, I was just so happy to
> finally be done with it, the last thing I wanted to do was spend a
> bunch of time trying to remember what was so painful about it and
> submitting all of that information to Apple.
>
> Yes, I agree it would have been better for me to do that. But I've
> got other things to do, and frankly given the utter lack of sympathy
> I found in the Mac development community for the issues I was going
> through, I didn't find myself very motivated to spend my own time
> trying to improve things. If Apple and the existing dev community
> doesn't care, why should I?
>
> Phew. I got rid of one long reply, only to eventually write
> another. I guess I really needed to get that off my chest. Suffice
> to say, I have not found the experience of writing Mac software
> nearly as pleasurable as writing .NET or Java software. It's only
> marginally better than the experience of writing to more primitive
> platforms, and that's only because the Cocoa framework itself
> counterbalances the awkward aspects of the rest of the environment.
>
> As long as the existing Mac dev community, and especially Apple's
> own developer support staff, fails to understand this, the Mac just
> isn't going to attract people to write code just for the sake of
> writing code. And people writing code just for the sake of writing
> code is one of the biggest ways a platform gains strong developer
> support.
>
> Pete
-
On Tue, May 20, 2008 at 1:33 AM, Peter Duniho <peted...> wrote:
>> Date: Mon, 19 May 2008 19:50:57 +0800
>> From: "Michael Ash" <michael.ash...>
>>
>> [...] the existence or even the volume of
>> these complains is not evidence of anything other than that this
>> platform actually attracts programmers who aren't using it just
>> because it's hard.
>
> The platform attracts programmers who aren't using it? What does that even
> mean? If the programmers aren't using it, how did the platform attract
> them?
This was apparently badly phrased.
Expanding on it a bit, there are two kinds of platforms:
1) Platforms where all of the developers are there only because they
like a challenge, because developing for the platform is hard, etc.
Example: BrickOS.
2) Platforms where the developers use the platform merely as a tool to
accomplish work.
Platforms of type #1 tend not to get many complaints about the quality
of the documentation, because the environment is expected to be bad,
and the few people who know the platform well enough to write
documentation are expected to spend their time improving the code
instead.
Platforms of type #2 get lots of complaints about the quality of the
documentation because that's what people do.
> In any case, it takes a pretty blind eye to claim that the volume of
> complaints is in no way related to problems.
I disagree. The volume of complaints which we experience is what I
would expect for this community, and therefore I don't think it means
that this community has any special problem.
>>> [...]
>>> Oh, and as an added benefit: because interfaces are treated like types
>>> and
>>> you're not dealing with method signatures directly, there's none of this
>>> "oops, you forgot to include the trailing colon in the selector name"
>>> business (you can probably guess, I've run into that at least once :) ).
>>> The compiler prevents that from happening.
>>
>> If this bothers you that much in ObjC then merely add
>> -Wundeclared-selector to your compiler warning flags.
>
> Never even heard of that flag. Why isn't it the default?
I haven't a clue, I don't and never have worked at Apple or on Xcode.
> This is a decent example of the kinds of usability issues we're talking
> about, and frankly that one looks pretty easy to fix.
On the other hand, at some point while programming on a UNIX system,
you should read the man page for the compiler you're using. Not
defending Apple on this, but you really should do a "man gcc" and read
the thing.
Xcode's default warnings are crap anyway. The first thing I do any
time I create a new project is go to Other Warnings Flags and enter
"-W -Wall -Wno-unused-parameter". Makes life so much easier.
>>> Which is all a long way of saying, the message-sending paradigm in Obj-C
>>> isn't required for the example you give. This is my point. With a
>>> strongly-typed language that includes run-time type information
>>> (something
>>> that's even available in some C++ implementations for that matter), you
>>> don't need to have a whole message-dispatching system for your
>>> function-calling.
>>
>> This makes no sense. If you support this kind of dispatch then you
>> *have* a whole message-dispatching system, no matter what you call it.
>> Java and C# ultimately support the same messaging semantics as ObjC,
>> albeit vastly more verbosely in the more complicated cases, and has
>> similar machinery underneath it making it all happen.
>
> Maybe I'm misinformed about how message-dispatching in Objective-C works.
> But AFAIK, it's nothing like the direct invocation and v-table mechanisms
> that exist in C# and Java. It's the exact opposite of "similar".
Irrelevant implementation details. You can take some kind of
identifier which represents a method name and use that to invoke the
method. In ObjC this is the standard method invocation path, in C# and
Java it may or may not be (I'm given to understand that Java VMs tend
to be implemented using a highly general OO dispatcher which is then
used to implement Java dispatch semantics) but the capability and thus
the mechanism exists.
Others have taken over the discussion on NSUndoManager so I will leave it be.
>> Or even implement something as simple as the Cocoa responder chain,
>> trivial in ObjC, in one of these more "mainstream" languages.
>
> It's trivial in C# too. Most likely, it'd be implemented as a "handleable"
> event, with each responder subscribed to the event, and invocation halted
> after the first subscribed delegate actually handling the event. But it
> wouldn't be hard to do it based on interfaces instead (and in Java, that's
> pretty much the best way to do it, it not having events or delegates), and
> that implementation would look a lot more like Obj-C (in that the invoker
> would simply enumerate the responders until it found the one that implements
> the interface it needs).
I don't see how you can implement the responder chain using
interfaces. The responder chain passes *arbitrary* messages which do
not exist at compile time. You need to be able to take an arbitrary
string, then walk the chain to find an object which implements a
method with that name. From what I understand of interfaces, it would
require all of the possible messages to be defined at compile time.
I'm sure it's possible in C# or Java but it's not going to be as easy.
In your other posts you keep talking about how these are framework
facilities so it doesn't matter how easy it is to implement. This is
rather missing the point. The point is that similar facilities can be
easily constructed by us, the end-programmer. Sure, I'm not going to
be rewriting NSUndoManager or distributed objects, that would be
silly. But I am going to be implementing invocation-capturing object
proxies for my own use, for example to have one object automatically
forward messages to objects it contains, or to wrap a collection
mutating message in a transaction so I can make that modification
thread safe. The fact that these things take only a few lines of easy
code make it a lot more practical to use these techniques on a regular
basis for things which the framework developers *didn't* anticipate in
advance.
>>> Likewise, interfaces aren't something you use _everywhere_ in Java and
>>> C#.
>>> You use them only when you need them. The difference is that in Java
>>> and
>>> C#, the compiler "always" (*) knows whether what you're doing is
>>> reasonable
>>> or not.
>>
>> Even with your caveat, this is insane.
>
> Yes, using words like "absurd" and "insane" to describe the person with whom
> you're discussing the issues is a really mature, productive way to engage
> them.
I'm not describing you as insane, I'm describing your statement as
insane. There's a difference. And stating that "the compiler 'always'
knows whether what you're doing is reasonable or not" *is* insane. Is
this pseudocode reasonable?
function sort(array):
for index in range(array - 1):
if array[index] > array[index + 1]:
swap(array[index], array[index + 1])
No, of course not; this is not a sort, just a broken piece of one. If
you translate this pseudocode into Java or C#, will the compiler tell
you that this code is unreasonable? If your answer is "yes", then I'm
switching right now, because gcc is woefully incapable of DWIM.
>> No compiler can stop you from
>> writing unreasonable code. It may be able to stop you from writing
>> code that treats an object as something it's not, but that is only one
>> tiny corner in an enormous universe of unreasonableness.
>
> You're missing the point. For things that the compiler _can_ do easily, it
> _should_. The lack of true constructors in Obj-C is an example of this.
I understand that, but you're missing the point as well. The compiler
can't do this easily. Or rather, it can, but in doing so it destroys
serious capabilities of the language. You can't just say that the
compiler can easily enforce strict type checking therefore it should.
The question is not only what benefits this brings, but what changes
to the language it causes.
Now, you may think that the capabilities which get destroyed in this
process are pointless, but you need to realize that there are a lot of
us out there who don't think that way.
>> This is, of
>> course, the fundamental point of contention between statically and
>> dynamically typed languages. Us dynamic advocates know that the
>> compiler can detect these things, we just don't care. You treat these
>> bugs like any other bugs, and you catch them in testing. Sure, it's
>> convenient to catch them when you compile instead, but is it worth the
>> enormous loss of flexibility? The people on this side say no. If you
>> disagree, that's fine, but realize that it's a fundamental matter of
>> opinion, not simply that your compilers are able to catch all your
>> errors and ours are not.
>
> Well, I'm still waiting for someone to show me how that flexibility is used.
> You are certainly doing a great job of stating the same party line I've
> heard countless times already. But you're also failing to provide a
> compelling example of how this flexibility comes into play in the real
> world. Again, this is not only typical, it's characteristic of _every_
> single time I've heard the party line stated.
I would have figured that NSUndoManager, which gets used constantly in
Cocoa apps and which has, as far as I know, no equivalent in the Java
or C# world, would be a pretty good example of the flexibility coming
into play in the real world. Of course, it doesn't help when you don't
know what it does or how it works and don't find out.
Anyway, here's a random list of other ways in which the flexibility
can be used in the real world. (They are things that I or my
colleagues have actually done, mind, so they're in no way contrived
examples.) I'm also including a rough estimate of the line count for
implementing each one, since as I mentioned above, the pertinent fact
in this comparison often isn't whether it can be done, but how
difficult it is and thus how practical it is to use this sort of
technique on a regular basis:
- Use message forwarding to simulate multiple inheritance (3 lines)
- Use message forwarding to present an interface which is implemented
by multiple internal objects (5 lines)
- Write a method to enable/disable menu items by calling a method with
a defined signature, such as adding "validate_" to the target message
of the menu item, and using the returned yes/no to enable/disable (3
lines)
- Map a network protocol's commands to object methods by appending a
standard suffix to the end of the command, then invoking the method
with that name (2 lines)
- Proxy messages across to another thread with blocking semantics that
emulate coroutines (10 lines)
Mike -
Hear hear. It has already happened to one platform, and look how
abysmally inconsistent it has become for users. I for one do not want
to see every Tom, Dick and Harry throwing Cocoa around and doing it
badly (even if I do so myself ;-). Yes, that's probably elitist. I
offer no apology.
G.
On 20 May 2008, at 6:04 am, Hamish Allan wrote:
> On Mon, May 19, 2008 at 6:03 AM, Peter Duniho <peted...>
> wrote:
>
>> And as long as you guys keep insisting that there's nothing wrong
>> with the
>> environment, and that people "just need to get used to it" and
>> "then they'll
>> love it", you're not going to get the kind of developer excitement
>> needed to
>> ensure the kind of developer support required to get the Mac really
>> into the
>> mainstream. At a minimum, market growth is going to happen a LOT
>> more
>> slowly than it could otherwise.
>
> I don't see that as a particularly bad thing. I don't want to see my
> platform of choice suddenly awash with apps written by people who
> don't want to take the time to understand the whole picture. I'm
> pretty sure such apps would be less likely to conform to the HIG, and
> less likely to have been properly profiled for performance.
>
> Hamish
-
> Date: Tue, 20 May 2008 04:26:08 +0200
> From: Andreas Mayer <andreas...>
>
> Am 19.05.2008 um 22:36 Uhr schrieb Peter Duniho:
>
>> But not the sort of compelling "we really need the language to be
>> this way otherwise it just doesn't work" example I was hoping for.
>
> There is no such example. As was already pointed out, you can do the
> same things in every touring complete language.
It's "Turing". As in "Alan Turing". And you keep ignoring what I'm
saying. Just because two languages are Turing-Complete, that doesn't
mean that they will have equivalent implementations. The most basic
Turing-Complete language possible would have implementations for the
simplest of problems that are far too unwieldy to be practical, never
mind any interesting program.
Likewise, in comparing two different languages, they can still both
be Turing-Complete, and yet one can implement some behavior in a few
lines of code while the other could take hundreds to do the same thing.
I hesitate to put a specific ratio on my question, because as you
write...
> So it's mostly a matter of what style you prefer.
...but I'd say that I'd expect an example significant enough to
justify the hazards involved in the Cocoa paradigm would reduce the
implementation size by _at least_ one order of magnitude.
I admit, there are lots of people who don't mind dangerous
programming environments. Some people even thrive on them. But me?
I've had enough of the danger. I've lived my life on the edge long
enough, and I'm ready for a nice, quiet language when it's available.
And finally, because this thread keeps heading down this path for no
real good reason, I really need to point out once again that whatever
problems I have writing Cocoa code, the issues in the language that
disturb me are REALLY minor relative to the other stuff. If Xcode
and IB and the documentation worked perfectly, I could easily
overlook how Objective-C works.
But as things are now, I can't help but mention those other things
when I find myself ranting about the tools and docs. :)
Pete -
> Date: Mon, 19 May 2008 19:18:30 -0400
> From: Andy Lee <aglee...>
>
>> [...] When you are accessing only the public API for a class, C#'s
>> extension methods provide the same sort of syntax, but via static
>> methods that the compiler handles so as to make them look like they
>> are part of the original class.
>
> Interesting. When you say static methods, do you mean methods that
> cannot access instance internals?
I mean "static" in the sense of: a method not associated with a
specific object instance.
> What does self (or this, or
> whatever) refer to in those methods?
Nothing. It's not valid.
As Philippe correctly pointed out, this is not quite the same as
categories in Objective-C. Only code compiled with extension methods
will wind up using them, and they can't do things like override
existing virtual methods.
But personally, it makes me nervous to have a language that allows
the implementation of a class to change according to other code not
related to the class. It's one thing if you're just adding a method
that you want to use somewhere else. But in Objective-C you can also
add a method that overrides a base class method, or would not
normally exist in the class but which has meaning to some other code
that might check for it.
Powerful? Yes. But I'm reminded about the classic joke about how
you shoot yourself in the foot with different programming languages.
I _like_ that in C#, you can't modify an existing class, except as a
syntactical shorthand.
If I had ever found myself banging my head against the wall or
wasting an exorbitant amount of time trying to get around the lack of
such features in other languages, I might be more inclined to find
them worth the trade-off in increased ways to shoot yourself in the
foot. But I haven't, so I'm not.
Obviously, other people's mileage may vary, including your own. But
I really REALLY think it would be worthwhile for the existing Cocoa
community, and especially the experts, to try to look at the issue
from this point of view once in awhile.
I don't go around telling you guys that you're crazy for wanting to
use Objective-C and even liking it. I find it condescending and
abusive that rather than those who are having trouble adjusting, or
who simply find the language not exactly to their liking, being
offered some sympathy instead those people are basically told "well,
you just haven't learned enough about Objective-C", or "you obviously
don't know anything about OOP", or "only the true believers are
worthy to write Mac software", or any of the numerous other
variations on that theme.
And no, not all responses are long those lines. But there's
certainly no shortage of those kinds of sentiments.
I can't speak for others, but for my own part, my goal isn't to
convince everyone that Objective-C is bad. My goal is to try to
express my own personal views of the language and why I feel the way
I do, as a way of trying to get someone, _anyone_ to have just a
smidgen of empathy for a person like me who does not necessarily find
the Kool-Aid particularly to his liking.
And one last time: it's NOT the language that really causes me
distress. The things I've spent an inordinate amount of time
discussing really are minor annoyances, easily dealt with. I don't
_have_ to have a safe language, I just happen to like that better.
If I could pick three things that I could change about Mac software
development, and with a wave of a magic wand fix them instantly,
there's nothing in Objective-C that would make that list.
Pete -
> I admit, there are lots of people who don't mind dangerous
> programming environments. Some people even thrive on them. But me?
> I've had enough of the danger. I've lived my life on the edge long
> enough, and I'm ready for a nice, quiet language when it's available.
Stay with the M$ way then, it seems to me the less adventurous choice today
It is a question of intellectual curiosity I believe, maybe you are too old and tired to take new risk and have more fun ?
> disturb me are REALLY minor relative to the other stuff. If Xcode
> and IB and the documentation worked perfectly, I could easily
> overlook how Objective-C works.
I know that it can be biased, but I am using every day Visual 2003 for my job, producing C++ code, and sincerely, I don't find the tools and doc superior to the MacOSX ones. Maybe it has more sense to use them when programming C#/.Net code, I don't know.
I had to explore .Net to integrate a .Net component in our Qt/trolltech project, to do Olap stuff, I was frightened by the state of the documentation for the .Net components, the learning curve was very unfriendly.
I don't like everything in Cocoa/Xcode/IB, but I feel that your criticism are a bit artificial here. All of us have a lot of different experience in programming; we have to fight with hostile environment sometimes, it is our job : I maintain the server part of our product under solaris, with sunstudio 11 and other tools like xemacs and co...
Xcode is very easy to use, navigating in the project is very efficient, the doc is well formed, IB is very powerful, and the tool are improving a lot every time a version is out.
Regards
Gerard -
On May 20, 2008, at 1:07 AM, Peter Duniho wrote:
> But personally, it makes me nervous to have a language that allows
> the implementation of a class to change according to other code not
> related to the class. It's one thing if you're just adding a method
> that you want to use somewhere else. But in Objective-C you can
> also add a method that overrides a base class method, or would not
> normally exist in the class but which has meaning to some other code
> that might check for it.
I have been programming in Obj-C against the Cocoa APIs (and their
predecessors) since 1989-- with quite a few other random APIs and
environments over the years, too-- and I can unequivocally say that
the ability to override existing functionality in categories is just
damned dangerous.
When I found out about C#'s "extension methods", I wrote about it here:
http://www.friday.com/bbum/2007/01/31/c-30-now-with-categories/
And then followed up with a second post here:
http://www.friday.com/bbum/2007/02/02/c-30-categories-followup/
In any case, you are absolutely correct that categories are dangerous
and the above includes an anecdote documenting a particularly
egregious related problem. Most extremely powerful tools are.
Sometimes one must question whether or not said power is gratuitous or
truly useful and this particular feature falls in "gratuitous".
Reminds me of this classic story:
http://artlung.com/smorgasborg/C_R_Y_P_T_O_N_O_M_I_C_O_N.shtml
In particular, search for "hole hawg".
Given that the Cocoa development community has obviously expanded
quite substantially in recent months and many of you are coming to
Cocoa with deep experience in other environments and languages, please
file bugs / feature requests / feedback through Apple's bugreporter
system (http://bugreport.apple.com/).
thanks,
b.bum -
Am 20.05.2008 um 09:47 Uhr schrieb Peter Duniho:
> It's "Turing". As in "Alan Turing".
Thank you very much for pointing out that typo. -.-
> Just because two languages are Turing-Complete, that doesn't mean
> that they will have equivalent implementations.
I didn't say that. You talked about "not working otherwise“ - that
sounded a bit stronger than just different implementations.
> ...but I'd say that I'd expect an example significant enough to
> justify the hazards involved in the Cocoa paradigm would reduce the
> implementation size by _at least_ one order of magnitude.
That those are 'hazards' is just your opinion. To other people it's
freedom.
As I said - a matter of personal preferences.
> I admit, there are lots of people who don't mind dangerous
> programming environments.
If it was just half as dangerous as you make it sound, no single Mac
would work reliably.
> I could easily overlook how Objective-C works.
Now *that's* generous. :-)
Andreas -
> Date: Tue, 20 May 2008 01:34:32 -0700
> From: G?rard Iglesias <gerard_iglesias...>
>
> [...]
> It is a question of intellectual curiosity I believe, maybe you are
> too old and tired to take new risk and have more fun ?
Yup, that must be it. I'm too old to "get" Objective-C. After all,
it's technology that's only 20 years old. It's really for those
young whipper-snappers, who are into risk-taking and extreme sports.
Us old fuddy-duddys better stay on the porch, or we might get hurt.
Well, thanks...now that I know that Mac software development is only
for the younger generation, I can see that I should just give up now
and forget about ever being able to write Mac software. After all,
Apple only wants the adrenaline junkies writing software for their
platform.
>> disturb me are REALLY minor relative to the other stuff. If Xcode
>> and IB and the documentation worked perfectly, I could easily
>> overlook how Objective-C works.
>
> I know that it can be biased, but I am using every day Visual 2003
> for my job, producing C++ code, and sincerely, I don't find the
> tools and doc superior to the MacOSX ones. Maybe it has more sense
> to use them when programming C#/.Net code, I don't know.
Well, a) you're using a version of VS that's five years old? And b)
yes, VS does a somewhat better job with C#/.NET code with respect to
Intellisense, auto-completion, etc. But it's not actually bad for C+
+ stuff, assuming you're using an up-to-date version of the program.
Pete -
>> It is a question of intellectual curiosity I believe, maybe you are
>> too old and tired to take new risk and have more fun ?
>
> Yup, that must be it. I'm too old to "get" Objective-C. After all,
> it's technology that's only 20 years old. It's really for those
> young whipper-snappers, who are into risk-taking and extreme
> sports. Us old fuddy-duddys better stay on the porch, or we might
> get hurt.
Gerard and Peter: This has been a very interesting discussion and
it's a shame to see it slide toward childish flame wars at your hands.
Can we stick to the issue and keep emotion in check, please?
--
I.S. -
I wanted to throw in another set of experiences and opinions, as
someone who has recently been (re)learning Cocoa for a new application.
Background... programming since mid-80's, MSc in HCI/CSCW, worked on a
number of significant Mac programs off and on since the "phone book"
edition of Inside Mac (Lightspeed/Think Pascal&C, Object Pascal, MPW,
TCL, Powerplant...), plus a large variety of other technology,
including C, C++, Java, various scripting languages, etc. Have done
very little Mac-only work in recent years (mostly cross-platform
stuff), but as I said, that's changing for a new project.
I've found learning Cocoa has been a very steep, slow, but manageable
learning curve, which has left me overwhelmed and frustrated more than
once for considerable periods of time - more so than any other
technology I've had to learn in recent years. And again, that's with a
lot of relevant experience; I can imagine what people who don't have a
formal comp sci background, just done Java or something similar would
be facing.
A few reasons, and hopefully I can tie some of this back to HCI... ;-)
1. Too many choices. Hard-coded models, or Core Data? Views or
layers? ObjC-classic or 2.0? Garbage collection or not? NSRect or
CGRect? Bindings or ...? I understand perfectly well why all the
different choices exist, how things have evolved, etc. but it means
everytime you encounter a problem in those kind of areas, you have to
figure out the right approach for your situation, and those aren't
trivial decisions, and they do require a lot of background knowledge.
We don't want our app users to be forced into making decisions when
they don't have to be, why should we? Yes, maybe that can't be
avoided, but it still is a significant factor slowing down learning.
2. Too many concepts. As the discussions here highlight, there are a
lot of concepts you need to keep in mind while developing; no need to
enumerate. Going back to the short term memory "7+-2" limits, you can
see why people get bogged down, because they get ten levels down into
concepts and then have to reorient themselves to what they were doing
higher up. Experts deal with those limits by "chunking", so that
several concepts can be effectively collapsed into one. That takes
experience and learning, which perhaps explains why some experts have
difficulty understanding why newbies don't get it. It takes a lot of
rote following "click this and type this here" examples before you
even start along that road.
3. Too much housekeeping. This is another instance of too many things
you have to hold in your head at once... to perform this operation,
you need to create this class, add this method, declare, alloc and
init this mutable whatzit, pass it this type which you get by calling
this function passing this other thing that you retrieved from this
method of... etc. Because ObjC/Cocoa are quite dynamic, they are
nowhere near as bad as Java, C++ and others in this regard, but
they're also not nearly as dynamic as dynamic languages like Ruby,
Python and Tcl. (Think creating lists for example). The tradeoffs
are there for a reason of course, but the extra steps do add to
learning curve.
4. Doesn't support everything. I'm being slightly facetious here, but
what I really mean is that there are some things you might think are
(should be) easy, that you have to create for yourself. If anyone has
used Tk, you know about its canvas widget, which provides a very rich
structured graphics framework which takes care of redraws, most event
handling, and does it in a very concise and self-contained way.
Programmers can use that facility for a surprisingly wide range of
common tasks. In Cocoa you need to handle that yourself. With tools
like the canvas, I've taught experienced programmers enough Tcl/Tk to
put together some useful tools in a matter of a couple of hours, and
non-programmers in a couple of days. Couldn't do that with ObjC and
Cocoa. It doesn't take long in Cocoa before you're at the "custom
view" level.
5. Too much hype. Or to put it another way, expectations are set very
high by many Cocoa experts, which it's difficult to live up to. Cocoa
is great, but it doesn't do everything the best way possible, is not
the right tool for every job, it's not for everyone, and there are a
lot of things to learn before you can do things well. That's not a
bad thing. But it's the old story that I'd rather under-promise and
over-deliver.
I really like Cocoa, and I'm getting more and more proficient, but
it's still slow going. And I am really thankful that the 3rd edition
of the Hillegass book came out on O'Reilly's Safari not too long after
I started working on this current project!
Mark -
I agree completely with Mark Roseman's analysis:
1) Too many chioces
2) Too many concepts
3) Too much housekeeping
4) Doesn't support everything
5) Too much hype.
The only additions I can make are the following:
1) Many folks from the Windows worls are certainly familiar with too many choices for good or ill.
2) Programming and Computer Scienec are all about concepts. I don't think someone should consider themselves a competent object oriented programmer if they are not familiar with the MVC pattern that organizes all of Cocoa. That's just my opinion though. And seriously, you can never have too many concepts. When you are unwilling to learn or gasp invent a new concept, you have just given up.
3) There absolutely is too much housekeeping
4) No framewor supports everything. Framework support for undo/redo is down right rare.
5) There absolutely has been too much hype particularly about bindings! -
Am 20.05.2008 um 19:54 schrieb Erik Buck:
> I agree completely with Mark Roseman's analysis:
I'm not quite with Mark and Erik.
> 1) Too many chiocesThe world the software is developed for is complex to such a degree,
that we need many choices. But don't torture yourself, and apply
Occam's razor!
> 2) Too many conceptsDivide and conquer! Cut a project into pieces small enough, that –
among other things – the short term memory limits, Mark mentioned,
aren't a problem any more (object-orientation separates concern; the
model-view-controller paradigm allows developing model and view
without having to think about both at the same time; etc., etc.). Of
course, newbies have to learn this strategy, too – sorry.
> 3) Too much housekeepingAgreed (but it is much better with Cocoa than with Carbon).
> 4) Doesn't support everythingUnderstood and agreed. But I get very far with things out of the box
and example code, and have more time for the complications afterwards.
> 5) Too much hype.Ignore it!
Klaus -
On 21 May 2008, at 2:41 am, Mark Roseman wrote:
> 4. Doesn't support everything. I'm being slightly facetious here,
> but what I really mean is that there are some things you might think
> are (should be) easy, that you have to create for yourself. If
> anyone has used Tk, you know about its canvas widget, which provides
> a very rich structured graphics framework which takes care of
> redraws, most event handling, and does it in a very concise and self-
> contained way. Programmers can use that facility for a surprisingly
> wide range of common tasks. In Cocoa you need to handle that
> yourself. With tools like the canvas, I've taught experienced
> programmers enough Tcl/Tk to put together some useful tools in a
> matter of a couple of hours, and non-programmers in a couple of
> days. Couldn't do that with ObjC and Cocoa. It doesn't take long
> in Cocoa before you're at the "custom view" level.
At the risk of fighting hype with hype, you might be interested in my
DrawKit project, which *may* be somewhat similar (I'm not familiar
with Tk, so I can't claim it's exactly the same, but it sounds like it
might be similar). http://apptree.net/drawkitmain.htm
My own personal experience with Cocoa has been very positive, I have
not found myself hung up on too many conceptual or functional issues
for very long. I come from a C++ background, having been steeped in
that for over a decade before starting with Cocoa. I had to "unlearn"
a lot. But it wasn't hard - I found Obj-C a liberating language
compared to C++ and I do feel that in many ways much of the
programming I used to do was keeping the language happy, not being
productive in itself (I don't want to rehash the C++ vs. Obj-C
arguments here, I'm just saying that's how I felt).
Possibly one of my advantages was taking up Cocoa before Core Data and
Bindings and Obj-C 2.0 and Garbage Collection were added - that meant
they were a delta on top of what I already knew (and in fact I still
haven't bothered exploring some of them to any great extent). Maybe
the learning curve has got steeper because of these extra things - you
certainly see a lot of newbies asking about them. I think you can get
a long, long way in Cocoa without any of these so perhaps my advice to
a beginner would be: walk before you try to run. Forget about all
these "advanced" features and work on something by doing it the old
way at first. That shouldn't be quite so large a mountain to climb and
you will pick up enough to move to the higher levels much more easily.
Establish a base camp before you embark on the final push to the
summit. I learned a lot of Cocoa's basics from Hillegass's book, and I
recommend it. But just *maybe* the second edition will prove to be a
better bet for a beginner than the third?
hth,
G. -
On Tue, May 20, 2008 at 4:07 PM, Peter Duniho <peted...> wrote:
> But personally, it makes me nervous to have a language that allows the
> implementation of a class to change according to other code not related to
> the class. It's one thing if you're just adding a method that you want to
> use somewhere else. But in Objective-C you can also add a method that
> overrides a base class method, or would not normally exist in the class but
> which has meaning to some other code that might check for it.
I'd just like to point out that the above applies to any OO language
which supports both subclassing and dynamic dispatch, which is to say
approximately all of them. Categories are certainly differently
powerful in this regard, and as such will get you into trouble in ways
that subclassing cannot, but subclassing already has this powerful and
dangerous semantic that you're worried about. (And I think you're
rightfully nervous, it's just that you can't get away from it by
banishing categories.)
One of the things I enjoy about Cocoa is how it tends to discourage
subclassing. Most common customizations can be done through delegates
or notifications which helps reduce the danger of subclassing.
Mike -
However you slice it and whatever your personal experience, I believe
that what we are experiencing with the docs are the early symptoms of
massive scaling of the problem vs. insufficient scaling of the
resources to tackle it. If anyone can fix this, it is Apple.
If you care to invest the time, I have 3400 words on the subject here:
http://www.bagelturf.com/files/8f2cab87e2f633752047fcac70643352-1179.php -
> Date: Wed, 21 May 2008 08:33:40 +0800
> From: "Michael Ash" <michael.ash...>
>
> On Tue, May 20, 2008 at 4:07 PM, Peter Duniho <peted...>
> wrote:
>> But personally, it makes me nervous to have a language that allows
>> the
>> implementation of a class to change according to other code not
>> related to
>> the class. It's one thing if you're just adding a method that you
>> want to
>> use somewhere else. But in Objective-C you can also add a method
>> that
>> overrides a base class method, or would not normally exist in the
>> class but
>> which has meaning to some other code that might check for it.
>
> I'd just like to point out that the above applies to any OO language
> which supports both subclassing and dynamic dispatch, which is to say
> approximately all of them. Categories are certainly differently
> powerful in this regard, and as such will get you into trouble in ways
> that subclassing cannot, but subclassing already has this powerful and
> dangerous semantic that you're worried about.
No, it doesn't.
Each language varies a bit, of course. But in the other popular
languages that I know reasonably well -- C++, C#, Java -- a subclass
does not have the ability to touch any part of the base
implementation that is not specifically exposed by that
implementation. Private members are invisible, and other members are
only overridable when the base class allows it by making them virtual.
There is, of course, hazard any time the base implementation makes
this allowance. But those choices can be made on a member-by-member
basis, and reliable decisions and assumptions can be made regarding
the relative dependability of the base class on the basis of what
that base class exposes to sub-classes. Many classes have _no_
overridable members and no "protected" members, and thus completely
encapsulate their implementations. This is, in fact, the norm for
these other languages.
Cocoa restrains class extension _much_ less than any of these other
languages, and in turn has a _much_ higher degree of hazard.
It's certainly a continuum. I agree we're not talking either/or,
black/white, etc. here. Other languages aren't without their danger
zones either. It just seems to me that Cocoa goes overboard, for
relatively little payoff.
YMMV.
Pete -
On May 20, 2008, at 10:50 PM, Steve Weller wrote:
> However you slice it and whatever your personal experience, I
> believe that what we are experiencing with the docs are the early
> symptoms of massive scaling of the problem vs. insufficient scaling
> of the resources to tackle it. If anyone can fix this, it is Apple.
and writing a blog post most likely won't change that situation.
You've got to contact Apple directly (i.e. bugreporter)
>
>
> If you care to invest the time, I have 3400 words on the subject here:
>
> http://www.bagelturf.com/files/8f2cab87e2f633752047fcac70643352-1179.php
A few (hopefully helpful) pointers.
Conceptual doc books are
* Getting Started
* Fundamentals
* Programming Guide
Looking in the reference library, there is a pop up that allows you to
select the type of doc you see. Guides are conceptual.
I'm not sure where the commenter Justin was looking for Cocoa sample
code, but there certainly is a section for it. It is on both
developer.apple.com, and visible in the same popup.
Yes, some things are out of date. And if you find them before we do,
file bugs. or feedback. (bugs are typically better, since we can then
communicate with you if necessary).
If there are specific areas where sample code is needed, file
enhancement requests. Both Tech Pubs and DTS try to be responsive to
these issues when we get specific requests to show how to do "foo".
Ultimately, learning is a very personal experience and we all do it
differently. I'm not surprised that there are issues for some
developers with the docs. We do our best to get you what you need. -
On May 20, 2008, at 9:52 PM, Peter Duniho wrote:
> Each language varies a bit, of course. But in the other popular<snip>
> languages that I know reasonably well -- C++, C#, Java -- a subclass
> does not have the ability to touch any part of the base
> implementation that is not specifically exposed by that
> implementation. Private members are invisible, and other members
> are only overridable when the base class allows it by making them
> virtual.
> Cocoa restrains class extension _much_ less than any of these other
> languages, and in turn has a _much_ higher degree of hazard.
The goal is not for every language to mimic C++/C#/Java. Different
languages serves different purposes and there is no single best
language. Take Adobe Lightroom as an example, almost half of the code
(by line count) is written in Lua:
<http://www.lua.org/wshop05/Hamburg.pdf>
Is this because they don't know how great a static, restrictive, safe,
and secure language is? No, it's because they thought that some other
language quality was more important.
I think that Objective C finds a pragmatic sweet spot between the
performance and interoperability of C, and the dynamism and rapid
development qualities of scripting languages. It is small and easy to
learn, easy to read and write, and since you rarely have to deal with
raw pointers, it also provides many of the benefits of a more pure
object environment like Smalltalk/Java/C#.
Most developers that I know of feel more productive in Objective C
than using more restrictive languages like C++/C#/Java. You might
expect that the same qualities that makes a language good for rapid
development also would brings some drawbacks, for example making the
code more difficult to read and maintain. However, this is not a
problem typically associated with Objective-C.
Finally, also note that the compiler isn't the only, or perhaps even
the best, way to achieve productivity and quality - See the
discussions on "Strong Typing vs. Strong Testing":
<http://mindview.net/WebLog/log-0025>
> It's certainly a continuum. I agree we're not talking either/or,
> black/white, etc. here. Other languages aren't without their danger
> zones either. It just seems to me that Cocoa goes overboard, for
> relatively little payoff.
Let's agree to re-visit this discussion one to two years from now. I
don't think that it's fair of us to expect you to provide an informed
comparison before you have more experiences with both environments.
Regards,
j o a r -
On May 21, 2008, at 12:49 AM, Jeff LaMarche wrote:
> This is really a fascinating discussion and, unfortunately, a time
> consuming one =)
>
> I can't help but feel that we have two identifiable camps forming,
> and I'm not sure I like that. Though a range of opinions have been
> stated, it seems that most of us can be readily identified as being
> on one side or the other of this "quality of documentation" debate.
> I'm really racking my brains to figure out why - why such a division?
I think one of the major issues is that we're gaining new developers
at an extraordinary rate. And everyone learns differently as you say
later.
> First, how much are you paying for the documentation? How much did
> you pay for the IDE? I mean, I'd love everything to be perfect for
> everybody, but let's be realistic here. Apple doesn't derive any
> direct income from the documentation or from Xcode, and as much as
> we might think that shouldn't matter, Apple's a corporation, so it's
> going to matter.
I'm not sure that how much is being 'paid' for the documentation is a
valid metric.
I believe (not speaking for the company of course) that both of these
areas are viewed as investments.
> That's reality, and it's not going to change. Resources are limited,
> and considering the resources that are available for API
> documentation, I think they do a phenomenal job, and I honestly hate
> that some of the comments in this thread could be read as
> disparaging their work, even if unintentionally.
This consideration is much appreciated. But I think that most of us
find that this type of feedback (even when it could be negative) is
useful to what our mission is... giving developers the documentation
they need to write their apps.
We sort of have to aim our documentation at the mid range developer in
many cases. We don't have the facilities to teach basic C or OOP
technologies. Sometimes the basics of a technology aren't documented
well enough for all external developers (or internal for that matter)
to grasp, and we just need to know that.
> Apple can't be expected to adjust to that change instantaneously. I
> don't think it's even completely clear yet who's coming to the
> platform right now and why. To the extent that people are trying to
> give feedback to Apple so they know how best to proceed with future
> revisions to the documentation, I think this discussion is valuable,
> but at times we veer dangerously close to a pissing match mentality,
> and when that happens, I don't think it's productive (even when it's
> me doing it :) )
One point that I'd want to make very clear to everyone (and it has
been said over and over) the list is not an official means for
providing this type of feedback to Apple. While many of us read it
and an benefit from the information we can glean from the list and the
users, it's direct contact with Apple via bug reports, enhancement
requests (via bugreporter) and the documentation feedback mechanism,
that is going to make a significant impact. -
On May 21, 2008, at 12:01 AM, j o a r wrote:
> On May 20, 2008, at 9:52 PM, Peter Duniho wrote:
>
> The goal is not for every language to mimic C++/C#/Java.
I never said that was the goal.
> Different languages serves different purposes and there is no
> single best language.
I agree. So?
> [...] I think that Objective C finds a pragmatic sweet spot between
> the performance and interoperability of C, and the dynamism and
> rapid development qualities of scripting languages.
I have already acknowledged that opinions vary. You, being among the
regular contributors to this mailing list, I fully expect to "think
that Objective-C find a pragmatic sweet spot". Anything else would
surprise me.
> [...] Let's agree to re-visit this discussion one to two years from
> now. I don't think that it's fair of us to expect you to provide an
> informed comparison before you have more experiences with both
> environments.
You are simply proving my point.
You reject my impressions simply because I have less experience with
the language. You fail to have any sympathy whatsoever for my
personal experience, and tell me that I will change my mind after
using Cocoa for two more years.
The fact is, whether my opinions will change, first impressions
matter. And frankly, I didn't need three years (the year I've
already had, plus your two more years) to know that I liked other
languages that I've enjoyed over the years. I have absolutely no
reason to think that there's any validity in your assertion that
after three years of using Cocoa, I will have all my doubts removed.
This is exactly the kind of anti-welcome that I and others have
described before. I'm sorry that we simply do not appear to be able
to get the point across. But the fact is, the very act of your
rejection of our assertions prove those assertions.
And again: it's not that I'm on a crusade to have Objective-C
changed, or to have Cocoa made fully accessible via some other
language. I just want people to have some empathy for what at least
some of us go through upon encountering the one official Mac
development environment. Stop telling us that our reactions aren't
valid; for better or worse, these are our reactions and we can no
more control them than you can stop breathing. They are ours and
like it or not, they matter.
Pete -
On Wed, May 21, 2008 at 12:52 PM, Peter Duniho <peted...> wrote:
>> Date: Wed, 21 May 2008 08:33:40 +0800
>> From: "Michael Ash" <michael.ash...>
>>
>> On Tue, May 20, 2008 at 4:07 PM, Peter Duniho <peted...> wrote:
>>>
>>> But personally, it makes me nervous to have a language that allows the
>>> implementation of a class to change according to other code not related
>>> to
>>> the class. It's one thing if you're just adding a method that you want
>>> to
>>> use somewhere else. But in Objective-C you can also add a method that
>>> overrides a base class method, or would not normally exist in the class
>>> but
>>> which has meaning to some other code that might check for it.
>>
>> I'd just like to point out that the above applies to any OO language
>> which supports both subclassing and dynamic dispatch, which is to say
>> approximately all of them. Categories are certainly differently
>> powerful in this regard, and as such will get you into trouble in ways
>> that subclassing cannot, but subclassing already has this powerful and
>> dangerous semantic that you're worried about.
>
> No, it doesn't.
>
> Each language varies a bit, of course. But in the other popular languages
> that I know reasonably well -- C++, C#, Java -- a subclass does not have the
> ability to touch any part of the base implementation that is not
> specifically exposed by that implementation. Private members are invisible,
> and other members are only overridable when the base class allows it by
> making them virtual.
>
> There is, of course, hazard any time the base implementation makes this
> allowance. But those choices can be made on a member-by-member basis, and
> reliable decisions and assumptions can be made regarding the relative
> dependability of the base class on the basis of what that base class exposes
> to sub-classes. Many classes have _no_ overridable members and no
> "protected" members, and thus completely encapsulate their implementations.
> This is, in fact, the norm for these other languages.
This doesn't mean that they don't have this hazard, it just means that
the creator of a class is able to mitigate it.
That said, I have a difficult time emphasizing with this antagonistic
point of view that users of these languages tend to have. It's as
though the API writer is a sysadmin, and the API users are system
users, and the users must be prevented from doing anything to
adversely affect the system. I've found a cooperative approach to make
a lot more sense. The reason you avoid accessing other objects'
private instance variables isn't because you can't (you can do it in
any C-based language, of course, regardless of the access controls you
set), but because it's a bad idea and makes your code more brittle. So
it's tough to see how it makes a language better because it enforces
this kind of thing, when you can get essentially the same effect by
simply adding a comment that says "// do not override this method".
> Cocoa restrains class extension _much_ less than any of these other
> languages, and in turn has a _much_ higher degree of hazard.
>
> It's certainly a continuum. I agree we're not talking either/or,
> black/white, etc. here. Other languages aren't without their danger zones
> either. It just seems to me that Cocoa goes overboard, for relatively
> little payoff.
Objective-C, not Cocoa, of course. Although Cocoa's designed is
inextricably based on the features and capabilities of Objective-C.
If the above languages are the only other OO languages you know, then
the fact that you think that these features are inconsequential and
pointless, when we think they're essential and useful, is
unsurprising. It's normal to think that the features in a language you
know well are all essential, and that the features in a language you
don't know well are all fluff. I'm sure I do it with other languages.
If I may, I'd suggest checking out at least a couple of languages that
come closer to the sort of dynamism that ObjC gives you, such as
Python, Smalltalk, Ruby, Common Lisp's CLOS, and others. It may give
you a better appreciation both for Objective-C and for how Cocoa is
put together. Or it may just convince you that we're all crazy, it's
hard to say.
Mike -
First off: all well said! +1
...a few comments though. (Will this thread ever gonna stop? ;) )
> First, how much are you paying for the documentation? How much did
> you pay for the IDE? I mean, I'd love everything to be perfect for
> everybody, but let's be realistic here. Apple doesn't derive any
> direct income from the documentation or from Xcode, and as much as
> we might think that shouldn't matter, Apple's a corporation, so it's
> going to matter. That's reality, and it's not going to change.
> Resources are limited, and considering the resources that are
> available for API documentation, I think they do a phenomenal job,
> and I honestly hate that some of the comments in this thread could
> be read as disparaging their work, even if unintentionally.
Well, they are free to open source XCode and have other people help.
Look at Eclipse.
Paying for documentation is a weird thought though. Apple should be
happy to attract developers to have the platform flourish. That's an
investment you have to make if you want to be the controlling entity
of an operating system.
I think even for the documentation user generated content could be a
good way to "spice it up". This worked very well for PHP for example.
It would be valuable feedback for the tech writers. Just submitting
bugs to the documentation is not the same. We are entering the age of
user generated content. Let's not miss the boat here. Cocoadev is
great - but too separate.
> Thirdly, who is the target audience for the documentation. ... This
> recent influx of new coders is quite a sudden change to the
> demographic. Apple can't be expected to adjust to that change
> instantaneously. I don't think it's even completely clear yet who's
> coming to the platform right now and why.
Totally agree. But just looking at the thread (and the popularity of
the platforms) I would guess many people will have either a C# or Java
background.
> To the extent that people are trying to give feedback to Apple so
> they know how best to proceed with future revisions to the
> documentation, I think this discussion is valuable, but at times we
> veer dangerously close to a pissing match mentality, and when that
> happens, I don't think it's productive (even when it's me doing
> it :) )
It sometimes has come very close ...but I am still surprised how well
it went in general. Pat on the back to everyone. Such threads are a
breeding ground for flames.
> Now, if you're having a hard time with the documentation, and the
> third party books aren't closing the gap for you, maybe you should
> consider something like the classes at the Big Nerd Ranch, where you
> can get direct feedback and answers from people who do have the big
> picture and can work with you to help you get it too. It's probably
> the fastest way to get over the hump. Though this list is
> tremendously helpful, it's really better for answering concrete
> technical questions than theoretical or conceptual ones, which
> rarely yield the answer you're looking for, and often lead to long-
> winded discussions like this one ;)
I think face-to-face is an important part to overcome the obstacles.
And this will become easier the more popular it gets.
cheers
--
Torsten -
On Wed, May 21, 2008 at 8:49 AM, Peter Duniho <peted...> wrote:
> And again: it's not that I'm on a crusade to have Objective-C changed, or to
> have Cocoa made fully accessible via some other language. I just want
> people to have some empathy for what at least some of us go through upon
> encountering the one official Mac development environment. Stop telling us
> that our reactions aren't valid; for better or worse, these are our
> reactions and we can no more control them than you can stop breathing. They
> are ours and like it or not, they matter.
I'm getting lost as to whether your main objection is about Apple not
providing anything other than Objective-C / Cocoa to develop apps on
the Mac, or whether it's just that you think their documentation could
be improved.
If it's the former, I don't particularly see that your opinion
matters; any more than mine would matter if I wanted to use Cocoa on
Windows. (Unless of course you are a shareholder and you think that
this decision is having a tangible negative impact on the company's
value, but I don't think that's the basis of your argument.)
If it's the latter, would it satisfy you if, say, Apple made a book
such as Hillegaas' available online, for free?
Hamish -
On May 21, 2008, at 12:49 AM, Peter Duniho wrote:
> I have already acknowledged that opinions vary. You, being among
> the regular contributors to this mailing list, I fully expect to
> "think that Objective-C find a pragmatic sweet spot". Anything else
> would surprise me.
There are a lot of things I would like to change about Objective-C if
I could, but would my version end up having the same broad appeal?
With pragmatic I wanted to imply that I think that it manages to solve
a lot of problems without falling into the trap of being too "pure" in
any direction.
>> [...] Let's agree to re-visit this discussion one to two years from
>> now. I don't think that it's fair of us to expect you to provide an
>> informed comparison before you have more experiences with both
>> environments.
>
> You are simply proving my point.
>
> You reject my impressions simply because I have less experience with
> the language. You fail to have any sympathy whatsoever for my
> personal experience, and tell me that I will change my mind after
> using Cocoa for two more years.
That was not my intention. What I wanted to say is that I think that
we've probably taken this discussion as far as we can at this point,
but that I thought it would be interesting to come back to this same
topic at some later point when you have had a chance of getting to
know ObjC + Cocoa better. My hope was not that you at this point would
be either brain washed or departed. I clearly failed to communicate
this well enough, and I should also not assume to know how much
experience you already have on this platform. If I came across as
blunt and / or condescending, I apologize.
> And again: it's not that I'm on a crusade to have Objective-C
> changed, or to have Cocoa made fully accessible via some other
> language. I just want people to have some empathy for what at least
> some of us go through upon encountering the one official Mac
> development environment. Stop telling us that our reactions aren't
> valid; for better or worse, these are our reactions and we can no
> more control them than you can stop breathing. They are ours and
> like it or not, they matter.
I do respect both your first impressions, and your unique insight
based on experiences from other platforms. That's why I wrote this in
my other message to this thread:
>> We welcome input from new users to our platform. It's great to have
>> an influx of new people come with fresh ideas. Please file bug
>> reports for any concrete problems you find or suggestions that you
>> have
j o a r -
On May 21, 2008, at 3:06 AM, Scott Anguish wrote:
> I'm not sure that how much is being 'paid' for the documentation is
> a valid metric.
>
> I believe (not speaking for the company of course) that both of
> these areas are viewed as investments.
No, you're right, it's not a good metric, and I certainly don't want
you guys thinking that way. I guess my point was just that it's
important for us to keep it in perspective that Apple doesn't have
unlimited resources to handle the documentation tasks and that there
are third-party for-pay options that can fill the gap. Also, I meant
to point out that some of the comparisons that have been made in this
thread are comparing free offerings to decidedly non-free ones, which
isn't necessarily a fair comparison. I just think it's a good idea to
keep things in perspective and try and avoid a sense of entitlement
when we start discussing the way things should be. -
On May 21, 2008, at 4:31 AM, Torsten Curdt wrote:
> Well, they are free to open source XCode and have other people help.
> Look at Eclipse.
You can suggest it to them, but I wouldn't hold your breath. :)
Probably shouldn't open up that argument in this thread.
> Paying for documentation is a weird thought though. Apple should be
> happy to attract developers to have the platform flourish. That's an
> investment you have to make if you want to be the controlling entity
> of an operating system.
Yeah, I know... one of the drawbacks of writing late at night - this
point was not well stated. I didn't mean to imply Apple should start
charging for documentation, just that we (including me) sometimes feel
entitled, and I think what we've paid should be kept in mind when we
start to feel entitled.
> I think even for the documentation user generated content could be a
> good way to "spice it up". This worked very well for PHP for
> example. It would be valuable feedback for the tech writers. Just
> submitting bugs to the documentation is not the same. We are
> entering the age of user generated content. Let's not miss the boat
> here. Cocoadev is great - but too separate.
This sounds interesting, but I'm not clear on what your comment about
CocoaDev means, to be honest. The problem here, of course, is that
somebody has to take the initiative to get it started and nurse it
through the difficult start-up times until you get critical mass.
> I think face-to-face is an important part to overcome the obstacles.
> And this will become easier the more popular it gets.
Amen. I can't tell you how much I sometimes hate having moved away
from the SF Bay Area where there are many Cocoa Programmers, and there
are NSCoder nights, and CocoaHeads, and other opportunities to meet
other Cocoa programmers, to a place where Cocoa is only something you
drink after snowmobiling. Then I remember how much bigger my house is
here and how much less I paid for it and I feel a little better :) -
>> Well, they are free to open source XCode and have other people
>> help. Look at Eclipse.
>
> You can suggest it to them, but I wouldn't hold your breath. :)
> Probably shouldn't open up that argument in this thread.
No ...I don't hold my breath :)
>> I think even for the documentation user generated content could be
>> a good way to "spice it up". This worked very well for PHP for
>> example. It would be valuable feedback for the tech writers. Just
>> submitting bugs to the documentation is not the same. We are
>> entering the age of user generated content. Let's not miss the boat
>> here. Cocoadev is great - but too separate.
>
> This sounds interesting, but I'm not clear on what your comment
> about CocoaDev means, to be honest. The problem here, of course, is
> that somebody has to take the initiative to get it started and nurse
> it through the difficult start-up times until you get critical mass.
Well, I meant that cocoadev is a separate site. It's not like user can
leave code snippets and comments on the original documentation. (see
the user contributes notes http://www.php.net/manual/en/language.control-structures.php
) And I doubt tech writers at Apple will check on some external site
for feedback.
Not sure there is the need to nurse at all ...someone at Apple would
need to implement a comment feature on their site. Once that is in
place comments will trickle in.
>> I think face-to-face is an important part to overcome the
>> obstacles. And this will become easier the more popular it gets.
>
> Amen. I can't tell you how much I sometimes hate having moved away
> from the SF Bay Area where there are many Cocoa Programmers, and
> there are NSCoder nights, and CocoaHeads, and other opportunities to
> meet other Cocoa programmers, to a place where Cocoa is only
> something you drink after snowmobiling. Then I remember how much
> bigger my house is here and how much less I paid for it and I feel a
> little better :)
Hehehe ...I know what you mean. Europe is far far away from there.
cheers
--
Torsten -
>>>
>>> I think face-to-face is an important part to overcome the
>>> obstacles. And this will become easier the more popular it gets.
>>
>> Amen. I can't tell you how much I sometimes hate having moved away
>> from the SF Bay Area where there are many Cocoa Programmers, and
>> there are NSCoder nights, and CocoaHeads, and other opportunities
>> to meet other Cocoa programmers, to a place where Cocoa is only
>> something you drink after snowmobiling. Then I remember how much
>> bigger my house is here and how much less I paid for it and I feel
>> a little better :)
>
> Hehehe ...I know what you mean. Europe is far far away from there.
>
> cheers
And there is lots of country here (in Europe) where Cocoa does not
even mean something you can drink ;-) -
On 2008/05/21, at 13:59, Jean-Daniel Dupas wrote:
>
>>>>
>>>> I think face-to-face is an important part to overcome the
>>>> obstacles. And this will become easier the more popular it gets.
>>>
>>> Amen. I can't tell you how much I sometimes hate having moved away
>>> from the SF Bay Area where there are many Cocoa Programmers, and
>>> there are NSCoder nights, and CocoaHeads, and other opportunities
>>> to meet other Cocoa programmers, to a place where Cocoa is only
>>> something you drink after snowmobiling. Then I remember how much
>>> bigger my house is here and how much less I paid for it and I feel
>>> a little better :)
>>
>> Hehehe ...I know what you mean. Europe is far far away from there.
>>
>> cheers
>
>
> And there is lots of country here (in Europe) where Cocoa does not
> even mean something you can drink ;-)
>
>
And there are even some of us that live in European countries where
besides all that you also have to endure countless jokes from some
fellow coders working on other platforms because "Cocoa" sounds a bit
like the word used for "poop". :)
--
João Pavão
-
As I remember it, about 20% of DECs revenue stream came from
documentation, not software or hardware.
The English Department of my university produced a steady stream of
technical writers who went to DEC.
As you might imagine I come from a FORTRAN background followed by
procedural Pascal. Indeed Cocoa's
learning curve is steep but quite rewarding. Given my background, I'm
sure it's much steeper for me than for
someone with no programming background.
In general, I find Apple's documentation to be excellent and of much
higher quality than DECs. What is missing
for me is adequate code snippets and links to sample code. I tend to
learn how stuff works by playing with samples in the debugger.
I'll cite one example. I've been spending two weeks trying to get a
table to reloadData to a multi column NSTableView that
I created programmatically. Creating the table view was straightforward.
Getting it to populate is yet another matter. I've yet to
find an example of a TableView code sample that does this. Hillegass
uses a cute trick of using NSSpeechSynthesizer to
populate his dataSource but how about tables with multiple columns and
populating them in the first place. When I go to f
oundation documentation.
http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals
/CommunicatingWithObjects/chapter_6_section_4.html
doesn't show a code sample of a delegate. It says something about a
delegate being a NSResponder but doesn't even show a header example
of a delegate.
Similarly:
http://developer.apple.com/documentation/Cocoa/Conceptual/TableView/Tasks/U
singTableDataSource.html
Makes no mention of InterfaceBuilder and/or bindings. Some links to
relevant sample code here would really help.
Finally, I find the Research Assistant do be indispensable. But given
Cocoa's novel syntax, the class references
could be improved by some code snippets that show how to message the
different methods from the sender.
Joseph Ayers
Jeff LaMarche wrote:
>
> On May 21, 2008, at 3:06 AM, Scott Anguish wrote:
>
>> I'm not sure that how much is being 'paid' for the documentation is a
>> valid metric.
>>
>> I believe (not speaking for the company of course) that both of these
>> areas are viewed as investments.
>
> No, you're right, it's not a good metric, and I certainly don't want
> you guys thinking that way. I guess my point was just that it's
> important for us to keep it in perspective that Apple doesn't have
> unlimited resources to handle the documentation tasks and that there
> are third-party for-pay options that can fill the gap. Also, I meant
> to point out that some of the comparisons that have been made in this
> thread are comparing free offerings to decidedly non-free ones, which
> isn't necessarily a fair comparison. I just think it's a good idea to
> keep things in perspective and try and avoid a sense of entitlement
> when we start discussing the way things should be.
>
--
Joseph Ayers, Professor
Department of Biology and
Marine Science Center
Northeastern University
East Point, Nahant, MA 01908
Phone (781) 581-7370 x309(office), x335(lab)
Cellular (617) 755-7523, FAX: (781) 581-6076
Boston Office 444RI, (617) 373-4044
eMail: <lobster...>
http://www.neurotechnology.neu.edu/ -
Scott,
Thank you for taking time to reply. You must be getting pretty tired
of all this. Worse, this is not a documentation issue, it's an Apple
issue.
On May 20, 2008, at 11:51 PM, Scott Anguish wrote:
>[helpful pointers and other parts snipped]
>
> Ultimately, learning is a very personal experience and we all do it
> differently. I'm not surprised that there are issues for some
> developers with the docs. We do our best to get you what you need.
But don't you see how biased the system is against those "some
developers" who have issues? Those are exactly the people least likely
to complain and least likely to file bugs against the docs! And if
they do, the bugs are unlikely to be actionable because the issues
they are encountering are not specific enough or in the wrong terms.
If you experience just a tiny teeny number of people who voice
usability problems with such a powerful filter in place then you know
that the problem is large and real.
Don't you see how different the learning experience is for 100,000
iPhone developers in 2008 vs. a few hundred Next developers twenty
years ago? And the differences in motivation? And background? And
sponsorship?
Scott, you *are* doing your best, and you are doing a great job with
what you have. But I feel that there is a part of Apple that is in a
state of denial, and until that changes, we're stuck with bug reports
as a means of trying to change corporate vision. -
On May 21, 2008, at 9:45 AM, Steve Weller wrote:
> Don't you see how different the learning experience is for 100,000
> iPhone developers in 2008 vs. a few hundred Next developers twenty
> years ago? And the differences in motivation? And background? And
> sponsorship?
>
> Scott, you *are* doing your best, and you are doing a great job with
> what you have. But I feel that there is a part of Apple that is in a
> state of denial, and until that changes, we're stuck with bug
> reports as a means of trying to change corporate vision.
I think there's an assumption implicit in your argument that Apple
"must" or "should" make it easier for anybody and everybody who wants
to code for the Mac or the iPhone to do so quickly and easily. I'm not
sure it's necessarily a valid assumption, and I'm not sure Apple is in
denial of anything. Lowering the barriers to entry doesn't necessarily
serve them or their consumers better, it serves new developers who see
the iPhone as an opportunity but, obviously, there is no shortage of
people wanting to take advantage of that opportunity, so I'm not sure
why Apple would be motivated to change an approach that has worked
well for them for many years. In the long run, these initial
difficulties and problems, I would argue, actually keep the quality of
third party software up, which seems desirable from Apple's point of
view.
I'm not saying your concerns aren't valid, just that yours is one
perspective in a very complex equation, and possibly not as much of a
factor in the big picture as you might think. -
> denial of anything. Lowering the barriers to entry doesn't necessarily
> serve them or their consumers better, it serves new developers who see
> the iPhone as an opportunity but, obviously, there is no shortage of
> people wanting to take advantage of that opportunity, so I'm not sure
Good point, the things that matters is market share, the PS2 was a nightmare to develop for but it has not dissuaded companies to make games for.
Look at the things done with jail-broken iPhone/iPod, no documentation, only classdump and nm etc...
Obviously, a good documentation is very important in the long run, and I am pretty happy to see that Tools, ObjC and Docs have so matured :)
Regards
Gerard -
Am 21.05.2008 um 15:12 Uhr schrieb Joseph Ayers:
> I'll cite one example. I've been spending two weeks trying to get a
> table to reloadData to a multi column NSTableView that
> I created programmatically. Creating the table view was
> straightforward. Getting it to populate is yet another matter. I've
> yet to find an example of a TableView code sample that does this.
Did you ask Google?
http://www.google.com/search?q=nstableview+delegate+sample
The fourth hit - from MacDevCenter - seems to cover the topic nicely.
(Though you point out that you created the table view
programmatically, I don't the why that should be relevant. So maybe I
didn't really understand what you are looking for.)
Andreas -
Sorry for the caps, not sure how else to try and get everyone's
attention.
This thread has been interesting and useful. In order to continue to
keep it so (if there is even anything left to be said) please keep in
mind the following.
- Don't debate the languages involved. Objective-C is the reality.
Selected other languages are supported via bridging.
- Keep personal messages off the list. If it isn't likely to be
relevant to a large number of list subscribers, please send the
message off list. If you're not sure, contact the admins.
Finally, there are mechanisms in place to provide feedback on what the
docs cover, what they don't, and that entire process. Every
documentation page has a link that allows you to do that for the
specific document. If you have general issues, please file them using
bugreporter. Doing this will get them into our tracking system.
The other option for providing overall feedback on the documentation,
sample code, and the developer experience in general is by contacting
WorldWide Developer Relations (WWDR).
I am in no way attempting to stifle the discussion. But it does need
to be shepherded to the appropriate forums (which in this case may not
be this particular forum). -
On May 21, 2008, at 12:52 AM, Peter Duniho wrote:
>
> Cocoa restrains class extension _much_ less than any of these other
> languages, and in turn has a _much_ higher degree of hazard.
I think you're overestimating the hazard. Or, at least, the risk that
it can be encountered accidentally.
It's not like Categories haven't been used in 'serious' software,
after all.
In the 90s, NeXTSTEP and Objective-C (with Categories) were safe
enough to be used for investment bank trading systems (derivatives,
fixed income trading, that kind of thing) that safely handled vast
numbers of high-value transactions (hundreds of millions of dollars
each and up).
It's possible to conceive of theoretical situations in which things
could go badly pear-shaped due to a Category. In practice, because of
the ways people typically use Categories, it just hasn't been that
big of an issue. -
On May 21, 2008, at 1:42 AM, Hamish Allan wrote:
> I'm getting lost as to whether your main objection is about Apple not
> providing anything other than Objective-C / Cocoa to develop apps on
> the Mac, or whether it's just that you think their documentation could
> be improved.
Sorry, that's fair. I have a number of concerns, and I admit that I
tend to hop around a little (we have one subject description but
really several side-topics related to it).
As far as your question goes, the answer is "neither". And "both".
My _main_ objection is how newcomers to Mac development are treated.
Please, when someone new to the current Mac development environment
brings up one or more of these points, don't say "well, you're too
inexperienced to see why [Obj-C|Cocoa|the documentation|the tools] is/
are so great". Don't say "you're riff-raff, it's supposed to be
hard, we _like_ that it's keeping you out". Don't say "you must not
have read the conceptual guides, otherwise all this would be clear".
Or any of the other condescending, presumptuous things that I've seen
said on a semi-regular basis.
The fact is, any of those _might_ be true with respect to a specific
person. But they aren't necessarily so, and whether it is true or
not, it's counter-productive.
Instead, say something like "your complaint is a common one, you
aren't alone, and [most importantly] it's legitimate to have these
concerns", acknowledging that even if someone's concern is somewhat
irrelevant (being regarding a fundamental design aspect of the
language or framework, for example), it does color their perception
and affect how they approach the development environment. And then
move directly to offering specific and constructive help with
specific problems. If someone has failed to state their own concerns
or problems in a way that allows for this kind of specific,
constructive help, just ask questions that will elicit the kind of
details that would allow for that.
There are in fact specific things about the development environment
that I think can be improved, and I'd start with the documentation.
Would making an authoritative text like Hillegaas's book available
free online be welcome? Sure. But ultimately, some thought needs to
be put into how to make the regular documentation better. More code
samples (if not embedded itself, then at least with prominent links
embedded within the relevant topic), links to relevant guides where
Cocoa concepts are referenced but not defined, fleshing out of
specific techniques, and most importantly: keeping the information up-
to-date (don't tell me to use a tool that's not even included with
the development environment any more, and make sure tool-specific
documentation refers to the version of the tool that is current).
But mainly treating people's own impressions and feelings with more
respect would go a long way. I recognize that this isn't something
most programmers are naturally good at, but inasmuch as the Mac is
_supposed_ to be the more "human" platform, IMHO it makes sense that
the developer community could stand to observe the more "human"
aspects of interpersonal communication.
And by the way, as far as the "shareholder" part of your reply goes:
I don't hold Apple stock directly. But everyone who relies on
Apple's hardware and software as part of their business, or has any
vested interest in the success of the Mac, is in some way a
shareholder. In that sense I am a shareholder, and it does concern
me to see things that limit the potential success of the Mac. I
think it's great that Apple has been able to expand their market
share a bit, but it remains to be seen whether their momentum can
continue without some fundamental improvements in developer support
(why this is, is a whole other topic unto itself, so I won't get into
the specifics here).
Pete -
On May 21, 2008, at 1:30 PM, Peter Duniho wrote:
> My _main_ objection is how newcomers to Mac development are
> treated. Please, when someone new to the current Mac development
> environment brings up one or more of these points, don't say "well,
> you're too inexperienced to see why [Obj-C|Cocoa|the documentation|
> the tools] is/are so great". Don't say "you're riff-raff, it's
> supposed to be hard, we _like_ that it's keeping you out". Don't
> say "you must not have read the conceptual guides, otherwise all
> this would be clear". Or any of the other condescending,
> presumptuous things that I've seen said on a semi-regular basis
Okay, first, Scott, my apologies - I'm letting the thread die after
this -- promise -- but needed to respond to this one tiny point.
Pete - you complain that people should treat newcomers better, yet
here you are characterizing what many of us have said in a blatantly
antagonistic way. Riff-raff? We "like" that it's keeping you out?
Nobody said any such thing. It may be that people won't want to help
you now, but not because you're a newcomer, but rather because you're
baiting people and unfairly characterizing our words and our
intentions. Don't ascribe ill-will to people who tell you things you
don't agree with or don't accept as true. I guarantee you that every
response was an honest attempt to help. -
On Wed, May 21, 2008 at 1:30 PM, Peter Duniho <peted...> wrote:
My _main_ objection is how newcomers to Mac development are treated.
> Please, when someone new to the current Mac development environment brings
> up one or more of these points, don't say "well, you're too inexperienced to
> see why [Obj-C|Cocoa|the documentation|the tools] is/are so great".
Why not? When the question is along the lines of "why isn't this exactly
like C++/Java/Whatever," and the person asking it is a newbie, then the
answer probably really is a subtle design decision that's beyond the
newbie's current experience level.
Don't say "you're riff-raff, it's supposed to be hard, we _like_ that it's
> keeping you out".
No one has. IMHO, you're being *way* too defensive here, and reading far
more between the lines than the people you're talking to have been putting
there.
> Don't say "you must not have read the conceptual guides, otherwise all this
> would be clear". Or any of the other condescending, presumptuous things
> that I've seen said on a semi-regular basis.
When someone is *demonstrating* that they haven't put any real effort into
doing their own research, it's not a presumption. When someone asks
questions that *are* clearly answered in the available docs, it's neither
condescending nor presumptuous to point them to said docs. In fact, it'd be
a disservice to them to offer my own half-baked summary of the docs, rather
than point to the authoritative source.
Instead, say something like "your complaint is a common one, you aren't
> alone, and [most importantly] it's legitimate to have these concerns",
> acknowledging that even if someone's concern is somewhat irrelevant (being
> regarding a fundamental design aspect of the language or framework, for
> example), it does color their perception and affect how they approach the
> development environment.
I'm sorry, but I couldn't disagree more strongly. This is a technical forum,
and such places are long on technical detail and very, very short on warm
fuzzies. If you want to know the technical reasons for specific design
decisions, you can find that out by asking here. If you want to have your
feelings validated, you'd be better off asking Dr. Phil.
This, I think, may be at or close to the root of your difficulties here.
You're interpreting the highly-technical and somewhat emotionally cold
atmosphere as hostile, and responding to that perceived hostility. But the
people you're talking to are not being purposefully hostile to you, or to
any other newbie, and your continuous insistence that we must be doing so is
getting in the way of communication.
And then move directly to offering specific and constructive help with
> specific problems.
I've been seeing (and receiving) precisely that kind of help here for about
eight years now. Maybe it's because I did my own homework first, and didn't
spend a week demanding "more respect" from everyone who failed to agree with
me 100%?
> But mainly treating people's own impressions and feelings with more respect
> would go a long way.
This list is about finding help with solving your programming problems, not
about helping you deal with your feelings. The technical issues being
discussed here are black and white, and when someone is wrong they're wrong,
regardless of how badly they might feel about it. This list, as with all
technical lists, is somewhat cold and clinical in nature, but I've yet to
see any huge number of people being treated with outright hostility or
disrespect.
In all honesty, I think that expecting emotional validation from a technical
mailing list isn't terribly realistic. If that kind of thing is what you
need, you'd be better off adopting a puppy.
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net -
On Wed, May 21, 2008 at 12:14 PM, Jeff LaMarche <jeff_lamarche...> wrote:
>
> On May 21, 2008, at 1:30 PM, Peter Duniho wrote:
>
>> My _main_ objection is how newcomers to Mac development are treated.
>> Please, when someone new to the current Mac development environment brings
>> up one or more of these points, don't say "well, you're too inexperienced to
>> see why [Obj-C|Cocoa|the documentation|the tools] is/are so great". Don't
>> say "you're riff-raff, it's supposed to be hard, we _like_ that it's keeping
>> you out". Don't say "you must not have read the conceptual guides,
>> otherwise all this would be clear". Or any of the other condescending,
>> presumptuous things that I've seen said on a semi-regular basis
>
> Okay, first, Scott, my apologies - I'm letting the thread die after this --
> promise -- but needed to respond to this one tiny point.
>
> Pete - you complain that people should treat newcomers better, yet here you
> are characterizing what many of us have said in a blatantly antagonistic
> way. Riff-raff? We "like" that it's keeping you out? Nobody said any such
> thing. It may be that people won't want to help you now, but not because
> you're a newcomer, but rather because you're baiting people and unfairly
> characterizing our words and our intentions. Don't ascribe ill-will to
> people who tell you things you don't agree with or don't accept as true. I
> guarantee you that every response was an honest attempt to help.
Thank you, Jeff.
You phrased this much better, and in a much more constructive way than
my own initial response.
Let me emphasize one more piece of constructive advice - if you do not
like the docs and examples, file bugs on each and every page that
specifically failed you, with real details. I heard at least one
respondent state that they were too busy to list any explicit examples
of doc failures, but that they saw lots. Not filing the bugs that
annoyed you is bowing out of the only process that can correct the
official docs.
The docs are far from perfect for all comers, and the authors have no
way of knowing how they failed you, and why you thought any specific
page was the right place to look.
Web Objects tutorials, at least when I went through them last, tend to
have a robocode section, followed by an explanation. Without fail,
the people I have guided through them stalled when they hit something
they did not understand, rather than reading a few paragraphs forwards
for a definition. Just a short note that 'foo, bar, and the baz
method are defined after the example' would have helped. And yes, I
commented on those pages when I last went through them.
File an issue, and state as clearly as you can how you got the page in
question, why you thought it would help, and exactly how it did not.
You may not be able to say what the content should have been, but if
the docs folks know that you honestly expected a discussion on Garbage
Collection in the NSArray docs, they can at least consider linking to
the conceptual guide with a message whose text would have gotten your
interest.
Scott -
I don't believe Peter Duniho's barking up the wrong tree - he sees
room for improvement, and wants to discuss what to do to make it
happen. I.e. he appears to care about making the platform better
(probably something we all share)...
These are the main valid issues from my point of view:
1 Apple's docs, particularly in relation to Objective-C & Cocoa, have
some room for improvement:
- e.g. navigation (can't go back to list of methods after clicking
a method name hyperlink for example)
- lack of and generally un-useful sample code
- too much "cocoa is wonderful" vs. not enough dry detail
2 Cocoa requires you when learning to implement things by clicking and
dragging, which makes learning harder for some people (this is a real
annoyance to me, why can we not see/edit these connections in a text
file? why is there so much other crap in the nib xml? etc).
3 There's a belief (among) that Cocoa is in some way special and these
documentation (or more general) shortcomings/issues are not relevant
or real or justified.
So, ignoring my usual cynicism (I don't believe there's much that us
developers can do to contribute to improving the documentation, or the
fact that dragging connections is necessary, though I do submit
feedback when I see a clearly-fixable issue), I think it is very valid
to raise such issues and discuss them on the mailing list.
thanks for a very interesting and enlightening discussion
Rua HM.
On May 22, 2008, at 5:30 AM, Peter Duniho wrote:
> On May 21, 2008, at 1:42 AM, Hamish Allan wrote:
>
>> I'm getting lost as to whether your main objection is about Apple not
>> providing anything other than Objective-C / Cocoa to develop apps on
>> the Mac, or whether it's just that you think their documentation
>> could
>> be improved.
>
> Sorry, that's fair. I have a number of concerns, and I admit that I
> tend to hop around a little (we have one subject description but
> really several side-topics related to it).
>
> As far as your question goes, the answer is "neither". And "both".
>
> My _main_ objection is how newcomers to Mac development are
> treated. Please, when someone new to the current Mac development
> environment brings up one or more of these points, don't say "well,
> you're too inexperienced to see why [Obj-C|Cocoa|the documentation|
> the tools] is/are so great". Don't say "you're riff-raff, it's
> supposed to be hard, we _like_ that it's keeping you out". Don't
> say "you must not have read the conceptual guides, otherwise all
> this would be clear". Or any of the other condescending,
> presumptuous things that I've seen said on a semi-regular basis.
>
> The fact is, any of those _might_ be true with respect to a specific
> person. But they aren't necessarily so, and whether it is true or
> not, it's counter-productive.
>
> Instead, say something like "your complaint is a common one, you
> aren't alone, and [most importantly] it's legitimate to have these
> concerns", acknowledging that even if someone's concern is somewhat
> irrelevant (being regarding a fundamental design aspect of the
> language or framework, for example), it does color their perception
> and affect how they approach the development environment. And then
> move directly to offering specific and constructive help with
> specific problems. If someone has failed to state their own
> concerns or problems in a way that allows for this kind of specific,
> constructive help, just ask questions that will elicit the kind of
> details that would allow for that.
>
> There are in fact specific things about the development environment
> that I think can be improved, and I'd start with the documentation.
> Would making an authoritative text like Hillegaas's book available
> free online be welcome? Sure. But ultimately, some thought needs
> to be put into how to make the regular documentation better. More
> code samples (if not embedded itself, then at least with prominent
> links embedded within the relevant topic), links to relevant guides
> where Cocoa concepts are referenced but not defined, fleshing out of
> specific techniques, and most importantly: keeping the information
> up-to-date (don't tell me to use a tool that's not even included
> with the development environment any more, and make sure tool-
> specific documentation refers to the version of the tool that is
> current).
>
> But mainly treating people's own impressions and feelings with more
> respect would go a long way. I recognize that this isn't something
> most programmers are naturally good at, but inasmuch as the Mac is
> _supposed_ to be the more "human" platform, IMHO it makes sense that
> the developer community could stand to observe the more "human"
> aspects of interpersonal communication.
>
> And by the way, as far as the "shareholder" part of your reply goes:
> I don't hold Apple stock directly. But everyone who relies on
> Apple's hardware and software as part of their business, or has any
> vested interest in the success of the Mac, is in some way a
> shareholder. In that sense I am a shareholder, and it does concern
> me to see things that limit the potential success of the Mac. I
> think it's great that Apple has been able to expand their market
> share a bit, but it remains to be seen whether their momentum can
> continue without some fundamental improvements in developer support
> (why this is, is a whole other topic unto itself, so I won't get
> into the specifics here).
>
> Pete
-
On 21 May 2008, at 23:58, Rua Haszard Morris wrote:
> I don't believe Peter Duniho's barking up the wrong tree - he sees
> room for improvement, and wants to discuss what to do to make it
> happen. I.e. he appears to care about making the platform better
> (probably something we all share)...
>
> These are the main valid issues from my point of view:
>
> 1 Apple's docs, particularly in relation to Objective-C & Cocoa,
> have some room for improvement:
> - e.g. navigation (can't go back to list of methods after clicking
> a method name hyperlink for example)
In my experience Backspace or Command-{ does this pretty well.
>
> - lack of and generally un-useful sample code
> - too much "cocoa is wonderful" vs. not enough dry detail
>
> 2 Cocoa requires you when learning to implement things by clicking
> and dragging, which makes learning harder for some people (this is a
> real annoyance to me, why can we not see/edit these connections in a
> text file? why is there so much other crap in the nib xml? etc).
>
> 3 There's a belief (among) that Cocoa is in some way special and
> these documentation (or more general) shortcomings/issues are not
> relevant or real or justified.
>
> So, ignoring my usual cynicism (I don't believe there's much that us
> developers can do to contribute to improving the documentation, or
> the fact that dragging connections is necessary, though I do submit
> feedback when I see a clearly-fixable issue), I think it is very
> valid to raise such issues and discuss them on the mailing list.
>
> thanks for a very interesting and enlightening discussion
> Rua HM.
>
> On May 22, 2008, at 5:30 AM, Peter Duniho wrote:
>
>> On May 21, 2008, at 1:42 AM, Hamish Allan wrote:
>>
>>> I'm getting lost as to whether your main objection is about Apple
>>> not
>>> providing anything other than Objective-C / Cocoa to develop apps on
>>> the Mac, or whether it's just that you think their documentation
>>> could
>>> be improved.
>>
>> Sorry, that's fair. I have a number of concerns, and I admit that
>> I tend to hop around a little (we have one subject description but
>> really several side-topics related to it).
>>
>> As far as your question goes, the answer is "neither". And "both".
>>
>> My _main_ objection is how newcomers to Mac development are
>> treated. Please, when someone new to the current Mac development
>> environment brings up one or more of these points, don't say "well,
>> you're too inexperienced to see why [Obj-C|Cocoa|the documentation|
>> the tools] is/are so great". Don't say "you're riff-raff, it's
>> supposed to be hard, we _like_ that it's keeping you out". Don't
>> say "you must not have read the conceptual guides, otherwise all
>> this would be clear". Or any of the other condescending,
>> presumptuous things that I've seen said on a semi-regular basis.
>>
>> The fact is, any of those _might_ be true with respect to a
>> specific person. But they aren't necessarily so, and whether it is
>> true or not, it's counter-productive.
>>
>> Instead, say something like "your complaint is a common one, you
>> aren't alone, and [most importantly] it's legitimate to have these
>> concerns", acknowledging that even if someone's concern is somewhat
>> irrelevant (being regarding a fundamental design aspect of the
>> language or framework, for example), it does color their perception
>> and affect how they approach the development environment. And then
>> move directly to offering specific and constructive help with
>> specific problems. If someone has failed to state their own
>> concerns or problems in a way that allows for this kind of
>> specific, constructive help, just ask questions that will elicit
>> the kind of details that would allow for that.
>>
>> There are in fact specific things about the development environment
>> that I think can be improved, and I'd start with the
>> documentation. Would making an authoritative text like Hillegaas's
>> book available free online be welcome? Sure. But ultimately, some
>> thought needs to be put into how to make the regular documentation
>> better. More code samples (if not embedded itself, then at least
>> with prominent links embedded within the relevant topic), links to
>> relevant guides where Cocoa concepts are referenced but not
>> defined, fleshing out of specific techniques, and most importantly:
>> keeping the information up-to-date (don't tell me to use a tool
>> that's not even included with the development environment any more,
>> and make sure tool-specific documentation refers to the version of
>> the tool that is current).
>>
>> But mainly treating people's own impressions and feelings with more
>> respect would go a long way. I recognize that this isn't something
>> most programmers are naturally good at, but inasmuch as the Mac is
>> _supposed_ to be the more "human" platform, IMHO it makes sense
>> that the developer community could stand to observe the more
>> "human" aspects of interpersonal communication.
>>
>> And by the way, as far as the "shareholder" part of your reply
>> goes: I don't hold Apple stock directly. But everyone who relies
>> on Apple's hardware and software as part of their business, or has
>> any vested interest in the success of the Mac, is in some way a
>> shareholder. In that sense I am a shareholder, and it does concern
>> me to see things that limit the potential success of the Mac. I
>> think it's great that Apple has been able to expand their market
>> share a bit, but it remains to be seen whether their momentum can
>> continue without some fundamental improvements in developer support
>> (why this is, is a whole other topic unto itself, so I won't get
>> into the specifics here).
>>
>> Pete
-
On Wed, May 21, 2008 at 6:58 PM, Rua Haszard Morris
<r.haszardmorris...> wrote:
> 2 Cocoa requires you when learning to implement things by clicking and
> dragging, which makes learning harder for some people (this is a real
> annoyance to me, why can we not see/edit these connections in a text file?
> why is there so much other crap in the nib xml? etc).
The fact that you have an XML version of the NIB is ancillary; it does
not exist to support editing by hand. It's there so that version
control systems which choke on binary files can handle NIBs better.
You're right that Cocoa -- or, more specifically, AppKit -- requires
you to click-and-drag a lot of things when developing. But why is
"seeing it all in a text file" superior? I fail to see how it's
anything but *inferior*, because you're not writing code when you're
doing the clicky-draggy-line-drawy part of AppKit development. This
is a very fundamental stumbling block for a lot of people who are used
to developing on other platforms, but it's really one of those things
you have to take on faith and just understand this is not your
previous environment.
> 3 There's a belief (among) that Cocoa is in some way special and these
> documentation (or more general) shortcomings/issues are not relevant or real
> or justified.
I actually think you're talking about two separate concerns. Cocoa is
very special, because it implements patterns that no other widely-used
framework does, and applies them rigorously and consistently. And I
think a lot of issues with the documentation are imaginary, or are a
result of not accepting or fully understanding how Cocoa differs from
previously-experienced platforms. Then again, I have been seeing a
lot of legitimate complaints arising recently in this thread and
others.
All I can say about this topic is that I ran into brick wall after
brick wall when learning Cocoa until one day when everything just
clicked. Like when I was studying statistics. Or the
Knuth-Morris-Pratt algorithm. You just have to say "I'm lost, I'll
keep clicking and dragging and voraciously reading and re-reading the
introductory, conceptual documentation until I get it, despite my
decade of software development experience."
--Kyle Sluder -
I'm curious:
On May 21, 2008, at 3:58 PM, Rua Haszard Morris wrote:
> - lack of and generally un-useful sample code
There is quite a lot of sample code at developer.apple.com. Did you
know? What would make it more useful?
> - too much "cocoa is wonderful" vs. not enough dry detail
So several people have alleged. Looking at the documentation, I'm not
finding anything that seems to qualify as hype. Could you provide some
links?
Wil -
> Date: Wed, 21 May 2008 15:14:24 -0400
> From: Jeff LaMarche <jeff_lamarche...>
>
> Pete - you complain that people should treat newcomers better, yet
> here you are characterizing what many of us have said in a blatantly
> antagonistic way. Riff-raff? We "like" that it's keeping you out?
> Nobody said any such thing.
As I wrote in my other reply to Sherm:
> Of course they have. I don't see any other way to read this message:
> http://lists.apple.com/archives/Cocoa-dev/2008/May/msg01604.html
>
> Shortly after, another poster replied for the sole purpose of
> agreeing with the sentiment:
> http://lists.apple.com/archives/Cocoa-dev/2008/May/msg01667.html
>
> It's true, the phrase "riff-raff" wasn't actually used. But it's
> the essence of what was written.
I don't know why it is you guys didn't notice those particular
statements, and I agree that they aren't representative of the bulk
of the comments. But it's not true that that sort of sentiment is
never expressed. I've seen it before, and it came up rather directly
in this thread. Not one single member of the community spoke out
against the sentiment, which only lends it more credibility.
Pete -
On May 21, 2008, at 12:27 PM, Sherm Pendley wrote:
> On Wed, May 21, 2008 at 1:30 PM, Peter Duniho <peted...>
> wrote:
>
>> My _main_ objection is how newcomers to Mac development are
>> treated. Please, when someone new to the current Mac development
>> environment brings up one or more of these points, don't say
>> "well, you're too inexperienced to see why [Obj-C|Cocoa|the
>> documentation|the tools] is/are so great".
>
> Why not?
Because it's not an appropriate answer.
> When the question is along the lines of "why isn't this exactly
> like C++/Java/Whatever," and the person asking it is a newbie, then
> the answer probably really is a subtle design decision that's
> beyond the newbie's current experience level.
I disagree in several respects. First, you're assuming a question.
That's not always the question being asked. Second, it's a fair
question. Inasmuch as there is an answer, provide the answer rather
than belittling the questioner. Third, making assumptions about what
the questioner can understand is offensive. I have taught C++, C#,
and Java concepts to people who have little to no OOP experience at
all. Presented properly, there is no problem. When they ask "why is
this beneficial to me?" or "why should I bother to learn this?", I
don't tell them "well, just do as I say and in a couple of years
you'll understand". I answer the question. More often than not,
they understand completely.
>> Don't say "you're riff-raff, it's supposed to be hard, we _like_
>> that it's keeping you out".
>
> No one has.
Of course they have. I don't see any other way to read this message:
http://lists.apple.com/archives/Cocoa-dev/2008/May/msg01604.html
Shortly after, another poster replied for the sole purpose of
agreeing with the sentiment:
http://lists.apple.com/archives/Cocoa-dev/2008/May/msg01667.html
It's true, the phrase "riff-raff" wasn't actually used. But it's the
essence of what was written.
> IMHO, you're being *way* too defensive here, and reading far more
> between the lines than the people you're talking to have been
> putting there.
I'm not reading between the lines. People are explicitly stating the
opinions I've described.
>> Don't say "you must not have read the conceptual guides, otherwise
>> all this would be clear". Or any of the other condescending,
>> presumptuous things that I've seen said on a semi-regular basis.
>
> When someone is *demonstrating* that they haven't put any real
> effort into doing their own research, it's not a presumption.
I'm not talking about that. I'm talking about people like me who
_have_ read all of the conceptual guides and who still run into
problems.
> When someone asks questions that *are* clearly answered in the
> available docs, it's neither condescending nor presumptuous to
> point them to said docs. In fact, it'd be a disservice to them to
> offer my own half-baked summary of the docs, rather than point to
> the authoritative source.
I'm not talking about "questions that *are* clearly answered in the
available docs". That's the whole point. And I'm not talking about
replies that simply refer to the documentation.
Just because _you_ think the answers are clearly answered in the
available docs, that doesn't mean that they actually are, nor does it
mean that you have any excuse for doing anything more than just
referencing the docs.
>> Instead, say something like "your complaint is a common one, you
>> aren't alone, and [most importantly] it's legitimate to have these
>> concerns", acknowledging that even if someone's concern is
>> somewhat irrelevant (being regarding a fundamental design aspect
>> of the language or framework, for example), it does color their
>> perception and affect how they approach the development environment.
>
> I'm sorry, but I couldn't disagree more strongly. This is a
> technical forum, and such places are long on technical detail and
> very, very short on warm fuzzies.
But you're wrong. The replies I'm talking about are NOT "long on
technical detail". They are smug and condescending, and at the same
time fail to answer the question that was asked.
If people were only sticking to the technical details, your statement
would make sense. But the moment that people start ascribing to
someone else motivations or failures or anything else that is not
based on a solid technical fact, they have opened the door to
complaints about how a person is treated.
> If you want to know the technical reasons for specific design
> decisions, you can find that out by asking here. If you want to
> have your feelings validated, you'd be better off asking Dr. Phil.
If all people were doing was answering technical questions
technically, that would be fine. But they aren't.
> This, I think, may be at or close to the root of your difficulties
> here. You're interpreting the highly-technical and somewhat
> emotionally cold atmosphere as hostile, and responding to that
> perceived hostility. But the people you're talking to are not being
> purposefully hostile to you, or to any other newbie, and your
> continuous insistence that we must be doing so i