www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Feedback on =?UTF-8?B?w4F0aWxhJ3M=?= Vision for D

reply Mike Parker <aldacron gmail.com> writes:
This thread is for general feedback and discussion regarding 
Átila's blog post on his vision for D's future.

https://dlang.org/blog/2019/10/15/my-vision-of-ds-future/
Oct 15 2019
next sibling parent Dennis <dkorpel gmail.com> writes:
On Tuesday, 15 October 2019 at 13:09:15 UTC, Mike Parker wrote:

 https://dlang.org/blog/2019/10/15/my-vision-of-ds-future/


"meaning that today, D isn’t memory safe."

Why exactly isn't it? I thought that with -dip1000, D does not 
allow memory corruption in  safe code, except for implementation 
bugs and wrong  trusted code. The currently proposed  
borrowing/ownership related DIPs are just to make more non-GC 
memory styles  safe as far as I know, but I could be wrong.
Oct 15 2019
prev sibling next sibling parent FeepingCreature <feepingcreature gmail.com> writes:
On Tuesday, 15 October 2019 at 13:09:15 UTC, Mike Parker wrote:

 This thread is for general feedback and discussion regarding 
 Átila's blog post on his vision for D's future.

 https://dlang.org/blog/2019/10/15/my-vision-of-ds-future/


String interpolation! Love the note on mixin strings. Code 
written in that way should look similar to Lisp macros? It hadn't 
occurred to me until I saw that that string interpolation for q{} 
is basically equivalent to quasiquoting.
Oct 15 2019
prev sibling next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 15 October 2019 at 13:09:15 UTC, Mike Parker wrote:

 This thread is for general feedback and discussion regarding 
 Átila's blog post on his vision for D's future.

 https://dlang.org/blog/2019/10/15/my-vision-of-ds-future/


I'm glad to see this. I liked the old Vision documents.

One quibble where he says:

"We’re mostly there—using the actor model eliminates a lot of 
problems that would otherwise naturally occur. We need to 
finalize shared and make everything  safe as well."

On the make everything  safe, you might want to make that 
clearer. Do you mean make everything in phobos  safe? Or 
something else?

Also, the comment about using the actor model...I don't think the 
documentation states that D is using the actor model...

In this thread [1], Ola makes the argument that std.concurrency 
is not actor-based because they are not independent. I have no 
idea if that's true or not...


[1] 
https://forum.dlang.org/post/pbnovrvmsifgvwquttnp forum.dlang.org
Oct 15 2019
next sibling parent reply SrMordred <patric.dexheimer gmail.com> writes:
I Love to see more concrete words about future D.
Keep the good work!

also, waiting for the nicer traits api:

//D
const isAddable = __traits(compiles, (T t) { return t + t; });
//C++20 concepts
concept isAddable = requires (T x) { x + x; };

Losing to C++ is unacceptable ;)
Oct 15 2019
parent reply Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 15 October 2019 at 13:55:28 UTC, SrMordred wrote:

 I Love to see more concrete words about future D.
 Keep the good work!

 also, waiting for the nicer traits api:

 //D
 const isAddable = __traits(compiles, (T t) { return t + t; });
 //C++20 concepts
 concept isAddable = requires (T x) { x + x; };

 Losing to C++ is unacceptable ;)


Meh:

//C++20 concepts
concept isAddable = requires (T x) { x + x; };

// D
enum isAddable(T) = is(typeof((T x) => x + x));


We lose by one character ;)
Oct 15 2019
next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Tuesday, 15 October 2019 at 16:17:57 UTC, Atila Neves wrote:

 Meh:

 //C++20 concepts
 concept isAddable = requires (T x) { x + x; };

 // D
 enum isAddable(T) = is(typeof((T x) => x + x));


 We lose by one character ;)


The one advantage C++ concepts have over D's template predicates 
is that they're transparent to the compiler. As a result, the 
compiler is able to determine a partial order on template 
constraints [1], and use that order to resolve overloads (just 
like D does with regular function overloads [2]). D can't do 
this, so we're stuck writing awkward things like this:

auto myAlgorithm(R)(R r) if (isInputRange!R && 
!isRandomAccessRange!R) { ... }
auto myAlgorithm(R)(R r) if (isRandomAccessRange!R) { ... }

...or this:

auto myAlgorithm(R)(R r) if (isInputRange!R)
{
     static if (isRandomAccessRange!R)
         return myRandomAccessRangeImpl(r);
     else
         return myInputRangeImpl(r);
}

...in order to make our constraints both disjoint and exhaustive.

[1] 
https://en.cppreference.com/w/cpp/language/constraints#Partial_ordering_of_constraints
[2] https://digitalmars.com/articles/b20.html
Oct 15 2019
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 15 October 2019 at 16:39:47 UTC, Paul Backus wrote:

 [snip]

 The one advantage C++ concepts have over D's template 
 predicates is that they're transparent to the compiler. As a 
 result, the compiler is able to determine a partial order on 
 template constraints [1], and use that order to resolve 
 overloads (just like D does with regular function overloads 
 [2]). D can't do this, so we're stuck writing awkward things 
 like this:

 auto myAlgorithm(R)(R r) if (isInputRange!R && 
 !isRandomAccessRange!R) { ... }
 auto myAlgorithm(R)(R r) if (isRandomAccessRange!R) { ... }

 .[snip]


That's an interesting point. The problem is the template 
constraints aren't considered for the overloading, right? 
However, if they were expressed as in something like below

auto myAlgorithm(T)(InputRange!T r) { ... }
auto myAlgorithm(T)(RandomAccessRange!T r) { ... }

then I presume that it wouldn't be an issue. You might find DIP 
1023 [1] interesting. One of the purposes of DIP1023 is to allow 
for template aliases to be used like types in functions. One of 
the arguments against DIP1023 is that you can simply use template 
constraints to do the same thing. However, your example shows 
that template constraints might get complicated in some instances.

[1] 
https://github.com/dlang/DIPs/blob/bf5157d3dc29a591826e22d188448fbc04ca81b2/DIPs/DIP1023.md
Oct 15 2019
parent reply Paul Backus <snarwin gmail.com> writes:
On Tuesday, 15 October 2019 at 17:50:52 UTC, jmh530 wrote:

 On Tuesday, 15 October 2019 at 16:39:47 UTC, Paul Backus wrote:

 [snip]

 The one advantage C++ concepts have over D's template 
 predicates is that they're transparent to the compiler. As a 
 result, the compiler is able to determine a partial order on 
 template constraints [1], and use that order to resolve 
 overloads (just like D does with regular function overloads 
 [2]). D can't do this, so we're stuck writing awkward things 
 like this:

 auto myAlgorithm(R)(R r) if (isInputRange!R && 
 !isRandomAccessRange!R) { ... }
 auto myAlgorithm(R)(R r) if (isRandomAccessRange!R) { ... }

 .[snip]


 That's an interesting point. The problem is the template 
 constraints aren't considered for the overloading, right? 
 However, if they were expressed as in something like below

 auto myAlgorithm(T)(InputRange!T r) { ... }
 auto myAlgorithm(T)(RandomAccessRange!T r) { ... }

 then I presume that it wouldn't be an issue.


You misunderstand.

The problem isn't that template constraints aren't considered for 
overloading--they are. It's that, if two overloads both have 
constraints that match, the compiler has no way of telling which 
one is "more specific".

In other words, if you pass an input range to the above overload 
set, it will satisfy *both* isInputRange and isRandomAccessRange, 
because all random access ranges are also input ranges, and 
you'll get an ambiguity error. Ideally, we would like the 
compiler to understand that isRandomAccessRange is "more 
specific" than isInputRange, and choose the correct overload 
without requiring any additional disambiguation.

Because templates are Turing-complete, it is undecidable, in the 
general case, whether one template predicate is "more specific" 
than another (i.e., whether A!T == true implies B!T == true for 
all T). So there's no way to have the compiler do what we want 
unless we replace template predicates like isInputRange with 
something else that the compiler can understand without needing 
to solve the halting problem.

Some possible solutions:
   - Designate a particular subset of templates--for example, 
those whose body
     consists of a single boolean expression--as "concepts", and 
add code in the
     compiler to analyze them.
   - Add C++-style concepts as a language construct distinct from 
templates.
   - Change predicates like isInputRange to return strings instead 
of boolean
     values, and use mixin to inject their expressions directly 
into template
     constraints without evaluating them first.
   - Add AST macros to D, and change predicates like isInputRange 
into macros
     that return unevaluated expressions instead of boolean values.
Oct 15 2019
next sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Tuesday, 15 October 2019 at 18:39:44 UTC, Paul Backus wrote:

   - Add AST macros to D, and change predicates like 
 isInputRange into macros
     that return unevaluated expressions instead of boolean 
 values.


Not going to happen, walter had express numerous times that AST 
Macros are not going to be accepted.

- Alex
Oct 15 2019
parent Paul Backus <snarwin gmail.com> writes:
On Tuesday, 15 October 2019 at 18:52:24 UTC, 12345swordy wrote:

 On Tuesday, 15 October 2019 at 18:39:44 UTC, Paul Backus wrote:

   - Add AST macros to D, and change predicates like 
 isInputRange into macros
     that return unevaluated expressions instead of boolean 
 values.


 Not going to happen, walter had express numerous times that AST 
 Macros are not going to be accepted.

 - Alex


Yes, I'm aware. It wasn't meant as a serious proposal, just an 
example.
Oct 15 2019
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 15 October 2019 at 18:39:44 UTC, Paul Backus wrote:

 [snip]

 You misunderstand.


I think I understood it, though perhaps I wasn't able to 
communicate myself as well as I tended.

So for instance, suppose we have

enum isSlice(T) = is(T: Slice!(U), U);
auto foo(T)(T m) if(isSlice!T) { /* ... */ }

and then we also add
enum isPackedUpperTriangularMatrix(T) = is(T: 
Slice!(StairsIterator!(U*, "-")), U);
auto foo(T)(T m) if(isPackedUpperTriangularMatrix!T) { /* ... */ }

this has the same problems you describe with input range and 
random access range. A packed upper triangular matrix should 
satisfy both.

DIP1023 addresses creating the alias
alias PackedUpperTriangularMatrix(T) = Slice!(StairsIterator!(T*, 
"-"));
and then enabling the ability to write
auto foo(T)(PackedUpperTriangularMatrix!T m) { }
without the current error.

Nothing would be stopping you from writing the equivalent of
auto foo(T)(Slice!T m) { }
as well.

That last version of foo taking a slice would be the equivalent 
of your input range version, while the second one would be the 
equivalent of random access range version. Unlike above, these 
examples are no longer using the template constraints. It is 
treating the aliases as types so the normal function overloading 
rules should apply.
Oct 15 2019
parent reply Paul Backus <snarwin gmail.com> writes:
On Tuesday, 15 October 2019 at 23:52:52 UTC, jmh530 wrote:

 DIP1023 addresses creating the alias
 alias PackedUpperTriangularMatrix(T) = 
 Slice!(StairsIterator!(T*, "-"));
 and then enabling the ability to write
 auto foo(T)(PackedUpperTriangularMatrix!T m) { }
 without the current error.

 Nothing would be stopping you from writing the equivalent of
 auto foo(T)(Slice!T m) { }
 as well.

 That last version of foo taking a slice would be the equivalent 
 of your input range version, while the second one would be the 
 equivalent of random access range version. Unlike above, these 
 examples are no longer using the template constraints. It is 
 treating the aliases as types so the normal function 
 overloading rules should apply.


This does not solve the ambiguity issue. If I write the 
equivalent code with the aliases expanded by hand, I get a 
compile-time error:

import std.stdio;

struct Outer(T) {}
struct Inner(T) {}

void fun(T)(Outer!(Inner!T) arg) { writeln("Outer!(Inner!T)"); }
void fun(T)(Outer!T arg) { writeln("Outer!T"); }

void main() {
     Outer!(Inner!int) x;
     fun(x); // Error: onlineapp.fun called with argument types 
[...] matches both:
}

https://run.dlang.io/is/pHPa89
Oct 15 2019
parent jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 16 October 2019 at 00:22:08 UTC, Paul Backus wrote:

 [snip]

 This does not solve the ambiguity issue. If I write the 
 equivalent code with the aliases expanded by hand, I get a 
 compile-time error:
 [snip]


Damn. What you have seems to make sense.

I made some example earlier today that seemed to work, but I'm 
not sure I saved it to see where I went wrong. I feel like I had 
an alias this in there somewhere, but can't seem to replicate it 
now...
Oct 15 2019
prev sibling parent reply Sebastiaan Koppe <mail skoppe.eu> writes:
On Tuesday, 15 October 2019 at 16:39:47 UTC, Paul Backus wrote:

 The one advantage C++ concepts have over D's template 
 predicates is that they're transparent to the compiler. As a 
 result, the compiler is able to determine a partial order on 
 template constraints [1], and use that order to resolve 
 overloads (just like D does with regular function overloads 
 [2]). D can't do this, so we're stuck writing awkward things 
 like this:

 auto myAlgorithm(R)(R r) if (isInputRange!R && 
 !isRandomAccessRange!R) { ... }
 auto myAlgorithm(R)(R r) if (isRandomAccessRange!R) { ... }


Surely it would be possible to define a partial ordering over our 
template constraints.

Since isRandomAccessRange!R includes isForwardRange!R (which 
includes isInputRange!R), the compiler should be able to 
determine that isRandomAccessRange!R is more strict than 
isInputRange!R.

If anything, you could simply count the && and the ||'s. That is, 
A && B > B. That ought to be a simple AST+lookup operation. Right?
Oct 15 2019
parent reply Paul Backus <snarwin gmail.com> writes:
On Wednesday, 16 October 2019 at 06:53:37 UTC, Sebastiaan Koppe 
wrote:

 Surely it would be possible to define a partial ordering over 
 our template constraints.

 Since isRandomAccessRange!R includes isForwardRange!R (which 
 includes isInputRange!R), the compiler should be able to 
 determine that isRandomAccessRange!R is more strict than 
 isInputRange!R.

 If anything, you could simply count the && and the ||'s. That 
 is, A && B > B. That ought to be a simple AST+lookup operation. 
 Right?


Template bodies may be arbitrarily complex, and determining 
whether one template predicate implies another is 
halting-equivalent in the general case.

The only way you can do this kind of analysis is if you define, 
in the language spec, a restricted subset of templates to apply 
it to--for example, enum templates whose body consists of a 
single boolean expression.

Personally, I find that kind of special-case handling a bit 
unprincipled, so it wouldn't be my first choice, but it's 
probably the shortest path from where we are now to partial 
ordering for template constraints.
Oct 16 2019
parent reply Sebastiaan Koppe <mail skoppe.eu> writes:
On Wednesday, 16 October 2019 at 13:07:30 UTC, Paul Backus wrote:

 On Wednesday, 16 October 2019 at 06:53:37 UTC, Sebastiaan Koppe

 If anything, you could simply count the && and the ||'s. That 
 is, A && B > B. That ought to be a simple AST+lookup 
 operation. Right?


 Template bodies may be arbitrarily complex, and determining 
 whether one template predicate implies another is 
 halting-equivalent in the general case.


If it would halt on your templates, wouldn't the compiler also 
halt compiling them in the first place?

But I wouldn't go as far as actually evaluating them, just look 
at the symbols.

That would probably result in A || B > B regardless of whether A 
is false or not. But then again why would you write such 
overloads?

Might be a nice project to try to solve with dmd as a library or 
libdparse, to see if it is more than just an idea.
Oct 16 2019
parent reply Paul Backus <snarwin gmail.com> writes:
On Wednesday, 16 October 2019 at 15:02:25 UTC, Sebastiaan Koppe 
wrote:

 But I wouldn't go as far as actually evaluating them, just look 
 at the symbols.

 That would probably result in A || B > B regardless of whether 
 A is false or not. But then again why would you write such 
 overloads?


Consider the following example:

enum isA(T) = __traits(compiles, ...);
enum isB(T) = __traits(compiles, ...);
enum isC(T) = __traits(compiles, ...);

enum isAB(T) = isA!T && isB!T;
enum isAC(T) = isA!T && isC!T;
enum isBC(T) = isB!T && isC!T;

auto fun(T)(T t) if (isAB!T) { ... }
auto fun(T)(T t) if (isAC!T && isBC!T) { ... }

C++'s partial ordering for concepts is able to correctly 
determine that the second overload is more specialized than the 
first. Your proposed solution that only examines the symbols is 
not.


 Might be a nice project to try to solve with dmd as a library 
 or libdparse, to see if it is more than just an idea.


Overload resolution is handled entirely inside the compiler, so 
an external tool won't help.
Oct 16 2019
parent reply Sebastiaan Koppe <mail skoppe.eu> writes:
On Wednesday, 16 October 2019 at 15:39:16 UTC, Paul Backus wrote:

 Consider the following example:

 enum isA(T) = __traits(compiles, ...);
 enum isB(T) = __traits(compiles, ...);
 enum isC(T) = __traits(compiles, ...);

 enum isAB(T) = isA!T && isB!T;
 enum isAC(T) = isA!T && isC!T;
 enum isBC(T) = isB!T && isC!T;

 auto fun(T)(T t) if (isAB!T) { ... }
 auto fun(T)(T t) if (isAC!T && isBC!T) { ... }

 C++'s partial ordering for concepts is able to correctly 
 determine that the second overload is more specialized than the 
 first. Your proposed solution that only examines the symbols is 
 not.


Yes it would. But maybe I am not explaining myself well enough. 
If you were to substitute the symbols and literally count the 
boolean operators, the fun's would get 1 and 3 respectively. That 
is what I meant with ast+lookup. Sorry for being so brief.

This is a very alpha idea and far from a solution, it is just 
that I don't believe it can't be done.


 Might be a nice project to try to solve with dmd as a library 
 or libdparse, to see if it is more than just an idea.


 Overload resolution is handled entirely inside the compiler, so 
 an external tool won't help.


Of course, I understand, but it would suffice as a way to 
validate the idea. Just give it a bunch of code and it would 
output the ordering of function overloads with template 
constraints. See it as a cheap way to validate an idea before 
mucking in the compiler.

Anyway, I have already talked about it too much.
Oct 16 2019
parent reply Paul Backus <snarwin gmail.com> writes:
On Wednesday, 16 October 2019 at 18:15:45 UTC, Sebastiaan Koppe 
wrote:

 C++'s partial ordering for concepts is able to correctly 
 determine that the second overload is more specialized than 
 the first. Your proposed solution that only examines the 
 symbols is not.


 Yes it would. But maybe I am not explaining myself well enough. 
 If you were to substitute the symbols and literally count the 
 boolean operators, the fun's would get 1 and 3 respectively. 
 That is what I meant with ast+lookup. Sorry for being so brief.


In that case, your algorithm will give false positives, which I 
consider grounds for disqualification. For example:

auto fun(T)(T arg) if (isA!T) { ... }
auto fun(T)(T arg) if (isA!T && isA!T) { ... }

Currently, these overloads are (correctly) considered ambiguous. 
If we go by symbol counts, however, the second overload would be 
preferred.


 This is a very alpha idea and far from a solution, it is just 
 that I don't believe it can't be done.


Obviously it can be done: C++ already does it. The question is 
not *whether* the problem can be solved, but *which* of several 
possible solutions is the best fit for D.
Oct 16 2019
parent Sebastiaan Koppe <mail skoppe.eu> writes:
On Wednesday, 16 October 2019 at 18:27:21 UTC, Paul Backus wrote:

 In that case, your algorithm will give false positives, which I 
 consider grounds for disqualification. For example:

 auto fun(T)(T arg) if (isA!T) { ... }
 auto fun(T)(T arg) if (isA!T && isA!T) { ... }


Haha. Yes, you are right. It would need to be a little more 
sophisticated.


 This is a very alpha idea and far from a solution, it is just 
 that I don't believe it can't be done.


 Obviously it can be done: C++ already does it. The question is 
 not *whether* the problem can be solved, but *which* of several 
 possible solutions is the best fit for D.


I apologize, I read in between the lines that you considered it 
impossible in D as it is now.
Oct 16 2019
prev sibling parent reply JN <666total wp.pl> writes:
On Tuesday, 15 October 2019 at 16:17:57 UTC, Atila Neves wrote:

 Meh:

 //C++20 concepts
 concept isAddable = requires (T x) { x + x; };

 // D
 enum isAddable(T) = is(typeof((T x) => x + x));


 We lose by one character ;)


I disagree. It's not just one character. C++ example is much 
cleaner. Imagine not being experienced with C++ and D and seeing 
these two examples.

C++ line of thought: we're defining a concept isAddable, which is 
something that requires that there is some x that can be added to 
itself.

D line of thought: we're defining an enum (why enum? why would I 
want an enumeration here?) isAddable of type T which is something 
that is a typeof (wait, why do I have to repeat the T here 
again)?? What does that even mean "is(typeof())"?

It feels more complicated for a bystander. Actually, 
__traits(compiles) would be even cleaner in this case, because 
the is(typeof()) part, while could be considered a D idiom, feels 
very unexpected.
Oct 16 2019
parent reply Atila Neves <atila.neves gmail.com> writes:
On Wednesday, 16 October 2019 at 07:09:38 UTC, JN wrote:

 On Tuesday, 15 October 2019 at 16:17:57 UTC, Atila Neves wrote:

 Meh:

 //C++20 concepts
 concept isAddable = requires (T x) { x + x; };

 // D
 enum isAddable(T) = is(typeof((T x) => x + x));


 We lose by one character ;)


 I disagree. It's not just one character. C++ example is much 
 cleaner. Imagine not being experienced with C++ and D and 
 seeing these two examples.


Ok:

enum requires(alias F) = is(typeof(F));
enum isAddable(T) = requires!((T x) => x + x);
static assert(isAddable!int);


 C++ line of thought: we're defining a concept isAddable, which 
 is something that requires that there is some x that can be 
 added to itself.


I don't see the difference in D.


 D line of thought: we're defining an enum (why enum? why would 
 I want an enumeration here?) isAddable of type T which is 
 something that is a typeof (wait, why do I have to repeat the T 
 here again)?? What does that even mean "is(typeof())"?

 It feels more complicated for a bystander. Actually, 
 __traits(compiles) would be even cleaner in this case, because 
 the is(typeof()) part, while could be considered a D idiom, 
 feels very unexpected.


Valid point on `is(typeof)`, but as seen above easy to fix. I 
don't agree on `enum` though, because that's D syntax that's 
extremely unlikely to change.
Oct 16 2019
parent reply John Colvin <john.loughran.colvin gmail.com> writes:
On Wednesday, 16 October 2019 at 11:08:18 UTC, Atila Neves wrote:

 On Wednesday, 16 October 2019 at 07:09:38 UTC, JN wrote:

 On Tuesday, 15 October 2019 at 16:17:57 UTC, Atila Neves wrote:

 Meh:

 //C++20 concepts
 concept isAddable = requires (T x) { x + x; };

 // D
 enum isAddable(T) = is(typeof((T x) => x + x));


 We lose by one character ;)


 I disagree. It's not just one character. C++ example is much 
 cleaner. Imagine not being experienced with C++ and D and 
 seeing these two examples.


 Ok:

 enum requires(alias F) = is(typeof(F));
 enum isAddable(T) = requires!((T x) => x + x);
 static assert(isAddable!int);


static assert(!isAddable!string); doesn't work so nicely
Oct 16 2019
parent Atila Neves <atila.neves gmail.com> writes:
On Wednesday, 16 October 2019 at 15:39:21 UTC, John Colvin wrote:

 On Wednesday, 16 October 2019 at 11:08:18 UTC, Atila Neves 
 wrote:

 On Wednesday, 16 October 2019 at 07:09:38 UTC, JN wrote:

 On Tuesday, 15 October 2019 at 16:17:57 UTC, Atila Neves 
 wrote:

 Meh:

 //C++20 concepts
 concept isAddable = requires (T x) { x + x; };

 // D
 enum isAddable(T) = is(typeof((T x) => x + x));


 We lose by one character ;)


 I disagree. It's not just one character. C++ example is much 
 cleaner. Imagine not being experienced with C++ and D and 
 seeing these two examples.


 Ok:

 enum requires(alias F) = is(typeof(F));
 enum isAddable(T) = requires!((T x) => x + x);
 static assert(isAddable!int);


 static assert(!isAddable!string); doesn't work so nicely


Ugh, good point.
Oct 16 2019
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 15 October 2019 at 13:34:46 UTC, jmh530 wrote:

 In this thread [1], Ola makes the argument that std.concurrency 
 is not actor-based because they are not independent.


D most certainly isn't actor based, although you can provide 
libraries that enable actor-like modelling. It is not 
unreasonable to say such in a blog post where people should 
interpret things less formally.

What I pointed out was that it is unreasonable to claim it in the 
online documentation.

Fault tolerance is a key aspects of actors. For that you need 
independence between actors. D can never provide that with a 
library.
Oct 15 2019
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 15 October 2019 at 14:53:47 UTC, Ola Fosheim Grøstad 
wrote:

 On Tuesday, 15 October 2019 at 13:34:46 UTC, jmh530 wrote:

 In this thread [1], Ola makes the argument that 
 std.concurrency is not actor-based because they are not 
 independent.


 D most certainly isn't actor based, although you can provide 
 libraries that enable actor-like modelling. It is not 
 unreasonable to say such in a blog post where people should 
 interpret things less formally.

 What I pointed out was that it is unreasonable to claim it in 
 the online documentation.

 Fault tolerance is a key aspects of actors. For that you need 
 independence between actors. D can never provide that with a 
 library.


For those interested:

https://en.wikipedia.org/wiki/Actor_model#Fundamental_concepts

D can not provide any of these qualities.

The term «actor» is more loosely used than «the actor model» 
though, so you can have «actors» even if you don't implement «the 
actor model».
Oct 15 2019
prev sibling next sibling parent WebFreak001 <d.forum webfreak.org> writes:
On Tuesday, 15 October 2019 at 13:09:15 UTC, Mike Parker wrote:

 This thread is for general feedback and discussion regarding 
 Átila's blog post on his vision for D's future.

 https://dlang.org/blog/2019/10/15/my-vision-of-ds-future/


* Memory safety
* Make D the default implementation language
* Second to none reflection.
* Fast development times.

my favorite points out of all the good points! The concurrency 
goal sounds a bit vague but otherwise I am looking forward to how 
D will develop with these visions in mind. I definitely think 
they will all be improvements which will greatly improve our 
lifes using D.
Oct 15 2019
prev sibling next sibling parent Fynn =?UTF-8?B?U2NocsO2ZGVy?= <fynnos live.com> writes:
Exciting vision!

My favorites are

* Memory safety combined with Safe and easy concurrency: Add a 
way to globally use RC instead of GC for high-concurrency 
situations (to mitigate stop-the-world issues) would be awesome
* Fast development times: Apart from unittests, an interpreter 
could greatly boost D's usage in data science (think Jupyter 
Notebook) by leveraging the excellent mir-libraries
* String interpolation: Really handy with string mixins!
* Make D the default implementation language: This is both bold 
vision.. when thinking of widespread adoption - yet improvements 
regarding the other visions should greatly help

Cheers!
Oct 15 2019
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Oct 15, 2019 at 01:09:15PM +0000, Mike Parker via Digitalmars-d wrote:

 This thread is for general feedback and discussion regarding tila's
 blog post on his vision for D's future.
 
 https://dlang.org/blog/2019/10/15/my-vision-of-ds-future/


 safe by default sounds like a VERY good idea. Can't wait to see when
