On 10/5/14, 9:14 AM, Dicebot wrote:
On Sunday, 5 October 2014 at 15:38:58 UTC, Andrei Alexandrescu wrote:
1. C++ support is good for attracting companies featuring large C++
codebases to get into D for new code without disruptions.
2. Auto-decoding is blown out of proportion and a distraction at this
time.
3. Ref counting is necessary again for encouraging adoption. We've
framed GC as an user education matter for years. We might have even
been right for the most part, but it doesn't matter. Fact is that a
large potential user base will simply not consider a GC language.
No need to explain it here. When I speak about vision I mean something
that anyone coming to dlang.org page or GitHub repo sees. Something that
is explained in a bit more details, possibly with code examples. I know
I am asking much but seeing quick reference for "imagine this stuff is
implemented, this is how your program code will be affected and this is
why it is a good thing" could have been huge deal.
I'm confused. Why would anyone who just comes to dlang.org see unformed
ideas and incomplete designs? Wouldn't newcomers be more attracted by
e.g. stuff coming in the next release?
Right now your rationales get lost in forum discussion threads and it is
hard to understand what really is Next Big Thing and what is just forum
argument blown out of proportion. There was a go at properties, at
eliminating destructors, at rvalue references and whatever else I have
forgotten by now. It all pretty much ended with "do nothing" outcome for
one reason or the other.
Let's see. We have properties, which indeed need some work done but
don't seem to prevent people from getting work done. The discussion on
eliminating destructors concluded with "we don't want to do that for
good reasons". For binding rvalues Walter has a tentative design that's
due for an RFC soon.
The fact that you don't seem to have a consensus with Walter on some
topic (auto-decoding, yeah) doesn't help either. Language marketing is
not about posting links on reddit, it is a very hard work of
communicating your vision so that it is clear even to random by-passer.
I think one good thing we can do is approach things in private before
discussing them publicly.
2) reliable release base
I think this is most important part of open-source infrastructure needed
to attract more contributions and something that also belongs to the
"core team". I understand why Walter was so eager to delegate is but
right now the truth is that once Andrew has to temporarily leave all
release process has immediately stalled. And finding replacement is not
easy - this task is inherently ungrateful as it implies spending time
and resources on stuff you personally don't need at all.
We now have Martin Nowak as the point of contact.
And what if he gets busy too? :)
Maybe you'll volunteer.
3) lack of field testing
Too many new features get added simply because they look theoretically
sound.
What would those be?
Consider something like `inout`. It is a very look feature to address an
issue specific to D and it looked perfectly reasonable when it was
introduces. And right now there are some fishy hacks about it even in
Phobos (like forced inout delegates in traits) that did come from
originally unexpected usage cases. It is quite likely that re-designing
it from scratch based on existing field experience would have yielded
better results.
No doubt its design could be done better. But inout was not motivated
theoretically. It came from the practical need of not duplicating code
over qualifiers.
Policy-based design is more than one decade old, and older under other
guises. Reference counting is many decades old. Both have been
humongous success stories for C++.
Probably I have missed the point where new proposal was added but
original one was not using true policy-based design but set of enum
flags instead (no way to use user-defined policy).
Sean proposed that. In fact that's a very good success story of sharing
stuff for discussion sooner rather than later: he answered a Request For
Comments with a great comment.
Reference counting
experience I am aware of shows that it is both successful in some cases
and unapplicable for the others. But I don't know of any field
experience that shows that chosing between RC and GC as a policy is a
good/sufficient tool to minimize garbage creation in libraries - real
issue we need to solve that original proposal does not mention at all.
That's totally fine. A good design can always add a few innovation on
top of known territory. In fact we've done some experimenting at
Facebook with fully collected PHP (currently it's reference counted). RC
is well understood as an alternative/complement of tracing. Anyhow,
discussion is what the Request For Comments is good for. But please
let's focus on actionable stuff. I can't act on vague doubts.
No need to trust me or anyone, but at some point decisions will be
made. Most decisions don't make everybody happy. To influence them it
suffices to argue your case properly. I hope you don't have the
feeling appeal to authority is used to counter real arguments. I _do_
trust my authority over someone else's, especially when I'm on hook
for the decision made. I won't ever say "this is a disaster, but we
did it because a guy on the forum said it'll work".
I don't want to waste your time arguing about irrelevant things simply
because I have misinterprete how proposed solution fits the big picture.
It is still unclear why proposed scheme is incompatible
with tweaking Phobos utilities into input/output ranges. I am stipid and
I am asking for detailed explanations before any arguments can be made
:) And not just explanations for me but stuff anyone interested can find
quickly.
Again: I don't have a complete design, that's why I'm asking for
comments in the Request For Comments threads. Would you rather have me
come up alone with a complete design and then show it to the community
as a fait accompli? What part of "let's do this together" I need to clarify?
This is closely related to SemVer topic. I'd love to see D3. And D4 soon
after. And probably new prime version increase every year or two. This
allows to tinker with really big changes without being concerned about
how it will affect your code in next release.
Sorry, I'm not on board with this. I believe it does nothing than
balkanize the community, and there's plenty of evidence from other
languages (Perl, Python). Microsoft could afford to do it with C# only
because they have lock-in with their user base, monopoly on tooling,
and a simple transition story ("give us more money").
You risk balkanization by keeping the things as they are. We do have
talks at work sometimes that simply forking the language may be a more
practical approach than pushing necessary breaking changes upstream by
the time D2 port is complete. Those are just talks of course and until
porting is done it is all just speculations but it does indicate certain
level of unhappinness.
It would be terrific if Sociomantic would improve its communication with
the community about their experience with D and their needs going forward.
Don has been mentioning that Sociomantic is all for breaking the code
for the greater good and I fully agree with him. But introducing such
surprise solutions creates a huge risk of either sticking with imperfect
design and patching it (what we have now) or changing same stuff back
and forth every basic release (and _that_ is bad).
I don't see what is surprising about my vision. It's simple and clear.
C++ and GC. C++ and GC.
It came as surpise. It is unclear how long will it stay. It is unclear
what exactly is the goal.
Have you ever considered starting a blog about your vision of D
development to communicate it better to wider audience? :)
Yah, apparently there's no shortage of ideas of things I should work on.
Perhaps I should do the same. Dicebot, I think you should work on making
exceptions refcounted :o).
Andrei
