[CONTACT]

[ABOUT]

[POLICY]

[ADVERTISE]

Aucbvax.fa.worksutcsrgv!utzoo!

Found at: gopher.quux.org:70/Archives/usenet-a-news/FA.works/82.03.17_ucbvax.6544_fa.works.txt

Aucbvax.6544
fa.works
utcsrgv!utzoo!decvax!ucbvax!works
Wed Mar 17 00:08:57 1982
WORKS Digest V2 #24
>From PLEASANT@RUTGERS Tue Mar 16 23:41:26 1982
Works Digest            Tuesday, 16 Mar 1982     Volume 2 : Issue 24
Today's Topics:             Administrivia
                          Someone's Theory
                       Modems vs Transceivers
                          Ethernet Doomed?
                         Your first language
                  UNIX & Workstations & Networking
                         UNIX & "the" Answer
                           C third worst?
                          Opinions & Biases
----------------------------------------------------------------------
Date: Monday, 15 March 1982  20:46-PST
From: Jonathan Alan Solomon <JSOL AT ECLC>
Subject: Administrivia - Out with the old - In with the new
I wish to take this opportunity to note that we have gone back to the
digest form of publication for all readers. Unfortunately, due to load
restrictions and the extreme volume of mail WorkS has generated, it
has simply become impossible to distribute the information fast enough
to all readers in the short time before the next response is ready to
be sent. I hope you will understand that it is for the good of all
that WorkS not interfere with the normal operation of the ARPANet, and
that it continue to maintain a "secondary" status to the important
business which is conducted on the Net.
When I started to offer immediate redistribution and digestification,
I was hoping that the list would no longer require as much time as I
was spending on it. The fact was that I spent more time on WorkS than
I had ever before done, since the volume of mail had increased quite
so much and it was hard for me to keep the digests up to date with the
discussion. Additionally, some of the traffic had little to nothing to
do with WorkS. It was my responsibility to insure that such
discussions were channeled to the proper mailing list. One example of
this was the complaints about the message header. This type of
complaint should have gone to WorkS-Request. Normally I would have
caught them before publishing a digest.
The simple fact is that I don't have the time anymore to handle the
traffic of 2 digests, 4 direct mailing lists, and the brunt of mailing
list maintainence across the ARPAnet. Unfortunately since I do this au
gratis, and I don't get paid to do it, I can't let it interfere with
the work which I do here at ECL, which I do get paid for. I am now
forced to take the less popular alternative (to me) which is to give
up moderation of the list. Therefore I am officially resigning my
place as moderator of WorkS.
I'm not going completely away, I will remain on the sidelines to
advise and to help maintain the list, along with our new moderator,
Mel Pleasant. Mel is a good friend of mine, someone who I can trust to
keep the discussion hearty and healthful, and I am sure that he will
do a fine job moderating the WorkStation discussion. Mel is a systems
programmer at Rutgers, and had always had an interest in WorkS, so it
seemed only natural for him to moderate it. Please help me welcome him
to the WorkS community.
			Good Luck Mel!
					******
					*JSol*
					******
------------------------------
Date:      12 Mar 82 2:10:19-EST (Fri)
From:      Michael Muuss <MIKE@BRL-BMD>
To:        Mike O'Dell [system] <MO@LBL-UNIX>
Subject:   Re:  Someone's Theory
I spent my first half-dozen years programming and hacking on IBM
systems.  I like UNIX tons better.  Does this mean I'm sick?  I wager
that most people on the net who learned computing someplace other than
college probably learned IBM.  This may dent the theory somewhat....
By the way, I would like to see discussion tend to follow the lines of
"what things can we do that give people even more power than
UNIX/TENEX/TOPS-20", rather than re-hash the basicly dead issue of
whether UNIX, TENEX, or TOPS-20 (or even something else) is "best".  I
regard the three as being (roughly) functionally equivalent (hackers
everywhere, peace!), differing mostly in smallish details.  They all
represent the "best" of the "current" software technology in
ultra-widespread use.  So, what's next?
                                -Mike
