Future of D

[ddcovery]

On Tuesday, 15 December 2020 at 17:45:20 UTC, a11e99z wrote:

> D is already very complicated for newbies.
> if u cannot write program (something connect to http/grpc 
> service) in a few hours than "f*ck it".
> man need 4-12 months for learning D.

 From my personal experience, the complication comes because D 
libraries and compiler itself follows the "convention" over 
"contract" way (similar to the "convention" over "configuration" 
with ruby on rails :-) ).

Example:  Do you need to be equatable... then add an "opEquals" 
method to your class/struct (operator overload)... you don't need 
to implement the "IEquatable" or "IComparable" interface.

A first look to ranges libraries (it is really impressive) 
exposes that it is based on introspection (static/compile time  
code), not on interfaces/contracts.  This makes it difficult for 
newbies to understand how it works because there is not a 
"contract" (an interface) explaining you what it does.   If you 
try to read de comments in the own library, it is oriented to doc 
generation:  it is extensive and thought for post processed 
documentation generation and really impossible (in my case) as a 
guidance to understand the function signature.  The only way to 
read this "comments" is navigating to dlang.org web and reading 
the generated documentation.

This gives the real power and weakness to D:   The missing 
contracts delegates to the compile-time static code the final 
real code generation... you need to compile to know if you are 
developing well, no interfaces/contracts can be used to guide you 
before this phase.  The problem is clean:  functions signature 
doesn't gives you enough information to understand what exactly 
it does and you need 4 or more months to acquire the knowledge 
(the intuition of the typical developer is not enough: you must 
work it to adapt)

It is like beginning with Functional programming:  you need to 
understand what it means before trying to write complex code... 
and D introduces a new paradigm itself for developers that 
usually works in "productive" more known ways.

Of course, when you change your way of thinking, D reveals it's 
real power:  *auto*, *alias*,... the same function can be applied 
to thinks that are not related.  It's magic? not: D doesn't use 
generics, it uses templates and templates are not generics.

Newbies need to understand this two main concepts:
* D is not based in contracts (it can, but it tries not to use):  
Type resolution is more "introspection" based than declaration 
based.
* D has templates, NOT generics...



Final conclusion... look at this:

void main(){
   0.doThis!(n=>assert(n==0));
   assert( 0.doThis!(n=>n) == 0 );
   assert( "hello".doThis!(s=>s) == "hello" );
   assert( "hello".doThis!(s=>s.length) == 5 );
   assert( doThis!(u=>u)(true) );
}
auto doThis(alias f, T)(T value){
   // Nothing in the "alias f" tells you that it must be an unary 
function or
   // witch type must return...
   return f(value);
}

Someone coming from java or c# will suffer an aneurysm, but it is 
really... wonderful? :-)