www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is D Language mature for MMORPG Client ?

reply "Robert" <misugi-pwnu live.fr> writes:
Hi all,



I am currently developing a MMORPG, client part is in c++ and

side ?

Its a simple 2d isometric game using opengl 3.X (with shaders) so
its not really a problem if i lose some fps.

Thanks and sorry for my bad english(im french).
Aug 02 2012
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Robert:




 I am currently developing a MMORPG, client part is in c++ and

 client side ?

 Its a simple 2d isometric game using opengl 3.X (with shaders) 
 so
 its not really a problem if i lose some fps.

 Thanks and sorry for my bad english(im french).


I think D today is enough to create a small game like that.
But D and its standard library are in development still, so 
probably you will need to fix small things every D release, for 
some years. Are you able and willing to do this?

Bye,
bearophile
Aug 02 2012
next sibling parent reply "Kapps" <opantm2+spam gmail.com> writes:
On Friday, 3 August 2012 at 02:16:22 UTC, bearophile wrote:

 I think D today is enough to create a small game like that.
 But D and its standard library are in development still, so 
 probably you will need to fix small things every D release, for 
 some years. Are you able and willing to do this?

 Bye,
 bearophile


Every release is slightly exaggerating it. I can think of a few 
major breaking changes, but breaking changes are less frequent 
now IMO. As they should be. Pretty much no D code from a year ago 
will compile today. Definitely a discouraging thing, especially 
if you just try to use someone else's library.
Aug 02 2012
parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Friday, 3 August 2012 at 03:13:06 UTC, Kapps wrote:

 On Friday, 3 August 2012 at 02:16:22 UTC, bearophile wrote:

 I think D today is enough to create a small game like that.
 But D and its standard library are in development still, so 
 probably you will need to fix small things every D release, 
 for some years. Are you able and willing to do this?

 Bye,
 bearophile


 Every release is slightly exaggerating it. I can think of a few 
 major breaking changes, but breaking changes are less frequent 
 now IMO. As they should be. Pretty much no D code from a year 
 ago will compile today. Definitely a discouraging thing, 
 especially if you just try to use someone else's library.


Every change is a potentially breaking change, even if all the 
change does is fix a bug (your code could rely on the bug). This 
happens to me quite a lot with subtle things. Forever, 2.060 
revealed that I had overloaded the same function twice with the 
same arguments and same template constraints. Up till 2.060 it 
wasn't flagged as an error and worked fine. Yeah, it's my fault 
entirely, but it's something I had to fix.

I can't remember upgrading my DMD without having to change 
*something*, and my project is only about 10kloc, so it's not 
big, and I don't think bearophile is exaggerating at all.


To answer the original question: yes, D is more than capable of 
writing games for the major desktop platforms right now, even if 
things are a little unstable at the moment.

One thing I will say to you though is that you'll have to avoid 
allocations during runtime if you want smooth gameplay as the GC 
is quite slow, but you should be doing that in any language.
Aug 03 2012
prev sibling parent reply "SomeDude" <lovelydear mailmetrash.com> writes:
On Friday, 3 August 2012 at 02:16:22 UTC, bearophile wrote:

 Robert:




 I am currently developing a MMORPG, client part is in c++ and

 client side ?

 Its a simple 2d isometric game using opengl 3.X (with shaders) 
 so
 its not really a problem if i lose some fps.

 Thanks and sorry for my bad english(im french).


 I think D today is enough to create a small game like that.
 But D and its standard library are in development still, so 
 probably you will need to fix small things every D release, for 
 some years. Are you able and willing to do this?

 Bye,
 bearophile


Well, normally, with the new STABLE branch, this is going to be a 
thing of the past
Aug 04 2012
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, August 04, 2012 09:13:48 SomeDude wrote:

 Well, normally, with the new STABLE branch, this is going to be a
 thing of the past


LOL. No offense, but it's really not going to fix the problem. It'll mitigate
it 
somewhat, but it won't fix it. Bug fixes break code all the time (generally 
because the code shouldn't have worked in the first place, but regardless, 
fixing bugs often causes code to stop compiling). And regardless of whether the 
average release in dlang-stable breaks anything, as soon as they merge in the 
next official release of dmd, you're in exactly the same situation you're in 
now. And it's not like official releases will be occuring less often now. It 
just means that you'll be able to get partial releases at a higher frequency 
with dlang-stable while you wait for the next official release.

For things to stop breaking with each release, their needs to be few enough 
major bugs that breaking changes caused by bug fixes are relatively rare, and 
Phobos is going to need to stabilize enough that deprecations are quite rare. 
We're approaching both of those points, but we're definitely not there yet, and 
dlang-stable won't magically get us there.

- Jonathan M Davis
Aug 04 2012
prev sibling next sibling parent Mike Parker <aldacron gmail.com> writes:
On 8/3/2012 9:22 AM, Robert wrote:

 Hi all,



 I am currently developing a MMORPG, client part is in c++ and

 side ?

 Its a simple 2d isometric game using opengl 3.X (with shaders) so
 its not really a problem if i lose some fps.

 Thanks and sorry for my bad english(im french).


Yes, it is if you are only targeting the big 3 platforms (Win, Linux, 
Mac). If you need mobile, we aren't quite there yet. There are several 
OpenGL-based D game projects on github right now.
Aug 02 2012
prev sibling next sibling parent reply "Tobias Pankrath" <tobias pankrath.net> writes:
On Friday, 3 August 2012 at 00:22:51 UTC, Robert wrote:

 Hi all,



 I am currently developing a MMORPG, client part is in c++ and

 client
 side ?

 Its a simple 2d isometric game using opengl 3.X (with shaders) 
 so
 its not really a problem if i lose some fps.

 Thanks and sorry for my bad english(im french).


I would recommend D only for small hobby projects. Everything 
else is out of scope. I'm constantly running in problems both 
with DMD and with phobos, especially with it's containers and 
algorithms. If you need something done, you are wrong here. At 
least for now.
Aug 03 2012
next sibling parent shd <alienballance gmail.com> writes:
2012/8/3 Tobias Pankrath <tobias pankrath.net>:

 On Friday, 3 August 2012 at 00:22:51 UTC, Robert wrote:

 Hi all,



 I am currently developing a MMORPG, client part is in c++ and

 side ?




