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

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

Date: Sun, 09 Jan 2005 19:15:02 GMT

NoDot wrote:
> Beth wrote:
> > XFree86 even ignores the possibility granted by the X protocol
> > specification that it doesn't involve itself in _HOW_ you want to send
the
> > data...it just uses "sockets" regardless (and a "sys_socket" syscall is
in
> > the Linux kernel itself)...you can use any kind of "IPC" for this,
> > though...and one thing that the XFree86 people haven't realised is that
X
> > is not specifying what to use _delibrately_...for instance, if both
> > "client" and "server" are on the same machine, then you can switch to
using
> > the more direct "IPC" (shared memory, message queues, etc. :) without
the
> > "sockets" overhead...it keeps out of this because this allows the
_best_
> > "transport" to be used, as applicable to the two machines involved...
>
> Oh, boy. I'm really not liking this.

In what context? The message or the messenger?

> > You see, lots of the blame is thrown onto X when it should be thrown
onto
> > _poor implementations_ by "bloatware" programmers...
>
> Lux86, XWin+, and LuxAsm: examples of good things to come.

Ah well, only LuxAsm is on the cards...the others are "theoretical
possibilities" only...to be honest, well beyond myself alone...I'm lazy at
the best of times but an entire system with all the trimmings? Release
date: 10 years after I'm dead ;)...

> > Worse, *NIX often also draws the "extremeists": "Users? That disgusting
> > vile lot? If they don't know how to use all the voodoo 'vi' commands
since
> > birth (while editing their X configuration files using a soldering iron
;),
> > then they are clearly ignorant animals who should be culled for the
stain
> > that their idiocy places upon the world! Hand me my shotgun...I'll sort
out
> > these great unwashed 'users'...how dare they be 'average'! How dare
they
> > not spend 6 billion dollars on hardware! How dare they not devote two
> > decades of their life to being an anti-social techno-geek like I am!!
KILL!
> > KILL USERS!!"...*bang*...*BANG*...hmmm, NOT a good idea to talk about
> > "human-machine interfacing" or "good user interface design" with you,
then,
> > eh? ;)...
>
> Where have we all heard this before?

Probably the last time I ranted and raved on the subject...complaining and
moaning...or, alternatively, you bumped into the aforementioned
"extremeists" and they were worryingly far too close to the
supposed-to-be-absurdly-exaggerated-for-emphasis example above? :)

> > Indeed, as NoDot mentioned before, I had thought about an idea of some
kind
> > of "X++"
>
> I think it was a Linux implimentation written only for x86 computers.

That was Linus' original implementation, wasn't it? His infamous USENET
post announcing it to the world for the first time, if I recall correctly,
had some "this is not particularly portable and has loads of x86-isms at
the moment" disclaimer near the end...

Also, XFree86 - from its very name - suggests that it was originally
intended to be x86 only...this is no longer the case, though, as there is
some Apple version, I think...

Both seemed to "buy into" using C more and making it "portable" more...the
"specific" path works to the other extreme...you _accept_ non-portability
of the source code and then code more "to the wire" for performance...note
that the non-portability of the source code does NOT necessarily imply a
non-portability of the _CONCEPTS_...for instance, though we didn't do so
for other reasons, LuxAsm could have taken RosAsm syntax "as is" and merely
re-applied it to the Linux situation...indeed, think of GAS AT&T syntax:
The "style" remains the same for all processors...

Also, this "accept the non-portability" might worry people...but, let's
look at some facts...Microsoft - with all their wealth and resources -
wrote NT for many platforms originally (why the "portable executable" PE
file was so named) but one of the world's richest companies, commanding the
resources of a small nation and having almost complete "monopoly" over the
PC arena, couldn't make it fly...

You have to ask if the dreams of "world domination" really justify
_crippling_ your product's performance in the 90+% common case for the sake
of the 1% rare case of someone wanting the OS or GUI for some other obscure
platform...I'm not saying it's always a pointless consideration but just
saying "look, shall we really look at the _REALITY_ and the _FACTS AND
FIGURES_ of the situation, rather than some 'theoretical ideal' that if you
use libc, then you'll have 'world domination' by a week next Thursday,
're-compiling' for every platform under the Sun"...

When people use C, the "portability" effort isn't always zero,
anyway...certain _concepts_ are logically non-portable...how much time on a
project really is spent coding? Even if we were talking of a complete
"re-write", how much effort is that really? Randy quotes "software
engineering" statistics in his "Great Debate" texts which do challenge if
quite such an emphasis is placed on these things...

