On Monday, 27 January 2014 at 08:12:14 UTC, Manu wrote:
> In order:
>
> 1. A debugger (that works properly)
> 2. Go-to definition (that always works)
> 3. Auto-complete (that always works)
> 4. Import management (missing/duplicate/unused imports)
> 5. Typical suite of modern refactoring tools

Holly crap, I forgot the goto definition. That is really needed.

. Static analysis
. Automated refactoring plugins for different editors
. Go to definition plugins for different editors
. Unused import warnings
. Some way of figuring out which import a function is from

Right now I'm glad that flycheck highlights compilation errors for me in emacs, but unfortunately there is no way currently to pass it -I flags for different projects so any non-Phobos non-currentdir imports fail.

I was also surprised to find an unused variable in my code a day or two ago that the compiler never warned me about. I wasn't happy.

Atila

On Sunday, 26 January 2014 at 20:29:30 UTC, Oten wrote:
> Which tools do you miss in the D language? it can be from any
> language not from C or C++ only but from any language that you
> have used and liked (might not liked but increased productivity
> anyway)  A very common argument from peoples which do choose
> other language than D is lack of your tools for D, even if they
> want to get D they say can't switch. The most common tools which
> they miss is debuggers/static analyzer/lint and so on. I think
> that by sharing this list with community instead of just say it
> like a criticizes is good because next time that some people say
> that such a x tools isn't available you can say "No, there's a D
> version for that". Also, totally new ideas are very welcome. If
> you  have had a idea that for any reason you wouldn't implement
> yourself, tell us too.
> (sorry for english, not my native language)

On Monday, 27 January 2014 at 08:24:07 UTC, Manu wrote:
> On 27 January 2014 18:11, Manu <turkeyman@gmail.com> wrote:
>
>> In order:
>>
>> 1. A debugger (that works properly)
>> 2. Go-to definition (that always works)
>> 3. Auto-complete (that always works)
>> 4. Import management (missing/duplicate/unused imports)
>> 5. Typical suite of modern refactoring tools
>>
>
> I might add, the frequency to which I pine for these things is in the order
> of minutes, perhaps even 10s of seconds >_<
>
> I made an interesting observation recently... D has kind of ruined my
> career ;)
> Before I started using D a lot, I found C/C++ quite okay as a language. But
> after extended time using D, I find C/C++ borderline intolerable, and don't
> enjoy writing it at all.
> But the tooling built around C/C++ is pretty good, and as such, I find the
> tooling while working in D borderline intolerable.
>
> So, before, I generally enjoyed my work, and felt generally productive. Now
> days, whenever I do any work in either language, I find one aspect or the
> other borderline intolerable, and I have trouble enjoying spending my time
> programming for long periods before getting frustrated and going and doing
> something else...
>
> I'm quite serious, this is a true realisation of an unconscious behaviour.
> D ruined C/C++ for me, but my expectations of C/C++'s tooling still remains
> a barrier to my enjoyment of writing D code all time time... I'm fucked!

I'm personally of the opinion that if you're resorting to a debugger, that you really don't understand the code you're writing and how to debug it.
I've only really needed it in .net languages like c# and vb.net. Note my first language was vb.net 7 odd years ago. And I was doing c# up to a couple months ago in a course for my degree. I have only used one once or twice for e.g. assembly which I don't truly understand.

Its strange for me to see people use it so much. Because its such a different approach.

So for me auto completion and refactoring is most important. Mono-D is quite close for auto completion but it needs to get a lot more stable before I'll be happy.

I would also like to point out that for a long time we didn't really have a standard build manager. I was designing my own based upon Maven when dub came along.

So I'm happy with the way the ecosystem is going for this.

