On Thursday, 17 October 2019 at 07:25:43 UTC, Russel Winder wrote:
> 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".
>

The plugin ecosystem for VSCode is a mess of competing plugins left and right. Everything in the editor (I don't want to call it an IDE) is a plugin and there are at least two or three competing plugins for every used case. This includes language support for a lot of programming languages. The UI for installing plugins does its best to confuse and makes search results look quite non-distinguishable. It's very much like the plugin trap that Eclipse fell into, only worse.

> Then there is trying to find out out how to use VSCode.
>
> Given I know how to use CLion, [...]

There is your problem ;). VSCode reuses a lot of conventions from Visual Studio. If you are familiar with VS, VSCode will feel very similar. However, the JetBrains family of IDEs have a completely different set of conventions, that you seem to be used to. So it seems only natural that you're strugging to get into VSCode.

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

At least with VSCode, this is the default and not something to be especially alarmed by. Other IDEs have less of a wild west mentality when it comes to plugins. I'd be more worried if we get competing free plugins for Visual Studio, Eclipse or IntelliJ/Clion. But I don't see any sign of that yet.

Would there be a market for a commercial IDE/plugin for D? I'm not sure that the community is large enough yet.

On Wed, 2019-10-16 at 14:53 +0000, Atila Neves via Digitalmars-d wrote: […]
> 
> 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.

Just at the moment, I'd probably say: none. The D plugin is not at a stage where it is usable to do debugging.

Free CLion licences can be obtained from JetBrains for people working on FOSS projects. IDEA and PyCharm have free and pay for versions, CLion and GoLand allow for free licences for the pay for edition. As for other JetBrains products, I have no idea, these are the four I use.

> I also don't know how different that is/would be from people currently using VisualD.

It would be a plugin for CLion instead of for Visual Studio.

As far as I am aware Visual Studio is not available on Linux.

> Is that it, though? go fmt? *That's* the "tooling"?
> 

Clearly not, it is just one of the tools. Consider someone saying "dfmt is the totality of the D tooling".

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

This is true, but the fashion for Go is not a simple piece of history to unravel. And remember large numbers of people considered Emacs, VIM, Atom, etc. completely and totally inadequate for the task of writing lots of Go code. Some started writing a plugin for IntelliJ IDEA, and when JetBrains saw an income stream appearing they took it over and created GoLand.

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

Possibly but many still consider Emacs and VIM to be inadequate to the task of being an IDE. Just because you are happy using it and it alone doesn't necessarily apply to the programmers we want to get using D. VSCode, CLion, and their ilk are what a lot of people expect to be able to use as IDEs.

(I emphasise CLion here over IntelliJ IDEA because CLion is the JetBrains IDE
that supports using gdb and lldb.)

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

Borland Delphi is arguably the first IDE to have taken off big time. and yet it wasn't till the 2000 that we got Eclipse, NetBeans, and then later still IntelliJ IDEA.

And of course there were C (and sort of C++) environments for development and ICE of embedded system software. But they were always very expensive.

> Obvious for some. Eclipse infuriated me so much I went back to Emacs and I haven't looked back since.

And that is fine; personal choice is important in these things. You chose to return to The One True Editor™ (and kitchen sink) as your "IDE". But you must recognise there are many for whom "no IDE means no using the language". If VSCode and one of four of five plugins is the only offering for a D IDE then opportunity to collect more users is being missed.

The D plugin to IntelliJ IDEA, but more realistically CLion – Rust started and is still usable in IntelliJ IDEA but added CLion to get debugging – is a lot of the way there, but not sufficient to be usable. The volunteers working on this try to do a great job, but they are volunteers. I keep trying to suggest to JetBrains they should take this plugin on board as an official one, but unlike Rust and Go, they see no future income stream from any D investment.

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

Restricting people to Emacs and VSCode is to advertise that "this is what we use, if you do not like it, go away". D support has gone beyond this, there is the beginnings of what could be an excellent CLion plugin. If D is to appeal to C, C++, and Rust programmers who use CLion (and there are a great number of them), then there needs to be a working plugin. This isn't going to happen based on volunteers only. Which seems to indicate it isn't going to happen. Which effectively means the D community is turning it's back on a whole ready- made audience of potential users.