we start transitioning! (Though, I'm not holding my breath on it atm --
I realize there's a lot to be done before this will be possible.)

Making D the default implementation language: this sounds a bit general.
What exactly does this mean, and what exactly does it entail?  Is this
pushing for better marketing ("hey world, let's use D as the default
implementation language"), or are we talking about something on the
implementation side here?

Interop with C++: while I applaud this goal, I'm not sure how exactly
we're going to pull this off, seeing as there are some fundamental
incompatibilities with C++ like transitive const, no Koenig lookups, a
different (albeit mostly compatible) templating system, etc.. Back in
the day C++ started off as essentially "C with classes", meaning
existing C code was practically 100% compilable as C++ (of course, there
are some subtle differences, but for the most part this is true). But
with D, some syntax like templates have a fundamentally different
syntax, and you're not gonna be able to just compile non-trivial C++
code as D without endless pages of syntax errors. This, of course, is
merely at the syntactic level. But the lack of transitive const is a
deeper problem that isn't going to be easy to solve: C++ programmers
expect to be able to cast away const without invoking UB, and in D you
just can't do that without getting into UB land.

//

Anyway, as for pet peeves / pet features: I'd like to propose having a
plan for Phobos v2 as Andrei has mentioned once.  There are some design
decisions in Phobos that are hard to reverse now, like autodecoding, the
whole shebang about .save in std.range, etc.. We *might* be able to pull
off removing autodecoding as a gradual transition, but that's impossible
for the range API since just about *everything* in Phobos uses it. The
only possible way I see is std.v2.

Plus, I'd like to see this not just as a one-off thing, but an ongoing
development and refinement of D as time goes on.  In the realm of
natural languages, languages are a living, dynamic thing that changes
and develops over time, adapting to the circumstances it's used in; it's
not a static thing that stays fixed forever. (A static natural language
is a dead one -- like Latin.)  IMO a programming language also has to be
constantly adapting and developing to fit contemporary needs, and one
should not expect it to stay static forever.  In more practical terms,
this means D needs to have *official mechanisms* in place for retiring
old features (not necessarily get rid of them -- nobody wants to be
rewriting legacy code every 5 years -- we can keep old features in the
back closet as long as they don't interfere with new ones) and
introducing new ones. std.v2 is one step in this direction, and I'd like
to see a consistent, workable scheme that would allow for std.v3,
std.v4, etc., in the distant future.

There is already the current deprecation process for relatively small,
gradual transitions; but I'd like to see a process for larger-scale
(probably longer-term) changes like std.v2, reworking the range API,
etc..


T

-- 
The right half of the brain controls the left half of the body. This means that
only left-handed people are in their right mind. -- Manoj Srivastava
Oct 15 2019
next sibling parent Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 15 October 2019 at 14:38:41 UTC, H. S. Teoh wrote:

 On Tue, Oct 15, 2019 at 01:09:15PM +0000, Mike Parker via 
 Digitalmars-d wrote:

 This thread is for general feedback and discussion regarding 
 Átila's blog post on his vision for D's future.
 
 https://dlang.org/blog/2019/10/15/my-vision-of-ds-future/


  safe by default sounds like a VERY good idea. Can't wait to 
 see when we start transitioning! (Though, I'm not holding my 
 breath on it atm -- I realize there's a lot to be done before 
 this will be possible.)

 Making D the default implementation language: this sounds a bit 
 general. What exactly does this mean, and what exactly does it 
 entail?  Is this pushing for better marketing ("hey world, 
 let's use D as the default implementation language"), or are we 
 talking about something on the implementation side here?


I mean "Write once (in D), wrap everywhere". No need for an IDL,
no need for translating, just generalise autowrap as it exists now
to make the (hopefully high-performant) D implementation be 
callable


I'm close to be able to write a blog post on how the easiest way 
to call C code from Python right now is D. Run dpp -> use 
autowrap -> no code written and everything is now available from 




 Interop with C++: while I applaud this goal, I'm not sure how 
 exactly we're going to pull this off,


Me neither. But we're in a better position than anyone else to do 
it, and if it happens to work in enough use cases we'll have a 
competitive advantage.


 C++ programmers expect to be able to cast away const without 
 invoking UB,


Which is only *not* UB if the data wasn't const to begin with. 
Otherwise...


 Anyway, as for pet peeves / pet features: I'd like to propose 
 having a plan for Phobos v2 as Andrei has mentioned once.  
 There are some design decisions in Phobos that are hard to 
 reverse now, like autodecoding, the whole shebang about .save 
 in std.range, etc.. We *might* be able to pull off removing 
 autodecoding as a gradual transition, but that's impossible for 
 the range API since just about *everything* in Phobos uses it. 
 The only possible way I see is std.v2.


I've thought about Phobos v2 but haven't been able to conclude 
anything yet.
Oct 15 2019
prev sibling parent berni44 <dlang d-ecke.de> writes:
On Tuesday, 15 October 2019 at 14:38:41 UTC, H. S. Teoh wrote:

 but I'd like to see a process for larger-scale (probably 
 longer-term) changes like std.v2, reworking the range API, etc..


+1
Oct 16 2019
prev sibling next sibling parent reply Meta <jared771 gmail.com> writes:
On Tuesday, 15 October 2019 at 13:09:15 UTC, Mike Parker wrote:

 This thread is for general feedback and discussion regarding 
 Átila's blog post on his vision for D's future.

 https://dlang.org/blog/2019/10/15/my-vision-of-ds-future/


"Instead of disparate ways of getting things done with fragmented 
APIs (__traits, std.traits, custom code), I’d like for there to 
be a library that centralizes all reflection needs with a great 
API."

Yes, 100% agreed. Another benefit of having one unified API is 
that it's easier to paper over the weird differences between 
various methods of doing reflection.

Ex:

is(typeof({ return x + x; })) vs __traits(compiles, { return x + 
x; })

__traits(identifier, x) vs. x.stringof (x.stringof will fail to 
compile if x is a function with at least 1 parameter, but 
__traits(identifier) works)

I'm curious, is Atila's work on this building on Andrei's? I 
remember him talking about his work on a reflection library at a 
recent DConf (I think it was last year's).

"String interpolation"

I've been finding a lot of places in my code where string 
interpolation would make it much more readable. It would be nice 
to be able to use them in invariants, in contracts, out 
contracts, and assert statements, e.g.:

struct OneIndexedArray(T)
{
     T[] store;

     T opIndex(size_t i)
     in (i > 0, "Index $i is out of range for 
$(OneIndexedArray.stringof)")
     in (i < store.length,
          "Index is out of range for $(OneIndexedArray.stringof) 
(length: $(store.length), index: $i")
     {
         ...
     }
}

It's a real pain having to stick a 
`.format(OneIndexedArray.stringof, store.length, i)` at the end 
of the message.

pragma(msg) get's this right, presumably because it's a compile 
time-only construct.
Oct 15 2019
parent reply Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 15 October 2019 at 15:05:52 UTC, Meta wrote:

 On Tuesday, 15 October 2019 at 13:09:15 UTC, Mike Parker wrote:

 This thread is for general feedback and discussion regarding 
 Átila's blog post on his vision for D's future.

 https://dlang.org/blog/2019/10/15/my-vision-of-ds-future/





 I'm curious, is Atila's work on this building on Andrei's? I 
 remember him talking about his work on a reflection library at 
 a recent DConf (I think it was last year's).


Yes, I'm stealing Andrei's idea. I'm currently working on said 
reflection library.


 It's a real pain having to stick a 
 `.format(OneIndexedArray.stringof, store.length, i)` at the end 
 of the message.


I suggest using `std.conv.text` instead. For one liners it's 
(IMHO) nearly the same as string interpolation. I think string 
interpolation only comes into its own with multi-line strings, 
which is common in D because of string mixins and q{}.


 pragma(msg) get's this right, presumably because it's a compile 
 time-only construct.


std.conv.text works exactly the same way.
Oct 15 2019
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 15 October 2019 at 16:22:22 UTC, Atila Neves wrote:

 I suggest using `std.conv.text` instead. For one liners it's 
 (IMHO) nearly the same as string interpolation. I think string 
 interpolation only comes into its own with multi-line strings, 
 which is common in D because of string mixins and q{}.


I find declaration names to be the most common place to actually 
concatenate strings in well-written code... and really, 
interpolation wouldn't help that much compared to `}~VAR~q{`...
Oct 15 2019
prev sibling parent Meta <jared771 gmail.com> writes:
On Tuesday, 15 October 2019 at 16:22:22 UTC, Atila Neves wrote:

 I suggest using `std.conv.text` instead. For one liners it's 
 (IMHO) nearly the same as string interpolation. I think string 
 interpolation only comes into its own with multi-line strings, 
 which is common in D because of string mixins and q{}.


 pragma(msg) get's this right, presumably because it's a 
 compile time-only construct.


 std.conv.text works exactly the same way.


I know, and I do like std.conv.text, but you can't put it in 
trailing/UFCS position with multiple arguments:

//doesn't work
in (a < b, ("argument must be greater than argument b (a: ", a, 
", b: ", b, ")").text())

And it causes me great pain to write `text("a message ", with " 
lots of ", interleaved, " ", arguments)`

Which is why I prefer to use format (not to mention the comma 
soup making the string much more busy visually with text()).

With interpolated strings, presumably this could be allowed?

i"argument must be greater than argument b (a: $a, b: $b)".text()

Which I could live with, but would still prefer it if even the 
text() could be omitted.
Oct 15 2019
prev sibling next sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Tuesday, 15 October 2019 at 13:09:15 UTC, Mike Parker wrote:

 This thread is for general feedback and discussion regarding 
 Átila's blog post on his vision for D's future.

 https://dlang.org/blog/2019/10/15/my-vision-of-ds-future/


If you pardon me making yet another "D need this" post:

(This is not a criticism about the vision but more an observation 
of the D vision until now)

There are no "community" points in the above vision but mostly 
language points, so I think it continues in a not-that-fruitful 
direction, a sort of escapism.

Language nowadays are co-designed along with the community ; this 
community's task is to create the open-source ecosystem that will 
lure users into using the language. Of course, it's up to the 
community to self-organize, however a bit of topdown 
organizing/funneling users can always help.


use a new programming language.

But the problem is that our ecosystem of libraries, while it 
exists and has solution for most everything, interoperates pretty 
badly. It is not maintained enough (or for the latest compilers 
only), and/or isn't generally dependable.

Perhaps because of our native backgrounds, we are still quite bad 
at sharing code. Nothing to do with what happens in the NPM 
ecosystem. We need to go out of our way to create high-quality, 
dependable software artifacts with shared maintenance that can be 
reused.

This means, practically-speaking:
- fixed DUB rankings
- fixed DUB search
- gamification of HQ library creation
- focus on DUB user experience (the one gateway to compiler 
cmdline)
- cooperation over multiple-solutions
- better documentation as a way to get the people to do the above 
points

I'm just not excited about language-level features
Oct 15 2019
next sibling parent Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 15 October 2019 at 16:16:24 UTC, Guillaume Piolat 
wrote:

 On Tuesday, 15 October 2019 at 13:09:15 UTC, Mike Parker wrote:

 [...]


 If you pardon me making yet another "D need this" post:

 (This is not a criticism about the vision but more an 
 observation of the D vision until now)

 [...]


These are very good points. Thanks for bringing them up!
Oct 15 2019
prev sibling next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 15 October 2019 at 16:16:24 UTC, Guillaume Piolat 
wrote:

 - fixed DUB rankings




clearly the rankings are already fixed :P
Oct 15 2019
prev sibling parent reply Chris <wendlec tcd.ie> writes:
On Tuesday, 15 October 2019 at 16:16:24 UTC, Guillaume Piolat 
wrote:

 If you pardon me making yet another "D need this" post:

 (This is not a criticism about the vision but more an 
 observation of the D vision until now)

 There are no "community" points in the above vision but mostly 
 language points, so I think it continues in a not-that-fruitful 
 direction, a sort of escapism.

 Language nowadays are co-designed along with the community ; 
 this community's task is to create the open-source ecosystem 
 that will lure users into using the language. Of course, it's 
 up to the community to self-organize, however a bit of topdown 
 organizing/funneling users can always help.


 use a new programming language.

 But the problem is that our ecosystem of libraries, while it 
 exists and has solution for most everything, interoperates 
 pretty badly. It is not maintained enough (or for the latest 
 compilers only), and/or isn't generally dependable.

 Perhaps because of our native backgrounds, we are still quite 
 bad at sharing code. Nothing to do with what happens in the NPM 
 ecosystem. We need to go out of our way to create high-quality, 
 dependable software artifacts with shared maintenance that can 
 be reused.

 This means, practically-speaking:
 - fixed DUB rankings
 - fixed DUB search
 - gamification of HQ library creation
 - focus on DUB user experience (the one gateway to compiler 
 cmdline)
 - cooperation over multiple-solutions
 - better documentation as a way to get the people to do the 
 above points

 I'm just not excited about language-level features


Good point, and it has been made before by various people on the 
forum. Átilas vision sounds good and very ambitious. Then again, 
D also needs a clean up due to failed ambitions in the past, and 
D needs proper tooling (like in the Java world). So what you need 
are TWO teams: one that cleans up, improves and extends D, and 
one that builds the tooling and infrastructure. The latter will 
be more difficult to find, because from what I've seen on this 
forum it seems that most professional and hobby users don't care 
so much about the tools as they often have their own custom made 
build tools for D and they are much more interested in features 
and libraries.

Does anyone have a plan how to get people on board who want to 
invest time and effort in a sound ecosystem? It seems that D 
hasn't reached the critical mass of users yet that enough people 
are frustrated and thus join efforts to make things easier (again 
cf. Java). How will you guys tackle that?
Oct 16 2019
next sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Wednesday, 16 October 2019 at 08:13:34 UTC, Chris wrote:

 On Tuesday, 15 October 2019 at 16:16:24 UTC, Guillaume Piolat 
 wrote:

 If you pardon me making yet another "D need this" post:


 Good point, and it has been made before by various people on 
 the forum. Átilas vision sounds good and very ambitious. Then 
 again, D also needs a clean up due to failed ambitions in the 
 past, and D needs proper tooling (like in the Java world).


What tooling what you like to see developed that doesn't exist 
now?
I keep reading online that Go has great tooling, but having used 
it I don't know what people mean when they say that. Likewise, I 
read that people want D to have great tooling but I also don't 
know what they mean then either.


 hobby users don't care so much about the tools as they often 
 have their own custom made build tools for D


AFAIK nearly everybody uses dub. What else would you like to see 
in this area?
Oct 16 2019
next sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Wed, 2019-10-16 at 11:14 +0000, Atila Neves via Digitalmars-d wrote:
[=E2=80=A6]

 What tooling what you like to see developed that doesn't exist=20
 now?


A D plugin to CLion as good as the Rust plugin.

There are some people working on this but it needs more resource: a collect=
ion
of volunteers are not going to be able to achieve what three or four fullti=
me
people could.


 I keep reading online that Go has great tooling, but having used=20
 it I don't know what people mean when they say that. Likewise, I=20
 read that people want D to have great tooling but I also don't=20
 know what they mean then either.


There is one and only one acceptable formatting of all Go code. The formatt=
ers
enforce this. Fortunately I quite like the Go code style, unlike the Phobos=
 D
style which I find hideous =E2=80=93 hence me contributing nothing.

GoLand is very good.

Tooling is all about the UI people use to develop code (obvious but it seem=
s
to need saying). Emacs and Vi are all very well but they are very 1980s
whatever people might do with them in 2010s. The 2000s brought us IDEs,
originally not very good but now the obvious choice for all software
development. Go has Goland; Rust, C, and C++ have CLion; Java, Kotlin, Groo=
vy,
Clojure, etc. have IntelliJIDEA; and Python has PyCharm =E2=80=93 and yes I=
 am as I
appear to be, a fan of JetBrain IDEs.

Sadly the D plugin to CLion is really not good enough for production use, n=
ot
from lack of volunteers trying to do stuff, but because volunteers can only
start stuff like this. After a while it needs a full-time team. The Rust
plugin got taken on by JetBrains. I really cannot see JetBrains taking on t=
he
D plugin, so that is not a route to resourcing a quality UI for development=
.


 AFAIK nearly everybody uses dub. What else would you like to see=20
 in this area?


Something much less like Dub and a lot more like Cargo.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk
Oct 16 2019
next sibling parent reply bachmeier <no spam.net> writes:
On Wednesday, 16 October 2019 at 12:01:09 UTC, Russel Winder 
wrote:


 Tooling is all about the UI people use to develop code (obvious 
 but it seems to need saying). Emacs and Vi are all very well 
 but they are very 1980s whatever people might do with them in 
 2010s. The 2000s brought us IDEs, originally not very good but 
 now the obvious choice for all software development. Go has 
 Goland; Rust, C, and C++ have CLion; Java, Kotlin, Groovy, 
 Clojure, etc. have IntelliJIDEA; and Python has PyCharm – and 
 yes I am as I appear to be, a fan of JetBrain IDEs.

 Sadly the D plugin to CLion is really not good enough for 
 production use, not from lack of volunteers trying to do stuff, 
 but because volunteers can only start stuff like this. After a 
 while it needs a full-time team. The Rust plugin got taken on 
 by JetBrains. I really cannot see JetBrains taking on the D 
 plugin, so that is not a route to resourcing a quality UI for 
 development.


The reality is that many programmers use IDEs, so any language 
that doesn't have them is losing out. It's my impression, though, 
that this community has settled on VS and VS Code as the IDE of 
choice. Monetary resources should continue to go into those 
efforts so that we can offer at least one good IDE. (Disclaimer: 
I no longer use IDEs, so my impression might be wrong.)
Oct 16 2019
parent reply Russel Winder <russel winder.org.uk> writes:
On Wed, 2019-10-16 at 13:22 +0000, bachmeier via Digitalmars-d wrote:
[=E2=80=A6]

 The reality is that many programmers use IDEs, so any language=20
 that doesn't have them is losing out. It's my impression, though,=20
 that this community has settled on VS and VS Code as the IDE of=20
 choice. Monetary resources should continue to go into those=20
 efforts so that we can offer at least one good IDE. (Disclaimer:=20
 I no longer use IDEs, so my impression might be wrong.)


I am not convinced the position "If you want an IDE for D programming you m=
ust
use VSCode" is a tenable position in the long run.=20

I set up the Micrsoft Debian repository for VSCode and installed it and you
get then to have to decide which of three or four different D extensions to
install. Which is the officially supported one or is it a question of "ther=
e
are multiple extensions to choose from which you choose is your problem".

Then there is trying to find out out how to use VSCode.

Given I know how to use CLion, and there is the beginnings of what could be=
 an
excellent plugin, I would love for it to get some resource to support the
volunteers.

Supporting multiple IDEs is, like supporting multiple editors (Emacs, Vi,
VIM), a good idea. Having multiple extensions/plugins per IDE/editor is not=
 a
good position for a programming language to be in.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk
Oct 17 2019
next sibling parent Gregor =?UTF-8?B?TcO8Y2ts?= <gregormueckl gmx.de> writes:
On Thursday, 17 October 2019 at 07:25:43 UTC, Russel Winder wrote:

 I am not convinced the position "If you want an IDE for D 
 programming you must use VSCode" is a tenable position in the 
 long run.

 I set up the Micrsoft Debian repository for VSCode and 
 installed it and you get then to have to decide which of three 
 or four different D extensions to install. Which is the 
 officially supported one or is it a question of "there are 
 multiple extensions to choose from which you choose is your 
 problem".


The plugin ecosystem for VSCode is a mess of competing plugins 
left and right. Everything in the editor (I don't want to call it 
an IDE) is a plugin and there are at least two or three competing 
plugins for every used case. This includes language support for a 
lot of programming languages. The UI for installing plugins does 
its best to confuse and makes search results look quite 
non-distinguishable. It's very much like the plugin trap that 
Eclipse fell into, only worse.


 Then there is trying to find out out how to use VSCode.

 Given I know how to use CLion, [...]


There is your problem ;). VSCode reuses a lot of conventions from 
Visual Studio. If you are familiar with VS, VSCode will feel very 
similar. However, the JetBrains family of IDEs have a completely 
different set of conventions, that you seem to be used to. So it 
seems only natural that you're strugging to get into VSCode.


 Supporting multiple IDEs is, like supporting multiple editors 
 (Emacs, Vi, VIM), a good idea. Having multiple 
 extensions/plugins per IDE/editor is not a good position for a 
 programming language to be in.


At least with VSCode, this is the default and not something to be 
especially alarmed by. Other IDEs have less of a wild west 
mentality when it comes to plugins. I'd be more worried if we get 
competing free plugins for Visual Studio, Eclipse or 
IntelliJ/Clion. But I don't see any sign of that yet.

Would there be a market for a commercial IDE/plugin for D? I'm 
not sure that the community is large enough yet.
Oct 17 2019
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 17 October 2019 at 07:25:43 UTC, Russel Winder wrote:

 I set up the Micrsoft Debian repository for VSCode and 
 installed it and you get then to have to decide which of three 
 or four different D extensions to install. Which is the 
 officially supported one or is it a question of "there are 
 multiple extensions to choose from which you choose is your 
 problem".


The D front page lacks a big "Get Started" button to a tutorial 
for setting up the development environment. So that problem is 
easy to fix.

Other languages also have multiple plugins, but the social 
ranking tends to favour just one with a very very large margin to 
the next contender. So not really a VSCode issue.



 Then there is trying to find out out how to use VSCode.


I view VSCode as an editor and not an IDE, but when trying out 
something new, I usually try VSCode first because plugins for 
VSCode tend to be plug and play for tools that have reached 
critical mass.

I'd be very reluctant to install an IDE just to try out a new 
tool/language. I might if it is developed by the same 
(commercial) team developing the tool/language.
Oct 17 2019
prev sibling next sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Wednesday, 16 October 2019 at 12:01:09 UTC, Russel Winder 
wrote:

 On Wed, 2019-10-16 at 11:14 +0000, Atila Neves via 
 Digitalmars-d wrote: […]

 What tooling what you like to see developed that doesn't exist 
 now?


 A D plugin to CLion as good as the Rust plugin.


I'm not sure how many D users currently use CLion, would like to 
or willing to pay for it even if such a plugin existed.

I also don't know how different that is/would be from people 
currently using VisualD.


 I keep reading online that Go has great tooling, but having 
 used it I don't know what people mean when they say that. 
 Likewise, I read that people want D to have great tooling but 
 I also don't know what they mean then either.


 There is one and only one acceptable formatting of all Go code. 
 The formatters enforce this. Fortunately I quite like the Go 
 code style, unlike the Phobos D style which I find hideous – 
 hence me contributing nothing.


Is that it, though? go fmt? *That's* the "tooling"?


 GoLand is very good.


And yet, as far as I can remember or am aware of, Go managed to 
get very popular despite not having an officially blessed IDE 
from the get-go. Correct me if I'm wrong, but the way I remember 
it is the users came first, then IDE solutions showed up to cater 
to the new clientele.


 Tooling is all about the UI people use to develop code (obvious 
 but it seems to need saying). Emacs and Vi are all very well 
 but they are very 1980s whatever people might do with them in 
 2010s.


I disagree. Emacs in 2019 is vastly different from what it was in 
the 90s, never mind the 80s. I don't think I miss anything from 
an IDE while using Emacs to write D except for refactoring 
support. Anything I'd personally care about, anyway.


 The 2000s brought us IDEs


We had IDEs before that. I learned C by typing it into Borland's 
IDE and only transitioned to gcc via DJGPP, which emulated 
Borland's TUI.


 The 2000s brought us IDEs, originally not very good but now the 
 obvious choice for all software development.


Obvious for some. Eclipse infuriated me so much I went back to 
Emacs and I haven't looked back since.

People's preferences differ, however, and I'm trying to 
understand what it is that doesn't work for them with the options 
they have right now.


 Sadly the D plugin to CLion is really not good enough for 
 production use, not from lack of volunteers trying to do stuff, 
 but because volunteers can only start stuff like this. After a 
 while it needs a full-time team. The Rust plugin got taken on 
 by JetBrains. I really cannot see JetBrains taking on the D 
 plugin, so that is not a route to resourcing a quality UI for 
 development.


I assume JetBrains took over the Rust plugin because it'd make 
them money. I'm not sure we could say the same thing.


 AFAIK nearly everybody uses dub. What else would you like to 
 see in this area?


 Something much less like Dub and a lot more like Cargo.


This is another thing I read a lot that I'm not sure what it 
means. I'm aware of dub's faults, but if we eliminated them, what 
would make cargo better? I've used cargo and still don't know. 
Could you please elaborate on what you like about cargo that 
you'd like to see in dub?
Oct 16 2019
next sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Wed, 2019-10-16 at 14:53 +0000, Atila Neves via Digitalmars-d wrote:
[=E2=80=A6]

=20
 I'm not sure how many D users currently use CLion, would like to=20
 or willing to pay for it even if such a plugin existed.


Just at the moment, I'd probably say: none. The D plugin is not at a stage
where it is usable to do debugging.

Free CLion licences can be obtained from JetBrains for people working on FO=
SS
projects. IDEA and PyCharm have free and pay for versions, CLion and GoLand
allow for free licences for the pay for edition. As for other JetBrains
products, I have no idea, these are the four I use.


 I also don't know how different that is/would be from people=20
 currently using VisualD.


It would be a plugin for CLion instead of for Visual Studio.

As far as I am aware Visual Studio is not available on Linux.
=20

 Is that it, though? go fmt? *That's* the "tooling"?
=20


Clearly not, it is just one of the tools. Consider someone saying "dfmt is =
the
totality of the D tooling".


 And yet, as far as I can remember or am aware of, Go managed to=20
 get very popular despite not having an officially blessed IDE=20
 from the get-go. Correct me if I'm wrong, but the way I remember=20
 it is the users came first, then IDE solutions showed up to cater=20
 to the new clientele.


This is true, but the fashion for Go is not a simple piece of history to
unravel. And remember large numbers of people considered Emacs, VIM, Atom,
etc. completely and totally inadequate for the task of writing lots of Go
code. Some started writing a plugin for IntelliJ IDEA, and when JetBrains s=
aw
an income stream appearing they took it over and created GoLand.


 I disagree. Emacs in 2019 is vastly different from what it was in=20
 the 90s, never mind the 80s. I don't think I miss anything from=20
 an IDE while using Emacs to write D except for refactoring=20
 support. Anything I'd personally care about, anyway.


Possibly but many still consider Emacs and VIM to be inadequate to the task=
 of
being an IDE. Just because you are happy using it and it alone doesn't
necessarily apply to the programmers we want to get using D. VSCode, CLion,
and their ilk are what a lot of people expect to be able to use as IDEs.=
=20

(I emphasise CLion here over IntelliJ IDEA because CLion is the JetBrains I=
DE
that supports using gdb and lldb.)
=20

 We had IDEs before that. I learned C by typing it into Borland's=20
 IDE and only transitioned to gcc via DJGPP, which emulated=20
 Borland's TUI.


Borland Delphi is arguably the first IDE to have taken off big time. and ye=
t
it wasn't till the 2000 that we got Eclipse, NetBeans, and then later still
IntelliJ IDEA.

And of course there were C (and sort of C++) environments for development a=
nd
ICE of embedded system software. But they were always very expensive.


 Obvious for some. Eclipse infuriated me so much I went back to=20
 Emacs and I haven't looked back since.


And that is fine; personal choice is important in these things. You chose t=
o
return to The One True Editor=E2=84=A2 (and kitchen sink) as your "IDE". Bu=
t you must
recognise there are many for whom "no IDE means no using the language". If
VSCode and one of four of five plugins is the only offering for a D IDE the=
n
opportunity to collect more users is being missed.

The D plugin to IntelliJ IDEA, but more realistically CLion =E2=80=93 Rust =
started and
is still usable in IntelliJ IDEA but added CLion to get debugging =E2=80=93=
 is a lot
of the way there, but not sufficient to be usable. The volunteers working o=
n
this try to do a great job, but they are volunteers. I keep trying to sugge=
st
to JetBrains they should take this plugin on board as an official one, but
unlike Rust and Go, they see no future income stream from any D investment.


 People's preferences differ, however, and I'm trying to=20
 understand what it is that doesn't work for them with the options=20
 they have right now.


Restricting people to Emacs and VSCode is to advertise that "this is what w=
e
use, if you do not like it, go away". D support has gone beyond this, there=
 is
the beginnings of what could be an excellent CLion plugin. If D is to appea=
l
to C, C++, and Rust programmers who use CLion (and there are a great number=
 of
them), then there needs to be a working plugin. This isn't going to happen
based on volunteers only. Which seems to indicate it isn't going to happen.
Which effectively means the D community is turning it's back on a whole rea=
dy-
made audience of potential users.


 I assume JetBrains took over the Rust plugin because it'd make=20
 them money. I'm not sure we could say the same thing.


JetBrains only do things for income stream reasons these days, the evangeli=
sm
of the early 2000s is a thing of the past. Except they readily give free ID=
E
licences to anyone provably working on FOSS projects.

If the D community is of the view that Go and Rust can make IDE vendors mon=
ey,
but D will never be able to, then D will remain a small, relatively unused
programming language. If being niche and relatively unused is what the D
community want then fine, but stop all the bluster about appealing to C, C+=
+,
Go, Rust, and Python developers.=20


 This is another thing I read a lot that I'm not sure what it=20
 means. I'm aware of dub's faults, but if we eliminated them, what=20
 would make cargo better? I've used cargo and still don't know.=20
 Could you please elaborate on what you like about cargo that=20
 you'd like to see in dub?


Go and Rust emphasised using Git, Mercurial, and Breezy repositories as
packages from the outset. Go chose not to add a central repository, Rust ch=
ose
to add one. Rust's choice was the correct one for supporting developers. In
hindsight, Go has had problems with packages from the outset based on the
initial workspace model. Slowly over the decade Go is finding ways forward.
Rust got it right from the beginning, once they had stripped down the stand=
ard
library and emphasised use of the central repository =E2=80=93 if only Phob=
os could be
stripped right back to the absolute necessary and everything else provided =
via
the central repository. Obviously not all is good in Rust-land, just as wit=
h
Python and PyPI, the central repository is not curated, and this leads to
horrible messes. Ceylon got this more right, but it is a language few have
heard of and even fewer use.

Dub does not allow for use of Git, Mercurial, or Breezy repositories only t=
he
uncurated (and therefore potentially problematic) central repository. OK so
you can do Git checkouts as a separate activity and use local filestore
references, but this is not feasible for packages in the central repository=
.

Dub builds packages to a location outside the project being worked on. Carg=
o
pulls sources to such a central non-project place and then compiles into a
project specific location. Dub tries to store all compiled version out of
project in the same area as the sources. Does this matter? Isn't Dub making
things easier to share? Sort of, sort of, and no. Dub stores all compilatio=
ns,
but hides them and presents only the last compilation easily. This makes
things hard to work with for non-Dub tooling. Cargo makes it a lot easier, =
at
the expense of lack of sharing but always compiling everything into the
project area.

Cargo uses TOML, Dub uses SDL (or if you are masochistic JSON). 'nuff said.
QED.

Dub seems to have become the de facto, and indeed de jure, standard for D
build, and yet somehow Cargo is just assumed by all Rust programmers wherea=
s
Dub is a source of contention and ill-will in the D community.

Dub's biggest problem is that there are many in the D community who will no=
t
use it =E2=80=93 and they are vocal about it. The solution is not censorshi=
p, the
solution is for Dub to evolve very rapidly so that these vocal people have =
the
rug pulled from under them, i.e. their complaints become invalid.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk
Oct 17 2019
parent reply Atila Neves <atila.neves gmail.com> writes:
On Thursday, 17 October 2019 at 08:26:50 UTC, Russel Winder wrote:

 On Wed, 2019-10-16 at 14:53 +0000, Atila Neves via 
 Digitalmars-d wrote: […]

 
 This is another thing I read a lot that I'm not sure what it 
 means. I'm aware of dub's faults, but if we eliminated them, 
 what would make cargo better? I've used cargo and still don't 
 know. Could you please elaborate on what you like about cargo 
 that you'd like to see in dub?


 Go and Rust emphasised using Git, Mercurial, and Breezy 
 repositories as packages from the outset.


<snip>

As far as I can understand then, in your opinion cargo is better 
than dub because:

* It can use direct links to git repositories instead of 
mandating the owners of those repositories explicitly register 
them (that's all code.dlang.org does, associate an email address 
and package name with, more often than not, a git repo on github).
* TOML vs SDL or JSON
* The community rallies behind it
* Details of where compilation artifacts are on the filesystem

Is that an accurate summary?
Oct 17 2019
next sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Thu, 2019-10-17 at 14:14 +0000, Atila Neves via Digitalmars-d wrote:
[=E2=80=A6]

 As far as I can understand then, in your opinion cargo is better=20
 than dub because:
=20
 * It can use direct links to git repositories instead of=20
 mandating the owners of those repositories explicitly register=20
 them (that's all code.dlang.org does, associate an email address=20
 and package name with, more often than not, a git repo on github).
 * TOML vs SDL or JSON
 * The community rallies behind it
 * Details of where compilation artifacts are on the filesystem
=20
 Is that an accurate summary?


It is a good summary of the points so far, certainly =E2=80=93 assuming I h=
ave
understood the point about Dub and Git, Mercurial, and Breezy repositories.
The point about where compilation artefacts are is complicated and definite=
ly
not black and white =E2=80=93 minor changes to the way Dub handles things m=
ight make
it better than what Cargo does, especially for non-Dub tooling.

It is worth noting that it seems impossible to specify the application or
library version number in the dub.sdl file. It seems that Dub assumes
compilation in a Git repository, which would be a problem for source
distribution tarballs or zip files.

=46rom what I can see both Cargo and Dub fail on updating generated source
files. An example: I generate a D module for Fontconfig library using DStep=
,
but it seems SCons is the only tool of Dub, Cargo, Meson, etc. that easily
copes with this build precursor. But I may be missing something.

It is worth noting that Dub and Cargo have more similarities than differenc=
es
overall, but this is probably why the differences can generate so much heat
and angst.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk
Oct 17 2019
parent reply Jacob Carlborg <doob me.com> writes:
On 2019-10-17 18:46, Russel Winder wrote:


  From what I can see both Cargo and Dub fail on updating generated source
 files. An example: I generate a D module for Fontconfig library using DStep,
 but it seems SCons is the only tool of Dub, Cargo, Meson, etc. that easily
 copes with this build precursor. But I may be missing something.


Perhaps the `extraDependencyFiles` [1] field can help?

[1] 
https://dlang.org/changelog/2.085.0.html#extraDependencyFiles-attribute-added

-- 
/Jacob Carlborg
Oct 17 2019
parent Russel Winder <russel winder.org.uk> writes:
On Thu, 2019-10-17 at 20:23 +0200, Jacob Carlborg via Digitalmars-d wrote:

 On 2019-10-17 18:46, Russel Winder wrote:
=20

  From what I can see both Cargo and Dub fail on updating generated sour=




ce

 files. An example: I generate a D module for Fontconfig library using
 DStep,
 but it seems SCons is the only tool of Dub, Cargo, Meson, etc. that eas=




ily

 copes with this build precursor. But I may be missing something.


 Perhaps the `extraDependencyFiles` [1] field can help?
=20
 [1]=20
 https://dlang.org/changelog/2.085.0.html#extraDependencyFiles-attribute-a=


dded

Jacob,

Thanks I'll take a look at that.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk
Oct 18 2019
prev sibling parent Russel Winder <russel winder.org.uk> writes:
Atila,

An added extra in the Dub problems section:

When you build both debug and release builds of an application with Dub the=
 .o
files are not separated, only the final executables are. This means that if
you switch from debug to release build or vice versa, you get a full rebuil=
d.=20

An example .dub tree:

.dub
=E2=94=9C=E2=94=80=E2=94=80 build
=E2=94=82   =E2=94=9C=E2=94=80=E2=94=80 application-debug-linux.posix-x86_6=
4-ldc_2087-13DA9DDBDC6371C556B6892CC72563C7
=E2=94=82   =E2=94=82   =E2=94=94=E2=94=80=E2=94=80 gfontbrowser
=E2=94=82   =E2=94=94=E2=94=80=E2=94=80 application-release-linux.posix-x86=
_64-ldc_2087-8483C7A99B20CA1765F516DDE493FB5B
=E2=94=82       =E2=94=94=E2=94=80=E2=94=80 gfontbrowser
=E2=94=94=E2=94=80=E2=94=80 obj
    =E2=94=94=E2=94=80=E2=94=80 gfontbrowser.o

Cargo gets this right by separating debug and release builds completely.


--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk
Oct 17 2019
prev sibling parent reply Chris <wendlec tcd.ie> writes:
On Wednesday, 16 October 2019 at 14:53:48 UTC, Atila Neves wrote:

 On Wednesday, 16 October 2019 at 12:01:09 UTC, Russel Winder 
 wrote:

 On Wed, 2019-10-16 at 11:14 +0000, Atila Neves via 
 Digitalmars-d wrote: […]

 What tooling what you like to see developed that doesn't 
 exist now?


 A D plugin to CLion as good as the Rust plugin.


 I'm not sure how many D users currently use CLion, would like 
 to or willing to pay for it even if such a plugin existed.


I forgot to mention yesterday, it need not be CLion, in fact I'd 
strongly advise against an IDE you have to pay for. No beginner / 
person interested in D will pay for an IDE just to test D - and 
without an IDE, people will be less willing to test it not to 
mention adopt it.

I'd say IntelliJ IDEA Community Edition would be a good starting 
point or Netbeans. I personally like Netbeans, but strategically 
IntelliJ would be the better choice, because a lot of devs are 
already familiar with it and use it for JVM and Android 
development (Android Studio is basically IntelliJ), which is a 
huge sector. Once you get a proper IntelliJ plugin for D that 
takes advantage of the IDE's superb features that make you more 
productive, it will augment D's prestige, and who knows, maybe 
JetBrains will take over the plugin (but I wouldn't bet on it).

Long story short: IDE integration and a solid package manager are 
the minimum requirements for wider adoption today. Else you will 
forever remain in the "garage" where nerds solder things together.
Oct 17 2019
parent Russel Winder <russel winder.org.uk> writes:
On Thu, 2019-10-17 at 08:38 +0000, Chris via Digitalmars-d wrote:
[=E2=80=A6]

 I forgot to mention yesterday, it need not be CLion, in fact I'd=20
 strongly advise against an IDE you have to pay for. No beginner /=20
 person interested in D will pay for an IDE just to test D - and=20
 without an IDE, people will be less willing to test it not to=20
 mention adopt it.


CLion can be obtained on a free licence for people working on FOSS projects=
.

I agree though that whilst someone might run up the community editions of
IntelliJ IDEA or PyCharm to try them out, that there is no community editio=
n
of CLion and GoLand is a massive barrier to trying them out.


 I'd say IntelliJ IDEA Community Edition would be a good starting=20
 point or Netbeans. I personally like Netbeans, but strategically=20
 IntelliJ would be the better choice, because a lot of devs are=20
 already familiar with it and use it for JVM and Android=20
 development (Android Studio is basically IntelliJ), which is a=20
 huge sector. Once you get a proper IntelliJ plugin for D that=20
 takes advantage of the IDE's superb features that make you more=20
 productive, it will augment D's prestige, and who knows, maybe=20
 JetBrains will take over the plugin (but I wouldn't bet on it).


Like the Rust plugin, the D plugin works with IntelliJ IDEA. However there =
is
no debugging capability for native code languages in IntelliJ IDEA, you hav=
e
to use CLion to get that.

So pushing a D plugin in the community edition of IntelliJ IDEA is a way
forward for trying to capture JetBrains IDE addicts to D. However the D plu=
gin
needs more work to do this.


 Long story short: IDE integration and a solid package manager are=20
 the minimum requirements for wider adoption today. Else you will=20
 forever remain in the "garage" where nerds solder things together.


Agreed.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk
Oct 17 2019
prev sibling next sibling parent berni44 <dlang d-ecke.de> writes:
On Wednesday, 16 October 2019 at 12:01:09 UTC, Russel Winder 
wrote:

 There is one and only one acceptable formatting of all Go code. 
 The formatters enforce this.


That's exactly the reason why I discarded Go when I was looking 
for a new language. I don't want to wear that corset (and several 
others Go imposes on it's programmers).

Just for not being missunderstood: I like to have an unique style 
for Phobos and I'll accept and use what ever it is if it's not 
completely off the marks (the current one is quite close to what 
I normally use, though). But for my own projects I want to be 
able to use my style.
Oct 16 2019
prev sibling next sibling parent Gregor =?UTF-8?B?TcO8Y2ts?= <gregormueckl gmx.de> writes:
On Wednesday, 16 October 2019 at 12:01:09 UTC, Russel Winder 
wrote:

 AFAIK nearly everybody uses dub. What else would you like to 
 see in this area?


 Something much less like Dub and a lot more like Cargo.


And how exactly is dub not close enough to what cargo provides?
Oct 16 2019
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/16/2019 5:01 AM, Russel Winder wrote:

 unlike the Phobos D
 style which I find hideous – hence me contributing nothing.


The style used in Phobos is completely conventional.
Oct 16 2019
parent Russel Winder <russel winder.org.uk> writes:
On Wed, 2019-10-16 at 13:22 -0700, Walter Bright via Digitalmars-d wrote:

 On 10/16/2019 5:01 AM, Russel Winder wrote:

 unlike the Phobos D
 style which I find hideous =E2=80=93 hence me contributing nothing.


=20
 The style used in Phobos is completely conventional.


But there are so many conventions to choose from.=20

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk
Oct 17 2019
prev sibling next sibling parent reply Chris <wendlec tcd.ie> writes:
On Wednesday, 16 October 2019 at 11:14:30 UTC, Atila Neves wrote:

 What tooling what you like to see developed that doesn't exist 
 now?
 I keep reading online that Go has great tooling, but having 
 used it I don't know what people mean when they say that. 
 Likewise, I read that people want D to have great tooling but I 
 also don't know what they mean then either.


 hobby users don't care so much about the tools as they often 
 have their own custom made build tools for D


 AFAIK nearly everybody uses dub. What else would you like to 
 see in this area?


Russel has basically answered the question for me. Plugins for 
IDEs are indispensable, both beginners and experienced 
programmers appreciate the simplicity of IDEs and plugins. A good 
asset would be a plugin for Android Studio that compiles and 
packages your D library automatically.

Apart from that, your vision document is sound because it focuses 
on practical things that programmers would encounter in their 
everyday work life.
Oct 16 2019
parent Russel Winder <russel winder.org.uk> writes:
On Wed, 2019-10-16 at 17:57 +0000, Chris via Digitalmars-d wrote:

 [=E2=80=A6]
 programmers appreciate the simplicity of IDEs and plugins. A good=20
 asset would be a plugin for Android Studio that compiles and=20
 packages your D library automatically.


Unless things have changed again since I stopped doing Android things, Andr=
oid
Studio is a Google built IDE over JetBrain's IntelliJ IDEA core. If the D
plugin to IntelliJ IDEA worked well enough for production use, it should be
usable, with perhaps some extras, in Android Studio.
=20
--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk
Oct 17 2019
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2019-10-16 13:14, Atila Neves wrote:


 What tooling what you like to see developed that doesn't exist now?
 I keep reading online that Go has great tooling, but having used it I 
 don't know what people mean when they say that. Likewise, I read that 
 people want D to have great tooling but I also don't know what they mean 
 then either.


In general the compiler (DMD) needs to be able to be used as a library 
to build various tools on top of it. A great start is to have a full 
working LSP [1] server which uses DMD as a library under the hood. 
Features supported by LSP include:

* Code completion
* Hover (I guess this can show the actual type of an `auto` declaration)
* Signature
* Go to definition
* Find references
* Highlight all references
* Code formatting
* Symbol renaming
* Code folding
* Show documentation for symbol

On top of that there are more advanced refactoring tools:

* Upgrade tool - automatically replace deprecated features and symbols 
with new equivalent

* Modernizer - replaces some language contracts with more modern 
alternatives. Might be combined with the above tool but will not be 
limited to deprecated this. Perhaps replace `in {}` contracts with the 
newer `in()` syntax.

* Code extractor - extract a code snippet to a function/class/struct
* Move a variable to a smaller scope

And other tools:

* Linter

* Compile time lowerer - show how the compiler expands mixins, lowers 
some features to others (i.e. `scope` to `try`/`catch`/`finally`), 
`foreach` to `for` (I assume). This could be implemented as a special 
view in and editor/IDE

* Automatically add attributes to functions

Regarding Go. One huge advantage is that the standard library contains a 
Go frontend [2]. Here is what seems to be the standard Go tools [3]:

* callgraph - a tool for reporting the call graph of a Go program
* eg - The eg command performs example-based refactoring
* goyacc - Goyacc is a version of yacc for Go
* guru - a tool for answering questions about Go source code

* fiximports - The fiximports command fixes import declarations to use 
the canonical import path for packages that have an "import comment" as 
defined by https://golang.org/s/go14customimport

* godex - The godex command prints (dumps) exported information of 
packages or selected package objects

* goimports - Command goimports updates your Go import lines, adding 
missing ones and removing unreferenced ones

* gomvpkg - The gomvpkg command moves go packages, updating import 
declarations

* gopls - The gopls command is an LSP server for Go

* gorename - The gorename command performs precise type-safe renaming of 
identifiers in Go source code

* gotype - The gotype command, like the front-end of a Go compiler, 
parses and type-checks a single Go package

[1] https://microsoft.github.io/language-server-protocol/
[2] https://golang.org/pkg/go/
[3] https://godoc.org/golang.org/x/tools/cmd

-- 
/Jacob Carlborg
Oct 17 2019
parent reply Atila Neves <atila.neves gmail.com> writes:
On Thursday, 17 October 2019 at 18:18:49 UTC, Jacob Carlborg 
wrote:

 On 2019-10-16 13:14, Atila Neves wrote:


 What tooling what you like to see developed that doesn't exist 
 now?
 I keep reading online that Go has great tooling, but having 
 used it I don't know what people mean when they say that. 
 Likewise, I read that people want D to have great tooling but 
 I also don't know what they mean then either.


 In general the compiler (DMD) needs to be able to be used as a 
 library to build various tools on top of it. A great start is 
 to have a full working LSP [1] server which uses DMD as a 
 library under the hood. Features supported by LSP include:


<snip>

I agree and support all of this. I know that dmd as a library 
right now can only be used from dub with `~master`. What is the 
technical reason stopping a version number again?
Oct 18 2019
next sibling parent reply Laurent =?UTF-8?B?VHLDqWd1aWVy?= <laurent.treguier.sink gmail.com> writes:
On Friday, 18 October 2019 at 16:07:43 UTC, Atila Neves wrote:

 On Thursday, 17 October 2019 at 18:18:49 UTC, Jacob Carlborg 
 wrote:

 On 2019-10-16 13:14, Atila Neves wrote:


 What tooling what you like to see developed that doesn't 
 exist now?
 I keep reading online that Go has great tooling, but having 
 used it I don't know what people mean when they say that. 
 Likewise, I read that people want D to have great tooling but 
 I also don't know what they mean then either.


 In general the compiler (DMD) needs to be able to be used as a 
 library to build various tools on top of it. A great start is 
 to have a full working LSP [1] server which uses DMD as a 
 library under the hood. Features supported by LSP include:


 <snip>

 I agree and support all of this. I know that dmd as a library 
 right now can only be used from dub with `~master`. What is the 
 technical reason stopping a version number again?


Isn't it because 2.088.1 isn't semver-compliant ? It would need 
to be tagged at something like 2.88.1 (and thus changing the 
versioning scheme) to be recognized as a correct version by Dub, 
if I'm not mistaken
Oct 18 2019
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Oct 18, 2019 at 04:48:24PM +0000, Laurent Trguier via Digitalmars-d
wrote:
[...]

 Isn't it because 2.088.1 isn't semver-compliant ? It would need to be
 tagged at something like 2.88.1 (and thus changing the versioning
 scheme) to be recognized as a correct version by Dub, if I'm not
 mistaken


This is a side-note, but I find it really ironic that semver started out
as being a general principle of bumping version numbers semantically
rather than arbitrarily, which isn't tied to any specific version
syntax, but nowadays it seems to be become a stick with which to beat
others over for not complying with a specific syntactic implementation
of it.


T

-- 
MSDOS = MicroSoft's Denial Of Service
Oct 18 2019
parent FeepingCreature <feepingcreature gmail.com> writes:
On Friday, 18 October 2019 at 17:23:17 UTC, H. S. Teoh wrote:

 On Fri, Oct 18, 2019 at 04:48:24PM +0000, Laurent Tréguier via 
 Digitalmars-d wrote: [...]

 Isn't it because 2.088.1 isn't semver-compliant ? It would 
 need to be tagged at something like 2.88.1 (and thus changing 
 the versioning scheme) to be recognized as a correct version 
 by Dub, if I'm not mistaken


 This is a side-note, but I find it really ironic that semver 
 started out as being a general principle of bumping version 
 numbers semantically rather than arbitrarily, which isn't tied 
 to any specific version syntax, but nowadays it seems to be 
 become a stick with which to beat others over for not complying 
 with a specific syntactic implementation of it.


 T


DMD would not be semver compliant even if it dropped the extra 0. 
As such, it's probably good that it has it in there, so people 
don't think it's semver just because it has a version number with 
three numbers.

DMD breaks compatibility in minor changes. It's not semver, it's 
more like dmd2-19.04.
Oct 19 2019
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On Friday, 18 October 2019 at 16:07:43 UTC, Atila Neves wrote:


 I agree and support all of this. I know that dmd as a library 
 right now can only be used from dub with `~master`. What is the 
 technical reason stopping a version number again?


Dub needs a Git tag and it needs to follow semantic versioning, 
otherwise Dub will ignore it. The tags for the compiler do not 
follow semantic versioning. There's no technical reason. It's 
just that the compiler releases doesn't follow the semantic 
versioning model. Any release can break anything, basically.

I suggested a workaround until the compiler properly follows the 
semantic versioning model. Which is to add two tags for each new 
release. One that we already add today. The other one would be 
explicitly intended only for the library and would be `0.x.0` and 
we increment `x` by one for each release. Since the `0.x.y` 
versions have special meaning, it's for the initial development. 
Semantic versioning says:

"Anything MAY change at any time. The public API SHOULD NOT be 
considered stable."

Nothing happened with that with that suggestion.

--
/Jacob Carlborg
Oct 21 2019
next sibling parent Laurent =?UTF-8?B?VHLDqWd1aWVy?= <laurent.treguier.sink gmail.com> writes:
On Monday, 21 October 2019 at 09:45:08 UTC, Jacob Carlborg wrote:

 On Friday, 18 October 2019 at 16:07:43 UTC, Atila Neves wrote:


 I agree and support all of this. I know that dmd as a library 
 right now can only be used from dub with `~master`. What is 
 the technical reason stopping a version number again?


 Dub needs a Git tag and it needs to follow semantic versioning, 
 otherwise Dub will ignore it. The tags for the compiler do not 
 follow semantic versioning. There's no technical reason. It's 
 just that the compiler releases doesn't follow the semantic 
 versioning model. Any release can break anything, basically.

 I suggested a workaround until the compiler properly follows 
 the semantic versioning model. Which is to add two tags for 
 each new release. One that we already add today. The other one 
 would be explicitly intended only for the library and would be 
 `0.x.0` and we increment `x` by one for each release. Since the 
 `0.x.y` versions have special meaning, it's for the initial 
 development. Semantic versioning says:

 "Anything MAY change at any time. The public API SHOULD NOT be 
 considered stable."

 Nothing happened with that with that suggestion.

 --
 /Jacob Carlborg


+1 to this, it makes a lot more sense than my idea of simply 
dropping the 0 and having a fake semantic versioning that follows 
the current one.

When I tried using DMD as a library, as a workaround I had to set 
it up as a git submodule, with an explicit path for dub.
Oct 21 2019
prev sibling next sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Mon, 2019-10-21 at 09:45 +0000, Jacob Carlborg via Digitalmars-d wrote:
[=E2=80=A6]

 Dub needs a Git tag and it needs to follow semantic versioning,=20
 otherwise Dub will ignore it. The tags for the compiler do not=20
 follow semantic versioning. There's no technical reason. It's=20
 just that the compiler releases doesn't follow the semantic=20
 versioning model. Any release can break anything, basically.


Should Dub really be mandating use of Git? Mercurial and Breezy still exist
even if GitHub, GitLab, and BitBucket make it seem like Git is the only VCS
option. Subversion is still also a player.


 I suggested a workaround until the compiler properly follows the=20
 semantic versioning model. Which is to add two tags for each new=20
 release. One that we already add today. The other one would be=20
 explicitly intended only for the library and would be `0.x.0` and=20
 we increment `x` by one for each release. Since the `0.x.y`=20
 versions have special meaning, it's for the initial development.=20
 Semantic versioning says:
=20
 "Anything MAY change at any time. The public API SHOULD NOT be=20
 considered stable."


The numbering should at least be 2.x.y for the current DMD.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk
Oct 30 2019
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 30/10/2019 9:33 PM, Russel Winder wrote:

 Should Dub really be mandating use of Git? Mercurial and Breezy still exist
 even if GitHub, GitLab, and BitBucket make it seem like Git is the only VCS
 option. Subversion is still also a player.


In the context of dmd which is on Github and uses Git.

Dub is not tied to a single VCS system nor hosting site. Even if dub 
repository is limited to what it can interact with.
Oct 30 2019
prev sibling parent reply Andre Pany <andre s-e-a-p.de> writes:
On Monday, 21 October 2019 at 09:45:08 UTC, Jacob Carlborg wrote:

 On Friday, 18 October 2019 at 16:07:43 UTC, Atila Neves wrote:


 I agree and support all of this. I know that dmd as a library 
 right now can only be used from dub with `~master`. What is 
 the technical reason stopping a version number again?


 Dub needs a Git tag and it needs to follow semantic versioning, 
 otherwise Dub will ignore it. The tags for the compiler do not 
 follow semantic versioning. There's no technical reason. It's 
 just that the compiler releases doesn't follow the semantic 
 versioning model. Any release can break anything, basically.

 I suggested a workaround until the compiler properly follows 
 the semantic versioning model. Which is to add two tags for 
 each new release. One that we already add today. The other one 
 would be explicitly intended only for the library and would be 
 `0.x.0` and we increment `x` by one for each release. Since the 
 `0.x.y` versions have special meaning, it's for the initial 
 development. Semantic versioning says:

 "Anything MAY change at any time. The public API SHOULD NOT be 
 considered stable."

 Nothing happened with that with that suggestion.

 --
 /Jacob Carlborg


Officially, yes, dub relies on git tags. Unofficially you can set 
the version attribute in dub.json / dub.sdl.

This works quite well in my scenario, where the build system 
needs to know the version of the package and in a later step will 
create itself the git tag.

Kind regards
Andre
Oct 30 2019
parent Atila Neves <atila.neves gmail.com> writes:
On Wednesday, 30 October 2019 at 12:11:12 UTC, Andre Pany wrote:

 On Monday, 21 October 2019 at 09:45:08 UTC, Jacob Carlborg 
 wrote:

 On Friday, 18 October 2019 at 16:07:43 UTC, Atila Neves wrote:


 [...]


 Dub needs a Git tag and it needs to follow semantic 
 versioning, otherwise Dub will ignore it. The tags for the 
 compiler do not follow semantic versioning. There's no 
 technical reason. It's just that the compiler releases doesn't 
 follow the semantic versioning model. Any release can break 
 anything, basically.

 I suggested a workaround until the compiler properly follows 
 the semantic versioning model. Which is to add two tags for 
 each new release. One that we already add today. The other one 
 would be explicitly intended only for the library and would be 
 `0.x.0` and we increment `x` by one for each release. Since 
 the `0.x.y` versions have special meaning, it's for the 
 initial development. Semantic versioning says:

 "Anything MAY change at any time. The public API SHOULD NOT be 
 considered stable."

 Nothing happened with that with that suggestion.

 --
 /Jacob Carlborg


 Officially, yes, dub relies on git tags. Unofficially you can 
 set the version attribute in dub.json / dub.sdl.

 This works quite well in my scenario, where the build system 
 needs to know the version of the package and in a later step 
 will create itself the git tag.

 Kind regards
 Andre


Weirdly enough dub writes out a dub.json (even if the original 
was dub.sdl) in the ~/.dub folder it downloads the package into, 
adding to it a version tag even if not present in the original. 
It never occurred to me that one could add it to get the version, 
but I wonder how the repository deals with that.
Oct 30 2019
prev sibling parent Jacob Carlborg <doob me.com> writes:
On Friday, 18 October 2019 at 16:07:43 UTC, Atila Neves wrote:


 I agree and support all of this. I know that dmd as a library 
 right now can only be used from dub with `~master`. What is the 
 technical reason stopping a version number again?


I'll like to add that I think this is the least of our problems 
with DMD as a library.

--
/Jacob Carlborg
Oct 22 2019
prev sibling next sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Wednesday, 16 October 2019 at 08:13:34 UTC, Chris wrote:

 Good point, and it has been made before by various people on 
 the forum. Átilas vision sounds good and very ambitious. Then 
 again, D also needs a clean up due to failed ambitions in the 
 past, and D needs proper tooling (like in the Java world). So 
 what you need are TWO teams: one that cleans up, improves and 
 extends D, and one that builds the tooling and infrastructure. 
 The latter will be more difficult to find, because from what 
 I've seen on this forum it seems that most professional and 
 hobby users don't care so much about the tools as they often 
 have their own custom made build tools for D and they are much 
 more interested in features and libraries.

 Does anyone have a plan how to get people on board who want to 
 invest time and effort in a sound ecosystem? It seems that D 
 hasn't reached the critical mass of users yet that enough 
 people are frustrated and thus join efforts to make things 
 easier (again cf. Java). How will you guys tackle that?


It's a bit too much irony for me. Your entire involvement with 
this forum is to disparage D and drive people out (I've read 
dozens of your posts). See the language you are using in this 
very post:

- "failed ambitions in the past"

- "D also needs a clean up" < implying it's too dirty to save, 
which is just funny as ProtoObject and copy-ctor makes is 
cleaner, the clean-up is actually in progress,

- "It seems hasn't reached the critical mass of users" < it 
"seems" but somehow it has to be asserted like truth? How do we 
know that?

...this sort of ready-made sentences been going for years and of 
course they have an effect on perception and you are doing it on 
purpose, every day.

One idea to improve D marketing would be not to offer a tribune 
for unsubstantiated criticism.
Oct 16 2019
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 16 October 2019 at 12:23:47 UTC, Guillaume Piolat 
wrote:

 - "D also needs a clean up" < implying it's too dirty to save, 
 which is just funny as ProtoObject and copy-ctor makes is 
 cleaner, the clean-up is actually in progress,


Well, for a new comer that is experienced in other languages 
seemingly arbitrary rough edges sends a very negative signal. 
Especially if it looks as unplanned as the low level 
"introspection" API. People tend to pick up languages in their 
spare time and they want to write beautiful code. You generally 
don't want people that read documentation to think "How on earth 
did they land on this api?" or "Wow, this looks really complex. I 
don't have time for this."

Anyway, Go has some aspects of this too, despite its 
"minimalism". Python is also going downhill, it has in version 
3.8 started to introduce careless design flaws.

Is it possible to clean up a language, well, yes if people who 
implement it doesn't have veto power. If people have spent months 
on implementing something then they have big issues when someone 
wants to erase it. Understandably.

Which is why languages very seldom become prettier, they tend to 
become heavier and heavier and suffer more and more from 
featuritis. There are frankly few examples of the opposite.

Dart 2.0 might be one counter example perhaps, although that 
assumes that you find dynamic languages with no static typing 
unpleasant. So it might be possible... but you know. Not typical.
Oct 16 2019
prev sibling parent reply welkam <wwwelkam gmail.com> writes:
On Wednesday, 16 October 2019 at 08:13:34 UTC, Chris wrote:

 Does anyone have a plan how to get people on board who want to 
 invest time and effort in a sound ecosystem? It seems that D 
 hasn't reached the critical mass of users yet that enough 
 people are frustrated and thus join efforts to make things 
 easier (again cf. Java). How will you guys tackle that?


I come back to forums/mailing list and I cant believe what I 
found. A Chris accurately identified a reason for a problem and 
is not blaming leadership. Its a miracle!

To make sound ecosystem whatever that means you need resources. 
Resources are both people and money. Just thinking about people 
you unnecessary limit options for solving problems. Second 
frustration is the wrong emotion to motivate people to work on D 
or any volunteer organisation. Frustrated people just give up and 
leave. To get people involved you need some of these emotions. 
Optimism, hopefulness, being part of something bigger, helpful to 
others, appreciation, responsibility, ownership.

Now I have been lurking here and on reddit for a few years and 
recently I noticed a lot of new people complaining about 
extremely negative community. In the past people talked about D 
community as being self critical and saw that as positive but 
never negative. Looking at this forum activity it becomes clear 
that you are the biggest reason why newcomers feel that way. I 
would suggest for you to rethink your conduct here so that 
newcomer opinion revert to previously held one namely self 
critical because at this moment your behavior is in opposition to 
your stated goals.
Oct 16 2019
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 16 October 2019 at 23:37:47 UTC, welkam wrote:

 Now I have been lurking here and on reddit for a few years and 
 recently I noticed a lot of new people complaining about


Get real. Most programmers never read forums. I've never read 
forums on the languages I use the most. I stay productive, I 
don't want to talk about how things can be fixed when I can 
easily find ways to move around the issues I face. People pick up 
languages because they have a project (maybe a hobby project). 
They want to be productive.

When hitting a language issue in other languages I do this:
1. search stack overflow and find solution in 10 seconds.
2. read documentation and find solution in 1-30 minutes.
3. search github and find solution in 15-120 minutes
4. find a tutorial and go through it (1+ hours)

If I have to do this:
5. ask on forums and wait for hours/days.
6. submit an issue on github and wait for weeks, months or years.

Then I put that language in the drawer and stick with the other 
options. Most people do.

So if people are active in forums there are many reasons for it, 
of course, but people often starts lurking because they want to 
know if the roadblocks they are experiencing will be fixed, and 
chime in to see if it is possible to do something about it.

But yeah, going ad hominem (like you just did) is never a good 
idea. Fortunately there appears to be much less of it now, but 
I've in the past, time and time again, seen very knowledgable 
people who obviously have a background in CS go silent after 
being hit over the head with a stick.

One thing Rust did right was moderating personal conflicts. As 
you can see from their forums, they have many people with a solid 
formal background that can move their eco system forward. Do 
people gripe about Rust in the Rust forums, yes, but they also 
knew what they were getting into as Rust always was all about the 
most "problematic" feature, the borrow checker. It was always 
front and center.

What has been marketed as D's front-and-center has changed over 
time and therefore people come to it with very different 
expectations. Which makes things more contentious.

Many discussions seem to struggle with this. Is D an alternative 
to C++ or is it in alternative to Python?

It cannot be both, yet it is, and is not, so that is basically an 
inherent struggle that cannot be resolved.

Thus this social dynamic will linger on...
Oct 17 2019
parent reply welkam <wwwelkam gmail.com> writes:
On Thursday, 17 October 2019 at 09:13:17 UTC, Ola Fosheim Grøstad 
wrote:


 Get real. Most programmers never read forums.


When I was in university I was invited to student organization. 
Because they had event recently they had beer kegs that need to 
be emptied before returning to company. So in the first meeting 
that I joined we drunk beer and it was free for me. Needles to 
say after such experiance me and a friend of mine joined that 
student organization. While in that organization I learned how 
important is motivation in organizations. Even if you pay your 
workers its still very important to keep them motivated and in 
volunteer based ones its the only thing you have. Because its so 
important we even traveled to other country for courses on 
motivation. I still remember some of it. You would say something 
like participating in student organisation you will acquire 
useful skills for future jobs and that you can put this on CV. I 
am saying all of this is because you completely missed the point 
I was raising. Its important how new people coming to this 
community are being welcomed/treated and their experiences. The 
story about student organization would have been different if 
there were no free beer and it was awful experience.


 But yeah, going ad hominem (like you just did)


To describe something as ad hominem you need two things:
1. There needs to be a response to a point opponent made. So a 
debate.
2. Its needs to be personal insult.
My post contained neither of them.


 I've in the past, time and time again, seen very knowledgable 
 people who obviously have a background in CS go silent after 
 being hit over the head with a stick.


Yes thats why I raised that issue. Some people have higher 
tolerance to negative emotion and some dont. The same situation 
can be ok or intolerable to different people so its better to be 
on safe side and not creating negative emotions for no good 
reason.


 What has been marketed as D's front-and-center has changed over 
 time and therefore people come to it with very different 
 expectations. Which makes things more contentious.


I would argue that there were no marketing.


 Many discussions seem to struggle with this. Is D an 
 alternative to C++ or is it in alternative to Python?

 It cannot be both, yet it is, and is not, so that is basically 
 an inherent struggle that cannot be resolved.

 Thus this social dynamic will linger on...


I have noticed this thing too. There are ideas that are 
widespread and they hurt D's adoption. There is idea that there 
needs to be different tool for the job or false dichotomy of low 
level and high level languages. Do I need to mention GC?
Oct 17 2019
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 17 October 2019 at 14:19:21 UTC, welkam wrote:

 Its important how new people coming to this community are being 
 welcomed/treated and their experiences.


That is exactly right. People look to forums when then wonder 
where things are going. So when people complain about the issues 
they are facing they should be met with understanding and the 
problems should be acknowledged. In the past that was not really 
the norm, in fact it was quite the opposite, what they complained 
about was outright dismissed and their opinions invalidated and 
ridiculed.

I haven't seen Chris doing any of that in this thread. Doesn't he 
acknowledge issues people feel strongly about?

If people look at a forum and see issues and opinions they share 
dismissed, then they will most likely loose hope of improvement 
and leave. If they see that others share their concerns then they 
gain hope that something can be done. If something is in the 
pipeline, even better!

For instance I lurked for a long time and the only reason I 
started writing in this forums because I felt that Manu was being 
dismissed while his arguments for where D should head were spot 
on. Only recently has D moved in this direction and I have to 
applaud his persistent stance on pushing D in that direction. I 
doubt that would have happend if he was alone... so for something 
to move you need many different voices pushing for that change. 
Then eventually, over time the arguments are picked up by those 
that resist change.

That said, I often look at github to see what a new tool/language 
turns out to be in practice. And quite frankly if you look at 
well-written fully typed generic D code on github, that code 
is... hard on the eyes.  That really matters. People should 
complain about it, because it actually matters. It isn't just 
syntax, this is how the language presents itself to the world.


 2. Its needs to be personal insult.
 My post contained neither of them.


"against the person". Anyway, Chris can handle it... but going 
personal does not build a good culture and does not encourage 
lurkers to participate.



 Yes thats why I raised that issue. Some people have higher 
 tolerance to negative emotion and some dont.


Well, but there is company in misery, so actually I'd say the 
opposite. People might stay and deicide to advocate for change if 
they perceive that other have had the same problems as they have. 
If people want something to move then they have to build some 
kind of alliance or exert some force or educate others. That  
sometimes invoke emotions, but it does not have to be personal. 
With no emotions you will probably not get more than tiny 
modifications of status quo.



 I would argue that there were no marketing.


Oh, D1 was marketed quite heavily as an improvement on C++, hit 
Slashdot as a news story when Slashdot was big.



 I have noticed this thing too. There are ideas that are 
 widespread and they hurt D's adoption. There is idea that there 
 needs to be different tool for the job or false dichotomy of 
 low level and high level languages. Do I need to mention GC?


But the dichotomy isn't false... and heavily relying on the GC 
has probably held D back from taking the position Rust is getting 
now...

Both Rust and the C++ committee are addressing user concerns at a 
fast pace now. So it isn't realistic to think that D can keep up 
with those at this point in time.

So at this point D can only try to figure out where it fits in, 
rather than taking over the space of other languages. The time 
window for "taking over" ended a few years ago. I think.
Oct 17 2019
parent reply welkam <wwwelkam gmail.com> writes:
On Thursday, 17 October 2019 at 15:19:32 UTC, Ola Fosheim Grøstad 
wrote:

 So when people complain about the issues they are facing they 
 should be met with understanding and the problems should be 
 acknowledged. In the past that was not really the norm, in fact 
 it was quite the opposite, what they complained about was 
 outright dismissed and their opinions invalidated and ridiculed.


People acknowledge problems. Just look at learn forum, IRC or 
discord. Thats never a problem. What actually happens is that 
some one complains on forums. Then is being told that all the 
people who work have their hands full and if he/she wants that 
problem to be solved either should solve them self or pay some 
one to solve it for them. And thats a bitter pill to swallow and 
some people refuse to accept the reality. Then all the post about 
how people do not acknowledge problems happen. People do not 
realise that everything of substance here was done because some 
one took the time to do it and it was never because some one 
asked on forum. And second some people have such a feeling of 
entitlement of other people time. No you do not have a right to 
tell me how I should spend my free time. People do not react well 
when they are treated almost like slaves by a master.

There is another type of comment we call drive by commenting when 
some usually never seen before post a post that can be boiled 
down to "D is not perfect because you are idiots". Good thing is 
that they usually dont stay for long.



 I haven't seen Chris doing any of that in this thread. Doesn't 
 he acknowledge issues people feel strongly about?


First I and other person recognized that his post here was out of 
character and I had in mind his behavior over period of time. 
Second I was talking about how other people coming here go "why 





 I felt that Manu was being dismissed while his arguments for 
 where D should head were spot on.


Could you elaborate. What Manu usually wants is quick fixes fast 
and that is the wrong way of building a programming language. 
Before any change is committed to the language it should be 
thoroughly studies otherwise you will get a mess.



 "against the person". Anyway, Chris can handle it... but going 
 personal does not build a good culture and does not encourage 
 lurkers to participate.


Thats not even 1% how he treats others. If he behaved the same in 
Rust community he would have been banned long time ago.


 People might stay and deicide to advocate for change if they 
 perceive that other have had the same problems as they have.


This presupposes that the reason they have a problems is because 
some people have different opinion or values. In D's case 99% of 
all problems are due to lack of resources so advocating for 
change will have 0 results. To cure a disease you first need to 
correctly identify a cause.



 But the dichotomy isn't false... and heavily relying on the GC 
 has probably held D back from taking the position Rust is 
 getting now...


If dichotomy isn't false then answer weather D is high or low 
level language? The dichotomy exist for other languages because 
of their design limitations not because of some lows of nature.

All languages that became popular did so because of some big 
backer. It would be mistake to conclude that language X became 
popular because of feature Y so we should also have feature Y and 
we too become popular.


 So it isn't realistic to think that D can keep up with those at 
 this point in time.


D is still on exponential growth curve.
Oct 17 2019
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 17 October 2019 at 17:23:29 UTC, welkam wrote:

 to tell me how I should spend my free time. People do not react 
 well when they are treated almost like slaves by a master.


Sure, but it isn't really about resources. It is about process. 
If you after version 1.0 have one experimental branch and don't 
let features into the stable branch until they have been  
harnessed and used heavily then you avoid many issues. D has 
moved more like an experiment than an engineered artefact.  From 
that there will be more noise...



 time. Second I was talking about how other people coming here 



When people slam the door when they are leaving it is because 
they've hit roadblocks that they think should not have been let 
into any stable branch... most likely.  They expected something 
carefully engineered and felt they walked into something that 
wasn't.



 Could you elaborate. What Manu usually wants is quick fixes 
 fast and that is the wrong way of building a programming 
 language. Before any change is committed to the language it 
 should be thoroughly studies otherwise you will get a mess.


I'm not here to evaluate anyone, but I am totally convinced that 
D would not have started moving in the right direction without 
constant pressure from people like Manu, that's all I have to 
say. If something ought to have happened five years ago then it 
is reasonable to push harder. Maybe it works?

If there is no push, nothing happens in the direction of real 
time programming.  That's been obvious for at least a decade.



 In D's  case 99% of all problems are due to lack of resources so


Not resources. Process... Expanding the feature set... Rather 
than narrowing down the focus.

Like, there is no point in planning for a borrow checker if you 
don't have people with the right know how and have plenty on the 
plate.  It's a great idea, but probably too late.  That's not a 
dismissive statement, that's just realism.

So why was it put on the table?



 If dichotomy isn't false then answer weather D is high or low 
 level language? The dichotomy exist for other languages because 
 of their design limitations not because of some lows of nature.


Low level.  With some high level runtime features.  There is very 
little room for high level optimization in D.


 All languages that became popular did so because of some big 
 backer. It would be mistake to conclude that language X became 
 popular because of feature Y so we should also have feature Y 
 and we too become popular.


As I stated elsewhere in this thread, languages become popular 
because they have a use case where they are superior (even if the 
language isn't). You don't need a big backer (and you don't need 
a great language). But you need some adoption before somebody 
implements something that enables that "superior use case", and 
probably also the right set of features to make it easy to do so.

So the only way you can plan for traction is to understand what 
use case you want to be superior for and design the language with 
that in mind.

Otherwise popularity becomes a random event (someone accidentally 
chose language X to build a great framework).



 D is still on exponential growth curve.


I wouldn't know, and I don't think it matters all that much.  I 
was talking about the language/compiler.

The C++ people have realized that Rust is coming to take a slice 
of their cake and they appear to be pushing new features out the 
door at a high pace.  I don't think that would have happened 
without Rust.  I think it was a wakeup call.
Oct 17 2019
next sibling parent reply welkam <wwwelkam gmail.com> writes:
On Thursday, 17 October 2019 at 19:00:47 UTC, Ola Fosheim Grøstad 
wrote:

 In D's  case 99% of all problems are due to lack of resources 
 so


 Not resources. Process... Expanding the feature set... Rather 
 than narrowing down the focus.

 Like, there is no point in planning for a borrow checker if you 
 don't have people with the right know how and have plenty on 
 the plate.  It's a great idea, but probably too late.  That's 
 not a dismissive statement, that's just realism.

 So why was it put on the table?


First its enhancement not a problem. But maybe its distinction 
without a difference. D already have memory safety guaranties but 
it relies on GC to do that. What Walter wants is for simple
void* p = malloc();
free(p);
to be marked  safe. Just by looking at it its clear that is safe 
but current compiler cant prove it. So he wants to implement 
additional checks based on control flow graph. This is not like 
Rust's borrow checker. Its much simpler and one motivated man can 
do it.


 As I stated elsewhere in this thread, languages become popular 
 because they have a use case where they are superior (even if 
 the language isn't)


Go, Rust, Swift, Kotlin all new languages had backer. I wish that 
language adoption was as you said but real word data contradicts 
your view. The only language might fit your example is Ruby but 
it wasn't that popular.

I feel like whenever I say AEOA you read that and the go to talk 
about ÆØÅ. Close but not what I was talking. I really dont enjoy 
that kind of conversation.

Oftopic: https://youtu.be/f488uJAQgmw
Oct 17 2019
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 17 October 2019 at 19:49:55 UTC, welkam wrote:

 safe but current compiler cant prove it. So he wants to 
 implement additional checks based on control flow graph. This 
 is not like Rust's borrow checker. Its much simpler and one 
 motivated man can do it.


Ok, I missed that clarification.
So, it will only work sometimes.
So, you cannot use it reliably in generic code.

I find that troublesome. Maybe it isn't, but it sounds very 
problematic.


 contradicts your view. The only language might fit your example 
 is Ruby but it wasn't that popular.


Perl, Python, Php, and many smaller languages have built a strong 
following without corporate backing so, no.

What is true is that corporates often provides the superior use 
case for a language, but that is a different issue.



 I feel like whenever I say AEOA you read that and the go to 
 talk about ÆØÅ. Close but not what I was talking.


I don't see your point. I feel that you assume too much.
Oct 17 2019
parent reply bachmeier <no spam.net> writes:
On Thursday, 17 October 2019 at 20:01:37 UTC, Ola Fosheim Grøstad 
wrote:


 Perl, Python, Php, and many smaller languages have built a 
 strong following without corporate backing so, no.


If you exclude a small company named Google, the part about 
Python is kind of correct. From the very beginning, when they 
were indeed small, it's my understand that Python has been an 
approved language. They used it so much that they eventually 
hired Guido.

You can debate about Perl and Php's support, but they were 
uniquely-positioned languages as the WWW took off. That was kind 
of a big deal.

These days it's hard to give someone a compelling reason to adopt 
any particular language. There are so many good alternatives no 
matter what you want to do.
Oct 17 2019
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 17 October 2019 at 21:24:27 UTC, bachmeier wrote:

 You can debate about Perl and Php's support, but they were 
 uniquely-positioned languages as the WWW took off. That was 
 kind of a big deal.


Perl was actually big before WWW.
Used for scripting purposes by sys admins.
Lisp was big before WWW.
And more...

But you also had commercial languages by small developers before 
Open Source became the norm, which also are examples of "no 
corporate" languages. Although proprietary. That is difficult 
today, though.



 These days it's hard to give someone a compelling reason to 
 adopt any particular language. There are so many good 
 alternatives no matter what you want to do.


That is true.  But my point is that people do not necessarily 
adopt languages, they adopt frameworks for some specific task 
which imply a language (so an indirection).
Oct 17 2019
prev sibling parent welkam <wwwelkam gmail.com> writes:
On Thursday, 17 October 2019 at 21:24:27 UTC, bachmeier wrote:

 On Thursday, 17 October 2019 at 20:01:37 UTC, Ola Fosheim 
 Grøstad wrote:


 Perl, Python, Php, and many smaller languages have built a 
 strong following without corporate backing so, no.


 If you exclude a small company named Google, the part about 
 Python is kind of correct.


And CERN
Oct 17 2019
prev sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Thursday, 17 October 2019 at 19:49:55 UTC, welkam wrote:

 I really dont enjoy that kind of conversation.



Hello welkam,

here is a pro tip: just don't engage in a conversation with Ola 
and Chris.

Here is some helpful context: 
https://www.mail-archive.com/digitalmars-d puremagic.com/msg209018.html

Chris is of the same ilk and they will defend each other when 
pointed out for what they are.

They are also _good_ debaters, having devoted their life to being 
right on Internet forums of languages they don't use, and don't 
like.

Who does that kind of thing? Not people with a lot of 
achievements. Your annoying conversation is joy for them. When 
they are dead, noone will remember anything they have created or 
done.
Oct 17 2019
next sibling parent Greatsam4sure <greatsam4sure yahoo.com> writes:
On Thursday, 17 October 2019 at 20:11:58 UTC, Guillaume Piolat 
wrote:

 On Thursday, 17 October 2019 at 19:49:55 UTC, welkam wrote:

 I really dont enjoy that kind of conversation.



 Hello welkam,

 here is a pro tip: just don't engage in a conversation with Ola 
 and Chris.

 Here is some helpful context: 
 https://www.mail-archive.com/digitalmars-d puremagic.com/msg209018.html

 Chris is of the same ilk and they will defend each other when 
 pointed out for what they are.

 They are also _good_ debaters, having devoted their life to 
 being right on Internet forums of languages they don't use, and 
 don't like.

 Who does that kind of thing? Not people with a lot of 
 achievements. Your annoying conversation is joy for them. When 
 they are dead, noone will remember anything they have created 
 or done.


We trust a turning around for all in this forum. There is always 
a space for a change.
we are advocate a new dawn for D and all in this forum
Oct 17 2019
prev sibling next sibling parent reply welkam <wwwelkam gmail.com> writes:
On Thursday, 17 October 2019 at 20:11:58 UTC, Guillaume Piolat 
wrote:

 On Thursday, 17 October 2019 at 19:49:55 UTC, welkam wrote:

 I really dont enjoy that kind of conversation.



 Hello welkam,

 here is a pro tip: just don't engage in a conversation with Ola 
 and Chris.

 Here is some helpful context: 
 https://www.mail-archive.com/digitalmars-d puremagic.com/msg209018.html

 Chris is of the same ilk and they will defend each other when 
 pointed out for what they are.

 They are also _good_ debaters, having devoted their life to 
 being right on Internet forums of languages they don't use, and 
 don't like.

 Who does that kind of thing? Not people with a lot of 
 achievements. Your annoying conversation is joy for them. When 
 they are dead, noone will remember anything they have created 
 or done.


That message you linked reads like it was written by me.
Oct 17 2019
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 17 October 2019 at 20:51:35 UTC, welkam wrote:

 That message you linked reads like it was written by me.


You both assume too much then...

Ad hominem, slander and hostility does not build good 
communities.  You get what you seed.  That's the source of the 
negativity you complained about. Right there... Right here.
Oct 17 2019
parent reply Guillaume Piolat <first.last gmail.com> writes:
On Thursday, 17 October 2019 at 21:25:04 UTC, Ola Fosheim Grøstad 
wrote:

 On Thursday, 17 October 2019 at 20:51:35 UTC, welkam wrote:

 That message you linked reads like it was written by me.


 You both assume too much then...

 Ad hominem, slander and hostility does not build good 
 communities.  You get what you seed.  That's the source of the 
 negativity you complained about. Right there... Right here.


From: 
https://scottbarrykaufman.com/wp-content/uploads/2014/02/trolls-just-want-to-have-fun.pdf

Let me quote the conclusions:
   "it might be said that online trolls are prototypical everyday 
sadist"

And there is a non-zero amount of sadists (probably ill-defined 
but research shown it's a psychological trait). Some of them will 
engage in trolling behaviour.

I hope the reader now see it's hopeless to have no moderation and 
hope for the best, since goodwill alone doesn't prevent some 
people from enjoying distress in others.

Good communities are built on the Internet with exclusion 
(moderation, internet point, banning, etc...)

As evidenced by Reddit, HN, StackOverflow, lobste.rs having all 
of that and maintaining a good level of civility. Not banning 
people is the surest way to have an unwelcoming community.
Oct 17 2019
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Oct 17, 2019 at 09:58:14PM +0000, Guillaume Piolat via Digitalmars-d
wrote:
[...]

 From: https://scottbarrykaufman.com/wp-content/uploads/2014/02/trolls-just-want-to-have-fun.pdf


[...]

 I hope the reader now see it's hopeless to have no moderation and hope
 for the best, since goodwill alone doesn't prevent some people from
 enjoying distress in others.


[...]

Wow, it took >15 years for "official" research to recognize this fact?

Since around Y2K I've recognized the futility of engaging in online
debates, especially with certain personalities that exhibit certain
traits. They have be variously described as trolls, sadists, -- I call
them griefers.  Basically, their whole goal is to cause grief for the
sake of causing grief: they actually have no personal investment in
whatever topics they engage in heated debates about; their only goal is
to keep bringing up controversial issues to provoke other participants'
reactions and derail or distract from any productive discussions that
might be taking place. They will often latch on to what, on the surface,
appears to be very valid and legitimate issues, and use that to rouse
the rabble.  Some of them are very good at it, and it's not so easy to
tell their real motives at first. But eventually, their real motives
will become clear.

Once that happens, the only winning move is to not play, because the
more you engage them, the more they're emboldened to keep doing what
they're doing, to the detriment of everyone and everything else.

Most communities will have at least 1 person that continually falls for
their devices (cf: https://xkcd.com/386/), thus perpetuating their
goals. But you know what's funny?  On the (very) rare occasions that all
participants are able to refrain from engaging with them, these
sociopathic types will pack up and leave, instantly "forgetting"
overnight the oh-so-important issues that they were apparently
oh-so-very-passionate about, thereby revealing that in reality, said
issues were nothing more than convenient bait with which to arm their
hooks.

After encountering more than a few of these personalities, the truth
will gradually dawn on you of that great old adage: "don't feed the
trolls". The more you play this game, the more you will lose.



 Good communities are built on the Internet with exclusion (moderation,
 internet point, banning, etc...)
 
 As evidenced by Reddit, HN, StackOverflow, lobste.rs having all of
 that and maintaining a good level of civility. Not banning people is
 the surest way to have an unwelcoming community.


Ah, I must be old and jaded then. I have much less confidence in banning
and moderation that you apparently have. The problem with moderation is
that the griefers will adapt and find ever new ways of being compliant
to the letter but violating the spirit, gaming the system to their own
ends. Consequently, the finger on the trigger will inevitably become
heavier and heavier, and ultimately it will result in a sterile (and
puerile) community that can no longer generate fresh new ideas, because
anything that goes against the accepted norm will be knee-jerk rejected
as "trollish".

You can't win on the internet. Either you have an open community, where
griefer types will inevitably show up, or you have a closed community
that grows stale and old (and practically dead as far as innovation is
concerned). There is no third choice.


T

-- 
Дерево держится корнями, а человек -
друзьями.
Oct 17 2019
prev sibling next sibling parent IGotD- <nise nise.com> writes:
On Thursday, 17 October 2019 at 21:58:14 UTC, Guillaume Piolat 
wrote:

 I hope the reader now see it's hopeless to have no moderation 
 and hope for the best, since goodwill alone doesn't prevent 
 some people from enjoying distress in others.

 Good communities are built on the Internet with exclusion 
 (moderation, internet point, banning, etc...)


This forum (which is technically not forum, more a mailing list) 
have quite little problems with trolls. Few people even find this 
place.

The problem this forum is that the discussion often derails into 
off topic (which even this post is). Many threads seems to derail 
into some kind of despair and whining over the state of D. This 
is of course not very productive and might be a reason that D 
development is going slowly. People who are doing are not trolls 
but perhaps more dejected people. You are allowed to be 
dissatisfied and dejected but threads must stay on topic.

BTW I would be happy if you would upgrade the D forum to 
something more modern. With a modern forum you will also get 
better functionality for moderating the forum.
Oct 17 2019
prev sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Friday, 18 October 2019 at 11:09:42 UTC, Chris wrote:

 Again, you are publicly calling for censorship.


Moderation.


 You never have any real points but you are engaging in a smear 
 campaign against me and other critics. That's the typical 
 behavior of an ideologue.


But you are the objective observer I guess.

Here is the thing: I think I have a better handle on actual D 
shortcomings than you.
Read the whole thing: https://p0nce.github.io/d-idioms/
Pretty critical at times.

I used to be in detailed trivia about D. Addiction for sure. I 
complained a lot about the language.

But something else I realized is that D cannot really fill three 
books of "Effective D", let alone one.

Things are actually quite good. Even compared to the "better" 
competition you mention all the time.

I look at reality: my D products cause me zero problems, make 
money, are as-fast-as-native can be, easy to maintain, and build 
faster than in similar languages (with the exception of Nim whose 
creator actually read the forum there, and is a competent 
alternative).
Oct 18 2019
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 18 October 2019 at 12:05:41 UTC, Chris wrote:

 and once Adam said that he uses a very conservative style of D 
 so he never has problems with dmd updates.


I have been kinda avoiding this thread as I don't wanna get 
burned but I wanna tell a funny little story here.

My libraries have a pretty good compatibility record. Yes, 
sometimes I push half-baked stuff and people get warnings or 
whatever, but I tend to fix those fairly quickly so 99% of the 
time you grab my code it is probably going to work on old and new 
compilers alike.

Many of my modules work with D versions going back two years or 
more. I actively test on gcc releases now too, and (in)famously 
avoid third-party library entanglements... again, for the most 
part.


But actually a lot of the stuff from the last year I like a lot. 
And cgi.d now uses static foreach in some optional sections. 
Pretty cool stuff.

The problem is it now doesn't work on old gdc :( And since 
version() requires the innards to parse, I can't even version it 
out. I might mix it in as a string (yikes!) just to maintain that 
cross-compiler compatibility, as often I'd just stick to the old 
feature but this time it is legitimately really useful and not 
easily replaced by an older way.

oh well though.
Oct 18 2019
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Oct 18, 2019 at 12:47:51PM +0000, Adam D. Ruppe via Digitalmars-d wrote:
[...]

 My libraries have a pretty good compatibility record. Yes, sometimes I
 push half-baked stuff and people get warnings or whatever, but I tend
 to fix those fairly quickly so 99% of the time you grab my code it is
 probably going to work on old and new compilers alike.
 
 Many of my modules work with D versions going back two years or more.
 I actively test on gcc releases now too, and (in)famously avoid
 third-party library entanglements... again, for the most part.


I actually *really* like your philosophy of avoiding 3rd party library
entanglements.  Using 3rd party libraries seems to be the bandwagon
these days, but it seems people are turning a blind eye to its
downsides.  Being able to just copy the darned source file into my
source tree and just compile away is so refreshingly simple and
effective, as opposed to needing to install some NP-complete dependency
solver, waiting 5 seconds (often more) for said solver to solve that
damned dependency graph every time I build, and needing network access
just to be able to get a pristine copy of the sources, and when the 3rd
party server goes down for whatever reason, you're stuck, ad nauseaum.

I don't like libraries that comes with all sorts of dependency strings
attached. Just give me the darned file, plop it in, and compile away --
no strings attached, no fuss, no muss, no requirements of over-complex,
over-engineered dependency graphs -- *that's* the best kind of library.


T

-- 
What do you get if you drop a piano down a mineshaft? A flat minor.
Oct 18 2019
prev sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 18 October 2019 at 12:47:51 UTC, Adam D. Ruppe wrote:

 But actually a lot of the stuff from the last year I like a 
 lot. And cgi.d now uses static foreach in some optional 
 sections. Pretty cool stuff.


I actually just now took the last couple hours in guaranteeing* 
this compatibility: cgi.d uses mixin to work around the grammar 
change, but it now has core functions working on gdc as well! 
With a few more tweaks, 49 of my library modules are now 
confirmed to work on the newest dmd as well as the gdc that came 
out of my Slackware package manager.

gdc in upstream gcc release is based on frontend 2.076.0 (Sep 1, 
2017). This means my libs have two years of compatibility :)

And fun fact, while I was in there, I  tested my old D1 code. It 
did need a few trivial tweaks - changing array from C-style to 
D-style mostly - but it now works on newest dmd as well as old D1 
compiler equally well. That's about 11 years of compatibility!

ps don't use those old d1 files i maintain them for the lulz not 
for the serious use.


* not actually guaranteed in any legal sense i explicitly 
disclaim all warranties including but not limited to 
merchantability for a particular purpose. USE AT YOUR OWN RISK.

or give me all your money then maybe we can work out a formal 
support agreement. lol
Oct 18 2019
prev sibling parent reply welkam <wwwelkam gmail.com> writes:
On Saturday, 19 October 2019 at 11:21:10 UTC, Chris wrote:

 On Saturday, 19 October 2019 at 10:37:12 UTC, drug wrote:


 I'm sincerely wondered why you can't stop posting here if you 
 gave up using D long time ago? What is the reason that forces 
 you to continue this non-technical correspondence?


 I'm sincerely wondering why the D community avoids doing the 
 obvious and keeps wondering why adoption rates are still low, 
 after 20 years. As I remember it was all about 1. ranges, 2. 
 templates, 3. functional programming and 4. memory safety, 
 nice, but basics were / and are still being neglected. I 
 understand that many users might not care because e.g. they 
 don't use IDEs or don't develop for mobile, but when people 
 keep raising these issues and other new languages immediately 
 work on ARM and IDE plugins, still nobody here sees the big 
 pink elephant in the room. And it's not "scarce" resources, 
 it's that nobody seems to care. If you think about the amount 
 of time people spend discussing a syntactic detail in template 
 declarations and stuff like that, and then people tell me there 
 aren't enough resources, c'mon. The truth is that the community 
 enjoys bikeshedding but ignores the basics. Maybe my 
 conversation is non-technical in the sense that I don't 
 bikeshed about template syntax, but stability, 
 automagicaltooling and support for mobile are still technical 
 issues. If you don't sort those out, D will remain a niche 
 language. It's a nobrainer, really, I don't understand this 
 obstinate resistance to the obvious.



 If you think about the amount of time people spend discussing a 
 syntactic detail in template declarations and stuff like that, 
 and then people tell me there aren't enough resources, c'mon.


Talking != working. If people stopped talking that doesnt mean 
they would start working. Thats a huge mistake to make for some 
one who thinks he is the only reasonable person here.


 when people keep raising these issues and other new languages 
 immediately work on ARM and IDE plugins, still nobody here sees 
 the big pink elephant in the room


Zig - doesnt have proper ARM support
Nim - it got it for free because it translates to C
Crystal - didnt had windows support not to mention arm
Rust - It kind of compiles but no tests are run so its not 
guaranteed to work. RustC and cargo are not supported on ARM.
Go - doesnt work on Android but has linux Arm support.
jai - ???

Before claiming of how other languages immediately work on on ARM 
do some fact checking. Yes Android is big but the only new 
language that has good support for it is Kotlin.

Here are some facts:
1. One of the first D language foundation expenditures were 
paying for Visual studio plugin enhancement. If you didnt know 
Visualstudio is an IDE and it was concluded that enhancing user 
experience was a key thing in making D grow. This directly 
contradicts your view.
2. Every year D foundation gets more money to invest in D. This 
and Ethans money kick started ARM effort. Money is still being 
raised for iOS port by the way. If as you say thing were not done 
because we didnt understood that things were important then tell 
me why we are still raising money? Why money was required to 
kickstart it in the first place?

While mobile development is huge its not the best strategic 
decision to invest huge amounts of resources pursuing that 
market. Let me explain. Firstly it is easier to sell water to a 
thirsty man. There is no indication that mobile people are 
thirsty for a new programming language. Second thing is that you 
would have to compete with Google and Apple at the same time. 
Competing against one is suicide let alone against both. If we 
did as you want D would fail because it would never reach the 
polish that Google or Apple can afford and with nothing to offer 
in other areas D would just die.

But there are other areas where people are thirsty for new 
programming language. They are:
1. Research
2. Game dev
3. Desktop application creation.

Researchers and scientist each day are facing with ever 
increasing data sets and python or R are chocking on those huge 
data sets. The other option researchers have is either C or C++ 
and they dont like programming in them. D as better C allows for 
easy library development which could be easily be used in Python 
or other languages that researches use. DasBetterC allowed 
development for mir glass library that is a cornerstone library 
for any subsequent development in research area. Little 
investment in this are is paying of big time with companies 
sponsoring development for new libraries and tools in D. With 
data frames support coming D is growing stronger in this are. 
Since "critics" never mention this area as growth opportunity 
show how much they really understand.

For game developers its very important to have C++ 
interoperability because there are lots of code already written 
in C++ and you cant just rewrite it. And what do you know there 
is effort in improving interoperability with C++.

On discord there is working group for GUI library.

It seems that people working on D perform const benefit analysis 
before investing and from what I can tell they are way better at 
deciding on what to work or where to best invest money than you.
Oct 19 2019
parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Saturday, 19 October 2019 at 17:22:10 UTC, welkam wrote:

 On Saturday, 19 October 2019 at 11:21:10 UTC, Chris wrote:

 [...]



 [...]


 Talking != working. If people stopped talking that doesnt mean 
 they would start working. Thats a huge mistake to make for some 
 one who thinks he is the only reasonable person here.

 [...]


DeepGlance wrote code for a world leader company in Display 
Projections and Visualization Technologies to be run on ARM in a 
monitor, and we happily did it in D
Oct 19 2019
prev sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Friday, 18 October 2019 at 10:44:39 UTC, Chris wrote:

 Is it so hard to say why D is the best choice for you?


https://p0nce.github.io/d-idioms/#So-D-is-just-C++-with-a-Garbage-Collector?

But it's really:
https://p0nce.github.io/d-idioms/#How-does-D-improve-on-C++17?

that sell me D (the "small" stuff and readability).

It's an excellent combination of power and productivity that 
shines into the programs you do with it, and the user can notice 
it in the end.

Auto-decoding? Never had a single issue with it...
Breaking code? That happens, but rarely enough that I can live 
with it. And it happens less and less.
Oct 18 2019
parent reply Chris <wendlec tcd.ie> writes:
On Friday, 18 October 2019 at 11:07:15 UTC, Guillaume Piolat 
wrote:

 On Friday, 18 October 2019 at 10:44:39 UTC, Chris wrote:

 Is it so hard to say why D is the best choice for you?


 https://p0nce.github.io/d-idioms/#So-D-is-just-C++-with-a-Garbage-Collector?

 But it's really:
 https://p0nce.github.io/d-idioms/#How-does-D-improve-on-C++17?

 that sell me D (the "small" stuff and readability).

 It's an excellent combination of power and productivity that 
 shines into the programs you do with it, and the user can 
 notice it in the end.

 Auto-decoding? Never had a single issue with it...
 Breaking code? That happens, but rarely enough that I can live 
 with it. And it happens less and less.


Point taken, yeah, D has great features, and how do you use it? 
Desktop / server only I suppose. How does it scale? Would you use 
D as other companies use Java and C++. I.e. when it stops being a 
one man show? Honest answer please.
Oct 18 2019
parent reply Guillaume Piolat <first.last gmail.com> writes:
On Friday, 18 October 2019 at 11:15:55 UTC, Chris wrote:

 Point taken, yeah, D has great features, and how do you use it?


All the time, and avoiding recent features.



 Desktop / server only I suppose. How does it scale?


Hence the iOS effort.



 Would you use D as other companies use Java and C++.


I've used C++ in commercial capacity in 3 places. All had massive 
compile time problems, fragmentation, inability to add 
third-party code easily, and were massive debt machines.

I would never, ever start any effort in C++ as it's a sink of 
money compared to D. It's just much more expensive.

For small tools productivity can be 2x less with C++.

I think Java is fine when you don't use native. I don't use it, 
but friends are and it seems competent AND fixes long-time issues 
with C++ such as unsigned.
Oct 18 2019
next sibling parent reply Chris <wendlec tcd.ie> writes:
On Friday, 18 October 2019 at 11:24:38 UTC, Guillaume Piolat 
wrote:

 On Friday, 18 October 2019 at 11:15:55 UTC, Chris wrote:

 Point taken, yeah, D has great features, and how do you use it?


 All the time, and avoiding recent features.


Avoiding recent features? What does that mean? Which features and 
why?


 Desktop / server only I suppose. How does it scale?


 Hence the iOS effort.


I couldn't wait anymore. Something so basic (not simple). That's 
when D comes back to bite you. Sad but true.


 Would you use D as other companies use Java and C++.


 I've used C++ in commercial capacity in 3 places. All had 
 massive compile time problems, fragmentation, inability to add 
 third-party code easily, and were massive debt machines.


I believe that but isn't using D a big risk too? Where will it be 
tomorrow?


 I would never, ever start any effort in C++ as it's a sink of 
 money compared to D. It's just much more expensive.


Ok, me neither. But how does D scale?


 For small tools productivity can be 2x less with C++.



 I think Java is fine when you don't use native. I don't use it, 
 but friends are and it seems competent AND fixes long-time 
 issues with C++ such as unsigned.


Java is way better than it used to be. Don't you think that D has 
missed (cf. iOS and Android) great opportunities because of too 
much feature frenzy and trying out CS stuff? Seriously, I think 
is has.
Oct 18 2019
next sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Friday, 18 October 2019 at 11:36:45 UTC, Chris wrote:

 But how does D scale?


I'm glad you asked!
Your question is not very specific ("scales") but let's try.

D scales in terms of codebase size since the stdlib is rich 
already, build times are good and chances are will get better 
still.

D scales in terms of mental load because it has dependency 
management and SemVer (you can maintain a large amount of code 
with little breakage). Without DUB I couldn't hope to maintain so 
much code, SemVer lets you update things when you need them 
updated.

D scales to teams because it has builtin unittests, invariant, 
builtin heredoc (though, like C++, you will probably need to 
restrain some features).

D scales to newer platforms thanks to multiple backends, with 
very many platforms announced for GDC and iPhone and Webasm 
coming to LDC.
Oct 18 2019
parent reply Russel Winder <russel winder.org.uk> writes:
On Fri, 2019-10-18 at 13:35 +0000, Guillaume Piolat via Digitalmars-d wrote=
:

 On Friday, 18 October 2019 at 11:36:45 UTC, Chris wrote:

 But how does D scale?
=20


=20
 I'm glad you asked!
 Your question is not very specific ("scales") but let's try.


How does any programming language scale? It doesn't, it's just a programmin=
g
language.

If we take scale to mean able to be as easily used by 200 programmers on a
10,000,000 line codebase as as 1 programmer on a 100 line codebase, then
generally no-one has any idea, and certainly no data. For any language. The
whole scaling argument regarding codebases is usually vacuous philosophisin=
g.
Most teams use a programming language and then find out how to use it for b=
ig
codebases as for little ones when their little codebase becomes a big one. =
cf.
FORTRAN, Fortran, C++, COBOL, Go, Rust, Lisp, SML, etc.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk
Oct 18 2019
parent reply Guillaume Piolat <first.last gmail.com> writes:
On Friday, 18 October 2019 at 13:54:19 UTC, Russel Winder wrote:

 On Fri, 2019-10-18 at 13:35 +0000, Guillaume Piolat via 
 Digitalmars-d wrote:

 On Friday, 18 October 2019 at 11:36:45 UTC, Chris wrote:

 But how does D scale?
 


 
 I'm glad you asked!
 Your question is not very specific ("scales") but let's try.


 How does any programming language scale? It doesn't, it's just 
 a programming language.

 If we take scale to mean able to be as easily used by 200 
 programmers on a 10,000,000 line codebase as as 1 programmer on 
 a 100 line codebase, then generally no-one has any idea, and 
 certainly no data. For any language. The whole scaling argument 
 regarding codebases is usually vacuous philosophising. Most 
 teams use a programming language and then find out how to use 
 it for big codebases as for little ones when their little 
 codebase becomes a big one. cf. FORTRAN, Fortran, C++, COBOL, 
 Go, Rust, Lisp, SML, etc.


Where is no data or conclusive evidence, there are some anecdotes.
- some people with large python codebases, even full-time, tend 
to tell me that dynamic types don't "scale" that well past 10 kLOC
- some problems reveal themselves "at scale". For example in a 
C++ constructor you can leave a filed uninitialized. I've once 2 
weeks on such a bug that cascaded in a complicated system.  D has 
.init and would have avoided that.
- Java seems to scale exceptionally well thanks to a culture of 
reuse and comparably simple language
I don't think it's all in our heads that some language are more 
conducive to "scale", whatever that means.
Oct 18 2019
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/18/2019 7:01 AM, Guillaume Piolat wrote:

 Where is no data or conclusive evidence, there are some anecdotes.
 - some people with large python codebases, even full-time, tend to tell me
that 
 dynamic types don't "scale" that well past 10 kLOC
 - some problems reveal themselves "at scale". For example in a C++ constructor 
 you can leave a filed uninitialized. I've once 2 weeks on such a bug that 
 cascaded in a complicated system.  D has .init and would have avoided that.
 - Java seems to scale exceptionally well thanks to a culture of reuse and 
 comparably simple language
 I don't think it's all in our heads that some language are more conducive to 
 "scale", whatever that means.


D does have features specifically to help with scaling. Along with what you
mention:

1. modules
2. lack of a global namespace
3. anti-hijacking features
4. a very good capability to do encapsulation
5. the 'version' declaration
6. the 'deprecation' attribute
Oct 19 2019
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 19/10/2019 10:00 PM, Walter Bright wrote:

 On 10/18/2019 7:01 AM, Guillaume Piolat wrote:

 Where is no data or conclusive evidence, there are some anecdotes.
 - some people with large python codebases, even full-time, tend to 
 tell me that dynamic types don't "scale" that well past 10 kLOC
 - some problems reveal themselves "at scale". For example in a C++ 
 constructor you can leave a filed uninitialized. I've once 2 weeks on 
 such a bug that cascaded in a complicated system.  D has .init and 
 would have avoided that.
 - Java seems to scale exceptionally well thanks to a culture of reuse 
 and comparably simple language
 I don't think it's all in our heads that some language are more 
 conducive to "scale", whatever that means.


 
 D does have features specifically to help with scaling. Along with what 
 you mention:
 
 1. modules
 2. lack of a global namespace
 3. anti-hijacking features
 4. a very good capability to do encapsulation
 5. the 'version' declaration
 6. the 'deprecation' attribute


Don't forget about the 'debug' declaration too!

Highly underutilized that one is, but pretty awesome.
Oct 19 2019
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Fri, 2019-10-18 at 14:01 +0000, Guillaume Piolat via Digitalmars-d wrote=
:
[=E2=80=A6]

 Where is no data or conclusive evidence, there are some anecdotes.


But that is the point, they are anecdotes, reports of individual's experien=
ce.
Very useful for building theories and hypotheses, but definitely not
conclusive evidence.


 - some people with large python codebases, even full-time, tend=20
 to tell me that dynamic types don't "scale" that well past 10 kLOC


And some people have no problem using dynamic types with 10kLOC codebases.


 - some problems reveal themselves "at scale". For example in a=20
 C++ constructor you can leave a filed uninitialized. I've once 2=20
 weeks on such a bug that cascaded in a complicated system.  D has=20
 .init and would have avoided that.


Which is good.


 - Java seems to scale exceptionally well thanks to a culture of=20
 reuse and comparably simple language


That there are some very big Java codebases doesn't necessarily support the
thesis that Java supports scaling. That some people have found ways of work=
ing
with big codebases is a testament to their ingenuity as much as it is to th=
e
classes and packages. But yes packages definitely help with all languages t=
hat
have them =E2=80=93 we could posit that as a theory.=20


 I don't think it's all in our heads that some language are more=20
 conducive to "scale", whatever that means.


If we do not define "scaling" then there can be no statement of "some langu=
age
support scaling better than others". We need to be clear what we mean by
scaling in codebases, but I thought we had a common definition of this
already.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk
Oct 20 2019
parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/20/2019 2:57 AM, Russel Winder wrote:

 If we do not define "scaling" then there can be no statement of "some language
 support scaling better than others". We need to be clear what we mean by
 scaling in codebases, but I thought we had a common definition of this
 already.


I don't know what the common definition of it is, but I'd define it as the 
complexity of the code goes up linearly with the number of lines. I'd say the 
close the complexity is to linear, the better it "scales".

I'd then define complexity as the number of interactions between the lines of
code.

This means that the better a language supports encapsulation, the more scalable 
it is.

For example, if a language has only one namespace, the larger it gets, the 
harder it is to declare a new variable, as it would have to be unique. This 
would be a quadratic increase in complexity as the number of declarations
increased.
Oct 20 2019
prev sibling parent reply welkam <wwwelkam gmail.com> writes:
On Friday, 18 October 2019 at 11:36:45 UTC, Chris wrote:

 Desktop / server only I suppose. How does it scale?


 Hence the iOS effort.


 I couldn't wait anymore. Something so basic (not simple). 
 That's when D comes back to bite you. Sad but true.


I have this view. If current libraries or services in all 
languages do not satisfy your needs and you want to build your 
own solution then D is the perfect language. If you want to take 
a bunch of libraries, put some glue code and shit a product then 
D is a bad language for you.

I never had false idea that D is full of wonderful libraries for 
all my needs so I never had any problem when I didnt found 
something in dub. I bet most people have similar view.
Oct 18 2019
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Oct 18, 2019 at 03:09:02PM +0000, welkam via Digitalmars-d wrote:
[...]

 I have this view. If current libraries or services in all languages do
 not satisfy your needs and you want to build your own solution then D
 is the perfect language. If you want to take a bunch of libraries, put
 some glue code and shit a product then D is a bad language for you.


[...]

Very interesting view.  This probably explains why I like D so much --
I've never liked the idea of just throwing a bunch of libraries together
with some glue code and calling it a product.  But I bet most people
would disagree.  *shrug*


T

-- 
Once the bikeshed is up for painting, the rainbow won't suffice. -- Andrei
Alexandrescu
Oct 18 2019
parent welkam <wwwelkam gmail.com> writes:
On Friday, 18 October 2019 at 16:37:03 UTC, H. S. Teoh wrote:

 On Fri, Oct 18, 2019 at 03:09:02PM +0000, welkam via 
 Digitalmars-d wrote: [...]

 I have this view. If current libraries or services in all 
 languages do not satisfy your needs and you want to build your 
 own solution then D is the perfect language. If you want to 
 take a bunch of libraries, put some glue code and shit a 
 product then D is a bad language for you.


 [...]

 Very interesting view.  This probably explains why I like D so 
 much -- I've never liked the idea of just throwing a bunch of 
 libraries together with some glue code and calling it a 
 product.  But I bet most people would disagree.  *shrug*


 T


It suppose to be ship not shit...
Its not really interesting. Its just reality. If you want to 
build iOS game you are forced by circumstances to write it in 
swift. If you want to make multi platform(PC and consoles) game 
based on Unreal engine you are forced to use C++. If your program 
requires certain library you would choose a language that has 
access to that library. It would be foolish to pick D in those 
situations. That said if you want to make a server for a game 
then D start to shine because game server require lots of custom 
code. When it comes to writing custom code I dont think any 
language on the market is better than D.
Oct 18 2019
prev sibling next sibling parent Radu <void null.pt> writes:
On Friday, 18 October 2019 at 11:24:38 UTC, Guillaume Piolat 
wrote:

 On Friday, 18 October 2019 at 11:15:55 UTC, Chris wrote:

 [...]


 All the time, and avoiding recent features.



 [...]


 Hence the iOS effort.



 [...]


 I've used C++ in commercial capacity in 3 places. All had 
 massive compile time problems, fragmentation, inability to add 
 third-party code easily, and were massive debt machines.

 I would never, ever start any effort in C++ as it's a sink of 
 money compared to D. It's just much more expensive.

 For small tools productivity can be 2x less with C++.

 I think Java is fine when you don't use native. I don't use it, 
 but friends are and it seems competent AND fixes long-time 
 issues with C++ such as unsigned.


"Don't feed the trolls!"

You don't have to prove anything to anyone, engaging in **any* 
argument* with such avatars is as dry as Atacama.
Oct 18 2019
prev sibling parent IGotD- <nise nise.com> writes:
On Friday, 18 October 2019 at 11:24:38 UTC, Guillaume Piolat 
wrote:

 On Friday, 18 October 2019 at 11:15:55 UTC, Chris wrote:

 Point taken, yeah, D has great features, and how do you use it?


 All the time, and avoiding recent features.



 Desktop / server only I suppose. How does it scale?


 Hence the iOS effort.



 Would you use D as other companies use Java and C++.


 I've used C++ in commercial capacity in 3 places. All had 
 massive compile time problems, fragmentation, inability to add 
 third-party code easily, and were massive debt machines.

 I would never, ever start any effort in C++ as it's a sink of 
 money compared to D. It's just much more expensive.

 For small tools productivity can be 2x less with C++.

 I think Java is fine when you don't use native. I don't use it, 
 but friends are and it seems competent AND fixes long-time 
 issues with C++ such as unsigned.


That's also my experience. Using C++ in a fairly high level 
projects involving interfacing to servers/cloud or any business 
application C++ is just a no go, at least for me. C++ has almost 
nothing out of the box, right now C++ doesn't even have its own 
socket library. Then you have search of 3rd party libraries which 
takes time and you really have to watch out when it comes to 
licenses which reduces the amount you can choose from. 3rd party 
libraries also varies a lot when it comes to quality. You have 
Boost which is quite good but when you include it will increase 
the compile times by a crazy amount.

Anything not low level, stay away from C++.

Java is better with good library support but suffers from high 
memory consumption. You cannot chuck several Java processes in a 
Linux system with only 512 - 1 GB of RAM because you will run out 
of memory very quickly. 1 - 4 java processes but then you're out.

D fills the spot between Java and C++. You can quickly code 
something in a working condition than C++ which is also more 
stable. Memory consumption wise I expect it also to be between 
C++ and Java. I would like to see a plug in referenced counted GC 
because that would decrease the memory consumption as well which 
is good for those small but many services you often see in 
systems today.
Oct 18 2019
prev sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Thursday, 17 October 2019 at 19:00:47 UTC, Ola Fosheim Grøstad 
wrote:

 On Thursday, 17 October 2019 at 17:23:29 UTC, welkam wrote:

 If dichotomy isn't false then answer weather D is high or low 
 level language? The dichotomy exist for other languages 
 because of their design limitations not because of some lows 
 of nature.


 Low level.  With some high level runtime features.  There is 
 very little room for high level optimization in D.


I hope for that not to be the case if/when the MLIR SAOC project 
comes through.

Even without that being able to do array of struct <-> struct of 
array in the language is very nice and as an example of high 
level optimisation parameterisation that is far more effective in 
allow optimisation from the top down and still be able to change 
design decisions.
Oct 18 2019
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 18 October 2019 at 20:40:46 UTC, Nicholas Wilson wrote:

 On Thursday, 17 October 2019 at 19:00:47 UTC, Ola Fosheim 
 Grøstad wrote:

 Low level.  With some high level runtime features.  There is 
 very little room for high level optimization in D.


 I hope for that not to be the case if/when the MLIR SAOC 
 project comes through.

 Even without that being able to do array of struct <-> struct 
 of array in the language is very nice and as an example of high 
 level optimisation parameterisation that is far more effective 
 in allow optimisation from the top down and still be able to 
 change design decisions.


Right, you can establish that a program follows a high level 
strategy by statically proving that the program at hand is 
written without depending on memory layout, but that doesn't make 
the language high level (in which case all programs written in 
that language have that property).

Though, I guess it is fair to say that if a language provides 
100% encapsulation for library constructs then libraries can do 
high level optimizations (if the language provide the right meta 
programming features, e.g. term rewriting).
Oct 29 2019
prev sibling parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Thursday, 17 October 2019 at 17:23:29 UTC, welkam wrote:


 In D's case 99% of all problems are due to lack of resources so 
 advocating for change will have 0 results.


In D's case 99% of all problems are due to lack of understanding 
why there's a lack of resources ...
Oct 17 2019
prev sibling parent welkam <wwwelkam gmail.com> writes:
On Thursday, 17 October 2019 at 08:20:02 UTC, Chris wrote:

 <...>there have been changes in the leadership, and Átila seems 
 to have an open mind as regards tooling


 From https://news.ycombinator.com/item?id=21257943
	
WalterBright 1 day ago [-]

 I think every programmer language designer underestimates the 
 importance of good IDE support.


Oh, we're well aware of it. It's just that the language design 
part consumes all our time.

So as you can see previous leadership also valued tooling but 
nothing was done because lack of available resources. The only 
thing that might change is the amount of people asking for 
certain tool and more money available to D language foundation 
than in the past. Changing people in charge wont change anything 
when people in charge are not the ones why things are not 
happening.


 His vision is ambitious


What? Apart from making D the default implementation language all 
other are what Atila could do alone in a year. Its not ambitious 
at all.



 Yeah, no. It's the few critics who are to blame, it's not the 
 multiple flaws of D that prevent mass-adoption of D


Deflection. Classic. I talked about that there is significant 
increase in negativity that new people coming here start to 
complain about and you responded to what is preventing mass 
adoption. If you are quoting then respond to actual point or not 
at all.



 But then again, how do you explain this post by a long standing 
 and well respected member of the community?

 https://forum.dlang.org/post/mailman.538.1571254122.8294.digitalmars-d puremagic.com


What is here to explain? He is complaining about lack of 
communication. What do you want me to explain?
Oct 17 2019
prev sibling next sibling parent IGotD- <nise nise.com> writes:
On Tuesday, 15 October 2019 at 13:09:15 UTC, Mike Parker wrote:

 This thread is for general feedback and discussion regarding 
 Átila's blog post on his vision for D's future.

 https://dlang.org/blog/2019/10/15/my-vision-of-ds-future/


While I agree mostly with the vision I feel that that roadmap for 
betterC has been left out. There is currently not any roadmap how 
to continue to improve betterC and "pay as you go".

betterC is a great step of embedded programming but libraries are 
lacking as well as the benefits of the built features like 
dynamic arrays and associative arrays. It would be a great 
benefit to port these features to a non GC environment as well.

Basically a vision for D to improve being a real systems 
programming language suitable for bare metal and embedded 
programming.
Oct 15 2019
prev sibling next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
Everything looks good in the article.
As others have said pay as you go D would be nice.

Something I am concerned about is no mention of a big push to get dmd 
into a good state for library usage. That is really missing if we want a 
first class IDE experience IMO.

That is not what I personally care about to the point of working on it 
actively. What I care about is Phobos v2 as H.S. Teoh mentioned.

If we were to do it today, very little would have changed in terms of 
language integration. We would still have isInputRange and friends which 
is quite frankly a code smell. Yes its great that we can do it 100% with 
the tools we have, but it is absolutely horrible for integration into 
the compiler (e.g. errors) and easily being understood for newbies in 
that part of a given library.

I don't want anyone else to go through what I did in 2012-2013'ish to 
learn ranges. We can do better. We are missing a concept here in the 
language (see Rust and Swift as evidence that there is is a trend to 
have something for this).

My solution was to replace e.g. isInputRange with signatures from ML, 
sadly DIP 1020 was a major stepping stone on this path. So I'm now in a 
state of figuring out the entire thing from scratch.

Thoughts?
Oct 15 2019
prev sibling next sibling parent reply neikeq <ignalfonsore gmail.com> writes:
On Tuesday, 15 October 2019 at 13:09:15 UTC, Mike Parker wrote:

 This thread is for general feedback and discussion regarding 
 Átila's blog post on his vision for D's future.

 https://dlang.org/blog/2019/10/15/my-vision-of-ds-future/


The second paragraph of 'Make D the default implementation 
language' lacks an example for those who are not familiar with 
it. How can D, compared to its contenders, make the code 
'automagically' callable from other languages? A reference to an 
existing library could do.

Regarding interop with C++, what are your thoughts on tools like 
Calypso? It supports most C++ features, including advanced stuff 
like template instantiation, and it seems to be under active 
development: https://github.com/Syniurge/Calypso

I understand the main motivation behind the interpreter is fast 
iteration times. Is the idea to have an interpreter that can run 
entire applications?

Overall this was an interesting read. It's nice to see the 
efforts that are being made to make D  safe by default.
Oct 15 2019
next sibling parent Atila Neves <atila.neves gmail.com> writes:
On Wednesday, 16 October 2019 at 00:33:20 UTC, neikeq wrote:

 On Tuesday, 15 October 2019 at 13:09:15 UTC, Mike Parker wrote:

 https://dlang.org/blog/2019/10/15/my-vision-of-ds-future/


 The second paragraph of 'Make D the default implementation 
 language' lacks an example for those who are not familiar with 
 it. How can D, compared to its contenders, make the code 
 'automagically' callable from other languages? A reference to 
 an existing library could do.


https://github.com/symmetryinvestments/autowrap


 Regarding interop with C++, what are your thoughts on tools 
 like Calypso? It supports most C++ features, including advanced 
 stuff like template instantiation, and it seems to be under 
 active development: https://github.com/Syniurge/Calypso


My thoughts are the same as the ones I described in my DConf 2019 
talk, namely that convincing a team wary of changing over to D 
that they should use a forked version of a compiler that's not 
even the reference one would go down like a lead balloon.

If you're in charge, can mandate using Calypso and it works for 
you, great! But in that case you're likely to be less averse to 
change than the average programmer and we "have you" already. We 
want to convince "regular folk".


 I understand the main motivation behind the interpreter is fast 
 iteration times. Is the idea to have an interpreter that can 
 run entire applications?


Yes.
Oct 16 2019
prev sibling parent reply Gregor =?UTF-8?B?TcO8Y2ts?= <gregormueckl gmx.de> writes:
On Wednesday, 16 October 2019 at 00:33:20 UTC, neikeq wrote:

 Regarding interop with C++, what are your thoughts on tools 
 like Calypso? It supports most C++ features, including advanced 
 stuff like template instantiation, and it seems to be under 
 active development: https://github.com/Syniurge/Calypso


What is the state of Calypso? The last release was in 2014. This 
is also the latest tag that was created. Development on master 
stopped in 2018. The most recent commits were on branch. I would 
have missed that from a cursory look at the commit history (you 
have to switch branches to notice!). I don't know when it was 
last sync'ed with LDC. If I wanted to use it, how would I even go 
about that? How do I get a version that is compatible with recent 
versions of D and works / is supported?

My point is: the publicly visible state of the project isn't very 
encouraging for potential users.
Oct 16 2019
parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Wednesday, 16 October 2019 at 17:07:27 UTC, Gregor Mückl wrote:

 On Wednesday, 16 October 2019 at 00:33:20 UTC, neikeq wrote:

 Regarding interop with C++, what are your thoughts on tools 
 like Calypso? It supports most C++ features, including 
 advanced stuff like template instantiation, and it seems to be 
 under active development: https://github.com/Syniurge/Calypso


 What is the state of Calypso? The last release was in 2014. 
 This is also the latest tag that was created. Development on 
 master stopped in 2018. The most recent commits were on branch. 
 I would have missed that from a cursory look at the commit 
 history (you have to switch branches to notice!). I don't know 
 when it was last sync'ed with LDC. If I wanted to use it, how 
 would I even go about that? How do I get a version that is 
 compatible with recent versions of D and works / is supported?

 My point is: the publicly visible state of the project isn't 
 very encouraging for potential users.


The last line of work appears to be in the clang-9 branch: 
https://github.com/Syniurge/Calypso/commits/clang-9

W.r.t to C++ interop there are 5 areas of development:
1. During the past 3 years there have been a ton of fixes to 
extern (C++) (and to a lesser extent extern (C), which was 
already close to rock-solid) and nowadays it should be pretty 
usable (namespaces, classes and templates work in many cases). 
You can directly call much of D from C++ and vice versa. 
Obviously there are many D and C++ specific language features 
that are not yet/can't be supported, but we're pretty further 
along than what we had a couple of years ago. Having all 3 major 
compilers (first DMD, then LDC and now GDC) be written half in D 
and half in C++ is a testament to that. (Actually now DMD is 
D-only now, but it was in C++ + D mode for enough time to force 
many of the developers at the time to at least make the subset of 
extern (C++) that it used fully working.)

2. During the past year some parts of STL had bindings written to 
them and tested for Linux, Mac and Windows (which is surprisingly 
difficult, due to difference in C++ compilers and STL 
implementations): 
https://github.com/dlang/druntime/tree/master/src/core/stdcpp

3. Having tools like dstep and dpp support C++. As far as I know 
both tools support only C header files, but at least for dpp, 
Atila has listed C++ as a major planned feature. Work in area 1. 
makes 3. now possible. The work of one of GSOC students made a 
huge impact for dstep, so it's likely that a similar tactic for 
dpp would also help.

4. Automatic C/C++ header generation for D code. There has been 
solid progress, but we're probably a couple of months before 
having the work finally merged upstream.

5. Making import C++ automagically work has been the holy grail 
for many. The author of Calypso has had the unfortunate task of 
having to single-handedly work on not only implementation, but 
also solving many language-level challenges like template 
instantiation, overloading and many more. Adding insult to 
injury, the most efficient way to interface with libClang is with 
C++ and for they don't guarantee a stable API, and even break it 
very often, and D's frontend is likely worse then that (at 
minimum it switched from being C++ only, to D only during the 
time Calypso was developed.).
I think the best way forward is to get it merged in LDC as soon 
as possible - that way at least the burden of supporting new D 
frontend and LLVM/clang backend versions could be shared by other 
contributors.
Oct 17 2019
parent reply Gregor =?UTF-8?B?TcO8Y2ts?= <gregormueckl gmx.de> writes:
On Thursday, 17 October 2019 at 13:16:07 UTC, Petar Kirov 
[ZombineDev] wrote:

 The last line of work appears to be in the clang-9 branch: 
 https://github.com/Syniurge/Calypso/commits/clang-9

 W.r.t to C++ interop there are 5 areas of development:
 1. During the past 3 years there have been a ton of fixes to 
 extern (C++) (and to a lesser extent extern (C), which was 
 already close to rock-solid) and nowadays it should be pretty 
 usable (namespaces, classes and templates work in many cases). 
 You can directly call much of D from C++ and vice versa. 
 Obviously there are many D and C++ specific language features 
 that are not yet/can't be supported, but we're pretty further 
 along than what we had a couple of years ago. Having all 3 
 major compilers (first DMD, then LDC and now GDC) be written 
 half in D and half in C++ is a testament to that. (Actually now 
 DMD is D-only now, but it was in C++ + D mode for enough time 
 to force many of the developers at the time to at least make 
 the subset of extern (C++) that it used fully working.)

 2. During the past year some parts of STL had bindings written 
 to them and tested for Linux, Mac and Windows (which is 
 surprisingly difficult, due to difference in C++ compilers and 
 STL implementations): 
 https://github.com/dlang/druntime/tree/master/src/core/stdcpp

 3. Having tools like dstep and dpp support C++. As far as I 
 know both tools support only C header files, but at least for 
 dpp, Atila has listed C++ as a major planned feature. Work in 
 area 1. makes 3. now possible. The work of one of GSOC students 
 made a huge impact for dstep, so it's likely that a similar 
 tactic for dpp would also help.

 4. Automatic C/C++ header generation for D code. There has been 
 solid progress, but we're probably a couple of months before 
 having the work finally merged upstream.

 5. Making import C++ automagically work has been the holy grail 
 for many. The author of Calypso has had the unfortunate task of 
 having to single-handedly work on not only implementation, but 
 also solving many language-level challenges like template 
 instantiation, overloading and many more. Adding insult to 
 injury, the most efficient way to interface with libClang is 
 with C++ and for they don't guarantee a stable API, and even 
 break it very often, and D's frontend is likely worse then that 
 (at minimum it switched from being C++ only, to D only during 
 the time Calypso was developed.).
 I think the best way forward is to get it merged in LDC as soon 
 as possible - that way at least the burden of supporting new D 
 frontend and LLVM/clang backend versions could be shared by 
 other contributors.


Thank you for the detailed progress report. However, I'm afraid 
that this doesn't answer the one central question that a 
potential user would have: which version do I use and where/how 
do I get it?

Calypso has been mentioned as a possible path to get easy C++ 
interop here several times. But the current appearance of the 
github project does not instill any confidence in people who 
don't feel especially adventurous.

I'm amazed at the determination that it takes to create something 
as complex as Calypso. I'd very much like it to succeed.

Semi-OT, I would also like to see the automatic C++ header 
generation integrated into DMD/LDC/GDC. This would complement 
C++-to-D interop nicely. There's a pull request for this feature 
on github that is slowly getting stale. I don't know if it's 
merely being ignored or whether there are remaining issues with 
it.
Oct 17 2019
parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Thursday, 17 October 2019 at 23:56:20 UTC, Gregor Mückl wrote:

 On Thursday, 17 October 2019 at 13:16:07 UTC, Petar Kirov 
 [ZombineDev] wrote:

 The last line of work appears to be in the clang-9 branch: 
 https://github.com/Syniurge/Calypso/commits/clang-9

 W.r.t to C++ interop there are 5 areas of development:
 1. During the past 3 years there have been a ton of fixes to 
 extern (C++) (and to a lesser extent extern (C), which was 
 already close to rock-solid) and nowadays it should be pretty 
 usable (namespaces, classes and templates work in many cases). 
 You can directly call much of D from C++ and vice versa. 
 Obviously there are many D and C++ specific language features 
 that are not yet/can't be supported, but we're pretty further 
 along than what we had a couple of years ago. Having all 3 
 major compilers (first DMD, then LDC and now GDC) be written 
 half in D and half in C++ is a testament to that. (Actually 
 now DMD is D-only now, but it was in C++ + D mode for enough 
 time to force many of the developers at the time to at least 
 make the subset of extern (C++) that it used fully working.)

 2. During the past year some parts of STL had bindings written 
 to them and tested for Linux, Mac and Windows (which is 
 surprisingly difficult, due to difference in C++ compilers and 
 STL implementations): 
 https://github.com/dlang/druntime/tree/master/src/core/stdcpp

 3. Having tools like dstep and dpp support C++. As far as I 
 know both tools support only C header files, but at least for 
 dpp, Atila has listed C++ as a major planned feature. Work in 
 area 1. makes 3. now possible. The work of one of GSOC 
 students made a huge impact for dstep, so it's likely that a 
 similar tactic for dpp would also help.

 4. Automatic C/C++ header generation for D code. There has 
 been solid progress, but we're probably a couple of months 
 before having the work finally merged upstream.

 5. Making import C++ automagically work has been the holy 
 grail for many. The author of Calypso has had the unfortunate 
 task of having to single-handedly work on not only 
 implementation, but also solving many language-level 
 challenges like template instantiation, overloading and many 
 more. Adding insult to injury, the most efficient way to 
 interface with libClang is with C++ and for they don't 
 guarantee a stable API, and even break it very often, and D's 
 frontend is likely worse then that (at minimum it switched 
 from being C++ only, to D only during the time Calypso was 
 developed.).
 I think the best way forward is to get it merged in LDC as 
 soon as possible - that way at least the burden of supporting 
 new D frontend and LLVM/clang backend versions could be shared 
 by other contributors.


 Thank you for the detailed progress report. However, I'm afraid 
 that this doesn't answer the one central question that a 
 potential user would have: which version do I use and where/how 
 do I get it?

 Calypso has been mentioned as a possible path to get easy C++ 
 interop here several times. But the current appearance of the 
 github project does not instill any confidence in people who 
 don't feel especially adventurous.


I don't think that anybody has ever advertised Calypso as 
anything remotely production ready. Like any proof-concept/alpha 
software, it should be used only by people coming the mindset 
that they *will* hit many bugs and they're here to test the 
project, report the bugs and help its development. If you're not 
one of those people you should either wait for the project to 
become ready, or if it's important enough for you to help in some 
other way.


 I'm amazed at the determination that it takes to create 
 something as complex as Calypso. I'd very much like it to 
 succeed.


Yes, I am also extremely impressed by the skills and 
determination of the author, and I think that his approach is the 
only that can offer the best user experience, but I think it 
would be more healthy if people don't come with wrong 
expectations.


 Semi-OT, I would also like to see the automatic C++ header 
 generation integrated into DMD/LDC/GDC. This would complement 
 C++-to-D interop nicely. There's a pull request for this 
 feature on github that is slowly getting stale. I don't know if 
 it's merely being ignored or whether there are remaining issues 
 with it.


That's point 4. on my list. When it will be ready it would be 
part of all 3 compilers. As far as I know there's more work to be 
done and when the author has free time he will need to push 
forward before we can have his PR merged.
Oct 18 2019
parent Gregor =?UTF-8?B?TcO8Y2ts?= <gregormueckl gmx.de> writes:
On Friday, 18 October 2019 at 08:28:22 UTC, Petar Kirov 
[ZombineDev] wrote:

 I don't think that anybody has ever advertised Calypso as 
 anything remotely production ready. Like any 
 proof-concept/alpha software, it should be used only by people 
 coming the mindset that they *will* hit many bugs and they're 
 here to test the project, report the bugs and help its 
 development. If you're not one of those people you should 
 either wait for the project to become ready, or if it's 
 important enough for you to help in some other way.


Thank you for that clarification. I distinctly remember some 
messages here that implied that Calypso is usable. I don't recall 
who said that.


 Semi-OT, I would also like to see the automatic C++ header 
 generation integrated into DMD/LDC/GDC. This would complement 
 C++-to-D interop nicely. There's a pull request for this 
 feature on github that is slowly getting stale. I don't know 
 if it's merely being ignored or whether there are remaining 
 issues with it.


 That's point 4. on my list. When it will be ready it would be 
 part of all 3 compilers. As far as I know there's more work to 
 be done and when the author has free time he will need to push 
 forward before we can have his PR merged.


I was talking about https://github.com/dlang/dmd/pull/9971, which 
would include that feature in the DMD frontend.

Either way, the software stack I work with needs C++ at the 
uppermost layer that ties everything together. I could write 
individual libraries within the stack in D, but I don't want to 
maintain separate interface definitions manually. This is why I'm 
so interested int getting this feature. I don't care quite as 
much for having C++ interfaces usable from D, although that would 
be a big one. Most languages require a C wrapper around C++ which 
makes this stuff even more cumbersome to use. I don't want to 
bother with anything like this. I even consider the C++ 
header/implementation file split cumbersome and slow to work with.
Oct 18 2019
prev sibling next sibling parent reply GreatSam4sure <greatsam4sure gmail.com> writes:
On Tuesday, 15 October 2019 at 13:09:15 UTC, Mike Parker wrote:

 This thread is for general feedback and discussion regarding 
 Átila's blog post on his vision for D's future.

 https://dlang.org/blog/2019/10/15/my-vision-of-ds-future/



Thanks to Mike and Atila. This is refreshing to hear. All the 
goals are superb. They are really well thought of and D deserves 
such push and prominence.

To make D the default implementation language, D must cover in 
addition to the stated goals.

(1) Desktop-A easy to use and easily customizable GUI toolkit D. 
JavaFX can be posted to D. I am aware of gtkd and dlangui. I have 
try them but still lacking e.g I do I center windom 
programmatically on screen?

(2)web- we have vibe.d already. Can we have a web framework that 
is ease and provide high performance like Go

(3)mobile-effort is already on but we need the ease of java and 
kotlin.

(4) Data science and AI-framework just like python. Although 
python can be easily call from D

         Tooling

The best tooling of D on windows is code-d and visualD.This is 
also DLS onwindow. D needs to have strong support on all major 
IDE like IntelliJ, NetBeans, vs code, visual studio, and eclipse. 
There is D support for IntelliJ and eclipse but still really 
lacking. Vs code and visual studio has D support that is really 
doing well. I commend the effort of those behind it


               Great Community

One of the biggest problem of the D language is harmony of the 
community. For all I have seen in this community thus far is 
fragile unity and singleness of purpose. People do what they like 
and there is good reason for that since they are not paid.


The solution is to assemble a community around each of the goal 
of D to ensure that such goal are realize in good time. A people 
skill is needed here. I think Atila is not doing bad on that. 
Each of the goals should have a person heading it. It is possible.

Strong harmony must be ensure in the D community if we must have 
these goals. Recently I have seen greater level of harmony 
especially in the recent DIP on shared.

     Money through donations

We can them raise money through donations to fund some of these 
goals.
Oct 16 2019
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 16/10/2019 10:51 PM, GreatSam4sure wrote:

 
 (1) Desktop-A easy to use and easily customizable GUI toolkit D. JavaFX 
 can be posted to D.


Recently I have been working on widget rendering as a requirements 
gathering process for the graphics workgroup (informal, on Discord).

Sadly we are a bit resource constrained as the experts on things like 
color and graphics pipelines (aka Manu and with that Ethan) are a bit 
busy most of the year and its not a small task. So not much to show as 
of now, hence no public announcement.
Oct 16 2019
parent reply aberba <karabutaworld gmail.com> writes:
On Wednesday, 16 October 2019 at 10:09:14 UTC, rikki cattermole 
wrote:

 On 16/10/2019 10:51 PM, GreatSam4sure wrote:

 
 (1) Desktop-A easy to use and easily customizable GUI toolkit 
 D. JavaFX can be posted to D.


 Recently I have been working on widget rendering as a 
 requirements gathering process for the graphics workgroup 
 (informal, on Discord).

 Sadly we are a bit resource constrained as the experts on 
 things like color and graphics pipelines (aka Manu and with 
 that Ethan) are a bit busy most of the year and its not a small 
 task. So not much to show as of now, hence no public 
 announcement.


I believe someone here was working on Color and Windowing. Was 
previously called Divisualization on GitHub. I think GUI is one 
of the pressing needs for a killer App and enterprise 
adoption...native apps.

Tilix is said to be the D killer app due to GUI. D need a GUI. 
Whatever we can scrap off DlangUI and the existing ones to build 
a modern GUI toolkit is worth it.

GTK is great as a GUI toolkit especially with the use of CSS for 
styling, UI markup/xml/json-like support and modern smart 
layouts. Very basic and flexible to powerful theming with CSS. 
Only issue is its not cross platform by design...and its C.
Oct 16 2019
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 17/10/2019 10:20 AM, aberba wrote:

 On Wednesday, 16 October 2019 at 10:09:14 UTC, rikki cattermole wrote:

 On 16/10/2019 10:51 PM, GreatSam4sure wrote:

 (1) Desktop-A easy to use and easily customizable GUI toolkit D. 
 JavaFX can be posted to D.


 Recently I have been working on widget rendering as a requirements 
 gathering process for the graphics workgroup (informal, on Discord).

 Sadly we are a bit resource constrained as the experts on things like 
 color and graphics pipelines (aka Manu and with that Ethan) are a bit 
 busy most of the year and its not a small task. So not much to show as 
 of now, hence no public announcement.


 
 I believe someone here was working on Color and Windowing. Was 
 previously called Divisualization on GitHub. I think GUI is one of the 
 pressing needs for a killer App and enterprise adoption...native apps.


That be a me!


 Tilix is said to be the D killer app due to GUI. D need a GUI. Whatever 
 we can scrap off DlangUI and the existing ones to build a modern GUI 
 toolkit is worth it.


Last I have seen, there is nothing in dlangui that I would want to copy.

On that note Tilix is looking for a new maintainer, and I've offered to 
move it over to dlang-community given how prevalent its usage is outside 
of D.
Oct 16 2019
prev sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Wed, 2019-10-16 at 21:20 +0000, aberba via Digitalmars-d wrote:
[=E2=80=A6]

 GTK is great as a GUI toolkit especially with the use of CSS for=20
 styling, UI markup/xml/json-like support and modern smart=20
 layouts. Very basic and flexible to powerful theming with CSS.=20
 Only issue is its not cross platform by design...and its C.


Does it matter what language a library being used is written in as long as =
the
binding/wrapper to D is a good quality one? GtkD is a great binding/wrapper=
 to
GTK created using the correct tools for creating binding/wrapper to a GObje=
ct-
based library.

Also of course D is supposed to be able to use C libraries without the mass=
es
of overhead that Rust requires.
=20
--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk
Oct 17 2019
next sibling parent bioinfornatics <bioinfornatics fedoraproject.org> writes:
On Thursday, 17 October 2019 at 07:18:15 UTC, Russel Winder wrote:

 On Wed, 2019-10-16 at 21:20 +0000, aberba via Digitalmars-d 
 wrote: […]

 GTK is great as a GUI toolkit especially with the use of CSS 
 for styling, UI markup/xml/json-like support and modern smart 
 layouts. Very basic and flexible to powerful theming with CSS. 
 Only issue is its not cross platform by design...and its C.


 Does it matter what language a library being used is written in 
 as long as the binding/wrapper to D is a good quality one? GtkD 
 is a great binding/wrapper to GTK created using the correct 
 tools for creating binding/wrapper to a GObject- based library.

 Also of course D is supposed to be able to use C libraries 
 without the masses
 of overhead that Rust requires.


  I would agree with Russel. Indeed we have some resource that 
maintains GtkD, it work well to create a D heavy application.

To my point of view the market is not bound to a D GUI. They are 
2 two targets:

1/ light application so we need a killer framework "à la" 
jhipster (https://www.jhipster.tech)
This allow to create in less than 10 min minutes a three-tier 
architecture with these features: ready to be packaged (build 
script and dockerfile are generated), draw me your data I 
generate the code (uml to query), security ready (SSO technology 
are provided), database agnostics (choose cassandra, mysql, 
postgrsql, mongodb) I create the query for you.

2/ data scientist framework, python start to become famous around 
2012 but its reputation grow hugely with the new frameworks 
around data analysis, mining and learning. Especially with 
tensorflow, pytorch and so on ...

D can be a player in this fields if we prowide such powerful 
framework easy to use for the end user. Or easy to use for a any 
developer in such case we need to look what it is done by Apache 
with yarn,parquet,spark,hbase ...

For me D can become a huge player with one or bih killer 
application in this two fields.
Oct 25 2019
prev sibling parent reply bioinfornatics <bioinfornatics fedoraproject.org> writes:
On Thursday, 17 October 2019 at 07:18:15 UTC, Russel Winder wrote:

 On Wed, 2019-10-16 at 21:20 +0000, aberba via Digitalmars-d 
 wrote: […]

 GTK is great as a GUI toolkit especially with the use of CSS 
 for styling, UI markup/xml/json-like support and modern smart 
 layouts. Very basic and flexible to powerful theming with CSS. 
 Only issue is its not cross platform by design...and its C.


 Does it matter what language a library being used is written in 
 as long as the binding/wrapper to D is a good quality one? GtkD 
 is a great binding/wrapper to GTK created using the correct 
 tools for creating binding/wrapper to a GObject- based library.

 Also of course D is supposed to be able to use C libraries 
 without the masses
 of overhead that Rust requires.


  I would agree with Russel. Indeed we have some resource that 
maintains GtkD, it works well to create a D heavy application.

To my point of view, the market is not bound to a D GUI. They are 
2 two targets:

1/ light application so we need a killer framework "à la" 
jhipster (https://www.jhipster.tech)
This allows to create in less than 10 min minutes a three-tier 
architecture with these features: ready to be packaged (build 
script and dockerfile are generated), draw me your data I 
generate the code (UML to query), security ready (SSO technology 
are provided), database agnostics (choose Cassandra, MySQL, 
PostgreSQL, MongoDB) I create the query for you.

2/ data scientist framework, python start to become famous around 
2012 but its reputation grows hugely with the new frameworks 
around data analysis, mining and learning. Especially with 
Tensorflow, PyTorch and so on ...

D can be a player in these fields if we provide such powerful 
framework easy to use for the end-user. Or easy to use for by any 
developer in such case we need to look at what is done by Apache 
with yarn, parquet, spark, HBase ...

For me D can become a huge player with one or both killer 
applications in these two fields.
Oct 25 2019
parent reply bioinfornatics <bioinfornatics fedoraproject.org> writes:
On Friday, 25 October 2019 at 07:59:36 UTC, bioinfornatics wrote:

 On Thursday, 17 October 2019 at 07:18:15 UTC, Russel Winder 
 wrote:

 [...]


  I would agree with Russel. Indeed we have some resource that 
 maintains GtkD, it works well to create a D heavy application.

 [...]


About D and data scientist framework
a) I missed pandas python library
b) maybe Andrei could use its relationship with Yann LeCun (work 
at Facebook) and other key leaders on the deeplearning field to 
promote D through a killer DeepLearning framework
Oct 25 2019
parent jmh530 <john.michael.hall gmail.com> writes:
On Friday, 25 October 2019 at 10:01:06 UTC, bioinfornatics wrote:

 [snip]

 About D and data scientist framework
 a) I missed pandas python library


This is a step in the right direction:
https://forum.dlang.org/thread/jgsdvnjpttejswscxcjk forum.dlang.org?page=1
Oct 25 2019
prev sibling next sibling parent reply Rumbu <rumbu rumbu.ro> writes:
On Tuesday, 15 October 2019 at 13:09:15 UTC, Mike Parker wrote:

 This thread is for general feedback and discussion regarding 
 Átila's blog post on his vision for D's future.

 https://dlang.org/blog/2019/10/15/my-vision-of-ds-future/


I will put this here: 
https://rawgit.com/wilzbach/state-of-d/master/report.html

Summary (community profile/expectations/disappointments):
- Desktop applications as main area of development;
- Linux as preferred operating system;
- Dub as building tool;
- Visual Studio Code as main editor;
- Missing language features (tuples, named arguments, string 
interpolation)
- Phobos is not intuitive
-  nogc phobos
- json serialization;
- missing phobos important modules;
- poor compiler error messages;
- poor debugging experience;
-  safe is expected to be default;
- not enough third party libraries;
- lack of progress on DIPs;
- ranges are the best;
- spaces, not tabs :)

I don't necessarily endorse this list (e.g. I sincerely hate 
dub), but the D Vision seems to ignore it. And I find this more 
than wrong, personally perceiving it as "we don't care about your 
opinion, we have our own agenda, get lost".
Oct 16 2019
next sibling parent Greatsam4sure <greatsam4sure yahoo.com> writes:
On Wednesday, 16 October 2019 at 16:42:28 UTC, Rumbu wrote:

 On Tuesday, 15 October 2019 at 13:09:15 UTC, Mike Parker wrote:

 [...]


 I will put this here: 
 https://rawgit.com/wilzbach/state-of-d/master/report.html

 Summary (community profile/expectations/disappointments):
 - Desktop applications as main area of development;
 - Linux as preferred operating system;
 - Dub as building tool;
 - Visual Studio Code as main editor;
 - Missing language features (tuples, named arguments, string 
 interpolation)
 - Phobos is not intuitive
 -  nogc phobos
 - json serialization;
 - missing phobos important modules;
 - poor compiler error messages;
 - poor debugging experience;
 -  safe is expected to be default;
 - not enough third party libraries;
 - lack of progress on DIPs;
 - ranges are the best;
 - spaces, not tabs :)

 I don't necessarily endorse this list (e.g. I sincerely hate 
 dub), but the D Vision seems to ignore it. And I find this more 
 than wrong, personally perceiving it as "we don't care about 
 your opinion, we have our own agenda, get lost".


This effort is lovely. We need must listening and acting on 
people's suggestion so that they can feel at home and open their 
mind to work sincerely. Identity is the first thing in human 
relationship
Oct 16 2019
prev sibling next sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Wednesday, 16 October 2019 at 16:42:28 UTC, Rumbu wrote:

 On Tuesday, 15 October 2019 at 13:09:15 UTC, Mike Parker wrote:

 [...]


 I will put this here: 
 https://rawgit.com/wilzbach/state-of-d/master/report.html

 [...]


Which parts of that survey would you like the vision to include?
Oct 16 2019
next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Wednesday, 16 October 2019 at 17:40:42 UTC, Atila Neves wrote:

 On Wednesday, 16 October 2019 at 16:42:28 UTC, Rumbu wrote:

 On Tuesday, 15 October 2019 at 13:09:15 UTC, Mike Parker wrote:

 [...]


 I will put this here: 
 https://rawgit.com/wilzbach/state-of-d/master/report.html

 [...]


 Which parts of that survey would you like the vision to include?


Given that the community has already spoken, I think the onus is 
on the language maintainers at this point to take the results 
into account (or not).

For example, I could say which items I, personally, think are the 
most important--but I've already taken the survey. My answers are 
there, in the data, along with everyone else's. If the language 
maintainers care what I and the rest of the community thinks, 
that's where they ought to look. (And if they don't, then why ask 
a question like the one above in the first place?)
Oct 16 2019
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Oct 16, 2019 at 05:52:33PM +0000, Paul Backus via Digitalmars-d wrote:

 On Wednesday, 16 October 2019 at 17:40:42 UTC, Atila Neves wrote:

 On Wednesday, 16 October 2019 at 16:42:28 UTC, Rumbu wrote:




[...]

 https://rawgit.com/wilzbach/state-of-d/master/report.html






[...]

 Which parts of that survey would you like the vision to include?


 
 Given that the community has already spoken, I think the onus is on
 the language maintainers at this point to take the results into
 account (or not).


[...]

Yes, yes, and yes!  The language maintainers need to take this survey
into consideration, especially considering it represents a significant
number of D users (about 500+, give or take depending on the question).

It's OK if the language maintainers don't agree with certain points on
the survey, but please, pretty please, *make your stance clear*. Please
don't keep silence and leave us guessing.  That's *very* detrimental to
morale, and given the current state of D, we need as much morale as we
can muster.

Communication from the leadership has been wanting all these years, and
according to my observation it has resulted in a general loss of morale,
which could explain some of the avid D users who eventually left or
otherwise stopped contributing or reduced their contribution. Given that
this is supposed to be an open source, community project, communication
is extremely important. *Especially* response to something a large
number of users raise. And by response I don't mean always agree with
the majority, but TELL US clearly where exactly the leadership stands on
important issues.

By not communicating, or by not giving clear, direct responses to issues
raised, you are (intentionally or not) sending the message that you
don't care what we think, and while you certainly have the right to do
that, it's very demoralizing and discouraging to would-be contributors.


To use a concrete example: one rather telling point from the above
linked survey is that out of 291 respondents, 210 (72%) say that they
don't use -betterC, and 69 (24%) say they only use it for experimenting
/ testing / debugging, and only a meager 12 (4%) say that their project
actively depends on it.  Given how much time and effort has been poured
into -betterC recently, it begs the question, why?  What does the
leadership think of the results of this survey?  Does it think it's time
to reconsider the amount of effort put into -betterC?  Or does it
disagree? Or does it plain not care?  PLEASE TELL US.  Personally I
couldn't care less if the leadership says "we are charging ahead with
-betterC anyway, because XYZ". But please at least TELL US.

The leadership needs to respond, and needs to respond *publicly* and
*clearly*, in official capacity, to issues like this. Preferably, in a
public, easy-to-find place so that we don't have to keep asking and
wondering.  Failure to respond, like it or not, will lead to people
assuming that the leadership just plain doesn't care. That may or may
not be true, but that's what people will assume. And we don't want that,
because it damages morale. So please, communicate with us.


T

-- 
IBM = I'll Buy Microsoft!
Oct 16 2019
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 16 October 2019 at 19:28:35 UTC, H. S. Teoh wrote:

 [snip]

 To use a concrete example: one rather telling point from the 
 above linked survey is that out of 291 respondents, 210 (72%) 
 say that they don't use -betterC, and 69 (24%) say they only 
 use it for experimenting / testing / debugging, and only a 
 meager 12 (4%) say that their project actively depends on it.  
 [snip]


It would be interesting to do another survey and see if these 
numbers have changed. This survey was done in early 2018 and had 
been around less than a year.
Oct 16 2019
prev sibling next sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Wednesday, 16 October 2019 at 19:28:35 UTC, H. S. Teoh wrote:

 On Wed, Oct 16, 2019 at 05:52:33PM +0000, Paul Backus via 
 Digitalmars-d wrote:

 On Wednesday, 16 October 2019 at 17:40:42 UTC, Atila Neves 
 wrote:

 On Wednesday, 16 October 2019 at 16:42:28 UTC, Rumbu wrote:




 [...]

 https://rawgit.com/wilzbach/state-of-d/master/report.html






 [...]

 Which parts of that survey would you like the vision to 
 include?


 
 Given that the community has already spoken, I think the onus 
 is on the language maintainers at this point to take the 
 results into account (or not).


 [...]

 Yes, yes, and yes!  The language maintainers need to take this 
 survey into consideration, especially considering it represents 
 a significant number of D users (about 500+, give or take 
 depending on the question).

 It's OK if the language maintainers don't agree with certain 
 points on the survey, but please, pretty please, *make your 
 stance clear*. Please don't keep silence and leave us guessing.
  That's *very* detrimental to morale, and given the current 
 state of D, we need as much morale as we can muster.


I wasn't in my current role when that survey was taken. To be 
honest, I'd forgotten it'd happened (even though I participated!) 
and can't even remember if it was one or two years ago.

I'm happy it was brought up again, and even though there's no way 
of telling what the results would be now other than doing another 
survey, I'll make a point of taking a look at it going forward.

String interpolation was very popular at that survey and that's 
happening.
Oct 17 2019
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Oct 17, 2019 at 12:54:19PM +0000, Atila Neves via Digitalmars-d wrote:

 On Wednesday, 16 October 2019 at 19:28:35 UTC, H. S. Teoh wrote:


[...]

 It's OK if the language maintainers don't agree with certain points
 on the survey, but please, pretty please, *make your stance clear*.
 Please don't keep silence and leave us guessing.
  That's *very* detrimental to morale, and given the current state of
  D, we need as much morale as we can muster.


 
 I wasn't in my current role when that survey was taken. To be honest,
 I'd forgotten it'd happened (even though I participated!) and can't
 even remember if it was one or two years ago.


That was not directed at you personally, but in general at leadership as
the role.  But anyway, I'm also glad it was brought up again. Hopefully
we'll actually get some concrete results this time round.



 I'm happy it was brought up again, and even though there's no way of
 telling what the results would be now other than doing another survey,
 I'll make a point of taking a look at it going forward.


Perhaps doing another survey would not be amiss.  It would be
interesting afterwards to compare the two results to see how opinions
have shifted (or not).



 String interpolation was very popular at that survey and that's
 happening.


That's very heartening to hear, thanks!


T

-- 
MASM = Mana Ada Sistem, Man!
Oct 17 2019
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/17/2019 5:54 AM, Atila Neves wrote:

 String interpolation was very popular at that survey and that's happening.


That has multiple DIPs for it. So does named arguments. I've written DIPs for 
both. I've also done a DIP for  safe as default.
Oct 19 2019
prev sibling next sibling parent Martin Tschierschke <mt smartdolphin.de> writes:
On Wednesday, 16 October 2019 at 19:28:35 UTC, H. S. Teoh wrote:

 On Wed, Oct 16, 2019 at 05:52:33PM +0000, Paul Backus via 
 Digitalmars-d wrote:

 On Wednesday, 16 October 2019 at 17:40:42 UTC, Atila Neves 
 wrote:

 On Wednesday, 16 October 2019 at 16:42:28 UTC, Rumbu wrote:




 [...]

 https://rawgit.com/wilzbach/state-of-d/master/report.html






 [...]


[...]

 Yes, yes, and yes!  The language maintainers need to take this 
 survey into consideration, especially considering it represents 
 a significant number of D users (about 500+, give or take 
 depending on the question).

 It's OK if the language maintainers don't agree with certain 
 points on the survey, but please,[...] Please don't keep 
 silence and leave us guessing.


YES!

mt.
Oct 17 2019
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/16/2019 12:28 PM, H. S. Teoh wrote:

 Given how much time and effort has been poured
 into -betterC recently,


It wasn't that much. It was mainly turning some things off. I probably spent 
more time documenting it, writing an article, and doing a presentation on it 
than implementation.



 it begs the question, why?  What does the
 leadership think of the results of this survey?  Does it think it's time
 to reconsider the amount of effort put into -betterC?


Since -betterC is done, it's not like we can go back in time and take a 
different fork in the road. We cannot reconsider that effort.

28% of D users using it is quite a nice return on the little time invested in 
it. It also provides an effective answer to those who want to use D without GC 
and the runtime library, which was a constant issue.

I myself have found betterC very handy for writing tiny utilities that used to 
be in C. It's well suited for use in embedded systems.
Oct 19 2019
parent reply welkam <wwwelkam gmail.com> writes:
On Sunday, 20 October 2019 at 06:01:23 UTC, Walter Bright wrote:

 On 10/16/2019 12:28 PM, H. S. Teoh wrote:

 Given how much time and effort has been poured
 into -betterC recently,


 It wasn't that much. It was mainly turning some things off. I 
 probably spent more time documenting it, writing an article, 
 and doing a presentation on it than implementation.


I think its very important that this was said and I think it 
should be repeated in the future. Too many people incorrectly 
estimate the cost of things and then come to the wrong conclusions
Oct 20 2019
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Oct 20, 2019 at 01:00:22PM +0000, welkam via Digitalmars-d wrote:

 On Sunday, 20 October 2019 at 06:01:23 UTC, Walter Bright wrote:

 On 10/16/2019 12:28 PM, H. S. Teoh wrote:

 Given how much time and effort has been poured into -betterC
 recently,


 
 It wasn't that much. It was mainly turning some things off. I
 probably spent more time documenting it, writing an article, and
 doing a presentation on it than implementation.


 I think its very important that this was said and I think it should be
 repeated in the future. Too many people incorrectly estimate the cost
 of things and then come to the wrong conclusions


And that is exactly why I said we need official statements on this sort
of things.  It's an important part of communicating with the community.


T

-- 
A computer doesn't mind if its programs are put to purposes that don't match
their names. -- D. Knuth
Oct 20 2019
prev sibling next sibling parent 12345swordy <alexanderheistermann gmail.com> writes:
On Wednesday, 16 October 2019 at 17:40:42 UTC, Atila Neves wrote:

 On Wednesday, 16 October 2019 at 16:42:28 UTC, Rumbu wrote:

 On Tuesday, 15 October 2019 at 13:09:15 UTC, Mike Parker wrote:

 [...]


 I will put this here: 
 https://rawgit.com/wilzbach/state-of-d/master/report.html

 [...]


 Which parts of that survey would you like the vision to include?


First class tuples for me personally.

As a side note, we really need to start discussing the current 
status of "alias this". Multi "alias this" isn't implemented and 
walter is now thinking that it is a bad idea in general. He want 
structs to be implemented via component approach rather then 
using "alias this". If that were the case then the D language 
needs to  implement custom implicit conversions for 
structs/classes as implicit conversions are provided by "alias 
this". We can implemented it with strict rules to avoid the 
nightmare scenario that is c++(Opt-in rather then Opt-out).

-Alex
Oct 16 2019
prev sibling parent reply Rumbu <rumbu rumbu.ro> writes:
On Wednesday, 16 October 2019 at 17:40:42 UTC, Atila Neves wrote:

 On Wednesday, 16 October 2019 at 16:42:28 UTC, Rumbu wrote:

 On Tuesday, 15 October 2019 at 13:09:15 UTC, Mike Parker wrote:

 [...]


 I will put this here: 
 https://rawgit.com/wilzbach/state-of-d/master/report.html

 [...]


 Which parts of that survey would you like the vision to include?


I already said that I don't endorse the list entirely, so my 
personal opinion is irrelevant, lost somewhere between the 
responses on the survey.

But if you insist, I am personally disappointed about dub, phobos 
organization and function names, missing features, IDE 
integration, range syntax, OOP considered as a second-hand 
citizen.

On the other hand, before include anything else in the vision, I 
would like to see the language finished according to the 
specification (shared, cent, ucent)
Oct 16 2019
parent reply Atila Neves <atila.neves gmail.com> writes:
On Wednesday, 16 October 2019 at 18:34:01 UTC, Rumbu wrote:

 On Wednesday, 16 October 2019 at 17:40:42 UTC, Atila Neves 
 wrote:

 On Wednesday, 16 October 2019 at 16:42:28 UTC, Rumbu wrote:

 On Tuesday, 15 October 2019 at 13:09:15 UTC, Mike Parker 
 wrote:

 [...]


 I will put this here: 
 https://rawgit.com/wilzbach/state-of-d/master/report.html

 [...]


 Which parts of that survey would you like the vision to 
 include?


 I already said that I don't endorse the list entirely, so my 
 personal opinion is irrelevant, lost somewhere between the 
 responses on the survey.

 But if you insist, I am personally disappointed about dub, 
 phobos organization and function names, missing features, IDE 
 integration, range syntax, OOP considered as a second-hand 
 citizen.


IDE integration seems to be a common refrain. I'm trying to 
understand what it is people need here by asking questions.

What is it about OOP in D that you find lacking?

Could you please expand on what you mean about "range syntax"?
Oct 17 2019
next sibling parent bachmeier <no spam.net> writes:
On Thursday, 17 October 2019 at 12:51:17 UTC, Atila Neves wrote:


 IDE integration seems to be a common refrain. I'm trying to 
 understand what it is people need here by asking questions.


I had promised Andrei about six months ago that I would lead an 
effort to formalize and make decisions about what needs to be 
done to make Dub a first-class tool. The plan was to allow anyone 
to file an issue in a Git repo. All of that information would 
then be turned into something resembling a DIP.

Personal issues have to this point derailed that plan, but maybe 
that is a better way to proceed versus vague discussions on a 
mailing list that will soon be out of sight and out of mind. 
There is not much useful information (particularly in terms of 
concrete suggestions for how to proceed) in mailing list 
discussions.
Oct 17 2019
prev sibling parent reply Rumbu <rumbu rumbu.ro> writes:
On Thursday, 17 October 2019 at 12:51:17 UTC, Atila Neves wrote:

 On Wednesday, 16 October 2019 at 18:34:01 UTC, Rumbu wrote:

 On Wednesday, 16 October 2019 at 17:40:42 UTC, Atila Neves 
 wrote:

 On Wednesday, 16 October 2019 at 16:42:28 UTC, Rumbu wrote:

 On Tuesday, 15 October 2019 at 13:09:15 UTC, Mike Parker 
 wrote:

 [...]


 I will put this here: 
 https://rawgit.com/wilzbach/state-of-d/master/report.html

 [...]


 Which parts of that survey would you like the vision to 
 include?


 I already said that I don't endorse the list entirely, so my 
 personal opinion is irrelevant, lost somewhere between the 
 responses on the survey.

 But if you insist, I am personally disappointed about dub, 
 phobos organization and function names, missing features, IDE 
 integration, range syntax, OOP considered as a second-hand 
 citizen.


 IDE integration seems to be a common refrain. I'm trying to 
 understand what it is people need here by asking questions.

 What is it about OOP in D that you find lacking?


The general attitude "OOP is bad, let's use a struct instead". 
When the struct becomes not enough, the wheel is reinvented by 
workarounds like alias this, alias that.

The fact that objects are by default allocated using gc. There is 
no language construct to use RAII or heap application on objects. 
We had scope but it was deprecated.

The fact that class encapsulation is not fully implemented. 
Private is not so private.

Templated members of interfaces are not working as expected 
(implementors are not forced to implement the templated members).

Structs cannot implement interfaces (see next point for usage).


 Could you please expand on what you mean about "range syntax"?


Already discussed here:
https://forum.dlang.org/post/qo85so$2iaj$1 digitalmars.com
Oct 17 2019
parent reply Atila Neves <atila.neves gmail.com> writes:
On Thursday, 17 October 2019 at 15:24:09 UTC, Rumbu wrote:

 On Thursday, 17 October 2019 at 12:51:17 UTC, Atila Neves wrote:

 On Wednesday, 16 October 2019 at 18:34:01 UTC, Rumbu wrote:

 On Wednesday, 16 October 2019 at 17:40:42 UTC, Atila Neves 
 wrote:

 On Wednesday, 16 October 2019 at 16:42:28 UTC, Rumbu wrote:

 On Tuesday, 15 October 2019 at 13:09:15 UTC, Mike Parker 
 wrote:

 [...]













 What is it about OOP in D that you find lacking?


 The general attitude "OOP is bad, let's use a struct instead".


I don't know what to do about this. I prefer structs myself.


 The fact that objects are by default allocated using gc.


Only if you use `new`. And if you don't, then you'll have to 
worry about memory management.


 There is no language construct to use RAII or heap application 
 on objects. We had scope but it was deprecated.


That would be news to me. Even if `scope obj = new MyClass;` got 
deprecated, there are library solutions.


 The fact that class encapsulation is not fully implemented. 
 Private is not so private.


This is by design and isn't going to be changed. Classes can be 
in their own module if needed.


 Structs cannot implement interfaces (see next point for usage).


Also by design, unless you want something like Rust's traits or 
Haskell's typeclasses. But none of this is OOP.
Oct 17 2019
next sibling parent reply Rumbu <rumbu rumbu.ro> writes:
On Thursday, 17 October 2019 at 16:26:07 UTC, Atila Neves wrote:

 On Thursday, 17 October 2019 at 15:24:09 UTC, Rumbu wrote:

 On Thursday, 17 October 2019 at 12:51:17 UTC, Atila Neves 
 wrote:

 On Wednesday, 16 October 2019 at 18:34:01 UTC, Rumbu wrote:







 What is it about OOP in D that you find lacking?


 The general attitude "OOP is bad, let's use a struct instead".


 I don't know what to do about this. I prefer structs myself.


Wonderful. Then why ask in the first place?


 The fact that objects are by default allocated using gc.


 Only if you use `new`. And if you don't, then you'll have to 
 worry about memory management.


Thank you for stating the obvious.



 There is no language construct to use RAII or heap application 
 on objects. We had scope but it was deprecated.


 That would be news to me. Even if `scope obj = new MyClass;` 
 got deprecated, there are library solutions.


Library solution is not a *language construct*. You know what? 
Let's deprecate 'struct'. I bet that we can build a library 
solution instead. Too many keywords, 'switch' can be reduced to a 
library solution using just 'if's.


 The fact that class encapsulation is not fully implemented. 
 Private is not so private.


 This is by design and isn't going to be changed. Classes can be 
 in their own module if needed.


 Structs cannot implement interfaces (see next point for usage).


 Also by design, unless you want something like Rust's traits or 
 Haskell's typeclasses. But none of this is OOP.


Being by design, doesn't mean it's correct.

I'm starting to understand Chris.
Oct 17 2019
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Oct 17, 2019 at 04:50:15PM +0000, Rumbu via Digitalmars-d wrote:

 On Thursday, 17 October 2019 at 16:26:07 UTC, Atila Neves wrote:

 On Thursday, 17 October 2019 at 15:24:09 UTC, Rumbu wrote:

 On Thursday, 17 October 2019 at 12:51:17 UTC, Atila Neves wrote:

 What is it about OOP in D that you find lacking?
 


 
 The general attitude "OOP is bad, let's use a struct instead".


 
 I don't know what to do about this. I prefer structs myself.


 
 Wonderful. Then why ask in the first place?


He was just trying to understand where you're coming from. Doesn't mean
he has to agree with you.


[...]

 There is no language construct to use RAII or heap application on
 objects. We had scope but it was deprecated.


 
 That would be news to me. Even if `scope obj = new MyClass;` got
 deprecated, there are library solutions.


 
 Library solution is not a *language construct*. You know what? Let's
 deprecate 'struct'. I bet that we can build a library solution
 instead. Too many keywords, 'switch' can be reduced to a library
 solution using just 'if's.


Why does it have to be a language construct? Please explain.


[...]

 Structs cannot implement interfaces (see next point for usage).


 
 Also by design, unless you want something like Rust's traits or
 Haskell's typeclasses. But none of this is OOP.


 
 Being by design, doesn't mean it's correct.
 
 I'm starting to understand Chris.


If by "understand Chris" you mean "D leadership sucks because their
opinion differs from mine", then sure.

Seriously, people need to get a grip here.  It's one thing to ask for
more communication from the leadership, which IMO is a valid complaint
because people need to know where the leadership stands w.r.t. various
issues.  It's totally a different thing to react with negativity when
the leadership's stance differs from yours.  Why should they be forced
to adopt your opinion instead of their own?  It's not as though you're
paying them to do what you want. And after all, it's *their* project not
yours.

At the very least, you could explain your position and why you think
your way is better. But if you've already done that and the leadership
still does not agree, then you have two choices: (1) swallow your pride
and accept the leadership's decision, or (2) understand that D is not
your pet project and since it doesn't match what you want, perhaps
you'll be happier somewhere else.

//

I seriously don't understand why people continue staying around
poisoning the well when it's clear that things will likely *never* go
their way, and that they would be much happier elsewhere.  If you don't
like the way things are going, and speaking up didn't convince anybody,
then well, this is an open source project, fork the code and do it your
way. See if it works out better. Maybe once you've garnered a larger
following from your great ideas, you can come back with solid proof that
your way is better, and then the leadership might be convinced to go
that way too.  Or just give up and realize D is not for you, and go join
the Rust community or something.

But why stay around just for the sake of complaining?  I mean,
personally I don't particularly like Java, but I don't go sticking my
nose in the Java forums and badmouth Java leadership and complain about
why Java sucks and why everyone else is stupid because they think Java
is great.  Well hello, they are on the Java forums *because* they think
Java is great, so if I don't agree with them, then it's time to move on
to something else (like D :-P) where I'll be much happier.  There's
really no reason to stick around if you're really that unhappy with the
way things are going.


T

-- 
MACINTOSH: Most Applications Crash, If Not, The Operating System Hangs
Oct 17 2019
next sibling parent welkam <wwwelkam gmail.com> writes:
On Thursday, 17 October 2019 at 17:56:03 UTC, H. S. Teoh wrote:

 wall of text


I think you fired prematurely. While his attitude was not right 
for constructive dialog neither your post. It feels like you hold 
something in until you couldn't anymore.
Oct 17 2019
prev sibling next sibling parent reply Rumbu <rumbu rumbu.ro> writes:
On Thursday, 17 October 2019 at 17:56:03 UTC, H. S. Teoh wrote:

 On Thu, Oct 17, 2019 at 04:50:15PM +0000, Rumbu via 
 Digitalmars-d wrote:

 On Thursday, 17 October 2019 at 16:26:07 UTC, Atila Neves 
 wrote:

 On Thursday, 17 October 2019 at 15:24:09 UTC, Rumbu wrote:

 On Thursday, 17 October 2019 at 12:51:17 UTC, Atila Neves 
 wrote:

 What is it about OOP in D that you find lacking?
 


 
 The general attitude "OOP is bad, let's use a struct 
 instead".


 
 I don't know what to do about this. I prefer structs myself.


 
 Wonderful. Then why ask in the first place?


 He was just trying to understand where you're coming from. 
 Doesn't mean he has to agree with you.


I already stated that my opinion is irrelevant and suggested to 
take the survey as starting point for the Vision. Why ask about 
an opinion if you really don't care? Just to make me feel better 
for ten seconds? Wow, I appreciate.


 [...]

 There is no language construct to use RAII or heap 
 application on objects. We had scope but it was deprecated.


 
 That would be news to me. Even if `scope obj = new MyClass;` 
 got deprecated, there are library solutions.


 
 Library solution is not a *language construct*. You know what? 
 Let's deprecate 'struct'. I bet that we can build a library 
 solution instead. Too many keywords, 'switch' can be reduced 
 to a library solution using just 'if's.


 Why does it have to be a language construct? Please explain.


Because library solutions are workarounds and don't highlight any 
language design commitment. Using library solutions, I can make D 
look like Brainfuck if I insist. But this doesn't mean that D is 
Brainfuck. Keep in mind that the original question was why I 
consider OOP a second hand citizen in D language. I fact the 
outcome of the discussion does nothing else than strongly support 
my opinion: I need a library solution to do OOP in D.


 I'm starting to understand Chris.


 If by "understand Chris" you mean "D leadership sucks because 
 their opinion differs from mine", then sure.


No, no, no. I understand Chris' frustration. I don't want the 
management to agree with me. I want the management to not 
simulate any interest in my opinion. Because we loose both 
valuable time: me explaining the zillionth time the same thing 
and management disagreeing.


 Seriously, people need to get a grip here.  It's one thing to 
 ask for more communication from the leadership, which IMO is a 
 valid complaint because people need to know where the 
 leadership stands w.r.t. various issues.  It's totally a 
 different thing to react with negativity when the leadership's 
 stance differs from yours.  Why should they be forced to adopt 
 your opinion instead of their own?  It's not as though you're 
 paying them to do what you want. And after all, it's *their* 
 project not yours.
 At the very least, you could explain your position and why you 
 think your way is better.


I explained it too many times in too many posts during the last 7 
years. I won't repeat myself.


 But if you've already done that and the leadership still does 
 not agree, then you have two choices: (1) swallow your pride 
 and accept the leadership's decision, or (2) understand that D 
 is not your pet project and since it doesn't match what you 
 want, perhaps you'll be happier somewhere else.


Already choose (1). That's the difference between me an Chris. 
Probably he is younger, I'm too old to have any pride :)


 I seriously don't understand why people continue staying around 
 poisoning the well when it's clear that things will likely 
 *never* go their way, and that they would be much happier 
 elsewhere.  If you don't like the way things are going, and 
 speaking up didn't convince anybody, then well, this is an open 
 source project, fork the code and do it your way. See if it 
 works out better. Maybe once you've garnered a larger following 
 from your great ideas, you can come back with solid proof that 
 your way is better, and then the leadership might be convinced 
 to go that way too.  Or just give up and realize D is not for 
 you, and go join the Rust community or something.

 But why stay around just for the sake of complaining?  I mean, 
 personally I don't particularly like Java, but I don't go 
 sticking my nose in the Java forums and badmouth Java 
 leadership and complain about why Java sucks and why everyone 
 else is stupid because they think Java is great.  Well hello, 
 they are on the Java forums *because* they think Java is great, 
 so if I don't agree with them, then it's time to move on to 
 something else (like D :-P) where I'll be much happier.  
 There's really no reason to stick around if you're really that 
 unhappy with the way things are going.


 T


I am not complaining, I sincerely don't care anymore. But if I 
see that there is some hope, I will not hesitate to spice things 
up. Because, believe it or not, I like D, but I don't like how D 
transformed in the last years.

In fact, I stopped complaining 2 years ago when my involvement in 
D stopped also. I just came back these day because dub/dmd fucked 
up again my decimal library and entered in the forums to see 
what's going on: https://github.com/rumbu13/decimal/issues/8

I reopened a bugzilla 
(https://forum.dlang.org/thread/bug-19432-3 https.issues.dlang.org%2F) and
happened Atila's post.

Sorry for polluting these discussions, it will not happen again. 
See you in 2 years. Or if you miss me, fuck up my decimal library 
again.
Oct 17 2019
next sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Thursday, 17 October 2019 at 18:38:31 UTC, Rumbu wrote:

 On Thursday, 17 October 2019 at 17:56:03 UTC, H. S. Teoh wrote:

 On Thu, Oct 17, 2019 at 04:50:15PM +0000, Rumbu via 
 Digitalmars-d wrote:

 On Thursday, 17 October 2019 at 16:26:07 UTC, Atila Neves 
 wrote:

 On Thursday, 17 October 2019 at 15:24:09 UTC, Rumbu wrote:

 On Thursday, 17 October 2019 at 12:51:17 UTC, Atila Neves 
 wrote:

 What is it about OOP in D that you find lacking?
 


 
 The general attitude "OOP is bad, let's use a struct 
 instead".


 
 I don't know what to do about this. I prefer structs myself.


 
 Wonderful. Then why ask in the first place?


 He was just trying to understand where you're coming from. 
 Doesn't mean he has to agree with you.


 I already stated that my opinion is irrelevant and suggested to 
 take the survey as starting point for the Vision. Why ask about 
 an opinion if you really don't care? Just to make me feel 
 better for ten seconds? Wow, I appreciate.


I definitely care about your opinion. I'm sorry if it came across 
otherwise. I asked because I wanted to know what your problems 
with OOP in D are, and to know if anything can be done to 
mitigate or eliminate them.


 strongly support my opinion: I need a library solution to do 
 OOP in D.


I don't understand what you mean by this. What is it about OOP in 
D now that you can't get done without a library solution? And why 
are library solutions insufficient for those purposes?
Oct 18 2019
parent reply Max Samukha <maxsamukha gmail.com> writes:
On Friday, 18 October 2019 at 16:10:31 UTC, Atila Neves wrote:


 I don't understand what you mean by this. What is it about OOP 
 in D now that you can't get done without a library solution? 
 And why are library solutions insufficient for those purposes?


One cringeworthy problem with D's implementation of interfaces 
and classes is how D resolves method conflicts. Conflicting 
interface methods are silently collapsed into one implementation, 
which seems to be by design and is definitely incorrect.

interface Display {
   void fmt();
}

interface Debug {
   void fmt();
}

class C: Display, Debug {
   override fmt() {  } // implements both interfaces
}

At the very least, this should be an ambiguity error. Some
Oct 19 2019
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Oct 19, 2019 at 03:55:38PM +0000, Max Samukha via Digitalmars-d wrote:
[...]

 One cringeworthy problem with D's implementation of interfaces and
 classes is how D resolves method conflicts. Conflicting interface
 methods are silently collapsed into one implementation, which seems to
 be by design and is definitely incorrect.
 
 interface Display {
   void fmt();
 }
 
 interface Debug {
   void fmt();
 }
 
 class C: Display, Debug {
   override fmt() {  } // implements both interfaces
 }
 
 At the very least, this should be an ambiguity error. Some languages



IMO, you should file a bug for this one.


T

-- 
"If you're arguing, you're losing." -- Mike Thomas
Oct 19 2019
parent Max Samukha <maxsamukha gmail.com> writes:
On Saturday, 19 October 2019 at 17:18:34 UTC, H. S. Teoh wrote:


 IMO, you should file a bug for this one.


IIRC, I did years ago. I'll try to find it.
Oct 20 2019
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 19 October 2019 at 15:55:38 UTC, Max Samukha wrote:

 One cringeworthy problem with D's implementation of interfaces 
 and classes is how D resolves method conflicts. Conflicting 
 interface methods are silently collapsed into one 
 implementation, which seems to be by design


I don't see anything about it in the spec... I wonder if this is 
legitimately by design or just a plain oversight for all these 
years.
Oct 19 2019
parent Exil <Exil gmall.com> writes:
On Saturday, 19 October 2019 at 17:29:25 UTC, Adam D. Ruppe wrote:

 On Saturday, 19 October 2019 at 15:55:38 UTC, Max Samukha wrote:

 One cringeworthy problem with D's implementation of interfaces 
 and classes is how D resolves method conflicts. Conflicting 
 interface methods are silently collapsed into one 
 implementation, which seems to be by design


 I don't see anything about it in the spec... I wonder if this 
 is legitimately by design or just a plain oversight for all 
 these years.


Looking at bugzilla there's a lot of issues related with multiple 
interfaces.

Found one that is similar to this one: 
https://issues.dlang.org/show_bug.cgi?id=4435

You shouldn't be able to make an ambiguous call like that to 
begin with.
Oct 19 2019
prev sibling parent reply Meta <jared771 gmail.com> writes:
On Saturday, 19 October 2019 at 15:55:38 UTC, Max Samukha wrote:

 On Friday, 18 October 2019 at 16:10:31 UTC, Atila Neves wrote:


 I don't understand what you mean by this. What is it about OOP 
 in D now that you can't get done without a library solution? 
 And why are library solutions insufficient for those purposes?


 One cringeworthy problem with D's implementation of interfaces 
 and classes is how D resolves method conflicts. Conflicting 
 interface methods are silently collapsed into one 
 implementation, which seems to be by design and is definitely 
 incorrect.

 interface Display {
   void fmt();
 }

 interface Debug {
   void fmt();
 }

 class C: Display, Debug {
   override fmt() {  } // implements both interfaces
 }

 At the very least, this should be an ambiguity error. Some 



It's not a defect. Interfaces have no state, so it doesn't matter 
which is called. Java does the same thing.
Oct 19 2019
next sibling parent reply Meta <jared771 gmail.com> writes:
On Saturday, 19 October 2019 at 22:14:55 UTC, Meta wrote:

 On Saturday, 19 October 2019 at 15:55:38 UTC, Max Samukha wrote:

 On Friday, 18 October 2019 at 16:10:31 UTC, Atila Neves wrote:


 I don't understand what you mean by this. What is it about 
 OOP in D now that you can't get done without a library 
 solution? And why are library solutions insufficient for 
 those purposes?


 One cringeworthy problem with D's implementation of interfaces 
 and classes is how D resolves method conflicts. Conflicting 
 interface methods are silently collapsed into one 
 implementation, which seems to be by design and is definitely 
 incorrect.

 interface Display {
   void fmt();
 }

 interface Debug {
   void fmt();
 }

 class C: Display, Debug {
   override fmt() {  } // implements both interfaces
 }

 At the very least, this should be an ambiguity error. Some 



 It's not a defect. Interfaces have no state, so it doesn't 
 matter which is called. Java does the same thing.


To work around this, you can use the "non-virtual interface" 
pattern (there are probably other ways; this is just what comes 
to mind):

import std.stdio;

interface Display
{
     protected void displayFmt();
     final void fmt() { displayFmt(); }
}

interface Debug
{
     protected void debugFmt();
     final void fmt() { debugFmt(); }
}

class Test: Display, Debug
{
     override void displayFmt() { writeln("inside Display.fmt"); }
     override void debugFmt() { writeln("inside Debug.fmt"); }
}

void main()
{
     Display dsp = new Test();
     Debug dbg = new Test();
     dsp.fmt();
     dbg.fmt();
}
Oct 19 2019
parent Max Samukha <maxsamukha gmail.com> writes:
On Saturday, 19 October 2019 at 23:09:11 UTC, Meta wrote:

 void main()
 {
     Display dsp = new Test();
     Debug dbg = new Test();
     dsp.fmt();
     dbg.fmt();
 }


You can't do that if the interfaces come from third parties. 
There is a half-working hack using nested classes, but it is 
obviously inadequate:

interface A {
     void foo();
}

interface B {
     void foo();
}

class C: A {
     private final class _B: B {
         override void foo() {
             this.outer.bFoo();
         }
     }

     private _B _b;
     final B b() {
         return _b;
     }
     alias b this;

     this() {
         _b = new _B();
     }

     import std.stdio;
     override void foo() {
         writeln("A.foo");
     }

     void bFoo() {
         writeln("B.foo");
     }
}


class D: C {
}

void main() {
     auto c = new C;
     // auto c = new D; // won't work because of broken 'alias 
this'
     A a = c;
     B b = c;

     a.foo(); // "A.foo"
     b.foo(); // "B.foo"
}
Oct 20 2019
prev sibling parent reply Max Samukha <maxsamukha gmail.com> writes:
On Saturday, 19 October 2019 at 22:14:55 UTC, Meta wrote:


 It's not a defect. Interfaces have no state, so it doesn't 
 matter which is called. Java does the same thing.


What do you mean by 'have no state'? If Java does the same thing, 
it does it wrong. Nominal typing is all about avoiding structural 
conflicts. Members coming from different nominal types should not 
be conflated.
Oct 20 2019
parent reply Meta <jared771 gmail.com> writes:
On Sunday, 20 October 2019 at 09:31:34 UTC, Max Samukha wrote:

 On Saturday, 19 October 2019 at 22:14:55 UTC, Meta wrote:


 It's not a defect. Interfaces have no state, so it doesn't 
 matter which is called. Java does the same thing.


 What do you mean by 'have no state'? If Java does the same 
 thing, it does it wrong. Nominal typing is all about avoiding 
 structural conflicts. Members coming from different nominal 
 types should not be conflated.


Interfaces in D do not have any state, i.e., they're not allowed 
to declare member variables that implementing classes inherit, 
and they don't define any implementation for implementing classes 
to inherit - they just define the interface (this has recently 
changed in Java now that interfaces can define methods with a 
default implementation, thus Java now provides a way to 
disambiguate if two different interfaces declare default methods 
with the same name).

Because classes do not inherit any state or implementation from 
interfaces, if you have, say, the following class:

class ImplementsBoth: Display, Debug { void fmt(){} }

And you do `new ImplementsBoth().fmt()`, it really doesn't matter 
whether the fmt you're calling is Display's fmt, or Debug's, 
because there is no interface state or inherited implementation 
that would change fmt's behavior by calling one or the other.

The fact that interfaces carry no state or default implementaion 
is also why they don't have the diamond inheritance problem that 
C++'s multiple inheritance can cause.

So semantically, collapsing Display.fmt and Debug.fmt into one is 
perfectly valid. I agree it might be nice to allow disambiguating 
in certain cases, but that would be an enhancement, not a bug.

https://en.m.wikipedia.org/wiki/Multiple_inheritance#The_diamond_problem
Oct 20 2019
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Sunday, 20 October 2019 at 17:11:27 UTC, Meta wrote:

 On Sunday, 20 October 2019 at 09:31:34 UTC, Max Samukha wrote:

 [...]


 Interfaces in D do not have any state, i.e., they're not 
 allowed to declare member variables that implementing classes 
 inherit, and they don't define any implementation for 
 implementing classes to inherit - they just define the 
 interface (this has recently changed in Java now that 
 interfaces can define methods with a default implementation, 
 thus Java now provides a way to disambiguate if two different 
 interfaces declare default methods with the same name).

 [...]


They don't carry state, but they surely carry semantics hence why 
some languages allow to clarify the implementations.

Because passing implementation B to a method expecting 
implementation A can lead to hard to track down errors.
Oct 20 2019
parent reply Meta <jared771 gmail.com> writes:
On Sunday, 20 October 2019 at 17:34:17 UTC, Paulo Pinto wrote:

 On Sunday, 20 October 2019 at 17:11:27 UTC, Meta wrote:

 On Sunday, 20 October 2019 at 09:31:34 UTC, Max Samukha wrote:

 [...]


 Interfaces in D do not have any state, i.e., they're not 
 allowed to declare member variables that implementing classes 
 inherit, and they don't define any implementation for 
 implementing classes to inherit - they just define the 
 interface (this has recently changed in Java now that 
 interfaces can define methods with a default implementation, 
 thus Java now provides a way to disambiguate if two different 
 interfaces declare default methods with the same name).

 [...]


 They don't carry state, but they surely carry semantics hence 
 why some languages allow to clarify the implementations.

 Because passing implementation B to a method expecting 
 implementation A can lead to hard to track down errors.


I'm not saying that allowing to differentiate between 
implementations would be worthless, just that it's not a bug that 
D collapses them into 1 in the implementing class.
Oct 20 2019
next sibling parent reply Max Samukha <maxsamukha gmail.com> writes:
On Sunday, 20 October 2019 at 17:46:07 UTC, Meta wrote:


 I'm not saying that allowing to differentiate between 
 implementations would be worthless, just that it's not a bug 
 that D collapses them into 1 in the implementing class.


I still do not follow why the diamond problem and the lack of 
data members is relevant. For me, it is not different from:

struct A {
     int x;
}

struct B {
     int x;
}

Both types are isomorphic to int, but we still consider them 
distinct types and x's inside them unrelated, even though they 
are typed and named identically.
Oct 20 2019
next sibling parent reply Alex <sascha.orlov gmail.com> writes:
On Sunday, 20 October 2019 at 19:58:28 UTC, Max Samukha wrote:

 On Sunday, 20 October 2019 at 17:46:07 UTC, Meta wrote:


 I'm not saying that allowing to differentiate between 
 implementations would be worthless, just that it's not a bug 
 that D collapses them into 1 in the implementing class.


 I still do not follow why the diamond problem and the lack of 
 data members is relevant. For me, it is not different from:

 struct A {
     int x;
 }

 struct B {
     int x;
 }

 Both types are isomorphic to int, but we still consider them 
 distinct types and x's inside them unrelated, even though they 
 are typed and named identically.


This is interesting. Can you provide a source of why the nominal 
type system is a contradiction to the current approach?
I mean, currently I can follow Meta more:
If you have an object implementing both, Debug and Display, then 
the class has to implement foo. And if it does, it can be handled 
by functions both handling Debug and Display. The ambiguity is 
solved at this level:

´´´
interface De{ void foo(); }
interface Di { void foo(); }
class C : De, Di{ override void foo(){} }
void main()
{
     auto c = new C();
     //c.fun1; //fails to compile, as you would expect
     De de = c;
     Di di = c;
     de.fun1;
     di.fun1;
}
auto fun1(De de){ de.foo; }
auto fun1(Di di){ di.foo; }
´´´

So, for sure, if you want to have different overloads for 
different interfaces, then, they can't go into the class of C. 
But there is no need to do so.
Oct 21 2019
parent reply IGotD- <nise nise.com> writes:
On Monday, 21 October 2019 at 10:46:40 UTC, Alex wrote:

 This is interesting. Can you provide a source of why the 
 nominal type system is a contradiction to the current approach?
 I mean, currently I can follow Meta more:
 If you have an object implementing both, Debug and Display, 
 then the class has to implement foo. And if it does, it can be 
 handled by functions both handling Debug and Display. The 
 ambiguity is solved at this level:

 ´´´
 interface De{ void foo(); }
 interface Di { void foo(); }
 class C : De, Di{ override void foo(){} }
 void main()
 {
     auto c = new C();
     //c.fun1; //fails to compile, as you would expect
     De de = c;
     Di di = c;
     de.fun1;
     di.fun1;
 }
 auto fun1(De de){ de.foo; }
 auto fun1(Di di){ di.foo; }
 ´´´

 So, for sure, if you want to have different overloads for 
 different interfaces, then, they can't go into the class of C. 
 But there is no need to do so.


I don't understand why multiple inheritance is allowed except 
this lethal "diamond problem" has been implemented in a language 
which would seem to be a fair limitation. I have programmed C++ 
for decades and I have never used virtual inheritance when 
diamond like inheritance has happened, zero times. Also I have 
never encountered I had to rearrange the inheritance in order to 
avoid the diamond problem. However, I use multiple inheritance 
often in terms of that one class inherits from several other 
classes but the inheritance is fairly flat and the inherited 
classes never have any common parent class.
Oct 22 2019
parent Alex <sascha.orlov gmail.com> writes:
On Tuesday, 22 October 2019 at 14:37:25 UTC, IGotD- wrote:

 I don't understand why multiple inheritance is allowed except 
 this lethal "diamond problem" has been implemented in a 
 language which would seem to be a fair limitation. I have 
 programmed C++ for decades and I have never used virtual 
 inheritance when diamond like inheritance has happened, zero 
 times. Also I have never encountered I had to rearrange the 
 inheritance in order to avoid the diamond problem. However, I 
 use multiple inheritance often in terms of that one class 
 inherits from several other classes but the inheritance is 
 fairly flat and the inherited classes never have any common 
 parent class.


This one belongs to the section of "why is something done, in the 
way it is done". I'm the wrong addressee here.
I was asking, how the theory of the nominal type system is 
contradicting the existing solution.
Oct 22 2019
prev sibling parent Meta <jared771 gmail.com> writes:
On Sunday, 20 October 2019 at 19:58:28 UTC, Max Samukha wrote:

 On Sunday, 20 October 2019 at 17:46:07 UTC, Meta wrote:


 I'm not saying that allowing to differentiate between 
 implementations would be worthless, just that it's not a bug 
 that D collapses them into 1 in the implementing class.


 I still do not follow why the diamond problem and the lack of 
 data members is relevant. For me, it is not different from:

 struct A {
     int x;
 }

 struct B {
     int x;
 }

 Both types are isomorphic to int, but we still consider them 
 distinct types and x's inside them unrelated, even though they 
 are typed and named identically.


That's not really a correct analogy, because A and B are carrying 
mutable state. As I said, interfaces carry no state. Let's 
imagine that they could:

interface A { int n; void setN(int n); int getN(); }
interface B { int n; void setN(int n); int getN(); }

class C: A, B
{
     //Does super refer to A here, or B?
     override void setN(int n) { this.n = n; }
     override void getN() { return this.n; }
}

If this was possible in the language, it would become VERY 
important to be able to specify which interface you were 
implementing getN and setN for, because now this code would do 
something different depending on whether `this.n` refers to A's n 
member or B's:

void takesA(A a) { writeln("Got an A with n = ", a.getN()); }

void takesB(B b) { writeln("Got a B with n = ", b.getN()); }

C c = new C();
c.setN(10); //Is A.n set or B.n?

//What do these methods print? What should they?
takesA(c);
takesB(c);

This should hopefully make more clear why the fact that 
interfaces carry no mutable state means that it doesn't matter 
whether C.setN / C.getN refers to C.A.getN/setN or C.B.getN/setN.

Now, as has been pointed out, A's getN / setN methods may carry a 
different semantic meaning from B's (or, to go back to the 
original example, Display.fmt may _mean_ something very different 
from Debug.fmt). In that light, it would probably be useful to be 
able to tell the compiler that you want a different 
implementation for one interface method vs. the other, even 
though they have the exact same method signatures.
Oct 21 2019
prev sibling parent reply Exil <Exil gmall.com> writes:
On Sunday, 20 October 2019 at 17:46:07 UTC, Meta wrote:

 On Sunday, 20 October 2019 at 17:34:17 UTC, Paulo Pinto wrote:

 On Sunday, 20 October 2019 at 17:11:27 UTC, Meta wrote:

 On Sunday, 20 October 2019 at 09:31:34 UTC, Max Samukha wrote:

 [...]


 Interfaces in D do not have any state, i.e., they're not 
 allowed to declare member variables that implementing classes 
 inherit, and they don't define any implementation for 
 implementing classes to inherit - they just define the 
 interface (this has recently changed in Java now that 
 interfaces can define methods with a default implementation, 
 thus Java now provides a way to disambiguate if two different 
 interfaces declare default methods with the same name).

 [...]


 They don't carry state, but they surely carry semantics hence 
 why some languages allow to clarify the implementations.

 Because passing implementation B to a method expecting 
 implementation A can lead to hard to track down errors.


 I'm not saying that allowing to differentiate between 
 implementations would be worthless, just that it's not a bug 
 that D collapses them into 1 in the implementing class.


Sure, one can argue that it's not a bug, auto-decoding isn't a 
bug, in fact it was very much intentional. But I think we'd all 
be better off without it. The way it is implemented can lead to 
bugs quite easily. Since it picks whichever one based on order. 
None of this is obvious. Rationale like your's is why the bug 
reports like this one remain open for 9+ years and it never gets 
fixed. It's not a bug it's a feature! Therefore any change is an 
enhancement and requires a DIP.
Oct 20 2019
parent reply Meta <jared771 gmail.com> writes:
On Sunday, 20 October 2019 at 20:41:01 UTC, Exil wrote:

 Sure, one can argue that it's not a bug, auto-decoding isn't a 
 bug, in fact it was very much intentional. But I think we'd all 
 be better off without it. The way it is implemented can lead to 
 bugs quite easily. Since it picks whichever one based on order.


Show me a concrete example. Also, there is no "picking" of which 
interface method is implemented. Both are implemented by the same 
method.


 None of this is obvious.


I agree. I was surprised as well when I first learned about this, 
but that doesn't mean it's incorrect.


 Rationale like your's is why the bug reports like this one 
 remain open for 9+ years and it never gets fixed. It's not a 
 bug it's a feature! Therefore any change is an enhancement and 
 requires a DIP.


There's this other language called Java that you may have heard 
of, that does things the exact same way, and the many millions of 
programmers that use that language seem to have no issue with 
this behaviour. I've already agreed that it would be worth having 
a way to write a different implementation for different 
interfaces with the same method, but that is the very 
*definition* of an enhancement.
Oct 21 2019
parent reply Exil <Exil gmall.com> writes:
On Monday, 21 October 2019 at 12:34:14 UTC, Meta wrote:

 On Sunday, 20 October 2019 at 20:41:01 UTC, Exil wrote:

 Sure, one can argue that it's not a bug, auto-decoding isn't a 
 bug, in fact it was very much intentional. But I think we'd 
 all be better off without it. The way it is implemented can 
 lead to bugs quite easily. Since it picks whichever one based 
 on order.


 Show me a concrete example. Also, there is no "picking" of 
 which interface method is implemented. Both are implemented by 
 the same method.


interface OneThing {
     void foo(); // should do One thing
}

interface AnotherThing {
     void foo(); // do another thing
}

class A : OneThing, AnotherThing {
     override void foo() { }
}


void bar(OneThing o) {
    o.foo(); // do something unrelated to AnotherThing
}

void tar(AnotherThing a) {
    a.foo(); // do something unrelated to OneThing
}


void main() {
     A a = new A;

     bar(a);
     tar(a);
}


Your assumption is that just because the functions are named the 
same thing then they should do the exact same thing. Sure you can 
avoid naming conflict when you have to, but if you are using two 
libraries you didn't write then you can't make those kinds of 
decisions.



 None of this is obvious.


 I agree. I was surprised as well when I first learned about 
 this, but that doesn't mean it's incorrect.


Technically nothing is incorrect. Auto decoding isn't incorrect. 
If that's how you view things in coding, as black and white, you 
can make that same argument against virtually everything. 
Surprises lead to bugs. Surprises that differ from how the rest 
of the language operates are even bigger surprises. Those kind of 
surprises can take hours to try to figure out what is going 
wrong. If you have an ambiguous call you get an error. The 
compiler doesn't choose one based on which one was defined first.


 Rationale like your's is why the bug reports like this one 
 remain open for 9+ years and it never gets fixed. It's not a 
 bug it's a feature! Therefore any change is an enhancement and 
 requires a DIP.


 There's this other language called Java that you may have heard 
 of, that does things the exact same way, and the many millions 
 of programmers that use that language seem to have no issue 
 with this behaviour. I've already agreed that it would be worth 
 having a way to write a different implementation for different 
 interfaces with the same method, but that is the very 
 *definition* of an enhancement.


Java isn't exactly the best language to look at. It's usually 
people's first language and then they just stick with it cause 
it's what they know. If you want to look at Java as an example 
for why something should be the way it is. Java doesn't have 

allows you to override the functions separately.

You can call it whatever you want. It doesn't change the fact 
this will just stay the way it is for another 9 years because 
people would rather sweep it under the rug due to ambiguity than 
fix it. Sure it's an edge case, but there's so many places in D 
where edges like this have questionable implementations, they 
start to add up.
Oct 21 2019
parent reply Meta <jared771 gmail.com> writes:
On Monday, 21 October 2019 at 13:20:05 UTC, Exil wrote:

 On Monday, 21 October 2019 at 12:34:14 UTC, Meta wrote:

 On Sunday, 20 October 2019 at 20:41:01 UTC, Exil wrote:

 Sure, one can argue that it's not a bug, auto-decoding isn't 
 a bug, in fact it was very much intentional. But I think we'd 
 all be better off without it. The way it is implemented can 
 lead to bugs quite easily. Since it picks whichever one based 
 on order.


 Show me a concrete example. Also, there is no "picking" of 
 which interface method is implemented. Both are implemented by 
 the same method.


 interface OneThing {
     void foo(); // should do One thing
 }

 interface AnotherThing {
     void foo(); // do another thing
 }

 class A : OneThing, AnotherThing {
     override void foo() { }
 }


 void bar(OneThing o) {
    o.foo(); // do something unrelated to AnotherThing
 }

 void tar(AnotherThing a) {
    a.foo(); // do something unrelated to OneThing
 }


 void main() {
     A a = new A;

     bar(a);
     tar(a);
 }


 Your assumption is that just because the functions are named 
 the same thing then they should do the exact same thing.


You're talking about the semantic appropriateness of A.foo doing 
the same thing whether A is accessed through a reference to a 
OneThing or an AnotherThing. I'm talking about whether it is a 
bug or not, i.e., the correctness of the behaviour of the 
implementation from a theoretical perspective.

Compiler's don't examine your code for conformance to a given set 
of semantics; that's up to humans. The best they can do is check 
that your program is well-formed.
Oct 21 2019
parent reply Exil <Exil gmall.com> writes:
On Monday, 21 October 2019 at 13:44:16 UTC, Meta wrote:

 You're talking about the semantic appropriateness of A.foo 
 doing the same thing whether A is accessed through a reference 
 to a OneThing or an AnotherThing. I'm talking about whether it 
 is a bug or not, i.e., the correctness of the behaviour of the 
 implementation from a theoretical perspective.


No I'm not. Whether "foo" should do the same thing or not is 
irrelevant. I'm not talking about the semantics of it. I've used 
libraries where the same method name does different things. Under 
the right circumstances this is going to be true. Programming 
languages is a subset of written/spoken language, and English is 
full of ambiguities. With words having multiple meanings 
depending on what context they are used in.


 Compiler's don't examine your code for conformance to a given 
 set of semantics; that's up to humans. The best they can do is 
 check that your program is well-formed.


I'm talking about what is available to the user should they 
encounter this problem. There's no workaround to the problem, not 
an easy or clean one like one that can be easily implemented. 
Your arguing that no changes need to be made because Java does it 
that way. I don't agree with that at all, especially since it is 
Java. If that were the criteria for "correctness" we would not 
have operator overloading.
Oct 21 2019
parent Aliak <something something.com> writes:
On Monday, 21 October 2019 at 17:39:48 UTC, Exil wrote:

 On Monday, 21 October 2019 at 13:44:16 UTC, Meta wrote:

 [...]


 No I'm not. Whether "foo" should do the same thing or not is 
 irrelevant. I'm not talking about the semantics of it. I've 
 used libraries where the same method name does different 
 things. Under the right circumstances this is going to be true. 
 Programming languages is a subset of written/spoken language, 
 and English is full of ambiguities. With words having multiple 
 meanings depending on what context they are used in.

 [...]



So what are some solutions to this? How do you call the 
semantically correct one from inside foo?
Oct 21 2019
prev sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Thursday, 17 October 2019 at 18:38:31 UTC, Rumbu wrote:

 On Thursday, 17 October 2019 at 17:56:03 UTC, H. S. Teoh wrote:

 On Thu, Oct 17, 2019 at 04:50:15PM +0000, Rumbu via 
 Digitalmars-d wrote:

 On Thursday, 17 October 2019 at 16:26:07 UTC, Atila Neves 
 wrote:

 On Thursday, 17 October 2019 at 15:24:09 UTC, Rumbu wrote:

 On Thursday, 17 October 2019 at 12:51:17 UTC, Atila Neves 
 wrote:
 There is no language construct to use RAII or heap 
 application on objects. We had scope but it was 
 deprecated.










scope class Foo { ... } was always a bit weird and too narrow a 
feature. IMO it would have been better to allow aliases to 
storage classes as a general concept

class _Foo { ... }

alias Foo = scope _Foo;

which I have has to hack LDC to do for `__gshared`.


 That would be news to me. Even if `scope obj = new 
 MyClass;` got deprecated, there are library solutions.


 
 Library solution is not a *language construct*. You know 
 what? Let's deprecate 'struct'. I bet that we can build a 
 library solution instead. Too many keywords, 'switch' can be 
 reduced to a library solution using just 'if's.


 Why does it have to be a language construct? Please explain.


 Because library solutions are workarounds and don't highlight 
 any language design commitment. Using library solutions, I can 
 make D look like Brainfuck if I insist. But this doesn't mean 
 that D is Brainfuck. Keep in mind that the original question 
 was why I consider OOP a second hand citizen in D language. I 
 fact the outcome of the discussion does nothing else than 
 strongly support my opinion: I need a library solution to do 
 OOP in D.


What I think was lost in the chain is that it is entirely 
possible to do

auto foo = Structify!MyClass(args);

as a counterpart to

scope obj = new MyClass;
Oct 18 2019
prev sibling parent reply GreatSam4sure <greatsam4sure gmail.com> writes:
On Thursday, 17 October 2019 at 17:56:03 UTC, H. S. Teoh wrote:

 On Thu, Oct 17, 2019 at 04:50:15PM +0000, Rumbu via 
 Digitalmars-d wrote:

 On Thursday, 17 October 2019 at 16:26:07 UTC, Atila Neves 
 wrote:

 On Thursday, 17 October 2019 at 15:24:09 UTC, Rumbu wrote:

 On Thursday, 17 October 2019 at 12:51:17 UTC, Atila Neves 
 wrote:

 What is it about OOP in D that you find lacking?
 


 
 The general attitude "OOP is bad, let's use a struct 
 instead".


 
 I don't know what to do about this. I prefer structs myself.


 
 Wonderful. Then why ask in the first place?


 He was just trying to understand where you're coming from. 
 Doesn't mean he has to agree with you.


 [...]

 There is no language construct to use RAII or heap 
 application on objects. We had scope but it was deprecated.


 
 That would be news to me. Even if `scope obj = new MyClass;` 
 got deprecated, there are library solutions.


 
 Library solution is not a *language construct*. You know what? 
 Let's deprecate 'struct'. I bet that we can build a library 
 solution instead. Too many keywords, 'switch' can be reduced 
 to a library solution using just 'if's.


 Why does it have to be a language construct? Please explain.


 [...]

 Structs cannot implement interfaces (see next point for 
 usage).


 
 Also by design, unless you want something like Rust's traits 
 or Haskell's typeclasses. But none of this is OOP.


 
 Being by design, doesn't mean it's correct.
 
 I'm starting to understand Chris.


 If by "understand Chris" you mean "D leadership sucks because 
 their opinion differs from mine", then sure.

 Seriously, people need to get a grip here.  It's one thing to 
 ask for more communication from the leadership, which IMO is a 
 valid complaint because people need to know where the 
 leadership stands w.r.t. various issues.  It's totally a 
 different thing to react with negativity when the leadership's 
 stance differs from yours.  Why should they be forced to adopt 
 your opinion instead of their own?  It's not as though you're 
 paying them to do what you want. And after all, it's *their* 
 project not yours.

 At the very least, you could explain your position and why you 
 think your way is better. But if you've already done that and 
 the leadership still does not agree, then you have two choices: 
 (1) swallow your pride and accept the leadership's decision, or 
 (2) understand that D is not your pet project and since it 
 doesn't match what you want, perhaps you'll be happier 
 somewhere else.

 //

 I seriously don't understand why people continue staying around 
 poisoning the well when it's clear that things will likely 
 *never* go their way, and that they would be much happier 
 elsewhere.  If you don't like the way things are going, and 
 speaking up didn't convince anybody, then well, this is an open 
 source project, fork the code and do it your way. See if it 
 works out better. Maybe once you've garnered a larger following 
 from your great ideas, you can come back with solid proof that 
 your way is better, and then the leadership might be convinced 
 to go that way too.  Or just give up and realize D is not for 
 you, and go join the Rust community or something.

 But why stay around just for the sake of complaining?  I mean, 
 personally I don't particularly like Java, but I don't go 
 sticking my nose in the Java forums and badmouth Java 
 leadership and complain about why Java sucks and why everyone 
 else is stupid because they think Java is great.  Well hello, 
 they are on the Java forums *because* they think Java is great, 
 so if I don't agree with them, then it's time to move on to 
 something else (like D :-P) where I'll be much happier.  
 There's really no reason to stick around if you're really that 
 unhappy with the way things are going.


 T



Pls and pls. This thread is with a purpose.let keep the purpose.

Many thread in this forum done live to their purpose. We can open 
another to discuss the problem facing D

We all advocate for a new behaviour and character on D forums. 
Pls let this deviation stop right here. No more this unhappy 
outburst. Open a thread for that. We must not sound unfriendly in 
bearing our minds.we hurt D more when we do that.

Thanks for the understanding. A new wine must be put in a new 
bottle for this to go well.


Also feel deeply that Andrei resign not just because of family 
only but also because the hostility of the community to his 
leadership. This is my personal observation, I might be wrong, so 
don't quote me.


Let support Atila we all we have to get D where it suppose to be.


Atila on the other hands has to bring more unity and harmony to 
this community. In my own opinion that is the first step to being 
more adoption to D.


Our human relationship is little we must manage it well to grow 
big
Oct 17 2019
parent reply welkam <wwwelkam gmail.com> writes:
On Thursday, 17 October 2019 at 19:06:29 UTC, GreatSam4sure wrote:

 Our human relationship is little we must manage it well to grow 
 big


That requires for adults to behave like adults
Oct 17 2019
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 17 October 2019 at 19:19:01 UTC, welkam wrote:

 On Thursday, 17 October 2019 at 19:06:29 UTC, GreatSam4sure 
 wrote:

 Our human relationship is little we must manage it well to 
 grow big


 That requires for adults to behave like adults


Right.

Off-topic: https://youtu.be/f488uJAQgmw
Oct 17 2019
prev sibling next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 17 October 2019 at 16:50:15 UTC, Rumbu wrote:


 Also by design, unless you want something like Rust's traits 
 or Haskell's typeclasses. But none of this is OOP.


 Being by design, doesn't mean it's correct.

 I'm starting to understand Chris.


Private to the module *is* correct in D.

http://dlang.org/blog/2018/11/06/lost-in-translation-encapsulation/
Oct 17 2019
parent reply aliak <something something.com> writes:
On Thursday, 17 October 2019 at 18:00:39 UTC, Mike Parker wrote:

 On Thursday, 17 October 2019 at 16:50:15 UTC, Rumbu wrote:


 Also by design, unless you want something like Rust's traits 
 or Haskell's typeclasses. But none of this is OOP.


 Being by design, doesn't mean it's correct.

 I'm starting to understand Chris.


 Private to the module *is* correct in D.

 http://dlang.org/blog/2018/11/06/lost-in-translation-encapsulation/


That's debatable: 
https://github.com/aliak00/d-isms/blob/master/da-faq/06-access-levels.md
Oct 17 2019
parent reply drug <drug2004 bk.ru> writes:
On 10/17/19 11:48 PM, aliak wrote:

 On Thursday, 17 October 2019 at 18:00:39 UTC, Mike Parker wrote:

 On Thursday, 17 October 2019 at 16:50:15 UTC, Rumbu wrote:


 Also by design, unless you want something like Rust's traits or 
 Haskell's typeclasses. But none of this is OOP.


 Being by design, doesn't mean it's correct.

 I'm starting to understand Chris.


 Private to the module *is* correct in D.

 http://dlang.org/blog/2018/11/06/lost-in-translation-encapsulation/


 
 That's debatable: 
 https://github.com/aliak00/d-isms/blob/master/da-faq/06-access-levels.md


You complain that `doAmazingStuff` can access private members of class A 
if this function and this class are placed together in one module and 
continue complain that if you put that class in its own module then 
`doAmazingStuff` now cannot access private members of A and isn't a 
"first class" citizen of class A. Could you explain you position clearly?
Oct 18 2019
parent reply Aliak <something something.com> writes:
On Friday, 18 October 2019 at 07:56:26 UTC, drug wrote:

 On 10/17/19 11:48 PM, aliak wrote:

 On Thursday, 17 October 2019 at 18:00:39 UTC, Mike Parker 
 wrote:

 On Thursday, 17 October 2019 at 16:50:15 UTC, Rumbu wrote:


 [...]


 Private to the module *is* correct in D.

 http://dlang.org/blog/2018/11/06/lost-in-translation-encapsulation/


 
 That's debatable: 
 https://github.com/aliak00/d-isms/blob/master/da-faq/06-access-levels.md


 You complain that `doAmazingStuff` can access private members 
 of class A if this function and this class are placed together 
 in one module and continue complain that if you put that class 
 in its own module then `doAmazingStuff` now cannot access 
 private members of A and isn't a "first class" citizen of class 
 A. Could you explain you position clearly?


My position on what? No private access is the consequence of 
moving a function out of a module.
Oct 18 2019
parent reply drug <drug2004 bk.ru> writes:
On 10/18/19 5:37 PM, Aliak wrote:

 On Friday, 18 October 2019 at 07:56:26 UTC, drug wrote:

 On 10/17/19 11:48 PM, aliak wrote:

 On Thursday, 17 October 2019 at 18:00:39 UTC, Mike Parker wrote:

 On Thursday, 17 October 2019 at 16:50:15 UTC, Rumbu wrote:


 [...]


 Private to the module *is* correct in D.

 http://dlang.org/blog/2018/11/06/lost-in-translation-encapsulation/


 That's debatable: 
 https://github.com/aliak00/d-isms/blob/master/da-faq/06-access-levels.md


 You complain that `doAmazingStuff` can access private members of class 
 A if this function and this class are placed together in one module 
 and continue complain that if you put that class in its own module 
 then `doAmazingStuff` now cannot access private members of A and isn't 
 a "first class" citizen of class A. Could you explain you position 
 clearly?


 
 My position on what? No private access is the consequence of moving a 
 function out of a module.


  That's probably my misunderstanding but I think you took a bad example 
to show the problem.
You state that:
1) it is bad that `doAmazingWork` has private access to class A members 
if it is in one module with class A
2) it is bad that `doAmazingWork` has no private access to class A 
members if it is in an other module than class A

In my opinion these statement are contradictory
Oct 19 2019
parent reply Aliak <something something.com> writes:
On Saturday, 19 October 2019 at 07:45:14 UTC, drug wrote:

 On 10/18/19 5:37 PM, Aliak wrote:

 On Friday, 18 October 2019 at 07:56:26 UTC, drug wrote:

 On 10/17/19 11:48 PM, aliak wrote:

 On Thursday, 17 October 2019 at 18:00:39 UTC, Mike Parker 
 wrote:

 On Thursday, 17 October 2019 at 16:50:15 UTC, Rumbu wrote:


 [...]


 Private to the module *is* correct in D.

 http://dlang.org/blog/2018/11/06/lost-in-translation-encapsulation/


 That's debatable: 
 https://github.com/aliak00/d-isms/blob/master/da-faq/06-access-levels.md


 You complain that `doAmazingStuff` can access private members 
 of class A if this function and this class are placed 
 together in one module and continue complain that if you put 
 that class in its own module then `doAmazingStuff` now cannot 
 access private members of A and isn't a "first class" citizen 
 of class A. Could you explain you position clearly?


 
 My position on what? No private access is the consequence of 
 moving a function out of a module.


  That's probably my misunderstanding but I think you took a bad 
 example to show the problem.
 You state that:
 1) it is bad that `doAmazingWork` has private access to class A 
 members if it is in one module with class A
 2) it is bad that `doAmazingWork` has no private access to 
 class A members if it is in an other module than class A

 In my opinion these statement are contradictory


Oh. I see. Statement 1 is that it *can* be bad. And for statement 
2, I do not think i state anywhere that it’s bad? I can try and 
rephrase maybe? (Suggestions?)

Some languages have moduleprivate and privateprivate. If D had 
that then you could actually protect your objects, and if you 
wanted to allow non-state related variables to only the module 
you could do that too. So functions can access moduleprivate vars 
and do things that outside modules couldn’t and variables can be 
fully protected within a class if need be as well.
Oct 19 2019
parent reply drug <drug2004 bk.ru> writes:
On 10/19/19 2:10 PM, Aliak wrote:

 Oh. I see. Statement 1 is that it *can* be bad. And for statement 2, I 
 do not think i state anywhere that it’s bad? I can try and rephrase 
 maybe? (Suggestions?)
 
 Some languages have moduleprivate and privateprivate. If D had that then 
 you could actually protect your objects, and if you wanted to allow 
 non-state related variables to only the module you could do that too. So 
 functions can access moduleprivate vars and do things that outside 
 modules couldn’t and variables can be fully protected within a class if 
 need be as well.


I agree that in D having private to be in fact moduleprivate is unusual 
comparing to C++ for example. But is it really bad in practice?
Oct 19 2019
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Saturday, 19 October 2019 at 11:46:21 UTC, drug wrote:

 I agree that in D having private to be in fact moduleprivate is 
 unusual comparing to C++ for example.


In C++ you have no modules (modulo recent activity) and so the 
class is the only unit of encapsulation that there is apart from 
namespaces. In Java there you can only have a single class per 
module so module private and class private are the same thing 
(possibly modulo inner classes? idk I don't Java).

In D you can't not use modules _and_ you can have multiple 
declarations per module _and_ there is only one private (and no 
friend, or alternately everything in the modules are friends) so 
the line has to be drawn somewhere.


 But is it really bad in practice?


IME, no. If your module is big enough that you can't keep all of 
it in you head and you start calling implementation details of 
your classes _by accident_ then either:
a) name your implementation details so they stand out so you 
don't call by accident (e.g. a._something() )
b) split up your module into a package so that it fits in your 
head, this will (probably) cause you to not be able to call the 
implementation details at all, and will thus cause you to have to 
think about the organisation of you package (which is probably a 
good thing).
Oct 19 2019
parent reply Aliak <something something.com> writes:
On Saturday, 19 October 2019 at 12:23:36 UTC, Nicholas Wilson 
wrote:

 On Saturday, 19 October 2019 at 11:46:21 UTC, drug wrote:

 I agree that in D having private to be in fact moduleprivate 
 is unusual comparing to C++ for example.


 In C++ you have no modules (modulo recent activity) and so the 
 class is the only unit of encapsulation that there is apart 
 from namespaces. In Java there you can only have a single class 
 per module so module private and class private are the same 
 thing (possibly modulo inner classes? idk I don't Java).

 In D you can't not use modules _and_ you can have multiple 
 declarations per module _and_ there is only one private (and no 
 friend, or alternately everything in the modules are friends) 
 so the line has to be drawn somewhere.


 But is it really bad in practice?


 IME, no. If your module is big enough that you can't keep all 
 of it in you head and you start calling implementation details 
 of your classes _by accident_ then either:
 a) name your implementation details so they stand out so you 
 don't call by accident (e.g. a._something() )
 b) split up your module into a package so that it fits in your 
 head, this will (probably) cause you to not be able to call the 
 implementation details at all, and will thus cause you to have 
 to think about the organisation of you package (which is 
 probably a good thing).


