D versus Objective C Comparison

[John Reimer]

Hello Chris,

> John Reimer wrote:
> 
>> Hello Chris,
>> 
>>> http://www.fsdev.net/~cmiller/a/20090123_dvobjc.html
>>> 
>>> Also, I do honor the right of reply.  If there's something I have
>>> written that is now incorrect or inaccurate I will of course change
>>> my page to reflect that.  Heck, all the comparisons in the world are
>>> worthless if they aren't accurate!
>>> 
>>> Have a great day, and keep up the good work!  I personally can't
>>> wait until D gets to the point that a (total bonehead) like me can
>>> install it on OS X!  Alas, right now it seemeth to require more
>>> brain cells than I have at my disposal.
>>> 
>> Here's a couple comments:
>> 
>> (1) I'm surprised that, in your Objective C introduction, you don't
>> indicate that the langauge is a direct decendant of Smalltalk.
>> Interestingly you mention Smalltalk in the D introduction instead,
>> even though the only similarity between the two is that they both
>> implement a form of OO programming.  Objective C is practically C
>> with embedded Smalltalk. A major purpose for the creation of
>> Objective C was to bring the benefits and explicit OO style of
>> SmallTalk to C language developers.
>> 
> To me it seems that every language borrows from SmallTalk.  So I
> prefer to just ignore it as the father or all modern language design
> patterns.
> 
> I link to stuff so that people can do more reading if they want. :)
> 
> And again, I'm not there to really give a history lesson, more to
> analyze the situation of "you want to build an app which does foo,
> which is better for that purpose?"  (the answer is that it depends:
> who do you want to support?  Windows and Linux, or OS X?)
> 


As you wish, but I still think you left out a fairly distinct part of Objective 
C introduction: it's what makes it Objective C.  I say this because your 
mention of it is more appropriate on that side of the Objective-C introduction 
than the D one.   Not all OOP languages are alike.


>> (2)  The DWT port doesn't support 64-bit platforms (so far as I
>> know), so I don't understand why this is called a bug.  The two ports
>> of SWT that are currently supported are dwt-win and dwt-linux, both
>> 32-bit versions and dependent on a 32-compiler (dmd for x86).
>> dwt-mac is still in development by Jacob Carlborg: this version is
>> compiled with gdc for Mac and is also 32-bit, so far as I know.
>> 
> Yes, the 32-bit-ness of DWT has distressed me for some time.  When I
> had DMD working on Ubuntu a while back I tried to make DWT work... the
> code is 64-bit compatible AFACT, but it needs some work with the
> libraries it links to - they're not 64-bit compatible.  I wasn't up to
> re-writing the library linkage (or the prospect of maybe finding that
> the code itself isn't 64-bit compatible!) so I just left it unfixed in
> hopes that someone else would fix it someday.
> 


There are a lot of d applications and libraries that will need to become 
64-bit someday.  I'm afraid, though, that those of us contributing to dwt 
can only handle so much for now.  


>> Finally, I agree most with what you say here:
>> 
>> "I stand by my original statement that they're different languages
>> and different tools for different purposes."
>> 
>> My take on it is this:
>> 
>> Some of Objective C's features are very useful (dynamic OO extensions
>> and runtime binding); however, I think that Objective-C is really
>> meant to be a sort of domain specific solution for which the Cocoa
>> development experience is optimized: the language is purposely
>> simple, which makes it significantly useful for its intended task.  I
>> know Apple recently updated the language to Objective C 2.0 that
>> added a few more convenience features, but I don't think they even
>> argue that it's directly competitive with C++ (however, I cannot
>> verify this).  In fact, for those that might need to use other
>> libraries or use more powerful features only available in C++,
>> there's the option of developing in Objective C++.
>> 
>> Finally, I don't think Objective-C was intended to be a
>> general-purpose programming language in the manner of D or C++, so
>> the comparison will
>> 
> I would argue the opposite.  Objective-C retains the ability to
> compile and run *any* code that C can.  C is a general-purpose
> language. Therefore Objective-C is a SmallTalk-ish extension of a
> general-purpose language.
> 


Yes, I made an assumption in my statement there (concerning the C language). 
 If you still consider the C component a competitive general-purpose language, 
then this is indeed true.  I don't think C (plus the OO extension) is nearly 
as competitive in functionality as D or C++ as general-purpose languages 
go.  What we're discussing here anyway is really just the Objective extension, 
since C is available everywhere anyway.


But I do feel the Objective C extension serves the niche that it's in very 
well; in fact, it becomes the best option for that platform specifically 
because of the rich runtime and API immediately at its disposal.  But this 
could be the case with many languages that manage to be neatly and nearly 
built around an operating system... even D would excel a manifold times more 
if things like garbage collection, language specific linking and dynamics, 
interfaces, etc were integrated into and understood by the OS (or a type 
of abstraction layer that implements the functionality).   What better than 
to have singular consistancy where everything is oriented to D in a system 
such the compilers and systems can make easy assumptions.


I emphasize this fact because the dynanism that Objective C achieves is primarly 
a result of its runtime.  Here's a quote from /Objective-C 2.0 Runtime Programming 
Guide/ (Introduction, Page 7):


"The Objective-C language defers as much as it can from compile time and 
link time to runtime.  Whenever possible, it does things dynamically.  This 
means that the language requires not just a compiler, but also a runtime 
system to execute the compiled code.  The runtime system acts as a kind of 
operating system for the Objective-C language; it's what makes the language 
work."


This is actually kind of interesting because it would seem to make Objective-C 
slightly comparable to the C# language in that it's more than just a language 
(as is Java).  It's a platform (and the beauty of the platform is really 
only extensively demonstrated by the OS runtime functionality that supports 
it ... and Cocoa).  


> To me, it's the lack of really strong multiplatform support that keeps
> Objective-C from being more of a multiplatform general-purpose
> language, but it's still a general-purpose language to me.
> 


Yes, this is also true.  But I think Objective C will likely never break 
out of this mold because all the impressive functionality is to remain bound 
to it's runtime + API functionality on a single platform.  On the other hand, 
if Apple ever takes over the computer industry, I suppose we'll see Objective 
C everywhere, and then there will be no argument. :)  


With all that said, I certainly wouldn't mind seeing D demonstrate OS level 
integration of some sort or another such that threading, gc, exception handling, 
linking were completely D technology.  Niche or not, this would be amazing, 
and it would solve a multitude of weaknesses in the current D toolset.  I 
could see myself spending a fair bit of time using such a system. :)


-JJR