Re: Re: Learning Cocoa with RubyCocoa (was Regular Expressions)
Re: Re: Learning Cocoa with RubyCocoa (was Regular Expressions)
- Subject: Re: Re: Learning Cocoa with RubyCocoa (was Regular Expressions)
- From: WT <email@hidden>
- Date: Sat, 7 Jun 2008 22:07:10 +0200
Michael Ash said:
I disagree with your assessment that there's nothing in ObjC that
isn't done better in Java
If you read my message again, I think you'll see that I didn't go as
far as to say that, or even to suggest it. In fact, I explicitly
mentioned features of Obj-C that are useful, and non-existing in Java.
The fact is that ObjC's C nature is an enormous advantage, not a
disadvantage as you paint it.
Once again, I think you undeservedly interpreted my words in an
extreme way. I didn't paint Obj-C's C nature as being intrinsically a
disadvantage. I merely voiced my opinion that notions such as header
files, pointers, and manual memory management are things of the past.
Having said that, I *do* think that exposing pointers and requiring
programmers to manually manage memory *are* major disadvantages these
days, when applications are bigger and more intricate than ever. How
many hours of debugging time have been spent tracking memory problems
due to mismanaged pointers?
...the C integration brings enormous foibles. But that same C
integration also brings enormous advantages.
As with anything, it always boils down to a trade-off. Integrating
Cocoa with <substitute your favorite language here> would have its own
trade-offs as well.
You can directly call any C-based library on the system, which is
essentially all of them. You can drop in any portable C or C++ code
you happen to have, which is often a lot.
The existence of a large library base is also true of Java. Since
every copy of OS X comes with Java built-in, one has access to a large
number of well-tested libraries. Case in point: dealing with regular
expressions (a recent hot topic in this list).
I don't mean to make a case explicitly for Java (or to make a case at
all - I'm just voicing an opinion, not making a request for Apple to
change anything!). The bigger point I was trying to make is that, as
with any language, there are design choices in C that years of
practice have shown to have been poor choices. Unfortunately for us,
we're stuck with them because Obj-C sits on top of C.
All I was trying to convey with my previous message is the suspicion
that Apple would choose a different native language for Cocoa if they
were to wipe the slate clean and redesign Cocoa from scratch, knowing
what we all know today. I say that because of the OO additions (and
garbage collection in Obj-C 2.0), because there really isn't anything
in C that is essential for Cocoa to work, and because C brings with it
features that are either pretty much useless (such as header files) or
annoying to deal with (such as include cycles) or downright dangerous
(pointers and manual memory management).
Wagner
_______________________________________________
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