On Monday, 27 January 2014 at 09:29:44 UTC, Rikki Cattermole wrote:
> On Monday, 27 January 2014 at 08:24:07 UTC, Manu wrote:
>> On 27 January 2014 18:11, Manu <turkeyman@gmail.com> wrote:
>>
>>> In order:
>>>
>>> 1. A debugger (that works properly)
>>> 2. Go-to definition (that always works)
>>> 3. Auto-complete (that always works)
>>> 4. Import management (missing/duplicate/unused imports)
>>> 5. Typical suite of modern refactoring tools
>>>
>>
>> I might add, the frequency to which I pine for these things is in the order
>> of minutes, perhaps even 10s of seconds >_<
>>
>> I made an interesting observation recently... D has kind of ruined my
>> career ;)
>> Before I started using D a lot, I found C/C++ quite okay as a language. But
>> after extended time using D, I find C/C++ borderline intolerable, and don't
>> enjoy writing it at all.
>> But the tooling built around C/C++ is pretty good, and as such, I find the
>> tooling while working in D borderline intolerable.
>>
>> So, before, I generally enjoyed my work, and felt generally productive. Now
>> days, whenever I do any work in either language, I find one aspect or the
>> other borderline intolerable, and I have trouble enjoying spending my time
>> programming for long periods before getting frustrated and going and doing
>> something else...
>>
>> I'm quite serious, this is a true realisation of an unconscious behaviour.
>> D ruined C/C++ for me, but my expectations of C/C++'s tooling still remains
>> a barrier to my enjoyment of writing D code all time time... I'm fucked!
>
> I'm personally of the opinion that if you're resorting to a debugger, that you really don't understand the code you're writing and how to debug it.
> I've only really needed it in .net languages like c# and vb.net. Note my first language was vb.net 7 odd years ago. And I was doing c# up to a couple months ago in a course for my degree. I have only used one once or twice for e.g. assembly which I don't truly understand.

I disagree. Your claim it might be true when:

1. *you* recently wrote the code (last 18 months)
2. your the code base is small < 50 000 LOC
3. You're single threaded.
4. You have no third-party dependencies/libraries.

But that has never been the case for me at work, only for personal stuff.

It is so much more efficient to track down problems with a good debugger. Good GDB support would be great ... I know it is being worked on so I'm happy :D

>
> So for me auto completion and refactoring is most important. Mono-D is quite close for auto completion but it needs to get a lot more stable before I'll be happy.

I don't understand the reliance on IDEs around here. Is there something lacking in computer science education at uni nowadays?

Package managers are nice, dub rocks!.

I'd much prefer to see D devs working on improving ARM support and improving the GC. Again this is happening already so I cannot way to see where it goes.

Cheers.

On Monday, 27 January 2014 at 07:16:26 UTC, Knud Soerensen wrote:
> I miss check_expect from racket.
>
> It is used for unit testing
>
> check_expect(expression, result)
> Will test if expression equals result
> if it is not it print "Got expression but expected result" with file and
> line information.
>
> In D making unit tests is more tedious.
> When I develop in D I typical start with.
>
> writeln(expression)
> writeln(result)
>
> then when the code is working I replace it with
> assert(expression==result)
>
> Then if I do some refactoring which don't work I change again
> writeln(expression)
> writeln(result)
>
> When it is working again
> assert(expression==result)
>
> This back and forth process in D is very tedious compared to Racket.
>
> I think the should be a buildin function called test or something
> for-filing the same role as check_expect in racket.
>
> Knud
>
> On 2014-01-26 21:29, Oten wrote:
>> Which tools do you miss in the D language? it can be from any
>> language not from C or C++ only but from any language that you
>> have used and liked (might not liked but increased productivity
>> anyway)  A very common argument from peoples which do choose
>> other language than D is lack of your tools for D, even if they
>> want to get D they say can't switch. The most common tools which
>> they miss is debuggers/static analyzer/lint and so on. I think
>> that by sharing this list with community instead of just say it
>> like a criticizes is good because next time that some people say
>> that such a x tools isn't available you can say "No, there's a D
>> version for that". Also, totally new ideas are very welcome. If
>> you  have had a idea that for any reason you wouldn't implement
>> yourself, tell us too.
>> (sorry for english, not my native language)

import std.stdio;

void check_expect(A, B)(lazy A expression, B result, string file = __FILE__, size_t line = __LINE__)
{
	try
	{
		if (expression != result)
		{
			throw new Exception("Got expression but expected result", file, line);
		}
	}
	catch (Exception ex)
	{
		writefln("%s, file: %s, line: %s", ex.msg, ex.file, ex.line);
	}
}

unittest
{
	check_expect(1 + 2, 4);
}

You can find more usesful functions for unit testing here: https://github.com/nomad-software/dunit

I can understand why you think about how I work, the way you do. Its like the difference between an introvert and an extravert. Its just so different way of working and thinking. Its unbelievable.

I have honestly never meet somebody who works even similar to me.

On Sun, 2014-01-26 at 23:30 +0000, ed wrote:
[…]
> A quality GUI api with a decent GUI builder, something like the tools that come with Qt or that Window Builder for Java.
> 
> I find GTKD bindings are great but the GTK api itself, IMO, is less intuitive than Qt and GTK+Glade is a lot more work compared to other RAD tools in C++ or Java.

