C as a Platonic pathology

[spinoza1111]

<snip everything that doesn't have anything to do with clc>

Whoa.  Empty post now... hmm.

Can you rephrase your comments, questions, and ideas in terms of
elements of the C language?

Everything has everything to do with everything else: only Platonic
Ideas are isolated from each other. C is a dysfunctional way for
groups of people to agree how to use a computer, following Knuth's
definition of a programming language as a way for humans to agree how
to use a computer, because C is easily turned into a private language.

 

[Tom St Denis]

<snip everything not substantiated with fact or on topic with clc>

Tom

 

[Keith Thompson]

<snip everything not substantiated with fact or on topic with clc>

Tom

So why did you post a followup?

If everyone would stop feeding this particular troll, the S/N ratio of
this newsgroup would increase dramatically, especially for those of us
with working killfiles.

spinoza1111 isn't going to stop insulting people, and he's not going
to become a productive participant.

 

[Tom St Denis]

So why did you post a followup?

If everyone would stop feeding this particular troll, the S/N ratio of
this newsgroup would increase dramatically, especially for those of us
with working killfiles.

spinoza1111 isn't going to stop insulting people, and he's not going
to become a productive participant.

As someone who has seen a fair share of ignored trolls not go away I
have a hypothesis we have to actively ignore him to get the point
across. So replying while snipping his entire posts lets him know
that not only did I see it, and have the time to reply, but I chose
not to, and more so re-iterate the off-topic/trollness of his post.

Tom

 

[spinoza1111]

As someone who has seen a fair share of ignored trolls not go away I
have a hypothesis we have to actively ignore him to get the point
across.  So replying while snipping his entire posts lets him know
that not only did I see it, and have the time to reply, but I chose
not to, and more so re-iterate the off-topic/trollness of his post.

Tom

If you were sincere about this, you would communicate using email.
However, being yourselves oversensitive to criticism, you choose to
let me see your communication, because your purpose is to maliciously
label me with a misused word (see the definition) whose grammar is
isomorphic to anti-semitic texts.

You're in fact off-topic. I believe that C is a Platonism because I
learned and taught C twenty years ago, and have read Plato and taught
philosophy, therefore, I am illuminating your pathetic loyalty to bad
ideas.

You're in fact trolling according to the real definition of trolling.
This is posting to "get a rise" out of others. You want me to "lose
it" and be a "drama queen", so you can label me as Heathfield's butt
buddies labeled Navia. In your subconscious, which replicates barbaric
practise, the labeled one is "the chosen one" who dances "her" self to
death, a legend to which Stravinsky refers to in Le Sacre du
Printemps.

When she dances "her" self to death, this means to the primitive mind
that "he" is NOT the Chosen One despite his deepest fears.

Your goal is that of the member of the lynch mob. Instead of actually
being on-topic, and instead of coding C as I am, you prefer to exhibit
what "real men" you faggots wish you were by scapegoating "drama
queens" and "trolls". The lynch mob member likewise was primarily
interested in showing his community membership by watching a Black
person being murdered, or assisting in the murder.

Many of you creeps are too scared to use this ng properly and answer
newbies or submit code for comment, because this might expose you to
sarcasm and feminize you thereby, transforming you to The Chosen One.

I'm very serious about this. In situations of stress, you become the
sort of people who carry guns to town meetings in the USA. Were I to
give a talk at a professional conference, I'd need armed guards
because I have seen the dull hostility of incompetent programmers
explode into rage.

 

[Tom St Denis]

<snip off topic material>

If you want to discuss things in clc, please remain on topic. If
you're unaware of the CLC charter google for it.

Thanks,
Tom

 

[Keith Thompson]

As someone who has seen a fair share of ignored trolls not go away I
have a hypothesis we have to actively ignore him to get the point
across. So replying while snipping his entire posts lets him know
that not only did I see it, and have the time to reply, but I chose
not to, and more so re-iterate the off-topic/trollness of his post.

Really? I've seen no evidence that that works any better than
silently ignoring them.

For anyone with a killfile, it *doesn't matter* whether spinoza1111
goes away or not. It's unfortunate that several people I'm not
willing to killfile insist on responding to him (and I'm unwilling, at
least for now, to learn how to create a more sophisticated killfile).

 

[spinoza1111]

<snip off topic material>

If you want to discuss things in clc, please remain on topic.  If
you're unaware of the CLC charter google for it.

