Future of D
ddcovery
antoniocabreraperez at gmail.com
Wed Dec 16 10:04:03 UTC 2020
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? :-)
More information about the Digitalmars-d
mailing list