Dicebot on leaving D: It is anarchy driven development in all its glory.

[H. S. Teoh]

On Thu, Aug 23, 2018 at 06:39:32PM +0200, ag0aep6g via Digitalmars-d wrote:
> On 08/23/2018 05:17 PM, H. S. Teoh wrote:
> > And the nice thing about D being open source is that should the
> > situation escalate to the point where the community simply cannot
> > get along with W&A anymore, forking is always an option.
> 
> But forking only happens when the dissenters have enough motivation to
> do it. If they don't, they might just fade away one by one, looking
> for greener pastures elsewhere. That would probably be the worst
> outcome for D: the community shrinks until it's just Walter and Andrei
> wondering where everybody did go.

If that's what it takes, then maybe that will be the point where they
start addressing issues that drove people away? :-P


> Now, I don't know if the amount of (quality) contributors is actually
> growing, shrinking, or stagnating. But I do know that I feel the pull
> (push?) away from D myself.
> 
> It feels like `@safe` and `shared` won't ever be solid.

To be honest, I've been skeptical of @safe since the first time I read
about it in TDPL.  It feels like something tacked on, rather than
integrated into the language design, and it's exactly the kind of
feature that needs to be designed into the language from day one in
order to have a chance of actually being successful.  Over the years,
the holes in the implementation hasn't made my confidence much stronger,
and as a result, in my own code I rarely, if ever, use @safe.  Maybe in
self-contained modules I'd do it, and then mostly only via automatic
attribute inference and annotated unittests to prevent regressions.

`shared`... TBH, I haven't really needed to use it, and from the little
I know of it, it seems so cumbersome to use and bug-ridden in the
current implementation that I don't think I'll ever use it.  Sometimes
it's just not worth the trouble to fight with a language feature that
TBH isn't thoroughly-enough designed to fit in with other language
features seamlessly. I'd rather find a different way of approaching my
programming problem that wouldn't require `shared`.


> Auto-decoding won't go away.

Yeah, this is a big one for me.  Ironically, Walter actually agrees that
autodecoding was a bad idea.  But byCodePoint / byCodeUnit has so far
been a usable (if not as pleasant) workaround for the most part.


> Unsound conversions (e.g., `char` -> `dchar`) won't go away.

Yeah, another annoying holdover from C/C++ that doesn't make any sense.
This is one issue where I'd be happy for breaking changes that will
clean up the core language.


> Regressions aren't being fixed (78 open). Wrong-code don't get fixed
> (170!).  Etc., and so on. So why even bother?

I think this is unfair.  Regressions *are* being fixed... but they're
getting reported at a faster rate than they're being fixed.  Wrong-code
bugs also *are* getting fixed... just not as fast as we'd like, but I
think it's unfair to say they aren't getting fixed.

Overall, I think with the number of regressions being introduced every
release, we really got into language-freeze mode way too early.  The
fear of breaking changes has gotten to the level of paranoia, yet at the
same time regressions keep happening.  IMNSHO, if there are going to be
so many regressions anyway, why not take the chance to pull off breaking
changes like killing autodecoding, killing unsound conversions, and a
number of other small but cumulatively annoying rough edges that have
been thorns in our sides for years.  Unfortunately, I don't see this
happening in the near future.


> Currently, I'm toying with ideas for a hobby language of my own. I
> know that it most likely won't go anywhere, but wasting time on that
> starts to feel more rewarding than wasting it on D.

I've felt the temptation myself, actually.  The thing that's stopping me
from actually doing it is that I simply don't have the time it takes to
actually pull it off.

To put things in perspective, though: despite all of D's rough edges and
certain dark corners where you run into implementation bugs, features
that clash with each other, and other such unpleasant things, I still
find D much more pleasant to use than C/C++ or Java. Go isn't even on my
radar because it lacks generics. And Rust... honestly, I really cannot
see myself going back to the dark world of worrying about memory
management in every piece of code I write. That's simply the wrong level
of abstraction to be working at, IMO, when your programming problem
isn't to implement a memory manager.  And I'm not interested in
non-compiled languages, so Python isn't really on my consideration
either.  D is far from perfect, but I haven't yet found something closer
to my personal ideal of what a programming language should be like.  So
for the time being, given the choice, I'd still choose D over any other
language.


T

-- 
Do not reason with the unreasonable; you lose by definition.