Being well-informed about something beyond programming, and being able
to construct a proper sentence of length > n, isn't being "off-topic",
although I am well aware that aliteracy is used in organizations as a
reason for ignoring issues.

This newsgroup is dominated by thugs who have access to no other
forums, and their conduct resembles that of a lynch mob.

In the "C Code Adventure", Heathfield is now maintaining the absurd
proposition that a compiler may not generate interpreted code, while
documenting this with a reference that doesn't support his conclusion.

He's doing this because his goal is to destroy the reputation of
Herbert Schildt.

Meanwhile, I'm submitting C code for comment by the occasional decent
person who wanders in here.

 

[spinoza1111]

Really?  I've seen no evidence that that works any better than
silently ignoring them.

For anyone with a killfile, it *doesn't matter* whetherspinoza1111
goes away or not.  It's unfortunate that several people I'm not
willing to killfile insist on responding to him (and I'm unwilling, at
least for now, to learn how to create a more sophisticated killfile).

You keep on yapping about this. Why? Kill my submissions, and shut the
**** up. As it is, your constant posts constitute trolling, since you
make them insincerely and in order to elicit an off-topic reaction.

 

[spinoza1111]

spinoza1111said:



As I said yesterday, ultimately *all* executed code is interpreted,
because the machine is basically a machine code interpreter. The
position I'm maintaining is that compilation is a translation from
one language to another (deferred execution), whereas interpretation
consists of *interpreting* the source program's intent so that it can
be executed immediately.

Go ahead and maintain it. The fact is that several different meanings
co-exist and work very well within different communities when used
honestly to communicate. For example, a programming team may decide to
write an "interpreter" which of necessity for any language with
lexical syntax beyond single characters, and grammar beyond reverse
Polish notation, does "compilation". They then may write a "compiler"
which does the lexical and syntactical work of the first product but
also generates object code.

They will naturally call product A an "interpreter" and product B a
"compiler" although by Aho/Sethi, both products could also, in a
different context, be called "compilers" since both transform source
code to something else.

These networks of what are essentially differences (in the sense of
the linguist de Saussure) are used all the time. The problem is when
some thug insists on one definition for the sake of convenience or
exclusion.

I got onto Usenet pretty late - 1999ish - when Herbert Schildt's
reputation was already mud in C circles. He didn't then, and doesn't
now, have a reputation for me to destroy even if I wanted to. No,
what I want Schildt to do is publish full errata lists for his books
(electronically will do - I'm not suggesting expensive paper
publication), explaining each known bug carefully so that readers of
his works can learn from his mistakes.

Most of his "mistakes" are matters of interpretation and of style, and
as such McGraw Hill's editors decided that they didn't rise to the
level of errata.

And yet you ignore the comments. You were told about malloc.h days
ago, for example.

....I'm sorry, I tune out when incompetent thugs expect me to "listen"
to them. The comment was one of those snarky "everybody knows this"
comments, the writer of which is himself either incompetent or afraid
to explain for fear of some other incompetent thug telling him he's
wrong.

You need to stick strictly to the details of C which you have
apparently swotted and memorized. Please don't lecture me on broader
issues of programming, about which I know far more than you.

 

[spinoza1111]

spinoza1111said:

