Ramon:

> One obious (or seemingly obvious) solution was Ada. Well, no, it wasn't. Maybe, even probably, if I had to develop low level stuff for embedded stuff but not for a large application. And, that was a killer for me, Ada does not really support easily resizable arrays. To make things worse, while there nowadays is Gnat, a nice modern IDE, there is a major lack of libraries.
>
> Falling over the famous Ariane 5 article

The Ariane 5 failure shows that Ada programs are not perfect/infallible. But that's true for most languages :-)

Despite Ada has several problems and flaws, it still has some advantages over D. This is one of the hundreds of RosettaCode tasks written in Ada:

http://rosettacode.org/wiki/Universal_Turing_machine#Ada

If you compare that Ada version with my laboriously written D entry (and you can perform a similar comparison with several other tasks in that site) you see how the D entry replaces tons of tests done statically by the Ada program with run-time tests, like:

this(const ref TuringMachine tm_) {
    immutable errMsg = "Invalid input.";
    enforce(!tm_.runningStates.empty, errMsg);
    enforce(!tm_.haltStates.empty, errMsg);
    enforce(!tm_.symbols.empty, errMsg);
    enforce(tm_.rules.length, errMsg);
    enforce(tm_.runningStates.canFind(tm_.initialState), errMsg);
    enforce(tm_.symbols.canFind(tm_.blank), errMsg);
    const allStates = tm_.runningStates ~ tm_.haltStates;
    foreach (const s; tm_.rules.keys.to!(dchar[])().sort())
        enforce(tm_.runningStates.canFind(s), errMsg);
    foreach (const aa; tm_.rules.byValue)
        foreach (/*const*/ s, const rule; aa) {
            enforce(tm_.symbols.canFind(s), errMsg);
            enforce(tm_.symbols.canFind(rule.toWrite), errMsg);
            enforce(allStates.canFind(rule.nextState), errMsg);
        }

Despite those tests done by the Ada entry are semantically simple, they are numerous and good, and I have used a lot of energy to write the most statically safe D entry. Probably working even more you can make the D entry a bit more statically safe (eventually you could reach the level of Ada code) but the amount of work and code becomes excessive, and the resulting D code becomes unnatural, and rather not idiomatic.

On this Ada is still a winner :-)

Bye,
bearophile

On Sunday, 25 August 2013 at 15:06:28 UTC, bearophile wrote:
> Ramon:
>
>> One obious (or seemingly obvious) solution was Ada. Well, no, it wasn't. Maybe, even probably, if I had to develop low level stuff for embedded stuff but not for a large application. And, that was a killer for me, Ada does not really support easily resizable arrays. To make things worse, while there nowadays is Gnat, a nice modern IDE, there is a major lack of libraries.
>>
>> Falling over the famous Ariane 5 article
>
> The Ariane 5 failure shows that Ada programs are not perfect/infallible. But that's true for most languages :-)
>

Ariane 5 just showed what happens when engineers reuse code without proper testing.

It could happen in any language.

--
Paulo

Well, I had good reason not to mention Ariane5. Looking at that
particular problem, D would have helped, too and roughly in the
same way as Eiffel that is, by doing some debug runs with the
current (Ariane5) values; then dbc could have helped spot the
problem.

I did, btw, not at all intend to bash Ada. From what I can see,
Ada is well alive and has considerably more users than Eiffel
and, at least for the time being, D. Looking at the type of user,
usually not newbies but experienced software engineers, tells me
that Ada is alive and well for a reason.

As for language comparisons or shoot outs, I don't care that
much. I tend to look whether a language has a sound
implementation of some of the major concepts and paradigms,
whether it's consistent(ly implemented) and whether it has
dropped out of academia or rather had an evolutionary birth,
preferably with lots of experience behind it.

And yes, one point I keep in mind is what (in my minds eye) is
the point to be learned from Ariane5: Humans aren't good at micro
bookkeeping large numbers of details - computers are.

Nice! I cannot anymore go through all the over 100 replies to this, sorry if someone else has suggested this:

