[DGD] just out of curiosity
RobF
squaretriangle at hotmail.co.uk
Mon Sep 10 13:56:45 CEST 2012
I'm wondering what the state of this driver is.
It is clearly the most technologically accomplished MUD driver out
there, but I'm wondering if Felix wants to distance it from its roots,
given that the MUD lib that he was going to code never transpired and
the feature-set goes far beyond what a MUD would require.
And I even wonder whether he is working on DGD/Hydra under contract.
Might not be something he is willing or allowed to divulge, but it just
has me curious that given the decline in popularity of MUDs generally
and DGD's historical lack of uptake by MUD developers (which may be
argued as being for the best, as so many MUDs are dime-a-dosen clones of
one another), and the way he plods on with it for going on two decades.
During this time the lack of accessability as an actual MUD driver
hasn't improved much except by the contributions of third parties.
There hasn't been much interest shown in improving the documentation
(correct me if i'm wrong), leaving the labyrinthian mailing list
archives as the sole source of understanding the nuances of this
complicated and unique dialect of LPC, which I don't think is ideal or
user-friendly even for those technically inclined such as career
programmers.
'Hydra' is an apt sort of name for it not just for the
multi-threadedness but the power and potential of the system. I don't
know how he has the time as an obvious professional to lend his valuable
skills to such a project unless he is the client of a high profile firm,
or something. Once again, not wishing to pry into what is none of my
business, but I am curious.
I myself have had a replacement kernel in the back of my head for a
while, with at least one flagship feature I've not seen in the existing
one. I was going to hang onto the idea but I'm not as yet actually
procuring the result, so by now I figure I may as well share and share
alike and see if anyone wants to snitch the concept (or tell me it
sucks, or has already been tried for all that I know and isn't as great
as I think, not that I'm saying it is...).
The idea being of hiding the distinction between cloneables and
inheritables. In the context of that-which-sits-in-the-kernel (let's
call it the lib), it only sees a single object by a single name, and
depending on how the object is used it will invoke an operation on an
internally referenced inheritable or cloneable version of the object.
The result would be a seamless illusion of their being just one object
that can be inherited or cloned, and the maintainer of the lib wouldn't
have to observe or remember the distinction of their being inheritables
and cloneables. If needs be I could describe how such a feature would
be implemented and work but that should probably be enough to figure it out?
The only negative I have to say about the driver is that its developer
seems to have an odd design philosophy, or at least one that he isn't
anxious to have the people interested in utilizing the driver (one might
even say, 'fans' of the driver) understand or appreciate. Or at least, me.
As just one instance, he nonchalantly told me that there is no way for
code written within the rules of the dgd-extension system to access
objects--with no further comment, as if he had no interest in resolving
this fact--he didn't clarify whether it was impossible to resolve, or
just challenging for him, or if he just wasn't interested in dealing
with it regardless.
This, even though this state of affairs leaves the extension system
outrightly broken almost to the point of uselessness, as we all know
that the most powerful aspects of DGD lies primarily in the object
data-type and what can be done when manipulating said object.
This doesn't seem a way to attract people into using your technology, so
from what I can gather, he doesn't care, because the people trying to
use this as a MUD driver aren't his target audience anymore. Maybe a
mistaken impression, but it's the impression that I get. It isn't
helped when Felix also shows no lack of readiness in recommending the
other 'more dedicated' MUD drivers out there if they don't like the way
that things are, even though one might want the features that DGD
uniquely provides.
Not wishing to cause offense, and I hope also that the way I interacted
in this forum in the past (8 years ago) hasn't left any prejudice on the
minds of longer-term list-members that might affect how they perceive
me. Hoping just to get a clearer picture of things. I hope my overall
respect for the work as a technological accomplishment is seen in
balance with the criticisms that I have, and that my comments will
elicit some illuminating feedback or constructive dialog.
More information about the DGD
mailing list