Had another 48hr game jam this weekend...

[Jakob Ovrum]

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>