I find GtkD + Glade rather good actually. The problem is that this is not really a good direction for cross platform working since Gtk isn't a widely supported framework.

Qt5 on the other hand is making great strides (now that it isn't a Nokia/Microsoft technology). Go now has QML support and I am finding this a nice combination.

Having QML support in D would be a good thing.

I haven't had time to work on the various QtD repositories to see if Qt5 and QML are or can easily be supported.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On 27 January 2014 19:29, Rikki Cattermole <alphaglosined@gmail.com> wrote:

> On Monday, 27 January 2014 at 08:24:07 UTC, Manu wrote:
>
>> On 27 January 2014 18:11, Manu <turkeyman@gmail.com> wrote:
>>
>>  In order:
>>>
>>> 1. A debugger (that works properly)
>>> 2. Go-to definition (that always works)
>>> 3. Auto-complete (that always works)
>>> 4. Import management (missing/duplicate/unused imports)
>>> 5. Typical suite of modern refactoring tools
>>>
>>>
>> I might add, the frequency to which I pine for these things is in the
>> order
>> of minutes, perhaps even 10s of seconds >_<
>>
>> I made an interesting observation recently... D has kind of ruined my
>> career ;)
>> Before I started using D a lot, I found C/C++ quite okay as a language.
>> But
>> after extended time using D, I find C/C++ borderline intolerable, and
>> don't
>> enjoy writing it at all.
>> But the tooling built around C/C++ is pretty good, and as such, I find the
>> tooling while working in D borderline intolerable.
>>
>> So, before, I generally enjoyed my work, and felt generally productive.
>> Now
>> days, whenever I do any work in either language, I find one aspect or the
>> other borderline intolerable, and I have trouble enjoying spending my time
>> programming for long periods before getting frustrated and going and doing
>> something else...
>>
>> I'm quite serious, this is a true realisation of an unconscious behaviour.
>> D ruined C/C++ for me, but my expectations of C/C++'s tooling still
>> remains
>> a barrier to my enjoyment of writing D code all time time... I'm fucked!
>>
>
> I'm personally of the opinion that if you're resorting to a debugger, that you really don't understand the code you're writing and how to debug it.
>

That's one key point of a good debugger; when you don't understand the code you're debugging at all, but you need to fix it, like, 3 hours ago.

I've only really needed it in .net languages like c# and vb.net. Note my
> first language was vb.net 7 odd years ago. And I was doing c# up to a couple months ago in a course for my degree. I have only used one once or twice for e.g. assembly which I don't truly understand.
>
> Its strange for me to see people use it so much. Because its such a different approach.
>

I obviously use many other techniques when a debugger isn't available, but I don't know any in which I feel similarly as productive as with good runtime debug and analysis tools.

So for me auto completion and refactoring is most important. Mono-D is
> quite close for auto completion but it needs to get a lot more stable before I'll be happy.
>
> I would also like to point out that for a long time we didn't really have a standard build manager. I was designing my own based upon Maven when dub came along.
>
> So I'm happy with the way the ecosystem is going for this.
>

dub doesn't address my needs at all, but I've put crap loads of time/energy into the D extension for premake, which works well ( https://bitbucket.org/premakeext), although for some reason has never really gotten any attention from the D community :(

It generates cross-language build scripts (ie, C/C++ and D code all
together in the same project) for make and many popular IDE's.
I use it for large scale projects that involve C/C++ engine library, D
front end code, and other ancillary libraries bolted on the side.

On 2014-01-27 09:11, Manu wrote:
> In order:
>
> 1. A debugger (that works properly)
> 2. Go-to definition (that always works)
> 3. Auto-complete (that always works)

How well do these work for you in Visual Studio for C++? I'm finding cases in Xcode where it doesn't always work, especially in DMD.

> 4. Import management (missing/duplicate/unused imports)
> 5. Typical suite of modern refactoring tools

I agree on all the above.

-- 
/Jacob Carlborg

On Monday, 27 January 2014 at 08:12:14 UTC, Manu wrote:
> In order:
>
> 1. A debugger (that works properly)
> 2. Go-to definition (that always works)
> 3. Auto-complete (that always works)
> 4. Import management (missing/duplicate/unused imports)
> 5. Typical suite of modern refactoring tools

+1 for items 1, 4 and 5.