www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - 48 hour game jam

reply Manu <turkeyman gmail.com> writes:
--bcaec51d25d45beaef04cc17ac1d
Content-Type: text/plain; charset=UTF-8

We did a 48hr game jam at work this past weekend.
We decided to do our entry in D, to further prove that D was a viable and
productive solution for real-world game dev.

Here's our entry, for those interested.
It has only been built/tested in Windows using VS2010, but it should
theoretically work on Linux and consoles as well (but the build scripts
aren't setup to do it automatically).
If there is interest, I will create the build scripts, and test on Linux.

https://github.com/RemedyGameJam/stache/wiki

--bcaec51d25d45beaef04cc17ac1d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

We did a 48hr game jam at work this past weekend.<div>We decided to do our =
entry in D, to further prove that D was a viable and productive solution fo=
r real-world game dev.</div><div><br></div><div>Here&#39;s our entry, for t=
hose interested.</div>
<div>It has only been built/tested in Windows using VS2010, but it should t=
heoretically work on Linux and consoles as well (but the build scripts aren=
&#39;t setup to do it automatically).</div><div>If there is interest, I wil=
l create the build scripts, and test on Linux.</div>
<div><br></div><div><a href=3D"https://github.com/RemedyGameJam/stache/wiki=
">https://github.com/RemedyGameJam/stache/wiki</a></div><div><br></div>

--bcaec51d25d45beaef04cc17ac1d--
Oct 15 2012
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Manu:

 We did a 48hr game jam at work this past weekend. We
 decided to do our entry in D, to further prove that D was
 a viable and productive solution for real-world game dev.

And how did D do? Bye, bearophile
Oct 15 2012
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
--047d7bb0495a40d16804cc1a4f70
Content-Type: text/plain; charset=UTF-8

On 15 October 2012 17:02, bearophile <bearophileHUGS lycos.com> wrote:

 Manu:


  We did a 48hr game jam at work this past weekend. We
 decided to do our entry in D, to further prove that D was
 a viable and productive solution for real-world game dev.

And how did D do?

Well actually. It was my team-mates first D code. He was interested, read some stuff, never actually wrote any code. We actually took quite tangible benefits from using D for this one. We actually used the class factory (!), I didn't think I'd ever use that ;) Also used a convenient C# style event system, trivial to implement in D. But mainly it's all the little things, conveniences that add up and make the experience more enjoyable. That said, the code probably isn't particularly idiomatic D code. That's to be expected from new comers I suppose, bringing the conventions of their languages to the table, but it's also a great thing in terms of adoption potential, people can ween themselves in slowly. It's not an all or nothing switch. --047d7bb0495a40d16804cc1a4f70 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 15 October 2012 17:02, bearophile <span dir=3D"ltr">&lt;<a href=3D"mailt= o:bearophileHUGS lycos.com" target=3D"_blank">bearophileHUGS lycos.com</a>&= gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_= quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1= ex"> Manu:<div class=3D"im"><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> We did a 48hr game jam at work this past weekend. We<br> decided to do our entry in D, to further prove that D was<br> a viable and productive solution for real-world game dev.<br> </blockquote> <br></div> And how did D do?<br></blockquote><div><br></div><div>Well actually.</div><= div>It was my team-mates first D code. He was interested, read some stuff, = never actually wrote any code.</div><div>We actually took quite tangible be= nefits from using D for this one. We actually used the class factory (!), I= didn&#39;t think I&#39;d ever use that ;)</div> <div>Also used a convenient C# style event system, trivial to implement in = D. But mainly it&#39;s all the little things, conveniences that add up and = make the experience more enjoyable.</div><div><br></div><div>That said, the= code probably isn&#39;t particularly idiomatic D code. That&#39;s to be ex= pected from new comers I suppose, bringing the conventions of their languag= es to the table, but it&#39;s also a great thing in terms of adoption poten= tial, people can ween themselves in slowly. It&#39;s not an all or nothing = switch.</div> </div> --047d7bb0495a40d16804cc1a4f70--
Oct 15 2012
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Oct 16, 2012 at 12:34:44AM +0200, Paulo Pinto wrote:
 On Monday, 15 October 2012 at 22:14:48 UTC, H. S. Teoh wrote:

It *is* a pretty crazy idea to prohibit STL, seeing as STL is what
makes writing container-related C++ code bearable. I have horrible
memories of the Bad Old Days when I must've reinvented linked lists
at least 20 times, just because STL didn't exist in those days.

When templates first came out, I was elated that finally I didn't
have to implement Yet Another Linked List. Perhaps it took that kind
of experience to appreciate templates. :-) People who didn't have to
suffer through these kinds of limitations often don't appreciate what
templates offer. (And that's C++ templates, with all their warts, not
even speaking about D templates -- which are on a whole 'nother
level.)


 You should talk with the Go guys which seem to be happy re-inventing
 the type of tools we used in C++, back in the days templates were
 still not available, somewhere around 1993 in my case.

On the contrary, I should shut up and let them spend their time reinventing the wheel, while D moves forward to wider adoption. ;-)
 Does anyone remember the pre-processor hacks from Borland C++?

I remember Borland C++, yes... but I don't recall what preprocessor hacks were there. T -- For every argument for something, there is always an equal and opposite argument against it. Debates don't give answers, only wounded or inflated egos.
Oct 15 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--047d7b6d9340f7fa0204cc22e852
Content-Type: text/plain; charset=UTF-8

On 16 October 2012 01:47, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:

 On Tue, Oct 16, 2012 at 12:34:44AM +0200, Paulo Pinto wrote:
 On Monday, 15 October 2012 at 22:14:48 UTC, H. S. Teoh wrote:

It *is* a pretty crazy idea to prohibit STL, seeing as STL is what
makes writing container-related C++ code bearable. I have horrible
memories of the Bad Old Days when I must've reinvented linked lists
at least 20 times, just because STL didn't exist in those days.

When templates first came out, I was elated that finally I didn't
have to implement Yet Another Linked List. Perhaps it took that kind
of experience to appreciate templates. :-) People who didn't have to
suffer through these kinds of limitations often don't appreciate what
templates offer. (And that's C++ templates, with all their warts, not
even speaking about D templates -- which are on a whole 'nother
level.)


 You should talk with the Go guys which seem to be happy re-inventing
 the type of tools we used in C++, back in the days templates were
 still not available, somewhere around 1993 in my case.

