More radical ideas about gc and reference counting

[Caligo via Digitalmars-d]

On Sun, May 4, 2014 at 12:22 AM, Andrei Alexandrescu via Digitalmars-d <
digitalmars-d at puremagic.com> wrote:
>
>
> Mostly good points, but the bountysource program is an experiment by
> Facebook, not by myself. And (without me trying to speak on Facebook's
> behalf) it would be difficult to argue that Facebook doesn't understand
> FOSS or is out there to insult contributors. We're just experimenting with
> various angles.


If the bounty system was such a great idea, then every FOSS project would
be using it.  Now, hiring full-time engineers to work on a FOSS project,
that's an entirely different issue.  Besides, if someone is trying to
figure out how FOSS teams manage to become successful in regards to
development and all the associated technical and social complexities, then
all they have to do is study one of the million different FOSS projects out
there.  Many well known FOSS contributors have actually documented their
experience and knowledge of managing FOSS projects.


>
> The on/off switch may be a nice idea in the abstract but is hardly the
> perfect recipe to good language feature development; otherwise everybody
> would be using it, and there's not overwhelming evidence to that. (I do
> know it's been done a few times, such as the (in)famous "new scoping rule
> of the for statement" for C++ which has been introduced as an option by
> VC++.)
>
>
No, it's nothing abstract, and it's very practical and useful.  Rust has
such a thing, #![feature(X,Y,Z)].  So does Haskell, with {-# feature #-}.
 Even Python has __future__, and many others.


> I wonder how you've gotten the perception that one needs to be a member of
> the inner circle mafia to get things into D. Today's major contributors to
> D came from all over, without any preexisting relationship to anyone else,
> and their admission ticket has been getting work done. Could you please get
> into detail on how you view things? (I tried to look over your past posts
> to see a pattern of rejected contributions, but didn't find such.)
>
>
>
I wasn't trying to imply that contributions are rejected if contributors
are not members of a certain group.  I was just trying to say that it's
more likely for a _new_ feature to make it into D/Phobos if they are
proposed by members of the inner circle or someone representing a
corporation, probably because they become more noticeable, or because they
get lost in all the forum noise, I don't know.  I could be wrong, but
that's just how I perceive it.



>
> Actually I'd love to get you started so I'd understand your angle better.
> I'm sure we can do a lot better. One good thing Phobos reviews have done
> since we initiated them has been to prevent bad artifacts to make it into
> the library. We'd love to make it better. From what I saw witnessing
> similar processes (C++, Boost, Python, Scala) - they all have some sense of
> awkward self-importance to them upon the first look. I think that's the way
> such things work.
>
>
>
Here is an idea:  include new features in DMD/Phobos as soon as they
arrive, and make them part of the official binary release so that the
average D user can try them out.  Make sure they are marked as unstable,
and put a on/off switch on them (something like what Rust/Haskell have; not
a compiler switch).  If the feature receives no implementation bug reports
for X consecutive days AND no design bug reports for Y consecutive days,
then the feature is marked stable and officially becomes part of
DMD/Phobos.  The X and the Y can be decreased as D's number of users
increases over the years.  The whole idea is very much like farming: you
are planting seeds.  As the plants grow, some of them will not survive,
others will be destroyed, and some of them will take years to grow.  In any
case, you harvest the fruits when they are ready.

 Here are good starting values for X and Y:
X = 90 days
Y = 180 days
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140504/7816285a/attachment-0001.html>