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.