On the contrary, I should shut up and let them spend their time reinventing the wheel, while D moves forward to wider adoption. ;-)
 Does anyone remember the pre-processor hacks from Borland C++?

I remember Borland C++, yes... but I don't recall what preprocessor hacks were there.

Possibly one of the most epic thread hijack's I've seen in a while! ;) --047d7b6d9340f7fa0204cc22e852 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 16 October 2012 01:47, H. S. Teoh <span dir=3D"ltr">&lt;<a href=3D"mailt= o:hsteoh quickfur.ath.cx" target=3D"_blank">hsteoh quickfur.ath.cx</a>&gt;<= /span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quot= e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On Tue, Oct 16, 2012 at 12:34:44AM +0200, Paulo Pinto wro= te:<br> &gt; On Monday, 15 October 2012 at 22:14:48 UTC, H. S. Teoh wrote:<br> </div>[...]<br> <div class=3D"im">&gt; &gt;It *is* a pretty crazy idea to prohibit STL, see= ing as STL is what<br> &gt; &gt;makes writing container-related C++ code bearable. I have horrible= <br> &gt; &gt;memories of the Bad Old Days when I must&#39;ve reinvented linked = lists<br> &gt; &gt;at least 20 times, just because STL didn&#39;t exist in those days= .<br> &gt; &gt;<br> &gt; &gt;When templates first came out, I was elated that finally I didn&#3= 9;t<br> &gt; &gt;have to implement Yet Another Linked List. Perhaps it took that ki= nd<br> &gt; &gt;of experience to appreciate templates. :-) People who didn&#39;t h= ave to<br> &gt; &gt;suffer through these kinds of limitations often don&#39;t apprecia= te what<br> &gt; &gt;templates offer. (And that&#39;s C++ templates, with all their war= ts, not<br> &gt; &gt;even speaking about D templates -- which are on a whole &#39;nothe= r<br> &gt; &gt;level.)<br> </div>[...]<br> <div class=3D"im">&gt; You should talk with the Go guys which seem to be ha= ppy re-inventing<br> &gt; the type of tools we used in C++, back in the days templates were<br> &gt; still not available, somewhere around 1993 in my case.<br> <br> </div>On the contrary, I should shut up and let them spend their time<br> reinventing the wheel, while D moves forward to wider adoption. ;-)<br> <div class=3D"im"><br> <br> &gt; Does anyone remember the pre-processor hacks from Borland C++?<br> </div>[...]<br> <br> I remember Borland C++, yes... but I don&#39;t recall what preprocessor<br> hacks were there.<br></blockquote><div><br></div><div>Possibly one of the m= ost epic thread hijack&#39;s I&#39;ve seen in a while! ;)</div></div> --047d7b6d9340f7fa0204cc22e852--
Oct 15 2012
prev sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 15 October 2012 at 22:45:16 UTC, H. S. Teoh wrote:
 On Tue, Oct 16, 2012 at 12:34:44AM +0200, Paulo Pinto wrote:
 On Monday, 15 October 2012 at 22:14:48 UTC, H. S. Teoh wrote:

It *is* a pretty crazy idea to prohibit STL, seeing as STL is 
what
makes writing container-related C++ code bearable. I have 
horrible
memories of the Bad Old Days when I must've reinvented linked 
lists
at least 20 times, just because STL didn't exist in those 
days.

When templates first came out, I was elated that finally I 
didn't
have to implement Yet Another Linked List. Perhaps it took 
that kind
of experience to appreciate templates. :-) People who didn't 
have to
suffer through these kinds of limitations often don't 
appreciate what
templates offer. (And that's C++ templates, with all their 
warts, not
even speaking about D templates -- which are on a whole 
'nother
level.)


 You should talk with the Go guys which seem to be happy 
 re-inventing
 the type of tools we used in C++, back in the days templates 
 were
 still not available, somewhere around 1993 in my case.

On the contrary, I should shut up and let them spend their time reinventing the wheel, while D moves forward to wider adoption. ;-)
 Does anyone remember the pre-processor hacks from Borland C++?

I remember Borland C++, yes... but I don't recall what preprocessor hacks were there. T

I don't recall any longer how they were exactly. In can recall that they were implemented with macros. Then you needed to #define a set of values and include the relevant file multiple times for each set of parameter macros. -- Paulo
Oct 15 2012
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Monday, 15 October 2012 at 15:01:27 UTC, Manu wrote:
 
 But mainly it's all the little things, conveniences that add up 
 and make
 the experience more enjoyable.

I find this as well. D has a lot of neat and interesting features, but really the big advantages over C++ (for me) are: - No header files - Closures - Polymorphic lambdas - Aliases - Simple(r) templates The biggest problem with D at the moment for me is the quality of error messages, especially when using templates with constraints. The best error you'll get is "can't call this function with these arguments", and you have to go through and manually expand the templates in your head to see what went wrong. Not fun.
Oct 15 2012
prev sibling next sibling parent "F i L" <witte2008 gmail.com> writes:
On Monday, 15 October 2012 at 11:52:49 UTC, Manu wrote:
 We did a 48hr game jam at work this past weekend.
 We decided to do our entry in D, to further prove that D was a 
 viable and
 productive solution for real-world game dev.

 Here's our entry, for those interested.
 It has only been built/tested in Windows using VS2010, but it 
 should
 theoretically work on Linux and consoles as well (but the build 
 scripts
 aren't setup to do it automatically).
 If there is interest, I will create the build scripts, and test 
 on Linux.

 https://github.com/RemedyGameJam/stache/wiki

Nice! I might not get a chance to download the game in the next few days, but I glanced at the source and everything looks cool. Any screenshots? About that Linux build script, if you manage to make it, let me know :) ps. I'm surprised I don't see a bunch of 'final ...' throughout your code. I thought a big issue of yours in the past was D's auto-virtual functions. Has something been changed in that area that I missed, or have you just not gotten around to doing it (or you don't need it for this project)?
Oct 15 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Oct 15, 2012 at 06:37:06PM +0200, Peter Alexander wrote:
 On Monday, 15 October 2012 at 15:01:27 UTC, Manu wrote:
But mainly it's all the little things, conveniences that add up and
make the experience more enjoyable.

