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.
