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 <[EMAIL PROTECTED]>
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
_______________________________________________
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]