I find this as well. D has a lot of neat and interesting features, but really the big advantages over C++ (for me) are: - No header files - Closures - Polymorphic lambdas

Yeah closures are a major necessity in any modern language. Recently I've had to work with some code that was greatly simplified because I could simply return closures. Writing the same code in C++ or C would have required horrendously more code and complexity. I also found std.algorithm and std.range to be incredibly powerful in expressing common sequential operations in a concise way, often as one-liners where in C++ you'd have to manually write a for/while loop with manually-managed indices, increments, loop termination conditions, etc.. Writing custom structs/classes to conform to the range API also makes it possible to pass things around to library code that expect ranges, greatly eliminating lots of boilerplate code that would be needed in C++ to transcribe from one object list to another and back, ad nauseum.
 - Aliases
 - Simple(r) templates

The biggest advantage of D templates is that the syntax is actually sane!! When I was coding in C++, my eyes started to glaze over as soon as templates get nested more than 2 levels deep. Especially when a compiler error message contained a single template name that spanned 16 lines of output. Not fun.
 The biggest problem with D at the moment for me is the quality of
 error messages, especially when using templates with constraints.  The
 best error you'll get is "can't call this function with these
 arguments", and you have to go through and manually expand the
 templates in your head to see what went wrong. Not fun.

I've asked before for a "catch-all" template, which is a template that will be selected only if no other template is matched. This can then be used in library code to print a nicer error message than the current situation where the compiler basically talks to you in Klingon. One alternative I've thought of (and tried before on one occasion) is that instead of writing: RetVal MyTemplateFunc(T)(T args...) if (Condition1) {...} RetVal MyTemplateFunc(T)(T args...) if (Condition2) {...} RetVal MyTemplateFunc(T)(T args...) if (Condition3) {...} One could write: RetVal MyTemplateFunc(T)(T args...) { static if (Condition1) { ... } else static if (Condition2) { ... } else static if (Condition3) { ... } else static assert(0, NiceErrorMsgOnWhyConditionsDidNotMatch); } To be even more helpful, one could expand the static assert into a block: ... else { pragma(msg, "Template conditions failed:"); pragma(msg, "Condition1 Clause1 = ", Condition1_clause1); pragma(msg, "Condition1 Clause2 = ", Condition1_clause2); pragma(msg, "Condition2 = ", Condition2); ... static assert(0); } Something like this is probably the compiler's job, but one could present the info in a more human-understandable way, for example: RetVal MyTemplateFunc(S,T)(S s, T t) { static if (isInputRange!S) { static if (isForwardRange!T) ... else static assert(0, "t must be forward range when s is output range"); } else static if (isForwardRange!S) { static if (isOutputRange!T) ... else static assert(0, "t must be output range when s is forward range"); } else ... } Of course, effort needs to be invested to write code in this way in the first place. As a baseline, it's probably still better to have the compiler print out exactly which conditions failed to match (by recursively expanding templates for you). The output will be very verbose, though. T -- MACINTOSH: Most Applications Crash, If Not, The Operating System Hangs
Oct 15 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 15 October 2012 at 16:37:08 UTC, Peter Alexander wrote:
 On Monday, 15 October 2012 at 15:01:27 UTC, Manu wrote:
 
 But mainly it's all the little things, conveniences that add 
 up and make
 the experience more enjoyable.

I find this as well. D has a lot of neat and interesting features, but really the big advantages over C++ (for me) are: - No header files - Closures - Polymorphic lambdas - Aliases - Simple(r) templates The biggest problem with D at the moment for me is the quality of error messages, especially when using templates with constraints. The best error you'll get is "can't call this function with these arguments", and you have to go through and manually expand the templates in your head to see what went wrong. Not fun.

For me: - aliases (Can't believe how Java and C# don't have them) - templates - meta-programming - open source language Sadly at work it is hard to sneak in D, because we mainly do JVM/.NET stuff, with C++ projects considered legacy(!). -- Paulo
Oct 15 2012
prev sibling next sibling parent "so" <so so.so> writes:
On Monday, 15 October 2012 at 16:37:08 UTC, Peter Alexander wrote:
 ...
 - Simple(r) templates

I keep seeing things like this and probably i am failing to understand it. This is a vast understatement for D templates. Yes, easier to use, i agree. But C++ templates are stone age comparing to D and i don't see this mentioned enough where it matters most. It was there in recent reddit discussions too. I am reading those comments (some posters obviously have some kind of agenda) and seeing no one refuting them. They neither know C++ well enough to do metaprogramming nor D. Because if they did know, they would never bring templates into any discussions which involves C++/D comparison. Comparing to C++. * D templates easier to use. * There are constructs you can't just do templates without. (templates without "static if" is c without "if") * Some things possible (string/float/alias/... arguments) because there is no C++ way of doing these. * Some things possible in practice (there are things you can achieve with C++ templates but they are practically impossible) * You can have all these and able get higher performance. There are probably more of those i just can't remember now.
Oct 15 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Oct 15, 2012 at 07:19:42PM +0200, so wrote:
 On Monday, 15 October 2012 at 16:37:08 UTC, Peter Alexander wrote:
...
- Simple(r) templates

I keep seeing things like this and probably i am failing to understand it. This is a vast understatement for D templates. Yes, easier to use, i agree. But C++ templates are stone age comparing to D and i don't see this mentioned enough where it matters most. [...]

