www.digitalmars.com         C & C++   DMDScript  

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

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

im a c++/c# developper and i really want to try D.

I am currently developing a MMORPG, client part is in c++ and
server in c#, i want to know if D language is "ok" for the 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).
Aug 02 2012
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Robert:

 im a c++/c# developper and i really want to try D.

 I am currently developing a MMORPG, client part is in c++ and
 server in c#, i want to know if D language is "ok" for the 
 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
prev sibling next sibling parent Mike Parker <aldacron gmail.com> writes:
On 8/3/2012 9:22 AM, Robert wrote:
 Hi all,

 im a c++/c# developper and i really want to try D.

 I am currently developing a MMORPG, client part is in c++ and
 server in c#, i want to know if D language is "ok" for the 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).

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 "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
prev sibling next sibling 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 next sibling parent reply "Tobias Pankrath" <tobias pankrath.net> writes:
On Friday, 3 August 2012 at 00:22:51 UTC, Robert wrote:
 Hi all,

 im a c++/c# developper and i really want to try D.

 I am currently developing a MMORPG, client part is in c++ and
 server in c#, i want to know if D language is "ok" for the 
 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
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
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 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,

 im a c++/c# developper and i really want to try D.

 I am currently developing a MMORPG, client part is in c++ and
 server in c#, i want to know if D language is "ok" for the client
 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 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 next sibling parent deadalnix <deadalnix gmail.com> writes:
Le 03/08/2012 02:22, Robert a écrit :
 Hi all,

 im a c++/c# developper and i really want to try D.

 I am currently developing a MMORPG, client part is in c++ and
 server in c#, i want to know if D language is "ok" for the 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).

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

 im a c++/c# developper and i really want to try D.

 I am currently developing a MMORPG, client part is in c++ and
 server in c#, i want to know if D language is "ok" for the 
 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:

 im a c++/c# developper and i really want to try D.

 I am currently developing a MMORPG, client part is in c++ and
 server in c#, i want to know if D language is "ok" for the 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

What did I just read? Oh boy. Andrei
Aug 03 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
next 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 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 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 next 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: http://programmers.stackexchange.com/questions/159637/what-is-the-mars-curiosity-rovers-software-built-in/159638#159638?
 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 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
prev sibling next sibling 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 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 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
prev sibling next sibling 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 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.


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 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 next sibling parent Stefan Scholl <stesch no-spoon.de> writes:
Wow! The answers here aren't very encouraging for new D users.
Aug 03 2012
prev sibling 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 next sibling parent "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. C# is a terrible language to make a game in. -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
prev sibling next sibling 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:

 [...]

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

 [...]
 -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 next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Friday, 3 August 2012 at 02:16:22 UTC, bearophile wrote:
 Robert:

 im a c++/c# developper and i really want to try D.

 I am currently developing a MMORPG, client part is in c++ and
 server in c#, i want to know if D language is "ok" for the 
 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
prev sibling next sibling 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 "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling 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 next sibling parent "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?

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.

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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling 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 "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
prev sibling next sibling parent "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.


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
prev sibling next sibling parent "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
prev sibling next sibling parent "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: http://programmers.stackexchange.com/questions/159637/what-is-the-mars-curiosity-rovers-software-built-in/159638#159638?

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
prev sibling 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 next sibling parent ponce <spam spam.org> writes:
Le 03/08/2012 02:22, Robert a écrit :
 Hi all,

 im a c++/c# developper and i really want to try D.

 I am currently developing a MMORPG, client part is in c++ and
 server in c#, i want to know if D language is "ok" for the 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 to make client-side prediction anyway. I would advise a C# client, but then again I never did something that ambitious.
Aug 11 2012
prev sibling next sibling parent "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,

 im a c++/c# developper and i really want to try D.

 I am currently developing a MMORPG, client part is in c++ and
 server in c#, i want to know if D language is "ok" for the 
 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 to make client-side prediction anyway. I would advise a C# 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 been done in C# with Unity or XNA.
Aug 11 2012
prev sibling next 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 "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. I'd say #1 is by far the most common cause of bugs in any project (certainly DMD), and #2 gets more and more common as the number of developers on a project increases (as well as the number of lines of code). DMD is quite small, and you (who has full knowledge of DMD) checks every change list, so #2 is quite rare in DMD. #3 is solved by D, and #5 as well. #4 is hard to solve, especially when SIMD comes into the picture (as it often does in that sort of code). #2 is interesting because you could arguably say that it is 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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim gmail.com> writes:
--047d7b162fd75a96c804c711ae27
Content-Type: text/plain; charset=UTF-8

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
 competition track, have been done in C# with Unity or XNA.

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 --047d7b162fd75a96c804c711ae27 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Sat, Aug 11, 2012 at 12:12 PM, Paulo = Pinto <span dir=3D"ltr">&lt;<a href=3D"mailto:pjmlp progtools.org" target= =3D"_blank">pjmlp progtools.org</a>&gt;</span> wrote:<br><blockquote class= =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= ing-left:1ex"> <div class=3D"HOEnZb"><div class=3D"h5"><br></div></div> I have been watching the videos of this year&#39;s Assembly 2012 (<a href= =3D"http://archive.assembly.org/2012" target=3D"_blank">http://archive.asse= mbly.org/<u></u>2012</a>), surprisingly the majority of the games created i= n the game development competition track, have been done in C# with Unity o= r XNA.<br> <br><br></blockquote><div><br></div><div>I don&#39;t find it surprising at = all. Remember that game developers have to be extremely pragmatic to be abl= e to get somewhere with their work, because mixing so much technologies to = build such complex experiences requires to remove as much problems as possi= ble from the final user in a way that is surprisingly pragmatic.</div> <div>And as I already said, not all games require really high performance.<= /div><div>A lot of new game developers will use tools that are available, f= ree and let them focus on making games, not tech (if the game isn&#39;t abo= ut tech).</div> <div><br></div><div>It&#39;s about tools, not &quot;languages&quot;. We cho= ose tools that match the needs coming from the design of the game, not the = language we prefer.</div><div><br></div><div><br></div><div>Joel Lamotte</d= iv> <div><br></div></div> --047d7b162fd75a96c804c711ae27--
Aug 12 2012
prev sibling next sibling parent "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
prev sibling 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