dsimcha wrote:
Vote++. I'm convinced that there's just a subset of programmers out there that
will not use any high-level programming model, no matter how much easier it
makes
life, unless they're convinced it has **zero** overhead compared to the crufty
old
C way. Not negligible overhead, not practically insignificant overhead for
their
use case, not zero overhead in terms of whatever their most constrained resource
is but nonzero overhead in terms of other resources, but zero overhead, period.
Then there are those who won't make any tradeoff in terms of safety,
encapsulation, readability, modularity, maintainability, etc., even if it means
their program runs 15x slower. Why can't more programmers take a more pragmatic
attitude towards efficiency (among other things)? Yes, noone wants to just
gratuitously squander massive resources, but is a few hundred kilobytes (fine,
even a few megabytes, given how cheap bandwidth and storage are nowadays) larger
binary really going to make or break your app, especially if you get it working
faster and/or with less bugs than you would have using some cruftier, older,
lower
level language that produces smaller binaries?
I agree that a lot of the concerns are based on obsolete notions. First
off, I just bought another terabyte drive for $90. The first hard drive
I bought was $600 for 10Mb. A couple years earlier I used a 10Mb drive
that cost $5000. If I look at what eats space on my lovely terabyte
drive, it ain't executables. It's music and pictures. I'd be very
surprised if I had a whole CD's worth of exe files.
Next, even a very large executable doesn't necessarily run any slower
than a small one. The reason is the magic of demand paged virtual
memory. Executables are NOT loaded into memory before running. They are
memory-mapped in. Only code that is actually executed is EVER loaded
into memory.
You can actually organize the layout of code in the exe file so that it
loads very fast, by putting functions that call each other next to each
other, and grouping rarely executed code elsewhere. Optlink has the
features necessary to do this, and the -profile switch can output a file
to drive Optlink to do the necessary layouts.
Other languages do appear to have smaller executables, but that's often
because the runtime library is dynamically linked, not statically
linked, and is not counted as part of the executable size even though it
is loaded into memory to be run. D's runtime library is still statically
linked in for the pragmatic reason that static linking avoids the "dll
hell" versioning problem for your customers.
And lastly, it *is* possible to use D as a "C compiler" with the same
overhead that C has. All you need to do is make your main a "C" main,
and not link in Phobos. In fact, this is how I port dmd to new platforms
before Phobos is built. Stick with "C" constructs (i.e. no dynamic
arrays!) and it will work just like C does.