I'll partially repeat what others said.

You might want to stay with one library/compiler version. Every year
or so, while updating it to newer one, you'd have to do fixes + major
tests again.
You have to be aware about not doing many allocations/dealocations,
but that was easy at least for me.
You might consider not using more complicated language constructs,
most bugs are here.
You have  to be prepared for spotting and actually knowing some
compiler bugs (additionally to possible yours).

Besides of the downsides it will be really enjoyable to write your
project in D and your productivity will gain.
Aug 03 2012
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-08-03 09:24, Tobias Pankrath wrote:


 I would recommend D only for small hobby projects. Everything else is
 out of scope. I'm constantly running in problems both with DMD and with
 phobos, especially with it's containers and algorithms. If you need
 something done, you are wrong here. At least for now.


There's always the option to stay at a given release. Another option 
would be to use D1 and Tango if one wants stability. Not much is 
changing there.

-- 
/Jacob Carlborg
Aug 03 2012
next sibling parent "Tobias Pankrath" <tobias pankrath.net> writes:
On Friday, 3 August 2012 at 09:05:11 UTC, Jacob Carlborg wrote:

 On 2012-08-03 09:24, Tobias Pankrath wrote:


 I would recommend D only for small hobby projects. Everything 
 else is
 out of scope. I'm constantly running in problems both with DMD 
 and with
 phobos, especially with it's containers and algorithms. If you 
 need
 something done, you are wrong here. At least for now.


 There's always the option to stay at a given release. Another 
 option would be to use D1 and Tango if one wants stability. Not 
 much is changing there.


I don't mind, if my code breaks due language improvement. But I 
do mind if the compiler spills out wrong code or dies or doesn't 
work under a specific combination of flags or issues errors about 
some label not defined when I  introduce some invariant in my 
class.

And I'm using git-head because it resolves some of these bugs. 
Naturally you get not only fixes but new ones, too.
Aug 03 2012
prev sibling parent reply Stefan Scholl <stesch no-spoon.de> writes:
Jacob Carlborg <doob me.com> wrote:

 On 2012-08-03 09:24, Tobias Pankrath wrote:
 There's always the option to stay at a given release. Another option 
 would be to use D1 and Tango if one wants stability. Not much is 
 changing there.


From dlang.org: 
    please note: D1 will be discontinued effective December 31, 2012


This doesn't mean that D1 will stop working. It just becomes
"more stable" :-}
Aug 03 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-08-03 13:29, Stefan Scholl wrote:


  From dlang.org:
      please note: D1 will be discontinued effective December 31, 2012


Right, forgot about that.


 This doesn't mean that D1 will stop working. It just becomes
 "more stable" :-}


Exactly :)

-- 
/Jacob Carlborg
Aug 03 2012
prev sibling next sibling parent deadalnix <deadalnix gmail.com> writes:
Le 03/08/2012 02:22, Robert a écrit :

 Hi all,



 I am currently developing a MMORPG, client part is in c++ and

 side ?

 Its a simple 2d isometric game using opengl 3.X (with shaders) so
 its not really a problem if i lose some fps.

 Thanks and sorry for my bad english(im french).


ankama ?
Aug 03 2012
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Robert:




 I am currently developing a MMORPG, client part is in c++ and

 client side ?


I have one more comment. I see D as a possible future alternative 
to Ada to write some moderately reliable programs. D is not 
designed to write programs as reliable as Ada programs (*), but 
once the D compiler and Phobos will be well debugged, I think D 
programs will be more reliable than C/C++ programs.

But so far I have not seen people think and discuss of D as a 
possible future alternative to Ada; most people seem interested 
in D just as a language to write games.


(*) Ada has many features missing in D that make its programs 
significantly safer than D programs, like:
- built-in ranged integers;
- user-defined array indexes;
- clean syntax to stack-allocate matrices of runtime-defined 
sizes;
- pointer kinds with different limitations;
- stack overeflow safeties;
- safe concurrency;
- no undefined semantics;
- explicit type conversions;
- sane modulus on negative numbers;
- integral runtime overflow tests;
- etc etc.

Bye,
bearophile
Aug 03 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/3/12 4:05 PM, bearophile wrote:

 Robert:




 I am currently developing a MMORPG, client part is in c++ and



 I have one more comment. I see D as a possible future alternative to Ada
 to write some moderately reliable programs. D is not designed to write
 programs as reliable as Ada programs (*), but once the D compiler and
 Phobos will be well debugged, I think D programs will be more reliable
 than C/C++ programs.

 But so far I have not seen people think and discuss of D as a possible
 future alternative to Ada; most people seem interested in D just as a
 language to write games.


 (*) Ada has many features missing in D that make its programs
 significantly safer than D programs, like:
 - built-in ranged integers;
 - user-defined array indexes;
 - clean syntax to stack-allocate matrices of runtime-defined sizes;
 - pointer kinds with different limitations;
 - stack overeflow safeties;
 - safe concurrency;
 - no undefined semantics;
 - explicit type conversions;
 - sane modulus on negative numbers;
 - integral runtime overflow tests;
 - etc etc.

 Bye,
 bearophile


What did I just read? Oh boy.

Andrei
Aug 03 2012
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:


 (*) Ada has many features missing in D that make its programs
 significantly safer than D programs, like:
 - built-in ranged integers;
 - user-defined array indexes;
 - clean syntax to stack-allocate matrices of runtime-defined 
 sizes;
 - pointer kinds with different limitations;
 - stack overeflow safeties;
 - safe concurrency;
 - no undefined semantics;
 - explicit type conversions;
 - sane modulus on negative numbers;
 - integral runtime overflow tests;
 - etc etc.

 Bye,
 bearophile


 What did I just read? Oh boy.


