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?

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.

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

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?

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.

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.

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.

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.

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?

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.

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

> 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.

GoLand is very good.

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.

> 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.

-- 
Russel.
===========================================
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