Handling constructive criticism

[Sean Kelly]

== Quote from Scott S. McCoy (tag at cpan.org)'s article
> On Thu, 2008-04-17 at 07:21 +0900, Bill Baxter wrote:
> > The current problem seems to be the opposite to me.  The problem *is*
> > that Walter doesn't think D is good enough, and so he think he needs to
> > add ingredient C to woo large-systems developers or ingredient P to try
> > to leap ahead of the competition.  If anything he's aiming too high,
> > into territory that no one knows anything about, and which may pan out
> > to be ultimately not so useful.  Or it may pan out to be fantastic.  I
> > don't think anyone knows.
> I've sort of had a similar feeling.  D has a quite astounding feature
> set, and is in a really strong position.  And unlike many languages
> actually has a solid reference implementation.  Unfortunately I've
> noticed a lot of corner-case sloppiness, some rather unfortunate syntax
> which seems to need be revisited, and a few other odds and ends which
> really need cleaning up -- but never the less, time is spent moving
> forward, not perfecting what is.

Personally, I think D 1.0 is fantastic.  It has a few tiny warts, but overall
the syntax is elegant and imminently usable.  I would love for the 1.0
version of D to get some more attention and for the remaining functional
bits to be improved: template function overloading, inheritable contracts,
etc.  That said, the only compelling reasons for me to upgrade to 2.0 are
struct ctors and overload groups (or whatever they're called).  The const
syntax is a dis-incentive, as is the dual meaning of enum, dynamic
closures, etc.  They all complicate the syntax in undesirable ways or
cause problems while attempting to solve solutions I don't need solved
for the work I do.  I can appreciate that Walter thinks these are all the
best thing for D, so I hope that he can appreciate that they aren't the
best thing for me.  I would prefer more attention were paid to solidifying
the foothold D already has than erode it in an attempt to gain new users.

> However, I see all this talk about adding strange concepts like "pure
> functions" which add inane complexity to the language, meanwhile
> interesting corner cases about "auto" and various other behaviors -- as
> well as various implementation bugs -- remain.  Syntactical sores stick
> around (Foo!() comes to mind) and nobody worries about them.

hehe, I proposed that the template bit be dropped if no arguments are
necessary a year or so ago, but the proposal got no responses.  I can't
find the post, but perhaps someone else can.  It was in this group.

> The only thing holding me back, as a professional software architect,
> from trying to get D used at my day job is literally adoption.  const is
> nice, and I find the feature rather exciting -- but to be honest, it's
> not nearly as important as being able to point to articles showing other
> companies are using D.  And I think we'll see them as we see better
> programming frameworks and libraries take shape around D.  I think we'd
> see more of that if we cleaned up the miscellaneous issues, fixed a few
> of the syntax ambiguities, and got a focus on a solid, stable,
> non-tumultuous language specification that people can build on without
> fear of future change.

It would be nice if 64-bit support were improved (or at least the ABI were
modified to account for this) and if the linker discarded more unused code.
Fixing debug symbol output on linux would be nice as well (I believe symbols
are still mangled in gdb).  None of these are deal-breakers, but they are all
questions that come up for corporate developers when first encountering D.

> Fear of change is a major issue, for any language looking for adoption.
> If the specification is changing rapidly, or a large "bigger, better"
> version is looming in the distance (especially of the language is-- and
> after that some stability might come about. already not particularly
> well established) then it provides reason for reservation for going and
> say, building a good web service stack and WSDL-based code generator for
> D.  If D 2.0 is "so close", why not wait for that?

In my experience, the issue is more often a desire for stability and support.
An unpopular language is difficult to sell to management because they worry
about hiring developers to maintain the code.  An unstable language spec,
unreliable toolchain, or poor tool support is a difficult sell to the build team
because they have to maintain the build environment.  Issues like a lack of
const is far secondary to such practicalities--look at Java.

> At the same time, the molasses rate of change that languages like C, C++
> and Java have is not something D should adopt by any means.  But
> nevertheless, I'm really hoping that once D 2 is ironed out -- it will
> have a lot of the corner cases dealt with and hopefully some of the
> syntax cleaned up -- and after that some stability might come about.

There are other languages which have become quite popular in a fairly
short time which may be more worth looking at insofar as progress of
the syntax, community participation, etc, are concerned.  Take Ruby, for
example.


Sean