One of the major advances of D templates over C++ is its potent combination with other D features like aliases/enums, static if, compile-time introspection, and signature constraints. For example, consider this: // This template checks if T satisfies certain properties, like // having a .NodeType type, parseAtom and parsePrimary methods, // etc. template isExprType(T) { static if (is(T.NodeType) && is(isNodeType!(T.NodeType) && is(T.parseAtom(Lexer.init)) && is(T.parsePrimary(Lexer.init)) && ...) { enum isExprType = true; } else enum isExprType = false; } // This template checks that T is a valid node type. That is, // the previous template uses this one to enforce T.NodeType // being a type that satisfies certain properties. template isNodeType(T) { static if (is(T.precedence : int)) enum isNodeType = true; else enum isNodeType = false; } // By using the above template as a signature constraint, we're // free to make use of properties we assumed about T, such as // parametrizing the return type on .NodeType as defined in T T.NodeType parseExpr(T)(Lexer lex) if (isExprType!T) { ... // Or calling functions we verified to exist in T auto node1 = T.parseAtom(lex); auto node2 = T.parseAtom(lex); ... // Or using properties of T.NodeType that we verified // exists, even though the template itself is // independent of how T.NodeType is even defined by T! if (node1.precedence < node2.precedence) ... } This is a ducktyping system where any type that satisfies isExprType will work with parseExpr. This isn't just C++'s "conform to conventions described in the missing accompanying documentation or get 10 pages of template errors". This is *compile-time* verification that any type T you instantiate parseExpr with, conforms to the requirements defined by isExprType. And furthermore, even T.NodeType itself has been checked to have certain properties -- such as a .precedence property that is convertible to int (which means it can be an actual int field, or a property function that returns an int, or something that returns an object convertible to int, etc.). This allows you to implement an expression parser that is completely independent of the concrete types of the expression being parsed. AND this is done without requiring 100 template parameters that specify every configurable parameter: you just specify them in the type used to instantiate parseExpr. Better yet, if you designed the isExprType template correctly, you can even have a derived class of an expression node that stores a value, and specifies parsing functions that computes the value on the expression on-the-fly. So instantiating parseExpr with the base class gives you an expression tree, and instantiating it with the derived class computes the value of the expression at parse-time. In the latter case, even the return type is the correct derived class so you don't even need to down-cast a base class reference to get at the value. (I actually have code that does this. You cannot imagine the sense of power when code like this can be written _cleanly_, without bending over backwards and running a 100-meter dash with your left leg tied to your neck.) Now try doing this in C++. It is in all likelihood plain impossible, or so extremely painful that it's not worth the suffering to implement. T -- Lottery: tax on the stupid. -- Slashdotter
Oct 15 2012
prev sibling next sibling parent "Ethan" <gooberman gmail.com> writes:
On Monday, 15 October 2012 at 16:46:38 UTC, F i L wrote:
 ps. I'm surprised I don't see a bunch of 'final ...' throughout 
 your code. I thought a big issue of yours in the past was D's 
 auto-virtual functions. Has something been changed in that area 
 that I missed, or have you just not gotten around to doing it 
 (or you don't need it for this project)?

Well, the main reason for that is because I wrote a large chunk of the code. I didn't come across any area where final was needed because I kept the code heirarchy very shallow and relied on inheriting from multiple interfaces. So. I'm a D newbie. I've looked at this site before, but the only time I looked in to the language in any depth was last Thursday night when I read the introductory chapter of Andrei's D book. Turns out that the first chapter, combined with C++ and C# knowledge and sitting in earshot of Manu for when I had questions about how D works, was all I needed to write game logic from scratch. Straight up, I'm fairly impressed with the language. I've been moaning for years that there aren't any system level/performance oriented languages coming out with all of the nice things found in programming languages created in the 30-odd years since C++ was unleashed upon the world. The code I wrote was definitely more inspired by C# than C++, but I didn't really want to go in to the jam trying to write C# code in another language. I tried to do things in a more D like way. I think I succeeded in some areas - such as the one line creation table where we used to use an entire 1000+ line file back in the PS2 days - but towards the end I definitely started falling back in to more C++ style coding just to get stuff in the game and working. I'll definitely be looking more in-depth in to D, but I have already come across a few things that make me think it's about 99% ready for production code instead of the full 100%. I'll go in to more detail in another thread, but I did find it odd that D is a language that aims to make life easier for the programmer yet makes you jump through hoops at times. I'll be pretty happy to leave C++ behind when D2 is rock solid.
Oct 15 2012
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Monday, 15 October 2012 at 17:19:43 UTC, so wrote:
 On Monday, 15 October 2012 at 16:37:08 UTC, Peter Alexander 
 wrote:
 ...
 - Simple(r) templates

I keep seeing things like this and probably i am failing to understand it. This is a vast understatement for D templates. Yes, easier to use, i agree. But C++ templates are stone age comparing to D and i don't see this mentioned enough where it matters most. <snip>

I'm going to start a bit of a rant now. D templates are certainly powerful, and are inarguably an improvement over C++ templates, but they are still based on C++ templates, and inherit a lot of their fundamental problems. The main problem is the whole duck typing thing. Duck typing is the cause of all the horrible error messages in C++ templates, and D carried it over. Consider this: auto s = chain("a,b,c,", "d,e,f").splitter(","); Seems like a reasonable thing to do, but you get an error: std/algorithm.d(2020): Error: undefined identifier 'length' ... similar errors from inside std.algorithm ... What am I supposed to make of that? D attempts to mitigate this by adding template constraints, but this just makes the error messages shorter, not more useful. Here's another example, this time trying to instantiate a constrained template: bool b = filter!(not!isPunctuation)("Hello, world!").endsWith("world"); Again, seems reasonable. I want to remove all the punctuation from a string and then test if it ends with the word "world". Again, I get an error: Error: template std.algorithm.endsWith does not match any function template declaration std/algorithm.d(4375): Error: template std.algorithm.endsWith cannot deduce template function from argument types !()(FilterResult!(not,string),string) This error message is no more useful than saying "you can't do that". Why doesn't any function match? Why can't it deduce the template parameters? I don't believe there's any easy way to solve these problems with the current template design. You really need something like concepts or typeclasses to get quality errors. These aren't things that are easily tacked on. So yeah, D's templates are better than C++'s, but they're still templates.
Oct 15 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--f46d043890b9c40ea204cc1e3580
Content-Type: text/plain; charset=UTF-8

On 15 October 2012 19:46, F i L <witte2008 gmail.com> wrote:

 On Monday, 15 October 2012 at 11:52:49 UTC, Manu wrote:

 We did a 48hr game jam at work this past weekend.
 We decided to do our entry in D, to further prove that D was a viable and
 productive solution for real-world game dev.

 Here's our entry, for those interested.
 It has only been built/tested in Windows using VS2010, but it should
 theoretically work on Linux and consoles as well (but the build scripts
 aren't setup to do it automatically).
 If there is interest, I will create the build scripts, and test on Linux.

 https://github.com/**RemedyGameJam/stache/wiki<https://github.com/RemedyGameJam/stache/wiki>

Nice! I might not get a chance to download the game in the next few days, but I glanced at the source and everything looks cool. Any screenshots? About that Linux build script, if you manage to make it, let me know :) ps. I'm surprised I don't see a bunch of 'final ...' throughout your code. I thought a big issue of yours in the past was D's auto-virtual functions. Has something been changed in that area that I missed, or have you just not gotten around to doing it (or you don't need it for this project)?

