Conference turris::languages

2.0. "The story thus far..." by VAXUUM::DYER () Tue Jan 10 1984 14:39

	Here's the discussion so far, which inspired this file.  Not all
the text here can be called language flames/religion, but this is where
it started, VORTEX::SYS$NOTES:TOPSVMS Note #57.  I've edited the parts
out that have nothing to do with languages.  Wherever you see three aster-
isks, that means that some of the text of that particular note was edited
out (again, because it had nothing to do with languages).
		Enjoy!
		<_Jym_>
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  10-DEC-1983 23:47           ORPHAN::BRETT       

And a word from our favorite transportable language,  ADA!!!

This language was DESIGNED to be machine independent by one of the XXX'est
projects in a long time.   We have discovered programs that are legal on one
implementation but illegal on another.  Sigh.

/Bevin

PS: For XXX read BIGG, EXTENSIV, STUPID, EXPENSIV, or a variety of others.

PPS: For all its problems, it is the BEST attempt at such a language.  The more
I use it, the more I like it.  (By such a language I mean <general purpose,
powerful, aimed at large projects, arithemtic precision requirements, 
exceptions, etc.>, not a simple language like OCCAM)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  11-DEC-1983 21:48           RANI::LEICHTERJ   
				     * * *
Bliss as the implementation language.  While I've always thought the language
ill-conceived, I can't see any direct reason why its use should have a negative
impact on transportability.  (One thing that the C developers learned early on
is that moving the source level code was easy; what was hard was the system
interface, particularly the I/O.  The C language does not in and of itself
define a system interface package or a library, but a "standard library" has
evolved and at this point a C compiler without such a library is just not
acceptable.  It took Bliss much longer to get to the point of having XPORT,
and to this day the standard support library for Bliss is very impoverished,
compared to that for C.  This DOES have some impact - and I'll return to it in
a moment.)
				     * * *
BTW, the use of Bliss ties back in to this:  Since Bliss compilers don't run on
11's, any project using Bliss for development must use a VAX (or a 20, although
I've never heard of such a use).  Cross compilers are always more painful to use
than native ones, the debugging support is always more limited, etc., etc. -
so in this situation, the temptation to develop on the big machine and worry
about low-end performance "in the next base level" is all the stronger.  One
of the things that helps keep C code portable is that the compiler runs on
such a variety of systems.
							-- Jerry
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  12-DEC-1983 19:58           HARE::STAN        

I've had very good luck transporting programs written in FORTRAN
and in TECO between various operating systems.  So perhaps there
is a design problem with BLISS and maybe we should be writing in
a higher-level language than BLISS.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  12-DEC-1983 23:24           GOLD::WEAVER      
				     * * *
TEX (Tau Eta Chi) is a good example of the former.  While few people
like the limitations imposed by PASCAL (the reason PASCAL has diverged
so much in recent history), Wirth very consisely outlined the language
and dealt a great deal more with abstraction.  The effect this had on
TEX was not immediately obvious, as it was first written in SAIL which
ran on the 10's and 20's.  However, the resultant demand for TEX,
culminated in a rewrite in PASCAL.  TEX has now found its way to many
different architectures.

Obviously, the use of PASCAL was not the only factor in TEX being
transportable.  Knuth is a master, and his original code was very
structured, otherwise it wouldn't have stood a chance (talk about bad
I/O systems, look at how you do I/O in SAIL someday!).  But the fact
that it was rewritten in a high level (fairly abstract) language has
certainly helped get it around.  Of course, TEX is so popular, that it
probably would have been ported if it was written in assembler.

However, I agree that common sources have a niche, but they are but a
small part of transportable software.  As was mentioned in earlier
notes, modularity is one of the biggest keys.  Obviously, it had a BIG
effect in the porting of TEX from SAIL to PASCAL.  (I wouldn't doubt
that Knuth had it in mind when originally writing in SAIL!)
				     * * *