Sorry, let me explain better and again. There are programming 
tasks where a lot of reliability is required, but for some 
reasons a widespread virtual machine is not desired. In such 
cases people sometimes use C or C++ (sometimes with some enforced 
restrictions) or Ada (or some of its stricter subsets, as Spark), 
and once in a while Eiffel. D language offers features to 
increase code reliability, but:
- As long as D compilers and Phobos are significantly buggy, it's 
hard to write reliability programs, regardless of the qualities 
of D language. Ada specs and Ada compiler writers know this very 
well;
- As I have listed, Ada offers numerous means to constrain code 
and avoid many bugs statically. From what I am seeing D is less 
bug-prone than C++, but more bug prone than Ada. But so far I 
have not seen people interested in using D in some of the places 
where Ada is used.

Bye,
bearophile
Aug 04 2012
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 8/4/12 8:25 AM, bearophile wrote:

 Andrei Alexandrescu:


 (*) Ada has many features missing in D that make its programs
 significantly safer than D programs, like:
 - built-in ranged integers;
 - user-defined array indexes;
 - clean syntax to stack-allocate matrices of runtime-defined sizes;
 - pointer kinds with different limitations;
 - stack overeflow safeties;
 - safe concurrency;
 - no undefined semantics;
 - explicit type conversions;
 - sane modulus on negative numbers;
 - integral runtime overflow tests;
 - etc etc.

 Bye,
 bearophile


 What did I just read? Oh boy.


 Sorry, let me explain better and again.


I wasn't referring the clarity of explanation, just that I think this 
sort of righteous pontification - cheap to produce, yet implying vast 
insight - doesn't add any value to the exchange.

Andrei
Aug 04 2012
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:


 I wasn't referring the clarity of explanation, just that I 
 think this sort of righteous pontification - cheap to produce, 
 yet implying vast insight - doesn't add any value to the 
 exchange.


I agree that my answers were a little OT to the main discussion 
of this thread. But sometimes you want to discuss a bit more wide 
things, outside a matchbox. Next time in similar situations I 
will start a new thread then.

My two post didn't imply to contain significant insights, they 
mostly contain a single question.

Regarding the value of those two posts, they raises some 
questions, like: is D fit just for video games, or is it good to 
write highly reliable programs too? Are Ada programmers going to 
appreciate D?

The purposes of a language are important, because they must guide 
its design and progressive development. If D is very good mostly 
for games, then probably it's worth adding in Phobos things 
useful to write games, and the language designers need to listen 
more to what people like Carmak ask to language designers. On the 
other hand if in D future there is the creation of high integrity 
systems to replace some of the current uses of Ada (and 
C-high-integrity profiles), then it's worth considering how much 
useful some Ada features are, maybe for present and future 
improvements of D. As I have shown Ada has several advantages 
over D in that regard.

Bye,
bearophile
Aug 04 2012
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Saturday, 4 August 2012 at 15:12:54 UTC, bearophile wrote:

 Andrei Alexandrescu:


 I wasn't referring the clarity of explanation, just that I 
 think this sort of righteous pontification - cheap to produce, 
 yet implying vast insight - doesn't add any value to the 
 exchange.


 I agree that my answers were a little OT to the main discussion 
 of this thread. But sometimes you want to discuss a bit more 
 wide things, outside a matchbox. Next time in similar 
 situations I will start a new thread then.

 My two post didn't imply to contain significant insights, they 
 mostly contain a single question.

 Regarding the value of those two posts, they raises some 
 questions, like: is D fit just for video games, or is it good 
 to write highly reliable programs too? Are Ada programmers 
 going to appreciate D?


I doubt Ada programmers would appreciate any other language, given
the type of high security applications Ada is used in.

Even C and C++ have to endure strict regulations to be used in 
such environments, for example the Auto Industry MISRA standard.

--
Paulo
Aug 04 2012
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Paulo Pinto:

Thank you for your answer, but I think you have missed most 
subtleties of my points.


 I doubt Ada programmers would appreciate any other language, 
 given the type of high security applications Ada is used in.


I was not referring to just Ada programmers, but to programs that 
people *maybe* want to write in Ada.

Programs are not classified in just two groups as "normal" and 
"ultra high integrity". There is a continuum between the quicker 
Perl script and the Shuttle flight control software.



 Even C and C++ have to endure strict regulations to be used in 
 such environments, for example the Auto Industry MISRA standard.


D already contains some rules of those subsets of C and C++, and 
some of those rules are not needed in D because D has other 
features that avoid their need.

D is not like MISRA C but it's generally safer than regular C. A 
stricter subset of D too can be invented.

So, I think D is fit for intermediate projects where you don't 
want to afford the costs of the proved ADA-SPARK subset, but you 
want something a bit safer than plain full C/C++ (this is also 
the main design purpose of Rust language).

If future people will appreciate to use D for such purposes, then 
it's worth tuning a bit D/Phobos for their needs too.

Bye,
bearophile
Aug 05 2012
parent reply "Franciszek =?UTF-8?B?Q3pla2HFgmEi?= <home valentimex.com> writes:
I spent far to much time with Ada (I have and I have read quite a 
pile of books on this language). When I tried to write some 
sample programs with GNAT using advanced features of this 
language I immediately hit on bugs so ridiculous that I was 
thrown off the language for good. There are no free compilers of 
this language (which you could freely use to write commercial 
programs, like for example games), no affordable commercial 
compilers (which you could buy for ~$500). Ada as a language is 
DEAD. And you certainly heard about the Ada related catastrophe 
of the Ariadne rocket? So much for "safety". Ada is dead and 
should not be touched with a mile pole.

