Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!ll-xn!mit-eddie!uw-beaver!cornell!batcomputer!itsgw!nyser!cmx!billo
From: billo@cmx.npac.syr.edu (Bill O)
Newsgroups: comp.arch
Subject: Re: numbers
Message-ID: <499@cmx.npac.syr.edu>
Date: 18 May 88 03:02:02 GMT
References: <11571@ut-sally.UUCP> <28200145@urbsdc> <11618@ut-sally.UUCP> <493@cmx.npac.syr.edu> <11512@mimsy.UUCP>
Reply-To: billo@cmx.npac.syr.edu (Bill O)
Organization: Northeast Parallel Architectures Center, Syracuse NY
Lines: 27

In article <11512@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>>In article <11618@ut-sally.UUCP> nather@ut-sally.UUCP (Ed Nather) writes:
>>>Unfortunately I have found no simple way to get the star to cooperate with
>In article <493@cmx.npac.syr.edu> billo@cmx.npac.syr.edu (Bill O) writes:
>>This is a perfect example of why we need higher-level languages
>>like lisp.  ... [On] overflow ... lisp just converts the representation
>	4 294 967 294
>	4 294 967 925
>	Entering GC; please wait.  Estimated delay: 7.24s
>	<numerous photons missed>
>One problem with higher-level languages is that they...
>...are not suited for real-time applications.

OK, I wasn't thinking of real-time control, and I should
have been because the photon counter was probably a
real-time application.  However, my comments do apply to
any application which is not real-time (dare I say, the
majority of applications :-)). As I said before, we still
need languages that are close to the machine, and
real-time control is one reason. But surely that
shouldn't saddle the rest of us.  And please, no GC
bashing. Non incremental GC was invented when Lisp was
done in batch. Now-a-days we have ephemeral and
incremental GC for interactive applications (but NOT
real-time).

Bill O'Farrell, Northeast Parallel Architectures Center at Syracuse University
(billo@cmx.npac.syr.edu)Newsgroups: comp.arch