Re: Anybody here endure C/Cpp? (.h to .inc conversion)

From: Beth (BethStone21_at_hotmail.NOSPICEDHAM.com)
Date: 01/02/05 

Date: Sun, 02 Jan 2005 04:56:37 GMT

marcus wrote:
> Thats true, cause we think in abstracts so the program should be like
> half conceptual and half functional. Or something like that. Too
esoteric?

...and here lies the problem with "abstraction"...if you're not the one
who's defining the abstractions, trying to comprehend other people's
abstractions (when they aren't particularly "intuitive" to anyone but the
author) can sometimes become a greater nightmare than not having any at
all...and it all ends up as "or something like that" levels of
comprehension as to what someone else is doing...

Worse, source code sits somewhere in the middle, in fact...the "theory" is
that it's all "conceptual" and then some "optimising compiler" flies in and
performs a "miracle" to turn all the "concepts" into hard, useful, concrete
physicality...but, in practice, a machine can't actually do that because,
simply, a compiler is only another software program...the "machine" only a
dumb bunch of circuitry feeding voltage levels around a wafer of silicon...

The practice is that source code has to simultaneously be conceptual and
functional at the same time...demonstrated by things like Randy's "Write
Great Code" book, where he shows how to improve HLL code by understanding
how the machine works at a low level...which _does_ improve code...if the
"HLL Dream" that the compiler did all this and did all this perfectly
infallibly in all cases for all code really were true, then it would be
impossible to do any such thing (or it would be pointless to do any such
thing because the compiler is ahead of you and would have comprehended such
"optimisations" without your help)...

And demonstrated regularly by those who believe this "HLL Dream" and
completely ignore the low-level and optimisation and trust their compilers
completely...but then end up with 500MBs of EXE files and 27 DLL files to
add three numbers together (and then when they distribute their program,
their users double-click and are greeted with "MS657XFHD.DLL is
missing"...which is always a helpful thing...NOT! ;)...claiming "oh,
there's no need for optimisation on modern machines"...really? Yet, in the
same breath, what else do we hear? "Windows is so darn slow just loading up
the Start menu sometimes...and that X is even worse!!"...how long did you
wait for the world's officially slowest loading program: Outlook (Express)?
Go on, get out your stopwatches and have a good giggle seeing how many tens
of seconds by which "optimisation doesn't matter"...add on RAM upgrades in
small, incremental steps to see how long it takes for "RAM doesn't matter"
to actually be true...when you double your machine's RAM and clockspeed,
programs are just written that take up twice the space and run twice as
slow..."upgrading" is often "running to stand still", if not actually
sometimes going backwards...

Yeah, it doesn't matter when you're actually writing source code and the
fact that it matters might require you to do a more professional job...BUT
the second you're using software rather than writing it - so the
responsibility isn't on your shoulders - out comes all the complaints about
how big, slow and bloated everything is (which it is)...

In the "ideal theory" of HLL compilers, the source code should be solely
"conceptual" and then the compiler performs infallible "magic" to turn
"concepts" and "abstractions" (which it cannot possible actually
_UNDERSTAND_ in the context of the application because that would require
_intelligence_, which this "deus ex machina" _doesn't_ actually have) into
the most perfect optimised physical code...this "concept", though, is
complete crap regards the truth of the matter...

And, as you say, we end up with a strange "half conceptual, half
functional" hybrid that isn't pleasing the compiler ("theory") nor is it
pleasing the machine (practice) because it's compromising in both
directions simultaneously...and as ol' Abe once remarked: "You can't fool
all of the people all of the time"...the fact that we can only at best say
"half conceptual" demonstrates how the "theory" that optimising compilers
are "infallible gods" that operate with utter perfectness in all cases is
the kind of hype we should not be believing quite do readily because our
own eyes - go visit your nearest "bloatware" dealer for more details - tell
us that it's clearly otherwise...whatever "theory" may say...

The problem is that even if we had human-level artifically intelligent
compilers that could _comprehend_ code, there's _STILL_ no guarantee they
can do the job because many problems boil down to "enumerate the solutions
and pick the best"...the "HLL optimising compiler infallibility theory" is
based on the premise that machines can solve anything...Turing might
suggest that they "theoretically" should be able to...Godel and ticking
clocks tell us that they practically _can't_...the best we can ever expect
is that it gets "good enough" that it doesn't really matter...some would
contend that current compilers are at this level...but, sorry, I can't help
laughing and ridiculing-in-a-nice-way the very notion...reminds me of those
19th century physicists who declared they'd solved almost everything,
except for one or two "minor" things that needed to be "cleaned up" (things
that turned everything on its head, showed that the Newtonian basis they
were working from was always subtlely flawed, completely redefined the
universe, required many new "fields" to be invented to study it and so
forth...oh well, so much for being near the finish line, eh? And what did
the physicists of the 20th century say? "Ah, we're near a theory of
everything...not far away"..."what? The universal constants might not
actually be constant? The expansion is accelerating? Oh crap! Not
again!!"...it cannot ever be proved, by definition...but, surely by now,
the absolute universal validity of Murphy's Law is beyond dispute?
"Everything, in the end, is deeply ironic", said the joker to the thief
;)...

Beth :)