On Sunday, 5 August 2012 at 13:49:18 UTC, bearophile wrote:

 Paulo Pinto:

 Thank you for your answer, but I think you have missed most 
 subtleties of my points.


 I doubt Ada programmers would appreciate any other language, 
 given the type of high security applications Ada is used in.


 I was not referring to just Ada programmers, but to programs 
 that people *maybe* want to write in Ada.

 Programs are not classified in just two groups as "normal" and 
 "ultra high integrity". There is a continuum between the 
 quicker Perl script and the Shuttle flight control software.



 Even C and C++ have to endure strict regulations to be used in 
 such environments, for example the Auto Industry MISRA 
 standard.


 D already contains some rules of those subsets of C and C++, 
 and some of those rules are not needed in D because D has other 
 features that avoid their need.

 D is not like MISRA C but it's generally safer than regular C. 
 A stricter subset of D too can be invented.

 So, I think D is fit for intermediate projects where you don't 
 want to afford the costs of the proved ADA-SPARK subset, but 
 you want something a bit safer than plain full C/C++ (this is 
 also the main design purpose of Rust language).

 If future people will appreciate to use D for such purposes, 
 then it's worth tuning a bit D/Phobos for their needs too.

 Bye,
 bearophile
Aug 07 2012
parent reply "Araq" <rumpf_a web.de> writes:
On Tuesday, 7 August 2012 at 10:28:00 UTC, Franciszek Czekała 
wrote:

 I spent far to much time with Ada (I have and I have read quite 
 a pile of books on this language). When I tried to write some 
 sample programs with GNAT using advanced features of this 
 language I immediately hit on bugs so ridiculous that I was 
 thrown off the language for good.


For example?



 There are no free compilers of this language (which you could 
 freely use to write commercial programs, like for example 
 games), no affordable commercial compilers (which you could buy 
 for ~$500). Ada as a language is DEAD.


FSF's GNAT in GCC is GPL with linking exception, like the rest of 
GCC.
If you say "you can't build commercial software" with this, you 
can't build commercial software with GCC either.


 And you certainly heard about the Ada related catastrophe of 
 the Ariadne rocket? So much for "safety". Ada is dead and 
 should not be touched with a mile pole.


http://en.wikipedia.org/wiki/Ariane_5

"Ariane 5's first test flight (Ariane 5 Flight 501) on 4 June 
1996 failed, with the rocket self-destructing 37 seconds after 
launch because of a malfunction in the control software.[14] A 
data conversion from 64-bit floating point value to 16-bit signed 
integer value to be stored in a variable representing horizontal 
bias caused a processor trap (operand error)[15] because the 
floating point value was too large to be represented by a 16-bit 
signed integer. The software was originally written for the 
Ariane 4 where efficiency considerations (the computer running 
the software had an 80% maximum workload requirement[15]) led to 
4 variables being protected with a handler while 3 others, 
including the horizontal bias variable, were left unprotected 
because it was thought that they were "physically limited or that 
there was a large margin of error".[15] The software, written in 
Ada, was included in the Ariane 5 through the reuse of an entire 
Ariane 4 subsystem despite the fact that the particular software 
containing the bug, which was just a part of the subsystem, was 
not required by the Ariane 5 because it has a different 
preparation sequence[15] than the Ariane 4."
Aug 07 2012
next sibling parent "Matt" <webwraith fastmail.fm> writes:
Jeeze, guys, OT? The OP didn't ask about ADA, or exploding 
rockets. I, personally, would think that D is perfectly capable 
of handling a MMORPG client, as it has proven to be very capable 
of pretty much all the tasks required. Derelict is your friend 
here, I'd wager, allowing you access to libraries such as SDL, 
OpenGL (should you go onto a 3D client, maybe for a later game), 
sound libraries and more, while multi-threading and timing are 
handled just fine by Phobos, as are file manipulations which 
includes ZIP archives, and memory-mapped files
Aug 09 2012
prev sibling parent reply "Franciszek =?UTF-8?B?Q3pla2HFgmEi?= <home valentimex.com> writes:
On Tuesday, 7 August 2012 at 18:08:25 UTC, Araq wrote:

 On Tuesday, 7 August 2012 at 10:28:00 UTC, Franciszek Czekała 
 wrote:

 I spent far to much time with Ada (I have and I have read 
 quite a pile of books on this language). When I tried to write 
 some sample programs with GNAT using advanced features of this 
 language I immediately hit on bugs so ridiculous that I was 
 thrown off the language for good.


 For example?


If my memory serves me the bugs were related to postblit 
constructors and finalizers (not to mention that these features 
are horribly designed and a clear afterthought).

 There are no free compilers of this language (which you could 
 freely use to write commercial programs, like for example 
 games), no affordable commercial compilers (which you could 
 buy for ~$500). Ada as a language is DEAD.


 FSF's GNAT in GCC is GPL with linking exception, like the rest 
 of GCC.
 If you say "you can't build commercial software" with this, you 
 can't build commercial software with GCC either.


Check http://libre.adacore.com/comparisonchart/
GNAT GPL edition is meant for "Free Software development 
following the terms of the GPL". It is not that the compiler is 
GPL protected. It is that your programs created with GNAT are 
required to be GPL protected. The difference is related with 
licensing of the GNAT runtime which is always a part of compiled 
Ada programs. This licensing was changed some time ago to put 
restrictions on what you can do with Ada. I spent some time 
searching internet forums trying to clear the matter and the 
consensus was that you cannot legally use free GNAT to create 
closed-source commercial programs.


 And you certainly heard about the Ada related catastrophe of 
 the Ariadne rocket? So much for "safety". Ada is dead and 
 should not be touched with a mile pole.


 http://en.wikipedia.org/wiki/Ariane_5

 "Ariane 5's first test flight (Ariane 5 Flight 501) on 4 June 
 1996 failed, with the rocket self-destructing 37 seconds after 
 launch because of a malfunction in the control software.[14] A 
 data conversion from 64-bit floating point value to 16-bit 
 signed integer value to be stored in a variable representing 
 horizontal bias caused a processor trap (operand error)[15] 
 because the floating point value was too large to be 
 represented by a 16-bit signed integer. The software was 
 originally written for the Ariane 4 where efficiency 
 considerations (the computer running the software had an 80% 
 maximum workload requirement[15]) led to 4 variables being 
 protected with a handler while 3 others, including the 
 horizontal bias variable, were left unprotected because it was 
 thought that they were "physically limited or that there was a 
 large margin of error".[15] The software, written in Ada, was 
 included in the Ariane 5 through the reuse of an entire Ariane 
 4 subsystem despite the fact that the particular software 
 containing the bug, which was just a part of the subsystem, was 
 not required by the Ariane 5 because it has a different 
 preparation sequence[15] than the Ariane 4."