Most of [Schildt's] "mistakes" are matters of interpretation and of
style, and as such McGraw Hill's editors decided that they didn't
rise to the level of errata.

For that claim ("most") to be correct, Schildt would have had to have
made a very large number of "mistakes" that can sensibly be described
as matters of interpretation and style, because otherwise there is no
way for them to outnumber the technical errors. Please post some
examples of the mistakes to which you refer, taken directly from a
Schildt text.

For each different one you post, I will post at least one technical
error from a Schildt text, thus disproving your claim.

If you don't post any, it is reasonable to assume you know of none and
you're just making it up as you go along.

I predict (for you are very predictable) that you will post no
evidence whatsoever to support your (insupportable) assertion.

To show willing, I'll start, with a diagnosable syntax error on p63 of
"C: The Complete Reference" (1990):

x = 10 / y ~(127/x);

(If a report of this bug can be found in any Schildt-authored online
erratum, I will retract it.)

You're 1 down, so for your "most" claim to be true you're going to
need to find at least two Schildt "mistakes" that are matters of
interpretation and style.

...I'm sorry, I tune out when incompetent thugs expect me to
"listen" to them.

Calling me an incompetent thug doesn't make your code correct.

The comment was one of those snarky "everybody
knows this" comments,

No, it wasn't. It couldn't be, because everyone /doesn't/ know this.
For example, you clearly didn't.

You are treating a mass of trivial details about fuckups as knowledge,
and you want to be respected for a knowledge of unconnected details.

It is one thing to assert this, but quite another to demonstrate it.

I think the demonstration is lost on you. You see, Dijkstra felt that
use of natural language and mastery of its syntax indicated
programming ability, but most programmers believe the reverse: that
great programmers are inarticulate or terse.

 

[spinoza1111]

spinoza1111said:

Most of [Schildt's] "mistakes" are matters of interpretation and of
style, and as such McGraw Hill's editors decided that they didn't
rise to the level of errata.

For that claim ("most") to be correct, Schildt would have had to have
made a very large number of "mistakes" that can sensibly be described
as matters of interpretation and style, because otherwise there is no
way for them to outnumber the technical errors. Please post some
examples of the mistakes to which you refer, taken directly from a
Schildt text.

For each different one you post, I will post at least one technical
error from a Schildt text, thus disproving your claim.

If you don't post any, it is reasonable to assume you know of none and
you're just making it up as you go along.

I predict (for you are very predictable) that you will post no
evidence whatsoever to support your (insupportable) assertion.

To show willing, I'll start, with a diagnosable syntax error on p63 of
"C: The Complete Reference" (1990):

x = 10 / y ~(127/x);

Looks like a typo to me. Typographical errors appear in most computer
and other books. Your purpose is to destroy Schildt's sales to promote
your book.

Aho/Sethi are arguably wrong about compilers on p 4 of the Dragon
book.

An "error" would be a mistake that affects the entire book. Your
"errors" are typographical errors and artifacts, not of Schildt's
incompetence, but of the exagerrated status of C, itself an infantile
disorder imposed on competent people that destroys their
competence...as is so evident, here.

The point is that in a variety of fields, as diverse as religion and
programming, incompetent thugs turn Fundamentalist, and lose all
ability to make distinctions of importance, so as to destroy better
people than they.

 

[Dennis \(Icarus\)]

Looks like a typo to me. Typographical errors appear in most computer
and other books. Your purpose is to destroy Schildt's sales to promote

Enough such "typos" indicates negligence by the author, the publisher, or
both.

Aho/Sethi are arguably wrong about compilers on p 4 of the Dragon
book.

<snip>
You mean where they say "Traditionally we think of a compiler as a program
that tanslates a source language such as Fortran into assembly or machine
language of some computer"?

They mention query interpreters, text formatters, and silicon compilers as
using compiler technology.

Now, on pg 3, they mention that interpeters do not create a target programas
being a distinguishing characteristic from compilers. You're free to
disagree, of course.

My edition was published in 1986.

Dennis

 

[spinoza1111]

Enough such "typos" indicates negligence by the author, the publisher, or
both.

Possibly. Still, it's important in law to demonstrate intent in cases
of negligence, and the anti-Schildt creeps are charging negligence
without establishing intent. If they cannot prove intent, and because
they act with malice, any global claims they make about Schildt's
competence become criminal libels, made with intent to destroy his
livelihood.

Heathfield's only published one typo if that is what it is.

Fourteen year old boys are fundamentalists, teasing kids who stumble
over words or "get it wrong". Most adults grow out of this and look at
a person holistically, but because C has created a generation of
Dijkstra's "coding bums" (men able to get high paying jobs without
accomplishing the tasks of transition to adulthood), many C
programmers remain stuck at the level of 14 year olds.

This is one of the most pernicious effects of C's poor design. Because
it was designed in such a slapdash manner, it spawned an abiding
aftermarket in a "knowledge" that is more secrets than real knowledge.

This allowed a generation of men to evade the tasks of growing up
because they could get jobs as C programmers, and employers overlooked
their defective character.

<snip>
You mean where they say "Traditionally we think of a compiler as a program
that tanslates a source language such as Fortran into assembly or machine
language of some computer"?

They mention query interpreters, text formatters, and silicon compilers as
using compiler technology.

Now, on pg 3, they mention that interpeters do not create a target programas
being a distinguishing characteristic from compilers. You're free to
disagree, of course.

It appears you know very little about compiler internals. Were you to
have worked inside a compiler you would know that in actuality, a
program ordinarily called an "interpreter" by its users will in all
cases (save the case I mentioned of Mouse, a language using characters
in reverse Polish that literally needed neither lexical nor
syntactical analysis) produce *** an intermediate representation ***.
This *** intermediate representation *** might be a file, or a data
structure in memory, or it might even be single messages passed from a
compiler coroutine to the interpretive coroutine, but in all case the
"interpreter" does "compilation".

It also appears that you are yet another Fundamentalist who believes
along with St Augustine (cf Wittgenstein, Philosophical
Investigations) that words are bricks, that words are things, and that
there is, or even should be, a simple isomorphism between language and
reality. The alternative to this primitive view appears to be for you,
chaos and Ragnarok and meaninglessness, just as friend Ben Bacarisse
refused to accept the chaotic truth of C: that it is, as C, so
redefinable as to constitute a bad programming language.

Words are de Saussure's system of differences in Wittgenstein's
language game. Here, the "language game" is "get Schildt".

 

[spinoza1111]

spinoza1111said:

Most of [Schildt's] "mistakes" are matters of interpretation and of
style, and as such McGraw Hill's editors decided that they didn't
rise to the level of errata.

For that claim ("most") to be correct, Schildt would have had to have
made a very large number of "mistakes" that can sensibly be described
as matters of interpretation and style, because otherwise there is no
way for them to outnumber the technical errors. Please post some
examples of the mistakes to which you refer, taken directly from a
Schildt text.

For each different one you post, I will post at least one technical
error from a Schildt text, thus disproving your claim.

If you don't post any, it is reasonable to assume you know of none and
you're just making it up as you go along.

I predict (for you are very predictable) that you will post no
evidence whatsoever to support your (insupportable) assertion.

To show willing, I'll start, with a diagnosable syntax error on p63 of
"C: The Complete Reference" (1990):

x = 10 / y ~(127/x);

(If a report of this bug can be found in any Schildt-authored online
erratum, I will retract it.)

You're 1 down, so for your "most" claim to be true you're going to
need to find at least two Schildt "mistakes" that are matters of
interpretation and style.

...I'm sorry, I tune out when incompetent thugs expect me to
"listen" to them.

Calling me an incompetent thug doesn't make your code correct.

The comment was one of those snarky "everybody
knows this" comments,

No, it wasn't. It couldn't be, because everyone /doesn't/ know this.
For example, you clearly didn't.

the writer of which is himself either
incompetent or afraid to explain for fear of some other incompetent
thug telling him he's wrong.

You need to stick strictly to the details of C which you have
apparently swotted and memorized. Please don't lecture me on broader
issues of programming, about which I know far more than you.

It is one thing to assert this, but quite another to demonstrate it.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
This line unintentionally left unblank

OK, jerk face, I do seem to recall that one's supposed to quote and
not bracket malloc.h. Explain WHY in response to this post, because I
forget horseshit rules that derive from poor language design.

You actually believe that secrets are knowledge, and this means you're
a thug and a barbarian. But you are a useful idiot savant because
you've swotted the secrets. So tell us, slave, why malloc must be
quoted when included if that is the case.

When Priests are more in word, then matter;
When Brewers marre their Malt with water;
When Nobles are their Taylors Tutors,
No Heretiques burn'd, but wenches Sutors;
When euery Case in Law, is right;
No Squire in debt, nor no poore Knight;
When Slanders do not liue in Tongues;
Nor Cut-purses come not to throngs;
When Vsurers tell their Gold i'th' Field,
And Baudes, and whores, do Churches build,
Then shal the Realme of Albion, come to great confusion:
Then comes the time, who liues to see't,
That going shalbe vs'd with feet.
This prophecie Merlin shall make, for I liue before his time.

Shakespeare, King Lear

 

[Beej Jorgensen]

I do seem to recall that one's supposed to quote and not bracket
malloc.h. Explain WHY in response to this post

comp.lang.c FAQ list · Question 10.8a

Q: What's the difference between #include <> and #include "" ?

http://c-faq.com/cpp/inclkinds.html

-Beej

 

[Chris McDonald]

Possibly. Still, it's important in law to demonstrate intent in cases
of negligence, and the anti-Schildt creeps are charging negligence
without establishing intent. If they cannot prove intent, and because
they act with malice, any global claims they make about Schildt's
competence become criminal libels, made with intent to destroy his
livelihood.

This may all be true "in law", but you are the only one threatening
international law suits. No-one else has "charged" negligence; people
have simply, clearly, and repeatedly demonstrated unprofessional
carelessness by Schildt and his publisher.

In common practice, the same common practice that you promote so
loudly when discussing the way actual programming occurs, it's a
simple matter to be negligent without having an intent to be negligent.
It's termed carelessness and, if being performed in an environemnt where
professionalism is required, then it demonstrates a likely unprofessional
approach to the task.

To make errors, receive genuine criticisms, and to not correct those
errors is further demonstration of that unprofessionalism. And to then
make your livelihood based on those uncorrected errors.... ??

(so sue me too)

 

[spinoza1111]

Enough such "typos" indicates negligence by the author, the publisher, or
both.




<snip>
You mean where they say "Traditionally we think of a compiler as a program
that tanslates a source language such as Fortran into assembly or machine
language of some computer"?

You missed "traditionally" unless like Tevye you like tradition.

Look, when I was writing "Build Your Own .Net Language and
Compiler" (Apress 2004) and very close to homelessness as a result of
this effort, not working full time in software, I'd intended to do
full .Net MSIL generation. I had to jettison this goal in order to
meet my committment to Apress and wound up generating my own "Nutty
Professor" bytecode for my own "Nutty Professor" paper machine.

A few reviewers claimed I was being dishonest because all I had about
object code generation was a small example which I presented and
discussed.

The problem was that at the time (the early days of .Net in 2004) the
process was complicated and drew attention from the key skills, IMO,
of compiler development, which are in the front end, since if you mess
the front end up there's no point in having a backend at all.

It is true that the real "cutting edge" of compiler development is in
code generation and optimization, and I even included some basic
optimization, but my purpose was above all the same as Herb Schildt's:
to get people started. Quite a lot of people found my book to meet a
need for a "getting started" or "for dummies" (pour les nuls)
approach...the book has been in the top ten of Amazon's books about
compilers.

I'm in the same situation as Schildt, and Java author Kathy Sierra. If
one writes in an engaging, witty or even just readable way, one's work
is subject to multiple interpretations, for human language isn't
computer language. This attracts the scorn of people who can't write
and who have become self-appointed *mullahs*, *ayatollahs*, and
*imams* of a blasphemous technological religion which has reversed
enlightenment. One's book becomes their hated Satanic Verses, like
Salman Rushdie's, and from their *madrassahs* they issue calls for
*jihad* to their students, their *taliban*, claiming that one has
polluted the crystal truth of their secular *qu'ran*.

They are Sadducees, they are Pharisees, they are hypocrites. Behold
them as they walk through the market: behold them as they walk through
Jardine's Crescent, for lo! their wives in full *hijab* follow them in
the noonday sun near the noonday gun, whilst they violate the
Prophet's rules for male attire, with hair on chest and naked legs.
For hypocrisy is common to these men and those who would have us
worship the god they've made of C. With beams in their eyes they would
remove motes.

[I'm gonna get mediaeval on your ass]

The only reason my book hasn't been attacked in detail is that the
*mullahs* are too indolent to learn VB.

 

[spinoza1111]

comp.lang.c FAQ list · Question 10.8a

Q: What's the difference between #include <> and #include "" ?

http://c-faq.com/cpp/inclkinds.html

-Beej

Just as I thought! You can't explain it inline! Instead you point to
this, which is incredibly poorly written, nearly incoherent garbage:

"For example, if you're working on a large, multi-person project, and
if there are central directories where the official or at least main-
line development versions of source and header files reside, and
individual ``playpen'' directories where each team member works with
files prior to checking them back in to the main source tree, and if
header files can #include other header files, and if you've just
checked out a header file into your own ``playpen'' include directory,
modified it, and then recompiled, only to have your changes not take
effect, it's likely that the header file you modified is included,
using double quotes, by another header file, and that other header
file exists only in the central include directory, so that when any
other source file included that other header, the preprocessor
retrieved the mainstream, unmodified version of that header, from the
same ``current'' mainstream include directory, rather than the one you
just modified. In this case, you may have to check out a copy of that
other header file, too, even though you have no need to modify it,
just so it will be sitting in your private include directory, for
other inclusions to find first and so that the secondary header file
it includes will be your modified copy."

 

[Ben Bacarisse]

Just as I thought! You can't explain it inline!

It is not clear what your question is. If you have a question about
"" vs <> I'd have a go at answering it, but I don't think this has much
to do with malloc.h

I am pretty certain that the comment you would have received about
malloc.h is that it is a non-standard header and that it is better not
to use it at all. malloc is defined in stdlib.h and has been for
about 20 years (i.e. this is not a new change in C99).

In old, pre-standard, C there were lots of different headers floating
around and no two compilers seemed to agree about them. One of the
huge benefits of the first language standard was that all that was
sorted out.

<snip>