Solution a is a convention. And solution b is fluffy. Neither are 
enforceable. But they are indeed things you can do to try and 
mitigate things. And it becomes exponentially harder to enforce 
conventional practices the bigger the code base. Unfortunately 
that’s only something you get to realize after enough experience 
in big code bases and in larger teams.
Oct 19 2019
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Saturday, 19 October 2019 at 13:45:37 UTC, Aliak wrote:

 On Saturday, 19 October 2019 at 12:23:36 UTC, Nicholas Wilson 
 wrote:

 IME, no. If your module is big enough that you can't keep all 
 of it in you head and you start calling implementation details 
 of your classes _by accident_ then either:
 a) name your implementation details so they stand out so you 
 don't call by accident (e.g. a._something() )
 b) split up your module into a package so that it fits in your 
 head, this will (probably) cause you to not be able to call 
 the implementation details at all, and will thus cause you to 
 have to think about the organisation of you package (which is 
 probably a good thing).


 Solution a is a convention.


Indeed.


 And solution b is fluffy.


How so? Also, you should probably be doing that anyway for 
different reasons.


 Neither are enforceable. But they are indeed things you can do 
 to try and mitigate things. And it becomes exponentially harder 
 to enforce conventional practices the bigger the code base. 
 Unfortunately that’s only something you get to realize after 
 enough experience in big code bases and in larger teams.


