Had another 48hr game jam this weekend...

Manu turkeyman at gmail.com
Sun Sep 1 20:51:41 PDT 2013


On 2 September 2013 05:20, Jacob Carlborg <doob at me.com> wrote:

> On 2013-09-01 16:32, Manu wrote:
>
>  Well we never got OSX working (under mono-d), although this was mainly
>> due to supporting apple infrastructure in the end. I think we wrangled
>> the toolchain in the end, but never got everything linking; C++
>> dependencies got complicated.
>> We eventually gave up, just wasting too much time, and he went off and
>> did the music/sounds for the game...
>>
>
> Gave up? Why not just use DMD directly from the zip on the command line
> and use TextMate or Sublime. TextMate 2 supports in app download of new
> languages and Sublime comes with support for D out of the box. Even though
> it's not perfect it has to be better than giving up.
>

I dunno. People just don't do that.
It's perceived that typing commands in the command line is a completely
unrealistic workflow for most people that doesn't love linux.
He would have also had to have written himself a makefile, and none of us
know how to write a makefile. I generate makefiles with other tools, but
there are no good makegen tools that support D and C projects together, and
even if there were, you'd just be writing a makegen script instead, which
we still didn't know how to write...
We also really didn't have time to stuff around with it. He just went and
recorded audio instead.

Side note; I'm working on support in premake for parallel C and D project
generation for popular IDE's and makefiles. But it's not there yet.

 If you'd like to help me finish that OSX work we started together last
>> year, that'd be really great for next time! :)
>>
>
> Well, I'm quite busy with my own projects. But I could perhaps give you a
> hand if you need. Although I don't want to do all the work as last time.
>

Fair enough. Well I don't have a Mac, and I don't know Cocoa, or ObjC... :/

 No, actually, as much as I keep banging on the IDE thing, in this case I
>> absolutely don't want help from the IDE, I just want to look at my page
>> of text, and be able to read a useful summary.
>> Can you give me any good reasons why fully defined functions polluting
>> the readability of a class definition could possibly be a good thing?
>> I just don't get it... why would you ever want to break up the nice
>> summary of what a class has&does, and why would you want to indent all
>> of your functions an extra few tab levels by default?
>>
>
> To keep everything in one place. Why would you want to duplicate the
> method signatures? I hate the header/source synchronization in the C family
> of languages. Especially in C++ where the signatures cannot even be exactly
> the same between the header and source file. I'm thinking of default
> values, for example.
>

I'm not suggesting it be in a separate file, Just below the class
definition somewhere.
The IDE actually can help here. If it detects you've modified a function
signature, and it's defined lower in the file, it can fairly easily change
it for you there too.

 As a programmer, I spend a lot more time reading code than
>> documentation, and much of that time is spent reading it in foreign
>> places like github commit logs (limited horizontal space), diff/merge
>> windows (hard to distinguish class API changes vs function body changes
>> at a glance, since they're interleaved), even chat clients and
>> communication tools. The IDE can't assist in any of these contexts. If
>> you have to have an IDE to read your code, then something is really wrong.
>>
>
> That I agree with.
>

So the conclusion is to put the IDE's assistance burden on the authoring
side, not the reading side.
Ie, when you change a function signature, IDE can update the definition's
signature too.

Good IDE's have awesome refactor tools, where you change a signature, and
it will change it at all places that it is referenced.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130902/181bb0fc/attachment-0001.html>


More information about the Digitalmars-d mailing list