This game doesn't exactly raise the bar in terms of computational requirements ;) Also, it's quite a lot of game to write in 48 hours, we didn't have time to worry about things like that. And also, to some extent, we wanted to do it in a pure D way (ie, a way I wouldn't usually write code), mainly as an exercise, to test the productivity potential of D without worrying about all the stuff I normally waste time with. --f46d043890b9c40ea204cc1e3580 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 15 October 2012 19:46, F i L <span dir=3D"ltr">&lt;<a href=3D"mailto:wit= te2008 gmail.com" target=3D"_blank">witte2008 gmail.com</a>&gt;</span> wrot= e:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D= "margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On Monday, 15 October 2012 at 11:52:49 UTC, Manu wrote:<b= r> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"> We did a 48hr game jam at work this past weekend.<br> We decided to do our entry in D, to further prove that D was a viable and<b= r> productive solution for real-world game dev.<br> <br></div><div class=3D"im"> Here&#39;s our entry, for those interested.<br> It has only been built/tested in Windows using VS2010, but it should<br> theoretically work on Linux and consoles as well (but the build scripts<br> aren&#39;t setup to do it automatically).<br> If there is interest, I will create the build scripts, and test on Linux.<b= r> <br> <a href=3D"https://github.com/RemedyGameJam/stache/wiki" target=3D"_blank">= https://github.com/<u></u>RemedyGameJam/stache/wiki</a><br> </div></blockquote> <br> Nice! I might not get a chance to download the game in the next few days, b= ut I glanced at the source and everything looks cool. Any screenshots? Abou= t that Linux build script, if you manage to make it, let me know :)<br> <br> ps. I&#39;m surprised I don&#39;t see a bunch of &#39;final ...&#39; throug= hout your code. I thought a big issue of yours in the past was D&#39;s auto= -virtual functions. Has something been changed in that area that I missed, = or have you just not gotten around to doing it (or you don&#39;t need it fo= r this project)?<br> </blockquote></div><br><div>This game doesn&#39;t exactly raise the bar in = terms of computational requirements ;)</div><div>Also, it&#39;s quite a lot= of game to write in 48 hours, we didn&#39;t have time to worry about thing= s like that. And also, to some extent, we wanted to do it in a pure D way (= ie, a way I wouldn&#39;t usually write code), mainly as an exercise, to tes= t the productivity potential of D without worrying about all the stuff I no= rmally waste time with.</div> --f46d043890b9c40ea204cc1e3580--
Oct 15 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Oct 15, 2012 at 09:18:33PM +0200, Peter Alexander wrote:
[...]
 I'm going to start a bit of a rant now.
 
 D templates are certainly powerful, and are inarguably an
 improvement over C++ templates, but they are still based on C++
 templates, and inherit a lot of their fundamental problems.
 
 The main problem is the whole duck typing thing. Duck typing is the
 cause of all the horrible error messages in C++ templates, and D
 carried it over.
 
 Consider this:
 
 auto s = chain("a,b,c,", "d,e,f").splitter(",");
 
 Seems like a reasonable thing to do, but you get an error:
 
 std/algorithm.d(2020): Error: undefined identifier 'length'
 ... similar errors from inside std.algorithm ...

