Re: PL/I string representations
From: Edward G. Nilges (spinoza1111_at_yahoo.com)
Date: 01/02/04
- Next message: Randy Howard: "Re: Letter to US Sen. Byron Dorgan re unpaid overtime"
- Previous message: JT: "Re: Letter to US Sen. Byron Dorgan re unpaid overtime"
- In reply to: Richard Heathfield: "Re: PL/I string representations"
- Next in thread: Randy Howard: "Re: PL/I string representations"
- Reply: Randy Howard: "Re: PL/I string representations"
- Reply: Richard Heathfield: "Re: PL/I string representations"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 1 Jan 2004 16:07:29 -0800
Richard Heathfield <dontmail@address.co.uk.invalid> wrote in message news:<bt1sd7$566$1@sparta.btinternet.com>...
> Randy Howard wrote:
>
> > In article <f5dda427.0312311633.6af290e6@posting.google.com>, spinoza1111
> > @yahoo.com says...
> >>
> >> [...] EBCDIC was pretty much dominant from 1964 to about
> >> 1980.
> >
> > EBCDIC was dominant until 1980? Oh really?
>
> Not surprisingly, Mr Nilges is talking through his nose again. EBCDIC tends
> to be used on machines that use EBCDIC, whereas ASCII tends to be used on
> machines that use ASCII.
Your mastery of tautologies is acknowledged and you need only to brush
up on informal logic, including the reason why an inductive
generalization about space time tradeoffs is NOT refuted by a single
benchmark by a single compiler.
And in fact, IBM mainframes of the 1960s had a bit (bit 12 of the PSW)
that when set on caused the machine to use ASCII.
And in fact, SAS vended an EBCDIC based C compiler for which I had to
write ASCII support for my class in C on the IBM mainframe.
What this means is that your habits of oversimplification,
hypostatization and reification are part of the problem set and not
the solution set.
> No deep shock there, Randy, is there? But one
> sometimes has to make things very simple for Mr Nilges. (In fact, no matter
> how simple you make it, it doesn't always help.)
>
> >> > Programmers don't go out of their way to use keywords as
> >> > identifiers.
> >>
> >> Using Hungarian notation avoids this problem.
> >
> > You really are as clueless as they come. Too funny. Using variable
> > names that don't conflict with language keywords, reserved or not
> > avoids this problem. Starting every variable name with egn_moron_*
> > does the same thing.
>
> This is not guaranteed to remain true. Someone somewhere may be writing a
> language even now that uses... well, who knows?
>
> >> was indeed a problem, because around 1972, IBM mainframes became
> >> available with larger storage sizes as a result of virtual storage.
> >
> > And everyone needed strings longer than 32K, so it was a big problem?
> > You must be joking. Even as late as 2003 you were claiming that your
> > code was designed for strings no longer than 32 BYTES.
>
> And this despite the fact that the code as released in 2002 came with no
> such warnings of arbitrary limitations on string length.
>
>
> >> Therefore in 1976 I developed a set of tools to represent superstrings
> >> as arrays of PL/I strings, and I rescusitated this technology between
> >> 1991 and 1995 before the introduction of Visual Basic 4. Visual Basic
> >> 3 limited strings to 64K.
> >
> > Suddenly you like large strings.
>
> It's not all that sudden. He liked large strings last year, too. The only
> reason for his temporarily falling in love with short strings was that he
> needed a quick "justification" for using a crap algorithm (hey, who cares?
> The strings are only little...)
>
> > You are a fraud. I don't believe you.
> > Let's see an implementation of the EGN superstrings in PL/I. I'd love
> > to see how you did it.
>
> Oh, please. We've already seen his crap VB code and his crap C code. Do you
> /really/ want to see his crap PL/1 code too?
>
> >> I used the software to build a network analysis program for Illinois
> >> Bell in 1980 that used printer graphics to show patterns.
> >
> > And this required the use of string data in excess of 32K? Why?
>
> You believe his claim? Why? :-)
>
> > [...] it's
> > just a wannabe lying his *** off about events he *thought* were too
> > long ago for anyone to know differently.
>
> One thing that constantly surprises me about Usenet is the lengths of the
> memories of some of the regular contributors. People like Nilges forget
> this at their peril (the word "peril" here is used in a metaphorical sense,
> and should not be regarded as a threat to Mr Nilges's personal safety; I
> wouldn't touch Mr Nilges's personal safety with a bargepole).
>
That is in fact a threat.
>
> >> I agree. But C programmers sometimes have trouble with this.
> >
> > I'm still waiting for an application to come along where I really
> > need to be able to store \x00's in a char * apart from the
> > terminator. However, if it did come up, it is easily solvable,
> > except for perhaps sociologists.
>
> Yes, I have in fact solved this (non-existent) "problem" myself. It was
> hardly difficult.
...by grepping str* with mem*? You better call it up and ring, you
better pawn it babe.
Richard, all you've shown is that your indepth knowledge of C is
associated with a deep lack of even computing culture, and an
inability to do informal logic. You've shown yourself to be a typical
example of a non-promotable programmer who's unfit for any role above
programming in a specific language.
But if such people today define "good" programmer, I am proud to be a
"bad" programmer or no programmer at all.
For thirty years I have listened to people make ridiculous arguments
such as your argument that gnu C inlining can refute the mentoring
advice to regard time efficiency as inversely correlated, in
significant cases, with speed.
Who run to their little computer and "prove" that FBI agent Colleen
Rowley doesn't exist because Google cannot find her.
Who have systematically marginalized and pushed out women when the
latter insist on good practice (such as comparing pid_t to a symbolic
constant) IN REAL CODE as opposed to examples of good practice which
somehow never make it into real systems.
Who meet their deadlines by systematically trimming the requirements
to match what they have produced.
I am certain that you are a good person and an intelligent man...and
note that in the logic of the macho system, you cannot at this
juncture say this about me, not because I am evil and stupid (I am
not, save in the sense of Adam's fall) but because you have engaged in
a deliberate campaign, and for you to admit weakness would be the end.
But I am repelled by your conduct which has brought the worst out of
people in this ng. I am repelled by your complete lack of a sense of
humor or proportion.
You might reflect that we probably have quite enough software and that
your skilz are discounted, yet you encourage a false notion in losers
that if they follow your silly rules, they will become
"professionals".
What programming needs is a notion of professionalism that is
completely independent of artifacts such that any programmer of any
Turing complete device is treated equally with all others. Management
doesn't want this, of course, because this REAL programmer's union
(which would not waste its time in xenophobic struggles) would I think
demand that computers be used for human ends and not just Profit.
For this reason, management has an unconscious tendency to set thugs
like you on people like me in the expectation that like so many
posters in the past, I will run crying to alt.support.boo.fucking.hoo.
But I'm old fashioned, and Irish, and I love a fight, especially with
a Limey.
Happy New Year, again. You haven't the grace to return the greeting,
of course.
- Next message: Randy Howard: "Re: Letter to US Sen. Byron Dorgan re unpaid overtime"
- Previous message: JT: "Re: Letter to US Sen. Byron Dorgan re unpaid overtime"
- In reply to: Richard Heathfield: "Re: PL/I string representations"
- Next in thread: Randy Howard: "Re: PL/I string representations"
- Reply: Randy Howard: "Re: PL/I string representations"
- Reply: Richard Heathfield: "Re: PL/I string representations"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]