two co-existing projects

[Mike Rilee]

From: Alexey Goldin <goldin@spot.uchicago.edu>
> Andreas Eder <are@laphroig.mch.sni.de> writes:
> > 
> > I opt for rewriting LAPACK (and other libs like QUADPACK) in
> > Lisp. Let's show them how powerful and fast Lisp can be. This would
> > make it possible to integrate that numerical libraries and symbolic
> > libraries like mma (from R. Fateman) into a powerful scientific
> > workstation. Throw in a TeX in Lisp system - what else do you want?
> > I certainly would be glad to work in a port of LAPACK to Lisp. That's
> > just what I pondered over last week, before this thread about a LispOS
> > started.
> 
> This may be a start of the third coexisting project --- applications
> in Lisp ;-). To which I would gladly contribute. Except that I have to
> note that rewriting existing stuff that was written by very
> knowledgable in their area people may be not a very good idea even if
> they wrote it in Fortran. This is (rewriting and reinventing the
> wheel) is after all what Microsoft is doing all the time.

The point is to turn cpus and other devices into something more useful
than space heaters. If the machine is big enough, it heats chilled-
water.  FORTRAN (including Fortran 90) implicitly assumes
a certain kind of machine that is designed neither for efficient development
of software, nor the development of efficient software.  As evidence for
this statement I offer the extensive sets of compiler directives (e.g.
for parallelizing compilers) and High Performance Fortran itself. 

The advent of interactive front ends to numeric and graphic libraries through
'fourth generation languages' is leading to a dramatic change in the way
students, scientists, and engineers are doing (numeric) math with the computer. However, many of these 4GLs are not general purpose programming languages, and are
not designed with efficiency in mind.  The library code itself may be well
optimized (for single cpu machines etc.), and if your problem fits that toolset,
then you might not get hurt too much.  As a side note, the current
crop of symbolic algebra packages have not been designed with heavy-duty
number crunching in mind.  Such packages usually punt, and have facilities
to generate or link to foreign code (usually FORTRAN/C through a descendent 
of GENTRAN).

Finally, with regard to reinventing wheels: I would rebuild a house out of the
flood plain. I have no desire to remain in the UNIX swamp. My, those CRAYs boot
fast (and often)!

The main reason to avoid translating *PACK code to lisp is errors and tedium. 
R. Fateman (and others) have done some work with machine tranlation of *PACK
FORTRAN into lisp, with good results. That would help leverage some
functionality, but there's nothing to prevent one from adding better routines.
*PACK is not gospel, but merely (often) decently written, trusted code.
Furthermore, trust is subjective, and sometimes misplaced.

> From: Luca Pisati <pisati@nichimen.com>
> What is actually really hurting us, is that type-propagation
> information in the compiler is not first on the list of Lisp vendors.

(SGI/CRAY, ACL, Harlequin, anybody home?)

I am following developments in the lisp (and oberon) communities because
an integrated OS written in a sane language will be efficient for both
software development and execution.  Passing persistent objects from a
big compute server to a tape-robot sounds like a good idea to me. 
The abstract division of operating-system vs. application doesn't help
me manage and move around the sometimes immense amount of data that
result from large scale computations.  (The 'transparent ftp' talked
about by the Gnu folks seems almost quaint in this light.)

But first I'd like to see a few successes and some functionality. I agree
with Baker's admonition to start simple, and address issues such as memory
and time management: I think this fits in with those who are leaning towards
a Tunes-like project. Also, I would take a page from the Oberon project
and note that the compiler will play a central role in the development
of a successful lispy os.

BTW. CMUCL sounds quite good. Especially the stuff about functions having the 
right branches...  And I'd almost forgotten about Python's successes. Something
based on CMUCL might be a good testbed while generating some notoriety that 
would help the acceptance of, say, Tunes.

To conclude, I suppose I would prefer to see something along the lines of
Tunes, but there does seem to be an opportunity to build an expedient,
but useful CL system that addresses some of the needs of Web developers.
In fact, I would be more in a position to use a good CL for some 
computationa and visualization work, but I'd prefer Tunes to UNIX/FORTRAN/C/C++.

>From: "Reginald S. Perry" <perry@zso.dec.com>
> >"Kelly" == Kelly Murray <kem@Franz.COM> writes:
> 
> 
> > Just for the record, Microsoft's approach was not my inspiration for
> > the idea, but I would like to think it is validation of it.
> 
> I just want to get this straight. You feel that the desktop is the web
> browser. You do not feel that the web is an extension of the
> desktop. 

I look at the web as an extension of my databus.

Mike Rilee
NRC/NASA/GSFC mrilee@hannibal.gsfc.nasa.gov