P.J. Plauger said:
Call it a claim if you will. I think of it as an observation.
That's pretty slithery ...
If you reread your earlier diatribes, you'll find nearly as many
potential meanings for "portability" as occurrences of that word.
That would be pretty hard considering I've cited the dictionary
definition before as well.
I'm simply coming from a coherent worldview that seems to fit
with what rational people seem to mean when they use that word.
And you've come to the conclusion that C is a portable language out of
that. Some might say there's something wrong with your worldview.
I've been promulgating this "definition" for decades,
That's pretty sad ... Its like the swiftboat veterans who believe we
could have won in Vietnam if we had just stayed there.
[...] and I've repeatedly been told that it makes sense.
By who? Oh yes -- people in your worldview. People who think that C
is a portable language. Nice echo chamber.
[...] You seem to be working
backwards from a syllogism that ends in "Ergo, C is not really
portable." As Adlai Stevenson famously summarized a political
opponent's argument, "These are the opinions on which I base my
facts."
And what is your basis for saying this? You say you've read my
archived stuff. I've expanded on this before, and certainly you've
added nothing new here (except for the revelation that you seem to
think earth has an Oxygen atmosphere). So to be honest, I don't think
I've said much new here myself either -- its not a backwards-built
argument. I more liken my exposition here to Stevenson's presentation
before the UN on the issue of missiles.
Fine, pick your adjective. But once you say "degree" you've given
up on using portability as a Boolean. (And what happens when your
boss tells you that one degree costs $12,873.17?)
Its a matter of english -- that's what "--ability" means. I don't get
to "pick" anything; I am just describing what it is.
[...] it's not a Boolean. Availability is thus an important factor in
improving portability.
No. Availability affects where you can port to. The nature of a given
source code's portability is always taken against the set of platforms
that have a compiler for that platform.
And the fewer the platforms, the higher the probable cost of
porting -- I mean, the lower the degree of portability.
"cost of porting"? Why didn't you just say "the higher the probable
porting"? Oh yeah -- that wouldn't make sense. Because "porting" does
not mean "porting cost".
Uh, no. My brother worked a couple of years at making Java programs
really portable. He began by throwing away all multithreading code
and simplifying all GUI calls, so that he could then focus on all
the really sneaky portability problems. FWIW, he's one of the best
programmers I know, and it wasn't easy work for him. (Gosling
began by eliminating all the things from C that he *knew* were
portability problems, thus freeing himself up to get in *real*
trouble.)
And so, if your brother were trying to port C code that was
multithreaded and had GUI calls, do you think your brother would have
an easier time? Your point here seems really irrelevant. Its true
that race conditions are not portable and that Java has been going
through growing pains, but I seem to remember a time when C was hardly
in better shape ("far" and "near" anyone?) The main difference being
that Java appears to have long ago solved problems that C never has.
Back to the complete breakfast again. That "characteristic" you
call portability has a number of components. Among them are
availability, uniformity, and power.
No -- these are orthogonal concepts. The Hello world program is plenty
portable, but you wouldn't call it powerful. The fact that certain
platforms don't have C compilers, (affecting availability), doesn't
make the program itself non-portable.
Similarly, you can look at the source code for Berkeley Db. Its
definately very powerful, and its got pretty reasonable availability,
and the high level API is very uniform -- but just take a look at the
source code! Its pathetic! Hand ported to each and every platform
one at a time, with only the very highest level of API portability!
What does the mean? It means we *KNOW* it doesn't work on Itanium or
AMD64 platforms -- or at least we know it won't until it gets
painstakingly hand ported to those platforms. The upshot? BerkeleyDB
is inherently unportable, excepting for the fact that it has been
"ported by force" to a finite (though fairly large) number of
platforms.
[...] C rates high on all these measures, making it IME the best candidate in many
cases for writing code intended to be portable.
Nonsense. For anything except the most trivial code, you put real
effort into porting C code, and even when you do so, your best bet is
to stick with very conservative statements like "Its very portable, and
known to work on platforms X, Y, Z ..." when describing such
portability. The C specification covers non-2s complement, undefined
behavior on integer overflow, incorrect right shifting, etc but the
problem is that such platforms are barely available, so you can't test,
and so you can't be sure.
And that's where we part company. If by powerful you mean you can
perform certain large scale operations with an economy of expression,
then I agree.
No, I mean things like ftp servers (its in the built-in libraries in
Python), consistent numerics, run-time generated code, auto-serialized
data structures, threading, built-in array/string safety and memory
leak protection and so on.
[...] I write Maplesoft scripts to do things in minutes that
would be impractical in C. But if by powerful you mean that there
are few limitations on what you can manage, then C wins hands down.
Show me run-time generated code, autoserialized data structures or
coroutines in C.
Where the hell did that come from?
Painful experience. If you can't right shift deterministically, you've
lost performance. If you can't assume integer size, you've lost
performance. Standard cryptographic algorithms require exact scalar
integer size knowledge (have "at least" such and such many bits is not
helpful -- it needs to be exact), deterministic right shifting, no
integer overflow, and double-wide integer multiply. If you are forced
to emulate those operations (which the ANSI C standard requires, if you
are writing such code), your performance drops.
[...] And who the hell are you to tell
me what matters to me or what has meaning to me? Get stuffed.
If you try to implement high performance code, especially crypto, with
just standard C how do you expect to do so with "remarkably low
effort"? You'll end up giving up on one of those things.
You see, a lot of people are using google to read usenet now. It means
people can literally check your statements with the click of the mouse.
You can't rely on the news servers expiring your articles in hopes
that nobody will check what you say. In posts leading up to this one,
you've mentioned Fortran and Pascal -- this is in a response to my
statements about "modern languages in common use".
[...] If you take too much pain in porting the code,
somewhere along the line the cost of a complete rewrite
proves to be lower and the code is "not portable". (You
sometimes find that out too late.)
Now tell me who's being black and white?
If the cost is $17,000, that's a "degree".
No, that's a *MEASURE*. Measures, like cost, can go to infinity (in
theory). Degrees, as it is meant here, basically is between 0% and
100% (between 0 and 360 if you are talking about a circle, but its the
same idea). Do you see the difference?
If the question is
"Is cost less than $17,000?" that's a Boolean. Black and white.
Ok, but you miss my point. Why is it ok for *you* to synthesize an
arbitrary black and white, but when I just cite a commonly accepted
black and white (source code being portable or not), you get to deride
me for it?
Shows what happens when you believe more in Perl than in C, I'd say.
But the problems, in the case, *came* from C, the language it was
implemented in. Once its up and running, presumably, he'll have the
portable Perl language ready for him to use.