The program was written with Ada and failed in a most stupid way. 
Is it not a proof enough that safety cannot be sensibly enforced 
by mechanical tools? And this was the main rationale for Ada from 
day one. If you check for possible commercial compilers you will 
see that most of them remember the days of Windows 95. Ada was 
forced on people by administrative means and died when those 
means were removed. I wonder how much Ada is in Curiosity on 
Mars. Let me guess, 0%?
Aug 10 2012
next sibling parent reply "meh" <meh meh.com> writes:
 The program was written with Ada and failed in a most stupid 
 way. Is it not a proof enough that safety cannot be sensibly 
 enforced by mechanical tools? And this was the main rationale 
 for Ada from day one. If you check for possible commercial 
 compilers you will see that most of them remember the days of 
 Windows 95. Ada was forced on people by administrative means 
 and died when those means were removed. I wonder how much Ada 
 is in Curiosity on Mars. Let me guess, 0%?


The F35 runs on C++.

"Another difference with JSF is we have learned well the lesson 
that Moore's Law can work against you if you don't pay 
attention," Jeffreys continues. "So we have designed for 
technology refresh, so at the appropriate time we can stop 
putting in the 1 GHz processor board and swap out to the 2 GHz 
board without having to go back and do any redesign. We were once 
required to use a MIL-STD-1760 processor with Ada or other 
military languages; now we use commercial PowerPC with C++."
Aug 10 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/10/2012 1:22 AM, meh wrote:

 "Another difference with JSF is we have learned well the lesson that Moore's
Law
 can work against you if you don't pay attention," Jeffreys continues. "So we
 have designed for technology refresh, so at the appropriate time we can stop
 putting in the 1 GHz processor board and swap out to the 2 GHz board without
 having to go back and do any redesign. We were once required to use a
 MIL-STD-1760 processor with Ada or other military languages; now we use
 commercial PowerPC with C++."


It's a heck of a lot cheaper to keep things running if they are built out of 
commodity hardware.
Aug 10 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/10/2012 1:05 AM, "Franciszek Czekała" <home valentimex.com>" wrote:

 I wonder how much Ada is in Curiosity on Mars. Let me guess, 0%?


It's all in C.

Take a look at bearophile's list of Ada features advertised as making Ada code 
less buggy. Then look at, for example, dmd's bugzilla list.

How many of those bugs would have been prevented by Ada's features?

I'd say about 0.
Aug 10 2012
next sibling parent reply "jack" <jack jack.com> writes:
On Friday, 10 August 2012 at 08:38:18 UTC, Walter Bright wrote:

 On 8/10/2012 1:05 AM, "Franciszek Czekała" 
 <home valentimex.com>" wrote:

 I wonder how much Ada is in Curiosity on Mars. Let me guess, 
 0%?


 It's all in C.


Nope, at some place of the compilation there is some intermediate 
C code, yes, but the stuff the developers wrote is not C.


 Take a look at bearophile's list of Ada features advertised as 
 making Ada code less buggy. Then look at, for example, dmd's 
 bugzilla list.

 How many of those bugs would have been prevented by Ada's 
 features?

 I'd say about 0.


for example 4491 and 4835. This should render your "0" invalid.
Aug 10 2012
next sibling parent "Matt" <webwraith fastmail.fm> writes:
... I fold. I'll wait over at my 'module paths' thread for 
everyone to stop arguing about D vs language of the week.
Aug 10 2012
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 08/10/2012 11:51 AM, jack wrote:

 On Friday, 10 August 2012 at 08:38:18 UTC, Walter Bright wrote:

 On 8/10/2012 1:05 AM, "Franciszek Czekała" <home valentimex.com>" wrote:

 I wonder how much Ada is in Curiosity on Mars. Let me guess, 0%?


 It's all in C.


 Nope, at some place of the compilation there is some intermediate C
 code, yes, but the stuff the developers wrote is not C.


 Take a look at bearophile's list of Ada features advertised as making
 Ada code less buggy. Then look at, for example, dmd's bugzilla list.

 How many of those bugs would have been prevented by Ada's features?

 I'd say about 0.


 for example 4491 and 4835.


Those are not actually bugs. 4491 should probably be marked as an
enhancement request just as 4835 already is.

Anyway, how would a compiler written in Ada magically have support for
those enhancements?


 This should render your "0" invalid.


It does not.
Aug 10 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/10/2012 2:51 AM, jack wrote:

 On Friday, 10 August 2012 at 08:38:18 UTC, Walter Bright wrote:

 On 8/10/2012 1:05 AM, "Franciszek Czekała" <home valentimex.com>" wrote:

 I wonder how much Ada is in Curiosity on Mars. Let me guess, 0%?


 It's all in C.


 Nope, at some place of the compilation there is some intermediate C code, yes,
 but the stuff the developers wrote is not C.


According to this, it's C:





 Take a look at bearophile's list of Ada features advertised as making Ada code
 less buggy. Then look at, for example, dmd's bugzilla list.

 How many of those bugs would have been prevented by Ada's features?

 I'd say about 0.


 for example 4491


No, the compiler is detecting it and working as expected.


 and 4835.


It's arguable.


 This should render your "0" invalid.


Even if you find any, I sad "about" 0.
Aug 10 2012
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 10 August 2012 at 18:37:14 UTC, Walter Bright wrote:

 On 8/10/2012 2:51 AM, jack wrote:

 On Friday, 10 August 2012 at 08:38:18 UTC, Walter Bright wrote:

 On 8/10/2012 1:05 AM, "Franciszek Czekała" 
 <home valentimex.com>" wrote:

 I wonder how much Ada is in Curiosity on Mars. Let me guess, 
 0%?


 It's all in C.


 Nope, at some place of the compilation there is some 
 intermediate C code, yes,
 but the stuff the developers wrote is not C.


 According to this, it's C:




If you cared to follow the discussion up to the JPL documents, you
would see that the majority of C code is actually generated via 
Python.

