Future of D

[Paulo Pinto]

On Wednesday, 16 December 2020 at 10:04:03 UTC, ddcovery wrote:
> 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? :-)

You mean like this, yeah it is a bit more boilerplate, but no I 
didn't suffer an aneurysm

using System;
using System.Linq.Expressions;


public static class Helpers
{
	public static R dothis<T, R>(this T val, Expression<Func<T,R>> f)
	{
		var func = f.Compile();
		return func(val);
	}
	
	public static void dothis<T>(this T val, Expression<Action<T>> f)
	{
		var func = f.Compile();
		func(val);
	}
}

public class Program
{
	public static void Main()
	{
		0.dothis(n => assert(() => n == 0));
		System.Diagnostics.Debug.Assert(0.dothis(n => n) == 0);
		System.Diagnostics.Debug.Assert("hello".dothis(n => n) == 
"hello");
		System.Diagnostics.Debug.Assert(Helpers.dothis(true, n => n));
	}
	
	public static void assert(Expression<Func<bool>> exp) {
		var expc = exp.Compile();
		System.Diagnostics.Debug.Assert(expc());
	}
}