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.

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.

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.

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

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?

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.

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.

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

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.

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