On 27 January 2014 22:14, Jacob Carlborg <doob@me.com> wrote:

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


The VC debugger is perfect for C/C++. I can't imagine how it would be
improved. You can even edit your code and rebuild+relink while it's running
to make minor runtime tweaks, and continue execution using the modified
code.
Go-to definition is not perfect, but it works 95% of the time.
Auto-complete is very good in C/C++ but there are a few rough edges
(possibly from complex preprocessor mess?), but C# is the clear benchmark
for quality here.

D doesn't have a preprocessor or a horrible network of text include, it should easily be able to match the C# experiences in general.

I say 'that always works' above, implying that it sometimes works... which is true, but it's in the realm of 30% for me, which is unreliable enough to be very annoying. Any time 'class' appears in D, it all goes south under VisualD.


 4. Import management (missing/duplicate/unused imports)
>> 5. Typical suite of modern refactoring tools
>>
>
> I agree on all the above.
>
> --
> /Jacob Carlborg
>

Pretty much only thing I really miss compared to C++ is full valgrind support (including callgrind and helgrind).

There are a lot of things in tooling that could have been improved, but those are not a deal breakers are my typical development env is very minimalistic and does not rely on anything fancy.

Am 27.01.2014 09:23, schrieb Manu:
> 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!

So true for me, too... to the point that I'm sometimes mentally blocked from performing some simple kind of refactoring or implementing a little feature in C++ because my brain simply refuses to do that in such a sub-optimal way :(

With declining frequency of programming in C++ this got much worse (I was using D for some hobby projects besides my mostly C++ day job for some years until I finally also used it for a project at work before I quit and now use D almost exclusively).

On Monday, 27 January 2014 at 11:32:04 UTC, Manu wrote:
[:snip:]
> 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.

I had a look at it and wow. If I had seen this a year ago I would have helped!
Here is my spec for my build system that I was designing back then[0].

[0] http://pastebin.com/agChTmPM

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

It amazed me that your post was the first that mentioned a working debugger!

> 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 :(

Never heard of the extension until now.

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

That's cool, and I might make use of this when mixing D and C/C++. What dub does do really well is just making any source package available. I wish I had that plus the full features of a build system like CMake all under one roof.

Atila

On 1/26/14 11:16 PM, 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 do the same. There's a enhancement request in bugzilla for having assert detect these patterns itself.

Andrei

That can be (and is) solved by D unit testing libraries.

Atila

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)

On 01/26/2014 09:29 PM, Oten wrote:
> Which tools do you miss in the D language? ...

A fully working compiler for the most recent language version.

On Monday, 27 January 2014 at 17:57:02 UTC, Timon Gehr wrote:
> On 01/26/2014 09:29 PM, Oten wrote:
>> Which tools do you miss in the D language? ...
>
> A fully working compiler for the most recent language version.

Indeed, and robust documentation for it too.