Again, not saying this is always appropriate...some program who's sole
purpose is "portability" is obviously NOT where this would apply...but, in
many cases, one has to ask if it would make more sense to _ACCEPT_
"non-portability", code _specifically_ for performance and simply say "if
we want another version for another platform, then we'll simply start the
development effort again"...it wouldn't be totally from scratch...all
"concepts" can be retained...just recoding from the design happens once
more...

That, instead, the OS is made "specific" to the platform in question, to
maximise use of the machine resources throughout...after all, when you
"generalise", then the resource use often gets a bit sloppier...what is the
traditional definition of an OS's purpose? "To provide an interface between
application, hardware and user" (a "framework for their interoperability",
in more posh-sounding language ;)...it seems almost contradictory to be
creating a "framework" for accessing hardware that, ummm, doesn't access
hardware because it's being "portable"...

Indeed, in one sense, could we kind of say that we might be mixing
"concepts" here that inevitably mean that we get poorer performing
implementations? Let's look to analogy...

You're a ship builder...but you're not sure of future ship design...so, to
"hedge your bets", you create a "portable" design...it's kind of half-car,
half-hovercar, half-plane, half-boat, half-train...a "general-purpose
transport vehicle"...and, sure, if someone decides they'd rather a plane
then it's "portable"...just a quick "re-compile" - pull down the "wings"
stashed on the roof when in "boat mode" - and then it's a plane...pull out
the wheels, put the wings back in, now it's a car...

But, at the same time, such "hybrid vehicles" are, in practice, always
"jack of all trades, master of none"...they do all these things but they
don't do any of them particularly well...they "under perform" in comparison
to the "specialist" vehicles...you know, the
"boat-hovercraft-plane-boat-train-car" is not going to beat a formula 1 car
in "car mode", it's NOT going to beat a stealth fighter in "plane mode",
it's NOT going to beat a speedboat in "boat mode"...

And the essential point is that if 90+% of the market is simply _always_
and _only_ ever using "car mode", aren't we just creating a crap car on the
rare, bizarre off-chance someone strangely thinks "right, I would now like
to drive over the ocean without purchasing a boat specifically designed for
the task"?

If you like, we say "look, we just build cars" or "just build ships" here
and concentrate on good _car_ design and good _ship_ design
specifically...if people want a boat, then go see the boat builders...if
you want a car, go see the car builders...

And, in fact, let me make an incredibly bold prediction: The
"general-purpose" / "portable" actually stands _LESS_ chance, ironically,
of "world domination" by its very attempts to "be all things to all people"
simultaneously...

This is just a "guess", of course...never been proved in practice...but the
rationale is like this: We all know that pushed "to the wire", the hardware
is capable of far more...so, create the _specific_ x86 version...being a
bit of a "formula 1" in comparison to other "portable" x86 OSes, it steals
the show...someone tries the "aquacar" hybrid general-purpose OS and when
they click on a button to load an application, the response is, quite
frankly, awful...you know, the "sitting there wondering if the click even
registered or maybe it's even crashed because it's taking forever to do
anything" syndrome...they try out the "formula 1" _specific_ OS and it's
making an embarassment out of this...you click and practically everything
appears "instant"...all the programs are high-performance...it's a dream to
use...users are tempted to think "screw those aquacars!" and want "formula
1" performance straight down the line all the time, once they've met the
"revelation" of what their hardware _CAN_ do, when used specifically and
optimally (note, "optimal" is, by definition, always in the "specific"
arena)...

Then, it does so well, another "open source" project starts up - as they
typically do - because the Apple users are thinking "you know, we'd quite
like that kind of formula 1 performance over here too!"...it's recoded
because, of course, the whole point here is that the "formula 1"
performance is coming from the more optimal, specific use of
resources...although, it _CAN_ maintain "portability" on the
_concepts_...you know, the user sees exactly the same user interface
graphics and the buttons are in the same place...and, well, to the user,
they have no idea that the thing is recoded rather than
"re-compiled"...with the "open source" framework, splitting off another
project to do "the Apple iMac version" is not actually unusual...and it
typically would NOT actually be draining much, if any at all, resources
from the original project...in a sense, "portability" is also grounded in a
particular development model...the _commercial_ one...other development
models might, indeed, be better considering if they really _should_ be
following that commercial model...you know, should "open source" be taking
_advantage_ of its very differences, as those would be its inherent
strengths?