This looks like a bug. There should be signature constraints to test for the existence of .length before attempting to use it.
 What am I supposed to make of that?
 
 D attempts to mitigate this by adding template constraints, but this
 just makes the error messages shorter, not more useful. Here's
 another example, this time trying to instantiate a constrained
 template:
 
 bool b = filter!(not!isPunctuation)("Hello,
 world!").endsWith("world");
 
 Again, seems reasonable. I want to remove all the punctuation from a
 string and then test if it ends with the word "world". Again, I get
 an error:
 
 Error: template std.algorithm.endsWith does not match any function
 template declaration
 std/algorithm.d(4375): Error: template std.algorithm.endsWith cannot
 deduce template function from argument types
 !()(FilterResult!(not,string),string)

I agree that this error message is stupid. I've found myself having to insert pragma(msg,...)'s into my code just to see what exactly were the types that failed to match the template constraints. But to me, this is more of an implementational issue with the current dmd than a weakness of the language itself. If the templates were well-designed in the first place, the signature constraints ought to look something like: auto endsWith(R,S)(R range, S endswiththis) if (isInputRange!R && isForwardRange!S && ...) Now, if the compiler would just say something along the lines of: template std.algorithm.endsWith does not match arguments: FilterResult!(blahblah) fails constraints: isForwardRange, isInputRange, (or whatever) That would be much better. The constraint names themselves will already have told you what was wrong (assuming their names were well-chosen in the first place -- which I submit is a reasonable expectation, given that Phobos is the *standard* library).
 This error message is no more useful than saying "you can't do
 that". Why doesn't any function match? Why can't it deduce the
 template parameters?
 
 I don't believe there's any easy way to solve these problems with
 the current template design. You really need something like concepts
 or typeclasses to get quality errors. These aren't things that are
 easily tacked on.

To me, the current template design already models concepts/typeclasses. Things like isInputRange, isForwardRange, etc., are self-documenting, and they describe concepts and type classes -- if the compiler would only _use_ them in the error message instead of the current encrypted Klingon. I chalk it up to a dmd enhancement request. T -- Arise, you prisoners of Windows / Arise, you slaves of Redmond, Wash, / The day and hour soon are coming / When all the IT folks say "Gosh!" / It isn't from a clever lawsuit / That Windowsland will finally fall, / But thousands writing open source code / Like mice who nibble through a wall. -- The Linux-nationale by Greg Baker
Oct 15 2012
prev sibling next sibling parent "so" <so so.so> writes:
On Monday, 15 October 2012 at 17:58:13 UTC, H. S. Teoh wrote:

 Now try doing this in C++. It is in all likelihood plain 
 impossible, or
 so extremely painful that it's not worth the suffering to 
 implement.


 T

Having read some Lisp recently, i was so lucky it was not my first language. It would have been a very frustrating experience having to adopt other languages, required to write code in them. I don't have experience on it and don't know how it scales with bigger projects but as someone who sees the importance of metaprogramming in D/C++, it is disturbing when you find out it was a 50 years old concept.
Oct 15 2012
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Monday, 15 October 2012 at 19:52:44 UTC, H. S. Teoh wrote:
 On Mon, Oct 15, 2012 at 09:18:33PM +0200, Peter Alexander wrote:
 std/algorithm.d(2020): Error: undefined identifier 'length'
 ... similar errors from inside std.algorithm ...

This looks like a bug. There should be signature constraints to test for the existence of .length before attempting to use it.

It is, I've already created a pull request for it. Problem is, there's many more where that came from. And even if you fix everything in the standard library, you then have to worry about all the 3rd party libraries out there with inadequate constraints.
 Now, if the compiler would just say something along the lines 
 of:

 	template std.algorithm.endsWith does not match arguments:
 	FilterResult!(blahblah) fails constraints: isForwardRange,
 	isInputRange, (or whatever)

 That would be much better. The constraint names themselves will 
 already
 have told you what was wrong (assuming their names were 
 well-chosen in
 the first place -- which I submit is a reasonable expectation, 
 given
 that Phobos is the *standard* library).

It's not that simple. First, there are often multiple overloads, so you not only have to show why one overload failed, you have to show why all of them failed. Second, not all constraints are simply (isX && isY && isZ). They often contain things like complex is-expression and allSatisfy etc. Third, telling me that FilterResult failed a constraint isn't particularly enlightening either. Why isn't FilterResult a forward range (or whatever)? I didn't write it. I have to now go and look at the source of both isForwardRange and FilterResult to figure out where the mismatch is (compare this to, for example, just checking that a class implements an interface).
 To me, the current template design already models 
 concepts/typeclasses.
 Things like isInputRange, isForwardRange, etc., are 
 self-documenting,
 and they describe concepts and type classes -- if the compiler 
 would
 only _use_ them in the error message instead of the current 
 encrypted
 Klingon. I chalk it up to a dmd enhancement request.

This is a "sufficiently smart compiler" argument. Template constraints have been around for a long time, and the situation hasn't improved. To me, that's a hint that providing good error messages is a difficult task (like implementing export in C++). A simpler language design would enable a quicker and more robust implementation.
Oct 15 2012
prev sibling next sibling parent "so" <so so.so> writes:
On Monday, 15 October 2012 at 19:18:34 UTC, Peter Alexander wrote:

 I'm going to start a bit of a rant now.
 ...

On this one, i agree everything you say. D templates inherit quite a bit of errors. I have problem with the attitude of some people (not necessarily you). As they say D templates are just better because of things like syntax, other than that you could pretty much do everything you can do with C++ templates (you simply can't). And they just get away with this. For me it just shows how little they know about C++ or D.
Oct 15 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 15 October 2012 at 20:33:36 UTC, so wrote:
 On Monday, 15 October 2012 at 19:18:34 UTC, Peter Alexander 
 wrote:

 I'm going to start a bit of a rant now.
 ...

On this one, i agree everything you say. D templates inherit quite a bit of errors. I have problem with the attitude of some people (not necessarily you). As they say D templates are just better because of things like syntax, other than that you could pretty much do everything you can do with C++ templates (you simply can't). And they just get away with this. For me it just shows how little they know about C++ or D.

Many people use C++ as better C. I was amazed to hear that are companies that forbid templates or STL code on the videos from Going Native conference organized by Microsoft. -- Paulo
Oct 15 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 15 October 2012 at 20:20:28 UTC, so wrote:
 On Monday, 15 October 2012 at 17:58:13 UTC, H. S. Teoh wrote:

 Now try doing this in C++. It is in all likelihood plain 
 impossible, or
 so extremely painful that it's not worth the suffering to 
 implement.


 T

Having read some Lisp recently, i was so lucky it was not my first language. It would have been a very frustrating experience having to adopt other languages, required to write code in them. I don't have experience on it and don't know how it scales with bigger projects but as someone who sees the importance of metaprogramming in D/C++, it is disturbing when you find out it was a 50 years old concept.

Now imagine those that have experimented how powerful Lisp and Smalltalk based OS were. It is so sad to see IDE makers still trying to replicate the experience from those environments. -- Paulo
Oct 15 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Oct 15, 2012 at 10:40:12PM +0200, Paulo Pinto wrote:
 On Monday, 15 October 2012 at 20:33:36 UTC, so wrote:

I have problem with the attitude of some people (not necessarily
you). As they say D templates are just better because of things
like syntax, other than that you could pretty much do everything
you can do with C++ templates (you simply can't). And they just
get away with this. For me it just shows how little they know
about C++ or D.

Many people use C++ as better C.

I did, even while knowing C++ has OO constructs like classes, polymorphism, etc.. The fact of the matter is, OO programming in C++ is a pain, because C++'s OO wasn't very well designed. It did get the basics right, mind you, but not much beyond that. There are just so many loopholes and flaws that trying to do _real_ OO design in C++ is an exercise in frustration. I've found that using C++ as "C with classes" is a much less painful experience than trying to do "real" OO in C++. For that, I'd recommend Java instead (even though I'm by no means a Java fan). (I do use polymorphism, etc., in C++ code, but only barely, in limited situations. I don't even dare to go near multiple inheritance with a sterilized 15-foot pole. Java had the right idea with interfaces, something that I'm glad D picked up.)
 I was amazed to hear that are companies that forbid templates or STL
 code on the videos from Going Native conference organized by
 Microsoft.

I can totally understand why, even though I don't agree with the reasons. I've seen C++ gone wrong, horribly horribly wrong, as a result of over-engineering a system that became unmaintainably complex (and should I say, unnecessarily so -- it was a case of premature generalization taken to the extremes). Templates, and by extension STL, are perceived by many as one of those "unnecessarily complicated" features of C++, which lets careless programmers write hopelessly complex and unmaintainable code, so I can totally see PTBs prohibiting it. I mean, even C++ code written to *be* maintainable often *looks* unmaintainable due to the horrible template syntax, among other things. It's the kind of stuff that drives PTBs to ban C++ outright. (I don't agree with the assessment of templates, of course, but I can understand the sentiment.) If you think forbidding templates/STL is crazy, wait till you hear about the people who insist that const is evil and ban it from their codebase. (That was from before C++11, though, I don't know what their reaction would be now that key parts of the language _require_ const. Maybe they've migrated to VB or something. :-P) T -- BREAKFAST.COM halted...Cereal Port Not Responding. -- YHL
Oct 15 2012
prev sibling next sibling parent "so" <so so.so> writes:
On Monday, 15 October 2012 at 21:29:11 UTC, H. S. Teoh wrote:

 If you think forbidding templates/STL is crazy, wait till you 
 hear about
 the people who insist that const is evil and ban it from their 
 codebase.
 (That was from before C++11, though, I don't know what their 
 reaction
 would be now that key parts of the language _require_ const. 
 Maybe
 they've migrated to VB or something. :-P)


 T

I can somewhat understand not using STL as the library assumes you are using certain paradigms, but they sometimes doesn't do the job. It is similar to phobos being designed GC in mind. But if you are not even using templates, why bother? For OOP? I would never move to C++ for OOP, since you are also losing something quite important in the process, interoperability with other languages. Most (maybe all) languages (i know) have some kind of interface to C. With C++ you lose that one too.
Oct 15 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Oct 15, 2012 at 11:52:19PM +0200, so wrote:
 On Monday, 15 October 2012 at 21:29:11 UTC, H. S. Teoh wrote:
 
If you think forbidding templates/STL is crazy, wait till you hear
about the people who insist that const is evil and ban it from their
codebase.  (That was from before C++11, though, I don't know what
their reaction would be now that key parts of the language _require_
const. Maybe they've migrated to VB or something. :-P)


T

I can somewhat understand not using STL as the library assumes you are using certain paradigms, but they sometimes doesn't do the job. It is similar to phobos being designed GC in mind. But if you are not even using templates, why bother? For OOP? I would never move to C++ for OOP, since you are also losing something quite important in the process, interoperability with other languages. Most (maybe all) languages (i know) have some kind of interface to C. With C++ you lose that one too.

I dunno, maybe they like struct names being specifiable without the struct keyword (I always find that awkward when switching back to C after dealing with C++ code). :-P It *is* a pretty crazy idea to prohibit STL, seeing as STL is what makes writing container-related C++ code bearable. I have horrible memories of the Bad Old Days when I must've reinvented linked lists at least 20 times, just because STL didn't exist in those days. When templates first came out, I was elated that finally I didn't have to implement Yet Another Linked List. Perhaps it took that kind of experience to appreciate templates. :-) People who didn't have to suffer through these kinds of limitations often don't appreciate what templates offer. (And that's C++ templates, with all their warts, not even speaking about D templates -- which are on a whole 'nother level.) T -- One reason that few people are aware there are programs running the internet is that they never crash in any significant way: the free software underlying the internet is reliable to the point of invisibility. -- Glyn Moody, from the article "Giving it all away"
Oct 15 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 15 October 2012 at 22:14:48 UTC, H. S. Teoh wrote:
 On Mon, Oct 15, 2012 at 11:52:19PM +0200, so wrote:
 On Monday, 15 October 2012 at 21:29:11 UTC, H. S. Teoh wrote:
 
If you think forbidding templates/STL is crazy, wait till you 
hear
about the people who insist that const is evil and ban it 
from their
codebase.  (That was from before C++11, though, I don't know 
what
their reaction would be now that key parts of the language 
_require_
const. Maybe they've migrated to VB or something. :-P)


T

I can somewhat understand not using STL as the library assumes you are using certain paradigms, but they sometimes doesn't do the job. It is similar to phobos being designed GC in mind. But if you are not even using templates, why bother? For OOP? I would never move to C++ for OOP, since you are also losing something quite important in the process, interoperability with other languages. Most (maybe all) languages (i know) have some kind of interface to C. With C++ you lose that one too.

I dunno, maybe they like struct names being specifiable without the struct keyword (I always find that awkward when switching back to C after dealing with C++ code). :-P It *is* a pretty crazy idea to prohibit STL, seeing as STL is what makes writing container-related C++ code bearable. I have horrible memories of the Bad Old Days when I must've reinvented linked lists at least 20 times, just because STL didn't exist in those days. When templates first came out, I was elated that finally I didn't have to implement Yet Another Linked List. Perhaps it took that kind of experience to appreciate templates. :-) People who didn't have to suffer through these kinds of limitations often don't appreciate what templates offer. (And that's C++ templates, with all their warts, not even speaking about D templates -- which are on a whole 'nother level.) T

You should talk with the Go guys which seem to be happy re-inventing the type of tools we used in C++, back in the days templates were still not available, somewhere around 1993 in my case. Does anyone remember the pre-processor hacks from Borland C++? -- Paulo
Oct 15 2012
prev sibling next sibling parent "so" <so so.so> writes:
On Monday, 15 October 2012 at 20:41:55 UTC, Paulo Pinto wrote:

 Now imagine those that have experimented how powerful Lisp and 
 Smalltalk based OS were.

 It is so sad to see IDE makers still trying to replicate the 
 experience from those environments.

 --
 Paulo

Thanks for mentioning that, checked "lisp os" and next thing was "www.loper-os.org/?p=69". It might be offensive to some people but reading his posts/rants now, i kind of like what he says. This is what i was talking about when i say that i feel lucky because Lisp was not my first language. Looks like he experienced the language devolutions and very (rightly so) frustrated. An example: "You will not find a “Thumbs Down for Python” essay in this blog, because Python users make no attempt to peddle their crock of shit as “the future of Lisp.” I have no quarrel with users of Python, Ruby, Dylan, and other shoddy “infix Lisps.” Because they are honest. It is the lying of Clojure users which upsets me, and their deliberate attempts to rewrite history, to make people forget that truly-interactive, advanced Lisp systems once existed"
Oct 15 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 16 October 2012 at 02:45:42 UTC, so wrote:
 On Monday, 15 October 2012 at 20:41:55 UTC, Paulo Pinto wrote:

 Now imagine those that have experimented how powerful Lisp and 
 Smalltalk based OS were.

 It is so sad to see IDE makers still trying to replicate the 
 experience from those environments.

 --
 Paulo

Thanks for mentioning that, checked "lisp os" and next thing was "www.loper-os.org/?p=69". It might be offensive to some people but reading his posts/rants now, i kind of like what he says. This is what i was talking about when i say that i feel lucky because Lisp was not my first language. Looks like he experienced the language devolutions and very (rightly so) frustrated. An example: "You will not find a “Thumbs Down for Python” essay in this blog, because Python users make no attempt to peddle their crock of shit as “the future of Lisp.” I have no quarrel with users of Python, Ruby, Dylan, and other shoddy “infix Lisps.” Because they are honest. It is the lying of Clojure users which upsets me, and their deliberate attempts to rewrite history, to make people forget that truly-interactive, advanced Lisp systems once existed"

I know that site, you should have a look at http://www.loper-os.org/?p=932 presentation. Now imagine that computer system was developed in the late 70's and how things would look like today if it wasn't for the AI Winter. Same thing with Smalltalk environments, which are the only ones I know with the same capabilities. Everything that is trendy nowadays, unit testing, code refactoring, live editing, JIT and AOT compilation, full GC based environments, was already available in Lisp and Smalltalk machines. Or for that matter look at Native Oberon, a fully working desktop operating system implemented in a GC enabled systems programming language. Sad that mainstream always takes generations to accept something. -- Paulo
Oct 15 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-10-15 13:52, Manu wrote:
 We did a 48hr game jam at work this past weekend.
 We decided to do our entry in D, to further prove that D was a viable
 and productive solution for real-world game dev.

 Here's our entry, for those interested.
 It has only been built/tested in Windows using VS2010, but it should
 theoretically work on Linux and consoles as well (but the build scripts
 aren't setup to do it automatically).
 If there is interest, I will create the build scripts, and test on Linux.

 https://github.com/RemedyGameJam/stache/wiki

When using git submodules the recommended way of cloning is to use "git clone --recursive". -- /Jacob Carlborg
Oct 16 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf307f3a9eca4cd904cc2ba424
Content-Type: text/plain; charset=UTF-8

On 16 October 2012 12:50, Jacob Carlborg <doob me.com> wrote:

 On 2012-10-15 13:52, Manu wrote:

 We did a 48hr game jam at work this past weekend.
 We decided to do our entry in D, to further prove that D was a viable
 and productive solution for real-world game dev.

 Here's our entry, for those interested.
 It has only been built/tested in Windows using VS2010, but it should
 theoretically work on Linux and consoles as well (but the build scripts
 aren't setup to do it automatically).
 If there is interest, I will create the build scripts, and test on Linux.

 https://github.com/**RemedyGameJam/stache/wiki<https://github.com/RemedyGameJam/stache/wiki>

When using git submodules the recommended way of cloning is to use "git clone --recursive".

Ah, well. Allegedly I'm still rather a git noob. I'll update that, although the following steps still stand. I didn't have any luck making the subrepos default to a particular branch. (It worked once, but I couldn't see why, and then it stopped working) --20cf307f3a9eca4cd904cc2ba424 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 16 October 2012 12:50, Jacob Carlborg <span dir=3D"ltr">&lt;<a href=3D"m= ailto:doob me.com" target=3D"_blank">doob me.com</a>&gt;</span> wrote:<br><= div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin= :0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On 2012-10-15 13:52, Manu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> We did a 48hr game jam at work this past weekend.<br> We decided to do our entry in D, to further prove that D was a viable<br> and productive solution for real-world game dev.<br> <br> Here&#39;s our entry, for those interested.<br> It has only been built/tested in Windows using VS2010, but it should<br> theoretically work on Linux and consoles as well (but the build scripts<br> aren&#39;t setup to do it automatically).<br> If there is interest, I will create the build scripts, and test on Linux.<b= r> <br> <a href=3D"https://github.com/RemedyGameJam/stache/wiki" target=3D"_blank">= https://github.com/<u></u>RemedyGameJam/stache/wiki</a><br> </blockquote> <br></div> When using git submodules the recommended way of cloning is to use &quot;gi= t clone --recursive&quot;.</blockquote><div><br></div><div>Ah, well. Allege= dly I&#39;m still rather a git noob. I&#39;ll update that, although the fol= lowing steps still stand.</div> <div>I didn&#39;t have any luck making the subrepos default to a particular= branch. (It worked once, but I couldn&#39;t see why, and then it stopped w= orking)</div></div> --20cf307f3a9eca4cd904cc2ba424--
Oct 16 2012
prev sibling next sibling parent "ponce" <spam spam.org> writes:
On Monday, 15 October 2012 at 11:52:49 UTC, Manu wrote:
 We did a 48hr game jam at work this past weekend.

Now that's a hilarious game :) good job.
Oct 16 2012
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Ethan:

 but I have
 already come across a few things that make me think it's about
 99% ready for production code instead of the full 100%.

D has some rough edges still, and I think most of such rough edges are now known to D designers and the D community. Some of those edges will be fixed (some of them even have an already written patch in GitHub!), while some of them probably will not be fixed or will not be fixed soon, sometimes because there is no good way to fix them among the ecology of the other D features, or because D designers don't want to fix them (like some segfaults caused by nulls).
 I'll go in to more detail in another thread,

Good. Reports from practical usage are usually interesting.
 but I did find it odd that D is a language that aims to make 
 life easier for the programmer
 yet makes you jump through hoops at times.

D design comes from people that have a long experience of C and C++ (and some experience of Java and a bit of experience of Python, and Perl). This means in D you find many details wisely designed. But another consequence is that several parts are also designed in a old style. Some parts of D design are surely far away from some new trends in language design. A lot of experience about older ways is both a blessing and a curse :-) Bye, bearophile
Oct 16 2012
prev sibling parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
On Mon, Oct 15, 2012 at 8:00 PM, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:

 Better yet, if you designed the isExprType template correctly, you can
 even have a derived class of an expression node that stores a value, and
 specifies parsing functions that computes the value on the expression
 on-the-fly. So instantiating parseExpr with the base class gives you an
 expression tree, and instantiating it with the derived class computes
 the value of the expression at parse-time. In the latter case, even the
 return type is the correct derived class so you don't even need to
 down-cast a base class reference to get at the value. (I actually have
 code that does this. You cannot imagine the sense of power when code
 like this can be written _cleanly_, without bending over backwards and
 running a 100-meter dash with your left leg tied to your neck.)

Is this code available somewhere?
Oct 16 2012