Maybe, but this is a O(individual file size) problem not a O(code 
base) problem,
which is why b is such an effective solution.

Since I don't expect to convince you of anything further, the 
only thing I can suggest is to write a lint rule using the 
compiler as a library (or hack the compiler yourself), since 
changing the behaviour would almost certainly be rejected on cost 
(i.e. breaking stuff) / benefit, and adding a second private 
would probably also be rejected as too narrow a feature for 
marginal, at best, utility.

I can't remember if you do compiler stuff, but I'd be happy to 
help once I have some time (or try slack for faster response from 
others).
Oct 19 2019
parent reply aliak <something something.com> writes:
On Saturday, 19 October 2019 at 17:27:26 UTC, Nicholas Wilson 
wrote:

 On Saturday, 19 October 2019 at 13:45:37 UTC, Aliak wrote:

 On Saturday, 19 October 2019 at 12:23:36 UTC, Nicholas Wilson 
 wrote:

 IME, no. If your module is big enough that you can't keep all 
 of it in you head and you start calling implementation 
 details of your classes _by accident_ then either:
 a) name your implementation details so they stand out so you 
 don't call by accident (e.g. a._something() )
 b) split up your module into a package so that it fits in 
 your head, this will (probably) cause you to not be able to 
 call the implementation details at all, and will thus cause 
 you to have to think about the organisation of you package 
 (which is probably a good thing).


 Solution a is a convention.


 Indeed.


 And solution b is fluffy.


 How so? Also, you should probably be doing that anyway for 
 different reasons.


