🚀 go-pugleaf

Gee whiz!! It's amazing what happens when you go away for a week; truly
berserk outbreaks on the net [in comp.arch, of all places].  For some
reason my colleague Larry Weber [who runs the languages effort here, i.e.,
group who did all that zingy compiler technology] has chosen not to comment
on this.  However, I'm in a touchy mood [having been required to play
airline-guessing games to escape the snow in Washington], hence:

1. The MIPS R2000 wasn't particularly built to run COBOL fast.
   We didn't even take the small steps that the HP-Spectrum did to help it.
   I can't think of a single thing that we've sacrificed in favor of
   good COBOL-ness. REALLY, REALLY, WE'RE INNOCENT OF EXPECTING THAT:
2. Some of our customers/prospects discovered [to our astonishment, in some
   cases inventing amazing uses of some of our instructions] that the R2000
   actually looked like a fine COBOL engine (!!??!!)  This mostly comes from
   fast subroutine calls, some sneaky code-generation, and the effects you
   get from serious optimizing compiler technology, and the fact [documented
   by the Spectrum folks] that COBOL environments are mostly systems-type code
   that don't really spend much time doing decimal operations.
3. I know this may be astonishing out there in UNIX-land, but much of the
   world out there really uses COBOL, and it's often portable enough to move
   to new architectures.  When a whole bunch of large customers tell you that
   you need COBOL, you at least listen to them.  Sometimes they say things like
   "we really like your C, FORTRAN, PASCAL, etc, but we really need one
   architecture to cover both technical and commercial markets, so when will
   COBOL be available?" [You have noticed thjat DEC supports COBOL?]
4. Consider the current state of microprocessor languauges, as compared to
   minicomputer/mainframe compilers:
	a) The micro vendors have [often/sometimes] not invested upfront in
	high-quality optimizing compilers that use common components,
	compatible runtimes [where possible], etc.  The result is often
	a large gaggle of different compilers, runtimes, etc, in quality
	ranging from excellent to awful, which are supplied by combinations
	of microprocessor vendors, compiler vendors, and systems vendors.
	b) There are some fine compiler vendors out there; nevertheless,
	the confusion factor doesn't particularly help systems integrators
	or end users, who just want to g et a job done with a minimum of fuss.
5. Personally, I don't ever expect to write COBOL code, but I sure think it's
   important to have a good compiler for it that meshes well with our systems,
   and I'd much rather have Larry's [fine] compiler group doing it than to have
   our customers having to build complex 3rd-party deals to get what they
   need.  I'd much rather have 1 good COBOL system that people can count on.
   Thus, these comments are not particularly in favor of COBOL per se, but
   simply recognition of reality: any general-purpose computer vendor will
   need COBOL sooner or later, so it might as well be good.

Well, enough specific comments.  Let me observe that one of UNIX's strengths
has been the following combination:
	a) Elegant, insightful advances that looked beyond the state of the art.
	b) Willingness of people to adapt it as needed, even to environments
	otherwise alien, un-purist, or backward.
	c) Reduction of the "gulp factor", i.e., people avoid new technologies
	that make them discard everything they have.  They'd much rather move
	what they have, then convert it to newer technology over time.
	UNIX has snuck into a lot of environments this way, like when we helped
	UNIX let people edit COBOL and PL/I code and send it to IBM systems
	years ago [unpure! but it helped people get their work done, and many
	of the next round of projects was UNIX-based...]
Well, enough.....  and shame on you, Steve W: how can you give us a hard time
when you guys have put so much effort into doing well by that other nasty old
language, FORTRAN? :-) As you say, everyone has their price. :-)
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	{decvax,ucbvax,ihnp4}!decwrl!mips!mash, DDD:  	408-720-1700, x253
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086