Vision document for H2 2016
Andrei Alexandrescu via Digitalmars-d-announce
digitalmars-d-announce at puremagic.com
Fri Jul 8 11:04:16 PDT 2016
On 07/08/2016 05:17 AM, Robert burner Schadek wrote:
> On Thursday, 7 July 2016 at 20:44:05 UTC, Andrei Alexandrescu wrote:
>> On 7/7/16 3:55 PM, Andrei Alexandrescu wrote:
>>> https://wiki.dlang.org/Vision/2016H2 -- Andrei
>>
>> In the next pass I will integrate Walter_Andrei_Action_List
>
> I'm quite underwhelmed by the Vision Document (VD). I think that is
> because it is a biyearly VD, and IMO in half a year nothing really
> visionary can be done for D (because D is already pretty awesome and
> pushing the envelope takes a lot of time).
It seems to me six months is a sweet spot. Large companies such as
Google and Facebook also use a six-months horizon because it's long
enough to avoid micromanagement hysteria and short enough to be
verifiable and accountable. Yes, I do have a vision for a longer
horizon, but it's too vague to be useful - "D will be a major
programming language by 2020".
> Also I think, that you treat the Action_List as competition to the VD.
I consider it competition with other things that Walter and I need to
worry about. Walter put it cleverly: you can't add more administration
without administrators.
A semestrial vision document summarizing our outlook and intentions is
about as much as we can bear. A very nice collaborator offered to help
with the vision doc but got busy with other things. He had a good quip
about us being always late with the vision updates: "If we worked at a
company we'd be all fired."
My days in the past few months were as follows:
"I think I can do containers as well as I can do ranges, let me work on
that."
"Container nomenclature is exploding! Cool, there's this great Big-O
attributes idea on the forum, let me write a library for it"
"Crap, DConf stuff DConf stuff DConf stuff"
"Hey, let's start with a simple container so how about RCStr"
"Urgh, more conferences and gigs but hey it's for the sake of D and the
Foundation coffers"
"Argh, Foundation taxes are due"
"Oops, can't let checkedint happen but I can't criticize without
proposing an alternative so forget RCStr and let me work on that"
"Argh, I need to work on the nonprofit application"
"Uhm, here's the lawyer review with questions about the nonprofit
application"
"Ehm, here's the accountant review with more questions about the
nonprofit application"
"Yowzers, it's July 5th and we're late with the vision document"
And so it goes. (Don't even get me started about email.) There are days
at the end of which I realize I've been spinning my wheels but got not
one line of code written. I'm not complaining, it comes with the
territory! Administering one more document? I'd rather avoid it.
> If you don't, even better but consider this:
>
> You create a VD roughly twice a year. You have to compare it with the
> last VD and see what was done. That is a lot of overhead IMO.
Tracking of past performance in comparison with the plan is probably the
best and single most important thing about the Vision documents. If we
just issued some thoughts every six months and then let them flap in the
wind, no tracking no care no nothing - how would that be any better?
> Why not create "THE VISION DOCUMENT" and update it when needed.
It seems the kind of document you're thinking of is a webpage.
> You
> would be able to add long term visions like "Awesome Container Library
> using Allocators", then add subpoints to it like "<strikethrough>Create
> Allocator library</strikethrough>" (strikethrough because it is already
> done). We could then link the relevant forum threads to the points and
> subpoints, discussing the work item.
Would trello help with that kind of stuff?
> People would have a go to place
> looking for pre-approved work. Leading to no more gatekeeper rejection
> frustration.
I don't think preapproved work would lead to less rejection. Rejection
is of work of insufficient quality, not of work that has not been
preapproved. Conversely, preapproval does not guarantee any work will be
actually approaved.
> Additionally, I think that the vision for phobos is really weak, no
> mentions of containers, xml, (si)-units, unit-testing (framework),
> benchmarking, blas, json ... .
Added.
> I'm not the much in the DMD process, but what about making the frontend
> a library and being able to select the backend at the time of
> compilation, as shortly mentioned at DConf. I bet there are a lot of
> subpoints to that as well.
Added.
Thanks!
Andrei
More information about the Digitalmars-d-announce
mailing list