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)

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.

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!

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.

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.

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.

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.

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.

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.

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

On Wed, 2019-10-16 at 13:22 +0000, bachmeier via Digitalmars-d wrote: […]
> 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.)

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

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.

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