Had another 48hr game jam this weekend...

[Manu]

On 2 September 2013 01:02, Iain Buclaw <ibuclaw at ubuntu.com> wrote:

> On 1 September 2013 03:05, Manu <turkeyman at gmail.com> 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?
> >
>
> First impressions are important.  And I've found that whenever I talk
> about D, people are generally wow'd at some of the design choices of
> the language vs Java, C++.  But I do stress that focus is really the
> only area that we are lacking in to get us across the chasm in terms
> of adoption.
>
>
> >
> > 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.
> >
>
> Trying upgrading Windows.  https://www.fsf.org/windows8


Sadly, I already use Windows 8... *shudder* >_<

>
> > 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.
> >
>
> Central to the community projects?
> Absolutely yes.
>
> Hosted in same location as DMD?
> That's their choice if they want to do that.
>
> Deprecate DMD Makefile?
> I'd rather give both options, rather than force someone to go one way
> or the other.
>
> Force everyone to use IDE's?
> VIM is an IDE. :o)
>
>
> > IDE integration absolutely needs to be considered a first class feature
> of
> > D.
>
> An IDE is not a feature of a language.  Unless you are a RAD language
> that removes the ability of developers to write a single line of code
> (and do it awfully).
>

It certainly is in the case of C#. I think it's also central to C#'s
success. People got in, and feel productive within seconds of firing it up.
I've never had such a great language adoption experience. I clicked create
project, and started writing code.
The IDE is super helpful, and you can basically code by using the '.' key
and consequent auto-completion popups as a documentation replacement.

> 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.
> >
>
> That is their choice to make.
>

Sure, that's why it's a 'suggestion' :)

> 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.
> >
>
> Why not VIM?
>

Ummm, because I'm not a masochist? :)
But each to their own. No reason VIM shouldn't have a nice integration
too...

> 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.
>
> If you are referring to DMD as the whole application, that's their
> choice, but a library/plugin is not very useful for invoking directly.
> ;-)
>
> If you are referring to the D Front-End implementation, I will request
> for you to stop calling it DMD, and will also suggest a different
> approach.
> The components of the D Front-End are intended to be shared at the
> source level, rather than being a library that gets built, installed,
> and linked against. Thus, there is no distribution tarball; the idea
> is to copy files from D Front-End into your own source tree.
>
> This is something that I am working towards alongside DMD and LDC
> devs. So that we end up with a shared front-end between our compiler
> backends.  For IDE integration, they could in theory do the exact
> same.  Take the D Front-End and implement their backend against an
> IDE.
>

Yeah that, and I know you guys are on it, and that's awesome. I was just
stressing the importance of the project.
Also perhaps the focus on an API for use by tools and IDE integration might
be helpful, but I don't know the code and what it offers.

I was really just referencing the countless prior conversations on the
topic. When it's working, I suspect it'll help the IDE situation immensely.

>From conversations at dconf, I'm lead to believe one of the most important
elements that the d front end can offer is that it can still perform useful
analysis on partially compiled code, and on code that can't actually
compile due to errors (I think Don said CTFE depends on this ability a lot
too). Even in that case, the parts of the code that the compiler is able to
understand could still be offered for auto-completion purposes and all that
good stuff.
I'm sure it's very hard to reproduce that functionality in custom-written
semantic analysers, and it's critical to auto-complete analysis, in that
when you're in the process of typing code (when you use auto-complete),
it's rarely in a state that it can successfully compile ;)

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

The D frontend, whatever... it should be recycled to do the work, since
it's already the best at it. I'm just repeating myself...

>
> > 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.
> >
> >
>
> This is why GDC rox.
>

O_o ... GDC produces DWARF info, which isn't so useful in windows.
We used to roll with dwarf->pdb conversion, but I think there's quite a
loss in translation, and it didn't work too well.

> 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.
> >
> >
>
> Use the web?
>

Do. But the website is slow, and you probably haven't tried to use the
internet in Australia recently.
Also, our new government intends to set Australia's internet back about 10
years:
http://www.youtube.com/watch?v=b-6E5yX1E0U
http://www.youtube.com/watch?v=tpN7VCzDTdg
http://www.youtube.com/watch?v=zyY-xI6zgfk

Quality leadership to be sure...
Note: I can only watch these in 320p after about 20-30 seconds buffer time
;)

> Bugs:
> > 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 if that should work / don't see the advantage over just
> using a void*.
>

struct Mesh;
struct Material;

Mesh* mesh;
Material* material;

material = mesh; // ?

> We also ran into some completely nonsense error messages, but I forgot to
> > log them, since we were working against the clock.
> >
> >
>
> Shame on you.
>

>_<

> 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.
> >
> >
>
> That does seem more of the point of D interface files (.di).
>

I'm amazed at the resistance to this (a few no's, any yes's at all?). Do
people here actually write D code, or rather, non-trivial D code? O_o
Perhaps the dev's here use relatively few, or very simple classes?
Seriously, how do you quickly read and understand the API through the noise?
I really can't get my head around it... Why wouldn't you want to be able to
read a convenient summary of what a class is and does?
And why would you want to indent every line of function code by a few tabs?

Can anyone offer me ANY benefits? It legitimately blows my mind... O_O
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130902/454c900e/attachment.html>