On 1 September 2013 18:06, Benjamin Thaut <code@benjamin-thaut.de> wrote:

Am 01.09.2013 04:05, schrieb Manu:

!!!!!!!!!
This has to be given first-class attention!
I am completely and utterly sick of this problem. Don made a massive
point of it in his DConf talk, and I want to re-re-re-re-re-re-re-stress
how absolutely important this is.
!!!!!!!!!

I have to fully agree here.

Debugging:

Poor debugging experience wastes your time every 5 minutes.
I can only speak for the Windows experience (since we failed to get OSX
working); there are lots of problems with the debugging experience under
visual studio...
I haven't logged bugs yet, but I intend to.
There were many instances of people wasting their time chasing bugs in
random places when it was simply a case of the debugger lying about the
value of variables to them, and many more cases where the debugger
simply refused to produce values for some variables at all.
This is an unacceptable waste of programmers time, and again, really
burned us in a 48hour context.

Actually there is only one little patch needed to make debugging work nicely with the visual studio c++ debugger. It replaces all '.' chars with '@' in type names inside the debug information. There was a pull request from Rainer Schuetze once, but it got rejected by Walter.

https://github.com/Ingrater/dmd/commit/522f6dbeb93944ebfebde6f938a2ee3a2d6be124

Also if you are using Visual Studio 2012, you need to change the debugging engine because the new one can't deal with D code that has C++ debugging info. For that go to Options -> Debugging -> Edit and Continue -> Enable Edit and Continue (this will make Visual Studio 2012 use the old debugging engine).

I use 2010, but Simon was using 2012, maybe that was the source of his problems. He certainly seemed to have a lot more problems than me.

Then everything will work nicely. The only real issue is, that the debugger can't identify which class is behind a given interface.

Also you should try using mago, it can be enabled inside the visualD debugging options of your project. It even features D expression evaluation, but it only works for 32-bit (but requires not cv2pdb conversion).

Mago is only Win32, and DMD is only Win64... I've tried encouraging the Mago guy to support Win64, but it doesn't seem to be a highly active project recently. I think this is another case of a 1-man project that represents a fairly critical part of the ecosystem.

Containers:

The question came up multiple times; "I don't think this should be an
array... what containers can I use, and where are they?"...
Also, nobody could work out how to remove an arbitrary item from an
array, or an item from an AA by reference/value (only by key).

This code:
foreach(i, item; array)
if(item == itemToRemove)
array = array[0..i] ~ array[i+1..$];
Got a rather 'negative' reaction from the audience to put it lightly...

Oh containers, I would love to have some. Like every one else using D I've written my own by now.

It turns out that it's not actually so easy to just 'knock up' a set of robust containers that work well across all of D's features.

Templates, and various typing complexities always seem to complicate the issue.

In my experience, I knock something together, and it appears to work in the simple case... but then down the line, something a little more niche hits it, and I realise it's not a trivial tweak to fix it. Often a more substantial rethink may be required.

One more thing:
I'll just pick one language complaint from the weekend.
It is how quickly classes became disorganised and difficult to navigate
(like Java and C#).
We all wanted to ability to define class member functions outside the
class definition:
class MyClass
{
void method();
}

void MyClass.method()
{
//...
}

It definitely cost us time simply trying to understand the class layout
visually (ie, when IDE support is barely available).
You don't need to see the function bodies in the class definition, you
want to quickly see what a class has and does.

You should really use VisualD's ability to parse the AST .json files dmd generates while compiling. Using this feature you get a really awesome class view and even "Go to defintion" works.

Sometimes...

Have you worked with it on a daily basis? It just doesn't work all the time. Also, in my experience the auto-complete suggestions are often either incomplete, or list heaps of completely unrelated stuff.

I'm not saying it's bad, it's better than nothing and I really appreciate the project (I've said before, if it weren't for Rainer's effort, I simply wouldn't use D), but it certainly needs more work, especially if I'm going to have any traction selling it to others with no vested interest in the language.

The situation at Remedy was different, it was an easier sell. Since we implemented D as an extension language, the productivity comparison was to scripting languages like lua which also have no tight integration or debugging support in Visual Studio. Visual-D was certainly an improvement over other scripting solutions, and I think I made that case at DConf.

But this project approached it from a different angle, ie, a total replacement for C++ which does have a rich toolset available. I want to use D in this context in the future, and if that were the commitment we were considering at Remedy, there's no way we would have gone for it.

My hope from the Remedy experience was to prove that it works in a commercial environment.

I went out on a REALLY massive limb there, and as far as I can tell, it's well received (although it took the better part of a year longer to get there than I promised).

I'd love to see it take the next step one day, ie, into the main code-base... but the tools need to be rock solid before that can ever happen.

Conclusion:
I think this 48 hour jam approach is a good test for the language and
it's infrastructure. I encourage everybody to try it (ideally with a
clean slate computer).
The lesson is that we need to make this process smooth, since it mirrors
the first-experience of everybody new to D.
It also highlights and magnifies time-wasters that are equally
unacceptable in a commercial environment.

I don't think I made any converts this weekend wrt the above issues
encountered. I might have even just proved to them that they should
indeed stick with C# (the IDE's work!)... :(

Please, we need a road-map, we need to prioritise these most basic
aspects of the experience, and we need to do it soon.
I might re-iterate my feeling that external IDE integration projects
should be claimed by the community officially, and user experience +
debugging issues should be first-class issues in the main d language
bug-tracker so everybody can see them, and everybody is aware of the stats.
Also, the DMD front-end should be a lib offering auto-completion and
syntax hilighting data to clients.

I'm doing some more work on premake (a nice light buildsystem that
generated makefiles and project files for popular IDE's) to tightly
incorporate D into the various IDE's it supports.

</endrant>

Other then that I have to fully agree with all the points you listed.

Kind Regards
Benjamin Thaut