Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.

[Marco Leise via Digitalmars-d]

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.

[Marco Leise via Digitalmars-d]

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.

[Uknown via Digitalmars-d]

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.

[Dave via Digitalmars-d]

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.

[rikki cattermole via Digitalmars-d]

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.

[H. S. Teoh via Digitalmars-d]

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.

[jmh530 via Digitalmars-d]

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.

[Jonathan M Davis via Digitalmars-d]

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.

[H. S. Teoh via Digitalmars-d]

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.

[Jonathan M Davis via Digitalmars-d]

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.

[H. S. Teoh via Digitalmars-d]

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.

[Jonathan M Davis via Digitalmars-d]

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.

[arturg via Digitalmars-d]

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.

[Jonathan M Davis via Digitalmars-d]

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.

[arturg via Digitalmars-d]

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.

[Jonathan M Davis via Digitalmars-d]

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 

Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.

[Paolo Invernizzi via Digitalmars-d]

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.

[Basile B. via Digitalmars-d]

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=PLzk8A0LUvEOV-OMdz09jfOahwnKoA2na_=1

?

Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.

[H. S. Teoh via Digitalmars-d]

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 

Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.

[Benny via Digitalmars-d]

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.

[H. S. Teoh via Digitalmars-d]

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.

[JN via Digitalmars-d]

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.

[Kagamin via Digitalmars-d]

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.

[Dgame via Digitalmars-d]

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.

[H. S. Teoh via Digitalmars-d]

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

[David Gileadi via Digitalmars-d]

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.

[Steven Schveighoffer via Digitalmars-d]

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.

[NX via Digitalmars-d]

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.

[Dgame via Digitalmars-d]

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.

[Benny via Digitalmars-d]

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.

[Rubn via Digitalmars-d]

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.

[Dgame via Digitalmars-d]

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.

[Benny via Digitalmars-d]

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.

[Benny via Digitalmars-d]

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.

[Anonymouse via Digitalmars-d]

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.

[Benny via Digitalmars-d]

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.

[Seb via Digitalmars-d]

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.

[Johannes Loher via Digitalmars-d]

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.

[Rubn via Digitalmars-d]

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.

[Basile B. via Digitalmars-d]

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.

[Basile B. via Digitalmars-d]

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.

[bachmeier via Digitalmars-d]

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.

[Benny via Digitalmars-d]

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.

[bachmeier via Digitalmars-d]

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.

[Benny via Digitalmars-d]

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.

[Basile B. via Digitalmars-d]

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.

[Andre Pany via Digitalmars-d]

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é