Why is D unpopular? (page 19)

On Sunday, 14 November 2021 at 03:19:37 UTC, forkit wrote:

My 'second point' being, has D already become to complex? And is there any way to make it simpler, other than 'adding to it'?

I personally do not like simple. To me, that equates to restricted. But I doubt most are like me, hence why D may never, ever, become 'popular'.

Features like @trusted only makes sense if the invariants (rules) of the type system are easy to reason about, otherwise it becomes impossible for most programmers to write correct @trusted code.

Both C++ and D have unnecessary complexity, meaning that the complexity does not add power, it is basically just relics of the past. C++ cannot fix this, because of critical mass. It is a mistake for D to follow the same recipe…

On Sunday, 14 November 2021 at 21:58:21 UTC, Ola Fosheim Grøstad wrote: > > The ACID test of language complexity is to look at typical code bases and ask yourself if it would be a good idea to tell newbies to learn the language from studying those. > > I think both C+, Rust and D has a usability problem there. No. Never send a newbie to study a typical code base, no matter what the language. First, the concept of their being a 'typical' code base is a bit sus. Second, newbies need (up-to-date) learning material that minimizes learning time and confusion, and provides concise, focused guides to specific topics(Andrew Koenig, Accelerated C++, 2000).

November 14, 2021

Re: Why is D unpopular?

Posted by forkit
in reply to Ola Fosheim Grøstad

Permalink

forkit

Posted in reply to Ola Fosheim Grøstad

Permalink

On Sunday, 14 November 2021 at 21:58:21 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 14 November 2021 at 21:42:44 UTC, Dr Machine Code wrote:
>> what example of that D's complexity?
>
> In general? The forums are full of those.
>
> I don't want to start a flamewar by listing, but despite people claiming meta-programming is easy in D, it isn't difficult to point out that there are half-baked mechanisms, feature overlap that isn't needed, limited deduction abilities that can make expressing things more awkward etc.
>
> Too much complexity on function signatures for sure, how many casual D programmers remember what inout does?
>
> The ACID test of language complexity is to look at typical code bases and ask yourself if it would be a good idea to tell newbies to learn the language from studying those.
>
> I think both C+, Rust and D has a usability problem there.

I'd also argue, that complexity is the natural outcome of any programming language that is suitable for solving problems across different domains.

Complexity is the natural outcome, because developing 'general purpose' problem solving strategies that cut across different domains, is very difficult.

With such a language, you must begin on the basis: 'expect the unexpected'.

When introducing such a language to novices, you need to do it in a very structured and focused manner, and with a good understanding of cognitive science as it relates to learning.

The inverse is also true. A programming language designed for solving problems within a specific domain, will be less complex that one designed to solve problems across different domains.

Complexity is not the problem per se. Our approach to that complexity is usually the problem.

Forums