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)
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
William Paul Vrotney
In article <5030lt$e...@camelot.ccs.neu.edu> futr...@ccs.neu.edu (Robert Futrelle) writes:
>
> 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.
>
Yes, Common Lisp or an even more improved Lisp. But you see, it has to be
tried first in C++ and Java to prove that your statement is correct. We
should not lament since we've understood the necessary circumstance of this
proof all along, it's called "reductio ad absurdum".
QED in 2003!
In the mean time, unless a better idea comes along, our task as Lisp
supporters is to keep improving it quietly.
--
William P. Vrotney - vro...@netcom.com
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
mathew
>brings up. it is not new, it is indeed prevalent in certain circles.
>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.
Which is why I never suggested that the test was useful in isolation.
Passing the "hello, world" test is (in my view) a necessary, but not a
sufficient, condition for an application development environment to be
worth serious consideration as a *general* alternative to C/C++.
>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. C and C++ are relatively tightly coupled to their OSs,
and hence allow people to create small, fast executables which make
full use of OS features. (They also allow people to do bad things too,
but that's another discussion...)
If I can't use Lisp to create small, fast executables which make full
use of OS features, that *is* an issue, whatever the reason may be.
The "hello, world" test is just a quick first approximation test for
whether a development environment is likely to be able to produce
such programs.
The effort going in to speeding up startup times for scsh scripts
suggests that I'm not alone in feeling this is important.
Of course, for some applications it doesn't matter as much. If your
application is typically started once and left running for hours or
days (or even months), a half megabyte of 'fat' probably isn't
as important as the reliability of the code written; that's where
languages like Lisp and SmallTalk currently do well.
I don't see any inherent reason why a Lisp-like language shouldn't be
able to be used as a general replacement for C. But Common LISP
doesn't, in my view, fit the bill; I wouldn't try writing device
drivers or arcade games with it.
David Boles
In article <30502147...@arcana.naggum.no>,
Erik Naggum <er...@naggum.no> wrote:
>I have never understood the value of the "hello, world" that "mathew"
>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.
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")); }
Richard A. O'Keefe
Concerning 856-byte executables and the "hello world" test in general,
here are figures for five languages, all obtained on SPARC Solaris 2.5
systems, using SPARCompiler 4.0 compilers for code generation.
g% ls -l hello.*.out
-rwxrwxr-x 1 ok staff 143204 Aug 30 12:03 hello.c.out
-rwxrwxr-x 1 ok staff 247816 Aug 30 12:07 hello.cxx.out
-rwxrwxr-x 1 ok staff 302552 Aug 30 12:04 hello.f.out
-rwxrwxr-x 1 ok staff 192812 Aug 30 12:03 hello.p.out
-rwxrwxr-x 1 ok staff 173712 Aug 30 12:15 hello.sc.out
76744 [Note]
g% size hello.*.out
hello.c.out: 109762 + 6116 + 4272 = 120150 # C
hello.cxx.out: 175266 + 10244 + 23296 = 208806 # C++
hello.f.out: 229806 + 11992 + 54566 = 296364 # Fortran 77
hello.p.out: 140254 + 11704 + 7364 = 159322 # Pascal
hello.sc.out: 129074 + 11244 + 4276 = 144594 # Scheme (stalin)
21883 + 2249 + 2407 = 26539 # [Note]
The Scheme program was compiled with Stalin 0.6; the difference between
the Scheme size and the C size is due entirely to error messages and
error reporting functions that Stalin 0.6 includes automatically; the
0.7 version of Stalin doesn't generate any of this stuff unless it is
needed. [Note] I took the .c file that Stalin 0.6 generates and stripped
out by hand the things that Stalin 0.7 omits. The resulting difference
is due to Stalin using fputs and putc where my C code used printf().
C version: printf("Hello world.\n");
C++ version: cout << "Hello world.\n";
F77 version: print *, 'Hello world.'
Pascal version: writeln('Hello world.');
Scheme version: (begin (display "Hello world.") (newline))
These are *real* sizes obtained on a commercially provided UNIX system
using commercial compilers for code generation (I had Stalin call "cc").
[Yes, of *course* I used -Bstatic. That was the point!
On the other hand, Stalin *still* looks good with -Bdynamic.]
Somehow, I really don't expect to see a rush of C++ programmers switching
to Scheme because it gives them a smaller hello world executable than C++
does.
>Which is why I never suggested that the test was useful in isolation.
>Passing the "hello, world" test is (in my view) a necessary, but not a
>sufficient, condition for an application development environment to be
>worth serious consideration as a *general* alternative to C/C++.
I don't think it's a necessary condition.
I don't think it's even a remotely relevant condition.
A defensible condition is
"How big is a complete *non-trivial* application, ready to ship?"
Heck, if the executable size for hello world were a useful criterion,
a sh script like
echo Hello world.
(18 bytes) would be the winner every time.
>If I can't use Lisp to create small, fast executables which make full
>use of OS features, that *is* an issue, whatever the reason may be.
Hmm. The X window system is listed in the 1992 Unix System V Application
Binary Interface manual as MANDATORY: if a "UNIX" system has a window
interface at all it MUST have libX, and I understand that recent editions
of the ABI list libXt as a base component too. So "make full use of OS
features" implies "use everything in X" in SVr4, and on this system that
comes to almost 2.4 Mb of library code to be linked in, over and above
your "own" application code.
Whatever "fast" means, "small" has to mean "small in comparison with the
system libraries it uses", which on this system means "small compared with
2.4 Mb".
Thanks to shared libraries, that 2.4 Mb is not in your object file.
(More accurately, UNIX vendors scrambled to support shared libraries
when they saw how huge GUI programs were without.)
But it ain't free.
>I don't see any inherent reason why a Lisp-like language shouldn't be
>able to be used as a general replacement for C.
Sun's ESH interoperates *amazingly* smoothly with UNIX and C.
We should have more people banging on Sun's door demanding that they
turn ESH into a supported product.
--
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.
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.
ste...@centuryinter.net
In <505kl9$4...@goanna.cs.rmit.edu.au>, o...@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:
>Concerning 856-byte executables and the "hello world" test in general,
>here are figures for five languages, all obtained on SPARC Solaris 2.5
>systems, using SPARCompiler 4.0 compilers for code generation.
>
>g% ls -l hello.*.out
>-rwxrwxr-x 1 ok staff 143204 Aug 30 12:03 hello.c.out
>-rwxrwxr-x 1 ok staff 247816 Aug 30 12:07 hello.cxx.out
>-rwxrwxr-x 1 ok staff 302552 Aug 30 12:04 hello.f.out
>-rwxrwxr-x 1 ok staff 192812 Aug 30 12:03 hello.p.out
>-rwxrwxr-x 1 ok staff 173712 Aug 30 12:15 hello.sc.out
> 76744 [Note]
Holy huge, Batman! :-)
[snip]
>>If I can't use Lisp to create small, fast executables which make full
>>use of OS features, that *is* an issue, whatever the reason may be.
>
>Hmm. The X window system is listed in the 1992 Unix System V Application
>Binary Interface manual as MANDATORY: if a "UNIX" system has a window
>interface at all it MUST have libX, and I understand that recent editions
>of the ABI list libXt as a base component too. So "make full use of OS
>features" implies "use everything in X" in SVr4, and on this system that
>comes to almost 2.4 Mb of library code to be linked in, over and above
>your "own" application code.
Uhhh, no. You can do X programming by connecting to the X server
(via a socket connection) and communicating via a simple byte-stream.
Perhaps not for the feint of heart, but doable.
And "make full use of OS features" certainly does *not* mean to
"use everything in X". It means to use everything this is appropriate -
no more, no less.
And unless your library or linker is broken (possibly by design), you
only link in that which you use.
-Jeff
Rainer Joswig
> I don't see any inherent reason why a Lisp-like language shouldn't be
> able to be used as a general replacement for C. But Common LISP
> doesn't, in my view, fit the bill; I wouldn't try writing device
> drivers or arcade games with it.
This is difficult in every language. Replace "Common Lisp" with
"Pascal" (or whatever language you like)
and the sentence remains true. You need low-level access to
certain hardware and/or OS features to write device drivers.
What do you think the Lisp machines operating systems were
written in? Cobol? Clearly these Lisps had *everything*
(and more) to write an operating system, windowing systems,
network implementations. Why should it not be possible
to write TCP/IP implementations in Lisp? It has been done.
Done right this looks not half as ugly as C implementations
and is debuggable and patchable at run time.
Clearly you can do this stuff with certain variants of
Common Lisp. Sure you can write device driver stuff
with Symbolics Common Lisp (or ZetaLisp). Sure you can write
arcade games with Macintosh Common Lisp. Sure you can
do real-time programming in CL. Sure you can write 3D-animation
software in CL. ...
So, what does make you feel that CL doesn't "fit the bill"?
Greetings,
Rainer Joswig
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...
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
Georg Bauer
Hi!
RJ>annoying C weenies, ... and it does useful work.
Yes, I can second that ;-)
Although I tend to do most usefull work with a ML-derivate, but that's
mostly because of the availability (or not-availability) of command-line
compilers for Common Lisp that produce standalone executables on my
environment.
bye, Georg
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
Erik Naggum
[Georg Bauer]
| Although I tend to do most usefull work with a ML-derivate, but that's
| mostly because of the availability (or not-availability) of
| command-line compilers for Common Lisp that produce standalone
| executables on my environment.
appearance must really _be_ everything. the only standalone program this
here computer of mine sports is in the boot PROM. the rest is all one big
system with various parts being in memory or on disk at separate times.
just what one perceives as one's "environment" appears to be governed by
what one wishes to conclude. I'd like to see some understanding of the
_fact_ that one's "environment" may also be the boundaries of what one may
think about, just like our languages may limit what we can think about.
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
Georg Bauer
Hi!
RJ>Sure you can write device driver stuff
RJ>with Symbolics Common Lisp (or ZetaLisp).
Not to forget the Xerox Lisp-Machines, programmed in Interlisp. All
low-level structures and routines are written in Interlisp or are available
as primitives. Arcade games are no problem, there are some simple examples
in the 1186-archive. A game of life written in Interlisp running on a
simple 1186 runs very fast, even in 1024x768 mode. And since Common Lisp is
just build above the Interlisp, every feature is as easily available to
Common Lisp.
RJ>So, what does make you feel that CL doesn't "fit the bill"?
The main problem is still the system - you have to wrap the complete system
into a lisp layer or have to have a lisp-system emulation. The latter is
done in the Xerox Medley for DOS, where you have a complete system written
in Interlisp running on top of a 1186 emulator - and this emulation is fast
enough to be comparable in speed to a native running MS Windows.
bye, Georg
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:
>
>> 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
>
>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." [...]
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
Mike Haertel
In article <30506971...@arcana.naggum.no>,
Erik Naggum <er...@naggum.no> wrote:
>appearance must really _be_ everything. the only standalone program this
>here computer of mine sports is in the boot PROM. the rest is all one big
>system with various parts being in memory or on disk at separate times.
>just what one perceives as one's "environment" appears to be governed by
>what one wishes to conclude. I'd like to see some understanding of the
>_fact_ that one's "environment" may also be the boundaries of what one may
>think about, just like our languages may limit what we can think about.
Some of us like the additional protection afforded by running
different programs in different address spaces. While I'm sure
the historical Lisp machines were more robust than MS-DOS, they
were still a helluva lot easier for a beginner to hose than a
typical Unix. This, of course, is a standard argument that has
persisted since time immemorial, with zealots on both sides.
However, in a different vein...
What I dislike most about interactive Lisp environments is the
nonreproducibility of results after a session of any serious length.
Did that really work, or did it work just because of some definition
I accidentally made two hours ago?
I think what I'd really like would be some sort of checkpoint
and rollback feature. So, if some definition doesn't work, there
should be a way to undo it as if it had never happened, up to
and including restoring the previous definition if any.
Protected OS's where all programs get their own address space
give you a crude way to do this: launch a new program.
--
Mike Haertel <hae...@ichips.intel.com>
Not speaking for Intel.
David Boles
In article <ey3loet...@staffa.aiai.ed.ac.uk>,
Tim Bradshaw <t...@aiai.ed.ac.uk> wrote:
>* 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.
No, I'm not assuming that. I'm *very* aware of the difference between
application footprint and executable size. I apologize for not being
more clear on that point in my previous posting. However, the runtime
footprint *is* larger for Lisp executables. In addition, unless the
executable is very carefully linked, the increased disk image size
causes the "to-be-touched" data to be scattered across more pages.
It doesn't have to be that way. In a conversation with a guy doing a
sophisticated ML implementation, I learned that they are actually
quite concerned with the runtime footprint overhead and are developing
the ability to configure the size of the runtime (e.g., no gc vs.
simple gc vs. sophisticated generational gc) at the time of creation
of the executable. Why are they more responsive than the Lisp
community?
>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.
Hmmmm, let's see here. If we create stand-alone executables then we
can plug the resulting applications into a framework that includes
thousands of nifty programs/tools (representing an investment of many
tens if not hundreds of *billions* of dollars). Or we could ask people
to turn their backs on that investment in time-tested technology.
>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.
But it *IS* like that on UNIX, OS/2, MacOS, NT, DOS, VMS, ... . I'm
sorry, but that's what virtually everyone is working in and it's not
going to change anytime soon. Lisp can adapt to that reality, or not.
If it doesn't, it's early lead as a great development language will
continue to be eroded because of the enormous investment in other
development systems. Gee, didn't Gabriel write a paper on this very
subject. I guess the Lisp community didn't listen then, and what's
left of it still isn't listening.
Cheers,
David Boles
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?]
mathew
In article <joswig-3108...@news.lavielle.com>,
Rainer Joswig <jos...@lavielle.com> wrote:
>In article <503vh1$f...@snotra.harlequin.co.uk>, me...@pobox.com (mathew) wrote:
>> I don't see any inherent reason why a Lisp-like language shouldn't be
>> able to be used as a general replacement for C. But Common LISP
>> doesn't, in my view, fit the bill; I wouldn't try writing device
>> drivers or arcade games with it.
>
>This is difficult in every language. Replace "Common Lisp" with
>"Pascal" (or whatever language you like)
>and the sentence remains true.
I don't think so. Turbo Pascal was used to write countless PC
applications, in the days when 640K was the most RAM you could ever
expect to have and speed counted. I've used it to write utilities
which squeezed in under the 64K .COM size limit.
I've also written tiny Atari ST executables using a Modula-2 compiler,
and I've seen ST arcade games written entirely in Modula-2.
>What do you think the Lisp machines operating systems were
>written in? Cobol? Clearly these Lisps had *everything*
>(and more) to write an operating system, windowing systems,
>network implementations.
Unfortunately, the Lisp machine is dead. How far can you go on
today's hardware?
>Sure you can write arcade games with Macintosh Common Lisp.
Can you show me an example?
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
Rainer Joswig
In article <50gedc$i...@news.acns.nwu.edu>, for...@ils.nwu.edu (Kenneth D.
Forbus) wrote:
> 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.
We as a small interner provider have the problem of accounting the
IP traffic. Our customers pay for the bytes they transfer. There
was already a Perl program written by someone else. It did run
for **four****days** on our SPARCstation processing the data of
one month.
There was also a C program which ran much faster. At one point
users detected a small problem: it generated **negative** amounts of
transferred bytes for some customers. ;-) So we decided to develop our
own software in Common Lisp. It took an afternoon, my old Symbolics did
the parsing directly from a FTP stream in just under **three***hours**.
We now have developed a completely different and
much more complicated version with CL-HTTP and MCL
user interface, that does generate output
in a format suitable to feed it into our 4D database for further
processing and it does the computation incrementally.
Conclusion: if you do have the developers and your company gives the o.k.,
you can use Common Lisp quite sucessful for special purpose
inhouse programming. We are not planning to port this stuff to C. Why
should we?
Maybe next we will process our webserver
logs with CL (doing accounting, finding access patterns,
locate access problems, generating statistics, ...).
Greetings,
Rainer Joswig
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.
Georg Bauer
Hi!
CS>I've seen the FAQ. How many of these Lisps support OCX controls?
Franz has a quite good FFI, just build your own wrapper around the relevant
API, if it is not available. Actually ACL is a really great environment, if
you can live with the needed resources of ACL - it's a bit of a memory hog.
But compared with current Office applications, ACL is quite small.
And there are still some interesting alternatives to Lisp - especially if
you tolerate other functional languages, you can find some really practical
in the ML and Haskell family.
And if you want to look into the Scheme direction, take a look on Mr. Ed
and the related products (Mz. Scheme and such). Ok, it's only bytecode, but
it nicely integrates C++ classes and Mz. Scheme classes bidirectionally -
so you could integrate MFC with a Scheme (btw: Mz. Scheme builds on the
libscheme, so it's a quite good bytecode interpreter). The fun part: full
source is available, so you don't rely on much more than your normal
C-compiler.
CS>I'm told that VC++ performs better with 64 MB of RAM than with
CS>a mere 32 MB. ;-) I'd like to test this soon, by upgrading my
CS>machine to 64 MB.
That's the development environment, right. But you can still produce small
executables with VC++ :-)
bye, Georg