Anyway, the "formula 1" is coded for x86 - that's got you 90+% of "world
dominance" already...why be "greedy" about these things? Moreover, if we're
not particularly pleased with Microsoft "world dominance" and "monopoly",
where's the logic in _DUPLICATING_ the very thing you thought was so awful
about the OSes already in existence? As I mentioned before, you do get a
strange "Microsoft are so crap! Quick, let's copy Microsoft in all
regards!" kind of logic...isn't the very thing that makes Microsoft stuff
so crap, got to be fundamentally rooted in their "objectives", their
"thinking", their "design methodology", their "implementation" methods and
so forth? If you think Elvis is utter crap, then you don't "counter" this
by becoming an Elvis impersonator, surely? That _propogates_ the problem
and makes it worse, not solves it - and its performance wins comfortably
because, really, it's making the others look embarassingly crap...another
"spin-off" project of iMac users who liked the x86 stuff, do the same with
iMac...and so on and so forth...

In a sense, another thing here is questioning whether - kind of like how
Hollywood movies are distributed world-wide - you might _delibrately_
"stage" this? As I say, Hollywood movies tend to work something like
this...they release in America...if it does well, then European
release...then Japanese release...and so forth...if it bombs in America,
then you can save trying to sell what's a bit of a "duff" movie to Europe
and Japan...instead, try to recoup some money back with the old "straight
to video" (though, "straight to DVD" these days ;) approach...don't waste
your money on a big European and Japanese release...all those posters and
interviews and putting multi-millions into "promoting" it, when you've
already gathered that you've got a "turkey" on your hands from the total
box office bomb in native America...

After all, "specific" things can actually be often programmed
_faster_...Rene does speed through things fairly quickly at times and, yes,
I'm sure Rene would also point out that "specific philosophy" is part of
the reason...you can just "get straight to the point"...back before the PC,
most computers had fixed hardware and, yes, you could program the things
fairly quickly...the example that immediately springs to mind - though
perhaps not the best - is the games programmer Tony Crowther...reknown for
the fact that, at his peak, he really was spitting out a new game _every
week_...okay, games are more complicated these days and you'll never manage
"a game per week" ratio anymore...but you've got to think about these games
that are years in development with big teams in comparison to Tony
Crowther, alone, knocking out games every week...there are "caveats" to
this, of course...for example, there were three games of his which were all
the same thing with different graphics (some train thing :)...I'm sure he
was "re-using" big-style and ripping the guts out of one game to insert
into another...

Could it actually, bizarrely, make more sense to program specifically? The
question has no answer at the moment, really, because no-one really
attempts it to have the "statistics" to know conclusively...but there's a
case that "it might just work"...

Indeed, thinking of old games, that was actually a characteristic of
them...they were usually re-coded...and, thus, the Amiga version would
actually have better graphics because the team that were "porting" would
actually _improve_ things to take advantage of the better hardware...and,
generally, this meant that you got a game as good as the hardware
allowed...the 16-bit micros, in comparison to their 8-bit cousins, had much
more RAM so, in fact, extra "subgames" might even be added...bigger levels,
more levels...better graphics and sound, for sure...and so forth...you got
as good as the hardware gave every time...but if your hardware wasn't as
good, you just got a "cut down" / "simplified" version, so to speak, that
was as good as the not-so-impressive hardware would allow...

And the challenge - the "thought experiment" - is to ask if this actually
was necessarily a bad idea or not? Because, though the past is always seen
through rose-tinted spectacles, people who remember those days are often
found saying "ah, things worked better then"...I mean, we're not talking
about "going backwards"...but more, were the _attitudes_ actually "wrong"
that they needed changing? And, yes, some things certainly were...it's like
the "re-working" idea I was talking to Gerhard about a long while back...to
re-write an older game for modern hardware, in that same style that they
used to do it...you know, the Amiga had better graphics, so the Amiga
version looked better...the modern PC version? Well, it'll blow the socks
off the "original version"...and with all that RAM, we can add more
elements...and with the disk space, we can have tons of massive
levels...and so on and so forth...basically, I supposed the simplest way to
look at it is to move the _concept_ from machine to machine but not
necessarily the code at all...

Simple, really...if you write something specifically for the x86, it's not
going to be appropriate (or even possible, probably) for the 68K...on the
other hand, if you write it with some "C conventions" and "standard
library" to make it appropriate for both, then are we, in a sense,
contradicting Lincoln's wisdom:

"You can fool some of the people all of the time, and all of the people
some of the time, but you can not fool all of the people all of the time"
[ Abraham Lincoln ]

