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>

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.

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>

On 2013-09-01 02:05:39 +0000, Manu <turkeyman@gmail.com> said:

> I might re-iterate my feeling that external IDE integration projects should
> be claimed by the community officially

In my opinion the community is just too short on man-hours.

I did integrate D with Xcode at one point (no autocompletion though) and created an all-in-one installer for the compiler and the Xcode plugin. It just worked. I don't maintain it anymore and Xcode 4 broke it. It's open source so anyone in the community could have taken it further, but so far this hasn't happened.

I'm not using D anymore. I realized that with the time required to maintain the toolset (including installer and Xcode plugin) plus the time it'd take to make the language suitable to my needs (Objective-C integration, perhaps ARM support for iOS), all that by itself would probably be more than one full-time job. As all this meta-work would seriously get in the way of my actual work, I let it go. I'm not regretting that move.

So I'm no longer using D, but I'm still hanging around here from time to time because there's always something interesting to read.


-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca

 Yes IDE should be built with the language :)

D has bad IDE support that is why I read about D but don't actually use it...

Sorry about the nonsensical reply, the web interface was acting up... this is the intended reply.

On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:
> The only compiler you can realistically use productively in windows is
> DMD-Win64, and that doesn't work out of the box.

Why didn't you go with DMD-Win32? Because of OMF? implib and/or objconv is a hassle but probably less of a hassle than using the nascent DMD-Win64.

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

Although I'm not convinced auto-completion is a vital feature (Microsoft's C++ IntelliSense is shit too), I agree that any time spent on custom parsers and best-effort semantic analysis is a complete waste of time. The only semantic analysis engine that is going to be sufficiently good for D is one from a compiler front-end. Apart from DMD, it's worth taking a look at SDC for this.

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

dmd2\windows\bin\d.chm

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

`std.algorithm.remove` provides both stable (preserves order, shuffles entire array down) and unstable (swaps with last element and shrinks by one) removal. However, Phobos does not make a habit of providing helpers for strictly O(n) algorithms, so the O(n) nature has to be made explicit by first getting the index with `std.algorithm.countUntil`.

Removing a pair from an AA by value is also an exercise in linear search, and as such will not get a deceptive helper function. However, once range interfaces for AAs mature, such an algorithm can be composed trivially.

> Yes, we hit DMD bugs, like the one with opaque structs which required
> extensive work-arounds.
>   struct MyStruct;
>   MyStruct*[] = new MyStruct*[n];

I'm not sure this is a bug. How do you default initialize an array of structs you don't know the .init values of?

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

On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:
> 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.

I also spent a decent bit of effort getting Win64 to work, and I agree that this is something that DMD should attempt to bundle. It may not need to go as far as downloading VC express for you, but it should allow integration of an existing install during installation (and ideally post-installation as well). This is a pretty big deal IMO. When I was a newbie, issues with COFF vs OMF, coffimplib confusion, etc, were almost deal-breakers to me. I just couldn't get things easily working, and I'm sure many others see it the same way. Having Win64 gives us a chance to fix that, but it *has* to be integrated into the installer. The compiler should ideally detect that the VS linker / libraries are missing when you use -m64, and tell you how to download VS Express as well as directing you to a batch file bundled with DMD to update sc.ini. Going a step further, it'd be even nicer if -m64 was default but that's not feasible with external dependencies. However when it detects a library in an invalid format, it should inform you about the existence of coffimplib and a download link, as well as how this is necessary only when compiling 32-bit executables. I don't think that the core contributors realize how incredibly frustrating these issues are to beginners, and thus feel as if it's not something that needs to be solved.

> 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 to say, I don't see why you find this to be such a large issue. DMD is unique in the sense that it's the only thing I've ever been able to compile on Windows without running into many issues. So long as you have DMC installed, it just works. I've never had any makefile related issues on any platform. This is a big deal, as DMD evolves so rapidly that users should be able to get the git version with minimal effort, without having to download an IDE for it.

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

While yes, it would be wonderful if we could get DMD to do this (again, I don't think a lot of the core contributors realize just how incredibly important IDEs and perfect auto-completion are), it doesn't seem to be something likely in the short-term. That being said, I've actually found Mono-D to be excellent recently. It doesn't handle things like CTFE properly and other similar issues, but for my purposes it's worked rather well (that being said, I avoid mixins for the most part, largely due to this). Despite all this, I'm actually quite happy with Mono-D lately.

One thing I've toyed with is the idea of using reflection for getting auto-complete information. I made a runtime reflection module (has a fair few issues still), and I wonder if it would be possible to use something similar for this purpose. Most modules could be cached, allowing us to build only the module you're altering. On top of that, some real-time parsing could be done for code modified since the last recompile (really it would need to primarily handle scanning for methods and variables). History completion from the current file, such as what editors like Sublime Text do, could perhaps be integrated to completely eliminate the issue of not being able to find a symbol in your auto-complete list. That would likely only kick in when it finds no results for anything else. Plus since you're recompiling frequently in the background, you would get early notifications of errors/warnings like you would in C#/Java. Ultimately though, I'm not sure if this would be updated fast enough (depends how long compiles take) to be feasible.


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

Agreed, debugging is currently lacking thoroughly. Using Linux, Mono-D's works okay but it still jumps around a lot (even in debug mode) and hovering over variables isn't great yet. I really miss the Immediate Window from C# / Visual Studio, and it would be nice to have that. This is something that runtime reflection could handle.

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

Completely agreed. Containers are another huge problem which needs to be solved as soon as possible, yet is constantly getting pushed back. The idea that a language like D doesn't even have anything but the most basic containers in it's standard library is laughable. I shudder to think at how many different implementations exist of common containers right now in user code.

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

I used to hit compiler bugs very frequently, yet this is something that D has improved incredibly on. It's wonderful to not have to worry with every compile if there will be bugs. It's also wonderful to not have to worry about changing your code with every single compiler release. D has made *huge* headway in these two issues. Sure, there are still many bugs, but they're becoming less frequent for me and I find that workarounds are easier than before.

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

This isn't something I've found to be an issue personally, but I suppose it's a matter of what you're used to. Since I'm used to C#, I haven't had problems with this. I've always felt that this was the IDE's job, personally. That being said, perhaps .di files could help with this?

On 8/31/2013 7:05 PM, Manu wrote:
> 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.

The default sc.ini contains:
-----------------------------
[Version]
version=7.51 Build 020

[Environment]
LIB="%@P%\..\lib";\dm\lib
DFLAGS="-I%@P%\..\..\src\phobos" "-I%@P%\..\..\src\druntime\import"
LINKCMD=%@P%\link.exe
LINKCMD64=%VCINSTALLDIR%bin\amd64\link.exe
VCINSTALLDIR=%VCINSTALLDIR%
WindowsSdkDir=%WindowsSdkDir%
----------------------------------

When I installed VC 2010, it set the environment variables VCINSTALLDIR and WindowsSdkDir. Then, the default sc.ini should "just work".

What went wrong, specifically?

On Sun, 01 Sep 2013 06:45:48 +0200
"Kapps" <opantm2+spam@gmail.com> wrote:

> On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:
> > 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.
> 
> This isn't something I've found to be an issue personally, but I suppose it's a matter of what you're used to. Since I'm used to C#, I haven't had problems with this. I've always felt that this was the IDE's job, personally. That being said, perhaps .di files could help with this?

I see it as the job of doc generators.