Why I chose D over Ada and Eiffel

[Ramon]

On Thursday, 22 August 2013 at 19:28:42 UTC, Nick Sabalausky 
wrote:
> On Wed, 21 Aug 2013 18:50:35 +0200
> "Ramon" <spam at thanks.no> 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).
>> 
>
> Even if we assume Moore's law is as alive and well as ever, a 
> related
> note is that software tends to expand to fill the available
> computational power. When I can get slowdown in a text-entry 
> box on a
> 64-bit multi-core, I know that hardware and Moore's law, 
> practically
> speaking, have very little effect on real performance. At this 
> point,
> it's code that affects performance far more than anything else. 
> When we
> hail the great performance of modern web-as-a-platform by the 
> fact that
> it allows an i7 or some such to run Quake as well as a Pentium 
> 1 or 2
> did, then we know Moore's law effectively counts for squat -
> performance is no longer about hardware, it's about not writing
> inefficient software.
>
> Now I'm certainly not saying that we should try to wring every 
> last
> drop of performance out of every place where it doesn't even 
> matter
> (like C++ tends to do). But software developers' belief in 
> Moore's law
> has caused many of them to inadvertently cancel out, or even 
> reverse,
> the hardware speedups with code inefficiencies (which are 
> *easily*
> compoundable, and can and *do* exceed the 3x slowdown you 
> claimed in
> another post was unrealistic) - and, as JS-heavy web apps 
> prove, they
> haven't even gotten considerably more reliable as a result (Not 
> that JS
> is a good example of a reliability-oriented language - but a 
> lot of
> people certainly seem to think it is).

I agree. However I feel we should differentiate:
On one hand we have "Do not waste 3 bytes or 2 cycles!". I don't 
think that this a the, or at least not an adequate answer to 
doubts of Moore's laws eternal validity.
On the other hand we have what is commonly referred to as "code 
bloat". *That's" the point where a diet seems promising and 
reasonable. And btw., there we are talking megabytes instead of 2 
or 5 bytes.

Now, while many look in the hobby-programmers corner for the 
culprits, I'm convinced the real culprits are graphics/gui and 
the merciless diktat of marketing.
The latter because they *want* feature hungry customers and they 
don't give developers the time needed to *properly* implement, 
maintain, and repair those features.
Often connected to the this is the graphical guys (connected 
because graphical is what sells; customers rarely pay for 
optimized algorithm implementations deep down in the code).

Probably making myself new enemies I dare to say that gui, 
colourful and generally graphics is the area of lowest quality 
code. Simplyfying it somewhat and being blunt I'd state: Chances 
are that your server will hum along years without problems. If 
anything with a gui runs some hours without crashing and/or 
filling up stderr, you can consider yourself lucky.
Not meaning to point fingers. But just these days I happened to 
fall over a new gui project. Guess what? They had a colourful 
presentation with lots of vanity, pipe dreams and, of course, 
colours. That matches quite well what I have experienced. 
Gui/graphical/colour stuff is probably the only area where people 
seriously do design with powerpoint. I guess that's how they tick.

You can as well look at different developers. Guys developing for 
an embedded system are often hesitating to even use a RTOS. Your 
average non-gui, say server developer will use some libraries but 
he will ponder their advantages, size, dependencies and quality. 
Now enter the graphic world. John, creating some app, say, to 
collect, show, and sort photos will happily and very generously 
user whatever library sounds remotely usefull and doesn't run 
away fast enough.

Results? An app on a microcontroller that, say, takes care of 
building management in some 10K. A server in some 100K. And the 
funny photo app with 12MB plus another 70MB 
libraries/dependencies. The embedded sytem will run forever and 
be forgotten, the server will be rebooted ever other year and the 
photo app will crash twice a day.