[dnesteruk]

D is great but lack of tool support (proper intellisense) means we're all stabbing in the dark trying to figure out what function to use, where it comes from and what its parameters are supposed to take. Also, really needs declarative parallelization mechanisms a la OpenMP. Plus, unsure if compiler supports vectorization, SIMD support would be nice to get.

On the other hand, amazingly fast compiler, very concise language, and metaprogramming! Want a decent IDE!

[rukantos]

D already has decent IDE. -Visual D (VS Add In) -DDT (Eclipse Add In) -Mono-D (Mono-Develop Add In)

I recommend you use Mono-D or Visual D. and, D has great parallelism and SIMD support in standard library. http://dlang.org/phobos/std_parallelism.html http://dlang.org/phobos/core_simd.html

Let's try!

[ch_123]

"D is great but lack of tool support (proper intellisense) means we're all stabbing in the dark trying to figure out what function to use, where it comes from and what its parameters are supposed to take."

Some people like to read the documentation and not let their editor figure out how to program for them.

[anon1385]

Wasting time just to enhance your own ego is not a virtue. If you really find that pseudo-religious penance is beneficial to your smug sense of superiority then wear a hairshirt while you program.

[sanderjd]

Bah - the point is not that it is better to look things up than to have an IDE know things for you, the point is that if your IDE doesn't know those things, you should be able to find them yourself. It is bad to be beholden to intellisense to the point where you actually can't use a language that it doesn't work well for.

[anon1385]

Are you seriously arguing that a programmer, who surely has more than a passing familiarity with how to search for things on the internet, would forget how to look up documentation after using an IDE for some time period? The art of programming is not masted by mindless repetition of laborious documentation lookups. Searching documentation isn't an advanced skill that requires constant practice to remain capable. Generally there are still plenty of things to look up (has somebody solved this before, is there a library to do this, has somebody already figured out a workaround for this bug in library/framework X that I'm using etc etc).

I find languages with poor tooling irritating to use, in the same way that I find other language deficiencies irritating. I usually wish I was back using something more powerful. For example, it's the feeling I get when working with strings in C, or using a language without lambdas. I am irritated at my time being wasted when using languages where the compiler doesn't warn me about simple mistakes, or when I have to manually filter out false positives when renaming something with a tool that doesn't understand the code beyond doing find/replace/regex on a stream of unicode characters. None of this means that I can't get work done with 'blub' language and tooling, but the fact that something better exists is always in the back of my mind, and knowing I have mastered a worse tool doesn't give me much satisfaction.

The idea that more modern and better tools are a crutch is hardly unique to software development. In just about any field you can find people advocating for the 'character developing' tedium of the old ways. The irony of course is that the same arguments nearly always apply to the older methods being advocated: they once were new, and the hard won knowledge of the even older method became redundant. See: punchcards, assemblers, compilers, build automation tools, version control software, syntax highlighting, documentation being a big physical book with an index, compiler errors and warnings, images, refactoring tools, automated testing. Just about all of those have been described as a crutch that prevents people achieving real deep understanding of the computer or their code. Does it make you feel inadequate as a programmer to know that you couldn't do your job using punchcards, or as you put it, to be 'beholden to a text editor to the point where you can't program without one'.

[juanManuel]

D has intellisense in MonoD and VisualD.

[anon1385]

That's good to know. I was not intending to disparage D, which I have not used so I don't know how good the tooling is one way or the other. I was merely responding to comments implying that better tooling is a crutch for people who can't really code.

[0b1100110]

As well as syntastic support and syntax file for Vim, if you are so inclined.

Supports completion, as well as error checking.

[juanManuel]

You could also use CTRL-N in Vim. It autocompletes for any language (though it is not intellisense).

[johncoltrane]

Language-aware completion is called "omni completion" and triggered with <C-x><C-o>. <C-n> does keyword completion which is much dumber than its sibling but works.

[ch_123]

On the contrary, I would consider it a waste of time to dive into a language, library or framework without sitting down and reading through enough documentation to figure out what I want to do. The time you spend planning these things is well repaid in terms of avoiding simple mistakes.

[mitchi]

Coming from someone working in graph theory code I can tell you that the debugger is invaluable. So many pointer links :) Last time I tried VisualD it was pretty good.

[libraM]

http://d-ide.sourceforge.net/ - another good Windows IDE for D.

[WalterBright]

D has very good SIMD support, although it does not have an autovectorizer. For parallelism, see http://dlang.org/phobos/std_parallelism.html

[0b1100110]

You're doing it wrong, sorry. I have omni-completion enabled with syntastic support for D in Vim.

Works for me.