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

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.

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!

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.

On Thu, 2019-10-17 at 08:38 +0000, Chris via Digitalmars-d wrote: […]
> 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.

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 edition of CLion and GoLand is a massive barrier to trying them out.

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

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 have 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 plugin needs more work to do this.

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

Agreed.

-- 
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 Thu, 2019-10-17 at 14:14 +0000, Atila Neves via Digitalmars-d wrote: […]
> 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?

It is a good summary of the points so far, certainly – assuming I have understood the point about Dub and Git, Mercurial, and Breezy repositories. The point about where compilation artefacts are is complicated and definitely not black and white – minor changes to the way Dub handles things might 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.

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.

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

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

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.

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

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/