FORTRAN has made it to so many architectures because it developed a
following.  I personally detest the idea of FORTRAN, but the only way it
will ever die is to give people another choice.  What are the other
choices?  PASCAL?  the scientific communinity hasn't embraced it.  PL/I?
people can't decide on which subset to use.  APL?  too obscure for
non-mathmeticians and too slow. ADA?  it will probably suffer from the
same disease as PL/I, except non-malignant. LISP?  meant for AI.
COBOL?  words escape me!  Forgive me for getting a bit carried away, the
point is that a computer scientist will idealize the world of
computers, while a physicist lives with it (At least a lot of current
physicists).  FORTRAN code is the ultimate example of common sources
(not the compiler, the applications).  In this case, it is the abundance
of applications that has probably driven FORTRAN to where it is now.
				     * * *
					-Dave
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  13-DEC-1983 14:43           BABEL::HOBBS       
				     * * *
General comments on BLISS:

The BLISS language makes writing efficient "portable" systems both easy and
difficult at the same time.  BLISS is an excellent language for allowing the
programmer to make use of architectural features of a machine--this promotes
efficiency.  On the other hand, various BLISS features (especially structures)
allow a programmer to isolate this machine dependency so the majority of the
program is independent of the architecture.  If a good engineering job is done
on the design and implementation of a project then the well-designed BLISS
programs will easily port to other machines with all the special source code
required to exploit machine efficiency isolated in a few small modules and
require files.  Note that this machine specific code includes the interface to
operating system.  However, the BLISS language does not force (nor even
encourage) a programmer to do the machine-specific source code isolation.  Many
(most??) implementors at Digital probably use BLISS in such a way that porting
to another architecture (or operating system) is quite difficult because the
BLISS code that needs changing is scattered through-out the program.

Languages like Pascal and PL/I make it difficult to write programs that require
specific machine features.  Therefore, such languages encourage machine
independent algorithms.  However, it is very difficult to do machine specific
things for efficiency purposes.  Often when a particular technique is chosen
to exploit a particular machine feature that technique will be required to be
scattered through-out the high-level source code.  A program in Pascal or
PL/I using a language feature designed for efficiency on one architecture will
still easily port to another architecture but modifying the program to run
efficiently on the other architecture will be a monumental task because the
machine specific efficiency decisions are not isolated.  Again, careful design
and implementation of a system written in a high level language can help the
problem but usually the necessary care is considered too difficult and the
resulting system is difficult to keep efficient when ported.

Note that neither an intermediate-level language (like BLISS or C) nor
a high-level language (such as Pascal or PL/I) can help when a change of
algorithm is required for efficiency.  The example of the BLISS flow analysis
phase in response 47.12 is a situation where a different data-structure and
search technique is chosen depending on the page fault behavior of the machine.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  13-DEC-1983 20:03           BACH::PIERSON     

Another alternative:

	Incrementally extensible languages such as FORTH, LISP, and KOALA
    encourage you to package all architecture specific data structures
    along with the code that manipulates them.  These data structures and
    routines are then used as the primitives in the next level of the
    implementation.  With a well designed application, porting consists of
    simply rewriting the appropriate primitives.  The difference between
    this style and packaging everything in different subroutines is mainly a
    subtle issue of language clarity.  With an incrementally extensible
    system every layer is written in a language optimized for that layer;
    with BLISS or PASCAL subroutines, most layers consist of little but
    syntactically identical subroutine calls.

	This approach does not need to be slow - FORTH code can be arbitrarily
    fast.

						dan
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  14-DEC-1983 00:17           RANI::LEICHTERJ   
				     * * *
Incrementally extensible languages:  I fail to see any deep difference in phi-
losophy between an extensible syntax and an effective common subroutine library.
Most of the semantics that make C work as a development language are in the
standard library; there is very little in the language at all.  If the argument
is that optimizers can do better with the in-line code that results from what
are essentially macros with fancy syntax:  Well, that's true up to a point.
However, that's a matter of allowing limitations in the technology of present
compilers - which rarely do inter-procedural optimization, although they
certainly could do SOME - dictate the syntax of your language.  Hardly seems
a very logical approach to me...I'd rather see better compilers, and hardware
with a less extravagent definition of procedure calls...procedures as an
organizational technology have a LOT of advantages.

