Re: Cocoa et al as HCI usability problem
Re: Cocoa et al as HCI usability problem
- Subject: Re: Cocoa et al as HCI usability problem
- From: Erik Buck <email@hidden>
- Date: Mon, 19 May 2008 02:35:12 -0400
FROM : Peter Duniho
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).
That's odd. I see endless complaints about WPF and Microsoft's half
hearted support and poor documentation.
[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 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.
Here are some interesting comparisons between Cocoa and .Net from
the .Net Addicts Blog: http://dotnetaddict.dotnetdevelopersjournal.com/tags/?/cocoa
[deleted]
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.
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.
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]
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!
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.
[deleted]
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?
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 ?
[deleted]
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.
Apparently the docs don't spend enough time explaining incredibly
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]
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]
I agree. All forms of Apple help are useless. Apple used to provide
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
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.
Language preference is a preference. It's subjective. Some people
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, 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
There are many explanations for why dynamic languages are beneficial.
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.
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. 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.
[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
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.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden