On 30/09/2019 8:07 PM, JN wrote:
> I think D shouldn't be afraid to cut some of the language features which aren't used much, or have a viable workaround. This way the language would be smaller and easier to maintain/bugfix. Also, smaller language means lesser chance of bugs occuring in the first place. Right now I feel like D is in that weird spot. It's too afraid to cut or rework existing features for language stability, but then is too brave introducing new concepts which weren't battle-tested before.

I.e. hex strings

On Monday, 30 September 2019 at 07:07:34 UTC, JN wrote:

>
> This is true. However, given that it's a volunteer project, there is room for improvement. If the workforce is limited, it's spread over the language/libraries surface. If we were to minimize that surface, we can have more work done.
>
> I think D shouldn't be afraid to cut some of the language features which aren't used much, or have a viable workaround. This way the language would be smaller and easier to maintain/bugfix. Also, smaller language means lesser chance of bugs occuring in the first place. Right now I feel like D is in that weird spot. It's too afraid to cut or rework existing features for language stability, but then is too brave introducing new concepts which weren't battle-tested before.
>
> Main issues with D aren't with the specific features, which often came up as a good idea and solve some problem, but the problem is when these features interact with other features. The result is a lot of unexpected interactions (look at any DIP discussion thread, there's always a case of "yeah but this breaks if I have an immutable shared union with alias this"), added cognitive load for the programmer and harder to write generic code.

I agree. New features are introduced way too fast, often based on the latest CS fashion of the day ("Look here's a paper on...")  or "Rust has it, so we need it too!", regardless of whether or not this will break code. Maybe the reason why (ex-)users (including myself) are sometimes so grumpy and negative is that this implicit disregard of users' code makes users feel as if they and their work didn't count at all, yet D complains that there aren't enough users, yeah right. I don't know about others, but when I was still using D actively I would sometimes see discussions on the forum and say "Holy sh*t! Does this mean I'll have to refactor my code once this new feature becomes part of D?" It's like programming on an ejector seat, and after a while I got just sick and tired of it. Nobody wants to live like that forever, not to mention that it is really annoying if you have to go back to old code to "fix" things that shouldn't be broke in the first place. Ah, c'mon.

D is 20 years old and still the same criticism pops up again and again and again and the same answers are given: volunteer effort, do it yourself or PFO. Is it the users' or the language leadership's fault I wonder, after 20 years. Hm.

D is theoretically in a good position to do a spring cleaning. It has loads of features. Take what really works (battle-tested features), drop all the half-baked features that only a minority really uses. Improve the stability of the language and set up a proper ecosystem (e.g. out of the box compilation for various platforms / architectures).

Atm, I'm mainly using Kotlin and I have to say that a small set of clever and well thought-out features can get you a long way. Do I miss some of D's features? Not really, because Kotlin provides enough useful and battle-tested features that you need 90% of the time [1]. Once I missed `static if`, but I could live without it.

Mind you, Kotlin has some restrictions due to the fact that it has to be a 100% compatible with Java/JVM. But even when you use Kotlin/Native (without the Java universe, i.e. modules and libraries) you can get quite far. I think D should aim at that.

1. Take D's great features that are battle-tested
2. See what is not strictly necessary and drop it (dead weight), i.e. figure out what programmers need 90-95% of the time and don't pollute the language with features you only need in the remaining 5-10% of the cases.
3. Set up a sound and stable ecosystem

But then again, I fear this will never happen.

On Monday, 30 September 2019 at 09:21:30 UTC, Chris wrote:
> D is theoretically in a good position to do a spring cleaning. But then again, I fear this will never happen.

But the big one is @nogc and all its associated machinery. This is the killer, the biggest source of all the mess. And getting rid of that is not going to happen. Instead you'll see more and more stuff designed to support @nogc. Complaining about it is useless. So I personally don't complain, even though I disapprove of this course and consider it the only real strategic mistake in D.
This is, of course, assuming that maximising the number of users is the strategic goal. OTOH, all these "f... off, don't whine, do it yourself" on the forum suggest that it's not actually such an important goal. As Adam Ruppe mentioned, more users, more problems. Which is fair enough, so indeed why whine? It just annoys people and provokes trolling.

On Monday, 30 September 2019 at 09:21:30 UTC, Chris wrote:
> D is theoretically in a good position to do a spring cleaning. It has loads of features. Take what really works (battle-tested features), drop all the half-baked features that only a minority really uses. Improve the stability of the language and set up a proper ecosystem (e.g. out of the box compilation for various platforms / architectures).

In theory, yes, but in order to make it easy for open source contributions to be made the compiler would have to be made modular and basically rewritten from scratch.

A spring cleaning should not only focus on the language itself, but focus on attracting new contributors.

Quite frankly, a higher regard for basic computer science would go a long way... I think the Rust community has benefitted greatly for taking the field of computer science very seriously (perhaps even a bit too far in that direction, but it builds a very solid group identity).


> 1. Take D's great features that are battle-tested
> 2. See what is not strictly necessary and drop it (dead weight), i.e. figure out what programmers need 90-95% of the time and don't pollute the language with features you only need in the remaining 5-10% of the cases.
> 3. Set up a sound and stable ecosystem
>
> But then again, I fear this will never happen.

It won't happen, and it would only succeed if you focus on a carefully selected set of use cases. Which basically has been D's main problem since D2. D1 had the advantage of being a simple upcoming alternative to C++, which at that point was a niche with no contenders.

Today, you have to provide some use cases where the eco-system has next to no competition and where it excels. There are contenders in most niches... at that point the eco-system is no longer optional...

It could be Linux. It could be embedded. It could be games development. It could be scientific computing. It could be web development (although in that case the language has to be made more forgiving).

It cannot be iphone, android, database-integration or any other area where the eco-system is incredibly expensive to both build and maintain. (That includes Python's scripting niche, despite D developers saying that they prefer D over Python for scripting tasks.)

You really need a niche to grow from to get that ecosystem going.

Go is a very good example of this. They kept the language small. And the "owner" Google decided that it was primarily good for writing web services and put a lot of resources into the runtime, not the language.  The Go language is not a lot better for writing web services than other languages. The runtime and ecosystem in combination with the basic language is what makes it a strong contender in that space.

TypeScript, same story.

It is very difficult to make a sales pitch for a language if it does not have an ecosystem that makes it a strong contender in at least one niche. After 20 years... that becomes a problem. Even if the language had been perfect, that lack of a niche where you are a strong contender is problematic.

You see this with Kotlin too, it is now a strong contender in the Android niche.  That clearly makes a big difference in how the language eco system evolves...

On Monday, 30 September 2019 at 09:21:30 UTC, Chris wrote:
> Atm, I'm mainly using Kotlin and I have to say that a small set of clever and well thought-out features can get you a long way. Do I miss some of D's features? Not really, because Kotlin provides enough useful and battle-tested features that you need 90% of the time [1]. Once I missed `static if`, but I could live without it.
>
> Mind you, Kotlin has some restrictions due to the fact that it has to be a 100% compatible with Java/JVM. But even when you use Kotlin/Native (without the Java universe, i.e. modules and libraries) you can get quite far. I think D should aim at that.
>

I think Kotlin's dependency on Java/JVM is actually a benefit, because they know what worked and didn't work in Java and could work on improving that. Also, they are 100% behind the OOP paradigm, so they can introduce most features that benefit that. For example features like data classes or singleton objects are very useful, even if they are mostly a language syntax sugar for certain design patterns.

On Monday, 30 September 2019 at 09:57:59 UTC, nkm1 wrote:
> This is, of course, assuming that maximising the number of users is the strategic goal.

Maximizing the number of users should not be the strategic goal.

The strategic goal should be to provide a fertile ground for building an eco-system which becomes a strong contender in at least one niche.

I can't think of any language that survives without satisfying that requirement.

If you try to maximize the number of users you will end up not being particularly good for any particular purpose. Which means that the language is easy to replace with any upcoming generic language.

To be a player in that area the ecosystem is even more important than the language: Java, C#, Python etc. Languages like Kotlin very deliberately try to piggyback on an existing eco systems for that reason.

This is not to say that languages disappear, programming languages tend to have a long long dwindling trail (Perl, Fortran, Cobol, etc).

On Monday, 30 September 2019 at 10:21:42 UTC, Ola Fosheim Grøstad wrote:
> This is not to say that languages disappear, programming languages tend to have a long long dwindling trail (Perl, Fortran, Cobol, etc).

tail, not trail...

On Monday, 30 September 2019 at 09:57:59 UTC, nkm1 wrote:
> On Monday, 30 September 2019 at 09:21:30 UTC, Chris wrote:
>> D is theoretically in a good position to do a spring cleaning. But then again, I fear this will never happen.
>
> But the big one is @nogc and all its associated machinery. This is the killer, the biggest source of all the mess. And getting rid of that is not going to happen. Instead you'll see more and more stuff designed to support @nogc. Complaining about it is useless. So I personally don't complain, even though I disapprove of this course and consider it the only real strategic mistake in D.
> This is, of course, assuming that maximising the number of users is the strategic goal. OTOH, all these "f... off, don't whine, do it yourself" on the forum suggest that it's not actually such an important goal. As Adam Ruppe mentioned, more users, more problems. Which is fair enough, so indeed why whine? It just annoys people and provokes trolling.

Whine: "3. To complain or protest with a whine or as if with a whine." [1]. "Whining" is not constructive and does not propose any solution. However, _a lot of people_ criticizing D over the years have done so suggesting concrete solutions, and yet they have consistently been labelled as "whiners" or "trolls". If it's true that the D leadership and enthusiasts are not interested in users (and everything hints at that), then why do they complain about "negativity that hinders adoption of D"? Wanna have your cake and eat it? That's a rather schizophrenic attitude: "Don't put off users, but to hell with them, we don't give a damn about users anyway!" Ironically, the D leadership are the real whiners, they've been complaining about low adoption rates for years, and yet treat their target group like unworthy worms. Not a good way to sell a product. Yeah, no, I do wonder why D is not more popular.

You're basically saying that there's no cure for D and that it's is beyond hope. I wish the D leadership finally published a statement to this effect on dlang.org. Something like "D is a volunteer effort and serves no purpose other than playing around with features and ideas. It ships with no guarantees of stability or backward compatibility as we pretty much do what we please. Use at your own peril. Complaints will be ignored."

[1] https://en.wiktionary.org/wiki/whine

On Monday, 30 September 2019 at 10:21:42 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 30 September 2019 at 09:57:59 UTC, nkm1 wrote:
>> This is, of course, assuming that maximising the number of users is the strategic goal.
>
> Maximizing the number of users should not be the strategic goal.
>
> The strategic goal should be to provide a fertile ground for building an eco-system which becomes a strong contender in at least one niche.

That seems more like tactical or operational goal to me... What do you think of Haskell's "avoid success at all costs" or Lua's constant breakage?

On Monday, 30 September 2019 at 10:14:52 UTC, JN wrote:
> I think Kotlin's dependency on Java/JVM is actually a benefit, because they know what worked and didn't work in Java and could work on improving that.

Actually, it is a big disadvantage, except for one thing: they can piggyback on the ecosystem and cut down the costs of developing a solid runtime system.

In that Kotlin has the same advantage of being able to gradually take over for Java, which is comparable to how C++ could gradually take over for C.