www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - 48 hour game jam

reply Manu <turkeyman gmail.com> writes:
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
Oct 15 2012
next sibling parent reply "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
parent reply Manu <turkeyman gmail.com> writes:
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 ;)

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.
Oct 15 2012
parent reply "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
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:


- 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 parent reply "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
next sibling parent reply "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
parent reply "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
parent reply "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
parent reply "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
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 reply "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
next sibling parent reply "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
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 parent reply "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
parent reply "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
parent reply "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
parent reply "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
parent reply "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
parent reply "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
next sibling parent reply "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
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 parent Manu <turkeyman gmail.com> writes:
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! ;)
Oct 15 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
prev sibling next sibling parent reply "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
next sibling parent reply "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.

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.



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
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 Manu <turkeyman gmail.com> writes:
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.
Oct 15 2012
prev sibling next sibling parent reply 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
parent Manu <turkeyman gmail.com> writes:
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)
Oct 16 2012
prev 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