As for the remaining handwritten part, it follows the JPL strict 
C coding standard, which is an extension of MISRA C, with so many 
restrictions that
it kind of turns C into a Pascal like language.

--
Paulo
Aug 10 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/10/2012 3:50 PM, Paulo Pinto wrote:

 If you cared to follow the discussion up to the JPL documents, you
 would see that the majority of C code is actually generated via Python.


Then I stand corrected.



 As for the remaining handwritten part, it follows the JPL strict C coding
 standard, which is an extension of MISRA C, with so many restrictions that
 it kind of turns C into a Pascal like language.


I read that document, and it isn't that strict. In fact, I thought a lot of it 
was just common sense, like not having a #if in one file and the matching
#endif 
in another.
Aug 10 2012
next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 10 August 2012 at 23:22:03 UTC, Walter Bright wrote:

 On 8/10/2012 3:50 PM, Paulo Pinto wrote:

 If you cared to follow the discussion up to the JPL documents, 
 you
 would see that the majority of C code is actually generated 
 via Python.


 Then I stand corrected.


I think this goes into the philosophical realm, if a language is 
still being used if it only serves as target of the generated 
code, or if the generator is actually counts as the tool being 
used.

JPL could probably change the generator to target another 
language, while keeping what might be considered as the source 
input files.

--
Paulo
Aug 11 2012
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:


 As for the remaining handwritten part, it follows the JPL 
 strict C coding
 standard, which is an extension of MISRA C, with so many 
 restrictions that
 it kind of turns C into a Pascal like language.


 I read that document, and it isn't that strict. In fact, I 
 thought a lot of it was just common sense, like not having a 
 #if in one file and the matching #endif in another.


In MISRA C you can't use unbounded loops (unless they are 
infinite loops like the global loop in the main), any kind of 
recursion, you can't allocate heap memory, there are some 
restrictions in pointer and union usage, the compiler must be 
able to statically know what is the function you are calling 
through its pointer, you can't use goto, setjmp, and so on and 
on. It's that strict.

Bye,
bearophile
Aug 11 2012
prev sibling next sibling parent reply "Araq" <rumpf_a web.de> writes:
On Friday, 10 August 2012 at 08:38:18 UTC, Walter Bright wrote:

 On 8/10/2012 1:05 AM, "Franciszek Czekała" 
 <home valentimex.com>" wrote:

 I wonder how much Ada is in Curiosity on Mars. Let me guess, 
 0%?


 It's all in C.

 Take a look at bearophile's list of Ada features advertised as 
 making Ada code less buggy. Then look at, for example, dmd's 
 bugzilla list.

 How many of those bugs would have been prevented by Ada's 
 features?

 I'd say about 0.


And how many of those bugs would have been prevented with D's 
const system? (Which apparently still has some holes wrt 
delegates ...)

But IMHO it's an absurd comparison anyay since dmd does not 
qualify as a hard realtime system with provably bounded memory 
usage (which is what Ada is about ...)
Aug 10 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/10/2012 11:07 AM, Araq wrote:

 On Friday, 10 August 2012 at 08:38:18 UTC, Walter Bright wrote:

 On 8/10/2012 1:05 AM, "Franciszek Czekała" <home valentimex.com>" wrote:

 I wonder how much Ada is in Curiosity on Mars. Let me guess, 0%?


 It's all in C.

 Take a look at bearophile's list of Ada features advertised as making Ada code
 less buggy. Then look at, for example, dmd's bugzilla list.

 How many of those bugs would have been prevented by Ada's features?

 I'd say about 0.


 And how many of those bugs would have been prevented with D's const system?


Probably several. David Held has been reviewing the source code, and has found 
interactions between subsystems of the compiler that shouldn't be there, and 
would have been detected if const was used properly.

Const does a couple things:

1. it is self-documenting, making code using it automatically clearer wrt what 
an interface does and does not modify

2. it forces you to think carefully about interface design. This has caused a 
lot of discussion in the use of const on interfaces in the Phobos design

Also, dmd is not a multithreaded program, and const contributes a lot towards 
writing less buggy multithreaded programs, again by making interfaces clearer.



 (Which apparently still has some holes wrt delegates ...)


I know, but that's irrelevant to this discussion.



 But IMHO it's an absurd comparison anyay since dmd does not qualify as a hard
 realtime system with provably bounded memory usage (which is what Ada is about
...)


I don't think it's irrelevant at all. I think the topic of what language 
features contribute to writing bug free code and what features contribute to 
buggy code is very topical and interesting, and *important*.
Aug 10 2012
parent reply "Araq" <rumpf_a web.de> writes:
 And how many of those bugs would have been prevented with D's 
 const system?


 Probably several. David Held has been reviewing the source 
 code, and has found interactions between subsystems of the 
 compiler that shouldn't be there, and would have been detected 
 if const was used properly.


A concrete example would really be nice here ...
Aug 12 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/12/2012 5:00 AM, Araq wrote:

 A concrete example would really be nice here ...


Inappropriate use of Outbuffer's internal data.
Aug 13 2012
prev sibling parent reply "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Friday, 10 August 2012 at 08:38:18 UTC, Walter Bright wrote:

 Take a look at bearophile's list of Ada features advertised as 
 making Ada code less buggy. Then look at, for example, dmd's 
 bugzilla list.

 How many of those bugs would have been prevented by Ada's 
 features?

 I'd say about 0.


It's a good point.

I'd say it's about the same in my line of work (making games with 
C++).

Here's what I perceive to be the most common causes of bugs in 
things I write:

1. Unconsidered use cases.
- e.g. User did X, but I had forgot to consider X when writing 
the code, or X was considered by poorly tested.

2. Poor knowledge of a system.
- e.g. Wrote the code expecting it to do something, but it didn't 
do all the things I expected, or my code had unintended 
side-affects in another part of the system.

3. Uninitialised variables.
- These are relatively rare, but consume a lot of time as they 
can be hard to reproduce and only appear in release builds.

4. NaN's.
- Quite common in any sort of physical simulation code, and 
difficult to track down.