As in "fits in your head" is not concrete. And it's usually not 
just "you" in a team. Plus, IIRC dmd is a prime example where 
splitting is not happening because of "reasons". So it's not 
always doable either.

Furthermore, neither solution allows you to completely 
encapsulate some vars in a type while allowing module functions 
to access others that are not accessible outside the module.


 Since I don't expect to convince you of anything further, the 
 only thing I can suggest is to write a lint rule using the 
 compiler as a library (or hack the compiler yourself), since 
 changing the behaviour would almost certainly be rejected on 
 cost (i.e. breaking stuff) / benefit, and adding a second 
 private would probably also be rejected as too narrow a feature 
 for marginal, at best, utility.

 I can't remember if you do compiler stuff, but I'd be happy to 
 help once I have some time (or try slack for faster response 
 from others).


Well, the problem is that I've used languages with moduleprivate 
and privateprivate and it's from experience that it's cleaner. So 
unless there're some actual disadvantages to having that extra 
granularity that I'm not seeing, I suppose there can't be any 
convincing (and really, I was just trying to point out that the 
notion that D's access levels are obviously the correct ones is 
arguable, therefore not obviously correct - re Mike's post)

And thank you :) appreciate the offer! But it's not something I 
care too much about. And to get something like this in I'd have 
to argue for why encapsulation of user defined types is a good 
thing. A if I actually have to argue for that, pretty sure it 
won't go anywhere. So it's just a level of access I accept is 
missing from D - one good thing about it is that it gives you 
less choice so you don't need to worry about privateprivate vs 
moduleprivate.

