Had another 48hr game jam this weekend...

[Benjamin Thaut]

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

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

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


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

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