Had another 48hr game jam this weekend...

[Trent]

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.