Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site bu-cs.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!harvard!bu-cs!hen
From: hen@bu-cs.UUCP (Bill Henneman)
Newsgroups: net.ai,net.lang.lisp,net.lang.ada
Subject: Re: Speed with numbers: PDP-10 Maclisp vs. Fortran (details)
Message-ID: <253@bu-cs.UUCP>
Date: Sun, 17-Mar-85 13:58:19 EST
Article-I.D.: bu-cs.253
Posted: Sun Mar 17 13:58:19 1985
Date-Received: Tue, 19-Mar-85 04:57:33 EST
References: <242@bu-cs.UUCP>, <316@cmu-cs-k.ARPA>
Organization: Boston Univ Comp. Sci.
Lines: 21
Xref: watmath net.ai:2632 net.lang.lisp:396 net.lang.ada:236

I don't share the same set of ideals.  I can link FORTRAN (or PASCAL, or
PL/I, or whatever) routines in our LISP.  I can even fire up
supprocesses written in strange languages, and pipe the answers back.
Should I?  I think not, possibly because I have a stronger belief in the
Whorfian hypothesis for programming languages than for natural
languages.  If I want to build a system, I don't want to have to switch
languages in mid-development.  Niggling little details about
representation switching start using up all my hacking time, which I
would rather devote to the application level.  Do you link SNOBOL
routines when you want pattern matching?  I bet not.  Should you,
ideally?  By your argument, yes.

I have had the distinctly unpleasant experience of trying to fix a DEC
internal system which was written in OPS5, but fired up tasks written in

	o	BASIC
	o	BLISS
	o	COBOL(!)

Anyone acting in the role of program doctor would have done what I did.
I prescribed euthinasia.