What are (were) the most difficult parts of D?

[Ola Fosheim Grøstad]

On Wednesday, 11 May 2022 at 05:41:35 UTC, Ali Çehreli wrote:
> What are you stuck at? What was the most difficult features to 
> understand? etc.

No singular feature, but the overall cognitive load if you use 
the language sporadic. Which could be most users that don't use 
it for work or have it as their main hobby.

As with all languages, cognitive load increases when things do 
not work as one would intuitively expect or if a feature is 
incomplete in some specific case. D has some of the same issues 
as C++, you either deal with details or you can choose to go more 
minimalistic in your usage.

If you read other people's D code you can easily (IMO) see that 
there is no unified style or usage of features, so it seems like 
people stick to their own understanding of «good code», which can 
make it tiresome to read D code by others (e.g. standard 
library). I guess some good coherent educational material is 
missing, people are finding their own way. There are no obvious 
codebases that highlight «best practice». I suspect 
meta-programming is pushed too much and that this has a negative 
effect on legibility of code bases.

You basically increase the cognitive load further if you choose 
to be slightly different from other languages, and focus on 
special cases. Examples: the proposal for interpolated strings, 
dip1000, certain aspects of D's generics syntax etc.

When you already have high cognitive load you should be very 
careful about not adding more "slightly unusual/unexpected" 
semantics/syntax.


> To make it more meaningful, what is your experience with other 
> languages?

I believe what makes Python a favoured language by many is that 
you can use it sporadically without relearning. Spending less 
time reading documentation is always a win.

To do things right in C++ you have to look things up all the 
time, this is only ok for people who use it many hours every week.

In general I think the ergonomics would be much better if the 
historical baggage from C/C++ had been pushed aside in favour of 
a more intuitive clean approach. I am not sure if many new users 
have a good understanding of C/C++ anyway.

Of course, this perspective is highly irrelevant as it is clear 
now that the current direction of language evolution is to 
continue to absorb C and not really be provide a clean 
improvement over C, but more like an extension. (More like C++ 
and Objective-C than Rust).

I think it will be difficult to attract young programmers with 
this approach as they are less likely to be comfortable with the 
peculiarities of C.