Had another 48hr game jam this weekend...

[Rikki Cattermole]

On Sunday, 1 September 2013 at 03:17:29 UTC, Trent wrote:
> On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:
>> We have to get the user experience and first impressions under 
>> control...
>>
>> I'd really love to to see a general roadmap and list of 
>> priorities. Even if
>> goals are high-level, they might help direct focus?
>>
>> So I had another game-jam this weekend with a bunch of friends 
>> who are all
>> industry professionals.
>> The point of a 48 hour game jam is to prioritise productivity 
>> and
>> creativity.
>> Choosing a language like D here makes sense from a 
>> productivity point of
>> view... that is, if it 'JUST WORKS'™.
>>
>> There were 7 programmers, they were all using D for the first 
>> time (except
>> me).
>>
>> Most running windows, one on OSX, one on Linux.
>> We ran into the same problems old that have been giving me the 
>> shits as
>> long as I've been using D.
>>
>> Configuring compilers:
>>
>> Naturally, this is primarily a problem with the windows 
>> experience, but
>> it's so frustrating that it is STILL a problem... how many 
>> years later?
>> People don't want to 'do work' to install a piece of software. 
>> Rather, they
>> expect it to 'just work'. We lost about 6 hours trying to get 
>> everyone's
>> machines working properly.
>> In the context of a 48 hour game jam, that's a terrible sign! 
>> I just kept
>> promising people that it would save time overall... which I 
>> wish were true.
>>
>> The only compiler you can realistically use productively in 
>> windows is
>> DMD-Win64, and that doesn't work out of the box.
>> We needed to mess with sc.ini for quite some time to get the 
>> stars aligned
>> such that it would actually compile and find the linker+libs.
>>
>> Walter: DMD needs to internally detect installations of 
>> various versions of
>> VisualStudio, and either 'just work', or amend sc.ini on its 
>> own. Or the
>> installer needs to amend sc.ini. Either way, leaving it to a 
>> user to fiddle
>> with an ini file just isn't acceptable. We had to google 
>> solutions to this
>> problem, and even then, we had trouble with the paths we added 
>> to sc.ini;
>> are spaces acceptable? Do they have quites around them?...
>> I might also suggest that Microsoft supplied (ie, 'standard'), 
>> libraries
>> should be automatically detected and path entries added in 
>> there too:
>>  C:\Program Files (x86)\Microsoft SDKs\...
>>  C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\...
>> These are on basically every windows developers machine, and 
>> each of us had
>> to configure them ourselves.
>>
>>
>> Getting a workable environment:
>>
>> Unsurprisingly, the Linux user was the only person happy work 
>> with a
>> makefile. Everybody else wanted a comfortable IDE solution 
>> (and the linux
>> user would prefer it too).
>>
>> !!!!!!!!!
>> 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 come to the conclusion that treating IDE integration as 
>> ancillary
>> projects maintained by usually just one single member of the 
>> community has
>> absolutely failed.
>> I suggest:
>> * These should be made central D community projects.
>> * I think they should be hosted in the same github 
>> organisation as DMD.
>> *** As many contributors as possible should be encouraged to 
>> work with
>> them every day.
>>   - Deprecate DMD makefiles. Seriously! Insist that 
>> contributors use the
>> IDE bindings to work on DMD.
>>   - The fact that you all laughed at the prior point suggests 
>> clearly why
>> it needs to be done. It will cease to be a problem when all the
>> druntime/phobos contributors are suffering the end-user 
>> experience.
>> * They should receive bugs in the main github bug-tracker, so 
>> EVERY D
>> contributor can see them, and how many there are.
>>
>> IDE integration absolutely needs to be considered a first 
>> class feature of
>> D.
>> I also suggest that the IDE integration downloads should be 
>> hosted on the
>> dlang download page so they are obvious and available to 
>> everyone without
>> having to go looking, and also as a statement that they are 
>> actually
>> endorsed by the dlanguage authorities. As an end-user, you're 
>> not left
>> guessing which ones are good/bad/out of date/actually work/etc.
>>
>> Obviously, we settled on Visual-D (Windows) and Mono-D 
>> (OSX/Linux); the
>> only realistic choices available. The OSX user would have 
>> preferred an
>> XCode integration.
>>
>> Overwhelmingly, the biggest complaint was a lack of symbolic 
>> information to
>> assist with auto-completion. Visual-D tries valiantly, but it 
>> falls quite
>> short of the mark.
>> This goes back to the threads where the IDE guys are writing 
>> their own
>> parsers, when really, DMD should be able to be built as a lib, 
>> with an API
>> designed for using DMD as a lib/plugin.
>> I think continuous code compilation for auto-completion and 
>> syntax
>> highlighting purposes should be a service offered and 
>> maintained by DMD.
>> That way it will evolve with the language, and anyone can use 
>> it without
>> reinventing the wheel.
>>
>>
>> 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.
>>
>>
>> Documentation:
>>
>> Okay for the most part, but some windows dev's want a CHM that 
>> looks like
>> the typical Microsoft doc's people are used to. Those that 
>> aren't familiar
>> with the CHM viewer; it's just HTML but with a nice index + 
>> layout tree.
>>
>>
>> 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...
>>
>>
>> Bugs:
>> Yes, we hit DMD bugs, like the one with opaque structs which 
>> required
>> extensive work-arounds.
>>  struct MyStruct;
>>  MyStruct*[] = new MyStruct*[n];
>>
>> We also ran into some completely nonsense error messages, but 
>> I forgot to
>> log them, since we were working against the clock.
>>
>>
>> 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.
>>
>>
>> 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>
>
> I've hinted a few times here and on Reddit that I've been 
> working
> on revamping/redoing CMake support for D.
>
> This project would have gone public almost a month ago if it
> weren't for the situation on Windows, but as it stands, I would
> only make it easier for new users to hit a brick wall when they
> try to do D development on Windows. I don't think that's very
> beneficial.
>
> To add to Manu's gripes:
>
> OMF vs COFF / optlink is ridiculous
>
> One of CMake's appeals is that it can check the system for
> needed libraries, and aid in linking to them. DMD32's
> need for OMF libraries throws an uncomfortable wrench into
> the situation, which I have yet to resolve to my satisfaction.
>
> VisualD generation was fairly straightforward. VS generation
> for mixed C/D projects is not something I'm even sure I can
> do (on Win32/DMD, that is), since to get VS to use a different
> C compiler (dmc), I need to make a VS config that defers to a
> makefile config. I'm not sure that CMake is set up to support 
> this.
>
> I'm still working on it during my (ever-shrinking) free time,
> but it's pretty slow going.

I also would love to see Microsoft's linker support for Win32 
added. Although not as a replacement for Optlink. More as an 
option that can be enabled.
So maybe at the same time a rethink of PE-COFF support should be 
in order? We could also fix the paths issue at the same time.

About the whole IDE thing my target for DOOGLE[1] is to 
eventually be able to build an IDE out of it. Possibly even a 
full windowing environment. Because honestly we need one fully 
written in D (IDE).

[1] https://github.com/rikkimax/DOOGLE