But anyway, curious, why do you think it's of marginal utility at 
best? And on a related note have you used any languages that 
provide both levels of granularity that I mention above?
Oct 19 2019
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 19 October 2019 at 23:38:51 UTC, aliak wrote:

 Furthermore, neither solution allows you to completely 
 encapsulate some vars in a type while allowing module functions 
 to access others that are not accessible outside the module.


You could still use interfaces for a total separation, even 
inside a module (well, unless a cast is used, but meh). Or opaque 
structs.

Someone on Stack Overflow this week asked me if we can do 
Javascript style fake modules in D, where the "private" members 
are local inside the function and the "public" ones are returned 
in the object... and indeed we can, which is another amusing way 
of achieving it, but even I think that is a bit too silly in D.


I personally wouldn't vote against adding like private(class) - 
such could be done without massive breakage - but I'm totally meh 
on the whole debate.
Oct 19 2019
prev sibling next sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Saturday, 19 October 2019 at 23:38:51 UTC, aliak wrote:

 On Saturday, 19 October 2019 at 17:27:26 UTC, Nicholas Wilson

 How so? Also, you should probably be doing that anyway for 
 different reasons.


 As in "fits in your head" is not concrete. And it's usually not 
 just "you" in a team.


What I'm saying is a boundary point exists, even if is not 
precisely defined, passed which point separating your module into 
a package is a win for readability and reasonability.


 Plus, IIRC dmd is a prime example where splitting is not 
 happening because of "reasons". So it's not always doable 
 either.