Common sources:  There have been some misunderstandings here.  TECO DOES have
a common source across all O/S's; there is a single module (out of six or so)
that is chosen depending on your O/S.  Decus C and all its utilities have
single sources; there is conditionalized code for the various cases.  (Some
tests are made at assemble/compile time, some at run time.)  There is nothing
technically wrong or even particularly difficult about common sources, and
they have the powerful advantages of (a) GUARANTEEING compatibility (unless
you work in conditionalized code at too high a level; (b) ensuring that patches
are made to common problems across all versions simultaneously.
				     * * *
							-- Jerry
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  15-DEC-1983 13:29           REX::MINOW       

There are several other aspects of transportable systems that haven't
been mentioned yet.  Using DECtalk as an example, I might point out
the advantage of common, transportable sources (with machine-specific
problems handled by conditional compiliation).  DECtalk was
originally developed at MIT with some pieces running on an 11/60
running Unix and others on a Dec-20 running TOPS-20.

We bought the code and brought it up on Vax RSX compatibility mode
and RSTS/E and RT11 (using Decus C in all instances).  Once
Vax-11 C became reliable, the code was transported to Vax VMS
integrating the separate modules into a single program.

This was done so we could use a relatively friendly environment
to debug the linguistics of DECtalk.  Parallel to this, we implemented
a tiny real-time operating system with interprocess pipes and
messages for the target 68000.  It was then a relatively simple matter
to take the Vax/PDP11/PDP10 sources and recompile them for the
ultimate target.

While I wouldn't claim that it ran the first time, the advantages
of transportability far outweigh the disadvantages of debugging
three compilers and runtime libraries.
				     * * *
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  16-DEC-1983 12:09           EIFFEL::HARRIS      

Martin Minow makes an excellent point!  Yes, we should do all we can to 
encourage OTHER PEOPLE to write their software transportably.  That way, we
can make the easiest use of it, and it will probably be better on VAX
than on other machines because of all the optimizing compilers available.

This is a different issue from whether WE should write transportable software.
In particular, we have benefitted in a rather peculiar way from the 
unpopularity of BLISS outside of DEC.  Since nobody knows it, or has 
implementations on their machines, most of our system software is available
ONLY on DEC machines.  That means that if a customer wants DEC capabilities,
he must buy DEC hardware.  This may make it harder to communicate with
people in academia, but then we are in it for the money and they are in it
for the credit.

I think this is a real case of "what's sauce for the goose ISN'T sauce for the
gander".  We have heard frequently from the salesmen the ploy: Steal from the
competition by matching their features, and lock them in with ours.  
Encouraging others to write transportable software helps with the first.  
Avoiding it for us helps with the second.

Sounds pretty mercenary doesn't it?  Well, you all better start thinking that
way if we are going to prevent future disasters.
						-Kevin
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  16-DEC-1983 18:54           REX::MINOW       


Most of the transportability problems I've run into lately have been
in moving software between one flavor of RSX-11M and another (Vax
compatibility to RSTS/E to the PRO-350).  Also between one RELEASE
of VMS and another.  The Decus C runtime library initialization
code has several hundred lines of unmaintainable Macro containing
release-specific code for VMS compatibility mode.  (and there's
no way to discover the VMS release at runtime).

I can understand the business decision of making it hard to move
our software to our competitor's machines, but would note that
it probably costs us far more than we benefit.

PS: we just decided to use the J-11 for the next version of DECtalk.
We'll probably spend about two weeks transporting the code from
the 68000 to the PDP-11.  This should give us a speed improvement
as Decus C is a better compiler than what we've been using.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  16-DEC-1983 18:52           BACH::PIERSON     

				     * * *
    <flame on>

	Ignoring academia is a lot easier if you're in a nice stable market
    where nothing significant has changed in 10 years like Fortran.  Those
    of us who are trying to help the corporation break into new market areas
    NEED academic software and academic use of our software.  That's why we
    have to do a UN*X (blech) version of LISP.

    <flame down to a dull roar>

							dan
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  16-DEC-1983 21:41           ELUDOM::WINALSKI    

An observation just to pour more gasoline on the fire:

	LISP is all academic crap anyway.  Nothing useful has ever or ever will
	be done in it.  It is a waste of time and money for DEC to be involved
	with it at all.

--PSW
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  27-DEC-1983 12:39           VAXUUM::DYER        

	I think it's a pretty bad idea to try to lock customers
to our hardware by making our software untransportable (the
aforementioned effect of coding in Bliss).  Consider this:  there
are many, many micros out there, and not many of them are ours.
	DEC missed the boat on micros, coming out with the PRO
and the Rainbow a bit too late.  We all know that.  But there's
no reason why our software can't ride that boat.
	C is *the* language for micros.  C is also an excellent
language for general development.  I haven't used Bliss, but from
what I understand, it's at about the same level as C (i.e., not
a "high-level" or "low-level" language, but a "medium-level" lan-
guage).  Outside of DEC (yes, such a place exists), C is cleaning
up.  It's the rage.  It's seen as a "portable assembly language".
	Since I work for DEC, I do most of my coding in VAX C.
