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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 by C, C#, Java, Python, Julia, ... 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 Python. Or Excel, C#, ...
 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
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
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
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
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
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
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. Availability of open source libraries are the #1 reason people 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
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
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
but but my stuff has been consistently #2 the last few weeks clearly the rankings are already fixed :P
Oct 15
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.

 Availability of open source libraries are the #1 reason people 
 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 the F#$k its so negative here.
 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
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 
 go "why the F#$k its so negative 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 languages (C#, Rust) allow to disambiguate.
Oct 19
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
 (C#, Rust) allow to disambiguate.
IMO, you should file a bug for this one. T -- "If you're arguing, you're losing." -- Mike Thomas
Oct 19
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
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
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
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 languages (C#, Rust) allow to disambiguate.
It's not a defect. Interfaces have no state, so it doesn't matter which is called. Java does the same thing.
Oct 19
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 languages (C#, Rust) allow to disambiguate.
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
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
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
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
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
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
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
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
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
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
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
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
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
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 operator overloading. Anyways an easy counter example is that C# 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 
 minima that have trapped C#, JS, Python, now Rust...
https://trio.discourse.group/t/structured-concurrency-in-rust/73/14
Oct 19
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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