Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
Am Sat, 27 Jan 2018 07:54:37 -0500 schrieb Steven Schveighoffer : > If I had to write swift code without xcode, it would take me so much > extra time, because there are things you just aren't going to get done > without the tools. Swift's libraries are also vast and IMO confusingly > named. Same thing with Java. Without an IDE you see ridiculously long names and a lot of typing. But they do follow conventions that are understood by Java IDEs. The dummy implementation of an interface for example is always called Adapter and can be auto-generated. All byte streams end in ...Stream and similar. This makes it easy to have mnemonics handy: "I'm looking for an input, buffered, stream". So you type IBS, auto-complete and the IDE expands that to InputBufferStream and takes care of the necessary import. Some languages are developed with IDE support in mind, but are then limited in expressiveness and not editor friendly. -- Marco
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
Am Sat, 27 Jan 2018 14:58:27 -0800 schrieb "H. S. Teoh" : > I use ctags with vim, and it's amazingly efficient: two keystrokes and > I'm right at the right file in the right place on top of the definition > of an identifier. Less than 1 second. Yet when I work with my coworker, > who uses a fancy GUI-based IDE, he has pull up the search function, > re-type the identifer that the cursor is already sitting on, then wait > for the thing to slowly churn through 50,000 source files looking for a > pattern match, then reach for the mouse and drag the scrollbar down a > long list of possible matches, then open the file, then navigate to the > right place in the file. An order of magnitude slower. His IDE doesn't seem all that fancy. All the ones I came across had "Jump to definition" (Visual Studio, IntelliJ, NetBeans, Eclipse, MonoDevelop, Turbo Delphi, Qt Creator, CoEdit). F3in Mono-D Ctrl+Shift+Up in CoEdit In Mono-D when you type in the opening '(' of a function call, it would pop up the documentation and show you which argument you are currently at. The arrow keys can be used to pick another function overload with the current one displayed as e.g. 1/3 in the corner. > As for renaming files, what has that got to do with Vim? It's just > ctrl-Z, `mv orig.d dest.d`. Maybe followed by `git add dest.d`. Two > seconds max. Again, being unable to work with the OS efficiently is not > a sign of an inherent flaw of the OS, just the inexperience of the user. In a well working IDE like Eclipse for Java, you'd click on the file, press F2 or whatever the key for a rename is, type the new name (without extension), press Enter and it would handle the file rename, git add and updating all references to the module/class in the loaded projects. Eat that editor user. :p I for one can't do Ctrl+Z, "mv orig.d dest.d" and "git add dest.d" in 2 seconds. I'm a slow typer. :( And that still doesn't update all my imports referring to orig.d. > T -- Marco
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Tuesday, 24 April 2018 at 07:15:38 UTC, Dave wrote: On Sunday, 28 January 2018 at 16:02:36 UTC, Jonathan M Davis wrote: > The problem is Teoh that learning a language in Vim or a > IDE are two totally different things. vim is a fantastic tool but it can be time consuming to configure. So I am wondering if some vim-D users would kindly share their vim setup for D and maybe even give some insights into their vim-D work-flow? Thx Dave You can checkout [0], [1] which have some nice info on setting up various IDEs and text editors for D. vim in specific already had syntax highlighting support by default. Just do `syntax on`. You can enable other features like standard library highlighting, util snips, etc, by looking at [2]. [0]:https://wiki.dlang.org/Editors [1]:https://wiki.dlang.org/IDEs [2]:https://wiki.dlang.org/D_in_Vim
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Sunday, 28 January 2018 at 16:02:36 UTC, Jonathan M Davis wrote: > The problem is Teoh that learning a language in Vim or a IDE > are two totally different things. vim is a fantastic tool but it can be time consuming to configure. So I am wondering if some vim-D users would kindly share their vim setup for D and maybe even give some insights into their vim-D work-flow? Thx Dave
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On 29/01/2018 9:35 AM, H. S. Teoh wrote: On Mon, Jan 29, 2018 at 01:23:49AM +, jmh530 via Digitalmars-d wrote: [...] It's probably that they view programming languages as a tool to get things done. Investing a lot of time in writing an IDE or plugin is time that could instead be spent writing programs that are useful in some other language. That's why languages with better tooling usually have a lot of support from companies. The companies recognize that investing in the tools can help make some of their programmers more productive and it's worth the cost. I wonder if the D foundation can help in this regard? Pay somebody to improve the tooling, etc.. T They are, dmd as a library :)
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Mon, Jan 29, 2018 at 01:23:49AM +, jmh530 via Digitalmars-d wrote: [...] > It's probably that they view programming languages as a tool to get > things done. Investing a lot of time in writing an IDE or plugin is > time that could instead be spent writing programs that are useful in > some other language. That's why languages with better tooling usually > have a lot of support from companies. The companies recognize that > investing in the tools can help make some of their programmers more > productive and it's worth the cost. I wonder if the D foundation can help in this regard? Pay somebody to improve the tooling, etc.. T -- "If you're arguing, you're losing." -- Mike Thomas
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Monday, 29 January 2018 at 00:18:40 UTC, H. S. Teoh wrote: Still, it's strange that given the number of people who demand first class IDE support, there are so few who are willing to contribute to improving it. It's probably that they view programming languages as a tool to get things done. Investing a lot of time in writing an IDE or plugin is time that could instead be spent writing programs that are useful in some other language. That's why languages with better tooling usually have a lot of support from companies. The companies recognize that investing in the tools can help make some of their programmers more productive and it's worth the cost.
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Sunday, January 28, 2018 16:18:40 H. S. Teoh via Digitalmars-d wrote: > On Sun, Jan 28, 2018 at 05:13:15PM -0700, Jonathan M Davis via Digitalmars-d wrote: > > Either way, more folks need to put some time and/or money towards IDE > > development for D, or the folks who want first class IDE support for D > > are never going to have what they want. > > Still, it's strange that given the number of people who demand first > class IDE support, there are so few who are willing to contribute to > improving it. I suspect that part of the problem is that if they really care that much about having an IDE, they don't get into D far enough to then put in the time to improving the situation. > > Personally, I don't really care, because I have no interest in such > > support. I have no problem if it gets implemented, and it probably is > > better for the D community if we have better IDE support, but it > > wouldn't improve my life any. If we're going to get improved tooling, > > I'd rather see more improvements to stuff like dub than better IDE > > support. So, I generally ignore the complaints about the lack of good > > IDE support. Either way, it's not something that I'm going to spend > > time on. I have too much on my TODO list already. > > [...] > > It doesn't really concern me either, but neither do I want the > indifference of the non-IDE folk to be misunderstood as active neglect. > But people will see what they want to see, so meh, I guess. All I can > say is, after coming to D, I did find some things not quite to my > liking, so I fixed them myself and submitted PRs. And so did many others > like me. And we're all better off for it. Now if only more from the IDE > crowd would do the same, things might be different... That's really the only way that anything gets done around here. Someone decides that they want something fixed or implemented, so they put in the time to do it themselves, and everyone benefits. Almost nothing happens because of folks posting about how they want something done. The net result is that what gets done is heavily biased towards what the folks willing to put in the time and effort want done. - Jonathan M Davis
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Sun, Jan 28, 2018 at 05:13:15PM -0700, Jonathan M Davis via Digitalmars-d wrote: > On Sunday, January 28, 2018 15:06:49 H. S. Teoh via Digitalmars-d wrote: [...] > > But the thing is, this is not a proprietary language where people > > are paid to do the grunt work. It's unrealistic to expect that > > random volunteers in the internet would go out of their way to > > implement support for something they don't use themselves. > > *Somebody* among the IDE crowd has to step up to do the work of > > improving IDE support; otherwise no amount of complaints is going to > > change a thing. > > True. If something is going to happen, someone has to step up - > probably multiple someones - and most of the folks who seem to be > interested in putting the time in to develop D libraries or tools > don't seem to be interested in IDE development. If more folks decide > to put in the time and effort, we may eventually get to where some of > these folks who want better IDE support want D's IDE support to be. Given the number of people routinely clamoring for better IDE support, it's disheartening how few among them are willing to step up to the plate to do the work for the benefit of the others. I don't know why that is... we don't seem to have the same problem for, say, vim support. Maybe it's because (much?) less effort is involved, so people feel it's less daunting to take it on. Or maybe the folks who use vim are simply more inclined to put in the effort to make things work, I don't know. > But part of my point is that good IDE support seems to be one of those > things that generally only happens when a company pays for it. That's > not always the same company who develops the language (if there even > is a company behind the language), but if no company pays for such > development, the odds are much, much lower that it's ever going to > happen. Then maybe we should recruit, say, a team lead from the Visual Studio team or something, to learn D, then he'll be able to pull the right strings to get better IDE support implemented. :-P > Either way, more folks need to put some time and/or money towards IDE > development for D, or the folks who want first class IDE support for D > are never going to have what they want. Still, it's strange that given the number of people who demand first class IDE support, there are so few who are willing to contribute to improving it. > Personally, I don't really care, because I have no interest in such > support. I have no problem if it gets implemented, and it probably is > better for the D community if we have better IDE support, but it > wouldn't improve my life any. If we're going to get improved tooling, > I'd rather see more improvements to stuff like dub than better IDE > support. So, I generally ignore the complaints about the lack of good > IDE support. Either way, it's not something that I'm going to spend > time on. I have too much on my TODO list already. [...] It doesn't really concern me either, but neither do I want the indifference of the non-IDE folk to be misunderstood as active neglect. But people will see what they want to see, so meh, I guess. All I can say is, after coming to D, I did find some things not quite to my liking, so I fixed them myself and submitted PRs. And so did many others like me. And we're all better off for it. Now if only more from the IDE crowd would do the same, things might be different... T -- People say I'm indecisive, but I'm not sure about that. -- YHL, CONLANG
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Sunday, January 28, 2018 15:06:49 H. S. Teoh via Digitalmars-d wrote: > On Sun, Jan 28, 2018 at 09:02:36AM -0700, Jonathan M Davis via > > It is true though that most of the core developers around here favor > > editors like vim or emacs and would prefer to focus their efforts on > > the language itself or libraries rather than on plugins for IDEs and > > whatnot, which is part of why D's IDE support isn't as good as some > > folks would like - the other big component being the lack of a company > > paying for folks to work on IDE support. I think that in general, > > that's how you end up with IDEs with first class support for a > > language. Sometimes, volunteer work will get you there, but that > > doesn't seem to be how it usually comes about - not from what I've > > seen in other languages anyway. > > But the thing is, this is not a proprietary language where people are > paid to do the grunt work. It's unrealistic to expect that random > volunteers in the internet would go out of their way to implement > support for something they don't use themselves. *Somebody* among the > IDE crowd has to step up to do the work of improving IDE support; > otherwise no amount of complaints is going to change a thing. True. If something is going to happen, someone has to step up - probably multiple someones - and most of the folks who seem to be interested in putting the time in to develop D libraries or tools don't seem to be interested in IDE development. If more folks decide to put in the time and effort, we may eventually get to where some of these folks who want better IDE support want D's IDE support to be. But part of my point is that good IDE support seems to be one of those things that generally only happens when a company pays for it. That's not always the same company who develops the language (if there even is a company behind the language), but if no company pays for such development, the odds are much, much lower that it's ever going to happen. Either way, more folks need to put some time and/or money towards IDE development for D, or the folks who want first class IDE support for D are never going to have what they want. Personally, I don't really care, because I have no interest in such support. I have no problem if it gets implemented, and it probably is better for the D community if we have better IDE support, but it wouldn't improve my life any. If we're going to get improved tooling, I'd rather see more improvements to stuff like dub than better IDE support. So, I generally ignore the complaints about the lack of good IDE support. Either way, it's not something that I'm going to spend time on. I have too much on my TODO list already. - Jonathan M Davis
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Sun, Jan 28, 2018 at 09:02:36AM -0700, Jonathan M Davis via Digitalmars-d wrote: [...] > I have yet to find an IDE where I didn't feel like I was playing with > primitive tools in comparison to vim. And as such, it's that much weirder to > me for someone want to use an IDE. But it _does_ take quite a lot to learn > vim. Starting out with it was a lot like when I first switched to dvorak. > For a while, I could barely type at all. And I suspect that it's that first > encounter with vim or emacs where it feels like you have to fight them to > even get what you can get out of notepad is why more folks don't use vim or > emacs. But a lot of programmers do eventually end up with one or the other > in spite of that. [...] Yeah, I think the barrier to entry is probably a big deterrent for the casual learner. I think this is more so in vi clones like vim than in emacs, because of that modal thing. When I first started using vim, it almost drove me to tears in frustration. But nowadays, I find any text editing that *isn't* modal awkward and annoying to use. :-P There's something about being able to navigate freely without "accidentally" making an edit that just seems to make more sense to me. But I don't think any non-vi user would understand what I'm talking about. > > As far as learning a new language is concerned, though, IMO that has > > nothing to do with what IDE or editor you use or don't use. The > > idea is to learn the underlying paradigms and principles in > > programming languages in general, which is standard curriculum in > > universities AFAIK, and once you understand that, picking up a new > > language is easy. > > Learning a new language is always a bit of work, but once you > understand the underlying concepts and have use a language or two, > it's generally straightforward to learn a new language. The thing is, the majority of languages out there today are imperative; that means once you know how an imperative language works, you're already halfway to learning *all* of those languages. The other half is just learning keywords and standard identifiers that map to standard imperative concepts. Even with non-imperative languages like Lisp or Haskell, once you've learned the concepts behind the functional paradigm, learning another functional language is easy. Of course, this depends on being able to see through the external trappings of a language and discern its underlying principles; otherwise you have to start from scratch with every new language. [...] > Either way, I've seen a whole range of what programmers do and prefer in > their code editors. The youngest programmers do tend to use the standard IDE > for a language (in which case, many of them would initially feel a bit lost > with something like D), but that's often just a question of them not having > found something better yet. For many of them, even if they don't end up with > vim or emacs, they'll end up with something like sublime or notepad++. And > yes, some do stick with IDEs, but a lot don't. I think that part of that > tends to depend on the programming language or OS that's being used. I actually used to use Notepad++ or some related clone before I learned vim. But now, there's simply no comparison. The drive towards user- friendliness and general accessibility by MS and other IDE vendors is a double-edged sword; OT1H it's great that these nicely packaged software have made programming more accessible to a vast number of people who otherwise may not have gotten into it. But OTOH, it has also produced a kind of misconception that programming is "easy", and a sense of entitlement that everything must be handed to you on a silver platter. Unfortunately, the harsh reality is that programming is inherently hard, and if you want to write good code you'd better get ready to put in the effort to think (hard!) about your programming problem. Getting past the initial learning curve of syntax and library, that IDE's are purportedly good for, is only barely scratching the surface of it. [...] > It is true though that most of the core developers around here favor > editors like vim or emacs and would prefer to focus their efforts on > the language itself or libraries rather than on plugins for IDEs and > whatnot, which is part of why D's IDE support isn't as good as some > folks would like - the other big component being the lack of a company > paying for folks to work on IDE support. I think that in general, > that's how you end up with IDEs with first class support for a > language. Sometimes, volunteer work will get you there, but that > doesn't seem to be how it usually comes about - not from what I've > seen in other languages anyway. But the thing is, this is not a proprietary language where people are paid to do the grunt work. It's unrealistic to expect that random volunteers in the internet would go out of their way to implement support for something they don't use themselves. *Somebody* among the IDE crowd has
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Sunday, January 28, 2018 18:11:09 arturg via Digitalmars-d wrote: > On Sunday, 28 January 2018 at 17:51:19 UTC, Jonathan M Davis > > wrote: > > Hmm. Thanks. I'll have to check that out. I haven't done > > anything with folds in ages. > > > > Fortunately, I don't have to do anything with python right now > > though. The main reason that I used it before was so that I > > could have cross-platform scripts at a previous job when I > > couldn't use D (if it were for use by more than just me, I > > couldn't use D, because no one else in my group was doing > > anything with D and it wasn't part of our build system) - that > > and even if I had to write something Windows-specific, writing > > it in Python was worlds better than writing it in batch. > > > > Right now, I'm able to use D for work, so I'm much more likely > > to just write scripts in D. > > in C++ you have header files as an overview of a type in D and > other languages you can use code folding when you dont use any > plugins. I've use folds before, but ultimately, I decided that I didn't like them. I just don't like having sections of a file being hidden. - Jonathan M Davis
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Sunday, 28 January 2018 at 17:51:19 UTC, Jonathan M Davis wrote: Hmm. Thanks. I'll have to check that out. I haven't done anything with folds in ages. Fortunately, I don't have to do anything with python right now though. The main reason that I used it before was so that I could have cross-platform scripts at a previous job when I couldn't use D (if it were for use by more than just me, I couldn't use D, because no one else in my group was doing anything with D and it wasn't part of our build system) - that and even if I had to write something Windows-specific, writing it in Python was worlds better than writing it in batch. Right now, I'm able to use D for work, so I'm much more likely to just write scripts in D. - Jonathan M Davis in C++ you have header files as an overview of a type in D and other languages you can use code folding when you dont use any plugins.
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Sunday, January 28, 2018 17:32:30 arturg via Digitalmars-d wrote: > On Sunday, 28 January 2018 at 16:02:36 UTC, Jonathan M Davis > > wrote: > >> Erm, you do realize that Vim has built-in commands for > >> navigating nested brackets and parentheses, right? And > >> automatic bracket closing is just a macro away. You don't even > >> need a plugin for that. > > > > LOL. One of the reasons that I hate python is that I can't hop > > between braces in it in vim, because it has no braces. It makes > > jumping from the top of a function to the bottom a lot harder. > > Even Pascal has begin and end (which I found out that vim > > understands when I was mucking around with some stuff in Pascal > > several months ago). > > if you set foldmethod=indent in vim you can navigate to the top > or bottom of the fold with [z and ]z, or check help fold-commands. Hmm. Thanks. I'll have to check that out. I haven't done anything with folds in ages. Fortunately, I don't have to do anything with python right now though. The main reason that I used it before was so that I could have cross-platform scripts at a previous job when I couldn't use D (if it were for use by more than just me, I couldn't use D, because no one else in my group was doing anything with D and it wasn't part of our build system) - that and even if I had to write something Windows-specific, writing it in Python was worlds better than writing it in batch. Right now, I'm able to use D for work, so I'm much more likely to just write scripts in D. - Jonathan M Davis
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Sunday, 28 January 2018 at 16:02:36 UTC, Jonathan M Davis wrote: Erm, you do realize that Vim has built-in commands for navigating nested brackets and parentheses, right? And automatic bracket closing is just a macro away. You don't even need a plugin for that. LOL. One of the reasons that I hate python is that I can't hop between braces in it in vim, because it has no braces. It makes jumping from the top of a function to the bottom a lot harder. Even Pascal has begin and end (which I found out that vim understands when I was mucking around with some stuff in Pascal several months ago). if you set foldmethod=indent in vim you can navigate to the top or bottom of the fold with [z and ]z, or check help fold-commands.
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Sunday, January 28, 2018 00:27:51 H. S. Teoh via Digitalmars-d wrote: > On Sun, Jan 28, 2018 at 12:03:38AM +, Benny via Digitalmars-d wrote: > [...] > > > The problem is Teoh that learning a language in Vim or a IDE are two > > totally different things. > > > > I used to program in Notepad because i grew up with PHP and knew it > > like the back of my hand. The result was very little need to see the > > documentation. The moment i found PHPStorm, i fell in love. Fast > > function jumping, remote tools, database at your fingertips, code > > checkers and hinters and all the other niceties. > > The problem is that people keep equating Vim with Notepad. It *may* be > true that Vim sucks, but the reason implied by the comparison to Notepad > makes no sense. It's like saying Windows 10 sux because MSDOS sucked. > It simply doesn't follow logically. Comparing vim to notepad would be a comparison that I don't understand at all. Even if you're just talking really basic commands, it makes notepad look like a typewriter. If anything, I would have compared IDEs to notepad due to how poor their code editing capabilities are. IDEs add lots of nice tools for refactoring code and the like, but their actual text editing capabilities tend to be only a bit above notepad. This reminds me of this old stackoveflow question: https://stackoverflow.com/questions/2695919 > Erm, you do realize that Vim has built-in commands for navigating nested > brackets and parentheses, right? And automatic bracket closing is just a > macro away. You don't even need a plugin for that. LOL. One of the reasons that I hate python is that I can't hop between braces in it in vim, because it has no braces. It makes jumping from the top of a function to the bottom a lot harder. Even Pascal has begin and end (which I found out that vim understands when I was mucking around with some stuff in Pascal several months ago). > > Its the same issue i personally have with languages that get lazy and > > trow out readability in exchange for less keystrokes. You can at times > > tell what development ides a language uses simply by looking at the > > language. Everything awkwardly shortcut like "fn" and other shorthand > > ( but what do make it much more brain taxing for anybody new ). > > AFAICT, D has a pretty good balance between needlessly unreadably > shortened names like that awful *nix `creat()` or `awk`, and Java's > NeedlesslyVerboseCompletelyRedundantRepetitiousIdentifiers. I personally > prefer shorter names than what D has, but I think what D has does serve > pretty well in terms of being comprehensible to newbies, and still being > typable without giving your wrist an aneurysm. There used to be a couple > of pretty bad names, but IIRC we've weeded them out and replaced them > with better ones by now. LOL. You should read the grammar specification for Java. It has the longest identifier names I have ever seen. It just seemed so sadly perfect that Java's own grammar specification had ridiculously long identifier names. I think that overall D has struck a good balance with identifier names, but that's always a bit subjective - e.g. there was a rather long bikeshedding thread once where some folks complained that Clock.currTime wasn't currentTime or now. I'd always kind of assumed that if someone were going to complain about it, they'd start arguing about how many r's it had, not that I shouldn't have abbreviated an obvious word. > > As a side note, despite working years in Vim, i still prefer a normal > > but well equip IDE because there are just some things VIM is not good > > at ( unless you customize it to hell with 100's of plugins what tends > > to take years to find your sweet spot and build up the know how to use > > them all perfectly ). VIM with all the plugins is simply a IDE, just > > one where you do not move your hands too much away from the keyboard. > > Actually, I hardly use *any* Vim plugins. Maybe just a couple of > standard ones that are already configured by default. But you're right > that it's basically an IDE, if your baseline for comparison is Notepad. > That's something people don't seem to get, for some reason. But oh well. > Their loss, not mine. The only plugin that I really use at this point is minibufexpl, which shows your buffers at the top of the window. It does allow you to then navigate them with the mouse, but I mostly just use it so that I can see which buffers I have open and which I'm on. I don't even use ctags, and I certainly don't use anything like dscanner or dcd. I probably should find more plugins to boost my productivity, but I also should spend more time leaning stray vim commands - just like I should spend more time learning stray *nix commands. There are so many capabilities there that I barely use or don't even know about. I suspect that most vim users use less than 5% of its capabilities given the insane amount of stuff it can do without getting plugins involved at all. But even if I w
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Sunday, 28 January 2018 at 08:40:35 UTC, Basile B. wrote: On Thursday, 25 January 2018 at 15:20:15 UTC, Benny wrote: You know you're not the first coming with this topic. I've developped a theory. You guys are looking for excuses to not get into D. If IDE were okay you would find something else. That's the wrong mood to have with someone just reporting what's a fact: D Langland IDE quality is FAR lower than the major competitors out there. Full stop. /P
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Thursday, 25 January 2018 at 15:20:15 UTC, Benny wrote: After months doing a different project, i need a programming language for a new client with specific needs. D comes to mind. As usual that involves downloading the compiler (dmd and ldc). So, lets install Visual Studio Code: * Code-D Plugin: - Syntax highlight *check* - After saving: DMD error suggestions in the code. *check* - Limited name suggestion ( VSC functionality not the plugin ) only by forcing VSC (ctrl+space). - ... and nothing else... So lets try the next plugin: * Serve-D Plugin: - Syntax highlight *check* - After saving: DMD error suggestions in the code. *check* - Limited name suggestion ( VSC functionality not the plugin ) only by forcing VSC (ctrl+space). - ... and nothing else... Frustration level increasing. Lets try the next one: * D-Language Plugin: - Syntax highlight *check* - Limited name suggestion ( VSC functionality not the plugin ) only by forcing VSC (ctrl+space). - ... and nothing else... Ok ... so Visual Studio Code its Dscanner, DCD, Workspace-d do not properly work or some other issue. Then lets try IntelliJ Community Edition. After a long time getting all the dependancies and compiling them... Dscanner - DCD ( client and server ) - Dfix ... * D Language Plugin: - Syntax highlight *check* - Way too many items like writefln, import etc all being marked as unknown. Clearly wrong. - ... and nothing else... - Socket error (std.socket.xxx) on closing IntelliJ Conclusion is that it feels like the whole D infrastructure is very, very poorly supported. Other issues like delays that some of the D plugins seem to introduce: * Like "loading ..." popups that do nothing but always show up ( Visual Studio Code ) * Like pressing "dot" expecting a response, waiting 2 seconds and then finally something happening ( IntelliJ plugin ) but simply dumping every possible name and variable ( zero intelligent code support ) I assume that this is again broken DCD or Dscanner. And no, no errors in the console of VSC or anything like that. Let me summarize my personal D editor experience in the last 1+ year. * Attempts at getting D editor support going: 6 or 7. * Amount of times things worked out of the box. One! And this was limited to about a few minutes and after that all suggestions broke again. * Amount of times dscanner or dcd or other plugins broke because of DMD newest version broke: 4 * Tested on different machines: 4! They all have one thing in common: Windows 10 * Tested on different Windows installations: 3 * Tested on different "version" of Windows 10: 3 * Amount of times complaining to the plugin authors: Too many to count. * Time spend on these tests / issues: Easily 50 hours or more. * Frustration level: Again, like each time before EXTREME! Please do not give me the company line that i need to report issues. I did so many times. It is tiring playing guinea pig, complaining and reporting, waiting for things to get fixed and still seeing things break again or simply not working properly. I can download Go, C#, C, C++, Delphi, Rust and get proper working plugins for the above mentioned editors but D is always that frustrating problem child. And i can not blame the plugin authors because the issues always seem to stem from the D plugins ( dcd, dscanner, ... ). Like dscanner changing its binary location between builds from folder root to /bin folder, breaking the plugin authors there system as it expected it in the folder root. Maybe things work great in a few very specific editor but in my personal experience, D its editor support is non stop frustrating. And i suspect that this complaint is not new. Clearly there is infrastructure in place for automated testing the compiler but it feels like there is a total lack of infrastructure for everything that surround it. Beyond maybe a few editors that the core team uses? My personal opinion: Too much in the D landscape is so individualist and not properly cross platform tested, that it results in pure frustration for the end developer. You know you're not the first coming with this topic. I've developped a theory. You guys are looking for excuses to not get into D. If IDE were okay you would find something else. Did you know for example that with a decent D IDE you can press "F1" and get directly the html help: https://www.youtube.com/watch?v=9Ncf6n4yniI&list=PLzk8A0LUvEOV-OMdz09jfOahwnKoA2na_&index=1 ?
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Sun, Jan 28, 2018 at 12:03:38AM +, Benny via Digitalmars-d wrote: [...] > The problem is Teoh that learning a language in Vim or a IDE are two > totally different things. > > I used to program in Notepad because i grew up with PHP and knew it > like the back of my hand. The result was very little need to see the > documentation. The moment i found PHPStorm, i fell in love. Fast > function jumping, remote tools, database at your fingertips, code > checkers and hinters and all the other niceties. The problem is that people keep equating Vim with Notepad. It *may* be true that Vim sucks, but the reason implied by the comparison to Notepad makes no sense. It's like saying Windows 10 sux because MSDOS sucked. It simply doesn't follow logically. > But for anybody who is not a master of a language or even > intermediate, a good IDE can make one so much more productive compared > to the same person just relying on a default notepad type environment. > The fact that a good IDE expands the methods from a class, it shows > you the basic help / buildup of the methods calls so you know exactly > where you write what, without the need to visit the developers > documentation website. I learned D from scratch using only Vim, Andrei's TDPL book, and reading Phobos source code (which is surprisingly easy to read, compared to other languages' standard lib code *cough*ahem*glibc*sneeze*). At the time I started, the online docs sucked, and might as well be disregarded. Things have progressed a lot since then. I don't understand the fear of needing to *gosh* open your browser and visiting the developers documentation website. I don't hear of people complaining of needing to take driving lessons in order to get a driver's license, and here we're talking about *programming* in a Turing-complete language, which is something FAR more complex than driving a car ever will be. But hey, I'm just an outdated old geezer, what do I know anyway? [...] > And for the people who are used to a language, a IDE can still be > useful by increasing productivity as you simply do ... example "fu" > ... enter ... "function " or automated braked closing, or error > indicators when you forget something so you do not wast your time > discovering a stupid issue during compilation. Erm, you do realize that Vim has built-in commands for navigating nested brackets and parentheses, right? And automatic bracket closing is just a macro away. You don't even need a plugin for that. > Its the same issue i personally have with languages that get lazy and > trow out readability in exchange for less keystrokes. You can at times > tell what development ides a language uses simply by looking at the > language. Everything awkwardly shortcut like "fn" and other shorthand > ( but what do make it much more brain taxing for anybody new ). AFAICT, D has a pretty good balance between needlessly unreadably shortened names like that awful *nix `creat()` or `awk`, and Java's NeedlesslyVerboseCompletelyRedundantRepetitiousIdentifiers. I personally prefer shorter names than what D has, but I think what D has does serve pretty well in terms of being comprehensible to newbies, and still being typable without giving your wrist an aneurysm. There used to be a couple of pretty bad names, but IIRC we've weeded them out and replaced them with better ones by now. [...] > As a side note, despite working years in Vim, i still prefer a normal > but well equip IDE because there are just some things VIM is not good > at ( unless you customize it to hell with 100's of plugins what tends > to take years to find your sweet spot and build up the know how to use > them all perfectly ). VIM with all the plugins is simply a IDE, just > one where you do not move your hands too much away from the keyboard. Actually, I hardly use *any* Vim plugins. Maybe just a couple of standard ones that are already configured by default. But you're right that it's basically an IDE, if your baseline for comparison is Notepad. That's something people don't seem to get, for some reason. But oh well. Their loss, not mine. > As your example of your colleagues: a IDE where it takes ages to jump > to a definition in a file, is simply a incomplete IDE. Or maybe those > colleges have not master the IDE. I know for a fact from myself that > there is a massive amount of things still "hiding" in Jetbrain there > products or Visual Studio Code that can make me more productive but > you learn over time or when you stumble upon it. The thing about these fancy GUI IDEs is that *somebody* must have thought of a particular feature and implemented it for you, before you can use it. If you happen to need something the developers didn't think of, you're stuck up the creek without a paddle. Editors like Vim, OTOH, provide you an entire editing *language* to build upon; if the defaults don't have some feature you need, you have the power to add the feature yourself without needing to hack Vim source code
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Saturday, 27 January 2018 at 22:58:27 UTC, H. S. Teoh wrote: I never said we should not offer good IDE support, in fact I said that we *need* good IDE support. But that in no way justifies the wrong claim that you can't be productive without an IDE. In fact, I find myself *more* productive without needing a memory-hogging, CPU-hogging GUI program that requires taking my hands off the keyboard all the time, just to edit code. But I'm sure you think the same about Vim/Emacs, so we're square. :-) The problem is Teoh that learning a language in Vim or a IDE are two totally different things. I used to program in Notepad because i grew up with PHP and knew it like the back of my hand. The result was very little need to see the documentation. The moment i found PHPStorm, i fell in love. Fast function jumping, remote tools, database at your fingertips, code checkers and hinters and all the other niceties. But for anybody who is not a master of a language or even intermediate, a good IDE can make one so much more productive compared to the same person just relying on a default notepad type environment. The fact that a good IDE expands the methods from a class, it shows you the basic help / buildup of the methods calls so you know exactly where you write what, without the need to visit the developers documentation website. It massif increases the adoption rate of a language, when your new to a language or not a 10 year expert. And for the people who are used to a language, a IDE can still be useful by increasing productivity as you simply do ... example "fu" ... enter ... "function " or automated braked closing, or error indicators when you forget something so you do not wast your time discovering a stupid issue during compilation. Its the same issue i personally have with languages that get lazy and trow out readability in exchange for less keystrokes. You can at times tell what development ides a language uses simply by looking at the language. Everything awkwardly shortcut like "fn" and other shorthand ( but what do make it much more brain taxing for anybody new ). Advanced programmers have the skills to make new languages, unlike beginner programmers but they also are so used to a specific environment that they build up to speed up, over the year, that they assume that everybody else can get going just as fast as they are. As a side note, despite working years in Vim, i still prefer a normal but well equip IDE because there are just some things VIM is not good at ( unless you customize it to hell with 100's of plugins what tends to take years to find your sweet spot and build up the know how to use them all perfectly ). VIM with all the plugins is simply a IDE, just one where you do not move your hands too much away from the keyboard. As your example of your colleagues: a IDE where it takes ages to jump to a definition in a file, is simply a incomplete IDE. Or maybe those colleges have not master the IDE. I know for a fact from myself that there is a massive amount of things still "hiding" in Jetbrain there products or Visual Studio Code that can make me more productive but you learn over time or when you stumble upon it. From my point of view, without a working IDE its much more difficult for a non-specific-language to learn and get better at the language. And again, VIM with the right plugins is a IDE, simple as that. Its annoying that people do not see this. The big difference is that VIM is designed around not moving your hand to your mouse and that is its major strength. On a side note: The issue i had with the plugins, well one of the plugin authors found the issue and it came down to it that the D compiler had a regression that effect DCD. I remember mentioning before as how many times the compiler ends up breaking code. Going over the D release list, you see way too many times: Major release - fix - fix, Major release - fix, Major release - fix - fix... What indicates to me a lack of cross platform testing. Especially the amount of regressions surprises even me. It feels like too much focus is put upon new features and too few upon a test setup that does not only tests the compiler but also all the dub packages.
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Sat, Jan 27, 2018 at 06:18:02PM +, Dgame via Digitalmars-d wrote: [...] > It's nice that this works for you, but I strongly believe that most of > the programmers who are willing to try something new are younger and I > also think that most of them don't use VIM/Emacs on a daily basis. > It's impressive that you can do it and I'm sure it works for you > pretty well, but I doubt that younger programmers do the same - the > hurdle to work with those tools is way to high at the start. You know, before I started using Vim, I hated it and found it difficult and counterintuitive to use. Then one day my then-boss convinced me to give it an honest try. I did, and I still hated it... but I kept at it, and as time went by, it started to "click", and suddenly it dawned on me that it's not "just" an editor; it's an *editing language*. Then new vistas opened up to me, that allowed me to things like routinely edit 8000-line source files without getting lost, and to do so far more efficiently than any GUI can ever hope to be. Even today, I'm learning new things to do with it that can improve my productivity even more. I'd never go back to my babyish days of point-and-grunt. Was it an easy learning curve? I won't lie -- it's not. It takes time and dedication, something this coddled generation seems unable to grasp, it seems. But the rewards far outweigh the investment. > One of our programmers use VIM too, but on a regular basis he has > problems like finding/renaming files/variables or optimize imports or > code formatting. I bet you can do that with the right tools and a lot > of time as good as an IDE can do it, but the IDE can do that out of > the box without consuming your time. This sounds to me like inexperience. If one doesn't know the ins and outs of his tools, it's not surprising that he has trouble being efficient at doing his work. I use ctags with vim, and it's amazingly efficient: two keystrokes and I'm right at the right file in the right place on top of the definition of an identifier. Less than 1 second. Yet when I work with my coworker, who uses a fancy GUI-based IDE, he has pull up the search function, re-type the identifer that the cursor is already sitting on, then wait for the thing to slowly churn through 50,000 source files looking for a pattern match, then reach for the mouse and drag the scrollbar down a long list of possible matches, then open the file, then navigate to the right place in the file. An order of magnitude slower. Of course, having said that, some of my *other* coworkers who also use vim are equally slow, if not slower, because they haven't learnt how to use it to the max. As I said, that says to me "inexperience" rather than "the tool sux". As for renaming files, what has that got to do with Vim? It's just ctrl-Z, `mv orig.d dest.d`. Maybe followed by `git add dest.d`. Two seconds max. Again, being unable to work with the OS efficiently is not a sign of an inherent flaw of the OS, just the inexperience of the user. > It's like I said - if you mainly used VIM/Emacs you think everything > is fine and would not try an IDE - but that's not what nowadays > happens to new programmers. And to make D appealing to them, D has to > offer good IDE support or it will remain as a hobby language with very > few exceptions. I never said we should not offer good IDE support, in fact I said that we *need* good IDE support. But that in no way justifies the wrong claim that you can't be productive without an IDE. In fact, I find myself *more* productive without needing a memory-hogging, CPU-hogging GUI program that requires taking my hands off the keyboard all the time, just to edit code. But I'm sure you think the same about Vim/Emacs, so we're square. :-) To each his own. T -- Music critic: "That's an imitation fugue!"
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Saturday, 27 January 2018 at 18:18:02 UTC, Dgame wrote: One of our programmers use VIM too, but on a regular basis he has problems like finding/renaming files/variables or optimize imports or code formatting. I bet you can do that with the right tools and a lot of time as good as an IDE can do it, but the IDE can do that out of the box without consuming your time. It's like I said - if you mainly used VIM/Emacs you think everything is fine and would not try an IDE - but that's not what nowadays happens to new programmers. And to make D appealing to them, D has to offer good IDE support or it will remain as a hobby language with very few exceptions. I think it depends on what we consider good IDE support. We can use C++ as baseline, so syntax highlighting, code completion and debugging. Or we can take it a level higher, and go into Java/C# territory, with stuff like automatic variable renaming across the entire project, extracting fields into class etc. While I think D IDEs, when they work, aren't that much behind C++ IDEs (never really tried debugging D though), but they don't really have a chance with Java/C# IDEs and probably never will. Given how dynamic D can be with CTFE/mixins, you can't do the kind of safe refactoring that those IDEs allow. The same applies to C++, Rust, and probably Go as well.
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Thursday, 25 January 2018 at 21:18:23 UTC, Benny wrote: I am sorry if this sounds cruel but for now D is on the back burner and my next project will probably be in Rust. If you can cope with Rust ergonomics, I see no reason to not try it. IDEs always worked perfectly for you? My experience is different even with paid state of the art flagship IDEs.
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Saturday, 27 January 2018 at 17:55:06 UTC, H. S. Teoh wrote: On 1/26/18 5:50 PM, Dgame wrote: [...] > My impression so far is that most of the D users love to > program in a tiny editor without the features which modern > IDE's gives you. That's impressive, but outdated and even a > bit silly if the project is bigger. In any company I've > been so far we've used IDE's, because their feature-set and > tools take so much work away from you - I don't want to miss > them anymore. Nowadays, the majority of programmers who are > willing to try new/others programming languages, think so > too. I'm somewhat sure that this unneccessary hurdle is one > of D's biggest mistakes. [...] Not to negate the fact that we *do* need to improve IDE support, but the claim that IDEs are "required" for large projects is false, and so is the claim that non-IDE editors are "tiny". At my day job, I work with a very large codebase (50,000+ source files, and yes, I mean 50 *thousand*, not hundred), and vim has more than sufficed for the past 10 years. And vim does a *lot* more than what some people tend to falsely believe that it's "just" another "tiny" text editor on the order of NotePad. This doesn't excuse our poor IDE support, of course, we do need to improve our IDE support. But it's tiresome to keep reading these unfounded claims that IDE's are somehow inherently superior to powerful editors like vim, which is not necessarily the case. T It's nice that this works for you, but I strongly believe that most of the programmers who are willing to try something new are younger and I also think that most of them don't use VIM/Emacs on a daily basis. It's impressive that you can do it and I'm sure it works for you pretty well, but I doubt that younger programmers do the same - the hurdle to work with those tools is way to high at the start. One of our programmers use VIM too, but on a regular basis he has problems like finding/renaming files/variables or optimize imports or code formatting. I bet you can do that with the right tools and a lot of time as good as an IDE can do it, but the IDE can do that out of the box without consuming your time. It's like I said - if you mainly used VIM/Emacs you think everything is fine and would not try an IDE - but that's not what nowadays happens to new programmers. And to make D appealing to them, D has to offer good IDE support or it will remain as a hobby language with very few exceptions.
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
> On 1/26/18 5:50 PM, Dgame wrote: [...] > > My impression so far is that most of the D users love to program in > > a tiny editor without the features which modern IDE's gives you. > > That's impressive, but outdated and even a bit silly if the project > > is bigger. In any company I've been so far we've used IDE's, > > because their feature-set and tools take so much work away from you > > - I don't want to miss them anymore. Nowadays, the majority of > > programmers who are willing to try new/others programming languages, > > think so too. I'm somewhat sure that this unneccessary hurdle is one > > of D's biggest mistakes. [...] Not to negate the fact that we *do* need to improve IDE support, but the claim that IDEs are "required" for large projects is false, and so is the claim that non-IDE editors are "tiny". At my day job, I work with a very large codebase (50,000+ source files, and yes, I mean 50 *thousand*, not hundred), and vim has more than sufficed for the past 10 years. And vim does a *lot* more than what some people tend to falsely believe that it's "just" another "tiny" text editor on the order of NotePad. This doesn't excuse our poor IDE support, of course, we do need to improve our IDE support. But it's tiresome to keep reading these unfounded claims that IDE's are somehow inherently superior to powerful editors like vim, which is not necessarily the case. T -- Indifference will certainly be the downfall of mankind, but who cares? -- Miquel van Smoorenburg
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On 1/26/18 5:50 PM, Dgame wrote: On Saturday, 27 January 2018 at 00:13:51 UTC, Benny wrote: On Saturday, 27 January 2018 at 00:08:17 UTC, Benny wrote: * Rust: Jetbrain IntelliJ + Rust plugin. It looks like it has become a official supported plugin by Jetbrain. Works perfectly out of the box. Impressive results and issue hinting. https://blog.jetbrains.com/blog/2017/08/04/official-support-for-open-source-rust-plugin-for-intellij-idea-clion-and-other-jetbrains-ides/ Yep, i was right. Its now a official support plugin by Jetbrain. And no offense but i doubt it has anything to do with Mozilla officially backing Rust but more a sign of popularity. Just as how Go got its own Editor by Jetbrain. My impression so far is that most of the D users love to program in a tiny editor without the features which modern IDE's gives you. That's impressive, but outdated and even a bit silly if the project is bigger. In any company I've been so far we've used IDE's, because their feature-set and tools take so much work away from you - I don't want to miss them anymore. Nowadays, the majority of programmers who are willing to try new/others programming languages, think so too. I'm somewhat sure that this unneccessary hurdle is one of D's biggest mistakes. As an IDE junkie I've noticed this correlation in the past too. I wonder which direction the causation runs--does D tend to appeal to the no-IDE crowd, or do IDE-prefering people abandon D since there hasn't been great IDEs support? Regardless I'm very pleased by the recent trends. The vs-code plugins are good and getting better, and DMD as a library should enable simpler and more complete language support in any IDE. I believe we're getting closer to the point where IDE junkies like me won't feel somewhat short-changed, and that's impressive for a community-driven language like D.
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On 1/26/18 7:50 PM, Dgame wrote: On Saturday, 27 January 2018 at 00:13:51 UTC, Benny wrote: On Saturday, 27 January 2018 at 00:08:17 UTC, Benny wrote: * Rust: Jetbrain IntelliJ + Rust plugin. It looks like it has become a official supported plugin by Jetbrain. Works perfectly out of the box. Impressive results and issue hinting. https://blog.jetbrains.com/blog/2017/08/04/official-support-for-open-source-rust-plugin-for-intellij-idea-clion-and-other-jetbrains-ides/ Yep, i was right. Its now a official support plugin by Jetbrain. And no offense but i doubt it has anything to do with Mozilla officially backing Rust but more a sign of popularity. Just as how Go got its own Editor by Jetbrain. My impression so far is that most of the D users love to program in a tiny editor without the features which modern IDE's gives you. That's impressive, but outdated and even a bit silly if the project is bigger. In any company I've been so far we've used IDE's, because their feature-set and tools take so much work away from you - I don't want to miss them anymore. Nowadays, the majority of programmers who are willing to try new/others programming languages, think so too. I'm somewhat sure that this unneccessary hurdle is one of D's biggest mistakes. While I understand using an IDE is appealing, I want to point to a possible reverse correlation: If I had to write swift code without xcode, it would take me so much extra time, because there are things you just aren't going to get done without the tools. Swift's libraries are also vast and IMO confusingly named. On the other hand, I can write a d project without an IDE much quicker. Perhaps it's because I've been using D for almost 11 years. Perhaps it's because I'm intimately involved with the libraries. Or maybe it's because D libraries are easier to remember. I don't know the real reason, but to me, the command line tools seem to be enough for D. I just find it interesting that someone such as myself who prefers vi, and command line tools, still wants to use xcode for other languages. Is it me or is it the language? Or is it the project (in swift, I'm writing a full iOS app, in D just libraries and command line tools)? That being said, I wouldn't mind an xcode integration for D to try out :) -Steve
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Thursday, 25 January 2018 at 15:20:15 UTC, Benny wrote: I can download Go, C#, C, C++, Delphi, Rust and get proper working plugins for the above mentioned editors but D is always that frustrating problem child. And i can not blame the plugin authors because the issues always seem to stem from the D plugins ( dcd, dscanner, ... ). I would like to point (again) that implementing proper and intelligent code completion for D is just ridiculously hard, and by that I mean *hard*. Seriously, one requires something as complex as the compiler itself. Oh and people actually did try to use compiler but guess what? Dmd doesn't do memory management of any kind (it was still the case last time I checked) it allocates and never frees, thus it's rather unfeasible to use dmd code for all those things. Also, the compiler is not fast enough for IDE usage anyway (ctfe, template heavy code...) so there is that. Maybe things work great in a few very specific editor but in my personal experience, D its editor support is non stop frustrating. And i suspect that this complaint is not new. From experience point I can tell the easiest and smartest IDE (plugin) *was* Mono-D¹. I say was because it doesn't support latest MonoDevelop version² and not maintained these days so you need to somehow find and install MonoDevelop 5 (you can find it here²). What you need to do is basically go to add-in manager, install "D Language Binding" from gallery, go to settings and set "Import Paths". If the compiler directory is not in the PATH you need to configure those too but that's about it. It even lets you open dub.json files as projects and some other nice stuff you can read in wiki³ (there are some outdated information so beware). The reason it's no longer maintained is as you can guess: it was a one man's show. ¹ https://github.com/aBothe/Mono-D ² https://github.com/aBothe/Mono-D/issues/648 ³ https://wiki.dlang.org/Mono-D
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Saturday, 27 January 2018 at 00:13:51 UTC, Benny wrote: On Saturday, 27 January 2018 at 00:08:17 UTC, Benny wrote: * Rust: Jetbrain IntelliJ + Rust plugin. It looks like it has become a official supported plugin by Jetbrain. Works perfectly out of the box. Impressive results and issue hinting. https://blog.jetbrains.com/blog/2017/08/04/official-support-for-open-source-rust-plugin-for-intellij-idea-clion-and-other-jetbrains-ides/ Yep, i was right. Its now a official support plugin by Jetbrain. And no offense but i doubt it has anything to do with Mozilla officially backing Rust but more a sign of popularity. Just as how Go got its own Editor by Jetbrain. My impression so far is that most of the D users love to program in a tiny editor without the features which modern IDE's gives you. That's impressive, but outdated and even a bit silly if the project is bigger. In any company I've been so far we've used IDE's, because their feature-set and tools take so much work away from you - I don't want to miss them anymore. Nowadays, the majority of programmers who are willing to try new/others programming languages, think so too. I'm somewhat sure that this unneccessary hurdle is one of D's biggest mistakes.
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Saturday, 27 January 2018 at 00:08:17 UTC, Benny wrote: * Rust: Jetbrain IntelliJ + Rust plugin. It looks like it has become a official supported plugin by Jetbrain. Works perfectly out of the box. Impressive results and issue hinting. https://blog.jetbrains.com/blog/2017/08/04/official-support-for-open-source-rust-plugin-for-intellij-idea-clion-and-other-jetbrains-ides/ Yep, i was right. Its now a official support plugin by Jetbrain. And no offense but i doubt it has anything to do with Mozilla officially backing Rust but more a sign of popularity. Just as how Go got its own Editor by Jetbrain.
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Friday, 26 January 2018 at 15:37:15 UTC, Benny wrote: On Friday, 26 January 2018 at 03:40:26 UTC, Rubn wrote: You seem to be short tempered You think after two days trying to get a series of plugins to work? you tried 2 plugins rather quickly, without even trying to see if there were configurations or other options you could use to get features working. Visual Studio Code: Code-D, Serve-D, D-Language Jetbrain: D-Language That is 4 plugins as described in the original post. Two of the same author, 2 from other authors. So that makes 3 different people there plugins. One may think a person can be salty after so many hours. Well one is an older version, which is why it's the same author. The Jetbrains plugin wasn't developed for a long time, I don't know the current state of it. Did you bother at all the create an issue on the respective github repos stating your issue? Did you look at the source at all for the plugins? They aren't terribly complicated, you could diagnose some issues yourself. - Limited name suggestion ( VSC functionality not the plugin ) only by forcing VSC (ctrl+space). - ... and nothing else... This is just not true... https://imgur.com/z6CZbjL.gif Well, if that actually worked, i will not be complaining here. Well, if it didn't work, that gif wouldn't exist.
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Thursday, 25 January 2018 at 15:20:15 UTC, Benny wrote: After months doing a different project, i need a programming language for a new client with specific needs. D comes to mind. As usual that involves downloading the compiler (dmd and ldc). So, lets install Visual Studio Code: * Code-D Plugin: - Syntax highlight *check* - After saving: DMD error suggestions in the code. *check* - Limited name suggestion ( VSC functionality not the plugin ) only by forcing VSC (ctrl+space). - ... and nothing else... So lets try the next plugin: * Serve-D Plugin: - Syntax highlight *check* - After saving: DMD error suggestions in the code. *check* - Limited name suggestion ( VSC functionality not the plugin ) only by forcing VSC (ctrl+space). - ... and nothing else... Frustration level increasing. Lets try the next one: * D-Language Plugin: - Syntax highlight *check* - Limited name suggestion ( VSC functionality not the plugin ) only by forcing VSC (ctrl+space). - ... and nothing else... Ok ... so Visual Studio Code its Dscanner, DCD, Workspace-d do not properly work or some other issue. Then lets try IntelliJ Community Edition. After a long time getting all the dependancies and compiling them... Dscanner - DCD ( client and server ) - Dfix ... * D Language Plugin: - Syntax highlight *check* - Way too many items like writefln, import etc all being marked as unknown. Clearly wrong. - ... and nothing else... - Socket error (std.socket.xxx) on closing IntelliJ Conclusion is that it feels like the whole D infrastructure is very, very poorly supported. Other issues like delays that some of the D plugins seem to introduce: * Like "loading ..." popups that do nothing but always show up ( Visual Studio Code ) * Like pressing "dot" expecting a response, waiting 2 seconds and then finally something happening ( IntelliJ plugin ) but simply dumping every possible name and variable ( zero intelligent code support ) I assume that this is again broken DCD or Dscanner. And no, no errors in the console of VSC or anything like that. Let me summarize my personal D editor experience in the last 1+ year. * Attempts at getting D editor support going: 6 or 7. * Amount of times things worked out of the box. One! And this was limited to about a few minutes and after that all suggestions broke again. * Amount of times dscanner or dcd or other plugins broke because of DMD newest version broke: 4 * Tested on different machines: 4! They all have one thing in common: Windows 10 * Tested on different Windows installations: 3 * Tested on different "version" of Windows 10: 3 * Amount of times complaining to the plugin authors: Too many to count. * Time spend on these tests / issues: Easily 50 hours or more. * Frustration level: Again, like each time before EXTREME! Please do not give me the company line that i need to report issues. I did so many times. It is tiring playing guinea pig, complaining and reporting, waiting for things to get fixed and still seeing things break again or simply not working properly. I can download Go, C#, C, C++, Delphi, Rust and get proper working plugins for the above mentioned editors but D is always that frustrating problem child. And i can not blame the plugin authors because the issues always seem to stem from the D plugins ( dcd, dscanner, ... ). Like dscanner changing its binary location between builds from folder root to /bin folder, breaking the plugin authors there system as it expected it in the folder root. Maybe things work great in a few very specific editor but in my personal experience, D its editor support is non stop frustrating. And i suspect that this complaint is not new. Clearly there is infrastructure in place for automated testing the compiler but it feels like there is a total lack of infrastructure for everything that surround it. Beyond maybe a few editors that the core team uses? My personal opinion: Too much in the D landscape is so individualist and not properly cross platform tested, that it results in pure frustration for the end developer. You are not alone. The existing D-Tools are either really bad or do not work propely/not out of the box. And I have more important things to do than trying to setup the tools. Maybe someone likes that, but not me. But I have to say that I've used more or less successfully Visual-D and Mono-D a few years ago. But neither of the tools can keep up in any way with Tools for Rust/C++/C#/Java/PHP. The existence of a good IDE which works out of the box without annoying setup procedures is crucial for the success of a language nowadays. That's one of the reason why I've moved on. I went back to C++ and nowadays to Rust. C++ is not that clean as D but the Tool support is crucial for anyone who wants to use the language for other than some hobby stuff.
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Friday, 26 January 2018 at 21:59:51 UTC, Dgame wrote: You are not alone. The existing D-Tools are either really bad or do not work propely/not out of the box. And I have more important things to do than trying to setup the tools. Maybe someone likes that, but not me. But I have to say that I've used more or less successfully Visual-D and Mono-D a few years ago. But neither of the tools can keep up in any way with Tools for Rust/C++/C#/Java/PHP. The existence of a good IDE which works out of the box without annoying setup procedures is crucial for the success of a language nowadays. That's one of the reason why I've moved on. I went back to C++ and nowadays to Rust. C++ is not that clean as D but the Tool support is crucial for anyone who wants to use the language for other than some hobby stuff. I have been comparing a bunch of languages and there IDEs this afternoon to see how fast and efficient there latest version work ( mostly inspired by the other topics of popular languages ). Wanted to avoid the whole "grass is greener on the other side" as a way to be fair. * Rust: Jetbrain IntelliJ + Rust plugin. It looks like it has become a official supported plugin by Jetbrain. Works perfectly out of the box. Impressive results and issue hinting. * Crystal: Visual Studio Code + OmniPascal plugin Color syntax but nothing else. No surprise, Crystal has no Windows compiler so no way to link any meaningful out output on Windows. * Pascal: Yes, freaking pascal! Visual Studio Code + OmniPascal plugin Impressive! Impressive features, type hinting and more. * C#: Visual Studio Code + C# ( OmniSharp ). No surprise there. Lots of functionality. * Go: Visual Studio Code + Go Plugin. Again, no surprise. Lots of functionality. Did not try the Jetbrain Gogland IDE because that is a official product so of course Go will work great in that one. * Julia: Visual Studio Code + Julia Plugin. Took a bit more configuring but again more functionality then i ever got from any D plugin. * Swift: Visual Studio Code + Swift Plugin. Like Crystal, no Windows version and limited to Color Syntax. ... got kind of fed up testing because everything that you expect to works on Windows, worked out of the box ( at best with oa Julia one needed to add the compiler path ). If nobody has figured out the trend by now, every language that has a windows compiler in any form has no major issues to offer extended functionality ( or even basic ). Those that do not have windows compiler, fall flat as expected. The exception being D that despite having multiple windows compilers offer ( in my case ) no functionality beyond color syntax. I do not count the VSC ability to list every keyword in your document. Another trend that i noticed from the other thread is that all the above mentioned languages all outperform D in github user activity ranking ( inc the very young one's ). D has always struck me more as a corporate language ( one that is less focused upon open source ). Maybe there is a more open community focus on the other platforms and this drives more interaction and pushes better plugin support? In other words, at best it take me half a hour to get proper editor support in the above mentioned languages ( that offer it in Windows ). Where as D ... well, its been a long topic and anybody who read the first post knows the results. Lets see: * 8+ hours: Struggling with 4 plugins and no results. And still waiting on one of the plugin authors his feedback as he also has a life. * 5 hours: Seven languages with 5 working perfectly and 2 POSIX languages with the expected no result. Yes, that includes the time to download all the compilers, get examples and other stuff. Guess the 8+ hour language ;)
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Friday, 26 January 2018 at 03:40:26 UTC, Rubn wrote: You seem to be short tempered You think after two days trying to get a series of plugins to work? you tried 2 plugins rather quickly, without even trying to see if there were configurations or other options you could use to get features working. Visual Studio Code: Code-D, Serve-D, D-Language Jetbrain: D-Language That is 4 plugins as described in the original post. Two of the same author, 2 from other authors. So that makes 3 different people there plugins. One may think a person can be salty after so many hours. - Limited name suggestion ( VSC functionality not the plugin ) only by forcing VSC (ctrl+space). - ... and nothing else... This is just not true... https://imgur.com/z6CZbjL.gif Well, if that actually worked, i will not be complaining here.
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Friday, 26 January 2018 at 16:30:19 UTC, Benny wrote: On Friday, 26 January 2018 at 07:08:50 UTC, Johannes Loher wrote: Take this all with a grain of salt: I have only tested this on Linux and OS X, I have no clue about the situation on Windows. In general a lot of plugins tend to work better in POSIX systems then Windows. I think its more a issue about Windows platform testing. Just want to pipe in that I run linux and yeah, I can't relate to any of the OP's grievances, using Visual Studio Code. I installed serve-d and the D tools on the side from repositories, then a few clicks for the code-d beta in vscode, and it just works. Arch/Manjaro. No real complaints about the features offered either. Autocomplete can be a bit too eager at times maybe, suggesting equals_t and various enum members when typing else, recently unitTest (from ModuleInfo) instead of unittest, etc. Syntax highlighting points out unbalanced parens, braces and quotes. Mouseover for documentation works, looking up/peeking at definitions does too. If I could magically wish for one thing it would be UFCS support.
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Friday, 26 January 2018 at 07:08:50 UTC, Johannes Loher wrote: Take this all with a grain of salt: I have only tested this on Linux and OS X, I have no clue about the situation on Windows. In general a lot of plugins tend to work better in POSIX systems then Windows. I think its more a issue about Windows platform testing. But at least my experience was really good, so I'd like to use this opportunity to thank all the authors of the plugins and the underlying tools for doing this (ungrateful) work (and in my opinion doing it very well). I know that probably a lot has still to be done, but the state of affairs is not as bad as all the complaints make it sounds. It probably is not as bad but its clearly a issue anyway. But one guy complaining after trying 6 or 7 times over a year+ ( with constant reporting the issues ), probably means there are more people out there who tried and simply gave up without reporting the issues. The reasons for the problems you describe still being so common have already explained thoroughly by others: Its mainly that there are no paid developers working on it and therefore not enough people working on it. So the solution is actullay quite simple and it is the same answer that most complaints about problems with D get: Either do it yourself, or pay somebody to do it. That is the quickest way to fix things. And that is the same issue with a lot of FOSS languages. But at one moment one needs to say stop. I donated a lot ( for me anyway ) of money to different FOSS projects but that money, what happened to it? In general there is zero accountability where money gets spend on most projects. Just in the last month over 500$ on different projects. But i am not a infinity money machine. And in this case: Does one donate money to the Code-D/Serve-D developer. But its not really his issue. To the D-Language developer? But its not really his issue. Who do you even donate too to have specific problems that are hard to trace fixed. Its not like one asks: "Please add x functionality". Just recently i donated 100$ to a other language project to implement socket support. So far i see nothing happening, while this functionality is more important to me now ( as it blocks my progress on that project ). So even when donating the results can be "i feel ripped off". Do it yourself = Time is money. If i had that much time to learn the base code of a language, i will not be donating money to specific language projects ( also i'am not a good core / system programmer ). I feel its too many times: Complain about issue => Get responds there are no people to do it => Please do it yourself or pay. By that logic i am bankrupt tomorrow with the issues i face in different languages :) Let me not bother you too much with my rants. Like i said, its better ( for me ) to focus on a language that has things better worked out and it does not feel like screaming at the walls. I feel sorry for projects like this that have no big corporate backers because its not a envy position without the money and focus.
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Friday, 26 January 2018 at 17:27:17 UTC, Anonymouse wrote: If I could magically wish for one thing it would be UFCS support. Just an FYI: implementing the universal language server protocol with DMD as a library is the number 1 priority for this year's GSoC: https://wiki.dlang.org/GSOC_2018_Ideas#Language_Server_Protocol_for_D (if the D Language Foundation gets accepted, of course)
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Thursday, 25 January 2018 at 15:20:15 UTC, Benny wrote: Maybe things work great in a few very specific editor but in my personal experience, D its editor support is non stop frustrating. And i suspect that this complaint is not new. Indeed, this complaint is not new. Because the complaint is actually so common, I'd like to share my own experience: I tried several different solutions, including the IntelliJ plugin, Mono-D, Sublimetext with a D-plugin, dlangide and vs code with code-d. With most of them, I had some problems, but in the end, I got all of them working. I had the least problems with code-d (the serve-d variant), which works perfectly after setting the stdlibPath in the settings (provided you already have dscanner and dfmt installed on your system and in your PATH). This what also what I've settled for in the end. In my opinion the features offered by it are actually quite good: The autocompletion provided by dcd is more than enough for my needs and in addition to that you get static linting, code formating, debugging (if you also install the native debug plugin from the same author) goto definition and some more features. And in my experience this all works without major issues. Sure, you don't get autocompletion for ufcs calls, but that is actually quite difficult to implement... Take this all with a grain of salt: I have only tested this on Linux and OS X, I have no clue about the situation on Windows. But at least my experience was really good, so I'd like to use this opportunity to thank all the authors of the plugins and the underlying tools for doing this (ungrateful) work (and in my opinion doing it very well). I know that probably a lot has still to be done, but the state of affairs is not as bad as all the complaints make it sounds. The reasons for the problems you describe still being so common have already explained thoroughly by others: Its mainly that there are no paid developers working on it and therefore not enough people working on it. So the solution is actullay quite simple and it is the same answer that most complaints about problems with D get: Either do it yourself, or pay somebody to do it. That is the quickest way to fix things.
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Thursday, 25 January 2018 at 21:18:23 UTC, Benny wrote: It seems to be that they understand the value of better tooling and friendly platform support. Whereas its my impression that a lot of resources get focused on making D its compiler / language better but the rest seems to be ignored. Well the entirety of what is used in basically every editor was developed by one person. Until recently all those projects were solely maintained by that one person. Rust's compiler can be integrated with tools if I'm not mistaken, at least I know it was being worked on a while back when I looked it up. Comparing to Rust isn't exactly fair, it is a lot more financially well off with Mozilla back it. When the tools are community run it is going to be like this. No one actually wants to work on it, they would rather be working on their own projects. Not working on tools that make working on their own projects a tiny bit easier. The tools are at a point where they are decent enough to use. You seem to be short tempered, you tried 2 plugins rather quickly, without even trying to see if there were configurations or other options you could use to get features working. - Limited name suggestion ( VSC functionality not the plugin ) only by forcing VSC (ctrl+space). - ... and nothing else... This is just not true... https://imgur.com/z6CZbjL.gif
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Thursday, 25 January 2018 at 21:18:23 UTC, Benny wrote: On Thursday, 25 January 2018 at 19:53:39 UTC, Basile B. wrote: If you write OOP with few templates like often done in C#, Delphi, or more declarative style like Go or C, then DCD works fine. Your frustration probably comes from the fact that popular techniques in D are not supported by DCD: Template Metaprogramming and CTFE. Maybe there has been a misunderstanding but i am not talking about CTFE or Metaprogramming. Basic OOP does not even work. And that is after testing D plugins going back a year or more with several DMD/Dub releases at the times. Curious because based on my own experience, a reasonable D programming style gives reasonable results with DCD. Maybe you missed how to configure things ? For example in CoEdit, everydays deps should be registered there: http://bbasile.github.io/Coedit/widgets_library_manager#description. In addition the dependencies of a DUB project are automatically handled at level 1 and if already fetched. I haven't used Delphi (which you mention in your first message) for a while (2012 last time) but even in this big commercial IDE there was a dialog where paths for libs had to be registered. And at this time this dialog was way less friendly than the one i made for CoEdit!
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Thursday, 25 January 2018 at 22:21:18 UTC, bachmeier wrote: On Thursday, 25 January 2018 at 21:56:12 UTC, Benny wrote: It was my impression that D Foundation has sponsoring from different companies. No clue how much but its strange to run a Foundation and not being able to pay one or more full time employees. If someone has been hired to work on tooling, I've not heard about it. Based on the number of complaints that should be a priority. I usually work with nothing more than a text editor so it's not an issue for me. No one has. The work on tools happens here since 8 months: https://github.com/dlang-community. I was in the team until September and i can say without any doubt that there's no money involved. I someone is paid for making tools then it's a kind of "Manhattan-project". So impossible, it would split people and create tensions.
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Thursday, 25 January 2018 at 21:56:12 UTC, Benny wrote: It was my impression that D Foundation has sponsoring from different companies. No clue how much but its strange to run a Foundation and not being able to pay one or more full time employees. If someone has been hired to work on tooling, I've not heard about it. Based on the number of complaints that should be a priority. I usually work with nothing more than a text editor so it's not an issue for me.
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Thursday, 25 January 2018 at 21:42:33 UTC, bachmeier wrote: Even one paid developer makes a big difference. You don't need hundreds. Making the problem harder is that many current D users don't have an interest in those tools. Therefore you're drawing from a small pool of part-time volunteer labor. It's entirely up to the community. This is not something Walter or Andrei should be concerned with. I had hoped the D Foundation would lead to a better organization of the community, but to this point, that doesn't seem to be the case. It was my impression that D Foundation has sponsoring from different companies. No clue how much but its strange to run a Foundation and not being able to pay one or more full time employees. I just looked up some community sourced project: Nim gets on average 1500 to 2000$ per month Crystal seems to be doing 2000 to 3000$ per month That is only counting salt.bountrysource and no direct donations. Just noticed this thread on Reddit and somebody asked about D. http://www.benfrederickson.com/ranking-programming-languages-by-github-users/ According to the author off the ranking: 18. Rust 0.73% 58. D... 0.047% No wonder that Rust seems to be more popular and D seems to struggle in popularity.
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Thursday, 25 January 2018 at 21:18:23 UTC, Benny wrote: When a new language like Rust is more tooling friendly and its extended platform integrates great with the editor plugins... Its not like Mozilla has hundreds of Engineers on Rust. Its extreme highly community driven. Even one paid developer makes a big difference. You don't need hundreds. Making the problem harder is that many current D users don't have an interest in those tools. Therefore you're drawing from a small pool of part-time volunteer labor. One can only express their hope that there will be a revitalization in the D management and the priorities. From my point of view it feels like D is falling behind when compared to other languages like Rust/C++/Go/... D really needs a project leader that knows the language and starts focusing the resources beyond just the compiler. It's entirely up to the community. This is not something Walter or Andrei should be concerned with. I had hoped the D Foundation would lead to a better organization of the community, but to this point, that doesn't seem to be the case.
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Thursday, 25 January 2018 at 19:53:39 UTC, Basile B. wrote: If you write OOP with few templates like often done in C#, Delphi, or more declarative style like Go or C, then DCD works fine. Your frustration probably comes from the fact that popular techniques in D are not supported by DCD: Template Metaprogramming and CTFE. Maybe there has been a misunderstanding but i am not talking about CTFE or Metaprogramming. Basic OOP does not even work. And that is after testing D plugins going back a year or more with several DMD/Dub releases at the times. On Thursday, 25 January 2018 at 17:32:24 UTC, Andre Pany wrote: While the several tools out of the box do not work well together, the involved developers did a great job (without any payment in contrast to Go/C#, Delphi...). I also struggled with the problem how to configure DCD in the DLang plugin for IntelliJ today. This might be the reason for the items marked as unknown. I created an issue here https://github.com/intellij-dlanguage/intellij-dlanguage/issues/356 Most of the plugins mentioned here are also made by community or individual members. The issue ends up being that its not so much the Editor plugins that create the problems but whatever language server that is behind it. Please look up several of the plugins there originals and you will see a lot are made by individuals? For instance OmniPascal... In my eyes its not the plugin authors there problem because they need the official tooling support from D. Compile a set of tools and notice how many deprecated calls show up. Or issues when a new D compiler version gets released. Or a new Dub version that breaks the tooling left or right. This is what i mean by "not properly cross platform tested". There seems to be a total lack for any tool "chain testing" beyond individual stand alone tests. How else does one explain the constant issues i have personally faced ( and reported ). I have been in the position to use D in several projects but in my experience its not worth taking the risk ( when issues like this keep happening ). This also affect not just the tooling but also the whole public dub packages. When a new language like Rust is more tooling friendly and its extended platform integrates great with the editor plugins... Its not like Mozilla has hundreds of Engineers on Rust. Its extreme highly community driven. It seems to be that they understand the value of better tooling and friendly platform support. Whereas its my impression that a lot of resources get focused on making D its compiler / language better but the rest seems to be ignored. I am sorry if this sounds cruel but for now D is on the back burner and my next project will probably be in Rust. Its a real shame but when even things like editor plugins barely work it makes me doubt the rest of the platform. And i do not even like Rust as a language but one can not deny it is a better supported platform. One can only express their hope that there will be a revitalization in the D management and the priorities. From my point of view it feels like D is falling behind when compared to other languages like Rust/C++/Go/... D really needs a project leader that knows the language and starts focusing the resources beyond just the compiler. Anyway, good luck in the future.
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Thursday, 25 January 2018 at 15:20:15 UTC, Benny wrote: After months doing a different project, i need a programming language for a new client with specific needs. D comes to mind. As usual that involves downloading the compiler (dmd and ldc). [...] My personal opinion: Too much in the D landscape is so individualist and not properly cross platform tested, that it results in pure frustration for the end developer. If you write OOP with few templates like often done in C#, Delphi, or more declarative style like Go or C, then DCD works fine. Your frustration probably comes from the fact that popular techniques in D are not supported by DCD: Template Metaprogramming and CTFE. They are not well supported because they "just" require to have a compiler built in the completion engine. You can also add "auto everywhere" to the problems (plenty of std.algorithm, std.typecons, std.range are not supported at all) This problem won't be fixed (ever: i'm honnest since i work a bit on dparse dcd etc. i didn't see the "big" thing coming) so the best advice i can give you is "do not to use the things that are not supported by DCD in the public API". Use them for private internal details. And avoid "auto". Now, let's talk about the bugs. The important things in DCD are done by a library called D-Symbol. This library needs more love. https://github.com/dlang-community/dsymbol/pulls. There are 5 valid bug fixes opened since the end of the summer and that haven't been handled. A movement had started in July / August but apparently has stopped in September for some reasons. I don't think that complaining about specific editor plugins will help. People who write these plugins have adapted DCD to their product but they cant just sit and wait that the completion gets better. At some point if you work on a IDE you have deal with certain low level language stuff. It's not just about piping process. (Note: this paragraph is addressed to editor plugins and IDE writers).
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Thursday, 25 January 2018 at 15:20:15 UTC, Benny wrote: After months doing a different project, i need a programming language for a new client with specific needs. D comes to mind. As usual that involves downloading the compiler (dmd and ldc). [...] While the several tools out of the box do not work well together, the involved developers did a great job (without any payment in contrast to Go/C#, Delphi...). I also struggled with the problem how to configure DCD in the DLang plugin for IntelliJ today. This might be the reason for the items marked as unknown. I created an issue here https://github.com/intellij-dlanguage/intellij-dlanguage/issues/356 The DLang ecosystem is getting better and better and you also can help by testing, writing constructive issues or even providing fixes. Kind regards André
Dscanner - DCD - Dfix ... Editor support or the lack of it.
After months doing a different project, i need a programming language for a new client with specific needs. D comes to mind. As usual that involves downloading the compiler (dmd and ldc). So, lets install Visual Studio Code: * Code-D Plugin: - Syntax highlight *check* - After saving: DMD error suggestions in the code. *check* - Limited name suggestion ( VSC functionality not the plugin ) only by forcing VSC (ctrl+space). - ... and nothing else... So lets try the next plugin: * Serve-D Plugin: - Syntax highlight *check* - After saving: DMD error suggestions in the code. *check* - Limited name suggestion ( VSC functionality not the plugin ) only by forcing VSC (ctrl+space). - ... and nothing else... Frustration level increasing. Lets try the next one: * D-Language Plugin: - Syntax highlight *check* - Limited name suggestion ( VSC functionality not the plugin ) only by forcing VSC (ctrl+space). - ... and nothing else... Ok ... so Visual Studio Code its Dscanner, DCD, Workspace-d do not properly work or some other issue. Then lets try IntelliJ Community Edition. After a long time getting all the dependancies and compiling them... Dscanner - DCD ( client and server ) - Dfix ... * D Language Plugin: - Syntax highlight *check* - Way too many items like writefln, import etc all being marked as unknown. Clearly wrong. - ... and nothing else... - Socket error (std.socket.xxx) on closing IntelliJ Conclusion is that it feels like the whole D infrastructure is very, very poorly supported. Other issues like delays that some of the D plugins seem to introduce: * Like "loading ..." popups that do nothing but always show up ( Visual Studio Code ) * Like pressing "dot" expecting a response, waiting 2 seconds and then finally something happening ( IntelliJ plugin ) but simply dumping every possible name and variable ( zero intelligent code support ) I assume that this is again broken DCD or Dscanner. And no, no errors in the console of VSC or anything like that. Let me summarize my personal D editor experience in the last 1+ year. * Attempts at getting D editor support going: 6 or 7. * Amount of times things worked out of the box. One! And this was limited to about a few minutes and after that all suggestions broke again. * Amount of times dscanner or dcd or other plugins broke because of DMD newest version broke: 4 * Tested on different machines: 4! They all have one thing in common: Windows 10 * Tested on different Windows installations: 3 * Tested on different "version" of Windows 10: 3 * Amount of times complaining to the plugin authors: Too many to count. * Time spend on these tests / issues: Easily 50 hours or more. * Frustration level: Again, like each time before EXTREME! Please do not give me the company line that i need to report issues. I did so many times. It is tiring playing guinea pig, complaining and reporting, waiting for things to get fixed and still seeing things break again or simply not working properly. I can download Go, C#, C, C++, Delphi, Rust and get proper working plugins for the above mentioned editors but D is always that frustrating problem child. And i can not blame the plugin authors because the issues always seem to stem from the D plugins ( dcd, dscanner, ... ). Like dscanner changing its binary location between builds from folder root to /bin folder, breaking the plugin authors there system as it expected it in the folder root. Maybe things work great in a few very specific editor but in my personal experience, D its editor support is non stop frustrating. And i suspect that this complaint is not new. Clearly there is infrastructure in place for automated testing the compiler but it feels like there is a total lack of infrastructure for everything that surround it. Beyond maybe a few editors that the core team uses? My personal opinion: Too much in the D landscape is so individualist and not properly cross platform tested, that it results in pure frustration for the end developer.
Shouldn't dfix be made a friend of the compiler?
"5. The kind that a tool such as 'dfix', can automate. For example, let's say dfix is included with the compiler package. Now you get an error, saying: "Error: `@nogc` is no longer accepted, but can be automatically replaced with `nogc`. Run dfix on this file? (y/n)"... or whatever is deemed the secure approach to this feature. " Sorry for the tangent (I have no view on the major topic), +1 for including a link to dfix within the compiler. Repetitive things ought to be automated and made easy and how many times does one end up fixing up old code ?
Re: Dfix
On Tuesday, 16 April 2013 at 20:39:51 UTC, Arlen wrote: Gofix, "a tool to mechanically update code to accommodate language and library changes." Mr. Pike talks more about it starting at 8:26 http://www.youtube.com/watch?v=bj9T2c2Xk_s&feature=player_embedded I wish D had such a tool. Any chance? Static analysis and other dev tools have a chain of dependencies, the beginning of which is a complete and correct grammar definition. I've been working on one for the past several days. There is a chance that such a tool could be created for D, but there's a lot of work to be done to get there.
Dfix
Gofix, "a tool to mechanically update code to accommodate language and library changes." Mr. Pike talks more about it starting at 8:26 http://www.youtube.com/watch?v=bj9T2c2Xk_s&feature=player_embedded I wish D had such a tool. Any chance?