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 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 To: Mike O'Dell [system] 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 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." 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 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 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 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 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.