Andrei's list of barriers to D adoption

[Chris via Digitalmars-d]

On Tuesday, 7 June 2016 at 16:12:42 UTC, Ola Fosheim Grøstad 
wrote:
> On Tuesday, 7 June 2016 at 15:15:03 UTC, Chris wrote:
>> Features are important. Templates, for example, make writing 
>> code in general and libraries in particular much easier.
>
> Both C++ and D have simple macro-like duck-typing templates. I 
> don't find that approach particularly impressive. Yes, I use it 
> a lot, but templated programming in this fashion also easily 
> get convoluted and having multiple levels of abstraction can 
> reduce transparency and make debugging more difficult.

But we agree that templates are a good idea in general, 
regardless of the actual implementation.

>> You sound as if a wealth of features and good libraries were 
>> mutually exclusive. They are not. The problems with Phobos are 
>> not due to D's features but to a specific implementation (slow 
>> algorithms) - like in any other language.
>
> Well, D has some language features that probably should be 
> library features (like slices) and some library features that 
> should have been language features (like memory management).

What do you mean by `memory management`? GC/RC built into the 
compiler?

> However I was not complaining about "problems", but pointing 
> out that system library APIs get out-of-date over time 
> irrespective of the quality of the implementation. The more 
> detached library features are from the core language the more 
> likely they are to get out-dated.
>

What do you mean? Is it a good or a bad thing that the library is 
detached from the core language?

>> When writing software, it's important to have a wealth of 
>> features to choose from so you can use the one that best fits 
>> the task at hand.
>
> Not really.
>
> C++/D would have been better languages if they just cut all the 
> pointless special casing and boiled the core semantics down to 
> templates and functors.
>
> C++ has at least boiled lambdas down to functors and are better 
> for it.

Believe me, features will be requested. Would you have an example 
of how such a language, or better still did you have time to 
design and test one? A proof of concept.

>
>> You realize that when you have to use a language with less 
>> features, then it's repeat yourself, repeat yourself ...
>
> Not true in my experience. Which languages have you used? 
> Orthogonal minimalistic languages can be very expressive. 
> Actually, it is often the opposite, because without that 
> minimalism you have to special case a lot of stuff when similar 
> entities cannot be treated the same.
>
> However in some minimalistic languages everything looks the 
> same (like Lisp) which can make it harder to read source code. 
> Sometimes you want a DSL for readability. However I don't think 
> C++ or D score high on readability. It is not their core 
> strength.
>
> I don't find C++ std or Phobos particularly readable. I can 
> read it, but neither provide shining examples of legible code.

Having to write the same for loop with slight variations all over 
again is not my definition of efficient programming. One of D's 
strengths is that it offers nice abstractions for data 
representation.

>> Java has lambdas now (since version 8, I think) and I read 
>> somewhere that it's not certain that Java programmers will 
>> adopt (i.e. use) them at all.
>
> So, Java was designed to be a simple language, just like the 
> JVM is simple. Lambdas aren't anything special. Most languages 
> have anonymous functions. Even the minimalistic OO ones.

Not special but handy. Before Java 8 (?) you had to use 
inner/anonymous classes to mimic lambdas. Not very efficient. 
Boiler plate, repetition, the whole lot.

>> D has the advantage that its users are not so complacent and 
>> actually demand and welcome new features and happily use them. 
>> They're not lulled into believing that this or that feature is 
>> useless.
>
> Uhm... Do you really think this reflects reality? You mean the 
> D language designers and fanbois don't try to cut people down 
> when they point out where D needs improvement? ORLY???

I was not talking about that. Read it again. I said that the D 
community actively demands features or improvements and uses 
them. What you refer to has nothing to do with my point and it 
doesn't happen very often on this forum. Usually everything is 
discussed to death and beyond.

>> This is why D evolves somewhat faster which helps to attract 
>> users who look for something different, who are not happy with 
>> the status quo.
>
> But it doesn't evolve much, it adds features without fixing 
> what is already there. Which makes it harder and harder to make 
> any significant progress on the language semantics.

That's how it works. Add, test, improve. Having to wait for years 
for a feature is terrible, because you build up a code base with 
code that is not optimal and verbose (cf. Java). It goes without 
saying that existing features have to be improved. It's a 
question of manpower.

> C++ actually do improve on the existing features, lambdas was 
> improved in C++14 and further improved in C++17 (constexpr). 
> And C++'s take on lambdas is better than D lambdas. Despite C++ 
> not being able to push breaking changes, which D can (D's major 
> advantage over C++).
>
> If D improved on the existing feature set then it could stand a 
> chance. Like, it could provide better integer semantics than 
> C/C++, but chose not to. It could provide better floating point 
> semantics than C/C++ (not hard to beat, as gcc/clang messes up 
> rounding modes), but chose to stick with something even worse. 
> The only advantage D has in the template department is the 
> ability to select class-members using meta-programming. 
> Everything else you need for practical meta-programming can be 
> done just as well in C++.
>
> If you compare current day D to C++ it only have two advantage 
> points:
>
> - static if
>
> - a naive garbage collector
>
> But D lambdas are worse, floats are worse, ints are worse, simd 
> support is worse (gcc/clang) and documentation is worse.
>
> Please understand that I am not saying that C++ is really 
> great, but D is deliberately not trying to be better, but for 
> some reason choose to just be "somewhat different". That cannot 
> work out to D's advantage as both languages have too many 
> pitfalls to be suitable for newbies (in comparison to high 
> level languages).

There is a learning curve that cannot be made flatter. There are 
concepts that have to be grasped and understood. Any language 
(cf. Nim) that allows you to do sophisticated and low-level 
things is harder to learn than JS or Python.

> As such, Go is better than C++ in some domains by being 
> dependent on GC and stripping down features to the essentials. 
> Go is very unexciting, but they stuck to improving on some core 
> competitive features over time. Which paid off in that niche as 
> other languages cannot get those features within 3 years.
>
> D needs to improve too. Not by growing the feature set, but by 
> improving on what is already there.

Go forces you to repeat yourself. The less features you have, the 
more you have to write the same type of code all over again. Look 
at all the for loops in a C program.