August 10, 2012
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.
August 10, 2012
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.
August 10, 2012
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
August 10, 2012
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.
August 10, 2012
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
August 10, 2012
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.


August 11, 2012
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


August 11, 2012
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.

August 11, 2012
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.


August 11, 2012
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