D versus Objective C Comparison

[Chris R Miller]

John Reimer wrote:
>> 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.

Well, I've come to the general conclusion that I am the least 
experienced person around here, so I'll defer to your judgement there. 
I've added a small note that acknowledges Objective-C's SmallTalk design 
underpinnings.

>> 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. 

I'm still amazed that so few people were able to create DWT.

>> 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.

There is still a whole lot of stuff being written in C, both 
commercially and Open-Source.  I believe that's because it's such a 
good, general-purpose language and because it's ubiquitous.  Nearly 
every platform has a C compiler.

> 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). 

Well, I suppose it's largely how much you build into the runtime.  C and 
C++ have runtimes, after all, but compared to things like D and C# they 
don't do much at all.  D, C#, and Objective-C perform many more 
functions via their runtimes than do C and C++.

>> 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. :) 

Objective-C's runtime is bundled with it just like C++'s (or as far as I 
can tell).

I wholly agree that the one killer feature of Objective-C - the Cocoa 
library - is stuck on OS X, but if you for some reason fell in love with 
Objective-C as a *language* you could run it on any platform.  Because 
it can access C libraries and, through Objective-C++, C++ libraries, you 
could probably use Objective-C with great success on other platforms.

I'm just not willing to leave the nice cushy "it just works" Xcode 
environment though.  :-)

Which is why I rate Objective-C's cross-platform ability so low.  Heck, 
you could write a brainfuck interpreter for any platform, but without 
the ability to load external libraries and interface with the system in 
truly meaningful ways I'd call brainfuck's cross-platform support 
horrible as well.

> 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. :)

Making an OS around D would be a grossly fascinating project.  As it is 
I don't think you could make the kernel in D - the D runtime relies too 
heavily on kernel-supplied routines for memory allocation, etc.  You'd 
have to take D and remove the runtime, which is largely what the Linux 
kernel does with C - they took C, and removed the runtime in order to 
make the kernel.  Which makes Linux kernel hacking very confusing!  Use 
zmalloc() instead of kmalloc() in kernel code, etc. and stuff like that...

Perhaps taking a Linux/BSD kernel and building a software system up from 
there?  How would one go about doing such a thing?  I suppose you could 
use a QEMU interpreter to virtualize the system in the earliest stages 
until you get such tools as a command shell working.