Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!purdue!bu-cs!xylogics!world!madd
From: madd@world.std.com (jim frost)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Charity
Keywords: wretched, pity, good counsel, ignoramus
Message-ID: <1989Oct24.181923.21699@world.std.com>
Date: 24 Oct 89 18:19:23 GMT
References: <13091@boulder.Colorado.EDU>
Reply-To: madd@std.com
Distribution: usa
Organization: Software Tool & Die
Lines: 118

In article <13091@boulder.Colorado.EDU> johnsobm@spot.Colorado.EDU writes:
|1. Briefly, what do the following abbreviations mean:
|  	RLL

Run-length-limited.

|	MFM

Modified Frequency Modulation, I believe.  This is supposed to be a
better encoding method than pure FM.

|	SCSI

Small Computer System Interface.

|1. What do UN*X loyalists hold as the greatest strength/virtue of that
|OS?

There are two reasons why I like UNIX.  First, it has a substantial
set of small utilities which can be combined in many ways to
accomplish just about any job without programming.  I appreciate this
approach and miss it terribly on other operating systems.  Second, it
defines a standard (or nearly standard) software interface which
remains consistent across a wide range of hardware platforms, allowing
program written on (say) a PC-class machine to run on (say) a Cray or
parallel-architecture machine.

The fact that it is an interface and not an implementation is why UNIX
is so "portable".  Even if it is impractical to port a current
implementation of UNIX to your hardware, you can retool the
implementation for your hardware and so long as the interface remains
the same, it will work fine.  This is an important consideration when
porting to such things as parallel architectures where conventional OS
designs don't work.  Interface-versus-implementation also means that
you can change the entire design of the filesystem without breaking a
single program.  Unfortunately it also means that your interface must
remain fairly simple or you will have a hard time supporting a wide
range of hardware.  The trade-off works well enough for me.

|Or, more simply, what chiefly distinguishes UN*X (Xenix, Ultrix,
|Minix, etc) from DOS, other than, say, sheer size/power?  What is the
|fundamental difference in philosophy that allows UN*X to handle much
|larger systems/applications?

The first difference between UNIX and DOS is that DOS provides mainly
a set of disk-i/o calls, with little or no support for anything else.
This design led many programmers (myself included) to go straight to
the hardware to get the job done correctly or with good response time.
If DOS had been a "real" operating system, it would have provided
standardized software interfaces (which *worked*) for such things as
serial communications devices (eg modems) and reasonable terminal i/o
handling (ie it would be efficient to use DOS to write to the screen).
The lack of this support has a lot to do with the difficulty in
creating a multitasking DOS, amongst other problems.

UNIX, on the other hand, provides support for a wide range of i/o
devices (although some would say poor support in many cases) and
attempts to use them efficiently.  Given the wide range of hardware
platforms that UNIX runs on, it is to the programmer's advantage to
avoid hardware dependencies.  Additionally UNIX provides multitasking
and several forms of interprocess communication, most notably the
pipe.  Most common implementations of UNIX also allow shared memory
and networked host communication.  Most versions of UNIX have virtual
memory -- either swapping or paging based or both -- to allow more
main memory to be used by applications than you actually have, faking
it by using secondary storage.  The UNIX filesystem, especially
implementations on research-based or high-end commercial UNIX's, is
fairly robust and responsive.  Newer implementations are very robust
and are unlikely to become heavily fragmented.  All UNIX filesystems
support file protection mechanisms.  Lastly, UNIX is a multiuser
system, with all the extra complexities which that implies.

|2. In a similar vein, what do the fans of the various C implementations
|say is the major advantage/raison d'etre/necessity of using C over, say,
|Turbo Pascal, or TP & assembler?

C is particularly well suited for systems work, much more so than
Pascal, and far more portable than assembler.  It is easy to make a
fairly good C compiler.  C has a good mixture of low-level programming
capabilities with the ease of use of a high-level language.  Few other
languages provide this.  While many people say that C is "cryptic",
good programmers can produce very readable code with little
difficulty, and the standard library set is no more cryptic than many
other languages I have used, although it is often much more terse
(which in part leads to its "crypticness").

|I would really appreciate any advice: good reference books on C and
|UN*X and the various shells, arguements designed to steer me in the
|direction of the ONE and TRUE path to programming wisdom (ie, should
|I emphasize C/UN*X to the practical exclusion of all else?  Is it yet
|a C/UN*X world out there?

There are a good many C books out there, although someone will have to
point you towards those (and good shell-programming books) since I
learned from the original K&R and K&P books.

As for emphasizing UNIX above all else, I believe it would be most
practical for you to learn UNIX programming well, but don't dwell on
it exclusively (read "The Idea of a University" by Newman for good
explanations of why).  The world is not completely UNIX and never will
be, although experts seem to expect a tremendous growth in the UNIX
market over the next several years (considering its growth in the last
several years, this is not surprising).  This tends to indicate that
you'll be able to find a job.

|Is C/UN*X simply THE superior programming tool
|of the 90's?)

Perhaps, perhaps not.  I've found it to be the best development
environment of any I have ever used for large-scale projects, probably
because the utilities were designed with such things in mind.
Properly used it is a very effective programming environment.  There
may be better, but there are no better environments which are so
widely available.

jim frost
software tool & die
madd@std.com