<div dir="ltr">On 1 September 2013 18:06, Benjamin Thaut <span dir="ltr"><<a href="mailto:code@benjamin-thaut.de" target="_blank">code@benjamin-thaut.de</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am 01.09.2013 04:05, schrieb Manu:<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
!!!!!!!!!<br>
This has to be given first-class attention!<br>
I am completely and utterly sick of this problem. Don made a massive<br>
point of it in his DConf talk, and I want to re-re-re-re-re-re-re-stress<br>
how absolutely important this is.<br>
!!!!!!!!!<br>
</blockquote>
<br></div>
I have to fully agree here.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Debugging:<br>
<br>
Poor debugging experience wastes your time every 5 minutes.<br>
I can only speak for the Windows experience (since we failed to get OSX<br>
working); there are lots of problems with the debugging experience under<br>
visual studio...<br>
I haven't logged bugs yet, but I intend to.<br>
There were many instances of people wasting their time chasing bugs in<br>
random places when it was simply a case of the debugger lying about the<br>
value of variables to them, and many more cases where the debugger<br>
simply refused to produce values for some variables at all.<br>
This is an unacceptable waste of programmers time, and again, really<br>
burned us in a 48hour context.<br>
<br>
</blockquote>
<br></div>
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.<br>

<br>
<a href="https://github.com/Ingrater/dmd/commit/522f6dbeb93944ebfebde6f938a2ee3a2d6be124" target="_blank">https://github.com/Ingrater/<u></u>dmd/commit/<u></u>522f6dbeb93944ebfebde6f938a2ee<u></u>3a2d6be124</a><br>
<br>
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).<br>
</blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Then everything will work nicely. The only real issue is, that the debugger can't identify which class is behind a given interface.<br>
<br>
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).</blockquote>
<div><br></div><div>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.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Containers:<br>
<br>
The question came up multiple times; "I don't think this should be an<br>
array... what containers can I use, and where are they?"...<br>
Also, nobody could work out how to remove an arbitrary item from an<br>
array, or an item from an AA by reference/value (only by key).<br>
<br>
This code:<br>
   foreach(i, item; array)<br>
     if(item == itemToRemove)<br>
       array = array[0..i] ~ array[i+1..$];<br>
Got a rather 'negative' reaction from the audience to put it lightly...<br>
<br>
</blockquote>
<br></div>
Oh containers, I would love to have some. Like every one else using D I've written my own by now.</blockquote><div><br></div><div>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.</div>
<div>Templates, and various typing complexities always seem to complicate the issue.</div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
One more thing:<br>
I'll just pick one language complaint from the weekend.<br>
It is how quickly classes became disorganised and difficult to navigate<br>
(like Java and C#).<br>
We all wanted to ability to define class member functions outside the<br>
class definition:<br>
   class MyClass<br>
   {<br>
     void method();<br>
   }<br>
<br>
   void MyClass.method()<br>
   {<br>
     //...<br>
   }<br>
<br>
It definitely cost us time simply trying to understand the class layout<br>
visually (ie, when IDE support is barely available).<br>
You don't need to see the function bodies in the class definition, you<br>
want to quickly see what a class has and does.<br>
<br>
</blockquote>
<br></div>
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.<br></blockquote><div>
<br></div><div>Sometimes...</div><div>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.</div>
<div>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.</div>
<div><br></div><div>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.</div>
<div>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.</div>
<div><br></div><div>My hope from the Remedy experience was to prove that it works in a commercial environment.</div><div>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).</div>
<div>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.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
Conclusion:<br>
I think this 48 hour jam approach is a good test for the language and<br>
it's infrastructure. I encourage everybody to try it (ideally with a<br>
clean slate computer).<br></div><div class="im">
The lesson is that we need to make this process smooth, since it mirrors<br>
the first-experience of everybody new to D.<br>
It also highlights and magnifies time-wasters that are equally<br>
unacceptable in a commercial environment.<br>
<br>
I don't think I made any converts this weekend wrt the above issues<br>
encountered. I might have even just proved to them that they should<br>
indeed stick with C# (the IDE's work!)... :(<br>
<br>
Please, we need a road-map, we need to prioritise these most basic<br>
aspects of the experience, and we need to do it soon.<br>
I might re-iterate my feeling that external IDE integration projects<br>
should be claimed by the community officially, and user experience +<br>
debugging issues should be first-class issues in the main d language<br>
bug-tracker so everybody can see them, and everybody is aware of the stats.<br>
Also, the DMD front-end should be a lib offering auto-completion and<br>
syntax hilighting data to clients.<br>
<br>
I'm doing some more work on premake (a nice light buildsystem that<br>
generated makefiles and project files for popular IDE's) to tightly<br>
incorporate D into the various IDE's it supports.<br>
<br>
</endrant><br>
</div></blockquote>
<br>
Other then that I have to fully agree with all the points you listed.<br>
<br>
Kind Regards<span class="HOEnZb"><font color="#888888"><br>
Benjamin Thaut<br>
<br>
</font></span></blockquote></div><br></div></div>