------------------------------
Date: Thursday, 11 March 1982 08:45-PST
From: Chris Ryland <RYLAND@SRI-KL>
To:   SIRBU at Mit-Mc
cc:   Human-Nets at Mit-Ai
Subject: Modems vs Transceivers
    Date: Thursday, 11 March 1982  06:02-PST
    From: "Marvin A. Sirbu, Jr." <SIRBU MIT-MC AT>
    I'm sorry, but Ethernet does not reguire a MODEM, it requires a
    TRANSCEIVER.  There's a big difference.  
Of course there's a difference (and I assumed that any reader of my
message would understand the technical distinction), but not the kind
of difference the article was implying: a naive reader would assume
that there was no need for a cable driver on the Ethernet.  A modem
and a transceiver are functionally identical.
    ... A modem implies RF oscillators and receivers with lots of
    filters and other non-digital components.  Transceivers,
    operating on honest-to-goodness digital signals, not RF tones,
    are easier to build.
Not true; rather, people have more experience building transceivers.
This is bound to change: TRW makes chips which allow you to build a
2MHz fixed-channel RF modem with essentially 3 components (rcvr,
xmittr, SDLC chip).  Frequency-agile modems are harder, but LSI can
change that, also.
------------------------------
Date: 12 March 1982 03:17-EST
From: Howard I Cannon <HIC@MIT-MC>
Subject:  Ethernet Doomed?
To: BILLW at Sri-Kl
cc: SIRBU at Mit-Mc, Ryland at Sri-Kl, Human-nets at Mit-Ai
I'm not sure how the Ethernet is spec'ed (since I'm at home, and the
documentation is in my desk at work), but the Chaosnet, which is a
CSMA/CD (carrier sense multiple access, with collision detection (did
I get this right?)) ethernet-like network, does something less analog
and in some sense more sneaky to detect collisions: it watches the
cable, and if what's on the cable isn't what it is sending, then a
collision has occured.  Since the cable is only actively driven in one
direction, this works nicely.  (positive, passive terminators on each
end provide the "pulldown".  Just like open-collector TTL, but
reversed.)
The analog electronics in the Chaosnet transceiver have mostly to do
with driving the cable, which is perhaps the most tricky part of any
scheme.  By getting this right, you can run at 10 megabaud baseband.
We had to slow the Chaosnet down from 8 to 4 megabits/sec in order to
get more acceptable error rates on our longer runs.  I believe the
major problem with 8 megabaud turned out to be that many of the
optical isolators we were using didn't work very well at that speed.
There is no question that ringnets have simpler interfaces to their
cables.  One could build a ringnet cable interface out of two
differential parts and do very nicely.  Even add optical isolation if
you want for a coupla more chips.  But I wouldn't want to try arguing
ringnet vs. ether-like net on that basis alone.
------------------------------
Date: 11 Mar 1982 1819-PST
From: Tom Wadlow <TAW@S1-A>
Subject: Your first language
        From: mo at Lbl-Unix (Mike O'Dell [system])
        Subject: Someone's Theory
        There is a psychological theory, the author of which I can't
        remember at the moment, which says the first language you
        learn, or become fluent in, dramatically controls the thoughts
        you can have.
The first computer language I learned was BASIC, on some obscure
Westinghouse computer.  This has not stopped me from appreciating the
good features of LISP, C, Pascal, Forth, Smalltalk, Mesa and others.
To say nothing of UNIX, Tops-20, Multics, WAITS, and other operating
systems too numerous to mention.  It has also not kept me from flaming
at great length about the drawbacks of the aforementioned.  I don't
wish for the good old days with line numbers and NEXT X statements.
Occasionally, I have met folks who claim that their language is The
Language.  They are always wrong.  It seems to me that the essence of
good software engineering is to be able to pick the appropriate
language from your repertoire (and, like anything else, the bigger
your repertoire, the better) and to know WHY you picked Language X for
Task Y.
------------------------------
Date: 12 Mar 1982 11:18 PST
From: Deutsch at Parc-Maxc
Subject: Re: UNIX & Workstations & Networking ...
In-reply-to: mike's message of 22 Feb 82 0:15:36-EST (Mon)
To: Michael Muuss <MIKE@BRL>
A few weeks ago you sent a message to WorkS about a terminal called
the BLIT.  I've seen a similar machine from BB&N called the BitGraph.
But it sounds like the BLIT has more functionality, and might even be
expandable to include more memory and/or a hard disk, which in my
opinion are both absolutely necessary for a home computer (which is
what I'm interested in).  Can you give me more information about who
designed it, who might market it, where to find out more about it,
etc.?
Uniform network protocols are a must.  Unfortunately, TCP/IP is
relatively complicated and (as I understand it) has some features that
run counter to our (the Ethernet world's) philosophy of
packet-switched, best-efforts communication.  I guess having some
halfway reasonable standard is better than not having any at all.
Incidentally, I think there is absolutely no excuse in this day and
age for building a workstation "so braindamaged as not to be able to
multi-program".  All it takes is some kind of hardware interrupt
system and a tiny bit of multi-process scheduling software.  Memory
protection, timers and suchlike are unnecessary.  In the mid-1960s
someone I knew at U.C. Berkeley wrote a real-time multi-process
scheduler for a DEC PDP-5 (the precursor of the PDP-8) in about 100
instructions.
P. D.
------------------------------
Date: Thursday, 11 Mar 1982 13:56-PST
To: Joe.Newcomer at Cmu-10a
Subject: Re:  Re: UNIX & "the" Answer
In-reply-to: Your message of 11 March 1982 1354-EST (Thursday).
From: mike at Rand-Unix
Dear Joe,
Your message about UNIX has the following semantic content:
        UNIX is no good because a) C is "the worst" and b)
        because UNIX doesn't call things the way "I'm" used
        to, ie it doesn't conform to PDP 6 (and its successors)
        terminlogy, so it must be "wrong".
Can we raise the intellectual content of this list a little?
Michael
------------------------------
Date: 12 March 1982 1900-EST (Friday)
From: Joe.Newcomer at Cmu-10a
To: pratt.Shasta at Sumex-Aim
Subject:  Re: C third worst?
In-Reply-To:  pratt@Shasta@Sumex-Aim's message of 11 Mar 82 18:28-EST
One thing is true of modern languages: you need not restrict yourself
to medium-level control and data strctures, it is possible to build
optimizing compilers which remove the burden of hacking and allow the
user to write the expression which is meant instead of the one which
"generates good code", and although garbage collectors are nice,
explicit allocation/deallocation is not so bad.  The major problem I
had with C after using Bliss is that the abstractions I program in
were extremely difficult to write.  If you ignore such incidentals as
the completely bogus way "." and "->" introduce a level of
inappropriate concretization of structures, and the inability to write
decent iteration abstractions (the most imnt one I care about), and
the proclivity in every C program I ever looked at to handle string
iteration by wiring in [i++] type notations, and the lack of a
'leave' style construct, the bogus way of doing case statements, and
the general unreadability of the programs because procedure
declarations look like procedure calls and a few dozen other
notational problems, it probably isn't a bad language.  However,
having used both Bliss and SAIL, I much prefer those two langauges.
SAIL without a string garbage collector would be a bit of a pain to
use, but I find that I can warp either of those langauges to the
"language" I use in my head (which is neither BLiss nor SAIL, but a
much higher level object-based notation), but with C, the underlying
mechanisms and notations I use cannot even be expressed.  Therefore, I
found that I was always writing very concrete code in C, instead of
abstract code, and I always had to be concious of how badly the
compiler was going to translate it, instead of knowing the compiler
would optimize away any rubbish I wrote.  It  was almost as bad as
writing in assembler in terms of the mind-set I found myself
maintaining.  I usually program two or three levels above the
implementation, and use sophisticated macros and knowledge that the
compiler will optimize to defer the detailed implementation.  The
change was more than I could bear.  Even a preprocessor would not
suffice in the case of C, bewcause some of the primitives I needed
weren't present, and in any case, I couldn't exploit the non-existent
sophisticated optimizer.  The only experience I have had worse than
this was with Pascal, which actively goes out of its way to prohibit
me from letting code flow from my head to the target language.  For
the curious, the second-worst language is Fortran, which is truly the
assembly code of high-order languages.  However, it doesn't actively
prevent me from doing what I want to do, as Pascal does.
                                        joe
------------------------------
Date: 12 March 1982 1917-EST (Friday)
From: Joe.Newcomer at Cmu-10a
To: JGOLDBERGER at Usc-Isib
Subject:  Re: Opinions & Biases
In-Reply-To:  <[USC-ISIB]11-MAR-82 17:19:30.JGOLDBERGER>
Indeed, no system is perfect.  I have a massive file on TOPS-20 in
which I document several dozen major or minor problems with the
system; the major ones usually deal with the fact that the original
computing model was a single user at a model 33 TTY running a single
program (perhaps of multiple processes) on a system possessing one
logical file  strucutre (no dismountable packs) working on a single
project.  Since none of these conform to what I do every day, I find
serious mismatches between what I need and what TOPS-20 supplies.  On
the other hand, for all those things which are within the design
parameters, it does them very well indeed.  I agree with your comment
that a complete new rethinking of the fundamental paradigm is
important.  The STAR and PERQ/SPICE are starts, but both will need to
be refined as the actual experience with distributed computing is
gained.  All workstation projects predicated on this are going in the
right direction.
It is important to separate the Unix user interface from the Unix
kernel.  All of my flaming about Unix center primarily on its user
interface.  A project which chooses to use the Unix kernel and which
completely redoes the interface might well produce a system which is
hardware independent and superior to TOPS-20 or Unix.  Couloris is
arguing that the Unix kernel may not be appropriate; I cannot
participate in that argument because I never explored the fringes of
the kernel enough to find where it broke down from the model of what I
need.
                                joe
------------------------------
Date: 13 Mar 1982 12:35:28-PST
From: pratt@Shasta at Sumex-Aim
To: Joe.Newcomer@CMU-10A, pratt@Shasta at Sumex-Aim
Subject: Re: C third worst?
I too like to write abstract code.  So far I've found that the only
obstacle to this in C has been the absence of garbage collection.
Modulo this problem, I've found myself able to program pretty
abstractly.  Of course there's no way to hide the implementation, but
that's a separate issue from being able to program abstractly to begin
with; hiding is more of a personal-security issue, trying to protect
yourself from your own stupidity.
The BIG problem for me is garbage collection.  I have no intuitive
feeling, WHEN I PROGRAM ABSTRACTLY, for when to return something.  I'm
impressed you are able to do it easily, I should learn the trick.  I
find when I try to do it I am working at the low level I was trying to
avoid by programming abstractly.  This slows me down, and my error
rate goes up sharply.
Vaughan
------------------------------
End of WorkS Digest
*******************
-------
-----------------------------------------------------------------
 gopher://quux.org/ conversion by John Goerzen <jgoerzen@complete.org>
 of http://communication.ucsd.edu/A-News/
This Usenet Oldnews Archive
article may be copied and distributed freely, provided:
1. There is no money collected for the text(s) of the articles.
2. The following notice remains appended to each copy:
The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996 
 Bruce Jones, Henry Spencer, David Wiseman.

NEW PAGES:

[ODDNUGGET]

[GOPHER]