Those reasons are largely "Walter" and are unrelated.


 And thank you :) appreciate the offer! But it's not something I 
 care too much about. And to get something like this in I'd have 
 to argue for why encapsulation of user defined types is a good 
 thing. A if I actually have to argue for that, pretty sure it 
 won't go anywhere. So it's just a level of access I accept is 
 missing from D - one good thing about it is that it gives you 
 less choice so you don't need to worry about privateprivate vs 
 moduleprivate.


Indeed, no need for "friend".


 But anyway, curious, why do you think it's of marginal utility 
 at best? And on a related note have you used any languages that 
 provide both levels of granularity that I mention above?


Because that doesn't allow you to do anything fundamentally new, 
as in the above solutions _work_, even if they don't work as well 
as you'd like them to, and to me it serves as a marker that if 
you are running into that problem then you module is too large 
anyway you likely have other issues regarding trying to reason 
about the code.

No I haven't used both at the same time, but I've used them 
separately and I find that module private provides enough 
encapsulation that I don't find myself wanting something more (As 
opposed to C++ where this impossible because there is only 
textual inclusion, not symbolic imports).
Oct 19 2019
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/19/2019 6:52 PM, Nicholas Wilson wrote:

 On Saturday, 19 October 2019 at 23:38:51 UTC, aliak wrote:

 Plus, IIRC dmd is a prime example where splitting is not happening because of 
 "reasons". So it's not always doable either.


 Those reasons are largely "Walter" and are unrelated.


I know I'm not popular with this idea, but packagizing dmd is akin to painting
a 
rusty/dirty car without prepping the metal first.

What I've been doing recently is a series of PRs aimed at OutBuffer, Array, and 
StringExp to:

1. use [] instead of * so that array bounds checking can be performed
2. use [] to reduce dependency on terminating 0s
3. make the data allocation private
4. prevent direct access to internal memory management
5. add debug code to ensure no dangling pointers

Fortunately, I found only a couple small issues with memory bugs.

While I'm still not proud of the abstractions, the amount of cowboy programming 
around them is significantly reduced, along with the possibility of bugs.
Oct 19 2019
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 20/10/2019 4:41 PM, Walter Bright wrote:

 On 10/19/2019 6:52 PM, Nicholas Wilson wrote:

 On Saturday, 19 October 2019 at 23:38:51 UTC, aliak wrote:

 Plus, IIRC dmd is a prime example where splitting is not happening 
 because of "reasons". So it's not always doable either.


 Those reasons are largely "Walter" and are unrelated.


 
 I know I'm not popular with this idea, but packagizing dmd is akin to 
 painting a rusty/dirty car without prepping the metal first.


It is on my list of things that need to happen for dmd-fe as a library 
to be "usable".

Surely the lexer and its support infrastructure can be separated out 
into its own sub package?


 What I've been doing recently is a series of PRs aimed at OutBuffer, 
 Array, and StringExp to:
 
 1. use [] instead of * so that array bounds checking can be performed
 2. use [] to reduce dependency on terminating 0s
 3. make the data allocation private
 4. prevent direct access to internal memory management
 5. add debug code to ensure no dangling pointers


I saw that, tis' good work that!
Oct 19 2019
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/19/2019 8:45 PM, rikki cattermole wrote:

 Surely the lexer and its support infrastructure can be separated out into its 
 own sub package?


Sorry, I'm worn out on that topic.
Oct 19 2019
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 20/10/2019 6:16 PM, Walter Bright wrote:

 On 10/19/2019 8:45 PM, rikki cattermole wrote:

 Surely the lexer and its support infrastructure can be separated out 
 into its own sub package?


 
 Sorry, I'm worn out on that topic.


Fair enough, we can come back to it if we ever get close to getting a 
working IDE shell :)
Oct 19 2019
prev sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Sunday, 20 October 2019 at 03:41:08 UTC, Walter Bright wrote:

 On 10/19/2019 6:52 PM, Nicholas Wilson wrote:

 On Saturday, 19 October 2019 at 23:38:51 UTC, aliak wrote:

 Plus, IIRC dmd is a prime example where splitting is not 
 happening because of "reasons". So it's not always doable 
 either.


 Those reasons are largely "Walter" and are unrelated.


 I know I'm not popular with this idea, but packagizing dmd is 
 akin to painting a rusty/dirty car without prepping the metal 
 first.


Obviously I think you're wrong, but for the sake of getting shit 
done:
Do you mean to imply that now is not the time, as opposed to it 
will never happen?
Because it _really_ needs to happen, and the sooner the better, 
as Rikki notes it is an absolute requirement compiler as a 
library.

  If so, what do you think needs to happen before that?
Oct 20 2019
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 20/10/2019 10:39 PM, Nicholas Wilson wrote:

 On Sunday, 20 October 2019 at 03:41:08 UTC, Walter Bright wrote:

 On 10/19/2019 6:52 PM, Nicholas Wilson wrote:

 On Saturday, 19 October 2019 at 23:38:51 UTC, aliak wrote:

 Plus, IIRC dmd is a prime example where splitting is not happening 
 because of "reasons". So it's not always doable either.


 Those reasons are largely "Walter" and are unrelated.


 I know I'm not popular with this idea, but packagizing dmd is akin to 
 painting a rusty/dirty car without prepping the metal first.


 
 Obviously I think you're wrong, but for the sake of getting shit done:
 Do you mean to imply that now is not the time, as opposed to it will 
 never happen?
 Because it _really_ needs to happen, and the sooner the better, as Rikki 
 notes it is an absolute requirement compiler as a library.
 
   If so, what do you think needs to happen before that?


While I agree with your sentimentality, this is not something worth 
fighting over until a solid use case comes up.

Because of dub its already separated out when loaded in an IDE.

My estimate based upon my last evaluation around 6-8 months ago was it 
would take around a week of concentrated effort to get the lexer into a 
good state for use as a library. The parser would be ridiculous compared 
to this (includes AST).

Semantic analysis while needing to be callable shouldn't need its 
internals exposed.

Point is, you will end up needing a dmd developer even if we were to 
separate out the lexer today and get it into a good state. If he wants 
to leave it for now we should. He has a lot of other things on his mind 
which are far more important.
Oct 20 2019
parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Sunday, 20 October 2019 at 10:08:29 UTC, rikki cattermole 
wrote:

 While I agree with your sentimentality, this is not something 
 worth fighting over until a solid use case comes up.


