Had another 48hr game jam this weekend...

[Iain Buclaw]

On 1 September 2013 17:37, Manu <turkeyman at gmail.com> wrote:
> 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:
>> > 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.
>

Yeah... I'm still not buying it. :o)


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

Well my perspective doesn't help that whenever I think of IDE, the
image of clippy comes into my head.

http://vigor.sourceforge.net/screenshots/fullscreen.png


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

Ah, I just didn't understand what you were referring to first time
round (the "as a service" was confusing also. :o)

I assume you mean using *enter IDE name here* to run syntax checks on
your code as you type to highlight errors before you build using the
compiler proper?


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

This is why using a free system rox.


>> > 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; // ?
>

The only used case I can think is in C++ bindings where you don't want
to define the contents, but want to have the correct mangling (this
I've had a partial need for in a project I'm working on behind the
scenes that will come out at around the 2.064 release :-)

The language implementation would have to be changed to not produce
TypeInfo for opaque types, but this might be undesirable in
restrictions to the use of such types, but I guess you are asking for
it if you want it.


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

Yes... though not outside the boundaries of implementing languages /
interpreters / bytecode compilers. ;-)


> Perhaps the dev's here use relatively few, or very simple classes?

K.I.S.S.


> Seriously, how do you quickly read and understand the API through the noise?

Depends how well the author was at documenting his API.


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

Document the class as you write it.


> And why would you want to indent every line of function code by a few tabs?
>

I use GNU style myself...  (that probably *does* make me a masochist).

http://en.wikipedia.org/wiki/Indent_style#GNU_style


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';