You should write this article (tidied up a bit) in a blog or somewhere more public on the web! Here in this forum, things are not as public as they could be!
But thanks for sharing anyway!

Stephan


On Monday, 19 August 2013 at 20:18:06 UTC, Ramon wrote:

> Sorry, this is a long and big post. But then, so too is my way that led me here; long, big, troublesome. And I thought that my (probably not everyday) set of needs and experiences might be interesting or useful for some others, too.
> And, of course, I confess it, I just feel like throwing a very big "THANK YOU" at D's creators and makers. Thank you!

On 8/21/2013 9:50 AM, Ramon wrote:
> I am *not* against keeping an eye on performance, by no means. Looking at
> Moore's law, however, and at the kind of computing power available nowadays even
> in smartphones, not to talk about 8 and 12 core PCs, I feel that the importance
> of performance is way overestimated (possibly following a formertimes justified
> tradition).

While a 5% performance boost is not relevant for consumer apps, it can make an enormous difference for server side apps. For example, if you've got a $100m server farm, 5% means you save $5m, and server farms can be much, much bigger than that.

On Sunday, 25 August 2013 at 22:00:23 UTC, Walter Bright wrote:
> On 8/21/2013 9:50 AM, Ramon wrote:
>> I am *not* against keeping an eye on performance, by no means. Looking at
>> Moore's law, however, and at the kind of computing power available nowadays even
>> in smartphones, not to talk about 8 and 12 core PCs, I feel that the importance
>> of performance is way overestimated (possibly following a formertimes justified
>> tradition).
>
> While a 5% performance boost is not relevant for consumer apps, it can make an enormous difference for server side apps. For example, if you've got a $100m server farm, 5% means you save $5m, and server farms can be much, much bigger than that.

You are, of course, perfectly right and my professional background would testify you to be correct.

But I didn't argue "performance is evil" - my point is "performance vs. realiability" and that it may quite well be a problem to favour performance too much.

performance is desirable, no doubt. But reliability is a conditio sine qua non in some environments.

To rephrase it: Thank you, Walter Bright, for giving us not only a performant language but one that also offers some very welcome mechanism to support reliability/safety.

On 8/25/2013 3:13 PM, Ramon wrote:
> You are, of course, perfectly right and my professional background would testify
> you to be correct.

It's also clear to me that unless D achieves performance parity with C++, D is not going to be considered for a lot of applications.

The good news is that I believe that D is technically capable of beating C++ on performance.

Ramon:

> As for language comparisons or shoot outs, I don't care that
> much.

In your first post of this thread you have listed some things you like, some things you don't like, listed points (Arrays, Strings, DBC, modern concurrency, GUI, "defer mechanism", Genericity) you have even assigned points. So while you have not written a direct language comparison, you have analysed specific points. In my answer I've given example that shows why Ada has still something good to offer that's lacking in D. Language comparisons can be sterile, or they can be a chance to learn.

Bye,
bearophile

On 8/25/13 3:00 PM, Walter Bright wrote:
> On 8/21/2013 9:50 AM, Ramon wrote:
>> I am *not* against keeping an eye on performance, by no means. Looking at
>> Moore's law, however, and at the kind of computing power available
>> nowadays even
>> in smartphones, not to talk about 8 and 12 core PCs, I feel that the
>> importance
>> of performance is way overestimated (possibly following a formertimes
>> justified
>> tradition).
>
> While a 5% performance boost is not relevant for consumer apps, it can
> make an enormous difference for server side apps. For example, if you've
> got a $100m server farm, 5% means you save $5m, and server farms can be
> much, much bigger than that.

More than server acquisition costs, it's the electricity.

Andrei

Walter Bright:

> The good news is that I believe that D is technically capable of beating C++ on performance.

Some suggestions for D to increase its performance:
- The frequency of heap allocations (like for arrays and small class instances) of idiomatic D programs should decrease;
- The support for simple SIMD-based programming should improve. In the last weeks I have written here some posts on this topic;
- It should allow simple and almost-standard means to use GPUs;

Bye,
bearophile