Had another 48hr game jam this weekend...

[Manu]

On 1 September 2013 18:06, Benjamin Thaut <code at 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/**522f6dbeb93944ebfebde6f938a2ee*
> *3a2d6be124<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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130901/0503c505/attachment-0001.html>