On Thursday, 10 July 2014 at 14:30:38 UTC, Andrei Alexandrescu
wrote:
In the meantime, everybody's busy arguing the minutia of logo
redesign. The length (not existence) of that thread is a piece
of evidence of what's wrong with our community.
Actually, that thread is a good sign and a good source for
community building. You know, people establishing boundaries and
goals together rather than trying to figure out if it is worth
contributing the vision of somebody else or adding to an existing
patchwork which has a unclear direction. It was a small managable
piece (the logo) so people felt like participating. It also was a
ground where people can share their views on
what-we-really-are-about on an abstract level.
Of course that doesn't undo the fact that Walter and I are on
hook for a number of things. What I'm saying is I disagree with
the allegation that "no amount of volunteer effort will help".
From the looks of things, we're in dire need of volunteer
effort.
Motivation is a difficult sport, but it would help a lot if you
just specced out the D2 language fully and plotted in the missing
parts, without implementation, but with proofs of correctness.
All this putting stuff in, then ripping it out is demotivating.
(Why contribute if it will be ripped out at the next turn of
events?)
People with formal training (CS background) will favour elegance
and correctness, which implies solid advance speccing… Without
it, they are unlikely to contribute unless they have D in
production or miss features which could make it possible for them
to use D in production…
There is too much pushing for breadth in the D community. What
you need is depth, the depth of quality and polish. Possibly
reducing the scopes and feature set, not extending it even more.
Maybe you have to cut back on system programming and go for fast
brute force lock-the-world GC without destructors, or maybe you
have to favour system programming. But surely, the worst option
is to not set a clear direction.
To match up with the best-in-class in the web space you need a
tight performant HTTP and SPDY implementation with support for
all relevant content negotiation headers, solid caching handling,
automatic compression, well working timeouts/load balancing, all
the right hooks for rapid development, builtin Memcache support,
a solid NOSQL abstraction, a transactional task queue and be
tight on memory so you can run the service on cheap hosting. That
would bring you to the basics of Go/App Engine… Then you have to
be better…
Kudos for vibe.d, but it won't really matter until it is better
than the alternatives. Building WordPress on top of it won't
matter, because creating WordPress is not difficult. The
difficult part is building the WordPress community.
