Andrei's list of barriers to D adoption

[Ola Fosheim Grøstad via Digitalmars-d]

On Tuesday, 7 June 2016 at 19:52:47 UTC, Chris wrote:
> But we agree that templates are a good idea in general, 
> regardless of the actual implementation.

Having access to parametric abstractions is a good idea. How to 
best use them is not so obvious... in real projects where things 
changes. (Except for trivial stuff).

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

Everything related to managing ownership and access, making the 
most out of static analysis. Putting things on the stack, or 
simply not allocating if not used.

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

I mean that the standard library features that are closely 
related to the core language semantics are more stable than 
things like HTTP.

> 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.

C++ with just member functions and wrappers around builtins is 
pretty close. Yes, I have used minimalistic languages, Beta for 
instance. I believe gBeta is closer. I guess dynamic languages 
like Self and even Javascript are there too. Probably also some 
of the dependently typed languages, but I have never used those.

If you stripped down C++  by taking out everything that can be 
expressed using another feature then you would have the 
foundation.

> 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.

Hm? You can have templated functions in C++.

> 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.

Well, that is a matter of implementation. C++ lambdas are exactly 
that, function objects, but there is no inherent performance 
penalty.  A "lambda" is mostly syntactical sugar.

> I was not talking about that. Read it again. I said that the D 
> community actively demands features or improvements and uses 
> them.

Are you talking about the language or the standard library? I 
honestly don't think the latter matter much. Except for memory 
management.

> It goes without saying that existing features have to be 
> improved. It's a question of manpower.

No, it is a matter of being willing to improve the semantics. 
Many of the improvements that is needed to best C++ are simple, 
but slightly breaking, changes.

D could change floats so that interval arithmetics can be 
implemented. Which is difficult to do in clang/gcc. That would be 
a major selling point. But the basic reasoning is that this is 
not needed, because C/C++ fails to comply with the IEEE standard 
as well.

If the motivation is to trail C/C++, then there is no way to 
surpass C/C++, then there is no real motivation to switch.

> 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.

Not sure what sophisticated things you are referring to.

(JS and Python have complexity issues as well, you just don't 
need to learn them to make good use the languages).

> 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.

Loops and writing the same code over is not a major hurdle. 
Getting it right is the major hurdle. So having many loops is not 
bad, but having a way to express that you want to iterate from 1 
to 10 in a less error-prone way matters.

But you can do that in minimalistic languages like Beta that has 
only two core entities:

- a pattern (type/function/subclass)
- an instance of a pattern

Just define a pattern that iterates and prefix your body with it, 
that is the same as subclassing it.

Pseudo-code (not actual Beta syntax, but Cish syntax for 
simplicty).

iterate:{
    N:@int;
    i: @int;
    enter N
    do
       i = 0
       while (i < N)
       do
           inner; // insert prefixed do-part here
           i++
}

10 -> iterate{ do i -> print; }


Or you could just do


repeat10:{
    N:<{ n:@int; do 10->n; inner; exit n};
    i:@int;
    do N -> iterate{ do inner; }
}

repeat99:repeat10{
   N:<{ do 99->n; inner; }
}

repeat99{ do i -> print; "bottles of wine" ->print }

etc...