Re: VSCode plugins
On Thursday, 6 July 2017 at 16:23:06 UTC, WebFreak001 wrote: While this isn't such a big problem for me because most code was already in workspace-d, How much is actually there though? Going by lines of code, dlang-vscode is a total of ~2000 lines of code *less* than code-d. That's not including workspace-d lines of code for code-d as well. So it can provide the same features in far fewer lines and with a less complex system. Having an extra process just isn't worth it the abstraction you get cause it is so minimal. I wouldn't be trying to abstract it even further, you are just over complicating something for no reason. Keep it simple.
Re: VSCode plugins
On Tuesday, 4 July 2017 at 06:26:52 UTC, Manu wrote: On 4 July 2017 at 14:59, bauss via Digitalmars-d < digitalmars-d@puremagic.com> wrote: On Tuesday, 4 July 2017 at 04:49:29 UTC, Manu wrote: If authors of both plugins are active here, I ask; why have 2 separate The same reason there are multiple editors. Errr. No. I don't think you can make an argument that one plugin performs in a way that conforms to some peoples taste more than others... they do exactly the same things, and even in the same way using the same tooling. There might be implementation quality differences, I don't know, but that leads to the conclusion that merging them would produce the best quality result. Personally I use dlang-vscode because it doesn't tak on an extra process used for communication. I can understand wanting to put common code into one location so that multiple editors can reuse it, but ultimately you end up writing the same code for the editors anyways. Just now instead of communicating with DCD/DScanner/etc it is doing the same thing just communicating with this new process now. It's also really buggy and you don't get any information when something goes wrong. When it does go wrong in code-d, the workspace-d crashes and you now lose access to every feature. Where as in dlang-vscode if something goes wrong with DCD you still have access to features covered by the other processes. So they are different, and I do have my preference after using both of them.
Re: VSCode plugins
On Tuesday, 4 July 2017 at 04:49:29 UTC, Manu wrote: I've been using code-d for a while, and it generally works well. I've also noticed there's another plugin available, which at the time I first looked, appeared to be older and less-featured than code-d. I've recently had a couple of colleagues ask me which plugin to install, and I noticed that both seem to be up-to-date these days, and this leads to confusion. Looking at the feature list, it appears that both plugins do mostly the same stuff. My feeling is, having 2 very similar plugins is confusing to potential users, and it undermines user confidence. Ie, users have the feeling that they're competing hacky things maintained by some guy, rather than something that's more 'official' with consolidated community support. I also tend to presume in these situations that the 'proper' one is the one with the most users/installs, but that's not clear either in this case. I know this has nothing to do with the truth, but it's about perception and first impressions. Little things matter. If authors of both plugins are active here, I ask; why have 2 separate plugins? I can't imagine any reason for divergence. I would be a lot more comfortable if there was only one with multiple contributors. Projects with many contributors always inspire a lot more confidence than multiple overlapping projects with one contributor each... So, is there a reason not to merge the projects beyond ego? hi, code-d author here. I personally think a merge of all of our features into one plugin would be a great idea but the problem is that the plugins work a lot differently in the code level. My plugin uses workspace-d to abstract dfmt, dcd and dscanner so the extension doesn't need to know about it and dlang-vscode simply uses the extensions directly. I am also planning on further abstracting code-d using serve-d and Microsoft's Language Server Protocol for a wider adoption and better support across editors, but that also means that the extension code will be mostly thrown out and converted to D. While this isn't such a big problem for me because most code was already in workspace-d, I think if we implemented all the features from dlang-vscode it would be a lot of work not to break things. And doing it the other way around (merging my code into dlang-vscode) would mean that all the abstraction goes away and that it would be a vscode only plugin. code-d is basically the same as the one for atom or sublime text, just with all the features implemented instead of just a subset. While I didn't really support atom or sublime text for a while, I still think it's a good idea to keep these projects around for anyone who wants to implement workspace-d or serve-d into their extension as example reference how to implement them. But if the authors of dlang-vscode could contact me on IRC for example (WebFreak on #d on freenode) we might be able to find a solution to improve the situation and either merge into one plugin or share some code and ideas.
Re: VSCode plugins
On Wednesday, 5 July 2017 at 18:12:21 UTC, bitwise wrote: Which is why it would be great to see 3+ active developers on each one ;) Take in account that WebFreak001 is working on serve-d... Microsoft language server protocol implementation for D using workspace-d. This program is basically a combination of workspace-d and most of code-d. The purpose of this project is to give every editor the same capabilities and editing features as code-d with even less code required on the editor side than with workspace-d due to a more widely available protocol. This is pretty much another abstraction layer on top of workspace-d to simplify and speed up extension development as most of the editor extension can now be written in D. His idea sound like a better future design...
Re: VSCode plugins
On Wednesday, 5 July 2017 at 08:18:59 UTC, MakersF wrote: Having instead 3 active people on a project means that a lot of improvement and consistent work can be put into it, also easing the work needed to accept PR from the community. Which is why it would be great to see 3+ active developers on each one ;)
Re: VSCode plugins
On Tuesday, 4 July 2017 at 04:49:29 UTC, Manu wrote: So, is there a reason not to merge the projects beyond ego? While both share the same tools used by pretty much all editor/IDE plugins for D, dlang-vscode requires *only* those, while code-d additionally requires workspace-d. YMMV, but that is why I used dlang-vscode exclusively.
Re: VSCode plugins
On Wednesday, 5 July 2017 at 02:46:05 UTC, Manu wrote: On 5 July 2017 at 12:37, bitwise via Digitalmars-d < digitalmars-d@puremagic.com> wrote: On Tuesday, 4 July 2017 at 04:49:29 UTC, Manu wrote: My feeling is, having 2 very similar plugins is confusing to potential users, and it undermines user confidence. Ie, users have the feeling that they're competing hacky things maintained by some guy, rather than something that's more 'official' with consolidated community support. I have to disagree with this. When I search for plugins and see a wide selection of completing products, it tells me that the language has a healthy ecosystem, with a lot of interested users. This in turn gives me faith in the language, and it's future, and makes me more comfortable investing time in it. I'm much more likely to forgive the bugs I find on the grounds that they will most likely be fixed. On the other hand, if there was only one plugin, and it was the "official" plugin, branded with "D Language Foundation" or "Digital Mars", this would paint a different, yet also positive picture for me. I'm glad we can agree on that second point :) On the former point; I personally can sympathise with that opinion only in the context of being a nerd. It is my experience that most professional programmers I've ever worked with are NOT nerds, they are just people who have a job. Most people aren't interested in 'ecosystem health', they are interested in authority, and intend/prefer to conform with the accepted standards. The worst thing they can see is a 'vibrant' ecosystem. It looks like 'linux nonsense' to these people. I have to agree with that. As you can see both plugins are wrappers around other tools (good, no wheel reinvention), and they offer some functionality on top. All that follows applies because of this: using the same tools underneath means that the same results are provided. There is no difference in functionality, only on how it is exposed to the user. https://github.com/Pure-D/code-d/blob/master/README.md https://github.com/dlang-vscode/dlang-vscode/blob/master/README.md The main difference (and I'm fairly sure pain point as well for new users, at least for me) is how these tools are installed or expected on the system. UX is something that takes a bit of time and it's not always fun (need to test many different configurations, support different systems which do things in different ways) and I really see no point in duplicating this tedious work. And if you look at the contributors tab, you see that both projects are not in a healthy state: one is developed solely by WebFreak001 and the other is split 3/4 and 1/4 between the two authors. Which means that if one of them leaves the project (because of work,family, persona issues, boredom, any situation which might happen in life) the project is likely going to stagnate and become dead. Having instead 3 active people on a project means that a lot of improvement and consistent work can be put into it, also easing the work needed to accept PR from the community. I understand and appreciate the amount of work the developers of the two extensions put into them, but I think it's fair to accept that the current situation is not the best one for the users and the community.
Re: VSCode plugins
On 5 July 2017 at 12:37, bitwise via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On Tuesday, 4 July 2017 at 04:49:29 UTC, Manu wrote: > >> My feeling is, having 2 very similar plugins is confusing to potential >> users, and it undermines user confidence. Ie, users have the feeling that >> they're competing hacky things maintained by some guy, rather than >> something that's more 'official' with consolidated community support. >> > > I have to disagree with this. When I search for plugins and see a wide > selection of completing products, it tells me that the language has a > healthy ecosystem, with a lot of interested users. This in turn gives me > faith in the language, and it's future, and makes me more comfortable > investing time in it. I'm much more likely to forgive the bugs I find on > the grounds that they will most likely be fixed. > > On the other hand, if there was only one plugin, and it was the "official" > plugin, branded with "D Language Foundation" or "Digital Mars", this would > paint a different, yet also positive picture for me. > I'm glad we can agree on that second point :) On the former point; I personally can sympathise with that opinion only in the context of being a nerd. It is my experience that most professional programmers I've ever worked with are NOT nerds, they are just people who have a job. Most people aren't interested in 'ecosystem health', they are interested in authority, and intend/prefer to conform with the accepted standards. The worst thing they can see is a 'vibrant' ecosystem. It looks like 'linux nonsense' to these people.
Re: VSCode plugins
On Tuesday, 4 July 2017 at 04:49:29 UTC, Manu wrote: My feeling is, having 2 very similar plugins is confusing to potential users, and it undermines user confidence. Ie, users have the feeling that they're competing hacky things maintained by some guy, rather than something that's more 'official' with consolidated community support. I have to disagree with this. When I search for plugins and see a wide selection of completing products, it tells me that the language has a healthy ecosystem, with a lot of interested users. This in turn gives me faith in the language, and it's future, and makes me more comfortable investing time in it. I'm much more likely to forgive the bugs I find on the grounds that they will most likely be fixed. On the other hand, if there was only one plugin, and it was the "official" plugin, branded with "D Language Foundation" or "Digital Mars", this would paint a different, yet also positive picture for me.
Re: VSCode plugins
On 4 July 2017 at 23:27, Wulfklaue via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On Tuesday, 4 July 2017 at 04:49:29 UTC, Manu wrote: > >> I've been using code-d for a while, and it generally works well. I've >> also noticed there's another plugin available, which at the time I first >> looked, appeared to be older and less-featured than code-d. >> > > dlang-vscode.dlang seems to be more alive at pure minimum. Webfreak his > code-d is more up to date and more easy to install. Well, months ago it was > my impression. > > The issue is sometimes some plugin authors take breaks. And sometimes the > latest versions of D break something, making it impossible for the plugins > to compile the dependencies. So its better the have choice then. > > Is it better to have one plugin where both authors work upon. Yes. Will it > happen: Probably not. > Right, and this is why I'm trying to make a plea to the respective authors; please consider merging the projects. The situation is bad. If the only meaningful factor keeping these things separate is ego, then it's objectively bad for the community.
Re: VSCode plugins
On 4 July 2017 at 22:41, Meta via Digitalmars-d wrote: > >> It's just different users developing different solutions. I disagree with > the notion that having multiple competing, up to date implementations would > "undermine user confidence" in D. Quite the opposite, I'd think. > My point was, I feel like this is a case of different users developing the same solution though. Sure, it's reasonable to disagree, but I raise it because I have multiple counts of anecdotal evidence from prospective users that it is a problem. Let's consider more popular languages; C++ has probably 1000 times the number of users... so I may expect roughly 2000 competing solutions? Nope, there's only one (not even 2). C#, only one. Java, there are 2, but the obvious winner is maintained by Red Hat. Rust, there are 2, and no clear indicator which to choose (same problem). Etc. Anyway, I think it's a bad situation, and 3 colleagues have echoed the same sentiment independently. I could tolerate if there were meaningful differences between the solutions, but they're effectively the same solution, just written+maintained by different individuals. Projects with multiple contributors are usually stronger than single-person projects. Competing one-man projects shooting it out in the wild-west is not confidence inspiring at all, a single agreed solution supplied by an authority (ie, "dlang.org") or something is preferred. If some enthusiastic user wants to develop a meaningfully superior solution, power to them, but the former should exist for the conservative minds. Most people don't want to experiment, or take time trying to work out which solution is the better or accepted standard, they explicitly prefer to conform, and that should be the easiest path.
Re: VSCode plugins
On Tuesday, 4 July 2017 at 04:49:29 UTC, Manu wrote: I've been using code-d for a while, and it generally works well. I've also noticed there's another plugin available, which at the time I first looked, appeared to be older and less-featured than code-d. dlang-vscode.dlang seems to be more alive at pure minimum. Webfreak his code-d is more up to date and more easy to install. Well, months ago it was my impression. The issue is sometimes some plugin authors take breaks. And sometimes the latest versions of D break something, making it impossible for the plugins to compile the dependencies. So its better the have choice then. Is it better to have one plugin where both authors work upon. Yes. Will it happen: Probably not.
Re: VSCode plugins
On Tuesday, 4 July 2017 at 04:49:29 UTC, Manu wrote: I've been using code-d for a while, and it generally works well. I've also noticed there's another plugin available, which at the time I first looked, appeared to be older and less-featured than code-d. I've recently had a couple of colleagues ask me which plugin to install, and I noticed that both seem to be up-to-date these days, and this leads to confusion. Looking at the feature list, it appears that both plugins do mostly the same stuff. My feeling is, having 2 very similar plugins is confusing to potential users, and it undermines user confidence. Ie, users have the feeling that they're competing hacky things maintained by some guy, rather than something that's more 'official' with consolidated community support. I also tend to presume in these situations that the 'proper' one is the one with the most users/installs, but that's not clear either in this case. I know this has nothing to do with the truth, but it's about perception and first impressions. Little things matter. If authors of both plugins are active here, I ask; why have 2 separate plugins? I can't imagine any reason for divergence. I would be a lot more comfortable if there was only one with multiple contributors. Projects with many contributors always inspire a lot more confidence than multiple overlapping projects with one contributor each... So, is there a reason not to merge the projects beyond ego? It's just different users developing different solutions. I disagree with the notion that having multiple competing, up to date implementations would "undermine user confidence" in D. Quite the opposite, I'd think.
Re: VSCode plugins
On 4 July 2017 at 14:59, bauss via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On Tuesday, 4 July 2017 at 04:49:29 UTC, Manu wrote: > >> If authors of both plugins are active here, I ask; why have 2 separate >> > > The same reason there are multiple editors. > Errr. No. I don't think you can make an argument that one plugin performs in a way that conforms to some peoples taste more than others... they do exactly the same things, and even in the same way using the same tooling. There might be implementation quality differences, I don't know, but that leads to the conclusion that merging them would produce the best quality result.
Re: VSCode plugins
On Tuesday, 4 July 2017 at 04:49:29 UTC, Manu wrote: If authors of both plugins are active here, I ask; why have 2 separate The same reason there are multiple editors.