You mean apart from chunking up a 125 file megapackage? Because 
thats the use case to me, not so much compiler as a library 
although that has packaging and aa sane codebase as a 
prerequisite.
  DMD is an actively hostile codebase to comprehend and reason 
about precisely because it is unstructured, not within files or 
sprawling dependencies across files, but that the is no logical 
structuring to the codebase imposed despite that it obviously 
exists.

See https://github.com/dlang/dmd/pull/9844#issuecomment-498110957 
for an example of the less than exemplary behaviour from the 
leadership. That veiled threat is more true than ever.

If there is a exists path to the packaging of dmd it needs to be 
made clear by Walter and progress can be made towards it. If not, 
then he should accept the fate of a dearth of contributors that 
follows and the consequences that entails.


 If he wants to leave it for now we should. He has a lot of 
 other things on his mind which are far more important.


On the contrary, the malorganised state of the (lack of) packages 
is one of _the_ top barriers to entry.
Oct 20 2019
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/19/2019 4:38 PM, aliak wrote:

 Plus, IIRC dmd is a prime example where splitting is not happening because 
 of "reasons".


dmd was originally developed as a C++ program, which did not have modules.
Hence 
its organization is not the D module system best practices, and it isn't really 
fair to hold it as an example of D best practices.

I don't think Phobos is a great example of module best practices, either, but 
that is somewhat forgivable because Phobos was designed long before we knew
what 
D best practices should be. (In particular, Phobos tends to lump too many 
unrelated things into each module.)

In D, declarations are grouped into a module that would otherwise need "friend" 
access if it were developed in C++.
Oct 19 2019
parent reply aliak <something something.com> writes:
On Sunday, 20 October 2019 at 05:43:52 UTC, Walter Bright wrote:

 On 10/19/2019 4:38 PM, aliak wrote:

 Plus, IIRC dmd is a prime example where splitting is not 
 happening because of "reasons".


 dmd was originally developed as a C++ program, which did not 
 have modules. Hence its organization is not the D module system 
 best practices, and it isn't really fair to hold it as an 
 example of D best practices.


Oh I know, it was a reply to Nicholas proposing splitting up a 
module as a general solution to something - but that's not always 
possible.


 I don't think Phobos is a great example of module best 
 practices, either, but that is somewhat forgivable because 
 Phobos was designed long before we knew what D best practices 
 should be. (In particular, Phobos tends to lump too many 
 unrelated things into each module.)

 In D, declarations are grouped into a module that would 
 otherwise need "friend" access if it were developed in C++.


Yeah this was related to benefits around being able to keep some 
things private from your friends (which is not d-able currently).
Oct 20 2019
parent reply Mike Parker <aldacron gmail.com> writes:
On Sunday, 20 October 2019 at 08:44:37 UTC, aliak wrote:

 On Sunday, 20 October 2019 at 05:43:52 UTC, Walter Bright wrote:



 In D, declarations are grouped into a module that would 
 otherwise need "friend" access if it were developed in C++.


 Yeah this was related to benefits around being able to keep 
 some things private from your friends (which is not d-able 
 currently).


===
module mypack.publicstuff.stuff.secretstuff;

class SecretStuff {
    public foo {}
    package friendlyFoo {]
    private secretFoo {]
}

===
module mypack.publicstuff.stuff.friends;

void beFriendly(SecretStuff s) {
    s.friendlyFoo();
}
...
===
module mypack.publicstuff;

public import mypack.publicstuff.stuff.friends,
               mypack.publicstuff.stuff.secretstuff;

...
===
Oct 20 2019
parent aliak <something something.com> writes:
On Sunday, 20 October 2019 at 09:02:18 UTC, Mike Parker wrote:

 On Sunday, 20 October 2019 at 08:44:37 UTC, aliak wrote:

 On Sunday, 20 October 2019 at 05:43:52 UTC, Walter Bright 
 wrote:



 In D, declarations are grouped into a module that would 
 otherwise need "friend" access if it were developed in C++.


 Yeah this was related to benefits around being able to keep 
 some things private from your friends (which is not d-able 
 currently).


 ===
 module mypack.publicstuff.stuff.secretstuff;

 class SecretStuff {
    public foo {}
    package friendlyFoo {]
    private secretFoo {]
 }

 ===
 module mypack.publicstuff.stuff.friends;

 void beFriendly(SecretStuff s) {
    s.friendlyFoo();
 }
 ...
 ===
 module mypack.publicstuff;

 public import mypack.publicstuff.stuff.friends,
               mypack.publicstuff.stuff.secretstuff;

 ...
 ===


Ha! Seems it is d-able.

project/
-- type/
---- package.d // definition of type
---- friends.d // can access package of type and not private of 
type

Thanks, added that data to da faq.
Oct 20 2019
prev sibling parent welkam <wwwelkam gmail.com> writes:
On Thursday, 17 October 2019 at 16:50:15 UTC, Rumbu wrote:

 There is no language construct to use RAII or heap 
 application on objects. We had scope but it was deprecated.


 That would be news to me. Even if `scope obj = new MyClass;` 
 got deprecated, there are library solutions.


 Library solution is not a *language construct*. You know what? 
 Let's deprecate 'struct'. I bet that we can build a library 
 solution instead. Too many keywords, 'switch' can be reduced to 
 a library solution using just 'if's.


Other people reaction depends on your actions. When there is 
problem with communication try to reword you idea or go more in 
depth with examples. If my attempt at reading your mind is 
correct your main complaint is that solutions to manual memory 
management for Class is not ergonomic. If that is correct than 
you should work on your communication skills instead of what you 
are doing here
Oct 17 2019
prev sibling parent Paul Backus <snarwin gmail.com> writes:
On Thursday, 17 October 2019 at 16:26:07 UTC, Atila Neves wrote:

 On Thursday, 17 October 2019 at 15:24:09 UTC, Rumbu wrote:

 The general attitude "OOP is bad, let's use a struct instead".


 I don't know what to do about this. I prefer structs myself.


 The fact that objects are by default allocated using gc.


 Only if you use `new`. And if you don't, then you'll have to 
 worry about memory management.


 There is no language construct to use RAII or heap application 
 on objects. We had scope but it was deprecated.


 That would be news to me. Even if `scope obj = new MyClass;` 
 got deprecated, there are library solutions.


 The fact that class encapsulation is not fully implemented. 
 Private is not so private.


 This is by design and isn't going to be changed. Classes can be 
 in their own module if needed.


 Structs cannot implement interfaces (see next point for usage).


 Also by design, unless you want something like Rust's traits or 
 Haskell's typeclasses. But none of this is OOP.


It's really disappointing to me how poor the communication is on 
both sides of this exchange.

- On Rubmu's side, the complaints are expressed in a way that 
makes it hard to understand what the actual problems are that 
he's encountered using D.
- On your side, Átila, the responses seem to be aimed primarily 
at dismissing or invalidating Rumbu's complaints, rather than 
attempting to understand them or asking for clarification.

There's a lot that could be improved here. Since you, Átila, are 
the one in a position of authority, you have a much greater 
opportunity to set a constructive tone for conversations like 
these going forward, so I'll focus your responses.

- It's true that a complaint about "general attitude" is not 
actionable. Instead of dismissing it, however, you could take the 
opportunity to ask for clarification. For example: is there a 
specific improvement to D that you'd like to see given a higher 
priority?

- It's true that D provides several alternatives to `new` and the 
GC for heap allocation, but it's likely that Rumbu wouldn't be 
making this complainy if those alternatives already solved his 
problems. Again, there's an opportunity here to ask clarifying 
questions: have you tried D's current alternatives to `new`? If 
not, why not? If so, are there specific ways in which you'd like 
to see them improved?

- It's true that class-level encapsulation can be achieved using 
D's module system, but it's not obvious, and it requires extra 
work. Possible follow-up questions: have you tried using the 
proposed solution of putting classes in their own modules? If 
not, why not? If so, did you run into any issues with it?

- It's true that structs can't implement interfaces, but there 
are reasons why someone might want them to. You might ask: what 
problems has this limitation caused you? Have you tried any of 
the existing library solutions, like `std.typecons.wrap`?

Don't take this harshly--effective communication is really, 
really difficult. Most people, including myself, get it wrong 
most of the time. It takes a lot of time, effort, and practice. 
If you can manage it, though, the rewards are huge: people will 
feel understood and listened-to when they talk to you, and you'll 
be able to avoid pointless arguments and focus on actually 
getting stuff done.
Oct 17 2019
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
On Wed, 2019-10-16 at 16:42 +0000, Rumbu via Digitalmars-d wrote:
[=E2=80=A6]

 Summary (community profile/expectations/disappointments):
 - Desktop applications as main area of development;


Works for me. GtkD is great.


 - Linux as preferred operating system;


This has to be wrong. Despite Linux being The Right OS=E2=84=A2, Windows an=
d macOS are
the market leaders and must be a strong focus. Of course this makes GtkD le=
ss
appealing. :-(


 - Dub as building tool;


Or Meson, SCons, etc.


 - Visual Studio Code as main editor;


Along with Emacs, VIM, CLion, Visual Studio. Restricting to one editor is t=
o
turn away large numbers of potential users.


 - Missing language features (tuples, named arguments, string=20
 interpolation)
 - Phobos is not intuitive
 -  nogc phobos
 - json serialization;
 - missing phobos important modules;


Phobos modules that should be deprecated and removed with severe prejudice.


 - poor compiler error messages;
 - poor debugging experience;


Hence me wanting CLion support. Debugging C++ and Rust in CLion is as close=
 to
fun as it is possible to get in the activity of debugging.


 -  safe is expected to be default;
 - not enough third party libraries;
 - lack of progress on DIPs;
 - ranges are the best;
 - spaces, not tabs :)


Philistine. Of course tabs are for indent, one per level. Emacs and CLion c=
an
set the tab indent spacing as you want.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk
Oct 17 2019
prev sibling parent reply Ethan <gooberman gmail.com> writes:
On Wednesday, 16 October 2019 at 16:42:28 UTC, Rumbu wrote:

 I will put this here: 
 https://rawgit.com/wilzbach/state-of-d/master/report.html

 Summary (community profile/expectations/disappointments):
 - Desktop applications as main area of development;
 - Linux as preferred operating system;
 - Dub as building tool;
 - Visual Studio Code as main editor;
 - Missing language features (tuples, named arguments, string 
 interpolation)
 - Phobos is not intuitive
 -  nogc phobos
 - json serialization;
 - missing phobos important modules;
 - poor compiler error messages;
 - poor debugging experience;
 -  safe is expected to be default;
 - not enough third party libraries;
 - lack of progress on DIPs;
 - ranges are the best;
 - spaces, not tabs :)

 I don't necessarily endorse this list (e.g. I sincerely hate 
 dub), but the D Vision seems to ignore it. And I find this more 
 than wrong, personally perceiving it as "we don't care about 
 your opinion, we have our own agenda, get lost".


As you've stated here, you don't necessarily agree with this 
list. So I'm just quoting for the audience because it's 
everything in one place.

I'll go ahead and point this out:

If you ask enthusiasts what's important, you'll get enthusiast 
responses. Focusing on this list wholesale is a sure way to keep 
par course.

The following from the list hold the language itself back:

- Missing language features (tuples, named arguments, string 
interpolation)
- poor debugging experience
- poor compiler error messages
- lack of progress on DIPs

The following hold user adoption back:
- Phobos is not intuitive
   * But that's a blanket statement, this needs to be specific
- not enough third party libraries
   * And my stance there is we need auto-generated bindings for 
C/C++ compatible APIs instead of reinventing every wheel out there

Everything else is highly subjective and doesn't focus properly 
on growth areas that need to be hit.

Needless to say. The point of a vision for the language is 
generally to identify areas for growth. If maintenance is being 
short changed for growth, then you've got a problem that will 
quickly become unsustainable.
Oct 17 2019
next sibling parent Gregor =?UTF-8?B?TcO8Y2ts?= <gregormueckl gmx.de> writes:
On Thursday, 17 October 2019 at 08:57:32 UTC, Ethan wrote:

 I'll go ahead and point this out:

 If you ask enthusiasts what's important, you'll get enthusiast 
 responses. Focusing on this list wholesale is a sure way to 
 keep par course.


I think the term you're looking for is Survivorship Bias. A good 
example of how this can affect results is the analysis of damaged 
bombers that returned home in World War II: 
https://en.wikipedia.org/wiki/Survivorship_bias#In_the_military
Oct 17 2019
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 17 October 2019 at 08:57:32 UTC, Ethan wrote:

   * And my stance there is we need auto-generated bindings for 
 C/C++ compatible APIs instead of reinventing every wheel out 
 there



Nothing wrong with that, but people tend to take the risk of 
switching to a new language when it is needed to access a 
superior framework for they task. So, something like Mir, if 
developed further, has much more potential than something like 
vibe-d.

Having one hands-down-solid framework might matter more than 
mirroring other platforms.

Just saying.
Oct 17 2019
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 17 October 2019 at 10:48:57 UTC, Ola Fosheim Grøstad 
wrote:

 Having one hands-down-solid framework might matter more than 
 mirroring other platforms.


And that seems to be the only requirement for gaining traction 
actually, if we look at other languages.


HAS CORPORATE BACKING?

Despite people claiming otherwise, corporate backing itself means 
nothing.

Case in point: Dart.

Dart was created by Google, used internally, endorsed by Google 
and the committed to maintaining it.
Yet it was not adopted outside Google.

They added Angular support for Dart.
Made little difference, most people would rather go for 
TypeScript. Dart may have been better for Angular development, 
but not superior to TypeScript.

Then some people inside Google started building Flutter, which 
enable cross platform development with hot reload, for which 
there are few alternatives. And now Dart is getting traction.


DOES NOT HAVE COPORATE BACKING?

Python, Php and many other languages have found large niches 
without being propelled by any corporate entity.


LANGUAGE FEATURES?

Insufficient.

Case in point: Perl 6

Lots of features, many interesting, but adoption doesn't even 
register in comparison with the alternatives.


GOOD LANGUAGE SEMANTICS?

Mostly irrelvant.

Case in point: Php

Integration with webservers and HTML was more important, and for 
many people Php is still the best option for setting up a blog or 
forum.


LACK OF RESOURCES?

Nah, many (or most) languages have started out with 1-3 people as 
a side project and grown slowly over time.  Start out by having a 
limited scope, and only extend the scope as you get more people 
on board...
Oct 17 2019
prev sibling next sibling parent welkam <wwwelkam gmail.com> writes:
On Tuesday, 15 October 2019 at 13:09:15 UTC, Mike Parker wrote:

 This thread is for general feedback and discussion regarding 
 Átila's blog post on his vision for D's future.

 https://dlang.org/blog/2019/10/15/my-vision-of-ds-future/


This whole thing reads more like what Átila wants and reasonably 
could do in a year than a vision for D. Its more like I instead 
of we. There is effort to port D to android and I want to see 
that discoursed in a vision document. What is currently is being 
done. When we expect what to be done. What needs to be done but 
needs more funding. Those kind of things. I want to hear more 
about the whole effort not only yours. I want to see a plan and a 
vision.

In that document you talked about making D also an interpreted 
language. I dont think its that good of an idea. While I would 
love to have faster compile times I think its better to spend 
time optimizing DMD. While it is fast game developers would not 
call it well optimized. If we applied data oriented design ideas 
to both front end and back end that would benefit everyone. 
Second crazy idea I have is to merge lld and DMD together. Now 
compiler translates internal data structures to object file and 
then linker read the file and tranlate it to internal structures. 
With modifications to both DMD and lld its possible to go make 
lld to just read DMD internal data. That would speed up build 
times.

The other thing that is completely missing from any discussion is 
how to improve onboarding process for new people that want to 
work on compiler, runtime or phobos. There is little 
documentation on them. Its not clear where to even ask questions 
about them. There is no help in "breaking the ice" so that new 
people become contributors. Personally I wanted to dump the whole 
data structure that is build here 
https://github.com/dlang/dmd/blob/master/src/dmd/attrib.d#L133
After some time I failed to find a place where its completely 
built up and where could I inspect it. I failed because I jumped 
in the middle of compiler without knowing the big picture view on 
how compiler works. Then I decided that I would read from main to 
understand how things work. I reached tokenizer and abandoned the 
whole idea. If a person have such a problem should they ask 
Walter or maybe Sebastian Wilzbach? And if so should they write 
private emails? At the time I was looking at compiler code I 
didnt knew that there were such a thing as slack. But it requires 
an invite and I dont have it.

There are many problems preventing people from contributing and 
there is not even a discussion about improvements to the process. 
Also I would like to mention that spending time attracting people 
might be more useful than spending that time coding.
Oct 17 2019
prev sibling next sibling parent Dukc <ajieskola gmail.com> writes:
Making D the default implementing (or interface) language and C++ 
interop are faily much the same thing. I read that as you're 
trying to make us a kind of new C - a langage between most other 
languages. I must say that I like that direction. As a not-so-big 
language, ecosystem size tends always to be somewhat of a 
problem. But interfacing with just about everything, and thus 
being able to lend other ecosystems should help a lot.

About needing a ridiculously fast interpreter - Are you thinking 
of using Stefan's newCTFE for that, or does it have to be 
something else?
Oct 18 2019
prev sibling next sibling parent reply John Belmonte <john neggie.net> writes:
On Tuesday, 15 October 2019 at 13:09:15 UTC, Mike Parker wrote:

 This thread is for general feedback and discussion regarding 
 Átila's blog post on his vision for D's future.



 Safe and easy concurrency


I'd like to make another plea to get on board with structured 
concurrency.  That includes having a standard cancellation 
mechanism.

https://forum.dlang.org/thread/ndirsnblaktyfellckil forum.dlang.org

Futures -> bad.  Quoting Nathaniel Smith:


 Language design happens by stepwise incremental improvements. 
 And like any form of gradient descent, it can get stuck in 
 sub-optimal local minima. Futures are a really attractive local 



https://trio.discourse.group/t/structured-concurrency-in-rust/73/14
Oct 19 2019
parent reply Sebastiaan Koppe <mail skoppe.eu> writes:
On Saturday, 19 October 2019 at 13:04:26 UTC, John Belmonte wrote:

 On Tuesday, 15 October 2019 at 13:09:15 UTC, Mike Parker wrote:

 This thread is for general feedback and discussion regarding 
 Átila's blog post on his vision for D's future.



 Safe and easy concurrency


 I'd like to make another plea to get on board with structured 
 concurrency.  That includes having a standard cancellation 
 mechanism.


https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/

Oh that is actually pretty nice. The nursery idea reminds me a 
bit of the coroutineScope in Kotlin. Makes a lot of sense.
Oct 19 2019
parent reply John Belmonte <john neggie.net> writes:
On Saturday, 19 October 2019 at 20:22:21 UTC, Sebastiaan Koppe 
wrote:

 https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/

 Oh that is actually pretty nice. The nursery idea reminds me a 
 bit of the coroutineScope in Kotlin. Makes a lot of sense.


Kotlin has a good structured concurrency implementation.  Scopes 
can be configured to use either a single OS thread (for UI, or 
simply to make concurrency easier to reason about and avoid the 
need for explicit locking and an entire class of race 
conditions), or multiple OS threads with various mapping 
strategies.  It's also a good example of what minimum support is 
needed from the language, vs. what can exist in the coroutine 
library.

Interestingly, the team working on Kotlin's experimental 
coroutine library stumbled on structured concurrency 
independently.  Martin Sústrik's defined it first (and made the 
libdill C implementation), which Nathaniel Smith greatly expanded 
on with his article and Python library.  A great characteristic 
of these people is that they want to work together to improve the 
state of the art, and aren't competitive with respect to their 
implementations 
(https://trio.discourse.group/t/structured-concurrency-kickoff/).

Rust appears to be going down the wrong concurrency path.  
Meanwhile C++ structured concurrency experiments have started 
(https://github.com/lewissbaker/cppcoro/, 
https://www.youtube.com/watch?v=1Wy5sq3s2rg).  It's either an 
opportunity for D, or a chance to fall behind...

The "founders" are very open to reviewing and consulting on 
getting structured concurrency right in other languages.  It 
would just take some mutual openness by D's stewards to have an 
honest look at where D is at and how it can move forward.
Oct 19 2019
parent reply Russel Winder <russel winder.org.uk> writes:
On Sun, 2019-10-20 at 03:23 +0000, John Belmonte via Digitalmars-d wrote:

=20


[=E2=80=A6]

 Rust appears to be going down the wrong concurrency path. =20


[=E2=80=A6]

I believe you need to expand on this claim. As far as I am aware there are =
a
number of structured concurrency crates, e.g. Rayon.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk
Oct 19 2019
parent John Belmonte <john neggie.net> writes:
On Sunday, 20 October 2019 at 06:44:45 UTC, Russel Winder wrote:

 On Sun, 2019-10-20 at 03:23 +0000, John Belmonte via 
 Digitalmars-d wrote:

 


 […]

 Rust appears to be going down the wrong concurrency path.


 […]

 I believe you need to expand on this claim. As far as I am 
 aware there are a number of structured concurrency crates, e.g. 
 Rayon.


long discussion here:  
https://trio.discourse.group/t/structured-concurrency-in-rust/

My summary as an onlooker:
   * Rust and/or the structured concurrency libraries don't have 
cancellation scopes (see 
https://vorpus.org/blog/timeouts-and-cancellation-for-humans/)
   * Rust has a competing ecosystem by way of futures, which adds 
significant API complexity and fractures the concurrency 
ecosystem for no advantage over async/await + structured 
concurrency

excerpt:

 There are multiple crates out there that implement coroutines, 
 but for now the futures ecosystem seems to be some orders of 
 magnitude more popular.


 Right – if you don’t have compiler support, then coroutines are 
 really inefficient (you need to allocate big stacks, like 
 threads) and futures are the only viable path. If you do have 
 compiler support, then they’re equally efficient, and 
 coroutines are simpler and easier to work with.

 That’s why async is such a trap for language designers: if you 
 knew from the start that you were going to add 
 syntax/compiler-support for async, then coroutines would be the 
 obvious way to go. But generally by the time you’ve convinced 
 yourself that you need syntax/compiler support, then you 
 already have a large futures ecosystem, and you’ve trained 
 yourself to think in terms of futures. It’s very difficult to 
 step back and realize that as soon as you add async syntax, all 
 your awesome futures APIs, which were important and tricky and 
 crucial, suddenly become unnecessary bloat.
Oct 20 2019
prev sibling next sibling parent Dan <dan_partelly rdsor.ro> writes:
On Tuesday, 15 October 2019 at 13:09:15 UTC, Mike Parker wrote:

On Tuesday, 15 October 2019 at 13:09:15 UTC, Mike Parker wrote:
 This thread is for general feedback and discussion regarding 
 Átila's blog post on his vision for D's future.

 https://dlang.org/blog/2019/10/15/my-vision-of-ds-future/


Good write-up. Technical. Speaking about D "the language". But 
what about D "the project" ? They are not the same things. Things 
stay technical as long myself and 3-4 other persons are "the 
project" and focus on solving a technical problem. But, as soon 
as more people get involved it gets fast out of hand. Political 
and social skills have to be involved. Economics rears it's ugly 
head. $$$ are needed.

What is Attila's vision on "D, the project" ? What are his goals 
, what does he want to accomplish as a leader? Same goes for 
walter.

To be  frank, I posted some things here two years ago, then just 
lurked in read only mode by time in time, but to this day I have 
no freaking idea where Walter/Andrei/Attila/wheoever else wants 
to go with D project and what goals they have, and what is done 
to get there.  And this is bad. No clear road ahead, at least how 
I perceive it. It always gave me the impression that neither the 
project and the language founds it's identity.
Oct 24 2019
prev sibling parent reply Radu <void null.pt> writes:
On Tuesday, 15 October 2019 at 13:09:15 UTC, Mike Parker wrote:

 This thread is for general feedback and discussion regarding 
 Átila's blog post on his vision for D's future.

 https://dlang.org/blog/2019/10/15/my-vision-of-ds-future/


I like most of the meta goals that are listed in the blog post.

However, I would like to see a road map with some specifics and 
time estimates attached to them.

I'm really interested in the "Make D the default implementation 
language" section.
And this comes from a semi failed experiment of mine trying to 
code a C library in D using -betterC. My conclusions:

- You miss the nice dynamic arrays and hash map structures, and 
others. You end-up rolling your own or wrapping C libraries, 
which requires lots of effort.
- There is no way to generate C/C++ header files from your 
extern(C/C++) declaration, I know this is being worked on. So had 
to roll my own.
- I had to roll out my own RefCount, Nullable and friends.
- At that time copy ctor was not available, so me wanting to 
properly use immutable for non POD types was a pain.
- CTFE is severely limited.
Most of these are tracked as bugs already, in case *thatsomeone* 
asks :)

All these problems are systemic and come from the lack of 
orthogonality in the core and std libs, the language had some 
improvements in using a template based run-time interface, but 
still has warts like no betterC CTFE. There are a lot of 
assumptions about what is available in terms of language and 
run-time, and vast majority of APIs in std lib is written with 
RTTI, exceptions and GC in mind.
In a perfect world core/std APIs will be layered bottom-up, so 
you have access to some (most?) algorithms and data structures 
from the lower denominator (betterC) till up the chain with GC, 
exceptions, type info where it makes sense.
It's the "pay as you go" mindset, that was discussed at length on 
this forum, that is not a reality yet.
std.v2 could be a good place to exercise this, as it could 
liberate the way APIs are constructed and how the whole thing 
plays together.

So there is a great deal of potential there for library writers, 
you can write some nice and elegant system code that can be used 
from any language, using the C API (or even C++), and still 
maintain the higher level D API, all without a fat run-time 
attached.
Oct 24 2019
next sibling parent divi <a b5.re> writes:
On Thursday, 24 October 2019 at 12:35:43 UTC, Radu wrote:

 snip


Fully agree, and it'd be nice to see a concerted effort as 
betterC is actually very nice, and I imagine in terms of user 
code there is a lot of work getting duplicated (rolling your own 
dynamic/assoc arrays etc).

The question is how would a transition look? I know it's a pretty 
insurmountable amount of work at this point but the improvement 
of betterC over C itself could justify it.
Oct 24 2019
prev sibling next sibling parent bpr <brogoff gmail.com> writes:
On Thursday, 24 October 2019 at 12:35:43 UTC, Radu wrote:

 On Tuesday, 15 October 2019 at 13:09:15 UTC, Mike Parker wrote:

 This thread is for general feedback and discussion regarding 
 Átila's blog post on his vision for D's future.

 https://dlang.org/blog/2019/10/15/my-vision-of-ds-future/


 ...


That's terrific feedback, a critique with actionable items drawn 
from experience.

I agree and share that experience, namely, I'm very positive 
about betterC, but there are many rough edges (yes, especially 
CTFE and missing library features) and I doubt I'd recommend it 
in it's current state for "real work" against the alternatives.


 All these problems are systemic and come from the lack of 
 orthogonality in the core and std libs, the language had some 
 improvements in using a template based run-time interface, but 
 still has warts like no betterC CTFE. There are a lot of 
 assumptions about what is available in terms of language and 
 run-time, and vast majority of APIs in std lib is written with 
 RTTI, exceptions and GC in mind.
 In a perfect world core/std APIs will be layered bottom-up, so 
 you have access to some (most?) algorithms and data structures 
 from the lower denominator (betterC) till up the chain with GC, 
 exceptions, type info where it makes sense.
 It's the "pay as you go" mindset, that was discussed at length 
 on this forum, that is not a reality yet.


That's the vision I could get behind. I think there are many on 
this list who have an aversion to this vision though, so I'm 
skeptical that it will happen anytime soon.
Oct 24 2019
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/24/2019 5:35 AM, Radu wrote:

 And this comes from a semi failed experiment of mine trying to code a C
library 
 in D using -betterC. My conclusions:
 
 - You miss the nice dynamic arrays and hash map structures, and others. You 
 end-up rolling your own or wrapping C libraries, which requires lots of effort.
 - There is no way to generate C/C++ header files from your extern(C/C++) 
 declaration, I know this is being worked on. So had to roll my own.
 - I had to roll out my own RefCount, Nullable and friends.
 - At that time copy ctor was not available, so me wanting to properly use 
 immutable for non POD types was a pain.
 - CTFE is severely limited.
 Most of these are tracked as bugs already, in case *thatsomeone* asks :)


Since all but the second item are not C features, I don't see how these caused 
your DasBetterC project to fail.



 but still has warts like no betterC CTFE.


Specifics, please.

BTW, many of Phobos' modules are template only, meaning they should work with 
betterC.
Oct 24 2019
next sibling parent reply SrMordred <patric.dexheimer gmail.com> writes:
On Thursday, 24 October 2019 at 21:29:08 UTC, Walter Bright wrote:

 On 10/24/2019 5:35 AM, Radu wrote:

 And this comes from a semi failed experiment of mine trying to 
 code a C library in D using -betterC. My conclusions:
 
 - You miss the nice dynamic arrays and hash map structures, 
 and others. You end-up rolling your own or wrapping C 
 libraries, which requires lots of effort.
 - There is no way to generate C/C++ header files from your 
 extern(C/C++) declaration, I know this is being worked on. So 
 had to roll my own.
 - I had to roll out my own RefCount, Nullable and friends.
 - At that time copy ctor was not available, so me wanting to 
 properly use immutable for non POD types was a pain.
 - CTFE is severely limited.
 Most of these are tracked as bugs already, in case 
 *thatsomeone* asks :)


 Since all but the second item are not C features, I don't see 
 how these caused your DasBetterC project to fail.



 but still has warts like no betterC CTFE.


 Specifics, please.

 BTW, many of Phobos' modules are template only, meaning they 
 should work with betterC.


For me the betterC problems arise more in mixin generate codes.
I believe that every function that interacts with strings fail.(i 
think that´s because it uses some autoencoding code that uses gc, 
at least looks like that when i tried to search for the problem)

ex:
//this fails with -betterC
import std.string : split;
return "int x; ,".split(",")[0];
Oct 24 2019
parent SrMordred <patric.dexheimer gmail.com> writes:
 ex:
 //this fails with -betterC
 import std.string : split;
 return "int x; ,".split(",")[0];


Sorry, countUntil is a better example


 //this fails with -betterC


import std.algorithm : countUntil;
auto index = "int x; ,".countUntil(";");
Oct 24 2019
prev sibling next sibling parent reply Radu <void null.pt> writes:
On Thursday, 24 October 2019 at 21:29:08 UTC, Walter Bright wrote:

 On 10/24/2019 5:35 AM, Radu wrote:

 And this comes from a semi failed experiment of mine trying to 
 code a C library in D using -betterC. My conclusions:
 
 - You miss the nice dynamic arrays and hash map structures, 
 and others. You end-up rolling your own or wrapping C 
 libraries, which requires lots of effort.
 - There is no way to generate C/C++ header files from your 
 extern(C/C++) declaration, I know this is being worked on. So 
 had to roll my own.
 - I had to roll out my own RefCount, Nullable and friends.
 - At that time copy ctor was not available, so me wanting to 
 properly use immutable for non POD types was a pain.
 - CTFE is severely limited.
 Most of these are tracked as bugs already, in case 
 *thatsomeone* asks :)


 Since all but the second item are not C features, I don't see 
 how these caused your DasBetterC project to fail.


What do you mean? They are D issues, the only C "feature" you 
really use is the extern(C)
declaration on the API level.


 but still has warts like no betterC CTFE.


 Specifics, please.

 BTW, many of Phobos' modules are template only, meaning they 
 should work with betterC.


```
string foo()(string a, string b)
{
     return a ~ b;
}

extern(C) void main()
{
    enum x = foo("a", "b");
}
Error: array concatenation of expression a ~ b requires the GC 
which is not available with -betterC
```
Hey ho
https://issues.dlang.org/show_bug.cgi?id=20086
https://issues.dlang.org/show_bug.cgi?id=20101
https://github.com/dlang/dmd/pull/8253

Some algorithms are working indeed but it is a stupid trial and 
error exercise each time you want to use some template code from 
std. And you risk that the next compiler release could break 
them, because they are not really tested against -betterC.

```
import std.bitmanip : bitsSet;
import std.algorithm.comparison : equal;

extern(C) void main()
{
   assert(bitsSet(1).equal([0]));
}
Error: TypeInfo cannot be used with -betterC
```
Oct 24 2019
parent Radu <void null.pt> writes:
On Friday, 25 October 2019 at 05:23:33 UTC, Radu wrote:

 On Thursday, 24 October 2019 at 21:29:08 UTC, Walter Bright 
 wrote:

 On 10/24/2019 5:35 AM, Radu wrote:

 [...]


 Since all but the second item are not C features, I don't see 
 how these caused your DasBetterC project to fail.


 What do you mean? They are D issues, the only C "feature" you 
 really use is the extern(C)
 declaration on the API level.


 [...]


 Specifics, please.

 BTW, many of Phobos' modules are template only, meaning they 
 should work with betterC.


 ```
 string foo()(string a, string b)
 {
     return a ~ b;
 }

 extern(C) void main()
 {
    enum x = foo("a", "b");
 }
 Error: array concatenation of expression a ~ b requires the GC 
 which is not available with -betterC
 ```
 Hey ho
 https://issues.dlang.org/show_bug.cgi?id=20086
 https://issues.dlang.org/show_bug.cgi?id=20101
 https://github.com/dlang/dmd/pull/8253

 Some algorithms are working indeed but it is a stupid trial and 
 error exercise each time you want to use some template code 
 from std. And you risk that the next compiler release could 
 break them, because they are not really tested against -betterC.

 ```
 import std.bitmanip : bitsSet;
 import std.algorithm.comparison : equal;

 extern(C) void main()
 {
   assert(bitsSet(1).equal([0]));
 }
 Error: TypeInfo cannot be used with -betterC
 ```


Taken from the samples on front page
```
struct Point
{
     private double[2] p;
     // Forward all undefined symbols to p
     alias p this;
     double dot(Point rhs)
     {
         return p[0] * rhs.p[0] + p[1] * rhs.p[1];
     }
}

extern(C) void main()
{
     Point p1, p2; p1 = [2, 1], p2 = [1, 1];
     assert(p1[$ - 1] == 1);
}
error: undefined reference to '_memsetDouble'
collect2: error: ld returned 1 exit status
```
Same works in LDC, imagine you want to support both compilers...
Oct 24 2019
prev sibling parent reply Sebastiaan Koppe <mail skoppe.eu> writes:
On Thursday, 24 October 2019 at 21:29:08 UTC, Walter Bright wrote:

 but still has warts like no betterC CTFE.


 Specifics, please.

 BTW, many of Phobos' modules are template only, meaning they 
 should work with betterC.


Many do indeed. And many don't.

Like `chain` https://run.dlang.io/is/sU4q80
Anything on strings like `toLower`, `canFind` 
https://run.dlang.io/is/8PS9Vd
Until recently tuple didn't work

Other times, some function should work, but they are inside a 
file that imports something that doesn't.

And of course the problem that anything that doesn't work at 
betterC runtime, won't work in CTFE as well. Which I understand, 
but goes against intuition.

Having said that, I am of the same opinion as Mike Franklin, and 
I would rather see work being done on a pay-as-you-go druntime 
than on a better betterC.
Oct 24 2019
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/24/2019 11:44 PM, Sebastiaan Koppe wrote:

 Having said that, I am of the same opinion as Mike Franklin, and I would
rather 
 see work being done on a pay-as-you-go druntime than on a better betterC.


The two mostly go together.
Oct 25 2019
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 25/10/2019 8:13 PM, Walter Bright wrote:

 On 10/24/2019 11:44 PM, Sebastiaan Koppe wrote:

 Having said that, I am of the same opinion as Mike Franklin, and I 
 would rather see work being done on a pay-as-you-go druntime than on a 
 better betterC.


 
 The two mostly go together.


As of late I've been helping one or two people out with -betterC.

So many modules under the hood are relying on things that can't be 
CTFE'd with -betterC enabled.

Fix this, and pay-as-you-go druntime will be able to take advantage of 
that. Its not a wasted effort.
Oct 25 2019
parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/25/2019 4:05 AM, rikki cattermole wrote:

 So many modules under the hood are relying on things that can't be CTFE'd with 
 -betterC enabled.


It'd be nice if you could file a specific bugzilla issue on this.
Oct 25 2019