Common LISP: The Next Generation
P. Srinivas
The fall and Rise of LISP (or Lisp in 21st Century)
===================================================
Why are they so many splinter groups in LISP community? The strength
of LISP as an experimental vehicle contributed to its own misery. So
many dialects so few users!!
It took almost two decades to the world to realise the strengths of
LISP. Everybody is reinventing LISP in some form or other, some call
it Dylan, some other call it Java yet some more call it TCL. Yet some
people still call the good old name Scheme. People do not want to use
the word LISP. That is fine. A rose is in any name is a rose. But why
so many splinter groups? Apple started Dylan and now it is a defunct
language even before it is born. Tom Lord started Guile and now he
quits Cygnus; may be Guile is a dead language again. Whenever somebody
gets a new idea, he starts of a new dialect. I do not think it is
necessary to do that. If we have a common substrate then everybody can
start from there and build an extension package library.
Why not unite many of these "LISP"s under one umbrella? It is
perfectly feasible to define a common core and various extensions to
suite various needs. LISP as a hierarchy with the core functionality
as its root and various extensions as specialisations of the core
system. If I want to start a new LISP, I do not need to start from
scratch, Just add my extensions to the existing core!
Common LISP was a major step forwards. Thanks to many people. Since we
have ANSI standards, why dump all the success and everybody going in
their own way? Here we have an industrial strength tried and tested
language used in commercial world. Why not try improve the Common
LISP. Yes I am saying that it is time to work on new version of ANSI
Common LISP 2.0 or call it Common LISP 2000 to reflect the language of
the next century.
The following are some of my wish lists for the Common LISP: The
Next Generation.
1. Layered architecture (possibly a hierarchical) + autoloaded
libraries a la EULISP. Small executables are possible.
2. Clean and well integrated object system and MOP a la Dylan
3. Simplified package system
4. Cleaning of many builtins and possibly removing a few redundant
ones
5. A standard network interface
6. A standard interface for persistent object oriented database
7. A standard for multiprocessing with lightweight threads
8. Ability to create applets for Web based systems
9. Multi-media bindings such as JPEG and MPEG etc..
Current Common LISP is inadequate as a future programming language
without new features such as threads etc.
I think a time will come again where an OS will be implemented in LISP
again. LISP machine was not a failure. It was just too early for the world.
All the Lispers of the world unite! we have nothing to loose but a few
dialects! :-)
Srini
--
URL http://www.cs.usask.ca/homepages/grads/srini/
--------------------
Srinivas Palthepu Email: sr...@cs.usask.ca
ARIES laboratory, Phones: (306) 966-8654 (lab)
Department of Computer Science, (306) 966-4759 (office)
University of Saskatchewan, (306) 373-6724 (home)
57 Campus Dr, Saskatoon, SK, S7N 5A9 Fax: (306) 966-4884
John Brewer
In article <sjpw4hb...@alfresco.usask.ca>, sr...@alfresco.usask.ca (P.
Srinivas) wrote:
> The following are some of my wish lists for the Common LISP: The
> Next Generation.
>
> 1. Layered architecture (possibly a hierarchical) + autoloaded
> libraries a la EULISP. Small executables are possible.
>
> 2. Clean and well integrated object system and MOP a la Dylan
>
> 3. Simplified package system
>
> 4. Cleaning of many builtins and possibly removing a few redundant
> ones
>
> 5. A standard network interface
>
> 6. A standard interface for persistent object oriented database
>
> 7. A standard for multiprocessing with lightweight threads
>
> 8. Ability to create applets for Web based systems
>
> 9. Multi-media bindings such as JPEG and MPEG etc..
It's been done. It's called Java. You might want to look into it sometime.
John Brewer Senior Software Engineer Spyglass, Inc.
Opinions expressed do not necessarily reflect those of my employer.
Heck, I'm old enough to remember the _first_ time Apple was "doomed".
Carl L. Gay
From: jbr...@spyglass.com (John Brewer)
Date: Fri, 23 Aug 1996 17:54:43 -0500
In article <sjpw4hb...@alfresco.usask.ca>, sr...@alfresco.usask.ca (P.
Srinivas) wrote:
> The following are some of my wish lists for the Common LISP: The
> Next Generation.
>
> 1. Layered architecture (possibly a hierarchical) + autoloaded
> libraries a la EULISP. Small executables are possible.
>
> 2. Clean and well integrated object system and MOP a la Dylan
>
> 3. Simplified package system
>
> 4. Cleaning of many builtins and possibly removing a few redundant
> ones
>
> 5. A standard network interface
>
> 6. A standard interface for persistent object oriented database
>
> 7. A standard for multiprocessing with lightweight threads
>
> 8. Ability to create applets for Web based systems
>
> 9. Multi-media bindings such as JPEG and MPEG etc..
It's been done. It's called Java. You might want to look into it sometime.
Don't know if that was supposed to be flame bait or not, but...
Yes, Java has many of the things on the above list, but what the
original poster was asking for was to add them to Common Lisp. That
request probably wasn't just accidental but rather a reflection of the
fact that Common Lisp is in many ways a more complete *language* than
Java, even though it lacks *standard* versions of most of the above.
He might just as well have proposed the following:
The following are some of my wishes for Java: The Next Generation.
A. Higher order functions
B. Multiple inheritance
C. Multimethods
D. Macros
To which someone would reply "It's been done. It's called Common
Lisp. You might want to look into it sometime."
Dylan, on the other hand not only has A - B, but also has 1, 2, 3, and
4. Personally, I hold out more hope that Dylan will add threads and a few
standard libraries than that Java will add A - D, which are
indispensable for large system development. Java's great for what it
does, but it's not a replacement for Common Lisp in many ways.
[comp.lang.tcl removed]
Philippe Troin
>>>>> "John" == John Brewer <jbr...@spyglass.com> writes:
John> It's been done. It's called Java. You might want to look
John> into it sometime.
Java is not LISP. Java is a C++ bastard.
Tcl is not LISP neither. Though Tcl has the idea of list, processing
lists in Tcl is painfully slow.
Phil.
Rainer Joswig
> so many splinter groups? Apple started Dylan and now it is a defunct
> language even before it is born.
They still have NewtonScript. People programming the Newton
are using a language with Lisp semantics. Don't tell them. ;-)
> Common LISP was a major step forwards. Thanks to many people. Since we
> have ANSI standards, why dump all the success and everybody going in
> their own way? Here we have an industrial strength tried and tested
> language used in commercial world. Why not try improve the Common
> LISP.
This is exactly my position, too. Some people might consider
Common Lisp unfixable. ;-)
> The following are some of my wish lists for the Common LISP: The
> Next Generation.
>
> 1. Layered architecture (possibly a hierarchical) + autoloaded
> libraries a la EULISP. Small executables are possible.
Seems difficult.
> 2. Clean and well integrated object system and MOP a la Dylan
We already have CLOS, which I think is quite nice. Let all
vendors implement the MOP. Many stuff in commercial CLs is
based on CLOS (pathnames, streams, conditions, ...). Make
it standard.
> 3. Simplified package system
Hmm.
> 5. A standard network interface
Yes, we need a common interface to TCP/IP services.
> 6. A standard interface for persistent object oriented database
Yes, we all would like that.
> 7. A standard for multiprocessing with lightweight threads
Some people think we should use the stuff CLIM. Why not? Should
be extended to handle multiple processors.
> 8. Ability to create applets for Web based systems
I would like to see the following:
- a mechanism to generate multiple secure packages at runtime
- the package gives you access to secure versions of
CL functionality
- code can be loaded (and compiled is necessary) into that package
- code can be safely executed in this package
- after execution finishes, remove the packages and clear all waste
- have a monitoring mechanism, which ensures the proper
behaviour of the code
> 9. Multi-media bindings such as JPEG and MPEG etc..
gzip and some graphics stuff in Lisp would be fine.
> Current Common LISP is inadequate as a future programming language
> without new features such as threads etc.
Commercial CLs have had threads for quite a while.
> I think a time will come again where an OS will be implemented in LISP
> again. LISP machine was not a failure. It was just too early for the world.
With current processors this thing would fly.
Additionally we need:
- a common FFI
- a common interface to SOM, CORBA, ...
- a common GUI (free CLIM !)
- mechanism for compile time type checking
But most of all we need a fair amount of people willing to work
on that stuff. I'm not optimistic. But still there are some
Lisp hackers out there who are developing useful code
(example: see the CL-HTTP stuff). I'm not interested in
developing technology just because it is fun. Lisp still
is being used in the high-end areas. Bring
it to the masses.
It has to have real value for users:
- speed up our development
- increase code quality
- increase reuse
- and most important it should lead to usable, fast, stable and
portable software that solves real problems
Stop wasting your time reinventing *nix for nth time.
Rainer Joswig
Olin Shivers
From: jos...@lavielle.com (Rainer Joswig)
Subject: Re: Common LISP: The Next Generation
> 5. A standard network interface
Yes, we need a common interface to TCP/IP services.
My student, Brian Carlstrom, designed and implemented a very nice TCP/IP
package for scsh two years ago that is the most complete and attractive
sockets interface I have seen to date for Scheme. It allows full access to
Unix sockets (Unix domain, as well as TCP/IP, actually). If you can do it from
C, you can do it from Brian's Scheme interface, but in a Schemey (i.e., less
painful) way. Brian's design also provides useful high-level interfaces that
make it very easy to write, for example, network servers. You can still drop
down to the low-level procedures when you need to do something non-standard.
I would like to encourage people who want TCP/IP interfaces for Scheme to just
*steal Brian's interface*. It is completely laid out in the scsh manual. The
source comes with every copy of scsh.
No need to reinvent wheels once they've been done well once.
-Olin
Cyber Surfer
In article <joswig-2408...@news.lavielle.com>
jos...@lavielle.com "Rainer Joswig" writes:
> Stop wasting your time reinventing *nix for nth time.
My only interest in *nix that so many Lisps (and other languages
that interest me) tend to use it. If somebody stripped Linux down
to the absolute basics (the minimum number of daemons, for example).
_No_ web, mail, or news servers.
Now that CMU Common Lisp is available for Linux, a stripped Linux
might be a perfect "Lisp Machine". I could get a 2nd machine, and
access it from my NT box by running a X server or telnet client.
If I really wanted *nix, I'd be using it already. However, I don't
currently have that choice, as my NT box won't run Linux.
Instead, I'm using the web version of Allegro CL for Windows. Not all
the Common Lisp code I want to use (Screamer, Series functions, etc)
will run (erm, compile) in this Lisp. I dunno if CMU CL can cope with
it, either, but I'd at least like a chance to find out.
I'm a complete newbie as far as Linux is concerned, and compared
to the people who written most of the CL code I'm interested in,
I'm practically a CL newbie, too. Code that uses EVAL-WHEN is way
beyond me. So, whatever I do, I'll need help. At the moment, all
I can do is either ask for help, or play with something else.
For years, people have been telling me that I'm using the wrong
platform to do what I want (whatever it happens to be at the time).
This is why I've been considering Linux for the last few years.
If all the things that are of no interest to me (_all_ the non-Lisp
bits!) could be removed, making it look as much like a Lisp Machine
as possible, then I _might_ be able to do something...
On the other hand, perhaps I should just continue to struggle
with Allegro CL for Windows. After all, I get paid to write
Windows software, even if it's not in Lisp. By waiting a few
years, I'll be able to use Gwydion for NT. Even if I never get
paid to develop in Dylan, at least I'll have something decent
that I can play with in my own time.
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
I have it at last: 'And She Closed Her Eyes', by Stina Nordenstam
Ashley Branchfeather
In article <CGAY.96Au...@plastix.cs.uoregon.edu>,
cg...@plastix.cs.uoregon.edu (Carl L. Gay) wrote:
>A. Higher order functions
>B. Multiple inheritance
>C. Multimethods
>D. Macros
...
>Dylan, on the other hand not only has A - B, but also has 1, 2, 3, and
>4.
You meant A - D here, right? Dylan has macros and multimethods.
--
Ashley Branchfeather
Sean Doran
-----BEGIN PGP SIGNED MESSAGE-----
shi...@ai.mit.edu (Olin Shivers) writes:
> I would like to encourage people who want TCP/IP interfaces for Scheme to just
> *steal Brian's interface*. It is completely laid out in the scsh manual. The
> source comes with every copy of scsh.
As if Dr Shivers needed any support for his endorsements,
and mine would have any weight, scsh's networking
interface has been of incredible utility in developing
ad-hoc network monitoring and analysis scripts here at
Sprint, and has seen quiet use by one of our vendors too.
Sean.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: PGP Public Key in ftp://ftp.sprintlink.net/engineer/smd/pgpkey
iQCVAwUBMiAKKkSWYarrFs6xAQHegAP+NF7vZQz7LMDlPMMd/XloK1bPoEnsxodu
lF3X2EEGN+ueMP9iQqSI16sSg03qJW85H/udbJJwxhHFiiYRA0nh0FDbTI9MiV6J
/70Ek8hi3yu10m5xKWRPwk6xbeNQu3BW48YMs6+iN8zQgzMUob8nDYPpO3r2HONF
ofiSwFig4xg=
=l0Jm
-----END PGP SIGNATURE-----
mathew
[ Massive cross-posting trimmed. ]
In article <sjpw4hb...@alfresco.usask.ca>,
P. Srinivas <sr...@alfresco.usask.ca> wrote:
>Why are they so many splinter groups in LISP community? The strength
>of LISP as an experimental vehicle contributed to its own misery. So
>many dialects so few users!!
There are a zillion dialects of BASIC, and people still use it. There
was a True BASIC dialect which was multi-platform, but it died a
death.
>Why not unite many of these "LISP"s under one umbrella? It is
>perfectly feasible to define a common core and various extensions to
>suite various needs.
True enough. If your core is defined properly, you can extend the
language arbitrarily.
>Common LISP was a major step forwards. Thanks to many people. Since we
>have ANSI standards, why dump all the success and everybody going in
>their own way? Here we have an industrial strength tried and tested
>language used in commercial world. Why not try improve the Common
>LISP.
Because many people feel that to improve on Common LISP, you'd have to
throw most of it away. Or rather, move most of it out into packages
and libraries, rather than the core language.
If you're going to do that, and sacrifice compatability, you might as
well start with an existing well defined clean core language, like
Scheme, and build the libraries on top of that. Which is pretty much
what the Scheme community seem to be trying to do.
[ Modulo occasional attempts to introduce evil stuff like eval :-) ]
>Yes I am saying that it is time to work on new version of ANSI
>Common LISP 2.0 or call it Common LISP 2000 to reflect the language of
>the next century.
2000 is this century. I think you mean 2001.
>1. Layered architecture (possibly a hierarchical) + autoloaded
> libraries a la EULISP. Small executables are possible.
I'm really not a fan of autoloaded libraries in any language. When I'm
looking at some code, I want it to be clear and explicit what is being
loaded from where. Of the languages I've tried so far, I'm happiest
with the way Modula-2 handles libraries; name the library *and* each
visible function you want from it.
>8. Ability to create applets for Web based systems
Presumably you mean you'd like it to be able to compile to the Java
virtual machine?
The rest of your list seems reasonable.
>I think a time will come again where an OS will be implemented in LISP
>again. LISP machine was not a failure. It was just too early for the world.
Well, I think it might be worth enumurating some of the reasons why
people don't use Lisp:
1. No cheap easy-to-use development system for their machine.
I can download JDK from the net; I can get a C or C++ development
system for $150. If only Borland would produce "Turbo Scheme"...
2. Can't compile to a small standalone executable.
True for many Lisps. I have something I call the "hello world test".
You build a standalone "hello, world", and look at the size of
the executable. If your OS supports a GUI, you produce a simple
"one movable window" GUI version too. Lisps often do badly in this
test.
3. Not enough access to standard OS libraries. A C FFI is not good enough.
4. Performance.
This is largely a problem of misperception, but clearly there is
still an issue, even if it's one of education. One thing I saw
recently was the MS-DOS arcade game "Abuse". It's a fast
high-quality Aliens type game, which was praised by a number of
magazines. If you look at the README and stuff, though, you
discover that it's written in LISP, and built using a
cross-platform game development toolkit. Getting stuff like that
out there would help with the perception problem.
Performance isn't the be-all and end-all, though. Java has abysmal
performance on my Mac; it's about as fast as HyperCard. Yet it's
still managing to catch on.
5. Syntax.
Some people like syntaxy languages. That's just a matter of
taste.
6. Lack of coolness.
Sad but true. A lot of people are learning Java not because they
can do anything useful with it, but because it's "cool" and will
maybe look good on a CV.
7. Hard to port to other platforms.
You can develop cross-platform in Common LISP, of course; but
Scheme really falls down here. And Java, of course, wins big.
It's not that everyone actually wants to develop cross-platform;
it's more that they need to feel that they could. The industry's
so fickle that you never know when you might have to port your
code.
In some niche areas, strong multi-platform support can help a
language thrive even if it has little else to commend it. Look at
how Inform thrives in the interactive fiction development stakes,
in spite of being ugly and slow to compile. The fact that the
compiled code can run on everything from an Apple Newton to a UNIX
workstation to a TRS-80 is more of a benefit than one might
imagine.
8. Hard to learn.
This is one of the real problems with Common LISP. It is *huge*.
Learning CL, CLOS and CLIM is a major task, even if you know
another LISP. One of the reasons C++ is losing to Java is that C++
takes several years before you can really get proficient, because
it's just such a big language; yet compared to Common LISP, it's
small.
This is the real reason why I think "Common LISP 2001" would be
doomed to failure, if it were "Common LISP with more cool stuff
in".
mathew
--
me...@pobox.com home page with *content* at http://www.pobox.com/%7Emeta/
Help prevent economic bias on the net - support the Open Text Boycott
See http://www.pobox.com/%7Emeta/rs/ot/ for details
Cyber Surfer
> >8. Ability to create applets for Web based systems
>
> Presumably you mean you'd like it to be able to compile to the Java
> virtual machine?
Hasn't that been done? I thought I read something about a Scheme to
JVM compiler somewhere. Perhaps I'm mistaken.
> Well, I think it might be worth enumurating some of the reasons why
> people don't use Lisp:
That's a good idea. Some of those reasons are damned annoying,
but persistant.
> 1. No cheap easy-to-use development system for their machine.
>
> I can download JDK from the net; I can get a C or C++ development
> system for $150. If only Borland would produce "Turbo Scheme"...
I can (and did) download the "web" version of Allegro CL for
Windows, but this is not a complete system, and it has limitations
(it's a demo version, after all). To buy it would cost $600, and
to create stand alone apps, I'd need to spend $2500 on the full
version.
> 2. Can't compile to a small standalone executable.
>
> True for many Lisps. I have something I call the "hello world test".
> You build a standalone "hello, world", and look at the size of
> the executable. If your OS supports a GUI, you produce a simple
> "one movable window" GUI version too. Lisps often do badly in this
> test.
I don't even know if ACL for Windows can do the things I need,
like use OCX controls, and produce "small" binaries. Smaller
than 6 MB, for example. In fact, I need binaries smaller than
2 MB. Runtime code in a DLL might also help, but ACL appears
not to support this (yet).
I love Lisp, but these problems ensure that I continue to develop
in C++. <sigh>
> 3. Not enough access to standard OS libraries. A C FFI is not good enough.
Definitely. I'm not writing code that just happens to run under
NT. I'm writing Win32 apps. I'd _like_ to write them in Lisp, but
there's nowhere near enough OS support.
> 4. Performance.
>
> This is largely a problem of misperception, but clearly there is
> still an issue, even if it's one of education. One thing I saw
> recently was the MS-DOS arcade game "Abuse". It's a fast
> high-quality Aliens type game, which was praised by a number of
> magazines. If you look at the README and stuff, though, you
> discover that it's written in LISP, and built using a
> cross-platform game development toolkit. Getting stuff like that
> out there would help with the perception problem.
I need to write multimedia apps. Support for OCX might help, but
that's a cope out. The OCX controls will be written in C++. I'm
not convinced that Lisp is slow, but perhaps many Lisps are designed
for much larger (and less interactive? realtime?) apps that games
and other multimedia software.
> Performance isn't the be-all and end-all, though. Java has abysmal
> performance on my Mac; it's about as fast as HyperCard. Yet it's
> still managing to catch on.
Similar languages, like VB, are incredibly popular, dispite being
less "efficient" than C++. One of the reasons is support for C/C++
code via VBX/OCX controls and DLLs. A DLL can be supported by an
FFI, which VB has, while VBX/OCX support is even better. OLE goes
even further.
I dunno if HyperCard performance can be "assisted" by compenents
written in C/C++, and I doubt that Java can either. Not yet.
Why should some other language, like Lisp, not benefit? I don't
know of any good reason, so I'm waiting for Franz to add OCX
support in the next version of ACL for Windows.
> 5. Syntax.
>
> Some people like syntaxy languages. That's just a matter of
> taste.
Lisp programmers have clung to what appears to most other people
as a very odd syntax. I like it, but then I dislike infix. I don't
expect everyone to share my feelings. In fact, I expet them to
be seriously intimidated by the "standard" Lisp syntax.
Dylan dares to break with traditions.
> 6. Lack of coolness.
>
> Sad but true. A lot of people are learning Java not because they
> can do anything useful with it, but because it's "cool" and will
> maybe look good on a CV.
True. I find Java a rather dull language, but then I'm used to
the weird and wonderful features of Lisp. I don't expect many
people not familiar with Lisp to appreciate this.
> 7. Hard to port to other platforms.
>
> You can develop cross-platform in Common LISP, of course; but
> Scheme really falls down here. And Java, of course, wins big.
I've failed to get the few bits of other people's CL code to
work with ACL for Windows, but they _were_ difficult examples.
However, I'm a little concerned about compatibility.
My experience with Scheme doesn't include using code written
for a Scheme that I'm not using myself.
Java's success speaks for itself. Who can tell which machine
was used to write a Java applet? Who cares?
> It's not that everyone actually wants to develop cross-platform;
> it's more that they need to feel that they could. The industry's
> so fickle that you never know when you might have to port your
> code.
Some of us simply need a language that works on one platform,
the one we're currently using. True, I might someday have to
stop using Windows, and move to another OS. However, I don't
expect it to happen this decade...
Too bad Lisp support for Windows is so weak, esp when compared
with C++, Pascal, Basic...The market is big, but so little of
it (relatively speaking) is being exploited by Lisp developers.
> In some niche areas, strong multi-platform support can help a
> language thrive even if it has little else to commend it. Look at
> how Inform thrives in the interactive fiction development stakes,
> in spite of being ugly and slow to compile. The fact that the
> compiled code can run on everything from an Apple Newton to a UNIX
> workstation to a TRS-80 is more of a benefit than one might
> imagine.
Strong Windows support could make a far bigger difference.
Fortunately, CMU are planning to support Windows (Win32,
anyway - Win16 is practically dead) with their Dylan. I'm
hoping they'll include OCX support.
> 8. Hard to learn.
>
> This is one of the real problems with Common LISP. It is *huge*.
> Learning CL, CLOS and CLIM is a major task, even if you know
> another LISP. One of the reasons C++ is losing to Java is that C++
> takes several years before you can really get proficient, because
> it's just such a big language; yet compared to Common LISP, it's
> small.
Lisp is not CL. Perhaps the future is Dylan? I think so. CL has
_lots_ of problems, including a lot of historical baggage that
the Dylan designers threw away. Stop thinking that Lisp has to be
Common Lisp, and Lisp may have a more healthy future.
> This is the real reason why I think "Common LISP 2001" would be
> doomed to failure, if it were "Common LISP with more cool stuff
> in".
I've already given up on CL. It has failed me for years.
Perhaps Dylan will serve me better. I dunno when I'll know
for sure, but I can wait.
Ashley Branchfeather
In article <joswig-2408...@news.lavielle.com>,
jos...@lavielle.com (Rainer Joswig) wrote:
>In article <sjpw4hb...@alfresco.usask.ca>, sr...@alfresco.usask.ca (P.
>Srinivas) wrote:
>
>> so many splinter groups? Apple started Dylan and now it is a defunct
>> language even before it is born.
>
>They still have NewtonScript. People programming the Newton
>are using a language with Lisp semantics. Don't tell them. ;-)
I hear Apple originally acquired Dylan for the purpose of using it for the
Newton.
--
Ashley Branchfeather
Kjetil Valstadsve
Cyber Surfer <cyber_...@wildcard.demon.co.uk> writes:
> In article <4vp93n$f...@snotra.harlequin.co.uk> me...@pobox.com "mathew" writes:
> Hasn't that been done? I thought I read something about a Scheme to
> JVM compiler somewhere. Perhaps I'm mistaken.
Guess not. Per Bothner's Kawa scheme interpreter in Java does some
compiling. As for a real compiler, we're working on it this semester,
and hopefully we'll be able to come up with something. If anyone is
interested, please get in touch.
> Java's success speaks for itself. Who can tell which machine
> was used to write a Java applet? Who cares?
Or what language.
> I have it at last: 'And She Closed Her Eyes', by Stina Nordenstam
Hey, so do I :)
--
Kjetil Valstadsve <ed...@pvv.unit.no>
avsnitt www.pvv ~eddie
.. avsindig avsindig og alltid bare i begynnelsen av tiden
Rainer Joswig
>Re: Common LISP: The Next Generation
>From me...@pobox.com (mathew)
>Date 25 Aug 1996 11:15:19 +0100
>Because many people feel that to improve on Common LISP, you'd have to
>throw most of it away.
Not me. I do consider Common Lisp a quite practical language.
(Yes I have used Scheme and don't like it that much
nowadays.)
The Scheme people have thrown away a lot useful stuff and
now they are looking into putting it back into the
language (just read the recent threads on comp.lang.scheme).
Once they have it - it will look like CL. It will be more
complicated then before. Yeah, let's reinvent the wheel.
Scheme doesn't make the function/value cell distinction,
has call-with-current-continuation, is small, ... But then?
Besides that it has no obvius advantages for
writing software compared to CL.
Reasons I do like Common Lisp (my random collection):
- flexible arglists with keyword arguments
- closures
- cool object system
- easy to learn and use
- excellent integrated development environments with incremental compilers
- ANSI standard ensures portability
- declarations (types, compiler hints, ...)
- large standard library (optimizing the implementation of this stuff
has effects for many users!)
- FFIs
- good UIMS available
- excellent stability of development environments
- excellent literature available
- excellent software available (ported to a wide range of machines)
- fast
> 1. No cheap easy-to-use development system for their machine.
>
> I can download JDK from the net; I can get a C or C++ development
> system for $150. If only Borland would produce "Turbo Scheme"...
See Digitool's (http://www.digitool.com/) Macintosh Common Lisp.
Last time I looked they had very competetive pricing for
this excellent product.
> This is largely a problem of misperception, but clearly there is
> still an issue, even if it's one of education. One thing I saw
> recently was the MS-DOS arcade game "Abuse". It's a fast
> high-quality Aliens type game, which was praised by a number of
> magazines. If you look at the README and stuff, though, you
> discover that it's written in LISP, and built using a
> cross-platform game development toolkit. Getting stuff like that
> out there would help with the perception problem.
Abuse is not written in Lisp. It uses Lisp for some high-level stuff.
The underlying animation engine is not written in Lisp.
> Performance isn't the be-all and end-all, though. Java has abysmal
> performance on my Mac; it's about as fast as HyperCard. Yet it's
> still managing to catch on.
Some Common Lisps are quite fast. Still problems remain (32 bit arithmetic
on machines with 32 bit words, CLOS, ...).
> 8. Hard to learn.
>
> This is one of the real problems with Common LISP.
I disagree. Common Lisp is not difficult to learn.
> It is *huge*.
Well, it's easy to start simple in Common Lisp. You don't need
to introduce how to define method combinations in the first
two hours. As you need more of its power, learn more step by step.
> Learning CL, CLOS and CLIM is a major task,
To master it, you're right. But starting with CL and CLOS is easy.
CLIM on the other hand lacks introductory material, lacks
working examples, lacks a larger user base, lacks a free version...
Sigh. I'd wish more people could use it.
> One of the reasons C++ is losing to Java is that C++
> takes several years before you can really get proficient, because
> it's just such a big language; yet compared to Common LISP, it's
> small.
C++ ??? Common Lisp is really simple compared to C++. STL? Templates?
The object and type systems of C++ are really complicated. The syntax
is ugly and unreadable (atleast for me). All you need in CL
is to understand the basics of the syntax (lists, some data types),
the basic semantics (the evaluation rules), a bit of the library
and off you go. Later you will need a bit of CLOS (how to define
classes and methods, inheritance, slots, generic functions).
Rainer Joswig
Paul R. Potts
In article <AshleyB-2508...@news.halcyon.com>,
Ash...@halcyon.com (Ashley Branchfeather) wrote:
> I hear Apple originally acquired Dylan for the purpose of using it for the
> Newton.
In prototype, unreleased versions of the Newton project, Dylan or a
precursor to it (infix syntax, legend has it called Ralph?) was used.
The NewtonScript language, used for most Newton application development,
is actually very cool and I recommend that anyone interested in language
design take a look at it. While it isn't as featured as something like
Dylan, you get:
- very simple syntax, very small language, uncluttered design
- dynamic
- introspection features
- Compile ()
- every expression returns a value - uniform syntax
- closures
- a built-in mechanism for dual inheritance
- designed for very small RAM footprint
- built in data types for dynamic arrays, associative arrays (frames),
Unicode strings
Unfortunately, there is no stand-alone implementation. I think it would
make a good teaching language, introducing concepts of procedural
programming, recursion, object-oriented programming, inheritance, and
many of the things that are now taught using Lisp.
In fact, using Newt or some yet-to-be-written
development environment that would let you write NewtonScript on the
Newton, you could have a $700 student development workstation, with
keyboard; a faster Newton with more memory and a larger screen that
can fit in a student's backpack and support a development environment
as well as provide e-mail and web surfing would be quite cool.
-Paul-
Paul R. Potts - Project Engineering Lead - Health Media Research Lab
Comprehensive Cancer Center, University of Michigan - po...@umich.edu
Andreas Bogk
>>>>> "Olin" == Olin Shivers <shi...@ai.mit.edu> writes:
Olin> My student, Brian Carlstrom, designed and implemented a very
Olin> nice TCP/IP package for scsh two years ago that is the most
Olin> complete and attractive sockets interface I have seen to
Olin> date for Scheme. It allows full access to Unix sockets (Unix
If it is an sockets interface, it suffers the same shortcomings the C
socket interface interface has. One thing that is impossible with
sockets is finding out where a connection request is coming from,
without actually accepting the connection.
Of course I do appreciate the existence of packages for different
APIs. But I think it's a bad idea to use mediocre APIs as a basis for
standardization.
Andreas
--
Kallisti!
Scott Draves
>>>>> "Rainer" == Rainer Joswig <jos...@lavielle.com> writes:
> In article <4vp93n$f...@snotra.harlequin.co.uk>, me...@pobox.com (mathew) wrote:
mathew>> Because many people feel that to improve on Common LISP, you'd have
mathew>> to throw most of it away.
Rainer> Not me. I do consider Common Lisp a quite practical language.
Rainer> (Yes I have used Scheme and don't like it that much nowadays.)
Rainer> The Scheme people have thrown away a lot useful stuff and now
Rainer> they are looking into putting it back into the language (just
Rainer> read the recent threads on comp.lang.scheme). Once they have
Rainer> it - it will look like CL.
yes and no. the feature list may be as long, but the details will be
quite different. the reason Scheme `threw out' so much of CommonLISP
wasn't because they considered things like records and exceptions were
superfluous, but because they wanted to Do It Right. CommonLISP is
the expediant compromise and union of (then) existing lisp systems.
Scheme was the intersection: everything that they could agree was
Right. features weren't to be added until they could be done Right
(as agreed by a committee. key word here.) This has resulted in
significant differences from CommonLISP in areas that have since been
reconstructed, such as macros. more will follow.
i think *some* Schemers have a small-at-all-costs attitude, but please
don't condemn the group.
--
balance
equilibrium
death
Per Bothner
In article <jw47mqme8...@voldsboks.pvv.ntnu.no>,
Kjetil Valstadsve <ed...@voldsboks.pvv.ntnu.no> wrote:
>Guess not. Per Bothner's Kawa scheme interpreter in Java does some
>compiling.
What do you mean by "some compiling"? Everything inside a lambda
is compiled. Top-level forms when interpreted are not compiled,
though they could be. (I don't think it would make sense,
because it would add useless and unclaimable garbage.)
> As for a real compiler, we're working on it this semester,
Kawa is a real compiler. It is not, however, an optimizing
compiler. It is a straight-forward compiler that generates
decent code, as long as you accept it does little
analysis or optimization. But things like lexical scoping
and syntax re-writing are handled at compile time.
>and hopefully we'll be able to come up with something.
>If anyone is interested, please get in touch.
If you are working on an optimizing compiler, it would be
nice if we could co-operate. That includes using the same
library of primitive data types and functions. I am certainly
open to modifying Kawa if it would make it possible to generate
better code.
--
--Per Bothner
Cygnus Support bot...@cygnus.com
Kenneth R. Knight
Ashley Branchfeather (Ash...@halcyon.com) wrote:
: In article <joswig-2408...@news.lavielle.com>,
: jos...@lavielle.com (Rainer Joswig) wrote:
: >In article <sjpw4hb...@alfresco.usask.ca>, sr...@alfresco.usask.ca (P.
: >Srinivas) wrote:
: >
: >> so many splinter groups? Apple started Dylan and now it is a defunct
: >> language even before it is born.
: >
: >They still have NewtonScript. People programming the Newton
: >are using a language with Lisp semantics. Don't tell them. ;-)
: I hear Apple originally acquired Dylan for the purpose of using it for the
: Newton.
Apple didn't acquire Dylan. They created it. Sadly they also are letting
it die as far as the Mac is concerned (laid off the entire Cambridge Lab
where Dylan was created). Dylan was considered for the resident language
on the Newton, but it was deemed to large. NewtonScript was developed by
Wlater Smith and owes a lot to langauges like Self (I guess I see some
LISP semantics in it too and that is fine - I really like NewtonScript
alot more than Java certainly, but that is another boat Apple could've
filled and didn't).
** Ken **
--
**** Kenneth Knight IA, Inc. Software Engineer ****
**** voice: (313)-995-9338 fax: (313)-995-9338 ****
**** email: kni...@sphinx.biosci.wayne.edu ****
Barry Margolin
In article <y8alof2...@hertie.artcom.de>,
Andreas Bogk <and...@artcom.de> wrote:
>If it is an sockets interface, it suffers the same shortcomings the C
>socket interface interface has. One thing that is impossible with
>sockets is finding out where a connection request is coming from,
>without actually accepting the connection.
This is not a failing of the sockets API, it's a failure of the Unix TCP/IP
driver. It doesn't inform the process of the existence of the connection
until after it has accepted the connection. There's nothing an API can do
to provide features that aren't in the underlying implementation.
--
Barry Margolin
BBN Planet, Cambridge, MA
bar...@bbnplanet.com - Phone (617) 873-3126 - Fax (617) 873-6351
(BBN customers, please call (800) 632-7638 option 1 for support)
Carl L. Gay
From: Ash...@halcyon.com (Ashley Branchfeather)
Newsgroups: comp.lang.lisp,comp.lang.dylan,comp.lang.scheme,comp.lang.java
Date: Sun, 25 Aug 1996 00:27:37 -0700
Right. (That's D as in Dvorak, which explains the typo.)
Olin Shivers
From: Andreas Bogk <and...@artcom.de>
Newsgroups: comp.lang.lisp,comp.lang.dylan,comp.lang.scheme
Date: 26 Aug 1996 17:56:18 +0200
Olin> My student, Brian Carlstrom, designed and implemented a very
Olin> nice TCP/IP package for scsh two years ago that is the most
Olin> complete and attractive sockets interface I have seen to
Olin> date for Scheme. It allows full access to Unix sockets (Unix
If it is an sockets interface, it suffers the same shortcomings the C
socket interface interface has. One thing that is impossible with
sockets is finding out where a connection request is coming from,
without actually accepting the connection.
Of course I do appreciate the existence of packages for different
APIs. But I think it's a bad idea to use mediocre APIs as a basis for
standardization.
Well... I just didn't think it would be such a good idea to ask a 20 year old
undergraduate to implement a high-quality TCP/IP stack in Scheme, bypassing
the OS's entire interface, and tying in to the ethernet, serial line, and
other device drivers. Carlstrom is coming along as a programmer, but he really
didn't get started on this kind of hacking until the first Lisp Machines were
built, when he was 12.
Perhaps other, more experienced hackers might want to take a stab at it.
-Olin
Bill Janssen
Sigh. Why didn't Brian just `steal' the ELK interface, which has been
around for over four years?
> No need to reinvent wheels once they've been done well once.
Bill
--
Bill Janssen <jan...@parc.xerox.com> (415) 812-4763 FAX: (415) 812-4777
Xerox Palo Alto Research Center, 3333 Coyote Hill Rd, Palo Alto, CA 94304
URL: ftp://ftp.parc.xerox.com/pub/ilu/misc/janssen.html
Juergen Nickelsen
Andreas Bogk <and...@artcom.de> wrote:
[about the socket interface of scsh]
> If it is an sockets interface, it suffers the same shortcomings the C
> socket interface interface has. One thing that is impossible with
> sockets is finding out where a connection request is coming from,
> without actually accepting the connection.
This has never occured to me, but sounds plausible. Accepting the
connection and breaking it off immediately after not recognizing (or
recognizing!) the peer sounds not too bad to me, though.
> Of course I do appreciate the existence of packages for different
> APIs. But I think it's a bad idea to use mediocre APIs as a basis for
> standardization.
I think it's a good idea to try standardization in an, especially
nowadays, very important area of application. As a basis of this you
will have to use what standard platforms (i.e. OSs) offer as a service.
If this service is mediocre, you could (a) accept it and use it as a
basis for your standardization or (b) change the world to make the
perfect API/service widespread enough as a platform to build on.
I'd stick to (a) for a start, and try to make the standard extensible
for achievements on (b).
--
Juergen Nickelsen
Bengt Kleberg
Bill Janssen wrote:
>
> Sigh. Why didn't Brian just `steal' the ELK interface, which has been
> around for over four years?
>
> > No need to reinvent wheels once they've been done well once.
>
The ELK implementation is marvelous. Unfortunatly ELK is very
handicapped by beeing developed outside the USA.
--
Bengt Kleberg, Enea Data AB
All opinions are mine, not Enea's
'If loops' are notoriously too short
mathew
In article <840989...@wildcard.demon.co.uk>,
Cyber Surfer <cyber_...@wildcard.demon.co.uk> wrote:
>In article <4vp93n$f...@snotra.harlequin.co.uk> me...@pobox.com "mathew" writes:
>> 1. No cheap easy-to-use development system for their machine.
>>
>> I can download JDK from the net; I can get a C or C++ development
>> system for $150. If only Borland would produce "Turbo Scheme"...
>
>I can (and did) download the "web" version of Allegro CL for
>Windows, but this is not a complete system, and it has limitations
>(it's a demo version, after all). To buy it would cost $600, and
>to create stand alone apps, I'd need to spend $2500 on the full
>version.
Does that mean I'm allowed to plug Harlequin FreeLisp? :-)
<URL:http://www.harlequin.com/freelisp/>
None of the free Lisp implementations are things you could actually
use to deliver product, though. Unlike, say, GCC.
>I dunno if HyperCard performance can be "assisted" by compenents
>written in C/C++
Yes it can, but that doesn't really address the problem. If I'm going
to have to write all the critical code in C++ and get a C++ compiler, I
might as well just write the whole thing in C++.
A C FFI should be viewed as a way to interface to existing code; not as
a way to supplement an inadequate OS interface, or a way to speed up
poor performance.
>> 7. Hard to port to other platforms.
>>
>> You can develop cross-platform in Common LISP, of course; but
>> Scheme really falls down here. And Java, of course, wins big.
>
>I've failed to get the few bits of other people's CL code to
>work with ACL for Windows, but they _were_ difficult examples.
>However, I'm a little concerned about compatibility.
Yet earlier you wrote:
>I don't even know if ACL for Windows can do the things I need,
>like use OCX controls, and produce "small" binaries.
It seems strange that you're concerned with cross-platform
compatibility, yet you use OCX. I suppose you're only interested in
porting stuff *to* Windows, right?
>> It's not that everyone actually wants to develop cross-platform;
>> it's more that they need to feel that they could. The industry's
>> so fickle that you never know when you might have to port your
>> code.
>
>Some of us simply need a language that works on one platform,
>the one we're currently using. True, I might someday have to
>stop using Windows, and move to another OS. However, I don't
>expect it to happen this decade...
They used to say that the language of the 21st century would be called
FORTRAN. It might look now as if the OS of the 21st century will be
called Windows, but nothing's certain.
Rainer Joswig
In article <potts-26089...@host-239.subnet-134.med.umich.edu>,
po...@cancer.med.umich.edu (Paul R. Potts) wrote:
> The NewtonScript language, used for most Newton application development,
> is actually very cool and I recommend that anyone interested in language
> design take a look at it.
It is an ugly (but brilliant) hack. ;-)
> While it isn't as featured as something like
> Dylan, you get:
You don't get:
- packages or modules
This is actually a big disadvantage!
- threads in NewtonScript
- functions and objects are not that well integrated
Rainer Joswig
mathew
Someone's pointed out to me that it might be to my advantage to make
the following clear:
* Though I work for Harlequin, I'm not in the Lisp or Dylan groups.
* My opinions on programming languages definitely don't coincide with
Harlequin's.
* Hence nothing I post should be construed as indicating anything about
Harlequin's future plans.
I am simply posting as an individual, with an interest in Scheme and
Dylan which predates my current employment. I didn't put disclaimers
all over the place originally, because:
(a) I'd clearly set the From: line to indicate my personal address, not my
work address, and
(b) I'm 'old net' enough to believe that disclaimers are a waste of
bandwidth, and one should never assume a Usenet poster is speaking for
the company he works for unless he explicitly states that he is doing so.
Anyway, enough of that...
I'm slightly more concerned that someone construed my remarks to be
"anti-LISP". I'm actually very pro-LISP -- and even more pro-Scheme,
which is my favourite programming language. I was just trying to
address why other people don't like LISP or don't feel able to use it,
and explain why I don't think adding stuff to Common LISP would make it
more popular.
In article <840989...@wildcard.demon.co.uk>,
Cyber Surfer <cyber_...@wildcard.demon.co.uk> wrote:
>In article <4vp93n$f...@snotra.harlequin.co.uk> me...@pobox.com "mathew" writes:
>> 1. No cheap easy-to-use development system for their machine.
>>
>> I can download JDK from the net; I can get a C or C++ development
>> system for $150. If only Borland would produce "Turbo Scheme"...
>
>I can (and did) download the "web" version of Allegro CL for
>Windows
Does that mean I'm allowed to plug Harlequin FreeLisp? :-)
<URL:http://www.harlequin.com/freelisp/>
None of the free LISP implementations are things you would actually
want to use to deliver product, though. Unlike, say, GCC, which has
been used to deliver commercial software.
>I dunno if HyperCard performance can be "assisted" by compenents
>written in C/C++
Yes it can, but that doesn't really address the problem. If I'm going
to have to write all the critical code in C++ and get a C++ compiler, I
might as well just write the whole thing in C++.
A C FFI should be viewed as a way to interface to existing code; not as
a way to supplement an inadequate OS interface, or a way to speed up
poor performance.
>> 7. Hard to port to other platforms.
>>
>> You can develop cross-platform in Common LISP, of course; but
>> Scheme really falls down here. And Java, of course, wins big.
>
>I've failed to get the few bits of other people's CL code to
>work with ACL for Windows, but they _were_ difficult examples.
>However, I'm a little concerned about compatibility.
Yet earlier you wrote:
>I don't even know if ACL for Windows can do the things I need,
>like use OCX controls, and produce "small" binaries.
It seems strange that you're concerned with cross-platform
compatibility, yet you use OCX. I suppose you're only interested in
porting stuff *to* Windows, right?
>> It's not that everyone actually wants to develop cross-platform;
>> it's more that they need to feel that they could. The industry's
>> so fickle that you never know when you might have to port your
>> code.
>
>Some of us simply need a language that works on one platform,
>the one we're currently using. True, I might someday have to
>stop using Windows, and move to another OS. However, I don't
>expect it to happen this decade...
They used to say that the language of the 21st century would be called
FORTRAN. It might look now as if the OS of the 21st century will be
called Windows, but nothing's certain.
Rainer Joswig
In article <wb0bufy...@goober.graphics.cs.cmu.edu>,
sp...@goober.graphics.cs.cmu.edu (Scott Draves) wrote:
>From sp...@goober.graphics.cs.cmu.edu (Scott Draves)
>Date 26 Aug 1996 12:42:07 -0400
(flame-mode :on)
>yes and no. the feature list may be as long, but the details will be
>quite different. the reason Scheme `threw out' so much of CommonLISP
>wasn't because they considered things like records and exceptions were
>superfluous, but because they wanted to Do It Right.
Well, they yet have to "do it right". Will it need another ten years?
There is a lot of interesting work done with Scheme. There
are some very interesting Scheme implementations. But
the Scheme community needs to make sure that users
can port their code more easily between the different
implementations. Make sure people can stand on your shoulders.
>CommonLISP is the expediant compromise and union of (then)
> existing lisp systems.
This is wrong. Look at the history papers. Common Lisp is largely based
on Lisp dialects like ZetaLisp, MacLisp and Scheme.
InterLisp for example has had almost zero influence on CL.
>i think *some* Schemers have a small-at-all-costs attitude, but please
>don't condemn the group.
Scheme is a nice language for a lot of applications. But it
lacks some flesh. If you'll add stuff, it'll be not the same
Scheme we all know. People have added features in the past for
all kinds of stuff - yet everyone is doing it again. A language
where I need to develop new versions of MEMBER, because MEMBER
doesn't have a test parameter isn't very practical to me.
A language where you do have to develop your own records via
lists isn't very practical to me also. DEFSTRUCT and DEFCLASS
may look ugly to some people, may have the wrong syntax/semantics
for others - but its there, it is not completely broken
and I can use it. Others use it too. Every time an implementor
of CL optimizes DEFSTRUCT or DEFCLASS, all the code out there
immediately benefits from that.
Sorry, but I don't have the time until the Scheme
community thinks it can agree on some RECORD mechanism.
All these excellent people have invested much time
to come up with really interesting proposals for macros
(maybe we should get a CL implementation ;-) ). Yet, how
many different are still in use?
Its nice to be a purist, but I want to develop software,
I want to see my investment of learning time not be wasted,
I want to **use** Lisp-based software (the editor I'm using
right now is written in CL). So, for my purpose it
is good to have standards. I would love to see a standard
UIMS for CL - even if it would not be "the right thing".
But it would be a start. It could be improved. It would
bundle efforts. Right now we have a lot of UIMS for CL - some
dead - some proprietary - some single platform - some
expensive - some not widely used - ...
Is it only me or has progress slowed down tremendously in
the Lisp world? Is it because key people are/were working
on Java/Dylan/C/C++/Haskell/SmallTalk?
Some people are devoting time to ISLisp. Who implements ISLisp?
Who sells it? Who uses it? Who wants it? Who benefits?
What happened?
(flame-mode :off)
Rainer Joswig http://www.lavielle.com/~joswig/
Cyber Surfer
> Does that mean I'm allowed to plug Harlequin FreeLisp? :-)
> <URL:http://www.harlequin.com/freelisp/>
Certainly. ;-)
> None of the free LISP implementations are things you would actually
> want to use to deliver product, though. Unlike, say, GCC, which has
> been used to deliver commercial software.
This is why I'm waiting for Gwydion. I'm hoping that it
_will_ be the kind of development system with which I'll
be able to deliver commercial software. Even if I only use
it for my personal projects,which are only ever used by me.
> >I dunno if HyperCard performance can be "assisted" by compenents
> >written in C/C++
>
> Yes it can, but that doesn't really address the problem. If I'm going
> to have to write all the critical code in C++ and get a C++ compiler, I
> might as well just write the whole thing in C++.
You might not need to do that if the components you want are
already available, or if writing them is trivial. One of the
major reasons for usinga tool like HyperCard or VB is that it's
easier than doing it all in C++. If the result is just as good,
why waste all that time? I'd rather get a life.
> A C FFI should be viewed as a way to interface to existing code; not as
> a way to supplement an inadequate OS interface, or a way to speed up
> poor performance.
I'm not just talking about an FFI, but a way of creating,
using and reusing software components. I started to dislike
reinventing wheels about 15 years ago. Today's wheels do
much more than the wheels I used back then, so I want better
tools to help me manage them. I'm always looking for new
tools, which is how I found Lisp, about 10 years ago.
> >> 7. Hard to port to other platforms.
> >>
> >> You can develop cross-platform in Common LISP, of course; but
> >> Scheme really falls down here. And Java, of course, wins big.
> >
> >I've failed to get the few bits of other people's CL code to
> >work with ACL for Windows, but they _were_ difficult examples.
> >However, I'm a little concerned about compatibility.
>
> Yet earlier you wrote:
>
> >I don't even know if ACL for Windows can do the things I need,
> >like use OCX controls, and produce "small" binaries.
>
> It seems strange that you're concerned with cross-platform
> compatibility, yet you use OCX. I suppose you're only interested in
> porting stuff *to* Windows, right?
I'd like compatibility at the language level, but I also
need support for the platform specific things. The former
is a general programming issue, while the second is specific
to application development. I'm paid to write software for
a specific platform, but if that platform changed, then my
interest in platform specific features would reflect that.
In the case of Common Lisp code, I'm interested in code that
works with Allegro Common Lisp for Windows, but only coz that's
the Lisp that I'm currently using. It was a purely arbitrary
choice.
> >> It's not that everyone actually wants to develop cross-platform;
> >> it's more that they need to feel that they could. The industry's
> >> so fickle that you never know when you might have to port your
> >> code.
> >
> >Some of us simply need a language that works on one platform,
> >the one we're currently using. True, I might someday have to
> >stop using Windows, and move to another OS. However, I don't
> >expect it to happen this decade...
>
> They used to say that the language of the 21st century would be called
> FORTRAN. It might look now as if the OS of the 21st century will be
> called Windows, but nothing's certain.
I agree, but right now the only platform that company I work
support is Windows. Conveniently, we have no trouble finding
clients who use Windows. What I can't do is write code for any
other platform (I don't have the tools at the moment). I'd love
to be paid to write in Lisp, or even better, Dylan, but it's
unlikely to happen soon.
People look at me strange when I mention Lisp, like they don't
believe there's a web server written in it. On the other hand,
last week I was chatting with a journalist who's going on a
course to learn to program in Lisp, and getting _paid_ for it.
She's new to programming, and my boss was extremely doubtful
that she'd learn much. I _think_ he was refering to her ability
to learn programming skills, rather than Lisp...
There's something wrong with the world when a journo gets paid
to play with Lisp and a Lisp programmer gets paid to use C++.
Roll on Dylan...
Cyber Surfer
In article <3222B6C5...@enea.se>
bengt....@enea.se "Bengt Kleberg" writes:
> The ELK implementation is marvelous. Unfortunatly ELK is very
> handicapped by beeing developed outside the USA.
And we know that all software outside the US is crap. ;-)
Ulrich Schreiner
mathew wrote:
> ...
i think you're right. many people (me too) have learned programming with
ms-dos/windows. where do you get a small but useful environment from ? ok, allegro
clos, but this isn't a full version.
another big problem is the fact that there is no good tutorial for clos. yes there are
good books, but compare them to the pool of c++-,delphi- or vb-books. it is *very*
frustrating to learn clos with an abstract example like "network-stream" or something
else. most people want a cheap programming-environment *AND* a book which can be
used as a tutorial for this programming-environment.
you said that clos is hard to learn and that c++ is small compared to clos. first of
all: c++ is much bigger and more complex than clos. take a look at c++: you have
pointers, references and stack-variables. then you can have a pointer to a reference
and a const pointer to a reference and a pointer to a const, and .... how much time do
you need to understand everything ? and how much time do you need to understand a
source ? (have you ever tried to understand a templated class which takes as template
argument a templated class and so on ? thanks to languages like clos, dylan,
smalltalk, ... with no types).
yes, you're right, you need years to program in c/c++ proficient, but in clos you
normally have an interpreter and so you can learn much more efficient (write it down
and test it immediately).
well, the main problem is that no one *knows* clos. most students here in germany
learn c, c++, pascal, sometimes smalltalk but that's all. i had the luck to meet an
ai-course and learned lisp. but very much people think that lisp and clos are only
useful in ai and so they ignore it. force microsoft to buy harlequin or franz and
you'll have your success with microsoft clos ;-)
ulrich schreiner (schr...@khe.scn.de)
Cyber Surfer
In article <joswig-2708...@news.lavielle.com>
jos...@lavielle.com "Rainer Joswig" writes:
> Is it only me or has progress slowed down tremendously in
> the Lisp world? Is it because key people are/were working
> on Java/Dylan/C/C++/Haskell/SmallTalk?
All of the above. :-( The only member of that list (Hey! A pun!)
that I've not used in Haskell, if you count Actor as "Smalltalk".
I dunno how representative I may be, but my feeling is that if
_I'm_ using it, esp if I'm being paid to use it, and I know of
others in the same position, then that's good enough for me.
I'm currently waiting for a Haskell tutorial to be published (I
have it ordered, already), so perhaps that languages is not yet
so well established as Java/C/C++/Smalltalk. Is there a Dylan
tutorial out there yet? I'm picking it up from the DRM and my
knowledge of Lisp (Scheme and CommonLisp), so perhaps a tutorial
for Dylan isn't needed quite so urgently as a Haskell tutorial?
Meanwhile, what's happening in the Lisp world, apart from Dylan?
If you mean CL and Scheme, then there are a _few_ things. Existing
Lisps are being ported to new (or relatively new) platforms, like
Linux and Win32. Some of it is commercial, some not.
None of it appears to have a high profile, at least from where
I'm sitting. Java dominates certain areas, like the Web, while
the C++ monster just keeps on eating developers. Smalltalk seems
to have a higher profile than Lisp. At least, I don't hear people
laughing so loudly when ST is mentioned...
That's why I tend not to talk about Lisp anymore. Now I mention
Dylan instead. Too bad I can't show anymore what Dylan can do,
coz so many people today expect something graphical. The people
I know expect _multimedia_, and I don't think that Mindy can do
that (yet). Oh well, someday Gwydion _will_.
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
******* Boycott 'The Observer' - see uk.media for details *******
Cyber Surfer
In article <30502147...@arcana.naggum.no>
er...@naggum.no "Erik Naggum" writes:
> compiled on my sparc-sun-sunos4.1.3 with cc -o hello -n -s hello.c yields a
> 856-byte object file that is "sparc pure executable". most of the overhead
> here is from a crt0.o file that cannot junk its dynamic loading preamble.
> the definition of exit is to avoid the overhead of the C library's version.
This is meaningless. The DOS batch language can do it in even fewer
bytes, but so what? Whatever the OS, there should be a scripting
language that can do it in less than 100 bytes. So what?
> is it useful to compare languages on the basis of how tightly coupled they
> are with the operating system? I don't think so.
I agree. Some platforms can associate a program with a file, using
a shell escape or file 'type', but how many "Hello, World!" programs
do you need to write each year? Who would pay for such an app to be
"developed"? I'm not sure where the demand these apps comes from,
unless it's programming/language tutorials.
Cyber Surfer
In article <3222EC...@khe.scn.de>
schr...@khe.scn.de "Ulrich Schreiner" writes:
> well, the main problem is that no one *knows* clos. most students here in
> germany
> learn c, c++, pascal, sometimes smalltalk but that's all. i had the luck to
> meet an
> ai-course and learned lisp. but very much people think that lisp and clos are
> only
> useful in ai and so they ignore it. force microsoft to buy harlequin or franz
> and
> you'll have your success with microsoft clos ;-)
Yeah, I'd love to be able to write multimedia Windows software in Lisp.
Right now, I've no idea if this is possible.
MS have already used Lisp (Allegro CL for Windows, under NT). See
<URL:http://www.research.microsoft.com/research/ui/persona/home.htm>.
Of course, this is only research, and tho it may be multimedia, until
a few years ago it might've been classed as AI. Yes, AI is becoming
multimedia, coz even MS are making computers understand speech, talk
back to us, or present a user interface with an animated parrot.
Too bad MIT's Media Lab gets all the attention, instead of the MS
folk doing _their_ research. After all, the people who decide which
languages Windows software is written in don't care about MIT. If MS
aren't doing it, most Windows developers won't even know it exists.
Maybe somebody should tell them...
Harley Davis
sr...@alfresco.usask.ca (P. Srinivas) writes:
> 1. Layered architecture (possibly a hierarchical) + autoloaded
> libraries a la EULISP. Small executables are possible.
Actually, EuLisp does not have autoloaded libraries. It has a module
system which requires you to explicitly import other modules you want
to use. We did try to make it possible to write automatic tools which
determine module imports; Ilog Talk does that in its development
environment.
-- Harley Davis
-------------------------------------------------------------------
Harley Davis net: da...@ilog.com
Ilog, Inc. tel: (415) 944-7130
1901 Landings Dr. fax: (415) 390-0946
Mountain View, CA, 94043 url: http://www.ilog.com/
Phil Perucci
On 24 Aug 1996 04:12:44 -0700, Philippe Troin <ph...@tantale.fifi.org>
wrote:
>Java is not LISP. Java is a C++ bastard.
Definately a son-of-a-bitc? sometimes :-) Still, I think it will be
enough to cause Micro$loth's growth to plateau.
Anyway, can anyone shed any light on the ability of Java to perform
LISPs (eval) function? It would be very nice to generate Java code,
and pass it back to Java for compilation/execution, which is one of
the main things LISP was famous for (that and lists...).
Erik Naggum
I have never understood the value of the "hello, world" that "mathew"
brings up. it is not new, it is indeed prevalent in certain circles.
the test shows not how small (or not) executables a programming language
can produce, like so many people believe. the test shows only how tightly
coupled the operating system and the programming language are.
the 92-character program
exit (code)
{
_exit (code);
}
main ()
{
write (1, "hello, world\n", 13);
return 0;
}
compiled on my sparc-sun-sunos4.1.3 with cc -o hello -n -s hello.c yields a
856-byte object file that is "sparc pure executable". most of the overhead
here is from a crt0.o file that cannot junk its dynamic loading preamble.
the definition of exit is to avoid the overhead of the C library's version.
now, this 856-byte executable plugs right into the Unix operating system,
and does its job without any hassles. however, it is an inordinately large
program for what it does! under e.g., TOPS-20, one would write a program
with two both system calls (and some setup) with constant string data and
no other data; it would require something like 16 words of preamble, 3-4
words for the code, and 3 words for the string. clearly, programming in
MACRO-20 under TOPS-20 is the most ideal programming environment there is!
according to the "hello, world" test, that is.
is it useful to compare languages on the basis of how tightly coupled they
are with the operating system? I don't think so.
#\Erik
--
my other car is a cdr
WJ Bland
On 25 Aug 1996, mathew wrote:
> >Why not unite many of these "LISP"s under one umbrella? It is
> >perfectly feasible to define a common core and various extensions to
> >suite various needs.
>
> True enough. If your core is defined properly, you can extend the
> language arbitrarily.
>
This, of course, is what CL *should* have been--a core language,
extendable by librarys, just like C.
> >Common LISP was a major step forwards. Thanks to many people. Since we
> >have ANSI standards, why dump all the success and everybody going in
> >their own way? Here we have an industrial strength tried and tested
> >language used in commercial world. Why not try improve the Common
> >LISP.
>
> Because many people feel that to improve on Common LISP, you'd have to
> throw most of it away. Or rather, move most of it out into packages
> and libraries, rather than the core language.
>
> If you're going to do that, and sacrifice compatability, you might as
> well start with an existing well defined clean core language, like
> Scheme, and build the libraries on top of that. Which is pretty much
> what the Scheme community seem to be trying to do.
>
I got around my CL problems by writing my own LISP compiler. It's small
and fast, and soon it will compile itself (at the moment it runs under
a CL interpreter). Once it is bootstrapped, I will make it freeware.
FYI: it writes .asm files to be assembled by TASM and run under DOS on
a PC.
I may eventually add CL compatability with librarys (if I ever decide I
need all that stuff).
> 2. Can't compile to a small standalone executable.
>
> True for many Lisps. I have something I call the "hello world test".
> You build a standalone "hello, world", and look at the size of
> the executable. If your OS supports a GUI, you produce a simple
> "one movable window" GUI version too. Lisps often do badly in this
> test.
I tried this test with several compilers. Most non-LISP compilers made
about 64Kbyte executables.
My compiler does it in 2Kbytes (which is still too big ;-).
I couldn't do the same test for a GUI version, as my compiler only does
DOS executables, but when I find out more about MS-WINDOWS, I'm going to
try making it write MS-WINDOWS executables...
Cheers,
Bill.
PS, if anyone wants more info on my compiler, please feel free to mail me
about it.
-------
/'I thought dwarfs didn't believe in devils and demons and stuff like that.' \
\'That's true, but ... we're not sure if they know.' Terry Pratchett - M.A.A/
Bill's home page is at http://www.ccc.nottingham.ac.uk/~pmykwjb/bil.html
Scott Schwartz
Erik Naggum <er...@naggum.no> writes:
| is it useful to compare languages on the basis of how tightly coupled they
| are with the operating system? I don't think so.
I think it is. Efficiency counts, and this is a relevent factor.
Lisp machines are extinct, with good reason, so learn to love the
alternatives.
Jeff Dalton
Part of the reason Common Lisp is less popular than it might be
is that people keep saying false things about it. For instance,
in a recent message sp...@goober.graphics.cs.cmu.edu (Scott Draves)
wrote:
> the reason Scheme `threw out' so much of CommonLISP
> wasn't because they considered things like records and exceptions were
> superfluous, but because they wanted to Do It Right. CommonLISP is
> the expediant compromise and union of (then) existing lisp systems.
> Scheme was the intersection: everything that they could agree was
> Right.
Everything there is wrong.
Scheme existed before Common Lisp and so didn't "throw out" anything
from Common Lisp. However, Common Lisp was influenced by Scheme.
Common Lisp is _not_ a union: if anything, it's an intersection:
it's what those working on several successors to MacLisp could agree
on. Look in CLtL. Moreover, Common Lisp is a substantial _cleanup_
compared most previous Lisp.
Finally, Scheme was _not_ the intersection of (then) existing
Lisp systems. For one thing, you don't get full lexical scoping by
taking the intersection.
-- jd
Scott Draves
apparantly, i was not clear.
i wasn't speaking about historical sequence (which i know), but rather
of end products of design philosophy, process, and objectives applied to
feature selection. loosely, that `intersection' produces the smallest
product by including essential features agreed upon by everyone, and
that union includes features found to be useful, but that one often
can live without (such as macros and packages) or were missing from
one of the predecessors (eg complex arithmetic).
So when i say Scheme `threw out' things form Common Lisp, i didn't
mean that they were reading the Common lisp standard and removed
things from it, i meant that the designers considered many of the same
features, but decided not to included them. remember the committe
operated by unanimous consent.
compatability, one of the core goals of Common Lisp, is inherently a
`union' philosophy. something you have to agree on once (like if
variables are by default lexical or dynamic, and how many namespaces
there are), but many, many features exist as standard/library
functions or data types which coexist, ie can be unioned.
from [Reese82] from [Evolution of Lisp]
we have refrained from supporting features that we didn't feel
completely right about. ...
[Evolution of Lisp] also says that eventually the common lisp group
felt that their task was finding The Right Thing as well, but i don't
believe this is true to the extent that it is in Scheme.
jeff> Part of the reason Common Lisp is less popular than it might be
jeff> is that people keep saying false things about it.
pu-leeze relax jeff. i think Common Lisp is a wonderful language. i
haven't said anything negative about it.
Mike Haertel
In article <30502147...@arcana.naggum.no>,
Erik Naggum <er...@naggum.no> wrote:
> [ C "hello world" on Sparc ]
>
>now, this 856-byte executable plugs right into the Unix operating system,
>and does its job without any hassles. however, it is an inordinately large
>program for what it does! under e.g., TOPS-20, one would write a program
>with two both system calls (and some setup) with constant string data and
>no other data; it would require something like 16 words of preamble, 3-4
>words for the code, and 3 words for the string. clearly, programming in
>MACRO-20 under TOPS-20 is the most ideal programming environment there is!
>according to the "hello, world" test, that is.
You could, of course, do precisely the same thing under Unix if you
care to descend to the level of assembler. All you need to do is
figure out the crt0.o entry conventions, and replace it with your
main program, with the system calls coded by hand. Then the Unix
executable would consist of a 32 byte header plus a handful of
instructions and a constant string.
I think the real reason most Lisp implementations produce huge
executables is not that it's not possible, but that Lisp implementors
have, for whatever reason, chosen not to work on that particular
problem. I don't see executable size as an inherent property of
a language any more than efficiency is. It is a property of a
specific implementation.
Now, it might be a property of a given language that all existing
implementations are inefficient or bloated, but that still doesn't
prove that all possible implementations are...
--
Mike Haertel <hae...@ichips.intel.com>
Not speaking for Intel.
Robert Futrelle
Now that there is an enormous amount of information on the Web, we need to
organize it and get a handle on its content (its semantics). This means
writing systems that do lots of symbolic computation on natural language and
graphics. This R&D work will take years of effort. I will also involve GUIs
and OODBs. I can think of no better language to use for these efforts than
Common Lisp. My $0.1.
-- Bob Futrelle
--
Prof. Robert P. Futrelle | Biological Knowledge Lab, College of CS
Office: (617)-373-2076 | Northeastern University, 161CN
Fax: (617)-373-5121 | 360 Huntington Ave.
futr...@ccs.neu.edu | Boston, MA 02115
Cyber Surfer
In article <Pine.SOL.3.91.960828151930.18118A-100000@granby>
pmy...@unix.ccc.nottingham.ac.uk "WJ Bland" writes:
> I got around my CL problems by writing my own LISP compiler. It's small
> and fast, and soon it will compile itself (at the moment it runs under
> a CL interpreter). Once it is bootstrapped, I will make it freeware.
> FYI: it writes .asm files to be assembled by TASM and run under DOS on
> a PC.
> I may eventually add CL compatability with librarys (if I ever decide I
> need all that stuff).
Excellent! If you can get it to work with MASM (for Win32) I might
be interested. My own compiler is for a subset of Scheme, and compiled
to C. Since I'm rewritting it, it's far from complete - not that it
ever was complete, of course.
> I tried this test with several compilers. Most non-LISP compilers made
> about 64Kbyte executables.
> My compiler does it in 2Kbytes (which is still too big ;-).
> I couldn't do the same test for a GUI version, as my compiler only does
> DOS executables, but when I find out more about MS-WINDOWS, I'm going to
> try making it write MS-WINDOWS executables...
Go for Win32, coz it'll be much easier. At least, that's my experience.
I started with a DOSX, so even the DOS version was 32bit.
Good luck - we need all the Lisp compilers we can get!
Thanks.
Eugene O'Neil
In article <503ff7$5...@rigel.tm.informatik.uni-frankfurt.de>, Anselm Lingnau <lin...@tm.informatik.uni-frankfurt.de> wrote:
>In article <32242ff6...@news.alt.net>,
>Phil Perucci <pper...@idsonline.com> wrote:
>
>> Anyway, can anyone shed any light on the ability of Java to perform
>> LISPs (eval) function? It would be very nice to generate Java code,
>> and pass it back to Java for compilation/execution, which is one of
>> the main things LISP was famous for (that and lists...).
>
>is well-nigh impossible in C++, only more so because of the so-called
>`security features'.
It is only impossible to do this in applets loaded off the network.
Applications, and other code loaded from the local file system, have no such
security restrictions. Some day, when authenticated applets show up,
it may even be possible for trusted applets to have less restrictions.
Not only is it possible to dynamically create java code in applications, it is
relatively easy. What you do is create a subclass of "classloader", which
is part of the core java distribution. Classloaders can convert an array
of bytes into a java class. Look up classloaders in a good book on Java
for more information: You will find it does most of the work for you. It's a
cakewalk compared to trying to do the same thing in C++.
-Eugene
David Boles
>brings up.
That's unfortunate as it's actually a simple concept.
>the test shows not how small (or not) executables a programming language
>can produce, like so many people believe. the test shows only how tightly
>coupled the operating system and the programming language are.
Not at all, it really just measures how wide a range of programming
problems the language is usable for. Every operating system will
provide the ability to execute a program and to perform I/O. Every
useful programming language for that OS will provide the capability to
access I/O.
>under e.g., TOPS-20, one would write a program
>with two both system calls (and some setup) with constant string data and
>no other data; it would require something like 16 words of preamble, 3-4
>words for the code, and 3 words for the string. clearly, programming in
>MACRO-20 under TOPS-20 is the most ideal programming environment there is!
>according to the "hello, world" test, that is.
Sorry, you're not understanding the test. The "test" doesn't distinguish
between an executable of 100 bytes and 64Kbytes. Both of these, on almost
all systems of the last decade, are "small" and hence acceptable.
However, producing executables of 300-3000KBytes is *not* acceptable
for many tasks.
Look at it this way, it takes ~5000 usecs to do a fork/exec. A typical
page-fault overhead for a process performing the initial touch of a
page* in it's address space is ~150 usecs, so we can touch ~33 pages
of address space before the overhead involved in touching pages is
comparable to the fork/exec overhead. Essentially, an executable's
runtime footprint can be up to ~120k for free. However, if the size
of the runtime footprint is 1MB then the runtime overhead dominates
the cost of creating the process. If the process is short-running,
then the it becomes untenable to impose the high runtime cost. Since
the speed of processors and the speed of a fork/exec are increasing
far faster than the speed of touching a new page of address space
(trap time's are not getting that much shorter) this issue will
continue to be important and may even become more so.
These costs restrict the domain over which your language can generate
useful solutions for. A language such as C imposes very minimal costs,
making it useful (in a runtime sense) across a much wider range of
applications. While Lisp's necessarily have a higher runtime cost than
a primitive language such as C, it is unclear to me that these costs
have to be as large as they currently are. With decent engineering,
Lisp's could be *much* more widely applicable. It's sad that the lack
of a reasonable I/O model and typical Lisp system's poor executable
generation are such a drag on the language.
Cheers,
David Boles
Hewlett-Packard Co., Convex Division
* - I'm assuming 4096 byte pages for convenience
Anselm Lingnau
> Anyway, can anyone shed any light on the ability of Java to perform
> LISPs (eval) function? It would be very nice to generate Java code,
> and pass it back to Java for compilation/execution, which is one of
> the main things LISP was famous for (that and lists...).
This is going to be well-nigh impossible for the same reasons why it
is well-nigh impossible in C++, only more so because of the so-called
`security features'.
Anselm
--
Anselm Lingnau ......................... lin...@tm.informatik.uni-frankfurt.de
Life is ours to be spent, not to be saved. --- D. H. Lawrence
Jeff Dalton
In article <Pine.SOL.3.91.960828151930.18118A-100000@granby> WJ Bland <pmy...@unix.ccc.nottingham.ac.uk> writes:
>On 25 Aug 1996, mathew wrote:
>
>> >Why not unite many of these "LISP"s under one umbrella? It is
>> >perfectly feasible to define a common core and various extensions to
>> >suite various needs.
>>
>> True enough. If your core is defined properly, you can extend the
>> language arbitrarily.
>>
>This, of course, is what CL *should* have been--a core language,
>extendable by librarys, just like C.
Implementations could treat it that way now.
-- jd
Rainer Joswig
> I have never understood the value of the "hello, world" that "mathew"
> brings up. it is not new, it is indeed prevalent in certain circles.
If my Mac doesn't crash I start my MCL once a week. Later
my Mac goes to sleep and comes up by touching the keyboard
in a few seconds - Lisp still up and running. Why should I
be interested in startup times for my Lisp development environment?
Opening a hello world window ? Why bother?
Rainer Joswig
Rainer Joswig
In article <3222EC...@khe.scn.de>, Ulrich Schreiner
<schr...@khe.scn.de> wrote:
> i think you're right. many people (me too) have learned programming with
> ms-dos/windows. where do you get a small but useful environment from ?
ok, allegro
> clos, but this isn't a full version.
Hopefully we get competition on the CL front for the PC this year.
Btw., CMU CL is being ported to Linux/x86. Another good sign.
> another big problem is the fact that there is no good tutorial for clos.
yes there are
> good books, but compare them to the pool of c++-,delphi- or vb-books. it
is *very*
> frustrating to learn clos with an abstract example like "network-stream"
or something
> else. most people want a cheap programming-environment *AND* a book
which can be
> used as a tutorial for this programming-environment.
There are some good CL books that even avoid CLOS. The best book that
actually shows extremely interesting source examples is "The
Art of the Meta Object Protocol". Be proud that it uses CL.
But we lack an introduction book that uses CL, CLOS and GUI stuff.
Maybe it is to easy to use and we don't need a book - I don't know.
But there are many cool topics for an advanced CL book
out there. A book that would talk about FFIs, speed, UIMS, OO design,
networking, CL-HTTP, CLIM, animation, ...
> yes, you're right, you need years to program in c/c++ proficient, but in
clos you
> normally have an interpreter
sure you meant "an incremental compiler" ;-)
> and so you can learn much more efficient (write it down
> and test it immediately).
Btw, I just read in a german magazine an article about STL (the "Standard
Template
Library). This is pure fun. The same stuff is ten times more easy in Lisp
(no wonder - many of the ideas have been developed with Scheme). Yet,
there was not a word about Functional Programming in the article. I guess
I should write a letter to the editor...
Greetings,
Rainer Joswig
Rainer Joswig
In article <841217...@wildcard.demon.co.uk>,
cyber_...@wildcard.demon.co.uk wrote:
> In article <joswig-2708...@news.lavielle.com>
> jos...@lavielle.com "Rainer Joswig" writes:
>
> Meanwhile, what's happening in the Lisp world, apart from Dylan?
> If you mean CL and Scheme, then there are a _few_ things. Existing
> Lisps are being ported to new (or relatively new) platforms, like
> Linux and Win32. Some of it is commercial, some not.
That shows people are using it. MCL is also doing well. Version
4.0 arrives in september.
> That's why I tend not to talk about Lisp anymore.
Don't **talk**!
**Write** code and then talk about it!
I'm using Lisp for web stuff, scanning logs, editing text,
annoying C weenies, ... and it does useful work.
Just Do It.
Rainer Joswig
Btw., CL-HTTP (from the MIT AI Lab) is the first HTTP 1.1 server.
Thomas Kwong
After playing with so many different programming languages for
a couple years, I finally realized that *language does not matter*.
It's almost a waste of time trying to relearn whatever we already
know. Do everyone in the world speaks the same language? No.
Stick with the language you like the most and be happy.
BTW, Java is the most fun language I have ever known, next to
Scheme.
Tom
P. Srinivas wrote:
>
> The fall and Rise of LISP (or Lisp in 21st Century)
> ===================================================
>
> Why are they so many splinter groups in LISP community? The strength
> of LISP as an experimental vehicle contributed to its own misery. So
> many dialects so few users!!
>
> [etc...]
William Paul Vrotney
>
> I think the real reason most Lisp implementations produce huge
> executables is not that it's not possible, but that Lisp implementors
> have, for whatever reason, chosen not to work on that particular
> problem.
Actually they have, it's just that they were stopped in mid stream by the
C++ wave.
--
William P. Vrotney - vro...@netcom.com
Per Bothner
In article <32242ff6...@news.alt.net>,
Phil Perucci <pper...@idsonline.com> wrote:
>Anyway, can anyone shed any light on the ability of Java to perform
>LISPs (eval) function? It would be very nice to generate Java code,
>and pass it back to Java for compilation/execution, which is one of
>the main things LISP was famous for (that and lists...).
Check out Kawa in ftp://ftp.cygnus.com/pub/bothner/kawa-0.3.tar.gz.
This is a compiler that compiles Scheme to Java bytecodes, with
the necessary runtime classes. The same techniques (and mostly
the same code) could do Lisp rather than Scheme.
Kawa does not have an eval function yet, but it does have
a read-eval-print loop. All lambda expressions (including
at the interactive level) are compiled into bytecodes.
--
--Per Bothner
Cygnus Support bot...@cygnus.com
Kenneth R. Knight
Phil Perucci (pper...@idsonline.com) wrote:
: Anyway, can anyone shed any light on the ability of Java to perform
: LISPs (eval) function? It would be very nice to generate Java code,
: and pass it back to Java for compilation/execution, which is one of
: the main things LISP was famous for (that and lists...).
At least on the Mac-based platforms (and I think it is prohibited period)
there is noe quivilent to LISPs EVAL (or NewtonScripts Compile :) ). We
had to write our own expression evaluator to do this sort of stuff.
However, Java does seem to have some nice tokening classes you can work
with that make the task easier.
** Ken **
--
**** Kenneth Knight IA, Inc. Software Engineer ****
**** voice: (313)-995-9338 fax: (313)-995-9338 ****
**** email: kni...@sphinx.biosci.wayne.edu ****
Erik Naggum
[David Boles]
| Not at all, it [the "hello, world" test] really just measures how wide
| a range of programming problems the language is usable for.
my argument was that the "hello, world" test only shows the ability of a
language/compiler/operating-system combination to perform well _together_,
while it does _not_ show any inherent values or qualities of the language,
such as it is interpreted to do. in doing this under Unix, it shows that
the operating-system/language interface is such that this can be made
extremely efficiently. this is not particularly surprising, given the
origins of Unix and C. the exact same program compiled with the Sargasso C
compiler under TOPS-20 was horrendously inefficient and much larger than
any user programs I have seen. the unintelligent conclusion people draw is
that because Unix and C are very tightly coupled, they can draw conclusions
about one of the tightly coupled parts.
C and Unix share an "assumption space" that is so closed that any other
assumptions have a very high penalty while they retain minimal overhead.
in operating systems designed for use by multiple languages, C is no better
than, e.g., Fortran or PL/1, in fact it may be much worse, because the
assumptions made in C are so difficult to spot that most programmers don't
even realize they are there.
| Sorry, you're not understanding the test.
really? let's try again.
if you type "hello, world" into a Lisp system's read-eval-print loop, it
will type "hello, world" back at you. if you write a one-line function to
do the same and invoke it, it will have much lower cost than C could ever
have in _its_ optimal environment. if you insist on a model that is known
to favor C and Unix, you should be a little careful with your conclusions
about other languages and environments. I repeat: all the test shows is
that Unix and C are very tightly coupled and very efficient for this model
of executing programs. we knew that before anybody wrote the "test". thus
is has no probative value whatsoever if used to compare _languages_.
| These costs restrict the domain over which your language can generate
| useful solutions for. A language such as C imposes very minimal costs,
| making it useful (in a runtime sense) across a much wider range of
| applications. While Lisp's necessarily have a higher runtime cost than
| a primitive language such as C, it is unclear to me that these costs
| have to be as large as they currently are. With decent engineering,
| Lisp's could be *much* more widely applicable. It's sad that the lack
| of a reasonable I/O model and typical Lisp system's poor executable
| generation are such a drag on the language.
on the other hand, a Lisp programmer on _any_ operating system would balk
at the need to fork off a whole new process to do something as simple as
printing a line to the terminal! the waste of system resources is
incredible for so little action!
it's pathetic how the C/Unix camp will insist upon loading the dice in any
competition among languages, and on top of it, they do not even recognize
that they have made assumptions that automatically make them win. I'll
scratch this up to incredible well-done marketing, just like large segments
of the population will insist that Intel and Microsoft are the only viable
suppliers of basic computing power. they are wrong, too.
#\Erik
--
main () { printf ("%d\n", sin ("foo")); }
Chris Page
Erik Naggum <er...@naggum.no> writes:
> my argument was that the "hello, world" test only shows the ability of a
> language/compiler/operating-system combination to perform well
_together_,
> while it does _not_ show any inherent values or qualities of the
language,
> such as it is interpreted to do.
I tend to agree with this statement. As an example outside the Lisp domain,
I recently implemented a C++ program for BeOS, which required drastically
less overhead than it would have for Mac OS.
This is because BeOS has object-oriented system services that provide
default behavior for things like windows. To do "Hello, world!" in a window
on BeOS you need only subclass the window class (some source, but no object
code) and override the Draw method, which contains, roughly, a single call
to draw the text string.
To do this on Mac OS, you have to make system calls to create a window,
poll for events in a loop, dispatch the "update" event, set up the graphics
port, then draw the text. Even then, you cannot move, resize, or close the
window without additional code to handle these events (all handled
automatically by BeOS).
Therefore, C++ cannot be judged by this test, since, in the above case, the
environment heavily determines the code size and miscellaneous overhead for
trivial programs.
On the other hand, "Hello, World!" should probably not require 300K of
object code or runtime memory in any language or OS.
...........................................................................
Chris Page
Software Wrangler This message was created using Cyberdog
Claris Corporation - a product of Apple Computer, Inc.
mailto:pa...@best.com
http://www.best.com/~page/
...........................................................................
Cyber Surfer
In article <joswig-2908...@news.lavielle.com>
jos...@lavielle.com "Rainer Joswig" writes:
> > Meanwhile, what's happening in the Lisp world, apart from Dylan?
> > If you mean CL and Scheme, then there are a _few_ things. Existing
> > Lisps are being ported to new (or relatively new) platforms, like
> > Linux and Win32. Some of it is commercial, some not.
>
> That shows people are using it. MCL is also doing well. Version
> 4.0 arrives in september.
Excellent. Too bad my boss hates Macs.
> > That's why I tend not to talk about Lisp anymore.
>
> Don't **talk**!
>
> **Write** code and then talk about it!
I am. I write code for Windows, in C/C++. :-( I dunno if
Allegro CL for Windows can produce a binary that'll fit
onto a single floppy, but it doesn't look like it can use
OCX controls, so I can't use it for the stuff I'm paid to
write. As I've said before.
What can I do about it? Well, apart from writing my own
Lisp compiler, which won't be anything more than a "toy",
I can express my disatisfaction.
> I'm using Lisp for web stuff, scanning logs, editing text,
> annoying C weenies, ... and it does useful work.
I also like to annoy C weenies, by saying things like, "I use
Lisp _because I can_." They just don't believe it. Perhaps the
lack of an app to demonstrate to them has something to do with
their scepticism.
> Just Do It.
Sure, just give me a Lisp for Windows that can support the
features I need. ACL can't do it. What can? Our clients want
Windows software, packed with all the features they want,
and _very_ small binaries. If there's a way to do this in
Lisp, then I want to know about it! The choice of develop
software isn't mine, but I can recommend stuff.
Right now, I'm still looking.
> Btw., CL-HTTP (from the MIT AI Lab) is the first HTTP 1.1 server.
Excellent. I'll point that out next time somebody claims that
Lisp can't do anything useful. BTW, can it run under NT?
I'd love to be able to say, "See that multimedia app we use
as the core of our business? That's written in Lisp that is",
or possibly, "See that webserver we're using to host websites
for our clients? That's written in Lisp that is." Sadly, most
people will demand that such software be written in C++, and
they _don't want to know_ if it could be done in Lisp.
Give me a demo web server written in Lisp, running under NT,
or a multimedia app using OCX, then I might be able to convince
a few people. At the moment, all I have is words. None of these
people give a shit about Lisp, coz they "know" that the stuff
they want can't be done in Lisp.
Your words are encouraging, but only coz I feel sure that these
things _can_ be done in Lisp. The problem is that all I have is
this faith in Lisp. There's nothing concrete that I can take to
my boss or a client and demonstrate for them. I can code all I
want to in Lisp, but until I can produce such a demo, nobody
will listen.
So, I'm writing a "toy" Lisp to C compiler, and working on it
when I have the time. I admit that I'm not good at this, so even
when I _do_ work on it, progress is very slow. Still, I might
just get it doing something useful before a commercial alternative
comes my way. You never know, do you? Anyway, it keeps me sane
while I struggle with the horrors of C/C++!
Cyber Surfer
In article <30503381...@arcana.naggum.no>
er...@naggum.no "Erik Naggum" writes:
> it's pathetic how the C/Unix camp will insist upon loading the dice in any
> competition among languages, and on top of it, they do not even recognize
> that they have made assumptions that automatically make them win. I'll
> scratch this up to incredible well-done marketing, just like large segments
> of the population will insist that Intel and Microsoft are the only viable
> suppliers of basic computing power. they are wrong, too.
I agree. Unfortunately, being wrong sometimes doesn't stop people
from succeeding. I'm not sure who said this, but I recall reading
something in the August 1981 issue of Byte (the Smalltalk issue),
"A operating system is a collection of things that don't belong
in a language. There shouldn't be one." My first machine used
Basic as the language/OS, and I wasn't even aware that it didn't
understand Basic at the hardware level, never mind that there was
a few K in the ROM that we might call an operating system.
While the people at Xerox PARC saw Smalltalk-80 as a single entity,
the people who came to take those ideas into the real world saw
_two_ distinct entities. That's part of the problem. It's also
a necessary part of delivering software to users, at least until
somebody can produce a software system (that's a vague enough
way to refer to it, isn't it?) that can blur the distinction and
still deliver code in a way that users and developers both find
acceptable, and make it more successful than the existing offerings,
like Unix, Windows, etc.
Somebody asked me last week, "What's an operating system?" I tried
to answer that it is something that shouldn't exist. My boss gave
the "mainstream" answer, which is a lot more complicated and which
makes all the assumptions that you've refered to. Nearly 15 years
after that Byte issue, and nothing has changed. This is either an
idea that is _still_ too radical for most people, or it requires
more than 15 years for the world's programmers to find a way of
implementing it as a commercial solution.
Unless, of course, you consider Java to be the answer...
Jeff Dalton
Scott Draves wrote a few days back
CommonLISP is the expediant compromise and union of (then) existing
lisp systems. Scheme was the intersection: everything that they could
agree was Right.
He now says he "haven't said anything negative about" Common Lisp.
But I'd call "expediant compromise" rather negative, and talk such
as "union of existing lisps" reinforces widespread prejudices and
misconceptions.
In any case, he has now offered a clarification:
On 28 Aug 1996 15:06:25 -0400, sp...@goober.graphics.cs.cmu.edu (Scott Draves)
wrote (in reply to me):
> apparantly, i was not clear.
> i wasn't speaking about historical sequence (which i know), but rather
> of end products of design philosophy, process, and objectives applied to
> feature selection. loosely, that `intersection' produces the smallest
> product by including essential features agreed upon by everyone, and
> that union includes features found to be useful, but that one often
> can live without (such as macros and packages) or were missing from
> one of the predecessors (eg complex arithmetic).
I did have history in mind when talking about whether Scheme "threw
out" things from CL, but not when talking about union and intersection.
I was talking about the relationships between languages and the
mechanism by which features were selected, not history, though that's
still (it seems) a partial misunderstanding of what you meant.
However, I'd still say you're wrong. Common Lisp was an intersection,
not a union. It was what could be agreed on. Ok, it was often by
majority vote, rather than requiring that "everyone" agree; and some
of what was included was not "essential" -- but neither of those are
necessary to an intersection.
Here I am rejection your definition of "union", because I think it is
seriously misleading to say "union" just because there's inclusion of
features that were not "essential" or were missing from predecessors.
(Neither a (set) union nor an intersection brings in features missing
from predecessors, BTW.)
Moreover, both Scheme and Common Lisp include features that one
can live without; but some of these "nonessential" features --
such as macros in CL -- are central to what makes the language
what it is and worth using. One can live without call/cc and
a number of other things in Scheme. One can even live without
symbols and lists, as programming in the vast majority of programming
languages has shown.
What you're left with is this: Scheme is far smaller than Common Lisp,
and the Scheme designers want Scheme to be a language with a small
number of powerful features, while the CL designers were more
pragmatic and cared more about overall functionality than size. But
this it not to say the CL designers wanted maximal functionality by
including everything useful they could find, nor that they cared
nothing about size. For instance, the 24 special operators in CLtL
reflect a significant degree of care in the selection of primitives;
and CL left out or cleaned up much that was in earlier Lisps.
As CL was developed by X3J13, in many cases extending the language
of CLtL, it became somewhat messier and some things (such as the full
LOOP macro) were included despite a widespread feeling that they
weren't really Right. But we can still see selection, cleanup,
and generalization -- e.g. in CLOS.
> So when i say Scheme `threw out' things form Common Lisp, i didn't
> mean that they were reading the Common lisp standard and removed
> things from it, i meant that the designers considered many of the same
> features, but decided not to included them.
It's misleading to say they threw out things from Common Lisp when
instead they were rejecting (and often not considering at all) things
from MacLisp and maybe some other Lisps around in the 70s or early
80s (such as various NILs). And many of these things either didn't
appear at all in Common Lisp or took a different form.
Your reference to the CL standard is a herring of deepest red.
Common Lisp was around well before the standard.
(I hope, BTW, that you're not going to argue that because the Scheme
designers were aware of what was in Common Lisp throughout the period
of CL design and standardization, we can say they "threw out"
everything in CL they didn't adopt for Scheme. If you don't accept
that "threw out" is prejudicial language, I hope you'll at least
recognize that more neutral language is available.)
> remember the committe operated by unanimous consent.
Remember that Scheme was not initially designed by a committee
and that the current Scheme is not very far from the original.
(Names have changed to those from T, some lightweight process
stuff was removed, ...; but the they both "look like Scheme".)
The RnRS authors took an existing, small, language and modified it
using a process that made change difficult. The existing language
came from a time when Lisps in general were often fairly small.
Common Lisp in effect started from something like 4 larger, and
still developing languages, successors to MacLisp. The aim was,
in effect, to agree on a common subset of what those languages
_would be_ (not what they were). The people involved were working
on or with similar languages, and they naturally agreed on a
fairly wide range of features. (If a wider range of languages had
been involved, agreement would have been less.) And the mechanisms
for changing the language made changes (including extensions)
easier than for Scheme.
So there are factors at work apart from deliberate design.
I've been involved in the design of several languages in the Lisp
family, and I've seen a certain pattern there and for some other
languages: there's fairly rapid and easy agreement on a range of
features, and then agreement becomes much harder. Features that
look like the sort of thing that would have been easily agreed to
earlier prove controversial; arguments for and against occupy more
time and a consensus does not emerge. That something is not Clearly
Right now seems to count effectively against it, though similarly
imperfect things were accepted before. (For instace, if "load"
were not already in Scheme, it would probably be impossible to add
it. If records had been in, say, the 1st "Revised Report", Scheme
would probably still have them.)
Anyway, this seems to be largely independent of what the designers
would say their design aims are. (The aims might remain pretty
much constant throughout, for instance.)
> compatability, one of the core goals of Common Lisp, is inherently a
> `union' philosophy. something you have to agree on once (like if
> variables are by default lexical or dynamic, and how many namespaces
> there are), but many, many features exist as standard/library
> functions or data types which coexist, ie can be unioned.
"Can be unioned" and "are unioned" are two different things.
Common Lisp is fairly compatible with Lisps close to MacLisp. With
a fairly small amount of compatibility code, I can write fairly
"natural" code that works in both Franz Lisp (which is very like
MacLisp) and Common Lisp. (I pick Franz, because then it's something
I've actually done.)
Now Franz Lisp has hunks, to be compatible with PDP-10 MacLisp.
_There's_ compatibility for you. CL does not have hunks, just
one of the many things in MacLisp and the various MacLisp successors
mentioned above that are not in Common Lisp.
CLtL mentions compatibility with Lisps outside the MacLisp group,
e.g. InterLisp; but you'd be hard pressed to find much in CL that
results from this "aim".
> from [Reese82] from [Evolution of Lisp]
> we have refrained from supporting features that we didn't feel
> completely right about. ...
> [Evolution of Lisp] also says that eventually the common lisp group
> felt that their task was finding The Right Thing as well, but i don't
> believe this is true to the extent that it is in Scheme.
It's hard to say. The authors of [Evolution of Lisp] are in a better
position to know than most. But the CL and Scheme designers had a
different notion of what the Right Thing was. (But that's not quire
right either. Some, at least, took the view that there wasn't a
single Right Thing.)
> jeff> Part of the reason Common Lisp is less popular than it might be
> jeff> is that people keep saying false things about it.
> pu-leeze relax jeff. i think Common Lisp is a wonderful language. i
> haven't said anything negative about it.
It looks to me like you've said things that are at best misleading
and that make Common Lisp look worse than it is.
Perhaps you don't know this, but many people think Common Lisp is
a union of almost everything found in earlier Lisps. When they
see both lexical and dynamic scoping, that's what they see: the
CL designers just threw in everything. But in reality the way
variables work in CL is not a union of everything around earlier.
It's a cleanup and generalization of what was in MacLisp and
similar Lisps. And it's not compatible with those earlier Lisps,
only (at most) with fairly clean subsets of those languages.
If you don't mean to say anything negative, there are probably ways to
make your point that I would not object to; but it's unlikely that
anything that talks of expedient compromise, labels Common Lisp a
union, or fails to recognize the extent to which CL was a cleanup
compared to earlier Lisps, will be among them.
-- jd
David Boles
In article <30503381...@arcana.naggum.no>,
Erik Naggum <er...@naggum.no> wrote:
>[David Boles]
>
>| Not at all, it [the "hello, world" test] really just measures how wide
>| a range of programming problems the language is usable for.
>
>language/compiler/operating-system combination to perform well _together_,
>while it does _not_ show any inherent values or qualities of the language,
>such as it is interpreted to do.
That's correct, but the acceptability of the language is partially
determined by the characteristics of the available implementations.
In fact, this was my precise point. The inability of existing
*implementations* to generate small executables is a retarding factor
in the usefulness of the language.
...
>C and Unix share an "assumption space" that is so closed that any other
>assumptions have a very high penalty while they retain minimal overhead.
>in operating systems designed for use by multiple languages, C is no better
>than, e.g., Fortran or PL/1, in fact it may be much worse, because the
>assumptions made in C are so difficult to spot that most programmers don't
>even realize they are there.
What operating systems exist today? Well, the following list certainly
covers most everything:
DOS, Windows95, OS/2, WinNT, UNIXen, Mach, Chorus, Plan9, QNX, MVS,
OS/400, VxWorks, AmigaOS, & VMS.
Any of these that supports VM (generally accepted as a good idea) with
the possible exception of OS/400 is going to face the math that I had
in my previous posting. Now, I'm certainly not one to just accept the
status quo, but I also don't spend much time thinking about how to get
the earth to spin the other way. These factors are a fixture of every
CPU architecture and will be for *years* to come.
If all implementations of a language generate executables that for
small, short-running programs have the property that the working set
overhead for the runtime system is large enough that the page-fault
overhead for it dominates the running time, then the language is not
useful for such applications. Many, many programs are small and short
running.
>it's pathetic how the C/Unix camp will insist upon loading the dice in any
>competition among languages, and on top of it, they do not even recognize
>that they have made assumptions that automatically make them win.
Gee, when I look around it looks more like an office than a camp. Maybe I
should be a little more paranoid :-).
Cheers,
David Boles
Bruce O'Neel
Hi,
Is there documention for NewtonScript somewhere?
thanks.
bruce
Paul R. Potts (po...@cancer.med.umich.edu) wrote:
: In article <AshleyB-2508...@news.halcyon.com>,
: Ash...@halcyon.com (Ashley Branchfeather) wrote:
: > I hear Apple originally acquired Dylan for the purpose of using it for the
: > Newton.
: In prototype, unreleased versions of the Newton project, Dylan or a
: precursor to it (infix syntax, legend has it called Ralph?) was used.
: The NewtonScript language, used for most Newton application development,
: is actually very cool and I recommend that anyone interested in language
: design take a look at it. While it isn't as featured as something like
: Dylan, you get:
--
on...@arupa.gsfc.nasa.gov -- Bruce O'Neel HSTX (301) 286-1511 -- So
you get an error in the ninth decimal digit to the right of the
mantissa. I think even if you're an engineer, you're not going to see
this. -- Steve Smith, Intel, from EE Times, 11/7/94
Raymond Toy
Cyber Surfer <cyber_...@wildcard.demon.co.uk> writes:
>
> In article <joswig-2908...@news.lavielle.com>
> jos...@lavielle.com "Rainer Joswig" writes:
>
> > Btw., CMU CL is being ported to Linux/x86. Another good sign.
>
> It already has been ported. For those who don't read the cola
> newsgroup, here's the announcement:
>
[announcement deleted]
You may also like to know that the FreeBSD version from Paul Werkowski
(http://www.mv.com:80/users/pw/lisp/) now runs on Linux too. (Perhaps
the changes were taken from the Linux port?) In any case, I find it
works a bit better than the Linux port, and it doesn't hang on (/ 2.0
0.0). It does have some minor problems with handling floating point
traps, but it doesn't hang and always returns the right results.
It's wonderful!
Ray
Tim Pritlove
>n article <y8alof2...@hertie.artcom.de>,
>Andreas Bogk <and...@artcom.de> wrote:
>>If it is an sockets interface, it suffers the same shortcomings the C
>>socket interface interface has. One thing that is impossible with
>>sockets is finding out where a connection request is coming from,
>>without actually accepting the connection.
>
>This is not a failing of the sockets API, it's a failure of the Unix
TCP/IP
>driver. It doesn't inform the process of the existence of the connection
>until after it has accepted the connection. There's nothing an API can do
>to provide features that aren't in the underlying implementation.
>--
>Barry Margolin
Barry,
I think you are not right at all. First there is nothing like an "UNIX
TCP/IP" Driver. The socket implementation brought in both the first
implementation of TCP/IP on UNIX _and_ a concept for integrating network
protocols in UNIX - sockets.
There is a very good interface in the UNIX world that does not suffer from
the socket drawbacks - TLI (Transport Level Interface) which was developed
together with the STREAMS module architecture for UNIX System V by AT&T. In
addition, TLI conforms to international standards (I guess its an ISO
standard but I can't tell now).
I agree that sockets are not a good foundation for networking. Good to see
that many systems manufacturers do not rely on it (OSI, IBM, Apple).
The above mentioned example (examining incoming connection indications
before accepting a connection) is an absolute must for security and
forwarding applications.
Tim
James Thiele
In article <506ne4$s...@post.gsfc.nasa.gov> on...@arupa.gsfc.nasa.gov (Bruce O'Neel) writes:
>Hi,
> Is there documention for NewtonScript somewhere?
>
Newton docs, including NewtonScript, are at:
http://devworld.apple.com/dev/newton/techinfo/docs.pdf.html
or they were at 1:15 PM PST 30 Aug 1996.
Hope this helps,
James Thiele
j...@eskimo.com
Alexey Goldin
It's wonderful!
Ray
Somehow CMU CL for Linux dissapeared from
ftp://sunsite.unc.edu/pub/Linux/Incoming and never appeared in
devel/lang/lisp. Makes me wonder.
How do I run FreeBSD CMU CL on Linux? just download and run or
there are some tricks to be done?
Cyber Surfer
> Btw., CMU CL is being ported to Linux/x86. Another good sign.
It already has been ported. For those who don't read the cola
newsgroup, here's the announcement:
> Newsgroups: comp.os.linux.announce
> Subject: CMUCL for Linux 1.00 - Lisp interpreter
> Followup-To: comp.os.linux.misc
> Date: Fri, 16 Aug 1996 02:06:34 GMT
> Organization: ?
> Lines: 89
> Approved: linux-a...@news.ornl.gov (Lars Wirzenius)
> Message-ID: <cola-liw-8401...@liw.clinet.fi>
> NNTP-Posting-Host: localhost
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Hi,
>
> I've uploaded CMUCL to sunsite.unc.edu. This is it's announcement:
>
> \begin
> Announcing: CMU lisp for Linux 1.00.
>
> This is a port from the FreeBSD version to linux. It still has a few rough
> edges but it can compile itself. Known bugs are:
>
> - - bad fp-support, it hangs on (/ 2.0 0.0). This turns out to be a bug in
> the original cmu lisp and the original freebsd port.
> - - reacts badly to a shortage of swap.
>
> The system requires about 16M to run, it only swaps a little when
> recompiling itself in 32M. Use *large* swapfiles, at least two times as
> large as our memory.
>
> CMU CL is a fully featured lisp, with a very good compiler that increases
> speed or security if you want to. The compiler checks all declared
> variables and their use.It is so good it almost makes lisp a
> typed language (like C where you have to declare the type of variables)!
>
> You need the runtime to compile cmu because it takes a working lisp to
> generate one. Some documentation is supplied, but this is still a
> bare-bones release.
>
> lsm:
>
> Begin3
> Title: CMU-lisp for linux
> Version: 04081996
> Entered-date: 4 Aug 1996
> Description: A port of CMU-lisp to Linux 2.0. CMU lisp is has
> very powerfull compiler "python". You'll find use
> for the documentation.tar.gz file from the 17f
> distribution.
> To recompile cmu, it needs itself. So if you download
> cmu-devel.tar.gz you WILL need runtime.tar.gz, or a
> working cmu lisp on a different platform. And the 17f
> cmu source tar.
> Keywords: Lisp,CMU,functional languager,programming
> Author: p...@snoopy.mv.com (Paul F. Werkowski)
> Maintained-by: nat...@uia.ac.be (Peter Van Eynde)
> Primary-site: sunsite.unc.edu /pub/Linux/devel/lang/Lisp
> 1268 CMUCL.lsm
> 10498K CMUCL-runtime.tar.gz
> 430K CMUCL-devel.tar.gz
> Alternate-site:
> Original-site: http://www.mv.com/users/pw/lisp
> Platforms: UNIX,X11
> Copying-policy: Public domain
> End
>
>
> All things considered, this should work even better than
> your regular Microsoft product.
>
> Groetjes, Peter
>
> \end
>
> - --
> It's logic Jim, but not as we know it.
> finger nat...@hipe.uia.ac.be for pgp public key.
> - -----BEGIN GEEK CODE BLOCK-----
> Version: 3.12
> GS/CS/L/C d->? s+:++>+@ a-- C++(+++)>$ ULOS++>++++$ P+>++++ L+++>++++
> E>++ W+(--) U++>+++ o>+ K? w--- O>+@ M-? V? PS++ PE(--) Y+ PGP+>++
> t++>+++ 5++ X++>+++ R tv b+++>++++ DI? D++@ G+>++ e++>++++ h!>+ r-@ y>+++**@
> - ------END GEEK CODE BLOCK------
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.2i
>
> iQCVAwUBMhPXXoQRll5MupLRAQHS9QP/cLBtUSbC9cL/rb6n4b//3wRsFoQosO+f
> 0pebssjTSNdSV5EFIA9KClqzJxi43/IeeRTgSDn7TEIrqopZLsr0/OyK+VZDZS3m
> ETX7wwz2gI+dNwAXqVkX21+4t9kGGz/rVD3i3L4An/wN2KK4eI0KH3v2ZErN68Pm
> wmwD4ieiuTs=
> =+G9J
> -----END PGP SIGNATURE-----
>
> --
> This article has been digitally signed by the moderator, using PGP.
> Finger wirz...@kruuna.helsinki.fi for PGP key needed for validating signature.
> Send submissions for comp.os.linux.announce to: linux-a...@news.ornl.gov
> PLEASE remember a short description of the software and the LOCATION.
Rainer Joswig
In article <841389...@wildcard.demon.co.uk>,
cyber_...@wildcard.demon.co.uk wrote:
> Excellent. Too bad my boss hates Macs.
Maybe you should get another boss?
> I am. I write code for Windows, in C/C++. :-( I dunno if
> Allegro CL for Windows can produce a binary that'll fit
> onto a single floppy, but it doesn't look like it can use
> OCX controls, so I can't use it for the stuff I'm paid to
> write. As I've said before.
As I said before, if it has to fit on a floppy (8" or 5 1/2"?)
Lisp may not be the solution. Or maybe you should look for
another Lisp implementation (Linklisp, MuLisp, XLisp,
PCScheme, NilsLisp, Gold Hill's CL, ...). See the Lisp FAQ.
> What can I do about it?
Ask the vendors (see the Lisp FAQ), whether they have a Lisp
that fits your needs? Write down what features you need
(size, performance, ffi, whatever, ...), ask the vendors
and publish the answers. Seems like some of them have
no will/capability to address the PC market the *right*
way. Questions by would-be-users may help waking them up
or help them staying in business.
> Sure, just give me a Lisp for Windows that can support the
> features I need. ACL can't do it.
Does Franz know about that? What was their answer?
Do any other Lisp users have experience with Lisp development
on the PC (besides systems needing more than 32 MB RAM
to run adequately)?
> Excellent. I'll point that out next time somebody claims that
> Lisp can't do anything useful. BTW, can it run under NT?
It can. But it will sure run better once the multithreaded
Common Lisp implementations from Franz and Harlequin are released.
Currently you need to buy a commercial CL implementation
to run CL-HTTP (atleast CL-HTTP comes for free).
> Give me a demo web server written in Lisp, running under NT,
> or a multimedia app using OCX, then I might be able to convince
> a few people. At the moment, all I have is words. None of these
> people give a shit about Lisp, coz they "know" that the stuff
> they want can't be done in Lisp.
To sad they don't use Macs. ;-) Apple is prototyping a next
generation multimedia development system in Lisp: SK8.
> Your words are encouraging, but only coz I feel sure that these
> things _can_ be done in Lisp. The problem is that all I have is
> this faith in Lisp. There's nothing concrete that I can take to
> my boss or a client and demonstrate for them. I can code all I
> want to in Lisp, but until I can produce such a demo, nobody
> will listen.
Macsyma and Axiom both run on the PC (sure won't fit on a floppy ;-) ).
Both are very cool systems written in Lisp. Actually there
is quite a lot Lisp software running on PCs.
> So, I'm writing a "toy" Lisp to C compiler,
There are Lisp to C compilers out there.
Btw., for some more pointers see http://www.lavielle.com/~joswig/lisp.html .
Greetings,
Rainer Joswig
Dieter Menszner
pmy...@unix.ccc.nottingham.ac.uk wrote about
"Re: Common LISP: The Next Generation":
...
> I got around my CL problems by writing my own LISP compiler. It's small
> and fast, and soon it will compile itself (at the moment it runs under
> a CL interpreter). Once it is bootstrapped, I will make it freeware.
> FYI: it writes .asm files to be assembled by TASM and run under DOS on
> a PC.
> I may eventually add CL compatability with librarys (if I ever decide I
> need all that stuff).
>
What about using the GNU as ? I don't have any idea of what has to be done
but in terms of portability this would be ideal.
Cyber Surfer
In article <5076jj$q...@zeppelin.convex.com>
dbo...@convex.com "David Boles" writes:
> If all implementations of a language generate executables that for
> small, short-running programs have the property that the working set
> overhead for the runtime system is large enough that the page-fault
> overhead for it dominates the running time, then the language is not
> useful for such applications. Many, many programs are small and short
> running.
There are many more programs that will be seen by _most_ users,
and they'll big programs that run for long periods of time.
Don't worry about C/C++ going away, losing your job, or finding
that all that accumulated C/C++ experience will become worthless.
If any of that will happen, it'll be because of languages like
VB and Java, and it'll happen regardless of whether you stand in
the way of progress or not.
> >it's pathetic how the C/Unix camp will insist upon loading the dice in any
> >competition among languages, and on top of it, they do not even recognize
> >that they have made assumptions that automatically make them win.
>
> Gee, when I look around it looks more like an office than a camp. Maybe I
> should be a little more paranoid :-).
You're just making more assumptions. Take a chance and look at a
new idea once in a while. ;-)
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
******* Boycott 'The Observer' - see uk.media for details *******
********** The witchhunt has finally arrived in the UK **********
We're living on a knife edge, looking for the ground -- Hawkwind
Cyber Surfer
In article <joswig-3108...@news.lavielle.com>
jos...@lavielle.com "Rainer Joswig" writes:
> In article <841389...@wildcard.demon.co.uk>,
> cyber_...@wildcard.demon.co.uk wrote:
>
> > Excellent. Too bad my boss hates Macs.
>
> Maybe you should get another boss?
If I could get a better boss, perhaps I would. However, this one
also happens to be one of my best friends, and it could easily be
that my best chance of being able to write Windows software using
the tools _I like_ is to work for him, instead of somebody with a
less open mind.
> > I am. I write code for Windows, in C/C++. :-( I dunno if
> > Allegro CL for Windows can produce a binary that'll fit
> > onto a single floppy, but it doesn't look like it can use
> > OCX controls, so I can't use it for the stuff I'm paid to
> > write. As I've said before.
>
> As I said before, if it has to fit on a floppy (8" or 5 1/2"?)
> Lisp may not be the solution. Or maybe you should look for
> another Lisp implementation (Linklisp, MuLisp, XLisp,
> PCScheme, NilsLisp, Gold Hill's CL, ...). See the Lisp FAQ.
I've seen the FAQ. How many of these Lisps support OCX controls?
Is Golden CL still available? Is it any better than ACL for Windows?
How many of the Lisps you mentioned actually have _any_ Windows
support? XLISP is an interpreter, and therefore totally inappropriate.
I'll need something that produces native code.
> > What can I do about it?
>
> Ask the vendors (see the Lisp FAQ), whether they have a Lisp
> that fits your needs? Write down what features you need
> (size, performance, ffi, whatever, ...), ask the vendors
> and publish the answers. Seems like some of them have
> no will/capability to address the PC market the *right*
> way. Questions by would-be-users may help waking them up
> or help them staying in business.
It certainly appears that Franz have not (in the past) had the
will/capacity to address the _mass_ PC market. They appear to
be happy with the very small and _invisible_ market that Lisp
already has. No wonder nobody believes that Lisp is a serious
development language.
I'm not even sure any more that Common Lisp or Scheme is the right
language. Dylan looks far more realistic, but that probably won't
be available to me for a couple of years.
> > Sure, just give me a Lisp for Windows that can support the
> > features I need. ACL can't do it.
>
> Does Franz know about that? What was their answer?
I've already asked them, perhaps last year. They weren't concerned
about it, stating that their market was large enough. I could ask
a few other vendors, but my feeling has been that if they have such
a low profile, how do I know they can deliver? How do I know they'll
still be around a year from now? I have my doubts.
More significantly, I'll also have to convince my boss. Why make
your software dependent on a product that has such an uncertain
future? I can understand that point of view, even if I personally
might take that chance.
> Do any other Lisp users have experience with Lisp development
> on the PC (besides systems needing more than 32 MB RAM
> to run adequately)?
I'm told that VC++ performs better with 64 MB of RAM than with
a mere 32 MB. ;-) I'd like to test this soon, by upgrading my
machine to 64 MB.
> > Excellent. I'll point that out next time somebody claims that
> > Lisp can't do anything useful. BTW, can it run under NT?
>
> It can. But it will sure run better once the multithreaded
> Common Lisp implementations from Franz and Harlequin are released.
> Currently you need to buy a commercial CL implementation
> to run CL-HTTP (atleast CL-HTTP comes for free).
Aha. Now the big questions: how does it perform compared to
servers written in C/C++, and does it support ISAPI? I'd love
to able to write CGI code in CL, but I need some damn good
reasons to justify doing it commercially.
Of course, if CL-HTTP isn't commercial, then this might not be
possible anyway. Some people prefer to have support they can
rely on (by paying for it) before they'll trust a product.
I'm used to working without any real support, but it might be
difficult in this case, as I'm not the one chosing the web
server software.
On the other hand, I perhaps could happily run such a server
on my own machine, but nobody else would be able to access it
(I'm not even on the company network).
Also, I'm the only Lisp programmer at the company I work for,
so it might not be wise to depend too heavily on a single
person for maintaining the company web server - assuming that
I _can_ actually do that. I'm not a Lisp expert, so it's
possible that CL-HTTP is beyond my understanding.
So, there would need to be a damn good reason for using CL-HTTP
instead of the many excellent commercial web servers already
available. I'm not knocking CL-HTTP, but it does have a major
disadvantage for any company not already using CL.
> > Give me a demo web server written in Lisp, running under NT,
> > or a multimedia app using OCX, then I might be able to convince
> > a few people. At the moment, all I have is words. None of these
> > people give a shit about Lisp, coz they "know" that the stuff
> > they want can't be done in Lisp.
>
> To sad they don't use Macs. ;-) Apple is prototyping a next
> generation multimedia development system in Lisp: SK8.
Excellent. I doubt the Mac we have could cope, as it's a
pretty old one, only used for transfering files from Mac
disks to PC disks. I've never seen it powered up. ;-)
Perhaps Franz or Harlequin should consider similar ideas?
I dunno if I'd spend $2500 just so I could say, "Yes, I
_can_ do multimedia development in Lisp", but I might have
a few other reasons to buy a commercial CL, esp if it was
the cut down version of ACL4Win, for $600. I've no idea
how much LispWorks costs, so I can't comment on it.
> Macsyma and Axiom both run on the PC (sure won't fit on a floppy ;-) ).
> Both are very cool systems written in Lisp. Actually there
> is quite a lot Lisp software running on PCs.
Where is it being used? I guess it must has a very low profile,
coz I only ever read about it on UseNet, in newsgroups like
comp.lang.lisp.
> > So, I'm writing a "toy" Lisp to C compiler,
>
> There are Lisp to C compilers out there.
With decent Win32 support? I'm still looking for it.
Meanwhile, I might as well have a go myself, just in
case I get there first. The quality of the code is not
important when it won't support the platform you use.
> Btw., for some more pointers see http://www.lavielle.com/~joswig/lisp.html .
Some of these links need updating, but I have the same
problem with my pages. You can never browse enough...
Thanks.
Raymond Toy
gol...@spot.uchicago.edu (Alexey Goldin) writes:
>
> How do I run FreeBSD CMU CL on Linux? just download and run or
> there are some tricks to be done?
>
Well, there's no binary available (unless you want one from me).
However, you can just grab the sources and build it yourself. It
works for me.
Ray
Richard A. O'Keefe
Anselm Lingnau <lin...@tm.informatik.uni-frankfurt.de> writes:
[Java generating Java and then running it]
>is going to be well-nigh impossible for the same reasons why it
>is well-nigh impossible in C++, only more so because of the so-called
>`security features'.
A Java program can write text to a file.
This text may be source text.
A Java program can load new object code at run time
(combining this with the "security features" is what
the bytecode verifier is all about).
If this were not so, down-loaded applets would not be possible.
All that's needed is a way to call the compiler in between.
I had a notion this was possible...
--
Australian citizen since 14 August 1996. *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.
Richard A. O'Keefe
Cyber Surfer <cyber_...@wildcard.demon.co.uk> writes:
>XLISP is an interpreter, and therefore totally inappropriate.
There has been a byte code version of XLISP for some time;
the current XLISP-STAT statistics package uses it.
>I'm not even sure any more that Common Lisp or Scheme is the right
>language. Dylan looks far more realistic, but that probably won't
>be available to me for a couple of years.
Hmm. You obviously haven't been reading comp.lang.dylan.
Lovely language, too bad its mother (Apple) wants it dead.
(By the way, how come the people who say "hello world is too big,
so Lisp is bad" aren't off trashing Java?)
Erik Naggum
[Richard A. O'Keefe]
| (By the way, how come the people who say "hello world is too big,
| so Lisp is bad" aren't off trashing Java?)
because prior to this (tantalizing oversimplification of a non-) argument,
there was a conclusion looking for an argument to support it. the same
conclusion does not apply to Java, therefore the argument is no longer
relevant.
#\Erik
--
those who do not know Lisp are doomed to reimplement it
Tim Bradshaw
* David Boles wrote:
> Sorry, you're not understanding the test. The "test" doesn't distinguish
> between an executable of 100 bytes and 64Kbytes. Both of these, on almost
> all systems of the last decade, are "small" and hence acceptable.
> However, producing executables of 300-3000KBytes is *not* acceptable
> for many tasks.
> [And some arguments that show that 1/2 Mb executables for tiny
> programs are slow based on page faulting costs vs fork/exec costs]
I think there are some hidden assumptions here.
Firstly you're assuming that all the pages of the executable are
touched, which needn't be the case. It is easy to imagine a system
where the minimum executable is very large, but almost none of it is
referenced at runtime -- perhaps only one page. All those extra pages
just sit on the disk. So the runtime of almost arbitrarily large
executables can be short. Of course you still burn disk space, but
then you can do a shared-library system if you care about that.
Secondly you're assuming that compiling an executable is a reasonable
way to work. If *I* was trying to run a hello world program I'd just
type it into a Lisp I have lying around. CMUCL on a sparc gives a
691-byte binary for a program does (format t "hello world~%"). Of
course not everyone has running lisps sitting there, but it would be
perfectly reasonable to have a lisp server per person which listens on
a socket or something.
Just because compiling a stand alone executable has always been the
Unix way doesn't mean it has to be like that. It may not even be
desirable for people trying to write `Unix-friendly' lisp systems to
concentrate on small executables for small programs -- small fasl
files are enough if you're willing to have a server-based system.
--tim
Tim Bradshaw
* Cyber Surfer wrote:
> In article <joswig-2908...@news.lavielle.com>
> jos...@lavielle.com "Rainer Joswig" writes:
>> Btw., CL-HTTP (from the MIT AI Lab) is the first HTTP 1.1 server.
> Excellent. I'll point that out next time somebody claims that
> Lisp can't do anything useful. BTW, can it run under NT?
Yes I think so. There is a version that runs under ACL for windows
and that runs under NT.
--tim
Rainer Joswig
In article <841563...@wildcard.demon.co.uk>,
cyber_...@wildcard.demon.co.uk wrote:
> Of course, if CL-HTTP isn't commercial, then this might not be
> possible anyway. Some people prefer to have support they can
> rely on (by paying for it) before they'll trust a product.
> I'm used to working without any real support, but it might be
> difficult in this case, as I'm not the one chosing the web
> server software.
I'm using GNU Emacs, it isn't a commercial product either.
> Also, I'm the only Lisp programmer at the company I work for,
> so it might not be wise to depend too heavily on a single
> person for maintaining the company web server - assuming that
> I _can_ actually do that.
With CL-HTTP you can build interfaces for web sites, so that
they are maintainable by a nonprogrammer.
> I'm not a Lisp expert, so it's
> possible that CL-HTTP is beyond my understanding.
Could be.
> Where is it being used? I guess it must has a very low profile,
> coz I only ever read about it on UseNet, in newsgroups like
> comp.lang.lisp.
Ever heard of AutoCad? Reduce? MuMath? Never heard of Macsyma?
HotMeTaL? Interleaf? Abuse? A lot of CAD systems are using Lisp.
Math software is using Lisp. Music software is using Lisp. Electrical
CAD software uses Lisp. Diverse AI software uses Lisp. How
does it come there are so many Lisp implementations for the PC?
> > Btw., for some more pointers see http://www.lavielle.com/~joswig/lisp.html .
>
> Some of these links need updating, but I have the same
> problem with my pages. You can never browse enough...
Which links do have problems?
Well, (using CL-HTTP 60.17 and Macintosh Common Lisp running
on a PowerBook 5300c connected to the Internet via PPP) let's see:
(defun problematic-urls (urls)
(loop for url in urls
for headers = (ignore-errors (http:get-url-headers url))
unless headers
collect url))
(problematic-urls
(let ((url:*url-host-name-resolution* :never)
(url (url:url "http://www.lavielle.com/~joswig/links.html")))
(w4::collect-hyperlinks url
(http:get-url-headers-and-body url))))
->
(#<HTTP-PATH http://legend.gwydion.cs.cmu.edu:8001/ ... )
Greetings,
Rainer Joswig
Cyber Surfer
In article <ey3k9ud...@staffa.aiai.ed.ac.uk>
t...@aiai.ed.ac.uk "Tim Bradshaw" writes:
> >> Btw., CL-HTTP (from the MIT AI Lab) is the first HTTP 1.1 server.
>
> > Excellent. I'll point that out next time somebody claims that
> > Lisp can't do anything useful. BTW, can it run under NT?
>
> Yes I think so. There is a version that runs under ACL for windows
> and that runs under NT.
Splendid! I don't expect it to convince many people, but it'll be
good to know. Thanks.
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
Kenneth D. Forbus
We're developing various programs, some in Common Lisp [ACLPC] and some in C++
[Borland] on NT & Win95 platforms. Some observations:
** Programmer productivity in Common Lisp is vastly better than C++. As
someone said about C: "The power of assembly language, with the abstraction of
assembly langauge". Even for the program that uses C++, we develop first in a
Lisp version and then reimplement in C++.
** Bad implementation decisions are language-independent. But the more
low-level stuff you have to reinvent or put together from disparate sources,
the more likely you are to lose.
** The "small executables" argument is irrelevant for many purposes. All the
PC's our target schools are buying are more than ready to run Lisp, not
because they knew we were coming, but because they want multimedia.
We deliver stuff in Common Lisp on two floppies, it will probably stretch to
three soon not because of Lisp but because we are expanding the help system!
We do have problems at the momemnt with some of our users who still have small
amounts of RAM (8MB), but they are all upgrading anyway because of the demand
for multimedia. This probably won't be an issue by this time next year.
The only reason we use C++ for one of the programs is because we expect it to
be used on PC's that have three or four other programs running on them as
well, so our RAM footprint has to be as small as possible. The C++ code eats
several MB of RAM, which is less than the equivalent Lisp version would be.
But if it wasn't for that constraint, we would just deliver the Lisp version
instead. (We do that sometimes already, because the Lisp version tends to be
months ahead of the C++ version!)
Look, no language is perfect for every purpose. But Common Lisp is already
the best language around for developing really complex software, and most of
the complaints that people have had about it are becoming less and less
relevant as computers get faster and more capacious and as the vendors
integrate better with their native environments. I think it's more fruitful
describing cool things one is doing with Common Lisp than angsting about how
one might change the language to address shibboleths of the past.
[Examples: Check out our web site. CyclePad is written in Common Lisp.
The Active Illustrations demo movie shows the Lisp version of the software;
we've made the C++ version alot prettier, but we would never have gotten it
working without the Lisp implementation as a very concrete specification.]
Ken
==========================================
Prof. Kenneth D. Forbus
Qualitative Reasoning Group
The Institute for the Learning Sciences
Northwestern University
1890 Maple Avenue
Evanston, Illinois, 60201, USA
email: for...@ils.nwu.edu
voice: (847) 491-7699
fax: (847) 491-5258
http://www.qrg.ils.nwu.edu/
==========================================
Jeff Dalton
In article <841391...@wildcard.demon.co.uk> cyber_...@wildcard.demon.co.uk writes:
>In article <30503381...@arcana.naggum.no>
> er...@naggum.no "Erik Naggum" writes:
>
>> competition among languages, and on top of it, they do not even recognize
>
>I agree. Unfortunately, being wrong sometimes doesn't stop people
>from succeeding. I'm not sure who said this, but I recall reading
>something in the August 1981 issue of Byte (the Smalltalk issue),
>"A operating system is a collection of things that don't belong
I happen to greatly prefer having an operating system with
proper memory protection, etc, to the systems (e.g. on Lisp
machines) that more or less got rid of the distinction.
Moreover, I want exiting Lisp and starting a new Lisp to
be a relatively lightweight operation compared to rebooting
the machine. I guess I'm just funny that way. ^_^
In any case, while the dice may well _be_ loaded, Lisp systems
could preduce much smaller executables than they usually do.
Indeed, a Lisp could fairly easily produce a "Hello, world!"
program that's as small as a C one. Suppose the source code
was:
(format t "Hello, World!~%")
It doesn't need to alloc anything at run-time, so no GC is needed.
Format strings can be compiled. (If I recall correctly, the XP
pretty printer has conde that does that.) And writng the string
can be handled directly by an OS write operation. You might
think that a Lisp would have to arrange for the string to be
aproper Lisp object, but that's not necessary. Writing a
constant string could be optimized by the compiler.
Ah, soemone will say, what if you write slightly larger
programs. Then you'll have the GC and all that other Lisp
stuff. Probably you will. But such things can be pretty
small. Most Lisp implementatinos are pretty big these
days, but they can be very small. (N.B. Lisp does not =
Common Lisp; but even Common Lisps could produce vastly
smaller executables than they typically do.)
Now, standard Lispy run-time stuff (such as the GC) that almost
all programs will want can be shared. Maybe they're in a shared
library. That's not all that different from having them in the OS.
(Think e.g. of micro-kernels with various things running as
separate processes. That something isn't in the kernel per
se shouldn't matter very much.) Even without shared libraries,
a good virtual memory implementation will let much be shared
(and will avoid touching pages that are not needed).
So, yes, Lisp vs C size comparisons are almost all bogus,
but it's also true that many Lisps could do better.
-- jd
John C. Wang
Thomas Kwong <tomk...@wilshire.com> wrote in article
<322614...@wilshire.com>...
> After playing with so many different programming languages for
> a couple years, I finally realized that *language does not matter*.
> It's almost a waste of time trying to relearn whatever we already
> know. Do everyone in the world speaks the same language? No.
> Stick with the language you like the most and be happy.
>
> BTW, Java is the most fun language I have ever known, next to
> Scheme.
>
> Tom
I think for a programming language is a different thing. It's bears more
resemblance to an
electrical specification than it does to one's mother tongue. A "good"
programming
language can be efficient, portable, readable, provable, ... among other
nice things.
No matter how good you are at writing assembly code, you still can't cut
your
maintenance cost below that for code written by a fairly experienced C++
programmer.
John.
Cyber Surfer
In article <50e478$3...@goanna.cs.rmit.edu.au>
o...@goanna.cs.rmit.edu.au "Richard A. O'Keefe" writes:
> Cyber Surfer <cyber_...@wildcard.demon.co.uk> writes:
>
> >XLISP is an interpreter, and therefore totally inappropriate.
>
> There has been a byte code version of XLISP for some time;
> the current XLISP-STAT statistics package uses it.
I wasn't aware of that, thanks. The FAQ only mentions an
experimental version - is that what you mean? I was refering
to the non-experimental version, as that's the one that most
people will know. I doubt that the experimental version will
be as widely distributed, even if _we_ know about it.
Unless the experimental version of XLISP is commercial, and
is fully supported, many developers won't touch it. Just being
experimental may be bad enough - some people won't trust beta
(or "pre-release") versions of a product, never mind experimental.
I like XLISP a lot, but it has a few disadvantages. It's fine
for personal use, and I use it and many tools like it without
any problems. However, if you want a tool for serious Windows
development, then it fails miserably. IMHO that's asking too
much of it, rather than a failing of XLISP itself.
Put another way, unless a Windows development tool supports
Windows features like OCX, then it'll be ignored. Look at what
VB gives a programmer, then imagine a Lisp that supports all
those features. If it exists, then it's a well kept secret.
I'm sorry for appearing obsessed with Windows, but that's the
platform that I and most of the people that I know use. These
are the people that I see ignoring (if not laughing at) Lisp.
Perhaps this is because all they see is XLISP. Well, it is
widely available, while far more complete and _commercial_
demo Common Lisps are not so widely "available". They may be
accessible to anyone with access to the Web, but you still
need to know they're there, and most people won't.
Also, most of these people won't even care. They may still
be too obsessed with the "Pascal vs C" issues to give a damn
about Lisp, or anything like it. The "VC++ vs VB" question
may be another example, but I don't know. I don't care enough
to bother looking for people "debating" it. See below.
> >I'm not even sure any more that Common Lisp or Scheme is the right
> >language. Dylan looks far more realistic, but that probably won't
> >be available to me for a couple of years.
>
> Hmm. You obviously haven't been reading comp.lang.dylan.
> Lovely language, too bad its mother (Apple) wants it dead.
Can Apple kill Dylan? I dunno, but what's to stop CMU & Harlequin
from just picking a new name and continuing?
> (By the way, how come the people who say "hello world is too big,
> so Lisp is bad" aren't off trashing Java?)
My guess is coz Java looks so much like C/C++ that they're more
inclined to accept it. IMHO this has nothing to do with technical
details and everything to do with "politics". People use what they
do because they can, but perhaps some people like to justify it.
A few will resort to some very odd means of doing this.
I've always found this to be bizarre behaviour, even when I first
encountered it, and I was as guilty of it as anyone at the time.
It was a Z-80 vs 6502 debate. I later wondered at how much of a
coincidence it was that I used a TRS-80, with a Z-80 in it, while
the other guy had a PET, with a 6502 in it. I know that the use
of a Z-80 wasn't a factor in the choice in the purchase of that
machine - neither I nor my dad (I was a teenager at the time)
knew or cared what a Z-80 was.
In the end, we "settled" the argument with a game of chess,
played by our two machines, playing on the lowest level available
on each chess program (Sargon and ???). It was a draw. ;-)
I know it was an arbitrary test - that was the whole point.
Still, that has nothing to do with the sad behaviour that could
be called "advocacy", but might be more accurately named, "tribal".
So, I don't care what C/C++ say or think. My answer to the "Hello,
World" argument is that I use Lisp _because I can_. What I don't
want to do is waste my time agreeing to the loaded terms of the
HW argument, when I can make a far more valuable point: that these
machines are here to serve _us_, not the other way around.
If Java seems to be escaping the attacks that Lisp has received,
then I'm glad. Perhaps it means that the C/C++ bigots are finally
beginning to understand what Lisp (and Smalltalk etc) programmers
discovered before them: that programming can be a lot more fun,
and a hell of a lot more productive, in some of the alternatives
to C/C++ - providing that your mind is open enough to consider
that this might be possible.
Look at it this way: what's the difference between Pascal and C?
Not much, when you compare these languages with, let's say, CL.
That didn't stop Pascal and C programmers from bickering about
"which langauge was best". My attitude has been to let the sad
bastards get on with it - so as they do it somewhere that won't
bother me. The "Z-80 vs 6502" question is now irrelevant to most
programmers. Fewer and fewer of us even bother programming at
the assembly level.
I think of Java in many ways, but mainly as a step toward ending
the love affair that so many programmers have with C/C++. It'll
introduce them to some "new" ideas, even if Lisp programmers have
known and used them for years. Many Smalltalk programmers may
also be laughing, and I won't blame them.
Perhaps I won't be using Dylan in a few years. For all I know,
by the time that Gwydion appears there may be reasonably complete
Scheme compilers for the JVM and interpreters built on top of
it (that should be even easier, if you can write your Scheme
interpreter in Scheme). It may also be possible that there'll
be Scheme enviroments running on the JVM that can rival anything
that already exists. I dunno, but I hope so. That way, whatever
future Scheme developments may occur will be available on any
platform that Java supports, instead of just one or two.
One point that I often see overlooks is the fact that a great
many computer users (and developers) can't choose the software
they work with. Those of us lucky enough to able to make these
choices for ourselves may a priviledged elite. Worse than that,
we may be irrelevant.
The Hawkwind quote in my current sigfile reflects certain
recent events in the UK media, but could be just as applicable
to software development, I think. Take care, everyone.
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
Oleg Moroz
>> Where is it being used? I guess it must has a very low profile,
>> coz I only ever read about it on UseNet, in newsgroups like
>> comp.lang.lisp.
>
>HotMeTaL? Interleaf? Abuse? A lot of CAD systems are using Lisp.
>Math software is using Lisp. Music software is using Lisp. Electrical
>CAD software uses Lisp. Diverse AI software uses Lisp. How
>does it come there are so many Lisp implementations for the PC?
[I'm sure the original author meant not Lisp itself (having low profile), but
some particular commercial Lisp implementor, whom he tried to contact about some
features he needed.]
Have you heard that AutoDesk is switching for Visual Basic for Applications ? I
never heard about other Lisp-based CAD systems. What market share do they have ?
What market share has Reduce or MuMath or Macsyma ? As far as I can tell it's
still Mathematica and Maple and MathCAD world. Abuse is a nice game, but about 2
percent of my friends interested in computer games even heard of it, not mention
playing. It's still Doom, Terminal Velocity and Sierra On-Line quests world. AI
software using Lisp ? Yes, I know the term... but I don't know any AI soft on
the mass market. Can you tell me the name ?
So guys, Common Lisp is wonderful language. Scheme is wondeful language. Dylan
is wonderful language. Haskell is even more wondeful. I can't wait for the time
when I can write the kind of applications I write for living in one of these
wonderful languages. But right now I just can't. And nobody can do it right now.
Most Lisp implementations for PC either lack major features I need everyday
(small executables, using "native" system features (in Windows it's OLE2, OCX's,
DLL generation and usage, multi-threadness, good integration with native API,
etc), good development environment, speedy execution of resulting production
code, ...) or are priced too much and still lack some of these features. Really,
I never seen the Lisp/Dylan/SML/Haskell-based development environment that
satisfied even a half of my needs. And Visual C++ or Delphi 2.0 for example, is
not perfect, but meets my needs _much_ better. And I don't talk about writing
drivers or some low-level hacks - it's pure user interface.
Another point here - have you seen the work done at Microsoft research labs on
Intentional Programming ? That thing is supposed to end language wars once and
for all - and it's real I'd say... And I'm sure it will integrate with Windows
as seamlessly as possible - it's Microsoft after all. Too bad they say it'll be
in "product" state in 2000 :-(
Oleg
Oleg Moroz
On 02 Sep 1996 11:47:32 +0100, Tim Bradshaw <t...@aiai.ed.ac.uk> wrote:
>I think there are some hidden assumptions here.
>
>Firstly you're assuming that all the pages of the executable are
>touched, which needn't be the case. It is easy to imagine a system
>where the minimum executable is very large, but almost none of it is
>referenced at runtime -- perhaps only one page. All those extra pages
>just sit on the disk. So the runtime of almost arbitrarily large
>executables can be short. Of course you still burn disk space, but
>then you can do a shared-library system if you care about that.
First, if you want to distribute your software "en masse", the executable size
matters. Even the companies targetting CD distribution tend to decrease the
executable size, because they usually give the user an option to install
executables on the hard disk thus decreasing startup time. And when you use two
or three CD-based packages simultaneously, you are forced to install some of
them on your HD (I usually use Visual C++ plus MSDN -- VC is fully installed on
my hard drive, taking about 150MB).
Second, AFAIK most OS's that use paging map all of the executable to memory when
making the system call analogous to 'exec' (probably creating separate maps for
code, data, resources etc). Thus, even if you don't touch significant parts of
the image, the system will waste some amount of memory for maintaining page
tables (proportional to the executable size).
Oleg
Mark Tillotson
Anselm Lingnau <lin...@tm.informatik.uni-frankfurt.de> wrote:
> In article <32242ff6...@news.alt.net>,
> Phil Perucci <pper...@idsonline.com> wrote:
>
> > Anyway, can anyone shed any light on the ability of Java to perform
> > LISPs (eval) function? It would be very nice to generate Java code,
> > and pass it back to Java for compilation/execution, which is one of
> > the main things LISP was famous for (that and lists...).
>
> This is going to be well-nigh impossible for the same reasons why it
> is well-nigh impossible in C++, only more so because of the so-called
> `security features'.
>
security checking can check it. You unfortunately have to generate a
vector of bytes to represent the new class definition, and present it
to a suitable class-loader, but thereafter you simply instantiate an
instance and do what you want. To do anything useful you tend to use
interface types.
Note that the Java compiler is written totally in Java, and apart from
redirection of its reads and writes to in-core class byte-vectors, all the
machinery is there to do this. It seems a bit of a shame you are
currently forced to use the file-system though.
(In common lisp this would be sort of like
(defun eval (form) (funcall (compile `(defun temp () ,form))))
except having to synthesize compile from compile-file)
__Mark
[ ma...@harlequin.co.uk | http://www.harlequin.co.uk/ | +44 1954 785433 ]
[ personal homepage http://www.juggling.org/~ma...@harlequin.co.uk/ ]
[Is this another instance of confusion caused by myth that Java and C++
are languages with similar semantics I wonder?]
John Brewer
First, off I'd like to apologize for the flame bait a couple weeks ago.
It was rude of me, and I'll try to avoid it in the future.
In article <841735...@wildcard.demon.co.uk>,
cyber_...@wildcard.demon.co.uk wrote:
> > (By the way, how come the people who say "hello world is too big,
> > so Lisp is bad" aren't off trashing Java?)
>
> My guess is coz Java looks so much like C/C++ that they're more
> inclined to accept it. IMHO this has nothing to do with technical
> details and everything to do with "politics". People use what they
> do because they can, but perhaps some people like to justify it.
> A few will resort to some very odd means of doing this.
>
Java doesn't just look a lot like C -- the algorithmic syntax is virtually
identical to C's. For example, on Sunday I was writing the obligatory
Mandelbrot set applet. I copied the inner loop straight from a K&R C
program I'd written 11 years earlier. It compiled just fine, and I got
the entire applet working in under 4 hours.
Now this may be a contrived example, but a lot of companies have an awful
lot of old C code out there, and being able to retool it into Java quickly
and easily is a big win. Being able to retool your programmers quickly
and easily is an even bigger win, since in the long run they're an even
bigger asset than your code base.
Gabor Greif
just browsing around in the Web, I found a quite interesting pointer
to
a forthcoming publication on Dylan.
That could be interesting to the .lisp and .scheme communities too --
dare a look !-)
here the URL
http://www.harlequin.com/books/dylan-book/index.html
of course the "mother of all Dylan books" is the Dylan Reference
Manual
http://www.harlequin.com/books/DRM/
thanks to Harlequin for providing this valuable source.
Gabor
Richard A. O'Keefe
Tim Bradshaw <t...@aiai.ed.ac.uk> writes:
>Just because compiling a stand alone executable has always been the
>Unix way doesn't mean it has to be like that.
I am reading this in comp.lang.dylan.
Given the origins of Dylan, I think it is reasonable to point out that
in Apple's "other" dynamic object-oriented language, NewtonScript, it
genuinely isn't like that. A NewtonScript application joins a whole
bunch of other stuff, and expects to place incremental revisions over
a large bunch of useful stuff already sitting in ROM.
In fact they went for a very powerful Lisp/Self-like language precisely
*because* they wanted small applications to run on a small machine.
Cyber Surfer
In article <joswig-0209...@news.lavielle.com>
jos...@lavielle.com "Rainer Joswig" writes:
> In article <841563...@wildcard.demon.co.uk>,
> cyber_...@wildcard.demon.co.uk wrote:
>
> > Of course, if CL-HTTP isn't commercial, then this might not be
> > possible anyway. Some people prefer to have support they can
> > rely on (by paying for it) before they'll trust a product.
> > I'm used to working without any real support, but it might be
> > difficult in this case, as I'm not the one chosing the web
> > server software.
>
> I'm using GNU Emacs, it isn't a commercial product either.
I'm using loads of non-commercial software, and my favourite app
has been obselete for several years, and is no longer supported.
The attitude of the people who write is "upgrade to our new version".
The "new version" is a very different app - as it includes loads
of stuff I _don't need and don't want_, and doesn't have the stuff
that I _do want_.
This happens all the time. What counts is that non-suppported
software will be harder to use in certain enviroments. For personal
use, on a personal machine, there's no problem. Development of
software can be one of those demanding situations, because the
client may demand things that you, the developer, don't normally
worry about. Sometimes the client's demands dictate that you only
work with supported software. That's some people's definition of
"mission critical".
In other words, Emacs may be a fine editor, but some people will
still insist that you a commercial alternative. Nothing you or I
may think or say will change that.
> > Also, I'm the only Lisp programmer at the company I work for,
> > so it might not be wise to depend too heavily on a single
> > person for maintaining the company web server - assuming that
> > I _can_ actually do that.
>
> With CL-HTTP you can build interfaces for web sites, so that
> they are maintainable by a nonprogrammer.
Is this a standard feature of CL-HTTP, or would a programmer
be needed to build such an interface? Could the server the
maintained _without_ a CL programmer? The concern that I know
will stop my employer, for example, from using CL-HTTP will
be that only one person in the company will be able to use
CL, and since we have a policy of never putting a mission
critical part of a business in the hands of just one person,
CL-HTTP would make us more vulnerable than if we chose a
commercial web server (like the many web servers available
for NT).
I don't think we can just ignore the fact that the supply of
CL programmers is not abundant, so most companies wishing to
run a web server won't have the CL expertise required (in the
example given above, a minimum of two people). I can't even
call myself a CL expert, while I have no trouble installing
and maintaining a typical web server for NT. So, even I have
doubts, and I'm pro CL!
> > I'm not a Lisp expert, so it's
> > possible that CL-HTTP is beyond my understanding.
>
> Could be.
That's my fear. If I'm not sure, then I know what most others
will think. If I suggest that CL-HTTP should be used instead
of a well-established commercial web server, I know what their
response will be, and it'll use some four letter words. This
may be the kind of hostility that the Lisp community should be
well used to by now, judging by the number of examples we've
seen of it in these newsgroups and elsewhere.
If a company already uses and trusts Lisp, then using it for
their web server may be a natural approach. However, anywhere
else people may look at it as madness. I'm not saying they're
right, but if the Lisp experience isn't sufficient to support
using CL-HTTP on a mission critical server, then perhaps it
_would be_ madness. That's not to say that the software is no
good, or that Lisp has any problems. It's simply a necessary
part of the way the computer industry works. People use the
technology they know and trust, and most people don't know
Lisp, and what they don't know, they won't trust.
> > Where is it being used? I guess it must has a very low profile,
> > coz I only ever read about it on UseNet, in newsgroups like
> > comp.lang.lisp.
>
> Ever heard of AutoCad? Reduce? MuMath? Never heard of Macsyma?
> HotMeTaL? Interleaf? Abuse? A lot of CAD systems are using Lisp.
> Math software is using Lisp. Music software is using Lisp. Electrical
> CAD software uses Lisp. Diverse AI software uses Lisp. How
> does it come there are so many Lisp implementations for the PC?
HotMetal uses Lisp? Good grief. My colleagues use this app,
and yet remain ignorant of Lisp. Same with AutoCad. They've
no use for MuMath, so that'll not convince them. Same with
Reduce. You're using some pretty exotic examples, which is
what I expected. _This_ is why so many people have not heard
of Lisp, and many of those who have will base their opinions
of it on some very outdated versions. See the intro to Winston
and Horn, where they debunk these common myths. Sadly, most
people don't read that book and will never have even heard of
it, nor will they understand why they should.
Remember that most people won't know or care what technology
their apps are based on. Most users will be more familiar with
a spreadsheet macro language than Lisp.
I'm not attacking Lisp, but the Lisp people who think that
this is not their problem. Well, IMHO it is. Lisp is ignored
by most people because the kind of Lisp available to them is
completely irrelevant. Perhaps Dylan will change this, but
I dunno. I only hope so. It certainly appears to me that the
designers of Dylan undertood this problem.
It often seems to me that the designers of Java understood it
even better. Java is not Lisp, and that may well be why it's
so popular. I still prefer Lisp, but I can understand why so
many others don't. It often seems to me that Lisp people don't
appreciate this enough.
> Which links do have problems?
There may have been some others, but I'm pretty sure about the
Scheme page. There were a number of failed links there. I got
at least one 404 error, so I don't think this is just a routing
problem at my "end".
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
Cyber Surfer
In article <Dx50Mu.2uo...@cogsci.ed.ac.uk>
je...@cogsci.ed.ac.uk "Jeff Dalton" writes:
> I happen to greatly prefer having an operating system with
> proper memory protection, etc, to the systems (e.g. on Lisp
> machines) that more or less got rid of the distinction.
> Moreover, I want exiting Lisp and starting a new Lisp to
> be a relatively lightweight operation compared to rebooting
> the machine. I guess I'm just funny that way. ^_^
I'm used to that way of working, because that'll all that's been
available to me. Most of the machines I've used didn't an OS that
used memory protection, but neither were they Lisp Machines.
They ran things like CP/M-68K, GEM, or DOS. All "real mode" OSs.
> In any case, while the dice may well _be_ loaded, Lisp systems
> could preduce much smaller executables than they usually do.
This why I'm keen to see what Dylan systems like Gwydion will be
like. Perhaps in something like 3 years time, I'll have a chance
to find out. It's hard to predict what'll happen 3 years from now.
> Indeed, a Lisp could fairly easily produce a "Hello, world!"
> program that's as small as a C one. Suppose the source code
> was:
>
> (format t "Hello, World!~%")
>
> It doesn't need to alloc anything at run-time, so no GC is needed.
It doesn't need to statically link, either. However, all the
compiled Lisps I've used have delivered code in a statically
linked image file. Some other languages have also done this.
(As far as I know, Actor is no longer.)
> Format strings can be compiled. (If I recall correctly, the XP
> pretty printer has conde that does that.) And writng the string
> can be handled directly by an OS write operation. You might
> think that a Lisp would have to arrange for the string to be
> aproper Lisp object, but that's not necessary. Writing a
> constant string could be optimized by the compiler.
Agreed. It should be pretty simple for a compiler to determine
that the literal string will only be used by that one function
call.
> Ah, soemone will say, what if you write slightly larger
> programs. Then you'll have the GC and all that other Lisp
> stuff. Probably you will. But such things can be pretty
> small. Most Lisp implementatinos are pretty big these
> days, but they can be very small. (N.B. Lisp does not =
> Common Lisp; but even Common Lisps could produce vastly
> smaller executables than they typically do.)
Yes, just avoid static linking. I don't know about Unix, but
a programming language for Win16/Win32 that uses static linking
only will be seen as a very poor tool. Never mind issues like
GC performance. Even a _C compiler_ for Win16/Win32 has to
support dynamic linking in order to be accepted as a serious
development tool. This isn't a language issue - it's a delivery
issue. Maybe this is different for Unix, but for Windows, a
"larger than necessary" binary is considered to be unforgivable.
It's subjective, of course, but both users and developers are
very sensitive to the code size, and yes, all those enourmous
Windows apps _are_ heavily criticised for being _too big_. If
it wasn't for all those features, nobody would put up with it.
In fact, some people _don't_. That's part of the problem...
> Now, standard Lispy run-time stuff (such as the GC) that almost
> all programs will want can be shared. Maybe they're in a shared
> library. That's not all that different from having them in the OS.
> (Think e.g. of micro-kernels with various things running as
> separate processes. That something isn't in the kernel per
> se shouldn't matter very much.) Even without shared libraries,
> a good virtual memory implementation will let much be shared
> (and will avoid touching pages that are not needed).
Exactly. This is why Windows developers using MFC can use the
MFC DLL, so that the code will be shared with any other apps
using that DLL. For Win32, that's a _big_ DLL. A lot of other
code that could be statically linked is also available in DLLs.
This isn't just a neat idea bolted onto the OS. The entire API
that an app will use is available as a set of DLLs.
So, put the language support code into DLLs, and you're a step
closer to a Lisp Machine. ;)
> So, yes, Lisp vs C size comparisons are almost all bogus,
> but it's also true that many Lisps could do better.
Most certainly. I've been saying that on UseNet for the last
couple of years. It's easy to get the impression that most Lisp
people here have lost touch with the "real world", and then
winge about how that world has ignored them.
Well, see the Hawkwind quote in my sigfile.
Dorai Sitaram
In article <841843...@wildcard.demon.co.uk>,
Cyber Surfer <cyber_...@wildcard.demon.co.uk> wrote:
>
>HotMetal uses Lisp? Good grief. My colleagues use this app,
>and yet remain ignorant of Lisp. Same with AutoCad. They've
>no use for MuMath, so that'll not convince them. Same with
>Reduce. You're using some pretty exotic examples, which is
>what I expected. _This_ is why so many people have not heard
>of Lisp, and many of those who have will base their opinions
>of it on some very outdated versions. See the intro to Winston
>and Horn, where they debunk these common myths. Sadly, most
>people don't read that book and will never have even heard of
>it, nor will they understand why they should.
The single page that Winston (with Horn) spends on
"debunking" unflattering myths about Lisp is more than
compensated by the three popular and excellent books by the
selfsame Winston plugging C, C++, and Java,
respectively. :->
--d
Rainer Joswig
In article <841693...@wildcard.demon.co.uk>,
cyber_...@wildcard.demon.co.uk wrote:
> In article <ey3k9ud...@staffa.aiai.ed.ac.uk>
> t...@aiai.ed.ac.uk "Tim Bradshaw" writes:
>
> > >> Btw., CL-HTTP (from the MIT AI Lab) is the first HTTP 1.1 server.
> >
> > > Excellent. I'll point that out next time somebody claims that
> > > Lisp can't do anything useful. BTW, can it run under NT?
> >
> > Yes I think so. There is a version that runs under ACL for windows
> > and that runs under NT.
You may consider undertaking a coding project to help advance
CL-HTTP: http://wilson.ai.mit.edu/cl-http/projects.html .
Give the C weenies something to think about. There are
many interesting projects for students. There is a lot
to learn. And more to come. Better start now.
Just saw a television report from "CeBIT Home" (german computer fair
with some 200000 visitors in five days). The big topic was "multimedia"
and the web. Guess what they showed in this TV report?
Henry Lieberman's browsing assitent for Netscape. Agents as the
next thing beyond systems like Yahoo and AltaVista.
The software is, guess what, written in Macintosh Common Lisp.
And it was watching out for some pages about "programming
by example" and Lisp.
Last week I bought a german newspaper. They had a story about
how computers changed our live. They had a **nice** picture.
On the left a Connection Machine and on the right a Symbolics
Lisp machine console. Gets me thinking, where are we ten years
later? (Btw., I contacted a friend at the newspaper. I
got a scan and will donate it later to the "Online Symbolics
Museum" at http://www.brightware.com/~rwk/symbolics/ .).
On CeBIT Home the japanese company Toshiba presented a tiny
computer (the size of a paperback): 640x480 16bit color TFT
screen, DX4 75 like processor, 8-20 MB RAM, 270 MB disk,
PCMCIA slot. This thing was really small - a sub sub notebook.
It runs Windows 95. You think CL is to large? To large for what?
Better start coding now and produce some useful (Lisp) software.
Greetings,
Rainer Joswig
Rainer Joswig
In article <322c991e...@news-win.rinet.ru>, mo...@inist.ru (Oleg
Moroz) wrote:
> Have you heard that AutoDesk is switching for Visual Basic for
Applications ? I
AutoDesk has a version without Lisp (AutoCAD LT). Still there
is a lot of Lisp traffic on the AutoCAD newsgroup. Still I see
a lot of AutoLisp articles in a german AutoCAD magazine.
Yes, it could make sense to drop AutoLisp completely. VB is
very strong in the market. People like you think Lisp
is useless and not all present in the software world.
> never heard about other Lisp-based CAD systems.
Just search on Altavista for CAD and Lisp and not AutoLisp.
> What market share do they have ?
Don't know. But some of them are large companies. Boeing's 777 turbines
have been designed by a Lisp based CAD application.
You may want to look in the application area of http://www.franz.com/ .
> What market share has Reduce or MuMath or Macsyma ?
Interestingly Reduce has been ported to a *lot* of platforms.
For Macsyma ask http://www.macsyma.com/. At one time they
got a good review in Byte magazine.
> As far as I can tell it's
> still Mathematica and Maple and MathCAD world.
Both are very strong. Still Mathematica for example has a lot
Lisp-like features.
> Abuse is a nice game, but about 2
> percent of my friends interested in computer games even heard of it, not
mention
> playing. It's still Doom, Terminal Velocity and Sierra On-Line quests
world. AI
The question up came whether there is any Lisp-based software being
used at all. So I mentioned couple of programs that are
marketed by companies and are successful in the commercial
market. Whether they have a great market share is not that
much interesting. The Interleaf publishing system may have
a very small market share, still in some segments it may own
the *whole* market.
It could be that the market for schedulers for satellite usage
is small. Still time on the Hubble Space telescope is being
scheduled by a Lisp program.
Some time ago Texas Instruments was look for Lisp developers. TI
develops their x86 with the help of Lisp-based ECAD software.
> software using Lisp ? Yes, I know the term... but I don't know any AI soft on
> the mass market. Can you tell me the name ?
What is the mass market? Who cares. There is still "AI" software being
used. American Express validates complex cases with Lisp machines.
Still running. Swissair develops large booking systems based on
mainframes. Still they market as part of it a Lisp system which looks for
double bookings. Go to Hamburg central railway station.
There is a touch sensitive screen where you can get
informations ideal routes in the complete public transport
system. Guess what, it is written in CL. It has been
written to assist phone based customer support.
Car painting facilities of Mercedes are being controlled by
a Lisp-based system. Ask Gensym, BBTech, Cycorp, ..
>
> So guys, Common Lisp is wonderful language. Scheme is wondeful language. Dylan
> is wonderful language. Haskell is even more wondeful. I can't wait for
the time
> when I can write the kind of applications I write for living in one of these
> wonderful languages. But right now I just can't. And nobody can do it
right now.
I could. I sure know companies who do. Just ask Altavista or
Dejanews for recent postings about Lisp related job offers.
You might also want to look at the Lisp FAQ. There
is an entry for a mailing list for Lisp related jobs.
You may want to look at the customer list of Digitool (http://www.digitool.com).
Looks not that bad to me (companies like AT&T, Motorola, Adobe, ...).
Ask Harlequin and Franz for references.
> Another point here - have you seen the work done at Microsoft research labs on
> Intentional Programming ? That thing is supposed to end language wars once and
> for all - and it's real I'd say... And I'm sure it will integrate with Windows
> as seamlessly as possible - it's Microsoft after all. Too bad they say
it'll be
> in "product" state in 2000 :-(
Interestingly enough they have been using some Lisp.
BOB for example was written in Lisp.
Listen, my point is not that Lisp is the most widely used programming
language. It is not even the best for a wide range of tasks.
My point is, you can develop interesting software with Lisp, people
have done it and still are doing it. There is no reason why this
should change, other than because of some people ignoring it.
Often the problem for companies is to find Lisp developers at all.
Greetings,
Rainer Joswig
Per Bothner
In article <MARKT.96S...@casper.harlqn.co.uk>,
Mark Tillotson <ma...@harlqn.co.uk> wrote:
>Note that the Java compiler is written totally in Java, and apart from
>redirection of its reads and writes to in-core class byte-vectors, all the
>machinery is there to do this. It seems a bit of a shame you are
>currently forced to use the file-system though.
Not at all. You can write the bytecodes to an in-core array,
and use a ClassLoader to load the compiled code. There is
no need to use the file-system.
This is what Kawa 0.3 does.
See ftp://ftp.cygnus.com/pub/bothner/kawa-0.3.tar.gz.
(Kawa is a Scheme compiler and runtime written in Java.)
--
--Per Bothner
Cygnus Support bot...@cygnus.com
ozan s. yigit
is it useful to compare languages on the basis of how tightly coupled they
are with the operating system? I don't think so.
if that is the basis of comparison, why not? also one erect an os to sustain
a language and vice versa, which is thought to be a good thing in some
circles...
Dieter Menszner
In C. Queinnec's book 'Les Langages Lisp' there is a reference
of an article [VH94]
Taming message passing: efficient method look-up for dynamically
typed languages.
Has anybody an idea how such 'taming' can be done in a lisp-like
language ?
Dieter
mathew
In article <841735...@wildcard.demon.co.uk>,
Cyber Surfer <cyber_...@wildcard.demon.co.uk> wrote:
>Unless the experimental version of XLISP is commercial, and
>is fully supported, many developers won't touch it. Just being
>experimental may be bad enough - some people won't trust beta
>(or "pre-release") versions of a product, never mind experimental.
That must be why Java's doing so badly then...
mathew
--
me...@pobox.com http://www.pobox.com/%7Emeta/
Help prevent bias on the net - http://www.pobox.com/%7Emeta/rs/ot/ for info
I killfile everything from or via earthlink.net, home of the spammer
Bruce O'Neel
Rainer Joswig (jos...@lavielle.com) wrote:
(snip)
: It could be that the market for schedulers for satellite usage
: is small. Still time on the Hubble Space telescope is being
: scheduled by a Lisp program.
Time on the X-Ray satellites ASCA (a Japanese/US one) and RXTE (or XTE) are
also scheduled by a vairiant of the HST scheduler. More info at
http://heasarc.gsfc.nasa.gov.
bruce
--
on...@arupa.gsfc.nasa.gov -- Bruce O'Neel HSTX (301) 286-1511 -- To
me, Mailing List Manager's for Mac-OS and DOS are like piano-playing
poodles -- I'm reluctant to evaluate them in terms of performance
because it's remarkable that they work at all. -- Norm Aleks