There's other dimensions to this too...what is the realistic "shelf life"?
Now, software does tend to carry on being used for a long time but, again,
is it long enough to justify trying to write "timeless" code? Is it even
possible to write "timeless" code, as nothing seems to qualify on this thus
far? And isn't that an implicit "surrender" to any Hope of future progress,
anyway? I mean, we do have the choice of '70s technology or '80s technology
for our OSes here...and they are essentially "stuck" there too...indeed, as
I was saying about X, one of its problems is that it was designed in the
'80s and "it shows" in places...unfortunately, it's basically _locked_
there now...you know, graphics have moved beyond "bitplanes" but the X
design will still be grounded in the assumption (correct in the '80s) that
the graphics hardware is all "bitplane-based"...the "portable" solution
attempts to "abstract" things so much that the code is essentially as
"timeless" as possible...you don't depend on the hardware specifics so the
code remains appropriate...but another alternative is to say "nothing lasts
forever"...instead, you accept it's only got a certain "shelf
life"...indeed, you kind of _want_ that to be the case...old data files are
converted up to new formats (as long as it's a "superset", there should be
a perfect lossless conversion)...and go for what I call "lateral
compatibility" instead...you don't retain all the old version forever more
but create the new version - with "superset" capabilities to the old - and
then data files can be "upgraded" to new formats...to call a "break" with
the old, actually permits that future developments can proceed without
constantly harking back and living in 1972 for the rest of eternity...

> > ...well, you know, C went to C++...X could go to X++...same
> > underlying design, possible "X compatibility" but addressing the
> > "complaints" that X has...which, by the way, as I've been pointing out,
> > aren't really complaints about X...they all are "peripheral" - poor
> > implementations, confusions over having 27 "toolkits" to choose from,
some
> > "extension" doesn't work, crap "window managers", etc. - BUT it's X
that
> > gets the blame, as the "overall name" for what is, after all, lots of
> > different things thrown together...but the simple concept would be redo
X
> > and, this time, there _is_ sound support...there _is_ a "standard"
window
> > manager...there _is_ a "standard" toolkit...and it's implemented bloody
> > _properly_ for once...you know what I mean, yeah?
>
> Sounds interesting, but let's get LuxAsm up and running first, and
> *then* we can mke Lux86 and XWin+.

I don't know that I was ever going to make them, really...it's just a
"thought" of something that would be nice to have...

Oh, don't forget, "mad ideas" are ten-a-penny with me...the way my little
"alien brain" functions...they pop up in my brain all the time...so, I
don't do everything that I think of necessarily...indeed, I couldn't do
everything that I've ever thought of...

> > If programming X is like trying to find the square root of pi in roman
> > numerals, then Windows must be like some binary complex number
differential
> > calculus in a twenty-seven dimensionial problem to solve the meaning of
> > existence in comparison...
>
> I doubt complex numbers, differentials, and twenty-seven dimentions are
that
> difficult. (They might be put together, but my experience with higher
> dimentions[1] and complex numbers, though small, wasn't too bad.)
>
> [1] OK, so I've never been past 3, but the others can't be that bad.

Well, programming X _doesn't_ involve finding the square root of pi with
Roman Numerals, you know...it's just a metaphorical joke...I was just doing
the same kind of joke in return...don't take it too literally...also,
you'll note that you're doing this all in binary throughout to "solve the
meaning of existence"...I think that's a lofty enough goal not to be
thought too easy to do ;)...

But, yes, more dimensions is all the same kind of thing but, well, more
numbers involved...also, note that things _DO_ change past 3 dimensions:
You can no longer accurately draw graphs or otherwise "visualise" what
you're doing (there are "tricks" to make lower dimension "approximations"
but these are "rough", not accurate, representations...well, obviously so,
dimensions of information are missing :)...

> > There's no reason at all, as I say, why GUIs are this big, this
> > complicated, this slow, this "bloated" and this crap...it's just poor
> > design / implementation / programming from the best "bloatware"
programmers
> > in the business...
>
> {www.bloatedjunk.com} should be a redirection to {www.microsoft.com}.
> (If someone manages to reserve that, then they might be able to make
> MS hand over their website, saying the visitors may not be able to tell
> the difference.)

There's a point...are there any laws regarding "damage to reputation" or
whatever from the use of redirection and hyperlinks? I don't think there
really could be...or, if there was, then the internet would start to fall
apart, with cases of people suing other people for linking to their
website...you know, Rene taking Randy to court for supplying a link to
RosAsm or equally stupid things like that...the internet would then become
a legal minefield and it would basically ruin it, just as the "litigation
culture" has conspired to ruin many things (you know, "health and safety"
close down a soup kitchen for the homeless because of the possibility of
someone spilling hot soup on themselves, like that daft cow who sued
McDonald's because her coffee was hot (it's "no win", isn't it? If you
supply cold coffee, you'd get sued for not heating it up...if you supply
hot coffee, you get sued for using hot water in it...and, yes, it makes so
much sense to leave those homeless people to starve to death rather than,
oh dear, a little hot soup being spilled)...someone slips on some ice and
the lawyers rush around trying to sue God for not putting up a warning
sign...all due respect, it's fudging stupid the bizarre things that are
litigated against these days, ain't it?)...

Beth :)

Loading