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

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

An example .dub tree:

.dub
├── build
│   ├── application-debug-linux.posix-x86_64-ldc_2087-13DA9DDBDC6371C556B6892CC72563C7
│   │   └── gfontbrowser
│   └── application-release-linux.posix-x86_64-ldc_2087-8483C7A99B20CA1765F516DDE493FB5B
│       └── gfontbrowser
└── obj
    └── gfontbrowser.o

Cargo gets this right by separating debug and release builds completely.


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

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

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

Unless things have changed again since I stopped doing Android things, Android
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.

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

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

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.

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

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