D versus Objective C Comparison

[John Reimer]

Hello Chris,

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


Well, now I'm feeling a little silly about being pushy about it.  But thank-you 
for listening nonetheless.   For many things I'm in the least experienced 
category too around here... Anyway, it just happened that I knew a little 
about Objective-C history, and that point bothered me. :)


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


Yeah, it's even better than that.  Frank did the most of two ports (dwt-win, 
dwt-linux).  I did some of the DWT underpinnings on both, along with the 
Browser/XPCOM port, and website.  And now Jacob Carlborg is doing the same 
for DWT-mac.  It's pretty amazing. 


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


I think what Objective-C does critically in it's runtime is dynamic binding. 
 For some reason, other languages haven't felt the need to do this.  I'd 
have to read more about it to know what's going on, though.


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


It's possible and has been done... D is at least flexible enough to swap 
in the parts necessary.  Tango is organized to help make such a project easier,for 
example.


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


There a few projects (some dead) that are implementing a D Operating System. 
 I think Jarett was contributing to one of them.


-JJR