http://www.cs.bell-labs.com/~dmr/primevalC.html
Dennis
DECtapes are highly platform specific, and are not covered by ANSI C, which
is the subject of this newsgroup (comp.lang.c). Try a DEC-related
newsgroup.
If you want us to comment on your source code, please post it in the body
of your email.
What was your C question?
--
Richard Heathfield
The bug stops here.
nasaldemon: "Richard, they won't get it. They won't understand. You're
gonna be shot down in flames for this one, big-time."
Richard: "I know. It's one of those do-it-and-damn-the-consequences days."
Wow.
Dennis Ritchie posts something.
And all he gets is a standard move-your-ass-to-the-right-group-reply.
> If you want us to comment on your source code, please post it in the body
> of your email.
>
> What was your C question?
hahahhahahahah.
YHBT. What I really wonder is whether these birds will be able to work
under v5 (tweaking into the state when v5 cc will take them, then feeding
the original variant to the result)...
--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid. Get yourself a better computer" - Dilbert.
>Dennis Ritchie <d...@bell-labs.com> wrote in article
><379FE9...@bell-labs.com>...
>> I finally prepared another fossil for museum exhibition: from DECtapes
>> written
>> in 1972-73, there are exhumed C compilers (including source) to show
>> what
>> the very early stages of the language were like. This was a highly
>> transitional stage; for example, the earlier one anticipates a "long"
>> type, but doesn't have struct; the 6-months-later compiler implements
>> struct, but reuses long's slot in the type table.
>>
>> http://www.cs.bell-labs.com/~dmr/primevalC.html
>> Dennis
>DECtapes are highly platform specific, and are not covered by ANSI C, which
>is the subject of this newsgroup (comp.lang.c). Try a DEC-related
>newsgroup.
>If you want us to comment on your source code, please post it in the body
>of your email.
>What was your C question?
>Richard Heathfield
>The bug stops here.
>nasaldemon: "Richard, they won't get it. They won't understand. You're
>gonna be shot down in flames for this one, big-time."
>Richard: "I know. It's one of those do-it-and-damn-the-consequences days."
I guess this might have been an attempt at humour. <pttt..bahh> you
lose ;-)
Were you around when K&R happened, or still playing trains? This was a
cheap shot at a computing great IMHO. The whole point about a standard
is the decision process that makes it a standard - in this respect the
early origins of the C language _are_ of relevance to the current
incarnation. What could be more relevant to comp.lang.c than a posting
by one of the languages creators about the process of designing it?
Richard Heathfield
The humour stops here.
analdemon: "Richard, they don't get it. They don't understand. You're
gonna be shot down in flames for this one, big-time."
except hopefully we're too mature for that. :-)
regards John B.
Er, well, it *was* a joke, wasn't it? I mean, did you see the signature?
--
Mark Brader Twas unix and the C++
Toronto Did compile and load upon the vax:
msbr...@interlog.com All Ritchie was the Kernighan,
And Lisp ran in GNU EMACS.
--Larry Colen (after Lewis Carroll)
My text in this article is in the public domain.
Yes, but maybe it was not Richard Heathfield with the smart-ass-answer, maybe it
was Brian Kernighan, pulling Dennis Ritchie's leg :-)
Although I have to admit that "What was you C question?" made laugh hysterically.
M.
--
Manuel Borowski
VJ63
Alcatel
Antwerp Belgium
tel : +32 3 240 7978
Mailto:emmanuel...@alcatel.be
Richard Heathfield wrote:
>
> Dennis Ritchie <d...@bell-labs.com> wrote in article
> <379FE9...@bell-labs.com>...
> > I finally prepared another fossil for museum exhibition: from DECtapes
> > written
> > in 1972-73, there are exhumed C compilers (including source) to show
> > what
> > the very early stages of the language were like. This was a highly
> > transitional stage; for example, the earlier one anticipates a "long"
> > type, but doesn't have struct; the 6-months-later compiler implements
> > struct, but reuses long's slot in the type table.
> >
> > http://www.cs.bell-labs.com/~dmr/primevalC.html
> >
> > Dennis
> >
>
> DECtapes are highly platform specific, and are not covered by ANSI C, which
> is the subject of this newsgroup (comp.lang.c). Try a DEC-related
> newsgroup.
>
> If you want us to comment on your source code, please post it in the body
> of your email.
>
> What was your C question?
>
> --
On Thu, 29 Jul 1999 11:08:59 +0200, Manuel Borowski VJ63
<boro...@sh.bel.alcatel.be> wrote:
>Alexander Bartolich wrote:
>>
>> > DECtapes are highly platform specific, and are not covered by ANSI C, which
>> > is the subject of this newsgroup (comp.lang.c). Try a DEC-related
>> > newsgroup.
>>
>> Wow.
>>
>> Dennis Ritchie posts something.
>> And all he gets is a standard move-your-ass-to-the-right-group-reply.
>>
>> > If you want us to comment on your source code, please post it in the body
>> > of your email.
>> >
>> > What was your C question?
>>
>> hahahhahahahah.
>
>Yes, but maybe it was not Richard Heathfield with the smart-ass-answer, maybe it
>was Brian Kernighan, pulling Dennis Ritchie's leg :-)
>Although I have to admit that "What was you C question?" made laugh hysterically.
>
>M.
>
>--
>
>Manuel Borowski
>VJ63
>Alcatel
>Antwerp Belgium
>tel : +32 3 240 7978
>Mailto:emmanuel...@alcatel.be
Lew Pitcher
System Consultant, Development Services
Toronto Dominion Bank
(Opinions expressed are my own, not my employers')
>>Dennis Ritchie <d...@bell-labs.com> wrote in article
>><379FE9...@bell-labs.com>...
>>> I finally prepared another fossil for museum exhibition: from DECtapes
>>> written in 1972-73, ...
> Were you around when K&R happened, or still playing trains?
The time period 1972-1973 puts this right around the time I first heard of
C. Sadly, I didn't go to Ritchie's talk. I was too busy hacking a shell
(we didn't call it that) for the DDP 516 in room 2D 518 at Murray Hill, so
all I heard was my boss's comments on the talk. He said it was really
interesting. He told me about this neat language called C, a modified
BCPL, that some people upstairs were working on (upstairs was where the
UNIX group worked), and the thing that seems to have impressed him the
most was the idea of adding explicit macros to a high level language.
I only looked briefly at the code Ritchie posted, so I didn't notice if
the macro preprocessor was part of the language yet, or just something that
was presented as an idea at the talk. This would have been in the summer
of 1973, by the way.
Doug Jones
jo...@cs.uiowa.edu
> The time period 1972-1973 puts this right around the time I first heard of
> C. Sadly, I didn't go to Ritchie's talk. I was too busy hacking a shell
> (we didn't call it that) for the DDP 516 in room 2D 518 at Murray Hill, so
> all I heard was my boss's comments on the talk. He said it was really
> interesting. He told me about this neat language called C, a modified
> BCPL, that some people upstairs were working on (upstairs was where the
> UNIX group worked), and the thing that seems to have impressed him the
> most was the idea of adding explicit macros to a high level language.
>
> I only looked briefly at the code Ritchie posted, so I didn't notice if
> the macro preprocessor was part of the language yet, or just something that
> was presented as an idea at the talk. This would have been in the summer
> of 1973, by the way.
<ot><nostalgia>
I was in D/71K at IBM East Fishkill helping to develop firmware drivers for four new
products: Igar (an "absurd" disk drive that used an 8" circle of tape in a plastic envelope
instead of a rigid platter), Gulliver (a tiny sealed disk drive from the Hursley Labs that
held an unheard-of 60 megabytes), Lynx (a compact 600 lpm printer that used something
resembling an embossed band saw blade), and IBM's first SDLC adapter. I'd have given almost
anything for an (even primeval) C compiler!
</nostalgia></ot>
Morris Dovey
West Des Moines, Iowa USA
mrd...@iedu.org
>> DECtapes are highly platform specific, and are not covered by ANSI C, which
>> is the subject of this newsgroup (comp.lang.c). Try a DEC-related
>> newsgroup.
>
>Wow.
>
>Dennis Ritchie posts something.
>And all he gets is a standard move-your-ass-to-the-right-group-reply.
You apparently failed to read the whole of Richard's reply.
>> If you want us to comment on your source code, please post it in the body
>> of your email.
>>
>> What was your C question?
>
>hahahhahahahah.
Sometimes plastering :-)'s everywhere just spoils the effect.
--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------
Greetings!
Volker
Some may not have seen the clear humorous intent, or may have wondered if it
was all that clear, but I'll bet Dennis Ritchie wasn't among them.
--
Paul Lutus
www.arachnoid.com
John Birch <jo...@invision.co.uk> wrote in message
news:37a01776...@news.demon.co.uk...
> On 29 Jul 1999 09:28:45 +0100, "Richard Heathfield"
> <comp...@eton.powernet.co.uk> wrote:
>
> >Dennis Ritchie <d...@bell-labs.com> wrote in article
> ><379FE9...@bell-labs.com>...
> >> I finally prepared another fossil for museum exhibition: from DECtapes
> >> written
> >> in 1972-73, there are exhumed C compilers (including source) to show
> >> what
> >> the very early stages of the language were like. This was a highly
> >> transitional stage; for example, the earlier one anticipates a "long"
> >> type, but doesn't have struct; the 6-months-later compiler implements
> >> struct, but reuses long's slot in the type table.
> >>
> >> http://www.cs.bell-labs.com/~dmr/primevalC.html
>
> >> Dennis
>
> >DECtapes are highly platform specific, and are not covered by ANSI C,
which
> >is the subject of this newsgroup (comp.lang.c). Try a DEC-related
> >newsgroup.
>
> >If you want us to comment on your source code, please post it in the body
> >of your email.
>
> >What was your C question?
>
> >Richard Heathfield
>
> >The bug stops here.
>
> >nasaldemon: "Richard, they won't get it. They won't understand. You're
> >gonna be shot down in flames for this one, big-time."
>
> >Richard: "I know. It's one of those do-it-and-damn-the-consequences
days."
>
> I guess this might have been an attempt at humour. <pttt..bahh> you
> lose ;-)
>
> Were you around when K&R happened, or still playing trains? This was a
> cheap shot at a computing great IMHO. The whole point about a standard
> is the decision process that makes it a standard - in this respect the
> early origins of the C language _are_ of relevance to the current
> incarnation. What could be more relevant to comp.lang.c than a posting
> by one of the languages creators about the process of designing it?
>
> Richard Heathfield
>
> The humour stops here.
>
> analdemon: "Richard, they don't get it. They don't understand. You're
> gonna be shot down in flames for this one, big-time."
>
I'm trying to think how I might've done better. Maybe criticizing
the code style and quoting some passages from K&R to him? Telling
him to go read K&R and come back when he understands the basics?
From the simple fact that several folks *didn't* get the implied
:-), I think you've been entirely successful, though!
Tim.
If this is *the* Dennis Ritchie then this is *the* most funniest thing I've
seen in ages :-)
Rob.
Richard Heathfield wrote:
I am posting the reply at the top in violation of usenet norms simply
because I don't know where to break in and EOM seems a long way for
people to page down. Dennis Ritchie posted a nice announcement of
additions to the C museum, to which Richard Heathfield posted a Paul
Lutus-like reply.
Richard, there are people who who will not recognize the tongue-in-cheek
nature of your posting. I know that's hard to believe, but it's true.
You simply have to decorate these things with smileys. It is not that
people are necessarily humor-impaired, although that is possible. There
are plenty of newer people who simply don'y know who either Dennis
Ritchie or Richard Heathfield are. To them, instead of humor, they see
a post from a real pain in the butt.
>
> Dennis Ritchie <d...@bell-labs.com> wrote in article
> <379FE9...@bell-labs.com>...
> > I finally prepared another fossil for museum exhibition: from DECtapes
> > written
> > in 1972-73, there are exhumed C compilers (including source) to show
> > what
> > the very early stages of the language were like. This was a highly
> > transitional stage; for example, the earlier one anticipates a "long"
> > type, but doesn't have struct; the 6-months-later compiler implements
> > struct, but reuses long's slot in the type table.
> >
> > http://www.cs.bell-labs.com/~dmr/primevalC.html
> >
> > Dennis
> >
>
> DECtapes are highly platform specific, and are not covered by ANSI C, which
> is the subject of this newsgroup (comp.lang.c). Try a DEC-related
> newsgroup.
>
> If you want us to comment on your source code, please post it in the body
> of your email.
>
> What was your C question?
--
Martin Ambuhl mam...@earthlink.net
__________________________________________________________
Fight spam now!
Get your free anti-spam service: http://www.brightmail.com
I think this was a beautiful experiment. While I agree that dmr's post
was clearly topical, I think most of the flames the Richard got for his
effort were misdirected.
There's nothing wrong with flaming Dennis Ritchie, if he gets confused and
posts in the wrong group.
The argument against the "flame" Richard posted shouldn't be "how dare you
flame dmr". It should be "the evolution of the language is important to
understanding the standard and how it got here".
Even dmr can post off-topic, even in a C newsgroup. He didn't this time, but
the knee-jerk defenses are sort of silly. (For that matter, isn't it fairly
obvious that, if it came down to it, he could defend himself plenty well?)
-s
--
Copyright 1999, All rights reserved. Peter Seebach / se...@plethora.net
C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon!
Will work for interesting hardware. http://www.plethora.net/~seebs/
Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!
Yeah, but do you think he actually *reads* this newsgroup? I suspect that he
just dropped off the notification. The only way he will read it is if some day
later he by chance a Deja News search on his name.
The reply was clearly intended for us, not for Mr. Ritchie. :)
Wow, Bell Labs embraces Open Source. :) :)
I have to comment that IS a heck of a lot better than SCO's move, whose
lawyers came up with the brilliant idea---in response to a net petition
initiative to open up the source to V7 UNIX---to not only impose a hundred
dollar licensing fee upon people who want a copy of the source code, but to
also restrict licensees to sharing modifications only with other licensees.
Last I heard, anyway. Shockingly incredible.
I agree. He undoubtedly has better things to do than note the reactions to
his occasional post.
--
Paul Lutus
www.arachnoid.com
Kaz Kylheku <k...@ashi.FootPrints.net> wrote in message
news:slrn7q1bm...@ashi.FootPrints.net...
Indeed.
I have a new sig block. I am rather foolishly proud of it, for a reason
which I'll leave you to guess. (It shouldn't be too difficult.)
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
Oh, no -- a "Paul Lutus-like reply?" I'm clearly in pretty deep doo-doo when
a type of reply gets named after me. Hopefully it means a tongue-in-cheek
mock-hostile reply, rather than the obvious alternative. :)
--
Paul Lutus
www.arachnoid.com
Martin Ambuhl <mam...@earthlink.net> wrote in message
news:37A0A54E...@earthlink.net...
>
>
> Richard Heathfield wrote:
>
> I am posting the reply at the top in violation of usenet norms simply
> because I don't know where to break in and EOM seems a long way for
> people to page down. Dennis Ritchie posted a nice announcement of
> additions to the C museum, to which Richard Heathfield posted a Paul
> Lutus-like reply.
>
> Richard, there are people who who will not recognize the tongue-in-cheek
> nature of your posting. I know that's hard to believe, but it's true.
> You simply have to decorate these things with smileys. It is not that
> people are necessarily humor-impaired, although that is possible. There
> are plenty of newer people who simply don'y know who either Dennis
> Ritchie or Richard Heathfield are. To them, instead of humor, they see
> a post from a real pain in the butt.
>
>
> >
> > Dennis Ritchie <d...@bell-labs.com> wrote in article
> > <379FE9...@bell-labs.com>...
> > > I finally prepared another fossil for museum exhibition: from DECtapes
> > > written
> > > in 1972-73, there are exhumed C compilers (including source) to show
> > > what
> > > the very early stages of the language were like. This was a highly
> > > transitional stage; for example, the earlier one anticipates a "long"
> > > type, but doesn't have struct; the 6-months-later compiler implements
> > > struct, but reuses long's slot in the type table.
> > >
If "this newsgroup" is comp.std.c, he has certainly appeared to read it in
the past.
Part of the issue here is that the whole thread has been crossposted. I
thought that Richard's article was very funny and not really open to
misinterpretation -- in comp.lang.c. In the other groups the situation may
have been less clear.
It's a shame that we have pretty much ignored the original subject of this
thread. I haven't yet had time to look beyond the introductory notes on the
web page, but I'm interested in the evolution of programming languages and
I'm looking forward to delving deeper. If DMR *is* reading, I'd like to
thank him for taking the time to make this -- and his other historical
materials -- available to us all.
Through Sixth Edition UNIX, the C preprocessor was a separate program
(written by Reiser). At some point the "cc" compiler driver was
written, and it looked at the first character of the source file to
see whether it was '#'. If so, the source file was passed through cpp
before it reached c0 (compiler proper, first pass). That explains why
so many UNIX C source files had "#" for their first line.
Seconded
Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
Over the years it has been very apparent that while, 1) dmr does
not read this group on a regular basis, 2) he definitely is made
aware of threads where his particular attention would be of
historic value, and 3) he does read the follow-ups to articles
that he posts and sometimes will even provide further
enlightenment.
The chances he has not been chuckling over this thread are none.
This is the first time to my knowledge that anyone has spoofed a
"flame" at dmr; however, it is not the first time that several
people have run off the deep end because of responses that were
thought to be flames. I do not recall exactly the person
involved, or even the exact subject, but maybe 8-9 years ago in
a thread relating to the way C handles strings Dennis posted an
article relating to zero terminated strings and BCPL compared to
C, which was immediately corrected by another poster who said
Dennis was mistaken.
That brought at least one response from a person who came a bit
unglued at the idea someone would have the brass to tell Dennis
Ritchie he was wrong. It went something like "Who are YOU to
tell *Dennis Ritchie* how it was!". Dennis, in his typical
deadpan style with no appearance of any nonsense at all, replied
to that article and pointed out that indeed he had remembered it
wrong, and indeed the person who corrected him out was as well
qualified as he was to know how it had been done originally.
(The poor fellow who let loose with the "Who are you..." was
embarrassed, but also very gracious in his apology.)
Hence comedy based on Dennis Ritchie's comp.lang.c articles is
very rare indeed, but not unheard of before Richard Heathfield's
worthy attempt. (Perhaps his is the first _intentional_ effort
though... :-)
Floyd
--
Floyd L. Davidson fl...@barrow.com
Ukpeagvik (Barrow, Alaska)
He said that the code was *TAKEN OFF OF* DEC tapes, *not* that
what he was making available currently resided on them. This is a
non-problem, and your mention of it a non-sequitir.
>If you want us to comment on your source code, please post it in the body
>of your email.
>
Funny. Last time *I* did something like that, I was told by one of the
*regulars*
to *put it on a web site and post the URL.* That's what Mr. Ritchie did.
I've
checked. It's there.
>What was your C question?
>
There was an implied question:
*Is this old C code currently still useful?*
Unfortunately, I doubt that any single person alive can
satisfactorily answer that question.
>--
>Richard Heathfield
>
>The bug stops here.
>
>
>
>On Thu, 29 Jul 1999 10:18:18 -0700, Paul Lutus <nos...@nosite.com> wrote:
>><< This was a cheap shot at a computing great IMHO. >>
>>
>>Some may not have seen the clear humorous intent, or may have wondered if it
>>was all that clear, but I'll bet Dennis Ritchie wasn't among them.
>
>Yeah, but do you think he actually *reads* this newsgroup?
Which newsgroup? This thread is cross-posted.
I think Dennis Ritchie does read comp.std.c, at least occaisionally;
he has been posting a few articles there recently. Check DejaNews.
--
Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger f...@128.250.37.3 | -- the last words of T. S. Garp.
Thanks for the historic link, which has now been added to
http://www.geocities.com/Athens/Agora/7256/c.html A C FAQ for
promoting the creation of public domain artificial intelligence (Mindix?)
as exemplified by the 19.Jul.1999 release of downloadable
http://www.geocities.com/Athens/Agora/7256/mind-fpc.html Mind.Forth AI.
> Dennis
>Part of the issue here is that the whole thread has been crossposted. I
>thought that Richard's article was very funny and not really open to
>misinterpretation -- in comp.lang.c. In the other groups the situation may
>have been less clear.
Being a DECtape-owning fossil myself who has never subscribed to the
the .c groups (well, maybe did for a week 10 years ago) I admit to
being impressed with what an idiot this Heathfield character was.
However, being a fossil who's be around USENET too long, I checked
him out on Deja news and concluded he means well in most postings.
I even checked dmr's WWW page to see if there were binary dumps of
the DECtapes.
I concluded it was likely plenty of feet would be in mouths in the posts
I had not yet read.
>It's a shame that we have pretty much ignored the original subject of this
>thread.
Indeed, DECtapes were wonderful devices and astoundingly reliable. Many
other media would have lost that old code. More folks in comp.*.c should
take the time to learns about DECtapes, PDP-11s, and especially PDP-10s.
-Ric Werme
--
Ric Werme | http://people.ne.mediaone.net/werme
we...@nospam.mediaone.net | http://www.cyberportal.net/werme
^^^^^^^ delete
What's incredible is that anyone would think that a corporation
shouldn't care about protecting its intellectual property (even
if acquired from some other original developer). The $100 fee
just about covers their costs in handling your application.
An interesting archeological experiment would be to try those algorithms
on modermn ansii standard C compiler syntax.
I think the reasons those old algorithms may be superior are:
1) Computer Science was part of traditional science and Bell Labs
people used and believed in scientific method. This changed in
late 1970's and early 80';s EE departments took over traditional
(in Literate and Science schools) Computer Science departments
where evaluation became manufacturability,
2) a result of moving Computer Science to EE departments
is that evaluation and promotion has become tied to efficiency of
working with industry (cronyism?).
Just my two cents.
/Steve
--
Steve Meyer Phone: (415) 296-7017
Pragmatic C Software Corp. Fax: (415) 296-0946
220 Montgomery St., Suite 925 email: sjm...@crl.com
San Francisco, CA 94104
It would take far less than $100 for someone to make a tarball and put it on
some server somewhere. It's not the fee that I specifically object to, but
the silly licensing restrictions.
The stuff is old, and the V6 sources were already published in a book. And
it's not even comparable to modern freeware operating systems; there is
obviously no strategic advantage in hanging on to this particular bit of
intellectual property.
I believe that the move on the part of SCO was strictly a ploy to discourage
the interested users: a mere bureaucratic run-around concocted by people who
don't really understand or care why anyone would be interested in the old
stuff, and don't want to take any real initiative on their behalf.
[ Okay, time to set followups to alt.folklore.computers, I think. ]
I think he does read it; he makes contributions fairly frequently.
So? It's widely documented that "wizards" have mystical powers and the
"second sight". I have always assumed he merely posts "appropriate" responses
based on hunches about what people are talking about. In some cases, he
inserts cleverly forged "References:" headers to make it look like part of a
thread.
Anyway, this one's not the "real" Dennis Ritchie; after the Bell
Labs/Lucent/AT&T breakup, Dennis ended up working for all three of them, so
you should immediately distrust anyone with an address that looks like
he works for only one. It's actually
d...@research.att.com
m...@bell-labs.com
r...@research.lucent.com
but the therapy is coming along nicely.
>> ... from DECtapes written in 1972-73, there are exhumed C compilers
>> (including source) to show what the very early stages of the language were
>> like.
Cool! Some historical background for the ANSI people to see how their standard
was developed!
On 29 Jul 1999, Richard wrote:
>DECtapes are highly platform specific, and are not covered by ANSI C, which
>is the subject of this newsgroup (comp.lang.c). Try a DEC-related
>newsgroup.
Great troll, Richard! Considering this is one of the guys who practically
WROTE the language, I'd say his source code would be well worth studying.
--
/| _,.:*^*:., |\ Cheers from the Viking family, including Marmalade
| |_/' viking@ `\_| | Running Linux and OpenDOS in Christchurch!
| flying-brick | $FunnyMail Bilbo : Now far ahead the Road has gone,
\_.caverock.net.nz_/ 5.39 in LOTR : Let others follow it who can!
> Richard, there are people who who will not recognize the tongue-in-cheek
> nature of your posting.
I (should) find it enormously hard to believe that *anyone* who read
Richard's post *completely* wouldn't see that it was a joke. Even
without
knowing who Richard "is" (I don't).
> You simply have to decorate these things with smileys.
If he had done that, it would not have been funny.
(Yes, I thought it was funny. Not hilarious; just funny. I know who dmr
is.
I know what a nasal demon is. Perhaps it's not funny if you don't.)
--
Chris "with a *machine*!" Dollin
>I finally prepared another fossil for museum exhibition: from DECtapes
>written
>in 1972-73, there are exhumed C compilers (including source) to show
>what
>the very early stages of the language were like. This was a highly
>transitional stage; for example, the earlier one anticipates a "long"
>type, but doesn't have struct; the 6-months-later compiler implements
>struct, but reuses long's slot in the type table.
>
> http://www.cs.bell-labs.com/~dmr/primevalC.html
>
> Dennis
Thanks!
>In article <w10o3.60083$AU3.1...@news2.giganews.com>,
>Paul Lutus <paul...@yahoo.com> wrote:
>>Some may not have seen the clear humorous intent, or may have wondered if it
>>was all that clear, but I'll bet Dennis Ritchie wasn't among them.
Oh I saw the humorous _intent_, just didn't find it humorous! I don't
claim to know how Dennis Ritchie would interpret it.
>I think this was a beautiful experiment. While I agree that dmr's post
>was clearly topical, I think most of the flames the Richard got for his
>effort were misdirected.
Well, I hope you don't consider my message a flame, maybe the TIC
comment about trains was a bit OTT tho'. I still find it a 'cheap
shot' tho', but that probably says more about me than the original
posting :-)
>There's nothing wrong with flaming Dennis Ritchie, if he gets confused and
>posts in the wrong group.
Which he didn't. Bearing in mind that it was posted to the a.f.c,
comp.lang.c and comp.std.c group**s**. Not OT for any AFAIK.
>The argument against the "flame" Richard posted shouldn't be "how dare you
>flame dmr". It should be "the evolution of the language is important to
>understanding the standard and how it got here".
Indeed!
>Even dmr can post off-topic, even in a C newsgroup. He didn't this time, but
>the knee-jerk defenses are sort of silly. (For that matter, isn't it fairly
>obvious that, if it came down to it, he could defend himself plenty well?)
Well consider my response as a second hook on the line then ;-)
regards John B.
? How does it do that, pray tell?
What costs?
They could have just released it, no licensing required. Like the
original mail in this thread did.
Linus
Did you read this bit? If not, don't you feel a bit silly now?
--
Robert
(Ancalimon)
Douglas W. Jones wrote:
> I only looked briefly at the code Ritchie posted, so I didn't notice
> if the macro preprocessor was part of the language yet, or just
> something that was presented as an idea at the talk. This would
> have been in the summer of 1973, by the way.
DMR states in the HTML doc that the preprocessor didn't yet exist
at the time. But I wonder if he's found any source for the early C
preprocessor(s) yet?
-- David R. Tribble, da...@tribble.com --
Oh, of course, you *would* say that ... :)
OTOH, $100 as a "licensing fee" is uncomfortably close to the full cost of
many applications that are sold for a profit by money-hungry corporations.
One can't help thinking this is simply a retail cost under another name.
I prefer my own "Careware" program -- give programs away, but provoke a tiny
bit of thought at the same time. www.arachnoid.com/careware.
--
Paul Lutus
www.arachnoid.com
Linus Torvalds <torv...@transmeta.com> wrote in message
news:7nslra$nmj$1...@palladium.transmeta.com...
Sure, if they wanted to surrender their property rights.
7th Edition UNIX utilities are close enough to modern UNIX
versions that protecting them has some value to their owner.
On 1999-07-30 vik...@brick.flying-brick.caverock.net.nz(EricGillespie) said:
:Great troll, Richard! Considering this is one of the guys who
:practically WROTE the language, I'd say his source code would be
:well worth studying.
Why? By his own admission, he was a beginner at C when he wrote it. I'm
sure his coding style has changed a great deal since then.
More interesting will be to see exactly what language it compiles...
--
the desk lisard communa time's taught the killing game herself
>Why? By his own admission, he was a beginner at C when he wrote it. I'm
>sure his coding style has changed a great deal since then.
OTOH, he was the most experienced user.
--
Howard S Shubs hsh...@mindspring.com hsh...@bix.com
The Denim Adept Is this the right room for an argument?
SPAM: u...@ftc.gov postmaster@[127.0.0.1] abuse@[127.0.0.1]
So are the BSD utilities. If I were to release my own proprietary Unix,
I would take one of the BSD distibutions as my base. The BSD license is
permissive enough; in fact, it basically states "take the source and do
whatever." Unix *utilities* are basically worthless nowadays (how hard
is it to implement cat?), only a well-written kernel holds interesting
technical information.
Of course I won't release my own Unix, the operating system market is
too saturated, especially since GNU finds more and more users.
Gergo
--
A bachelor never quite gets over the idea that he is a thing of beauty
and a boy for ever.
-- Helen Rowland
GU d- s:+ a--- C++>$ UL+++ P>++ L+++ E>++ W+ N++ o? K- w--- !O !M !V
PS+ PE+ Y+ PGP+ t* 5+ X- R>+ tv++ b+>+++ DI+ D+ G>++ e* h! !r !y+
>Linus Torvalds wrote:
>> They could have just released it, no licensing required.
>Sure, if they wanted to surrender their property rights.
>7th Edition UNIX utilities are close enough to modern UNIX
>versions that protecting them has some value to their owner.
Superior free replacements exist for every 7th edition utility.
The original source code is practically worthless, though it
does have historical interest.
I would not examine the 7th edition source even if I had a copy,
since the current owner of the code could then accuse me of stealing
their intellectual property. I wan't look at dmr's old compiler
either, for similar silly reasons. Too bad -- it would be amusing.
But such are the wonders of modern intellectual property law.
> > DECtapes are highly platform specific, and are not covered by ANSI C,
which
> > is the subject of this newsgroup (comp.lang.c). Try a DEC-related
> > newsgroup.
>
> Wow.
>
> Dennis Ritchie posts something.
> And all he gets is a standard move-your-ass-to-the-right-group-reply.
In a way, it's pretty neat. The net has become a perfect democracy, and
now everybody can be rude to everybody else without regard to whom they're
speaking to.
Okay, pretend to be rude, but still, it's an interesting phenomenon. I
rather like it, just so nobody flames me out who can't be bothered to learn
a real HLL.
For the record, Mr. Heathfield (Richard?), the first appearance of your
comment in alt.folklore.computers didn't contain the trool cautions, merely
the flame, which may account for some of the reaction it got.
> UNIX group worked), and the thing that seems to have impressed him the
> most was the idea of adding explicit macros to a high level language.
>
> I only looked briefly at the code Ritchie posted, so I didn't notice if
> the macro preprocessor was part of the language yet, or just something
that
> was presented as an idea at the talk. This would have been in the
summer
> of 1973, by the way.
But PL/I already had a macro processor, at least on Multics. Wasn't IBM's
available yet?
> >whatever." Unix *utilities* are basically worthless nowadays (how hard
> >is it to implement cat?)
>
> A lot easier than it is to implement awk or sed. :)
A lot? I suppose all is relative. I know lines of code is a bad
measure of complexity, but still... looking at *.[chly] on one
variant of BSD sources (OpenBSD) I get:
cat: 1 file, 266 lines
sed: 6 files, 2156 lines
awk: 11 files, 5934 lines
However, I agree with the sentiment. I'd call the UNIX utilities
anything but worthless. After all there are 693 programs among the
directories /bin /usr/bin /sbin /usr/sbin and /usr/libexec. Most
are just fine and do not need a re-write.
// marc
>OTOH, he was the most experienced user.
Is that clear? I've written things where someone other than me ended up
being a more experienced user...
I suppose it's time to quote from the IAQ.
Is that clear? I've written things where someone other than me ended up
being a more experienced user...
I suppose it's time to quote from the IAQ.
2.2: I heard that structures could be assigned to variables and
passed to and from functions, but K&R I says not.
A:
K&R I was wrong; they hadn't actually learned C very well before
writing the book. Later, Ritchie got a job at Bell Labs, and worked
closely with the authors of C, allowing the 2nd edition of the book
to be much more accurate. (Kernighan already worked at Bell Labs,
where he helped develop the ``kaw'' programming language, used to
simulate crows in an international chess tournament.)
If it were retail it would be $99.95. The $100 price sounds so
much more dignified than trying to entice you by giving a nickel
in change. Anyway, the licensing fee may also include karmic
transmigration, which means you're also a registered user in your
next lifetime!
--
Craig
clfr...@worldnet.att.net
Manchester, NH
Don't think only humans have nukes. There's over 20 nuclear subs
that have been sunk, and the whales know where they are. -- Stella
A good question, since only two versions of "cat" that I know of
were properly implemented, 8th Edition UNIX's and mine.
What does IBM have to do with it? Multics was developed on a GE 645 at
MIT and Bell Labs. The choice of the GE 645 was partly driven vy IBM's
refusal to modify the relocation registers on the machines it had to
offer.
--
Martin Ambuhl mam...@earthlink.net
__________________________________________________________
Fight spam now!
Get your free anti-spam service: http://www.brightmail.com
The big issue is: I hope that Mr. Dennis Ritchie does understand that we
greatly appreciate his making all these original material sources available.
I for one can *never* get enough of these insights that only the original
materials and source discussed by the original author can give. (Yes, I
have the Lions book.)
I wish we could somehow attract more of the computer pioneering people to
post and provide their unique insights to history of computing.
Also, when you think about it, Mr. Heathfields joke could be a jab at the
folks from <comp.lang.c>. They are *so* touchy about what is on-topic,
that they have become somewhat self-righteous IMHO.
--
+-------------------------------------------------------------+
| Charles and Francis Richmond <rich...@plano.net> |
+-------------------------------------------------------------+
On 1999-07-30 gw...@arl.mil said:
:> They could have just released it, no licensing required.
:Sure, if they wanted to surrender their property rights.
:7th Edition UNIX utilities are close enough to modern UNIX
:versions that protecting them has some value to their owner.
Be afraid, be very afraid. The world has changed a lot since the 7th
edition, as has Unix itself; if the utilities haven't, then I for one
don't particularly want to use them.
What was wrong with the other's versions? How can I tell whether the one
I'm using is defective?
Surrender what property rights? Posting them on the net probably gives
you the implied right to download them and read them. It doesn't give
you the right to distribute them or use them in your code.
--
David Starner - dstar...@aasaa.ofe.org
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
>What was wrong with the other's versions? How can I tell whether the one
>I'm using is defective?
... thus the use of the expression "what a dog" to refer to defective
software.
Some of the utilities have no reason to change. There are lots of new
utilities, but I ask you, what needs to change in "cat"?
The world has changed a lot; hydrocarbons are still a good idea. Utilities
are, after all, primitives.
Note followups; this no longer has any visible relevance to C.
-s
(Hmm. Come to think of it, perhaps the committee should declare that anything
anyone on the committee wants to say is topical in comp.std.c. RMS posted to
gnu.misc.discuss to ask if anyone was driving from Point A to Point B and
would be willing to ferry an instrument to Point B, perhaps we should
generalize this.)
Some time back I'd mentioned having read somewhere that
one (of the two) Harvard Mark I's was reported to have
been shipped off to Arizona sometime in the fifties.
I tracked down the most likely knowledgable person I
could, to question about that story. He could not verify
it, so I dropped it for the time being.
There was something I didn't know (until a few minutes ago).
That man's name? Granino Korn. Formerly, Professor Korn, of
the University of Arizona. Now in his eighties.
While digging through a listing of about 1,300 tech. books,
sitting in a Las Cruces (there's THAT town again!) store, I
ran across his name. Author of 'Electronic Analog and Hybrid
Computers' (1952). Which, as it happens, is said to be the
very first textbook on computer science. !!
I think he deserves some sort of recognition for that.
Hey, want another tidbit? Remember the fictional Professor
Falkin? So where do you suppose Professor Korn retired to?
Must be something draws computer people there.......
Instead of all the fruitcakes searching around Sedona for magnetic
centers or whatever, maybe they oughta search further north?
Bill
Tucson
Cheers
--
Chris
A lurker, but drawn out by this sickening sycophantic nonsense
The main problem was that record boundaries were not preserved.
So, for example, one could not copy magnetic-tape special devices
with them and end up with a usable copy.
That's what dd is for. Of course, dd doesn't concatenate. So if you needed to
concatenate multiple tapes and write the result to another tape, dd would be
clumsy, but a block size aware cat would be handy.
ftp://gatekeeper.dec.com/pub/digital/sim/sources/sim_2.3d.tar.Z
The disk image is there :
ftp://gatekeeper.dec.com/pub/digital/sim/software/uv5swre.tar.Z
Here is the result :
$ pdp11
PDP-11 simulator V2.3d
sim> set cpu 18b
sim> att rk0 unix_v5_rk.dsk
sim> boot rk
@unix
login: root
# chdir /usr/c
# ls -l
total 368
-rw-r--r-- 1 bin 11610 Nov 26 18:13 c00.c
-rw-r--r-- 1 bin 13248 Nov 26 18:13 c00.o
-rw-r--r-- 1 bin 6528 Nov 26 18:13 c01.c
-rw-r--r-- 1 bin 7344 Nov 26 18:13 c01.o
-rw-r--r-- 1 bin 11494 Nov 26 18:13 c02.c
-rw-r--r-- 1 bin 12268 Nov 26 18:13 c02.o
-rw-r--r-- 1 bin 2316 Nov 26 18:13 c03.c
-rw-r--r-- 1 bin 3168 Nov 26 18:13 c03.o
-rw-r--r-- 1 bin 6186 Nov 26 18:13 c04.c
-rw-r--r-- 1 bin 1488 Nov 26 18:13 c04.o
-rw-r--r-- 1 bin 3652 Nov 26 18:13 c0h.c
-rw-r--r-- 1 bin 1704 Nov 26 18:13 c0t.s
-rw-r--r-- 1 bin 12576 Nov 26 18:13 c10.c
-rw-r--r-- 1 bin 8434 Nov 26 18:13 c11.c
-rw-r--r-- 1 bin 9274 Nov 26 18:13 c12.c
-rw-r--r-- 1 bin 2146 Nov 26 18:13 c13.c
-rw-r--r-- 1 bin 2905 Nov 26 18:13 c1h.c
-rw-r--r-- 1 bin 934 Nov 26 18:13 c1t.s
-rw-r--r-- 1 bin 11044 Nov 26 18:13 c20.c
-rw-r--r-- 1 bin 9698 Nov 26 18:13 c21.c
-rw-r--r-- 1 bin 1735 Nov 26 18:13 c2h.c
-rw-r--r-- 1 bin 1142 Nov 26 18:13 cctab.s
-rwxr-xr-x 1 bin 3138 Nov 26 18:13 cvopt
-rw-r--r-- 1 bin 3948 Nov 26 18:13 cvopt.c
-rw-r--r-- 1 bin 1884 Nov 26 18:13 efftab.s
-rw-r--r-- 1 bin 6317 Nov 26 18:13 regtab.s
-rw-r--r-- 1 bin 773 Nov 26 18:13 sptab.s
-rw-r--r-- 1 bin 16398 Nov 26 18:13 tab.a
-rw-r--r-- 1 bin 105 Nov 26 18:13 trc
# date
Fri Mar 21 13:33:58 EST 1975
--
--------------------------------------------------------------------
Éric Lévénez "Felix qui potuit rerum cognoscere causas"
mailto:lev...@club-internet.fr Publius Vergilius Maro,
http://perso.club-internet.fr/levenez Georgica, II-489
--------------------------------------------------------------------
"We are Microsoft. You will be assimilated. Resistance is futile."
>Also, when you think about it, Mr. Heathfields joke could be a jab at the
>folks from <comp.lang.c>. They are *so* touchy about what is on-topic,
>that they have become somewhat self-righteous IMHO.
Nah, c.l.c has become much more tolerant. Some time ago you could draw
some serious flames with comparing c to its successors like C++ or
Java. Nowadays only Lutus would object with stating that it is off
topic. Too bad.
Perhaps it's a consequence of c being replaced by other languages.
Looking at the recent cross posts having alt.folklore.computers in the
newsgroups line really is an omen. Although c has the charm of having
a standard for free standing environments (like coffee machines) and
thus is an obvious choice for making embedded software. I guess most
of the posters in c.l.c are students interested in the history of
programming languages of which c was a big part.
c is a good language for understanding some basics about programming
since it's quite "close" to the underlying system. A little bit like
Assembly (although Assembly hasn't lost its significance over the
years ofcourse)
Maybe, but it probably wouldn't reveal how much of that "writing" was
influenced by Bachus' language already well in its teens at the time of
Ritchie's endeavor...
--
Dr.B.Voh
-----------------------------------------------
Modeling * Simulation * Analysis
http://www.netcom.com/~essoft
-----------------------------------------------
Oooh, look who's trying for flame wars now. (Hey, long time no see!)
>Looking at the recent cross posts having alt.folklore.computers in the
>newsgroups line really is an omen.
I don't really think so. This is a discussion of 70's code; that's folklore
anyway.
>c is a good language for understanding some basics about programming
>since it's quite "close" to the underlying system. A little bit like
>Assembly (although Assembly hasn't lost its significance over the
>years ofcourse)
Ooh, look at that big shiny hook!
-s
> Eric Gillespie wrote:
> >
> > Great troll, Richard! Considering this is one of the guys who practically
> > WROTE the language, I'd say his source code would be well worth studying.
>
>
> Maybe, but it probably wouldn't reveal how much of that "writing" was
> influenced by Bachus' language already well in its teens at the time of
> Ritchie's endeavor...
>
Now if we could only get Mr. Backus to post and give us some info on the
development of the *original* FORTRAN compiler, we could get more insight
there also. Hmmm...anyone have Mr. Backus' email address???
Yeah, but is Assembly PORTABLE???
(how's THAT for a hook? PASM anyone?)
Curt
--
Gone are the days of yore,
in which REAL programmers wrote programs with a piece of cardboard and a
hole punch...
**** Curt Schemmel **** sche...@home.com ****
> On Thu, 29 Jul 1999 10:18:18 -0700, Paul Lutus <nos...@nosite.com> wrote:
> ><< This was a cheap shot at a computing great IMHO. >>
> >
> >Some may not have seen the clear humorous intent, or may have wondered if it
> >was all that clear, but I'll bet Dennis Ritchie wasn't among them.
> Yeah, but do you think he actually *reads* this newsgroup? I suspect
> that he just dropped off the notification. The only way he will read
> it is if some day later he by chance a Deja News search on his name.
> The reply was clearly intended for us, not for Mr. Ritchie. :)
You've made a bad assumption. The inventor of C, who is involved in
evolving it as well, has a big interest in how people are using it. I
can vouch for the legitimacy of his posts. He reads comp.lang.c
regularly.
--
Tom Reingold
to...@bell-labs.com http://www.bell-labs.com/~tommy
Bell Labs, the Research and Development unit of Lucent Technologies
Murray Hill, NJ, 07974-0636 US
Java bytecode is universally portable, so presumably JVM assembly
code would be, too (if there were any JVM assemblers to begin with).
So there. We've come full circle.
P.S. Has anyone written a C/C++ compiler backend that produces JVM
bytecode?
-- David R. Tribble, da...@tribble.com --
>Old Bell Labs C compiler may be "fossil" but from my recollection of
>the pre-1976 Unix compiler, it has many methods and algorithms that are
>superior to those in use today. Off the top of my head some are: 1) better
>expression parsing (this is documented in Gries' old compiler writing
>text book), 2) better optimization because machine dependent throughout,
>3) better use of intermediate forms and data structures.
>An interesting archeological experiment would be to try those algorithms
>on modermn ansii standard C compiler syntax.
Interesting indeed, but note that part of the the old compiler's success
was due to the different language it was implementing: there were only 2
types, int (16 bit) and char; no unsigned types (though pointers were
implicitly signed); no unions; no casts. The hardware it compiled for
was also simpler than modern chips; it had very few registers, and
supported several flavors of memory-to-memory operations.
--
Amos Shapir
Paper: nSOF Parallel Software, Ltd.
Givat-Hashlosha 48800, Israel
Tel: +972 3 9388551 Fax: +972 3 9388552 GEO: 34 55 15 E / 32 05 52 N
I have been told by an expert in C compilers that there are technical
difficulties in compiling C to JVM bytecode.
Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
Unless the bytecode specs have changed, you can't,
at least not efficiently.
Java bytecode was designed to, among other things,
prevent "unbridled" use of pointers.
Scott Nudds would be proud.
*snif*
--Corey
> The hardware it compiled for
> was also simpler than modern chips; it had very few registers, and
> supported several flavors of memory-to-memory operations.
Well that's the worst of all possible worlds, for compiler complexity.
With a simple accumulator architecture you have to load every operand from
memory, and store all results back in memory.
With a load-store architecture you know that you *have* to load all
operands into registers before you can use them. With 32 or more
registers a simple compiler can just assume that everything will fit into
registers and make the user rewrite his code if it doesn't.
It's only with a machine with a medium number of registers and both
register-register and memory-register instructions (PDP11, x86, 68K all
fit both criteria) that you have to make those nasty decisions about what
to load into registers and what to use directly from memory, and worry
about register allocation and spills/reloads. Nasty stuff.
-- Bruce
> P.S. Has anyone written a C/C++ compiler backend that produces JVM
> bytecode?
I used to read comp.compilers and there it was a topic of dicsussion. Several
people were working on it but I think they were having problems with
simulating the C memory model for arrays. I suggest you ask in comp.compilers
for the current status.
--
Stephen Baynes CEng MBCS Stephen...@soton.sc.philips.com
Philips Semiconductors Ltd
Southampton SO15 0DJ +44 (0)23 80316431 *** NEW ***
United Kingdom My views are my own.
Do you use ISO8859-1? Yes if you see © as copyright, ÷ as division and ½ as 1/2.
>In article <37abd8f2...@news.euronet.nl>,
>Paul Mesken <usu...@euronet.nl> wrote:
>>Perhaps it's a consequence of c being replaced by other languages.
>
>Oooh, look who's trying for flame wars now. (Hey, long time no see!)
>
Hehe, Seebach. It doesn't seem it works (the attempt to an all out and
awe inspiring flame war that is :-)
Perhaps I've lost my touch but it could also be that it's a too
obvious troll since I nowadays quote a lot out of The Standard
(capitals are back again :-)
>>Looking at the recent cross posts having alt.folklore.computers in the
>>newsgroups line really is an omen.
>
>I don't really think so. This is a discussion of 70's code; that's folklore
>anyway.
>
Waaaaaay back in the 70's ;-)
>Yeah, but is Assembly PORTABLE???
>(how's THAT for a hook? PASM anyone?)
>
Assembly programmers aim for *performance* at the given platform.
Portability and readability is irrelevant :-)
David R Tribble wrote:
>
> P.S. Has anyone written a C/C++ compiler backend that produces JVM
> bytecode?
>
I'm not aware of one. I think the problem is that you wouldn't be able
to implement pointers on a JVM (pretty fundamental to C or C++).
Other languages like ADA have been implemented though...
--
<\___/>
/ O O \
\_____/ FTB.
Thanks the gods it's not portable. Makes life so much simpler
when one doesn't base one's work on a myth.
This is going to turn into a war of who can throw the
biggest hooks :-).
/BAH
Subtract a hundred and four for e-mail.
analdemon: "Jeff, they won't get it. They won't understand. They won't
even reply."
Jeff: "I know, but he asked for it. Besides, where does it say that I have
to be any *seriouser than thou.* This is going to be fun *anyway."*
analdemon: "Jeff, that's devious. In fact, that's positivly DEVILISH. I
*like* you."
Jeff: "There goes the neighborhood."
>
>
: Yeah, but is Assembly PORTABLE???
: (how's THAT for a hook? PASM anyone?)
Sure it is. You just spend a couple of long weekends rewriting the
code for your new machine.
Paul "My _second_ computer was a 1620" Hughett
>On Mon, 2 Aug 1999 12:17:38 -0500, "Curt Schemmel" <sche...@home.com>
>wrote:
>>Yeah, but is Assembly PORTABLE???
>Assembly programmers aim for *performance* at the given platform.
>Portability and readability is irrelevant :-)
I'll buy that statmemt for "portability" since in most environments
it's -- shall we say, "not very common" (these *are* family
newsgroups after all...)
But "readability"? If you're talking about a hack programmer, you'll
find that UNreadability is a language-independent characteristic. Good
assembler programmers -- and I would argue that *especially* assembler
programmers -- will write both code and commentary that are readable,
at least to someone competent in the computer architecture, the
assembler syntax and symantics, and the operating system/application
design.
'Way back when I was hiring programmers for the mainframe facility
that I managed I would ask applicants to show me examples of programs
they had written, in a language that they would be using as my
employee. Neatness, readability, and an occasional touch of humor
were all positive points in my evaluation; whether I could understand
the nitty-gritty details of the program was a different question.
Expertise in programming is necessary but not sufficient to make
someone a valuable employee; it can in fact be a problem if it's
coupled with an obsessive desire to win the "obfusticated _x_" contest
(for any programming language name value of _x_).
There are certainly times when it's impractical to include a tutorial
in the commentary of a program (the famous "you are not expected to
understand this" comment in the UNIX kernel comes to mind) but
"readability" is a larger concept than the issue of understanding
the details of the underlying algorithm.
Joe Morris (who escaped from the management job long ago)
One of the more useful definitions of portability is:
Source code is portable when the amount of work required to build it on
another machine is significantly less than rewriting it from scratch.
So, Paul, how's that cutting edge perfectly tuned game for the Matrox Mystique
turning out?
Hey, the company I work for makes its living with portable assembly.
--
+- David Given ---------------McQ-+
| Work: d...@tao-group.com | Pigs have wings, making them hard to
| Play: dgi...@iname.com | catch.
+- http://wired.st-and.ac.uk/~dg -+
>usu...@euronet.nl (Paul Mesken) writes:
>
>>On Mon, 2 Aug 1999 12:17:38 -0500, "Curt Schemmel" <sche...@home.com>
>>wrote:
>
>>>Yeah, but is Assembly PORTABLE???
>
>>Assembly programmers aim for *performance* at the given platform.
>>Portability and readability is irrelevant :-)
>
>I'll buy that statmemt for "portability" since in most environments
>it's -- shall we say, "not very common" (these *are* family
>newsgroups after all...)
>
>But "readability"? If you're talking about a hack programmer, you'll
>find that UNreadability is a language-independent characteristic. Good
>assembler programmers -- and I would argue that *especially* assembler
>programmers -- will write both code and commentary that are readable,
>at least to someone competent in the computer architecture, the
>assembler syntax and symantics, and the operating system/application
>design.
>
It's always a good idea to comment your code (typically after a day or
two you wouldn't even remember what your program should be doing ;-)
It's a bad idea to program in such a way that the code itself has
maximum readability. Even PPro code starts to look very obfuscated
when one is aiming at performance (and that's what an Assembly
programmer should do ofcourse else he could just as well resort to a
HLL). The order and types of instructions should be determined by the
goal of performance, not that of readability.
Besides: I wouldn't want my Assembly code to be readable to a mere C
programmer. I love it if they don't understand a word of it :-)
>'Way back when I was hiring programmers for the mainframe facility
>that I managed I would ask applicants to show me examples of programs
>they had written, in a language that they would be using as my
>employee. Neatness, readability, and an occasional touch of humor
>were all positive points in my evaluation; whether I could understand
>the nitty-gritty details of the program was a different question.
>
Humor is irrelevant, programming is no laughing matter :-)
The nice, shiny HOOK is the only relevance. See it twinkle? See it flash
invitingly?? You will be assimilated. LONG LIVE NUDDS!
(ps I've been lurking on CLC long enough to know what assembly is for, and
when to and (more importantly) NOT to use it... and I know all about void
main() by now...)
In spite of myself, I guess I'm deviating from the troll in order to extend
a HUGE "THANK YOU" to all the regulars of CLC (yes, even you, Paul Lutus...)
I am a developer for the AS/400 (with a degree in Electrical Engineering -
so my software background tends towards the bit-level and lower) and I have
learned an IMMENSE amount of knowledge about C and portability issues here
at CLC - and I feel it has made my coding much easier (and cleaner too -- we
all know how Engineers code...).
Portability is a rather large issue with machines like the AS/400 -- I'm
constantly mindful of "someday this might be copied to a PC or a mainframe
or a chip in a refrigerator" and am always dealing with issues like EBCDIC
<--> ASCII, etc. These issues are a LOT clearer now after a few years of
lurking here at CLC... and I don't deal only in C, I also deal in COBOL,
CL, PL/*, RPG, etc. (note I said "deal", NOT "write"... I DO NOT and WILL
NOT write in RPG. I still have my pride.) Anyway, these portability
concepts that I have learned here in CLC have extended to these other
languages as well.
My first assignment was to maintain the programs to port code from the old
S/36 and S/38 to the AS/400. So right out of school, I had to deal in
portability between systems... people (especially newbies to the language),
these issues EXIST. They are REAL BUSINESS PROBLEMS. They are NOT just lab
concepts and "it's a nice concept, but doesn't concern me". It WILL. Trust
me :)
I'm sure my employer would thank you as well. All of you have been a great
service to me.
Now, back to our regularly scheduled grumpiness.
Curt
--
Gone are the days of yore,
in which REAL programmers wrote programs
with a piece of cardboard and a hole punch.
*** Curt Schemmel *** sche...@home.com
the preceeding line made me laugh out loud...
one of the most humourous replies EVER...
>
> nasaldemon: "Richard, they won't get it. They won't understand. You're
> gonna be shot down in flames for this one, big-time."
>
could someone please explain what a nasaldemon is ?
cheers,
sean
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
> I finally prepared another fossil for museum exhibition: from DECtapes
> written
> in 1972-73, there are exhumed C compilers (including source) to show
> what
> the very early stages of the language were like. This was a highly
> transitional stage; for example, the earlier one anticipates a "long"
> type, but doesn't have struct; the 6-months-later compiler implements
> struct, but reuses long's slot in the type table.
>
> http://www.cs.bell-labs.com/~dmr/primevalC.html
>
> Dennis
There was an interesting article in the San Jose Mercury News which
referenced the original
Visicalc program (which would run under Windows 95), and also mentioned
Dennis Ritchie's
Primaeval C site and a Borland site for Turbo Pascal, etc. There's a URL
for this article:
http://www.mercurycenter.com/svtech/columns/gillmor/docs/dg080399.htm
which in turn points to where these other items of software
archaeological interest can be found.
--
Yours,
Jonathan Leffler (jlef...@informix.com) #include
Guardian of DBD::Informix v0.60 (v0.61_02) -- http://www.perl.com/CPAN
Informix IDN for D4GL & Linux -- http://www.informix.com/idn
I have a friend who might have done this. He's done Scheme and
Prolog, but I don't know about C. Let me ask him.
--
Paul Brinkley
ga...@clark.net
"Undefined behavior" by a C program, such as when you index
beyond the end of an array, can have any possible result. Some
reasons undefined behavior works this way are to avoid the cost
of checking for such occurrences, to free the implementation
to make optimizations that assume undefined behavior does not
occur, and to allow implementations to provide a useful extension
for some occurrences of undefined behavior.
The possibility that *anything* may happen is dramatized by
(among other things) the possibility of demons flying out of your
nose. Hence, nasal demons.
--
MJSR
From the Jargon File <URL:http://www.tuxedo.org/~esr/jargon/>:
# nasal demons n.
#
# Recognized shorthand on the Usenet group comp.std.c for any
# unexpected behavior of a C compiler on encountering an undefined
# construct. During a discussion on that group in early 1992, a
# regular remarked "When the compiler encounters [a given undefined
# construct] it is legal for it to make demons fly out of your nose"
# (the implication is that the compiler may choose any arbitrarily
# bizarre way to interpret the code without violating the ANSI C
# standard). Someone else followed up with a reference to "nasal
# demons", which quickly became established.
paul