> I assume JetBrains took over the Rust plugin because it'd make them money. I'm not sure we could say the same thing.

JetBrains only do things for income stream reasons these days, the evangelism of the early 2000s is a thing of the past. Except they readily give free IDE licences to anyone provably working on FOSS projects.

If the D community is of the view that Go and Rust can make IDE vendors money, but D will never be able to, then D will remain a small, relatively unused programming language. If being niche and relatively unused is what the D community want then fine, but stop all the bluster about appealing to C, C++, Go, Rust, and Python developers.

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

Go and Rust emphasised using Git, Mercurial, and Breezy repositories as packages from the outset. Go chose not to add a central repository, Rust chose to add one. Rust's choice was the correct one for supporting developers. In hindsight, Go has had problems with packages from the outset based on the initial workspace model. Slowly over the decade Go is finding ways forward. Rust got it right from the beginning, once they had stripped down the standard library and emphasised use of the central repository – if only Phobos could be stripped right back to the absolute necessary and everything else provided via the central repository. Obviously not all is good in Rust-land, just as with Python and PyPI, the central repository is not curated, and this leads to horrible messes. Ceylon got this more right, but it is a language few have heard of and even fewer use.

Dub does not allow for use of Git, Mercurial, or Breezy repositories only the uncurated (and therefore potentially problematic) central repository. OK so you can do Git checkouts as a separate activity and use local filestore references, but this is not feasible for packages in the central repository.

Dub builds packages to a location outside the project being worked on. Cargo pulls sources to such a central non-project place and then compiles into a project specific location. Dub tries to store all compiled version out of project in the same area as the sources. Does this matter? Isn't Dub making things easier to share? Sort of, sort of, and no. Dub stores all compilations, but hides them and presents only the last compilation easily. This makes things hard to work with for non-Dub tooling. Cargo makes it a lot easier, at the expense of lack of sharing but always compiling everything into the project area.

Cargo uses TOML, Dub uses SDL (or if you are masochistic JSON). 'nuff said.
QED.

Dub seems to have become the de facto, and indeed de jure, standard for D build, and yet somehow Cargo is just assumed by all Rust programmers whereas Dub is a source of contention and ill-will in the D community.

Dub's biggest problem is that there are many in the D community who will not use it – and they are vocal about it. The solution is not censorship, the solution is for Dub to evolve very rapidly so that these vocal people have the rug pulled from under them, i.e. their complaints become invalid.

-- 
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 -0700, Walter Bright via Digitalmars-d wrote:
> 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.

But there are so many conventions to choose from.

-- 
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 16:42 +0000, Rumbu via Digitalmars-d wrote: […]
> Summary (community profile/expectations/disappointments):
> - Desktop applications as main area of development;

Works for me. GtkD is great.

> - Linux as preferred operating system;

This has to be wrong. Despite Linux being The Right OS™, Windows and macOS are the market leaders and must be a strong focus. Of course this makes GtkD less appealing. :-(

> - Dub as building tool;

Or Meson, SCons, etc.

> - Visual Studio Code as main editor;

Along with Emacs, VIM, CLion, Visual Studio. Restricting to one editor is to turn away large numbers of potential users.

> - Missing language features (tuples, named arguments, string
> interpolation)
> - Phobos is not intuitive
> - @nogc phobos
> - json serialization;
> - missing phobos important modules;

Phobos modules that should be deprecated and removed with severe prejudice.

> - poor compiler error messages;
> - poor debugging experience;

Hence me wanting CLion support. Debugging C++ and Rust in CLion is as close to fun as it is possible to get in the activity of debugging.

> - @safe is expected to be default;
> - not enough third party libraries;
> - lack of progress on DIPs;
> - ranges are the best;
> - spaces, not tabs :)

Philistine. Of course tabs are for indent, one per level. Emacs and CLion can set the tab indent spacing as you want.

-- 
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 Wednesday, 16 October 2019 at 14:53:48 UTC, Atila Neves wrote:
> 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 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.

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

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.

On Wednesday, 16 October 2019 at 16:42:28 UTC, Rumbu wrote:
> 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".

As you've stated here, you don't necessarily agree with this list. So I'm just quoting for the audience because it's everything in one place.

I'll go ahead and point this out:

If you ask enthusiasts what's important, you'll get enthusiast responses. Focusing on this list wholesale is a sure way to keep par course.

The following from the list hold the language itself back:

- Missing language features (tuples, named arguments, string interpolation)
- poor debugging experience
- poor compiler error messages
- lack of progress on DIPs

The following hold user adoption back:
- Phobos is not intuitive
  * But that's a blanket statement, this needs to be specific
- not enough third party libraries
  * And my stance there is we need auto-generated bindings for C/C++ compatible APIs instead of reinventing every wheel out there

Everything else is highly subjective and doesn't focus properly on growth areas that need to be hit.

Needless to say. The point of a vision for the language is generally to identify areas for growth. If maintenance is being short changed for growth, then you've got a problem that will quickly become unsustainable.

On Wednesday, 16 October 2019 at 23:37:47 UTC, welkam wrote:
> Now I have been lurking here and on reddit for a few years and recently I noticed a lot of new people complaining about

Get real. Most programmers never read forums. I've never read forums on the languages I use the most. I stay productive, I don't want to talk about how things can be fixed when I can easily find ways to move around the issues I face. People pick up languages because they have a project (maybe a hobby project). They want to be productive.

When hitting a language issue in other languages I do this:
1. search stack overflow and find solution in 10 seconds.
2. read documentation and find solution in 1-30 minutes.
3. search github and find solution in 15-120 minutes
4. find a tutorial and go through it (1+ hours)

If I have to do this:
5. ask on forums and wait for hours/days.
6. submit an issue on github and wait for weeks, months or years.

Then I put that language in the drawer and stick with the other options. Most people do.

So if people are active in forums there are many reasons for it, of course, but people often starts lurking because they want to know if the roadblocks they are experiencing will be fixed, and chime in to see if it is possible to do something about it.

But yeah, going ad hominem (like you just did) is never a good idea. Fortunately there appears to be much less of it now, but I've in the past, time and time again, seen very knowledgable people who obviously have a background in CS go silent after being hit over the head with a stick.

One thing Rust did right was moderating personal conflicts. As you can see from their forums, they have many people with a solid formal background that can move their eco system forward. Do people gripe about Rust in the Rust forums, yes, but they also knew what they were getting into as Rust always was all about the most "problematic" feature, the borrow checker. It was always front and center.

What has been marketed as D's front-and-center has changed over time and therefore people come to it with very different expectations. Which makes things more contentious.

Many discussions seem to struggle with this. Is D an alternative to C++ or is it in alternative to Python?

It cannot be both, yet it is, and is not, so that is basically an inherent struggle that cannot be resolved.

Thus this social dynamic will linger on...

On Thursday, 17 October 2019 at 07:25:43 UTC, Russel Winder wrote:
> 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".

The D front page lacks a big "Get Started" button to a tutorial for setting up the development environment. So that problem is easy to fix.

Other languages also have multiple plugins, but the social ranking tends to favour just one with a very very large margin to the next contender. So not really a VSCode issue.


> Then there is trying to find out out how to use VSCode.

I view VSCode as an editor and not an IDE, but when trying out something new, I usually try VSCode first because plugins for VSCode tend to be plug and play for tools that have reached critical mass.

I'd be very reluctant to install an IDE just to try out a new tool/language. I might if it is developed by the same (commercial) team developing the tool/language.

On Thursday, 17 October 2019 at 08:57:32 UTC, Ethan wrote:
> I'll go ahead and point this out:
>
> If you ask enthusiasts what's important, you'll get enthusiast responses. Focusing on this list wholesale is a sure way to keep par course.
>

I think the term you're looking for is Survivorship Bias. A good example of how this can affect results is the analysis of damaged bombers that returned home in World War II: https://en.wikipedia.org/wiki/Survivorship_bias#In_the_military

On Thursday, 17 October 2019 at 08:57:32 UTC, Ethan wrote:
>   * And my stance there is we need auto-generated bindings for C/C++ compatible APIs instead of reinventing every wheel out there


Nothing wrong with that, but people tend to take the risk of switching to a new language when it is needed to access a superior framework for they task. So, something like Mir, if developed further, has much more potential than something like vibe-d.

Having one hands-down-solid framework might matter more than mirroring other platforms.

Just saying.