I've had lots of success bringing up programs written from/for
other systems - mostly micros - on the VAX.  I've even found it
pretty easy moving code from DECsystem-20's to here.  (The 20
doesn't have a C compiler quite yet, but there's one under devel-
opment at WPI.)
	Sometimes I write C programs on micros, and I see times
(oops - make that "places") where a call to the VMS RTL would be
just dandy.  C has directives for conditional assembly.  I can
tell it to compile (that's conditional *compilation*, not condi-
tional assembly - it's the "portable assembly language" phenom-
ena...) a call to the VMS RTL if I'm using VAX11C (or a VAX, or
VMS).  Later, I upload the file.  Often, it compiles and works.
	The point is, don't overlook C.  It's making its mark
as *the* development language.  It seems that there's a lot of
politics coming into play, that C isn't very seriously regarded
around here.  If it keeps up, we'll literally be talking a diff-
erent language than the people we're selling things to.
	Incidentally, in regards to the previous discussion
about TeX:  It's available on many micros.  It isn't written in
SAIL *or* Pascal; usually it's written in C.  Perhaps those of
us using the big machines should rewrite it *again* in C (or
convert one of the micro versions over).
		<_Jym_>
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  27-DEC-1983 18:20           ORPHAN::BRETT       

Sorry, C has been taken seriously - it is MUCH LESS powerful than Bliss.
There is a 'push' at present to change to C, often based on observations like
this.

C is 'taking over the world', NOT because it is a GOOD language, but because it
is a TRIVIAL language.  This makes it easy to implement (not a good thing - the
number of implementors we have working on Bliss is insignificant) on lots of
micros POORLY.

If you don't believe me about Bliss being MUCH more powerful than C, consider

	(1) The whole 'macro' mechanism

	(2) The whole 'structure' mechanism

	(3) The whole 'call/linkage' mechanism

In short, C is a structured assembler, nothing more.

/Bevin
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  27-DEC-1983 20:44           SMILEY::HENDERSON   

How did this note get to be religious?
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  28-DEC-1983 14:19           PIXEL::DICKSON     
				     * * *
But seriously, language chauvinism belongs in the special note
reserved for hostility.  I like Mumps and Forth myself.  There is
no way you can change anybody's mind about which language to use
unless that person actually uses the languages for something
more than toy applications, and sees the difference for
themselves.

Everyone I know who has been forced to use C this way, hated it.
Too low level.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  28-DEC-1983 23:35           SUPER::MORRIS      

As long as we're being nostalgic about languages I have fond memories of
Focal (liked it better than Basic).
							/Skip
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  31-DEC-1983 13:35           TSC::TOPSTEAM    

   Yes, as a matter of fact, once long ago (1976), I wrote a FOCAL interpreter
