Date: Mon, 19 May 2008 19:50:57 +0800
From: "Michael Ash" <[EMAIL PROTECTED]>
[...] 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
_______________________________________________
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]
