Website message overhaul

[Nick Sabalausky]

"Paulo Pinto" <pjmlp at progtools.org> wrote in message 
news:ja62t0$27bd$1 at digitalmars.com...
>
> Even if there was none, languages are not slow
> or fast, implementations are.
>

I know that's become an enormously popular thing to say, but to be brutally 
honest, it's a load of crap. Yes, there can be slow and fast 
implementations, but the fastest implementation in the world isn't going to 
do a damn bit of good if the language itself either A. Lacks the tools to 
let you do things in a fast manner, or B. Has the tools, but they're awkward 
enough that their use is effectively discouraged.

For example, if you take a language that has no direct memory manipulation, 
you're never going to write, say, a codec or a software rasterizer that's as 
fast as what could be done in C/C++/D/etc. If you take a language that does 
have that ability, but it's awkward to use, then it *might* be possible, but 
it's not realistically going to happen (and if it does, it only means 
someone just wasted a bunch of their time).

The only way this will ever change is if somebody invents a *perfect* 
optimizer, and that obviously hasn't happened yet.

(And PLEASE, don't anyone trot out "turing completeness". The typical CS 
student belief that "turing complete" means "you can do anything, just like 
any other turing complete language" is a complete perversion and 
misinterpretation of the theory.)

> As for your comment, was it an issue with the language, the algorithms,
> the implementation or the libraries you were using?
>

The system as a whole:

Convert this to C# ...Without significantly more processing, copying, memory 
usage, verbosity, or hindering readability:

import std.file;

align(1) struct Foo
{
    int x, y;
    ubyte r, g, b, a;
    char[16] ident;
    uint[100] data;
}

void main()
{
    auto buffer = cast(ubyte[])read("data.bin");
    auto foos = cast(Foo[])buffer;
}

Arguments about IO bottlenecks don't count because:

1. It might not be coming from a spinning platter.

2. It might even be coming straight from RAM or ROM.

3. Even if it is from a spinning platter, you might have other CPU-bound 
processing you can get done, even on the same core, while waiting for the 
data to load.

4. Giving the CPU more to do just uses more energy anyway (again, it's not 
always from a spinning platter, and CPUs can be power-hungry too), thus 
costing more, reducing battery life, and potentially hurting the environment 
(depending how your local power grid is, umm, powered).