5. Threading issues
- Quite rare, but difficult to track down.




of developers on a project increases (as well as the number of 
lines of code). DMD is quite small, and you (who has full 

in DMD.




(as it often does in that sort of code).


partially solved by things like functional programming, which 
makes some kinds of code simpler, meaning people are less likely 
to misunderstand how your system works. I have no doubt that it's 
true, but it's hard to argue that objectively. I don't believe 
there is any silver bullet for simple code.
Aug 11 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/11/2012 5:48 AM, Peter Alexander wrote:

 Here's what I perceive to be the most common causes of bugs in things I write:


It's a good list. I know that the kinds of bugs my own code has has changed
over 
the years, clearly due to experience. I'm just not so plagued with low level 
mistakes like I used to be, because I've learned to avoid them. The problems
I'm 
left with are:

1. incomplete understanding of the problem I'm trying to solve

2. changes in the design breaking the existing code's assumptions

I don't really know what to do about (1). But with (2), I'm thinking that a 
design that focuses better on encapsulation and compartmentalization should
fare 
better, hence my interest in those features of D that facilitate this.
Aug 11 2012
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:


 The problems I'm left with are:

 1. incomplete understanding of the problem I'm trying to solve

 2. changes in the design breaking the existing code's 
 assumptions

 I don't really know what to do about (1). But with (2), I'm 
 thinking that a design that focuses better on encapsulation and 
 compartmentalization should fare better, hence my interest in 
 those features of D that facilitate this.


Haskell folks say that their strong types help clear up a bit the 
meaning of the parts of the problem ("if it compiles it's right" 
is one of their mottos); and they also say those strong types 
help avoid introducing some bugs caused by changes in the design, 
because they cause type errors. They generally suggest to move as 
many assumptions as possible into the types.

I have programmed in Haskell, but not enough yet to see those 
qualities a lot.

Bye,
bearophile
Aug 11 2012
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
 Haskell folks say that their strong types help clear up a bit 
 the meaning of the parts of the problem ("if it compiles it's 
 right" is one of their mottos); and they also say those strong 
 types help avoid introducing some bugs caused by changes in the 
 design, because they cause type errors. They generally suggest 
 to move as many assumptions as possible into the types.


A recent nice blog post, discussed on Reddit, shows some basic 
examples:

http://tomasp.net/blog/type-first-development.aspx

http://www.reddit.com/r/programming/comments/yad16/why_typefirst_development_matters/

In Haskell/Scala you sometimes see rather more refined examples.

Bye,
bearophile
Aug 16 2012
parent "bearophile" <bearophileHUGS lycos.com> writes:
Some integer overflow, use-after-free and out-of-bounds writes 
bugs in the Abobe PDF viewer:
http://gynvael.coldwind.pl/?id=483

To find them maybe they have used the ideas shown here:
http://taviso.decsystem.org/making_software_dumber.pdf

Bye,
bearophile
Aug 17 2012
prev sibling next sibling parent reply "Araq" <rumpf_a web.de> writes:
 FSF's GNAT in GCC is GPL with linking exception, like the rest 
 of GCC.
 If you say "you can't build commercial software" with this, 
 you can't build commercial software with GCC either.


 Check http://libre.adacore.com/comparisonchart/


FSF's GNAT is not Adacore's GNAT ...
http://en.wikipedia.org/wiki/GNAT#License


 The program was written with Ada and failed in a most stupid 
 way.


It wasn't Ada's fault. The guys explicitely disabled some runtime 
checks. By the same logic you could blame the CPU they used ... 
Correlation is not causation.
Aug 10 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 08/10/2012 09:55 PM, Araq wrote:

 FSF's GNAT in GCC is GPL with linking exception, like the rest of GCC.
 If you say "you can't build commercial software" with this, you can't
 build commercial software with GCC either.


 Check http://libre.adacore.com/comparisonchart/


 FSF's GNAT is not Adacore's GNAT ...
 http://en.wikipedia.org/wiki/GNAT#License


 The program was written with Ada and failed in a most stupid way.


 It wasn't Ada's fault.


The point is that Ada didn't prevent it.


 The guys explicitely disabled some runtime checks.
 By the same logic you could blame the CPU they used ...


Nobody has blamed Ada.


 Correlation is not causation.


Correlation is correlation.
Aug 10 2012
parent reply "David Nadlinger" <see klickverbot.at> writes:
On Friday, 10 August 2012 at 20:11:08 UTC, Timon Gehr wrote:

 The point is that Ada didn't prevent it.
 […]
 Correlation is correlation.


Following the same logic, you could argue that SafeD is useless, 
because you can still write exactly the same kind of 
memory-corruption bugs if you only disable it.

David
Aug 10 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 08/10/2012 10:21 PM, David Nadlinger wrote:

 On Friday, 10 August 2012 at 20:11:08 UTC, Timon Gehr wrote:

 The point is that Ada didn't prevent it.
 […]
 Correlation is correlation.


 Following the same logic,


I'm going to ignore that part.


  you could argue that SafeD is useless,


SafeD is certainly useless for some purposes.


 because you can still write exactly the same kind of
 memory-corruption bugs if you only disable it.


There is no need to disable it to reach that goal.  safe indicates that
some specific function bodies do not contain unsafe constructs. It does
not prove transitive memory safety.
Aug 10 2012
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 08/10/2012 10:05 AM, "Franciszek Czekała" <home valentimex.com>" wrote:

 The program was written with Ada and failed in a most stupid way. Is it
 not a proof enough that safety cannot be sensibly enforced by mechanical
 tools?


It only shows that Ada cannot provide such safety guarantees. (Which
is clear from its specification alone, there actually was no need to
blast a rocket to establish that fact.) It is perfectly possible that
automated reasoning will become strong enough to automatically prove
some interesting program properties.
Aug 10 2012
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/4/2012 8:12 AM, bearophile wrote:

 My two post didn't imply to contain significant insights, they mostly contain a
 single question.

 Regarding the value of those two posts, they raises some questions, like: is D
 fit just for video games, or is it good to write highly reliable programs too?
 Are Ada programmers going to appreciate D?

 The purposes of a language are important, because they must guide its design
and
 progressive development. If D is very good mostly for games, then probably it's
 worth adding in Phobos things useful to write games, and the language designers
 need to listen more to what people like Carmak ask to language designers. On
the
 other hand if in D future there is the creation of high integrity systems to
 replace some of the current uses of Ada (and C-high-integrity profiles), then
 it's worth considering how much useful some Ada features are, maybe for present
 and future improvements of D. As I have shown Ada has several advantages over D
 in that regard.


What's frustrating about your analyses is they fail to mention or account for 
any features D has that make it more reliable than Ada. It's like you took a 
list of Ada features and ticked off which ones were not in D, thus making it a 
foregone conclusion that D can never be more than a pathetic subset of Ada.

For once I'd like you to take a list of D features and tick off those not in
Ada 
(or whatever other language du jour).

Like transitive immutability.
Aug 09 2012
prev sibling next sibling parent reply Stefan Scholl <stesch no-spoon.de> writes:
Wow! The answers here aren't very encouraging for new D users.
Aug 03 2012
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Stefan Scholl:


 Wow! The answers here aren't very encouraging for new D users.


Or maybe some people here know that giving honest technical 
answers is sometimes a good strategy. If you give false hopes you 
risk creating a bad image to D.

Bye,
bearophile
Aug 03 2012
prev sibling parent reply "Kapps" <opantm2+spam gmail.com> writes:
On Saturday, 4 August 2012 at 02:20:45 UTC, Stefan Scholl wrote:

 Wow! The answers here aren't very encouraging for new D users.


But the answers will be no better for any other language:


C++ is a terrible language to make a game in.

-Unmaintainable code
-Template bloat everywhere
-No garbage collection, inevitably causing memory leaks
-Due to no garbage collection, higher overhead passing references 
around with smart pointers.
-Difficult to code cross platform for.
-Disappointing lack in standard library
-Confusing build system supporting portability issues.
-Different features supported by different compilers, even in 
different ways.
-Features that may result in your engine giving undefined 
behaviour everywhere.
-Many features are not implemented yet, let alone widespread.
-Threading is not part of the language, when games now-a-days 
tend to be heavily multithreaded for maximum performance.



-Can be difficult to interop with C/C++ libraries.
-Code can be decompiled easily and stolen, even obfuscated.
-Bugs can be easily found and exploited due to IL code.
-Does not compile to native code, so your game will have 
performance issues.
-Overhead when calling native code.
-Your game may not easily run on every platform.
-Different compilers (all two of them) support different parts of 
the language.
-Forces your userbase to install yet a second product for .NET 
runtime and/or Mono.

Etc. The actual significant issue I would say for active 
development of an MMORPG client is the garbage collector. It will 
get fixed eventually, but it's supposedly not up to par yet. Of 
course, you can just use manual memory management if you're so 
inclined. However for a 2D game, this won't be an issue I 
believe. You *will* have to make some minor changes every now and 
then when DMD gets breaking changes, but I've never encountered 
one yet that's a non-trivial fix.
Aug 03 2012
parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Saturday, 4 August 2012 at 03:12:01 UTC, Kapps wrote:

 On Saturday, 4 August 2012 at 02:20:45 UTC, Stefan Scholl wrote:

 [...]



 [...]
 -Does not compile to native code, so your game will have 
 performance issues.


Just use ngen when installing the application. or mono -aot when 
using Mono.

Plus, the current most used **implementations** compile to MSIL 
by default, this is not a language issue.
Aug 03 2012
prev sibling parent reply ponce <spam spam.org> writes:
Le 03/08/2012 02:22, Robert a écrit :

 Hi all,



 I am currently developing a MMORPG, client part is in c++ and

 side ?

 Its a simple 2d isometric game using opengl 3.X (with shaders) so
 its not really a problem if i lose some fps.

 Thanks and sorry for my bad english(im french).


To answer your question about D, I think D is more than "ok" if you 
target Windows, Mac and Linux and no other platform. Productivity gains 
vs C++ are not negligible and it's generally a joy and relief to use.

But... why do you want your server and client software in different 
langages? You might have to duplicate some game logic to make 

again I never did something that ambitious.
Aug 11 2012
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Saturday, 11 August 2012 at 07:44:34 UTC, ponce wrote:

 Le 03/08/2012 02:22, Robert a écrit :

 Hi all,



 I am currently developing a MMORPG, client part is in c++ and

 client
 side ?

 Its a simple 2d isometric game using opengl 3.X (with shaders) 
 so
 its not really a problem if i lose some fps.

 Thanks and sorry for my bad english(im french).


 To answer your question about D, I think D is more than "ok" if 
 you target Windows, Mac and Linux and no other platform. 
 Productivity gains vs C++ are not negligible and it's generally 
 a joy and relief to use.

 But... why do you want your server and client software in 
 different langages? You might have to duplicate some game logic 

 client, but then again I never did something that ambitious.


I have been watching the videos of this year's Assembly 2012 
(http://archive.assembly.org/2012), surprisingly the majority of 
the games created in the game development competition track, have
Aug 11 2012
parent =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim gmail.com> writes:
On Sat, Aug 11, 2012 at 12:12 PM, Paulo Pinto <pjmlp progtools.org> wrote:


 I have been watching the videos of this year's Assembly 2012 (
 http://archive.assembly.org/**2012 <http://archive.assembly.org/2012>),
 surprisingly the majority of the games created in the game development



I don't find it surprising at all. Remember that game developers have to be
extremely pragmatic to be able to get somewhere with their work, because
mixing so much technologies to build such complex experiences requires to
remove as much problems as possible from the final user in a way that is
surprisingly pragmatic.
And as I already said, not all games require really high performance.
A lot of new game developers will use tools that are available, free and
let them focus on making games, not tech (if the game isn't about tech).

It's about tools, not "languages". We choose tools that match the needs
coming from the design of the game, not the language we prefer.


Joel Lamotte
Aug 12 2012