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
