queue container?

Steven Schveighoffer schveiguy at yahoo.com
Wed Nov 2 05:32:47 PDT 2011


On Tue, 01 Nov 2011 15:21:47 -0400, J Arrizza <cppgent0 at gmail.com> wrote:

> On Mon, Oct 31, 2011 at 7:07 AM, Steven Schveighoffer
> <schveiguy at yahoo.com>wrote:
>> I personally guarantee that dcollections will persist as long as
> std.container's design is not modified to become like dcollections'.
>  Simply because I need it for my projects :)  And I'm not going to some
> other language any time soon.
>> How much weight that pulls with you?  Not sure.
>
> I guess I am unclear on the relationship between D and Digital Mars and  
> you
> and Digital Mars.

D is the brainchild of Walter Bright, who works for Digital Mars (I'm  
actually not sure what the relationship between Walter and DM is, but I'm  
assuming he's one of the top people, if not the owner).  Walter is D's  
benevolent dictator, he makes final decisions for D's directions and  
acceptance of code.

Even though Walter has final say, Andrei is the lieutenant in charge of  
phobos, he drives the direction and development of the library.  Walter  
used to do this, and phobos did not really do well (this is back in the D1  
days).  Walter is a much better compiler/language writer than a library  
writer (or so I'm told).

I am just a contributor, and a huge fan of D.  I have no formal  
relationship with DM or Walter or Andrei, I don't work for them.  However,  
I develop code for Phobos and druntime in my spare time (I do not yet have  
any abilities to contribute to the compiler code).

> Who drives the policies and direction that D takes? If it
> is Digital Mars, then I'd like to see a statement from them indicating  
> that
> dcollections will be merged (at some time) into Phobos or that there will
> be an official repository for utilities, packages, modules, etc. like
> yours. You've already committed to moving it in there.

You will not see a statement that dcollections will be merged into phobos  
any time soon.  My opinions on the design of a collections package differ  
 from Andrei's, so far we have not been able to come to terms with how  
dcollections could be used as Phobos' collection package.  However, the  
door is still open (even if only slightly), since a) both phobos and  
dcollections have the same license (cross-pollination is possible) and b)  
std.container is woefully underdeveloped, even as designed.

If there were an "official" repository for 3rd party libraries like CPAN  
as discussed, I assume DM will have no problem with it containing  
libraries from anyone (including dcollections).  I assume the only  
requirement is they will be actively maintained.  In other words, the  
tight control over code belongs in phobos and dmd, not in a distribution  
tool for 3rd party libraries.  In that sense, I have committed to  
maintaining dcollections as long as it's functionality is not superseded  
by phobos.  If that happens, it should be a minor switch, or I will create  
guidelines on how to switch if it's not trivial.  I'm not going away from  
this.  If you are concerned about maintenance of dcollections, I'll point  
out that it's open source, and I am a professional developer by day who  
has no problem working as a contractor.

>
>> I certainly respect that position, and it's a good one to have.  But  
>> that
> does leave you with a queue-less container situation :)
>
> Yes it does. But I haven't committed to D yet either. I'm looking at it  
> for
> the long term. I have a need for a fast, OO language that has a cleaner
> "user interface" than C++.
>
> I need it fast since it will most likely be in an embedded product, most
> likely on an ARM based processor.

Then you will be dependent on gdc, as dmd only supports x86 and x86_64.   
Your concerns about dcollections ceasing to be maintained are minor  
compared to that.

> It has to be OO because so far nothing I've seen beats it at keeping  
> source
> complexity under control.
>
> By "user interface" I mean not just the syntax of the language but
> the surrounding packages, utilities, the compiler, etc.  Java and C# are
> popular because of this aspect, and C++ will die because it has less of  
> it.
> The reason I'm looking at D at all is because it is taking the approach  
> of
> cleaning up some of C++'s issues, it has some great C++ aspects (e.g.
> templates), it has some of Java's good things too (the gc), etc. In other
> words the overall direction the language is going is solid, and very
> promising.
>
> However it is still suffering from a lack of a  large dev kit ala JDK or
> CLR. Phobos is just the beginning.
>
> Why all this? Because the biggest impact to 99% of projects is hardly  
> ever
> truly difficult technical problems. It is the developer's learning
> curve. If we're going to invest in a language, utilities and packages,
> please make it 1) easy to learn in the first place and 2) stable so we
> don't have to learn it over and over again.
>
> Well, that was a bit of rant. My apologies...

D is getting there.  I suspect the inclusion of gdc into gcc proper (on  
the horizon, I think) will help in this.  Also inclusion of d compilers in  
major Linux distributions should help too.

I don't know as I'd prop up a real product using D yet (I'd have to know  
more about the product to be able to decide that), but it certainly is on  
the verge of being useful in that situation, if it's not already.

Once D does cross that threshold and becomes more mainstream and used in  
professional situations, I suspect the development will go even faster.   
Simply because, many of the top D developers have day jobs which do not  
involve D.  Think of how much D would progress if we could spend full time  
on it.

-Steve


More information about the Digitalmars-d mailing list