for a Z-80 system.  I can't say that it was fast, but we were able to
interchange games written in FOCAL between 8s, 10s 6502s and Z-80s with little
(or more usually) no changes.  It wasn't fast, but it was portable.
I really liked that language.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  31-DEC-1983 20:21           ATFAB::WYMAN       

Do you still have the FOCAL for Z-80s???? FOCAL was my first language
and I've still got tons of listings of what used to be fun games to
play. I'd love to be able to crank them up again on a Rainbow.

		bob wyman
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
   1-JAN-1984 13:46           PIXEL::DICKSON     

My first language too (in any depth).  A PDP-8/S with ASR-33 took
15 minutes to load the paper tape for FOCAL.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
   2-JAN-1984 18:35           SMILEY::HENDERSON   

Yeah!   Maybe we should start a note for DECies that cut their eye-teeth on
FOCAL (like myself).

 		Ken H
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
   2-JAN-1984 22:15           METEOR::MANN        

	Gee, FOCAL was my favorite language (not my first). It was
	the application language DEC sold with it's GAMMA-11 systems
	in the early 70's (Nuclear Medicine GAMMA camera interface).

	Now my favorite language is DCL (tongue in cheek).
					
							Bruce
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
   3-JAN-1984 10:49           PIXEL::DICKSON     


FOCAL bears a family resemblance to MUMPS.  I read somewhere that the
guy who did FOCAL started with MUMPS, then took out some of the more
complicated features, like the global file processor.  In many aspects
of syntax though, the two languages are identical.

(At least, with the way MUMPS was in the middle 60's.  The FOCAL-8
I used was dated 1968.)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
   3-JAN-1984 11:30           VAXUUM::DYER        

	FOCAL and the old teletypes and PDP-8's!  That brings back
memories...  I used to get so many questions from resume-readers
about FOCAL:  What is it?  Is it a graphics language?
	About C:  Yes, I suppose it is more low-level than BLISS
(like I said, I've never used BLISS).  And yes, I've seen some *very*
poor implementations of it on micros.  In fact, I've seen just about
every implementation of it hacked to pieces by micro wizards (just
how many versions *are* there of Ron Cain's small-c?)...
	But then again, if you're the type who *likes* to program in
assembly code (FOCAL was my third language; PAL-III assembler was my
second), C is a great way to get almost that close when switching
from system to system.
		<_Jym_>
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
   3-JAN-1984 14:40           BACH::PIERSON     

Actually, I suspect that both FOCAL and MUMPS came from JOSS - and early 60s
RAND language.  My introduction to FOCAL was on the PDP-15, both the DEC
version and a very nice extended version from DECUS.  It sure is a nice
little interpretive language - much nicer than BASIC.

							dan
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
   3-JAN-1984 14:54           REX::MINOW       

Well, to wrap this discussion up, there is a Focal running on
VMS that was written in C.  Sources were distributed with the
new Decus C kit (but Focal currently requires Vax-11 C for some
operating system support).

Having used C almost exclusively since 1978, may I point out that
its main advantage is that you can do 90% of the work with 10% of
the effort, as compared to any other readily available, transportable
language.

Maybe someone should start another note on language religion.

Martin.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
   3-JAN-1984 19:58           EIFFEL::HARRIS      

Again, I disagree.  The issue is:  Will we make more money by selling C
compilers or small systems?

I doubt that there could be an argument.  Even a 5% share (less than we already
have achieved) of the micro market will make us more money than selling C
(or any other kind) of compiler.

Note that this attitude comes from the project leader of one of the most
successful transportable languages ever (FORTRAN).

Look at all you hypocrites talking about FOCAL, we have locked people in with
that for years.

Thus, to sum up my position:

We should:
	1) Encourage all users of other machines to write transportable
	   software that we can get running on VAX quickly with our good
	   compilers.
	2) Try to lock in people to our machines as much as possible.  One
	   of the ways to do this is to use all possible advantages or our
	   hardware and software architecture.  Including using
	   non-transportable languages and features.
							-Kevin
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
   3-JAN-1984 23:42           VLNVAX::AMARTIN     

