Date: Mon, 19 May 2008 02:35:12 -0400
From: Erik Buck <[EMAIL PROTECTED]>
[...] 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
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