If you expect people to buy our small machines, then you get a choice:
Provide a C compiler, or let someone else provide it for you.
As long as the cost of purchasing hardware keeps going down compared to the
cost of writing and maintaining software, there will be more money floating
around to buy software "tools" like C than you make out.  And with a language
like C, we don't have to worry about our customer's maintainance costs
decreasing.

As far as using C internally goes, I am sure that it is quite easy enough
to write non-transportable garbage in C, just as it is in Bliss.  So we can
still lock people into any implementations we choose to write in C, if we
do a bad enough job of it.  And we can't be tied down by license fees to
another vendor's C compiler if we are going to implement much with it,
so there is another reason for having our own.

				/AHM (Another compiler project leader for one
				      of the world's most disgusting languages
				      (FORTRAN))
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
   4-JAN-1984 09:27           SMILEY::HENDERSON   
				     * * *
 		Ken H

(FOCAL hackers, let's take our nostalgia to another note. I can see we're not
welcome here...  these guys think they can actually win a religious argument -
I guess they've never seen ENET83 note 86)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
   4-JAN-1984 14:05           EIFFEL::HARRIS      

Alan, there are C implementations for VAXes, 11s, and Rainbows, what more could
you want?
	-Kevin
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
   4-JAN-1984 17:47           GOLD::WEAVER      

Hate to side track the discussion one more time, but here goes:  Are there
any SYS$NOTES:LANGUAGES.NOT files around anywhere?  A lot of discussion
that has transpired in here could be carried to such a file (with a lot of
interest I am sure).  Then we could have NOTES like FOCAL History, Bliss
Transportability, "C" Transportability, FORTRAN disgusts, etc...  If there
is none already and a Language type doesn't want to set one up, then I might
consider starting one.

						-Dave
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
   4-JAN-1984 23:12           VLNVAX::AMARTIN     

I percieved an assertion that C was an unimportant language in the marketplace,
and that it was a waste of time for DEC to develop C compilers.  That may not
be what you were trying to say, only what I percieved at the time.  I think
you were tying up a discussion whose beginnings I had forgotten.  Sigh.
				/AHM/THX
P. S.  It would be interesting to see an implementation of C that didn't
require license fees, fit in with the PDP-10 layered products and generated
reasonable code.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
   5-JAN-1984 00:52           HARE::STAN        

Look in NOTESLIST.NOT for notes lists of interest.

If the language of your choice (e.g. FOCAL) is not there,
then start a notes file of your own!
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
   5-JAN-1984 17:15           VAXUUM::DYER        

	Okay, all you religious types.  I've started a notes file on
VAXUUM for discussion of languages' merits, faults, and whatever else
you want to say about them.  Enjoy!
		<_Jym_>
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
   5-JAN-1984 17:17           VAXUUM::DYER        

	Oops...maybe I should mention where it is....
		VAXUUM::PUBLIC$NOTES:LANGUAGES
(Note that I don't use SYS$ on VAXUUM...)
	    <_Jym_>
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
   8-JAN-1984 17:08           EIFFEL::HARRIS      

I was not maligning C or any other language.  Language preference is a religion
that I don't indulge in.  I was simply saying that we should write compilers
for OUR machines only, and not for other people's machines, even cross
compilers.  To do so only converts sales of our hardware (e.g. MicroVAX) into
sales of other people's hardware (e.g. M68000).  Goodness knows, they have
enough of an advantage already without us making it worse.  The small sales
gains in the compiler license fees themselves would be insignificant compared
to the revenue loss from lost hardware sales.  The industry is fighting tooth
and nail, we must "lock in" to survive.  This includes all the things mentioned
in previous notes, including DECnet, VIA, our variety of compilers with
standardized run-time environments, DECTALK, accurate floating point, . . .
								-Kevin
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-