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: ·····@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
In article <··············@alfresco.usask.ca>, ·····@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".
From: ·······@spyglass.com (John Brewer)
Date: Fri, 23 Aug 1996 17:54:43 -0500
In article <··············@alfresco.usask.ca>, ·····@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]
In article <··················@plastix.cs.uoregon.edu>,
····@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
Anselm Lingnau <·······@tm.informatik.uni-frankfurt.de> wrote:
> In article <················@news.alt.net>,
> Phil Perucci <········@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'.
>
In fact you are wrong, it is perfectly possible to do this, and the
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
[ ·····@harlequin.co.uk | http://www.harlequin.co.uk/ | +44 1954 785433 ]
[ personal homepage ······························@harlequin.co.uk/ ]
[Is this another instance of confusion caused by myth that Java and C++
are languages with similar semantics I wonder?]
In article <··················@casper.harlqn.co.uk>,
Mark Tillotson <·····@harlqn.co.uk> wrote:
>Note that the Java compiler is written totally in Java, and apart from
>redirection of its reads and writes to in-core class byte-vectors, all the
>machinery is there to do this. It seems a bit of a shame you are
>currently forced to use the file-system though.
Not at all. You can write the bytecodes to an in-core array,
and use a ClassLoader to load the compiled code. There is
no need to use the file-system.
This is what Kawa 0.3 does.
See ftp://ftp.cygnus.com/pub/bothner/kawa-0.3.tar.gz.
(Kawa is a Scheme compiler and runtime written in Java.)
--
--Per Bothner
Cygnus Support ·······@cygnus.com
>>>>> "John" == John Brewer <·······@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.
On 24 Aug 1996 04:12:44 -0700, Philippe Troin <····@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...).
In article <················@news.alt.net>,
Phil Perucci <········@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'.
Anselm
--
Anselm Lingnau ......................... ·······@tm.informatik.uni-frankfurt.de
Life is ours to be spent, not to be saved. --- D. H. Lawrence
From: Eugene O'Neil
Subject: Re: Common LISP: The Next Generation
Date:
Message-ID: <DwwJ4B.It9@world.std.com>
In article <··········@rigel.tm.informatik.uni-frankfurt.de>, Anselm Lingnau <·······@tm.informatik.uni-frankfurt.de> wrote:
>In article <················@news.alt.net>,
>Phil Perucci <········@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'.
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
Anselm Lingnau <·······@tm.informatik.uni-frankfurt.de> writes:
[Java generating Java and then running it]
>is going to be well-nigh impossible for the same reasons why it
>is well-nigh impossible in C++, only more so because of the so-called
>`security features'.
A Java program can write text to a file.
This text may be source text.
A Java program can load new object code at run time
(combining this with the "security features" is what
the bytecode verifier is all about).
If this were not so, down-loaded applets would not be possible.
All that's needed is a way to call the compiler in between.
I had a notion this was possible...
--
Australian citizen since 14 August 1996. *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.
In article <················@news.alt.net>,
Phil Perucci <········@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 ·······@cygnus.com
Phil Perucci (········@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: ······@sphinx.biosci.wayne.edu ****
In article <··············@alfresco.usask.ca>, ·····@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. ;-)
> 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
In article <·······················@news.lavielle.com>
······@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
In article <·······················@news.lavielle.com>,
······@lavielle.com (Rainer Joswig) wrote:
>In article <··············@alfresco.usask.ca>, ·····@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
In article <························@news.halcyon.com>,
·······@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 - ·····@umich.edu
In article <······················@host-239.subnet-134.med.umich.edu>,
·····@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
Hi,
Is there documention for NewtonScript somewhere?
thanks.
bruce
Paul R. Potts (·····@cancer.med.umich.edu) wrote:
: In article <························@news.halcyon.com>,
: ·······@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:
--
·····@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
From: James Thiele
Subject: Re: Common LISP: The Next Generation
Date:
Message-ID: <DwywFp.7Cx@eskimo.com>
In article <··········@post.gsfc.nasa.gov> ·····@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
···@eskimo.com
Ashley Branchfeather (·······@halcyon.com) wrote:
: In article <·······················@news.lavielle.com>,
: ······@lavielle.com (Rainer Joswig) wrote:
: >In article <··············@alfresco.usask.ca>, ·····@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: ······@sphinx.biosci.wayne.edu ****
From: ······@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
-----BEGIN PGP SIGNED MESSAGE-----
·······@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-----
[ Massive cross-posting trimmed. ]
In article <··············@alfresco.usask.ca>,
P. Srinivas <·····@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
--
····@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
In article <··········@snotra.harlequin.co.uk> ····@pobox.com "mathew" writes:
> >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.
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
I have it at last: 'And She Closed Her Eyes', by Stina Nordenstam
In article <············@wildcard.demon.co.uk>,
Cyber Surfer <············@wildcard.demon.co.uk> wrote:
>In article <··········@snotra.harlequin.co.uk> ····@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.
mathew
--
····@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
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 <············@wildcard.demon.co.uk>,
Cyber Surfer <············@wildcard.demon.co.uk> wrote:
>In article <··········@snotra.harlequin.co.uk> ····@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.
mathew
--
····@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
In article <···········@snotra.harlequin.co.uk> ····@pobox.com "mathew" writes:
> 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...
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
I have it at last: 'And She Closed Her Eyes', by Stina Nordenstam
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.
········@ccs.neu.edu | Boston, MA 02115
From: William Paul Vrotney
Subject: Re: Common LISP: The Next Generation
Date:
Message-ID: <vrotneyDww5I9.A5v@netcom.com>
In article <··········@camelot.ccs.neu.edu> ········@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 - ·······@netcom.com
In article <··········@snotra.harlequin.co.uk>, ····@pobox.com (mathew) wrote:
>Re: Common LISP: The Next Generation
>From ····@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
From: Ulrich Schreiner
Subject: Re: Common LISP: The Next Generation
Date:
Message-ID: <3222ECF7.4F32@khe.scn.de>
mathew wrote:
> ...
> 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
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 (········@khe.scn.de)
In article <·············@khe.scn.de>
········@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...
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
******* Boycott 'The Observer' - see uk.media for details *******
In article <·············@khe.scn.de>, Ulrich Schreiner
<········@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
In article <·······················@news.lavielle.com>
······@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:
> 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: ··············@news.ornl.gov (Lars Wirzenius)
> Message-ID: <··························@liw.clinet.fi>
>
> -----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: ··@snoopy.mv.com (Paul F. Werkowski)
> Maintained-by: ······@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 ······@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? ···@ G+>++ e++>++++ h!>+ ··@ 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 ········@kruuna.helsinki.fi for PGP key needed for validating signature.
> Send submissions for comp.os.linux.announce to: ··············@news.ornl.gov
> PLEASE remember a short description of the software and the LOCATION.
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
******* Boycott 'The Observer' - see uk.media for details *******
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
In article <················@arcana.naggum.no>
····@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.
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
******* Boycott 'The Observer' - see uk.media for details *******
In article <················@arcana.naggum.no>,
Erik Naggum <····@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 <·······@ichips.intel.com>
Not speaking for Intel.
From: William Paul Vrotney
Subject: Re: Common LISP: The Next Generation
Date:
Message-ID: <vrotneyDww5su.AJG@netcom.com>
In article <··········@news.jf.intel.com> ·······@ichips.intel.com (Mike Haertel) writes:
>
> I think the real reason most Lisp implementations produce huge
> executables is not that it's not possible, but that Lisp implementors
> have, for whatever reason, chosen not to work on that particular
> problem.
Actually they have, it's just that they were stopped in mid stream by the
C++ wave.
--
William P. Vrotney - ·······@netcom.com
In article <················@arcana.naggum.no>,
Erik Naggum <····@naggum.no> wrote:
>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.
[...]
>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.
mathew
--
····@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
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.
In <··········@goanna.cs.rmit.edu.au>, ··@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
In article <··········@snotra.harlequin.co.uk>, ····@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. 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
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
In article <·······················@news.lavielle.com>,
Rainer Joswig <······@lavielle.com> wrote:
>In article <··········@snotra.harlequin.co.uk>, ····@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
--
····@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
In article <··········@snotra.harlequin.co.uk>, ····@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.
So you think there is a general rule that writing device
drivers for computers (in general) is inherently more
difficult in CL than, say, in Turbo Pascal.
How does it come that the Lisp machines had external devices
at all (Disks, ethernet cards, graphics cards, video boards,
sound, modems, ...)?
> Unfortunately, the Lisp machine is dead. How far can you go on
> today's hardware?
That's an interesting question. I'd would like to present
an answer. Unfortunately, people are busy writing device
drivers for the thousands PC graphics cards.
> >Sure you can write arcade games with Macintosh Common Lisp.
>
> Can you show me an example?
Look at the contrib directory of Digitool. There are quite
some libraries supporting fast animations, gworlds,
bit level graphics operations, ... Why did people write this
stuff? Maybe not for developing arcade games, but
some of these libraries would be a good start for
low level stuff.
Greetings,
Rainer Joswig
In article <················@arcana.naggum.no>,
Erik Naggum <····@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
[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")); }
In article <················@arcana.naggum.no>
····@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...
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
******* Boycott 'The Observer' - see uk.media for details *******
In article <············@wildcard.demon.co.uk> ············@wildcard.demon.co.uk writes:
>In article <················@arcana.naggum.no>
> ····@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 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
In article <····················@cogsci.ed.ac.uk>
····@cogsci.ed.ac.uk "Jeff Dalton" writes:
> I happen to greatly prefer having an operating system with
> proper memory protection, etc, to the systems (e.g. on Lisp
> machines) that more or less got rid of the distinction.
> Moreover, I want exiting Lisp and starting a new Lisp to
> be a relatively lightweight operation compared to rebooting
> the machine. I guess I'm just funny that way. ^_^
I'm used to that way of working, because that'll all that's been
available to me. Most of the machines I've used didn't an OS that
used memory protection, but neither were they Lisp Machines.
They ran things like CP/M-68K, GEM, or DOS. All "real mode" OSs.
> In any case, while the dice may well _be_ loaded, Lisp systems
> could preduce much smaller executables than they usually do.
This why I'm keen to see what Dylan systems like Gwydion will be
like. Perhaps in something like 3 years time, I'll have a chance
to find out. It's hard to predict what'll happen 3 years from now.
> Indeed, a Lisp could fairly easily produce a "Hello, world!"
> program that's as small as a C one. Suppose the source code
> was:
>
> (format t "Hello, World!~%")
>
> It doesn't need to alloc anything at run-time, so no GC is needed.
It doesn't need to statically link, either. However, all the
compiled Lisps I've used have delivered code in a statically
linked image file. Some other languages have also done this.
(As far as I know, Actor is no longer.)
> Format strings can be compiled. (If I recall correctly, the XP
> pretty printer has conde that does that.) And writng the string
> can be handled directly by an OS write operation. You might
> think that a Lisp would have to arrange for the string to be
> aproper Lisp object, but that's not necessary. Writing a
> constant string could be optimized by the compiler.
Agreed. It should be pretty simple for a compiler to determine
that the literal string will only be used by that one function
call.
> Ah, soemone will say, what if you write slightly larger
> programs. Then you'll have the GC and all that other Lisp
> stuff. Probably you will. But such things can be pretty
> small. Most Lisp implementatinos are pretty big these
> days, but they can be very small. (N.B. Lisp does not =
> Common Lisp; but even Common Lisps could produce vastly
> smaller executables than they typically do.)
Yes, just avoid static linking. I don't know about Unix, but
a programming language for Win16/Win32 that uses static linking
only will be seen as a very poor tool. Never mind issues like
GC performance. Even a _C compiler_ for Win16/Win32 has to
support dynamic linking in order to be accepted as a serious
development tool. This isn't a language issue - it's a delivery
issue. Maybe this is different for Unix, but for Windows, a
"larger than necessary" binary is considered to be unforgivable.
It's subjective, of course, but both users and developers are
very sensitive to the code size, and yes, all those enourmous
Windows apps _are_ heavily criticised for being _too big_. If
it wasn't for all those features, nobody would put up with it.
In fact, some people _don't_. That's part of the problem...
> Now, standard Lispy run-time stuff (such as the GC) that almost
> all programs will want can be shared. Maybe they're in a shared
> library. That's not all that different from having them in the OS.
> (Think e.g. of micro-kernels with various things running as
> separate processes. That something isn't in the kernel per
> se shouldn't matter very much.) Even without shared libraries,
> a good virtual memory implementation will let much be shared
> (and will avoid touching pages that are not needed).
Exactly. This is why Windows developers using MFC can use the
MFC DLL, so that the code will be shared with any other apps
using that DLL. For Win32, that's a _big_ DLL. A lot of other
code that could be statically linked is also available in DLLs.
This isn't just a neat idea bolted onto the OS. The entire API
that an app will use is available as a set of DLLs.
So, put the language support code into DLLs, and you're a step
closer to a Lisp Machine. ;)
> So, yes, Lisp vs C size comparisons are almost all bogus,
> but it's also true that many Lisps could do better.
Most certainly. I've been saying that on UseNet for the last
couple of years. It's easy to get the impression that most Lisp
people here have lost touch with the "real world", and then
winge about how that world has ignored them.
Well, see the Hawkwind quote in my sigfile.
--
<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
We're living on a knife edge, looking for the ground -- Hawkwind
In article <············@wildcard.demon.co.uk> ············@wildcard.demon.co.uk writes:
>In article <····················@cogsci.ed.ac.uk>
> ····@cogsci.ed.ac.uk "Jeff Dalton" writes:
>> 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.
>
>It doesn't need to statically link, either. However, all the
>compiled Lisps I've used have delivered code in a statically
>linked image file.
How about WCL? It packages Cl itself as a shared library and
presumably allows you to construct shared libraries too.
Anyway, statically linked executables can be small.
>> Ah, soemone will say, what if you write slightly larger
>> programs. Then you'll have the GC and all that other Lisp
>> stuff. Probably you will. But such things can be pretty
>> small. Most Lisp implementatinos are pretty big these
>> days, but they can be very small. (N.B. Lisp does not =
>> Common Lisp; but even Common Lisps could produce vastly
>> smaller executables than they typically do.)
>
>Yes, just avoid static linking.
I'm not quite sure just what you have in mind here, but for most
Lisps it's not a simple change. These Lisps don't use the ordinary
linker/loader. Instead, code is loaded into a running Lisp and
then an image of the thus modified Lisp is saved. If, instead,
the compiler could turn Lisp source files into .o files that could
be statically linked with code from various libraries, you could
get much smaller executables despite using static linking.
"Tree shaking" and the like can also help, but work by discarding
rather than by never including in the 1st place.
I don't know about Unix, but
>a programming language for Win16/Win32 that uses static linking
>only will be seen as a very poor tool. Never mind issues like
>GC performance. Even a _C compiler_ for Win16/Win32 has to
>support dynamic linking in order to be accepted as a serious
>development tool. This isn't a language issue - it's a delivery
>issue. Maybe this is different for Unix, but for Windows, a
>"larger than necessary" binary is considered to be unforgivable.
Humm. Some of them sure _look_ larger than necessary.
>It's subjective, of course, but both users and developers are
>very sensitive to the code size, and yes, all those enourmous
>Windows apps _are_ heavily criticised for being _too big_. If
>it wasn't for all those features, nobody would put up with it.
>In fact, some people _don't_. That's part of the problem...
ok.
-- jd
In article <················@arcana.naggum.no>,
Erik Naggum <····@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.
>
>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.
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
In article <··········@zeppelin.convex.com>
······@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
Erik Naggum <····@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.
···········@best.com
http://www.best.com/~page/
...........................................................................
In article <················@arcana.naggum.no>, Erik Naggum
<····@naggum.no> wrote:
> 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
From: ozan s. yigit
Subject: Re: Unclear thought is the problem, not the solution
Date:
Message-ID: <OZ.96Sep16114148@nexus.yorku.ca>
Erik Naggum:
...
and what's their solution? create another cute little immature thing that
shows every sign of being just as bad at scalability and adaptability once
it gets out of the maternity ward.
...
i suspect you are referring to plan9, but this is the wrong forum to
dump on that topic. if you have something interesting to say, please
post it to comp.os.plan9 so that those of us who actually know
something about that system can respond appropriately.
thanks... oz
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
In article <········································@granby>
·······@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.
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
******* Boycott 'The Observer' - see uk.media for details *******
--Cyberdog-AltBoundary-00049DF0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hi,
just browsing around in the Web, I found a quite interesting pointer
to
a forthcoming publication on Dylan.
That could be interesting to the .lisp and .scheme communities too --
dare a look !-)
here the URL
http://www.harlequin.com/books/dylan-book/index.html
of course the "mother of all Dylan books" is the Dylan Reference
Manual
http://www.harlequin.com/books/DRM/
thanks to Harlequin for providing this valuable source.
Gabor
--Cyberdog-AltBoundary-00049DF0
Content-Type: multipart/mixed; boundary="Cyberdog-MixedBoundary-00049DF0"
Content-Transfer-Encoding: 7bit
--Cyberdog-MixedBoundary-00049DF0
Content-Type: text/enriched; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<X-FONTSIZE><PARAM>12</PARAM><FONTFAMILY><PARAM>Palatino</PARAM>Hi,
just browsing around in the Web, I found a quite interesting pointer
to
a forthcoming publication on Dylan.
That could be interesting to the .lisp and .scheme communities too --
dare a look !-)
here the URL
http://www.harlequin.com/books/dylan-book/index.html
of course the "mother of all Dylan books" is the Dylan Reference
Manual
http://www.harlequin.com/books/DRM/
thanks to Harlequin for providing this valuable source.
Gabor</FONTFAMILY></X-FONTSIZE>
--Cyberdog-MixedBoundary-00049DF0--
--Cyberdog-AltBoundary-00049DF0--
In article <········································@granby> WJ Bland <·······@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
is it useful to compare languages on the basis of how tightly coupled they
are with the operating system? I don't think so.
if that is the basis of comparison, why not? also one erect an os to sustain
a language and vice versa, which is thought to be a good thing in some
circles...
mathew (····@pobox.com) wrote:
: [ Massive cross-posting trimmed. ]
: In article <··············@alfresco.usask.ca>,
: P. Srinivas <·····@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.
I'm not dead yet!
But seriously, TrueBASIC, while nice, is obscure and overshadowed by Visual
Basic.
bruce
--
·····@arupa.gsfc.nasa.gov -- Bruce O'Neel HSTX (301) 286-1511 -- Graphical
icons were intended to make software friendly, and easy to use. Now Microsoft
applications have Tool Tips - Text labels that appear when you move the mouse
pointer over icons. We used to call these "menus." -- D Kalman DBMS 9/94
Cyber Surfer <············@wildcard.demon.co.uk> writes:
> In article <··········@snotra.harlequin.co.uk> ····@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 <·····@pvv.unit.no>
avsnitt www.pvv ~eddie
.. avsindig avsindig og alltid bare i begynnelsen av tiden
From: Per Bothner
Subject: Re: Scheme->JVM (Re: Common LISP: The Next Generation)
Date:
Message-ID: <4vsm3b$odn@andros.cygnus.com>
In article <··················@voldsboks.pvv.ntnu.no>,
Kjetil Valstadsve <·····@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 ·······@cygnus.com
>>>>> "Olin" == Olin Shivers <·······@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!
In article <···············@hertie.artcom.de>,
Andreas Bogk <·······@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
······@bbnplanet.com - Phone (617) 873-3126 - Fax (617) 873-6351
(BBN customers, please call (800) 632-7638 option 1 for support)
>n article <···············@hertie.artcom.de>,
>Andreas Bogk <·······@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
Andreas Bogk <·······@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
>>>>> "Rainer" == Rainer Joswig <······@lavielle.com> writes:
> In article <··········@snotra.harlequin.co.uk>, ····@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
http://www.cs.cmu.edu/~spot
····@cs.cmu.edu
In article <···············@goober.graphics.cs.cmu.edu>,
····@goober.graphics.cs.cmu.edu (Scott Draves) wrote:
>From ····@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/
In article <·······················@news.lavielle.com>
······@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 *******
In article <············@wildcard.demon.co.uk>,
············@wildcard.demon.co.uk wrote:
> In article <·······················@news.lavielle.com>
> ······@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.
In article <·······················@news.lavielle.com>
······@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++!
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
******* Boycott 'The Observer' - see uk.media for details *******
In article <············@wildcard.demon.co.uk>,
············@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
In article <·······················@news.lavielle.com>
······@lavielle.com "Rainer Joswig" writes:
> In article <············@wildcard.demon.co.uk>,
> ············@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.
--
<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 <············@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?)
--
Australian citizen since 14 August 1996. *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.
[Richard A. O'Keefe]
| (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
In article <··········@goanna.cs.rmit.edu.au>
··@goanna.cs.rmit.edu.au "Richard A. O'Keefe" writes:
> Cyber Surfer <············@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
We're living on a knife edge, looking for the ground -- Hawkwind
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 <············@wildcard.demon.co.uk>,
············@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.
In article <············@wildcard.demon.co.uk>,
Cyber Surfer <············@wildcard.demon.co.uk> wrote:
>Unless the experimental version of XLISP is commercial, and
>is fully supported, many developers won't touch it. Just being
>experimental may be bad enough - some people won't trust beta
>(or "pre-release") versions of a product, never mind experimental.
That must be why Java's doing so badly then...
mathew
--
····@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
In article <··········@snotra.harlequin.co.uk> ····@pobox.com "mathew" writes:
> That must be why Java's doing so badly then...
Software for the Web seems to be one of those special cases. ;-)
Yes, I've noticed how popular Netscape is with the same people
who might refuse to use another other beta. Ho hum.
The interesting question that springs to mind is: who is buying
this (Java) software? Perhaps some of it is being written simply
because it can be done. This has always seemed like a good enough
reason to me, having observed the number of times that people do
bizzare (and simetimes plain _dumb_) things with computers.
It's obviously a subjective thing. No single solution makes sense
to everybody.
--
<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
We're living on a knife edge, looking for the ground -- Hawkwind
In article <············@wildcard.demon.co.uk>,
············@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
>> 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?
[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
In article <················@news-win.rinet.ru>, ·····@inist.ru (Oleg
Moroz) wrote:
> Have you heard that AutoDesk is switching for Visual Basic for
Applications ? I
AutoDesk has a version without Lisp (AutoCAD LT). Still there
is a lot of Lisp traffic on the AutoCAD newsgroup. Still I see
a lot of AutoLisp articles in a german AutoCAD magazine.
Yes, it could make sense to drop AutoLisp completely. VB is
very strong in the market. People like you think Lisp
is useless and not all present in the software world.
> never heard about other Lisp-based CAD systems.
Just search on Altavista for CAD and Lisp and not AutoLisp.
> What market share do they have ?
Don't know. But some of them are large companies. Boeing's 777 turbines
have been designed by a Lisp based CAD application.
You may want to look in the application area of http://www.franz.com/ .
> What market share has Reduce or MuMath or Macsyma ?
Interestingly Reduce has been ported to a *lot* of platforms.
For Macsyma ask http://www.macsyma.com/. At one time they
got a good review in Byte magazine.
> As far as I can tell it's
> still Mathematica and Maple and MathCAD world.
Both are very strong. Still Mathematica for example has a lot
Lisp-like features.
> Abuse is a nice game, but about 2
> percent of my friends interested in computer games even heard of it, not
mention
> playing. It's still Doom, Terminal Velocity and Sierra On-Line quests
world. AI
The question up came whether there is any Lisp-based software being
used at all. So I mentioned couple of programs that are
marketed by companies and are successful in the commercial
market. Whether they have a great market share is not that
much interesting. The Interleaf publishing system may have
a very small market share, still in some segments it may own
the *whole* market.
It could be that the market for schedulers for satellite usage
is small. Still time on the Hubble Space telescope is being
scheduled by a Lisp program.
Some time ago Texas Instruments was look for Lisp developers. TI
develops their x86 with the help of Lisp-based ECAD software.
> software using Lisp ? Yes, I know the term... but I don't know any AI soft on
> the mass market. Can you tell me the name ?
What is the mass market? Who cares. There is still "AI" software being
used. American Express validates complex cases with Lisp machines.
Still running. Swissair develops large booking systems based on
mainframes. Still they market as part of it a Lisp system which looks for
double bookings. Go to Hamburg central railway station.
There is a touch sensitive screen where you can get
informations ideal routes in the complete public transport
system. Guess what, it is written in CL. It has been
written to assist phone based customer support.
Car painting facilities of Mercedes are being controlled by
a Lisp-based system. Ask Gensym, BBTech, Cycorp, ..
>
> So guys, Common Lisp is wonderful language. Scheme is wondeful language. Dylan
> is wonderful language. Haskell is even more wondeful. I can't wait for
the time
> when I can write the kind of applications I write for living in one of these
> wonderful languages. But right now I just can't. And nobody can do it
right now.
I could. I sure know companies who do. Just ask Altavista or
Dejanews for recent postings about Lisp related job offers.
You might also want to look at the Lisp FAQ. There
is an entry for a mailing list for Lisp related jobs.
You may want to look at the customer list of Digitool (http://www.digitool.com).
Looks not that bad to me (companies like AT&T, Motorola, Adobe, ...).
Ask Harlequin and Franz for references.
> Another point here - have you seen the work done at Microsoft research labs on
> Intentional Programming ? That thing is supposed to end language wars once and
> for all - and it's real I'd say... And I'm sure it will integrate with Windows
> as seamlessly as possible - it's Microsoft after all. Too bad they say
it'll be
> in "product" state in 2000 :-(
Interestingly enough they have been using some Lisp.
BOB for example was written in Lisp.
Listen, my point is not that Lisp is the most widely used programming
language. It is not even the best for a wide range of tasks.
My point is, you can develop interesting software with Lisp, people
have done it and still are doing it. There is no reason why this
should change, other than because of some people ignoring it.
Often the problem for companies is to find Lisp developers at all.
Greetings,
Rainer Joswig
Rainer Joswig (······@lavielle.com) wrote:
(snip)
: It could be that the market for schedulers for satellite usage
: is small. Still time on the Hubble Space telescope is being
: scheduled by a Lisp program.
Time on the X-Ray satellites ASCA (a Japanese/US one) and RXTE (or XTE) are
also scheduled by a vairiant of the HST scheduler. More info at
http://heasarc.gsfc.nasa.gov.
bruce
--
·····@arupa.gsfc.nasa.gov -- Bruce O'Neel HSTX (301) 286-1511 -- To
me, Mailing List Manager's for Mac-OS and DOS are like piano-playing
poodles -- I'm reluctant to evaluate them in terms of performance
because it's remarkable that they work at all. -- Norm Aleks
>> So guys, Common Lisp is wonderful language. Scheme is wondeful language. Dylan
>> is wonderful language. Haskell is even more wondeful. I can't wait for
>the time
>> when I can write the kind of applications I write for living in one of these
>> wonderful languages. But right now I just can't. And nobody can do it
>right now.
>
>I could. I sure know companies who do. Just ask Altavista or
>Dejanews for recent postings about Lisp related job offers.
>You might also want to look at the Lisp FAQ. There
>is an entry for a mailing list for Lisp related jobs.
>
>You may want to look at the customer list of Digitool (http://www.digitool.com).
>Looks not that bad to me (companies like AT&T, Motorola, Adobe, ...).
>Ask Harlequin and Franz for references.
Well, I'm really happy with my current job. I'm mostly happy with the tools I
use right now, but I feel that using such languages as Lisp, Dylan, SML and
Haskell could make my work _much_ more productive given the right
implementation/development environment. I don't want to look for another
employment opportunity just for the target OS or language change - I just play
with all these wonderful things at home and the fact that I cannot use it at
work just increases my frustration.
>> Another point here - have you seen the work done at Microsoft research labs on
>> Intentional Programming ? That thing is supposed to end language wars once and
>> for all - and it's real I'd say... And I'm sure it will integrate with Windows
>> as seamlessly as possible - it's Microsoft after all. Too bad they say
>it'll be
>> in "product" state in 2000 :-(
>
>Interestingly enough they have been using some Lisp.
>
>BOB for example was written in Lisp.
Bob ? In Lisp ? What kind of Lisp ? From the brief look at the Bob binaries on
the CD I'd swear it was written in "Modular" Visual Basic (the unreleased kind
of VB targeted for hand-help computers) plus some multimedia extensions in DLLs.
If it's really written in Lisp then I understand why it runs so slow :-)
Oleg
In article <················@news-win.rinet.ru>, ·····@inist.ru (Oleg
Moroz) wrote:
> >BOB for example was written in Lisp.
>
> Bob ? In Lisp ? What kind of Lisp ?
Ask Franz.
In article <·······················@news.lavielle.com>
······@lavielle.com "Rainer Joswig" writes:
> Interestingly Reduce has been ported to a *lot* of platforms.
> For Macsyma ask http://www.macsyma.com/. At one time they
> got a good review in Byte magazine.
When did Byte last review a Lisp? It used to be once every two
years, but the audience of the mag shifted away from developers,
and the Lisp reviews appeared to stop.
> The question up came whether there is any Lisp-based software being
> used at all. So I mentioned couple of programs that are
> marketed by companies and are successful in the commercial
> market. Whether they have a great market share is not that
> much interesting. The Interleaf publishing system may have
> a very small market share, still in some segments it may own
> the *whole* market.
A much more interesting question is "who knows that these products
exist, and that they were developed using Lisp?" Most people think
that Lisp is a joke. We may know different, but we're unusual, coz
we actually _use_ Lisp.
> Listen, my point is not that Lisp is the most widely used programming
> language. It is not even the best for a wide range of tasks.
>
> My point is, you can develop interesting software with Lisp, people
> have done it and still are doing it. There is no reason why this
> should change, other than because of some people ignoring it.
You sound like somebody lucky enough to use Lisp. Most of us
aren't that lucky, as the Lisps available to use either can't
support the features we need, or the people we work for don't
recognise the value of Lisp.
Yes, you _can_ develop interesting software with Lisp, if you
use the right platform, if your employer feels positive enough
about Lisp, and if the Lisps available to you support the features
needed for the software you're developing. Some_ people will be
fortunate enough to do this, because the above conditions will
be satisfied.
However, most developers are forced to use other languages, like
C++, because that's what they're paid to do, and they're paid to
use C++ because that's what we're told by MS is needed in order
to write apps for Windows. It's very hard to argue with MS. You
can try it if you like, but you'd need a _massive_ PR machine.
> Often the problem for companies is to find Lisp developers at all.
I'm still trying to get the practical experience needed to call
myself a professional Lisp programmer. I don't think that just
messing about in my own time will be worth much, but I'd be happy
if somebody out there would be willing to employ me as a Lisp
programmer, working from home (in London, UK). It's hard enough
doing this as a C++ programmer, never mind as a Lisp programmer.
This could be another reason why there are so many C++ programmers.
Look at it this way. Pascal doesn't have much of a chance against
C++, so why expect Lisp to do any better? Lisp is a lot more esoteric
than Pascal!
--
<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
We're living on a knife edge, looking for the ground -- Hawkwind
Hi!
OM>playing. It's still Doom, Terminal Velocity and Sierra On-Line quests
Sierra uses a special OO-language for their adventre-programes. Like the
Larry games for example. Back in history you were even able to jump into
the integrated debugger (was it ctrl-alt-D?) and browse through the stack
frames. Many adventure systems are written in a specialized high-level
language that often adopts ideas from Smalltalk and Lisp - just because you
can work better with the complex structures ...
(there was even once a Adventure construction kit from David Betz, that was
in fact a complete Lisp-dialect)
bye, Georg
···········@ms3.maus.westfalen.de (Georg Bauer) writes:
>(there was even once a Adventure construction kit from David Betz, that was
>in fact a complete Lisp-dialect)
It's available at the Retrocomputing Museum:
http://locke.ccil.org/retro/
Derek
--
Derek Bell ·····@maths.tcd.ie WWW: http://www.maths.tcd.ie/~dbell/index.html
"Donuts - is there _anything_ they can't do?" - Homer Simpson
On Fri, 6 Sep 96 08:54:00 +0200, ···········@ms3.maus.westfalen.de (Georg Bauer)
wrote:
>OM>playing. It's still Doom, Terminal Velocity and Sierra On-Line quests
>
>Sierra uses a special OO-language for their adventre-programes. Like the
>Larry games for example. Back in history you were even able to jump into
>the integrated debugger (was it ctrl-alt-D?) and browse through the stack
>frames. Many adventure systems are written in a specialized high-level
>language that often adopts ideas from Smalltalk and Lisp - just because you
>can work better with the complex structures ...
Oops ! I should have remembered my early experience with Sierra games before...
I have written a decompiler for their data files about 1988 and I still remember
they seemed to use some kind of OO language for their quests. From the inside
looks of their VM it was prototype-based.
Oleg
In article <·······················@news.lavielle.com>
······@lavielle.com "Rainer Joswig" writes:
> In article <············@wildcard.demon.co.uk>,
> ············@wildcard.demon.co.uk wrote:
>
> > Of course, if CL-HTTP isn't commercial, then this might not be
> > possible anyway. Some people prefer to have support they can
> > rely on (by paying for it) before they'll trust a product.
> > I'm used to working without any real support, but it might be
> > difficult in this case, as I'm not the one chosing the web
> > server software.
>
> I'm using GNU Emacs, it isn't a commercial product either.
I'm using loads of non-commercial software, and my favourite app
has been obselete for several years, and is no longer supported.
The attitude of the people who write is "upgrade to our new version".
The "new version" is a very different app - as it includes loads
of stuff I _don't need and don't want_, and doesn't have the stuff
that I _do want_.
This happens all the time. What counts is that non-suppported
software will be harder to use in certain enviroments. For personal
use, on a personal machine, there's no problem. Development of
software can be one of those demanding situations, because the
client may demand things that you, the developer, don't normally
worry about. Sometimes the client's demands dictate that you only
work with supported software. That's some people's definition of
"mission critical".
In other words, Emacs may be a fine editor, but some people will
still insist that you a commercial alternative. Nothing you or I
may think or say will change that.
> > Also, I'm the only Lisp programmer at the company I work for,
> > so it might not be wise to depend too heavily on a single
> > person for maintaining the company web server - assuming that
> > I _can_ actually do that.
>
> With CL-HTTP you can build interfaces for web sites, so that
> they are maintainable by a nonprogrammer.
Is this a standard feature of CL-HTTP, or would a programmer
be needed to build such an interface? Could the server the
maintained _without_ a CL programmer? The concern that I know
will stop my employer, for example, from using CL-HTTP will
be that only one person in the company will be able to use
CL, and since we have a policy of never putting a mission
critical part of a business in the hands of just one person,
CL-HTTP would make us more vulnerable than if we chose a
commercial web server (like the many web servers available
for NT).
I don't think we can just ignore the fact that the supply of
CL programmers is not abundant, so most companies wishing to
run a web server won't have the CL expertise required (in the
example given above, a minimum of two people). I can't even
call myself a CL expert, while I have no trouble installing
and maintaining a typical web server for NT. So, even I have
doubts, and I'm pro CL!
> > I'm not a Lisp expert, so it's
> > possible that CL-HTTP is beyond my understanding.
>
> Could be.
That's my fear. If I'm not sure, then I know what most others
will think. If I suggest that CL-HTTP should be used instead
of a well-established commercial web server, I know what their
response will be, and it'll use some four letter words. This
may be the kind of hostility that the Lisp community should be
well used to by now, judging by the number of examples we've
seen of it in these newsgroups and elsewhere.
If a company already uses and trusts Lisp, then using it for
their web server may be a natural approach. However, anywhere
else people may look at it as madness. I'm not saying they're
right, but if the Lisp experience isn't sufficient to support
using CL-HTTP on a mission critical server, then perhaps it
_would be_ madness. That's not to say that the software is no
good, or that Lisp has any problems. It's simply a necessary
part of the way the computer industry works. People use the
technology they know and trust, and most people don't know
Lisp, and what they don't know, they won't trust.
> > Where is it being used? I guess it must has a very low profile,
> > coz I only ever read about it on UseNet, in newsgroups like
> > comp.lang.lisp.
>
> Ever heard of AutoCad? Reduce? MuMath? Never heard of Macsyma?
> HotMeTaL? Interleaf? Abuse? A lot of CAD systems are using Lisp.
> Math software is using Lisp. Music software is using Lisp. Electrical
> CAD software uses Lisp. Diverse AI software uses Lisp. How
> does it come there are so many Lisp implementations for the PC?
HotMetal uses Lisp? Good grief. My colleagues use this app,
and yet remain ignorant of Lisp. Same with AutoCad. They've
no use for MuMath, so that'll not convince them. Same with
Reduce. You're using some pretty exotic examples, which is
what I expected. _This_ is why so many people have not heard
of Lisp, and many of those who have will base their opinions
of it on some very outdated versions. See the intro to Winston
and Horn, where they debunk these common myths. Sadly, most
people don't read that book and will never have even heard of
it, nor will they understand why they should.
Remember that most people won't know or care what technology
their apps are based on. Most users will be more familiar with
a spreadsheet macro language than Lisp.
I'm not attacking Lisp, but the Lisp people who think that
this is not their problem. Well, IMHO it is. Lisp is ignored
by most people because the kind of Lisp available to them is
completely irrelevant. Perhaps Dylan will change this, but
I dunno. I only hope so. It certainly appears to me that the
designers of Dylan undertood this problem.
It often seems to me that the designers of Java understood it
even better. Java is not Lisp, and that may well be why it's
so popular. I still prefer Lisp, but I can understand why so
many others don't. It often seems to me that Lisp people don't
appreciate this enough.
> Which links do have problems?
There may have been some others, but I'm pretty sure about the
Scheme page. There were a number of failed links there. I got
at least one 404 error, so I don't think this is just a routing
problem at my "end".
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
From: Dorai Sitaram
Subject: Re: Common LISP: The Next Generation
Date:
Message-ID: <50ku00$cf@news.gte.com>
In article <············@wildcard.demon.co.uk>,
Cyber Surfer <············@wildcard.demon.co.uk> wrote:
>
>HotMetal uses Lisp? Good grief. My colleagues use this app,
>and yet remain ignorant of Lisp. Same with AutoCad. They've
>no use for MuMath, so that'll not convince them. Same with
>Reduce. You're using some pretty exotic examples, which is
>what I expected. _This_ is why so many people have not heard
>of Lisp, and many of those who have will base their opinions
>of it on some very outdated versions. See the intro to Winston
>and Horn, where they debunk these common myths. Sadly, most
>people don't read that book and will never have even heard of
>it, nor will they understand why they should.
The single page that Winston (with Horn) spends on
"debunking" unflattering myths about Lisp is more than
compensated by the three popular and excellent books by the
selfsame Winston plugging C, C++, and Java,
respectively. :->
--d
In article <············@wildcard.demon.co.uk>,
············@wildcard.demon.co.uk wrote:
> In other words, Emacs may be a fine editor, but some people will
> still insist that you a commercial alternative.
A commercial alternative to GNU Emacs or XEmacs? Where?
Until the advent of a commercial alternative (or the Java-based
Emacs), I'll quite happily use a perfectly supported XEmacs.
> > With CL-HTTP you can build interfaces for web sites, so that
> > they are maintainable by a nonprogrammer.
>
> Is this a standard feature of CL-HTTP, or would a programmer
> be needed to build such an interface?
You need a programmer - well unless somebody would release
source code for this purpose.
> Could the server the
> maintained _without_ a CL programmer?
Not really. A future version maybe.
> CL-HTTP would make us more vulnerable than if we chose a
> commercial web server (like the many web servers available
> for NT).
My strategy would be to use CL-HTTP as a site management
system for a conventional server.
> doubts, and I'm pro CL!
So you're are more like a "fan". You are "pro CL"?
How many lines of CL do have actually written? Which
commercial implementations are you using (LispWorks, ACL, XCL, LCL,
MCL, SCL, ...)? Do you have any real experience with CL?
> HotMetal uses Lisp? Good grief. My colleagues use this app,
> and yet remain ignorant of Lisp.
Well, there is a SCM folder inside a Lib folder. What could it be?
> Same with AutoCad. They've
> no use for MuMath, so that'll not convince them. Same with
> Reduce. You're using some pretty exotic examples, which is
> what I expected.
Yep, AutoCAD the most popular CAD system. Sold hundreds of thousands
copies. Very exotic. Scheme being base of the DSSSL expression
language, is an IEEE standard, used in many universities and schools,
used as extension language for a lot software - very exotic
What's exotic about Axiom? Maybe that its base is more advanced
then Mathematica stuff. Macsyma is pretty exotic, too.
Well, its just the grandfather of all Computer Algebra software.
RPL is the programming language for HP28 and HP48. Guess what
RPL stands for. Reverse Polish Lisp?
See http://www.schema.de/ for an ACL/PC application.
Jesus, just that your Co-workers haven't heard of any Lisp-based
application says just nothing. They probably haven't heard of
Prolog, SmallTalk, whatever applications.
Ever heard of KEE, ART, G2, GBB, Metal?
Why did people port Lisp to Mainframes or SIMD machines? Just for
fun?
Why is the CMU archive full of Lisp stuff?
If you look closely you will find them. Otherwise it would
be unexplainable, why there are so many Lisp implementations.
Or can you tell, why there are still Common Lisp vendors?
How do they manage to pay their employees? Somebody
buys this stuff.
Saying "I like CL" is kind of childish. I use CL, because
I do have a need for an interactive development system.
I can quite comfortably explore my ideas using CL.
If you can't - well - be happy and use something else
that is more suitable to your problem.
Rainer Joswig
Btw, we *really* need a web site that people see Lisp is still alive.
From: Oleg Moroz
Subject: Re: Lisp is alive, was "Re: Common LISP: The Next Generation"
Date:
Message-ID: <3232e50a.913342@news-win.rinet.ru>
On Sat, 07 Sep 1996 02:08:04 +0200, ······@lavielle.com (Rainer Joswig) wrote:
>Why did people port Lisp to Mainframes or SIMD machines? Just for
>fun?
I really think that it was mostly for fun. While functional languages _are_ real
good for parallelism and SIMD architectures in particular, (Common) Lisp is as
far from the word "functional" as Smalltalk or Pascal is.
>Why is the CMU archive full of Lisp stuff?
Why are FTP sites of the world full of free C/C++ stuff ? The ratio is not on
the Lisp side :-)
>If you look closely you will find them. Otherwise it would
>be unexplainable, why there are so many Lisp implementations.
>Or can you tell, why there are still Common Lisp vendors?
>How do they manage to pay their employees? Somebody
>buys this stuff.
You don't need to look closely to find C/C++/Fortran/... - based applications.
Most non-commercial Lisp implementation are done just for the implementor's fun.
Others are usually written in universities by a group of enthusiastic
implementors that get some funding for the project that needs Lisp (in their
opinion).
Commercial versions of Lisp exist in the small market niche that is
self-supported, much analogous to the market niche of mainframe computers and
"real" OOD tools. They are working with couple hundred of buyers (historically
devoted to their product) each, getting major bucks for every copy to cover R&D
and support costs, supporting in their products just what this limited group of
customers needs. This explains their ten-twenty year old user interfaces and
strong cross-platform orientation. The latter (bad thing in my opinion) implies
slow (if any) adoption of new operating system features, once again poor UI,
usually restricted by the common denominator of what's available on all
supported systems, and the tendency to ignore completely the issues of
shrink-wrapped distribution of the software developed on this system.
>Saying "I like CL" is kind of childish. I use CL, because
>I do have a need for an interactive development system.
>I can quite comfortably explore my ideas using CL.
>If you can't - well - be happy and use something else
>that is more suitable to your problem.
I like Scheme and I like Smalltalk and I like Haskell and it's not childish at
all. If I could do all the things I do at work in one of the languages I really
like, I would be much more happy than I am right now. The obstacle is not the
language itself, it's the particular misfeatures of available implementations /
development environments. I feel from my "hobby" experience that I could be much
more productive with, say, Lisp instead of C++ given the IDE of the same power
and capabilities that I have now. Pity, there is none.
>Btw, we *really* need a web site that people see Lisp is still alive.
What we really need is some work done in implementing really modern Lisp
development environments that suit the developers now targetting C/C++ and using
these to implement real applications that most people use everyday. Just talking
about Lisp be it in computer magazines, on the WWW site or on the radio won't
buy Lisp an ounce of popularity. It probably will support the corpse alive for
some time... Flatlined...
Oleg
In article <···············@news-win.rinet.ru>, ·····@inist.ru (Oleg
Moroz) wrote:
> I really think that it was mostly for fun. While functional languages
_are_ real
> good for parallelism and SIMD architectures in particular, (Common) Lisp is as
> far from the word "functional" as Smalltalk or Pascal is.
Lisp has a long history in the field of parallel computing. Read the
literature.
Sure CL/Scheme/EuLisp/etc. is a lot nearer to "FP" than SmallTalk and Pascal.
> Commercial versions of Lisp exist in the small market niche that is
> self-supported, much analogous to the market niche of mainframe computers and
> "real" OOD tools. They are working with couple hundred of buyers (historically
> devoted to their product) each, getting major bucks for every copy to
cover R&D
> and support costs, supporting in their products just what this limited
group of
> customers needs. This explains their ten-twenty year old user interfaces and
Have you ever used a modern Common Lisp implementation? I doubt.
Rainer Joswig
From: William A. Barnett-Lewis
Subject: Re: Lisp is alive, was "Re: Common LISP: The Next Generation"
Date:
Message-ID: <512dmu$r8d@grandcanyon.binc.net>
In article <···············@news-win.rinet.ru>, ·····@inist.ru says...
>
>On Sat, 07 Sep 1996 02:08:04 +0200, ······@lavielle.com (Rainer Joswig) wrote:
(snip)
>>Why is the CMU archive full of Lisp stuff?
>
>Why are FTP sites of the world full of free C/C++ stuff ? The ratio is not on
>the Lisp side :-)
Compare CMU vs. ftp.cdrom.com for example...
(More snipping)
>Commercial versions of Lisp exist in the small market niche that is
>self-supported, much analogous to the market niche of mainframe computers and
>"real" OOD tools. They are working with couple hundred of buyers (historically
>devoted to their product) each, getting major bucks for every copy to cover
R&D
>and support costs, supporting in their products just what this limited group
of
>customers needs. This explains their ten-twenty year old user interfaces and
>strong cross-platform orientation. The latter (bad thing in my opinion)
implies
>slow (if any) adoption of new operating system features, once again poor UI,
>usually restricted by the common denominator of what's available on all
>supported systems, and the tendency to ignore completely the issues of
>shrink-wrapped distribution of the software developed on this system.
"Why worry about those pesky PC's when everyone knows they're just a passing
fad?" This, alas, even in the places that ship a PC based product,
appears to the the answer...just following Oracle's lead, I suppose.
(final snips)
>>Btw, we *really* need a web site that people see Lisp is still alive.
>
>What we really need is some work done in implementing really modern Lisp
>development environments that suit the developers now targetting C/C++ and
using
>these to implement real applications that most people use everyday. Just
talking
>about Lisp be it in computer magazines, on the WWW site or on the radio won't
>buy Lisp an ounce of popularity. It probably will support the corpse alive for
>some time... Flatlined...
>
>Oleg
There are lisp www sites. Hit search at Alta-vist on lisp & you'll see plenty
of sites that are fun to browse and learn from. They make utterly no implact,
because most people can't get an implementation that will work with the OS most
of them are browsing there from; all too often a Win variation.
Give me a real Win32/Ole compliant/OCX'ing/dynamic linking Lisp & I'll pay
through the nose for it - because only then will I be able to retire my damned
copy of Visual Basic. Until then (HINT BLOODY HINT FRANZ!), I need it to keep
eating on a regular basis.
William Barnett-Lewis
Brain Candy Computing
······@mailbag.com
From: Cyber Surfer
Subject: Re: Lisp is alive, was "Re: Common LISP: The Next Generation"
Date:
Message-ID: <842298477snz@wildcard.demon.co.uk>
In article <·······················@news.lavielle.com>
······@lavielle.com "Rainer Joswig" writes:
> > In other words, Emacs may be a fine editor, but some people will
> > still insist that you a commercial alternative.
>
> A commercial alternative to GNU Emacs or XEmacs? Where?
> Until the advent of a commercial alternative (or the Java-based
> Emacs), I'll quite happily use a perfectly supported XEmacs.
I wasn't thinking of Emacs specifically, but of software in general.
> > > With CL-HTTP you can build interfaces for web sites, so that
> > > they are maintainable by a nonprogrammer.
> >
> > Is this a standard feature of CL-HTTP, or would a programmer
> > be needed to build such an interface?
>
> You need a programmer - well unless somebody would release
> source code for this purpose.
Umm. That's what I was afraid you might say.
> > Could the server the
> > maintained _without_ a CL programmer?
>
> Not really. A future version maybe.
Ok, thanks.
> > CL-HTTP would make us more vulnerable than if we chose a
> > commercial web server (like the many web servers available
> > for NT).
>
> My strategy would be to use CL-HTTP as a site management
> system for a conventional server.
Ahh. That's another kind of application. ;) I'd be happy to write
network management software in Lisp.
> > doubts, and I'm pro CL!
>
> So you're are more like a "fan". You are "pro CL"?
I'm certainly not anti CL. I doubt I'd have spent 6 months writing
an interpreter for a small subset of CL if I didn't like it. At the
time, XLISP was the only other "Common Lisp" available to me, and
it was the wrong subset for me.
> How many lines of CL do have actually written? Which
> commercial implementations are you using (LispWorks, ACL, XCL, LCL,
> MCL, SCL, ...)? Do you have any real experience with CL?
I've not used Lisp as much as I'd like to. As I've said, I mostly
write C/C++ code. The only commercial Lisps that I've used have
been the "web" version of ACL for Windows and Cambridge Lisp on
the Atari ST. I've not heard of XCL, LCL, or SCL, and I've never
had access to a machine capable of running MCL or LispWorks.
By "real experience", do you mean professional? I'd have to say no,
I've not.
>
> > HotMetal uses Lisp? Good grief. My colleagues use this app,
> > and yet remain ignorant of Lisp.
>
> Well, there is a SCM folder inside a Lib folder. What could it be?
It's a directory of mainly binary files. It's very hard to
see what they might be for. The 'scm' clue is all there is,
and that's only a clue to me because I can associate it with
Scheme. Apart from that, it doesn't help me.
> > Same with AutoCad. They've
> > no use for MuMath, so that'll not convince them. Same with
> > Reduce. You're using some pretty exotic examples, which is
> > what I expected.
>
> Yep, AutoCAD the most popular CAD system. Sold hundreds of thousands
> copies. Very exotic. Scheme being base of the DSSSL expression
> language, is an IEEE standard, used in many universities and schools,
> used as extension language for a lot software - very exotic
How many people know that AutoCAD uses Lisp? Was AutoCAD
written in Lisp? That's not what I've read, both on UseNet
and in magazines like Byte. I'd call AutoCAD exotic dispite
selling hundreds of thousands of copies, as CAD software
is necessarily "high profile". Besides, I'm not certain
that AutoCAD is itself written in Lisp, so this may be a
misleading argument. I thought that we were discussing
AutoLisp, which doesn't appear to have the wonderfully high
profile that AutoCAD does.
> What's exotic about Axiom? Maybe that its base is more advanced
> then Mathematica stuff. Macsyma is pretty exotic, too.
> Well, its just the grandfather of all Computer Algebra software.
Please try to see this from the point of view of a non-Lisp
programmer. Not everyone gives a shit about this stuff, but
we do. Some software could have great historical significance,
and yet be completely irrelevant to most programmers.
> Jesus, just that your Co-workers haven't heard of any Lisp-based
> application says just nothing. They probably haven't heard of
> Prolog, SmallTalk, whatever applications.
Only two of them are programmers, but one of them reviewed
Smalltalk/V a few years ago, so I think he knows it alright.
> Ever heard of KEE, ART, G2, GBB, Metal?
Yes. So? I'm not slagging off Lisp. My point is that a great
many programmers won't have heard of these things, nor will
they care, unless we explain to them why they should. We know,
and we care, but _they don't_. If you're arrogant enough to
assume they will simply because you feel they should, then
nothing will change, apart from Lisp becoming even more
marginalised than it is at present.
I'm glad that Apple recognise the value of Lisp, but is that
enough to make a difference? It might, if you think the world
of computing begins and ends with the Mac. Sadly, for many of
us, it doesn't. Nor does it begin and end with Lisp, or a
single dialect of it, like CL. I'm sorry that Apple's Dylan
appears to be in trouble, and I hope it'll recover (like if
Apple sell it to Digitool).
Meanwhile, C++ marches on. What are we doing? I'm just looking
for a way of making programming easier.
--
<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
We're living on a knife edge, looking for the ground -- Hawkwind
In article <············@wildcard.demon.co.uk>,
············@wildcard.demon.co.uk wrote:
> I've not used Lisp as much as I'd like to. As I've said, I mostly
> write C/C++ code. The only commercial Lisps that I've used have
> been the "web" version of ACL for Windows
Which is interesting but not the *real* thing.
> and Cambridge Lisp on
> the Atari ST.
Which was buggy as hell. Get a Mac emulator for the Atari
and use MacScheme.
> Only two of them are programmers, but one of them reviewed
> Smalltalk/V a few years ago, so I think he knows it alright.
Have they seen or used any SmallTalk or Prolog applications?
> I'm glad that Apple recognise the value of Lisp,
They did in some distant history. Right now they are mostly
writing crashing C programs which they deliver late.
> Meanwhile, C++ marches on. What are we doing? I'm just looking
> for a way of making programming easier.
This is a good motivation. For me using CL does work that way.
Rainer Joswig
From: Erik Naggum
Subject: Re: Lisp is alive, was "Re: Common LISP: The Next Generation"
Date:
Message-ID: <3051429384347394@arcana.naggum.no>
[Cyber Surfer]
| Meanwhile, C++ marches on. What are we doing? I'm just looking for a
| way of making programming easier.
I'd like to hear about what you're doing, when and if you are doing
something. however, your incessant complaints about how you can't use
solutions that exist and blame Common Lisp for it, predicting doom and the
end of the world so repetitiously you could probably make a small program
churn out your articles instead of typing them in, are not all that
exciting, anymore.
if you were a gourmet chef, I can imagine you incessant complaints about
how McDonald's and Burger King and Pizza Hut and all those junkfood places
grow, instead of creating wonderful menus. but as far as I can understand,
you are not a gourmet chef, either, you're just a McDonald's and Burger
King and Pizza Hut customer who's pissed that you can't get gourmet food
for one dollar a meal, who waltzes into some gourmet restaurants every few
days to tell all the customers that they are doomed because McDonald's and
Burger King and Pizza Hut are "marching on" and while you have never even
dreamed of actually paying to eat at any of the places, you clamor on about
their being doomed.
you would have been thrown out of a gourmet restaurant long ago, not the
least because you're not a paying customer. here, you have to realize that
what you bring to town is not wanted. we don't need to hear yet another
time that C++ is supposedly winning and Lisp is supposedly dying, when each
of us are working in each our small ways to solve problems that are much
more important than whichever platform is being shipped most or which
compiler has the highest sales figures this week.
do something constructive. finish up that Lisp to C compiler of yours.
whatever.
here's what I'm doing: I set out a year ago to write a small software
development system that would allow me to obtain C code without the pain
and the suffering of writing in C. part of the motivator was that GNU
Emacs internals are really gory. another part of the motivation was that I
did not want my Emacs to spend 7% of the CPU just to run that annoying
cc-mode code that doesn't even indent properly, and instead wanted to fully
exploit the Lisp syntax machinery in Emacs. I wanted type inference based
on function calls and operators, and set out to convert the stupid header
files from being data-oriented to be function-oriented. I'm probably three
months from making it fully useful to myself. by then, I will be able to
generate C code for the internals of GNU Emacs directly from the Emacs Lisp
code, and be able to move most of the C code into Lisp, which would make it
possible to redesign the internals without thousands of hours of manual
work, not to mention run the code back again to see if there are any
serious differences, like my being able to detect that some variables
should have been GCPRO'd but aren't. this small system should make it
possible to perform an arbitrary amount of work when handling the cases
that are too complex for the C macro system, such as some convention that
needs each function to add a small amount of declarations in order to use
some specially designed macros in the body of the code. it could grow up
to become a Lisp to C compiler, but I only wanted to write C in Lisp so I
could capitalize on the Lisp development tools I have already obtained or
written. I'm old enough in this game not to be impressed by GUIs that do
nothing but slow me down and hurt my hand. as I said previously, I'm not
of the "mouse generation", but rather of the "cat generation". the tools I
need and want are vastly different from those that get shrink-wrapped for
people who should not have become programmers in the first place.
#\Erik
--
those who do not know Lisp are doomed to reimplement it
From: mathew
Subject: Re: Lisp is alive, was "Re: Common LISP: The Next Generation"
Date:
Message-ID: <meta19960915235941@pobox.com>
In article <················@arcana.naggum.no>,
Erik Naggum <····@naggum.no> wrote:
>if you were a gourmet chef, I can imagine you incessant complaints about
>how McDonald's and Burger King and Pizza Hut and all those junkfood places
>grow, instead of creating wonderful menus. but as far as I can understand,
>you are not a gourmet chef, either, you're just a McDonald's and Burger
>King and Pizza Hut customer who's pissed that you can't get gourmet food
>for one dollar a meal, who waltzes into some gourmet restaurants every few
>days to tell all the customers that they are doomed because McDonald's and
>Burger King and Pizza Hut are "marching on" and while you have never even
>dreamed of actually paying to eat at any of the places, you clamor on about
>their being doomed.
Well, let's turn that analogy around a bit.
We want a cup of coffee.
So we go to the Common LISP gourmet restaurant, and they say: Sure, we
can give you a cup of coffee. It'll be lovely freshly ground full
bodied coffee, the best you've ever tasted. However, you have to have
a three course meal with dessert as well.
So we try the Scheme diner, and they say: Well, we got rid of the
three course meal and dessert, and we have some fantastic fresh
Guatemalan coffee beans; they're beautiful and shiny, individually
polished even, and they smell really good too. We also have six or
seven different plans for making a grinder, and we've got some clay and
a kiln to make a cup with...
So we ask at the Java market stall, and they say: Well, we can't offer
you a cup of coffee, but we can offer you a picture of some dancing
coffee beans. Someone's announced that they'll be releasing a grinder
real soon now, and we're building a cold fusion reactor to heat the
water with. Oh, but for safety reasons you can't have any hot liquids
in cups.
So reluctantly, we go back to the C/C++ Burger King, and they make us a
cup of instant coffee with non-dairy creamer. And it tastes pretty
foul, but it is at least roughly what we wanted.
mathew
[ Ramping up the cynicism ready for Monday ]
--
····@pobox.com content available at http://www.pobox.com/%7Emeta/
Help prevent bias on the net; http://www.pobox.com/%7Emeta/rs/ot/ for info
"There's safety in numbers... Large prime numbers." -- John Gilmore
In article <··················@pobox.com>, ····@pobox.com (mathew) wrote:
> In article <················@arcana.naggum.no>,
> Erik Naggum <····@naggum.no> wrote:
> >if you were a gourmet chef, I can imagine you incessant complaints about
> >how McDonald's and Burger King and Pizza Hut and all those junkfood places
> >grow, instead of creating wonderful menus. but as far as I can understand,
> >you are not a gourmet chef, either, you're just a McDonald's and Burger
> >King and Pizza Hut customer who's pissed that you can't get gourmet food
> >for one dollar a meal, who waltzes into some gourmet restaurants every few
> >days to tell all the customers that they are doomed because McDonald's and
> >Burger King and Pizza Hut are "marching on" and while you have never even
> >dreamed of actually paying to eat at any of the places, you clamor on about
> >their being doomed.
>
> Well, let's turn that analogy around a bit.
>
> We want a cup of coffee.
>
> So we go to the Common LISP gourmet restaurant, and they say: Sure, we
> can give you a cup of coffee. It'll be lovely freshly ground full
> bodied coffee, the best you've ever tasted. However, you have to have
> a three course meal with dessert as well.
>
> So we try the Scheme diner, and they say: Well, we got rid of the
> three course meal and dessert, and we have some fantastic fresh
> Guatemalan coffee beans; they're beautiful and shiny, individually
> polished even, and they smell really good too. We also have six or
> seven different plans for making a grinder, and we've got some clay and
> a kiln to make a cup with...
>
> So we ask at the Java market stall, and they say: Well, we can't offer
> you a cup of coffee, but we can offer you a picture of some dancing
> coffee beans. Someone's announced that they'll be releasing a grinder
> real soon now, and we're building a cold fusion reactor to heat the
> water with. Oh, but for safety reasons you can't have any hot liquids
> in cups.
Therefore, we have the ability to pour hot liquid directly down your
throat continously, causing you to be so busy choking...er, drinking that
you don't have time to do anything else.
> So reluctantly, we go back to the C/C++ Burger King, and they make us a
> cup of instant coffee with non-dairy creamer. And it tastes pretty
> foul, but it is at least roughly what we wanted.
Then you hear about the Dylan cafe, which advertises a wonderful,
perfect, rich cup of espresso, but when you get there, they tell
you they're going out of business but you can have a free sample of
some of their half-brewed stuff that's been sitting in the pot for
a while. It tastes pretty good, even though it's cold and hard to drink
from that awkward revised infix styrofoam cup (the masses just don't like
ceramics, you see), but you will never get any more of it (except
vicariously by reading about it in a Harlequin romance), so you're
on your way back to the Burger King.
At which time you spy, out of the corner of your eye, a place called
"The Smalltalk Bistro"...
Shannon Spires
·······@telespin.com
From: Cyber Surfer
Subject: Re: Lisp is alive, was "Re: Common LISP: The Next Generation"
Date:
Message-ID: <842881413snz@wildcard.demon.co.uk>
In article <························@news.nmia.com>
·······@telespin.com "Shannon Spires" writes:
> Then you hear about the Dylan cafe, which advertises a wonderful,
> perfect, rich cup of espresso, but when you get there, they tell
> you they're going out of business but you can have a free sample of
> some of their half-brewed stuff that's been sitting in the pot for
> a while. It tastes pretty good, even though it's cold and hard to drink
> from that awkward revised infix styrofoam cup (the masses just don't like
> ceramics, you see), but you will never get any more of it (except
> vicariously by reading about it in a Harlequin romance), so you're
> on your way back to the Burger King.
That's the bitter flavour, I think. It's best to let it brew
for a few years, then you get a much more enjoyable taste. ;-)
Lisp has been brewing for years - perhaps too long - so the taste
is a very unusual one. You'll either love it or hate it. <sigh>
A few radicals sometimes suggest adding artificial flavouring,
but the purists always shout at them until they shut up again.
> At which time you spy, out of the corner of your eye, a place called
> "The Smalltalk Bistro"...
Ah, yes. The place that's suspended from a balloon that nobody
can find, probably coz it's way too high up. Still, the brightly
decorated walls are very attractive, and those bean bags...
But to get there, you have to pass the hotdog stand. Yep, that
smells like Basic! I'll have a coke with mine...<gag>
--
<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
We're living on a knife edge, looking for the ground -- Hawkwind
From: Thant Tessman
Subject: Re: Lisp is alive, was "Re: Common LISP: The Next Generation"
Date:
Message-ID: <323EC18C.41C6@interramp.com>
>
> In article <··················@pobox.com>,
····@pobox.com (mathew) wrote:
> We want a cup of coffee. [...]
Shannon Spires wrote:
> Then you hear about the Dylan cafe, [...]
Meanwhile, at the secret SML Labs, they don't have any
coffee, but they have been working on a highly potent
form of caffeine. And they don't have any cream or
sugar, or cups, but they do have a drawer full of
freshly sterilized syringes.
-thant
In article <·······················@news.lavielle.com>
······@lavielle.com "Rainer Joswig" writes:
> Ever heard of AutoCad? Reduce? MuMath? Never heard of Macsyma?
From what I've read about AutoCad, it seems that it isn't actually
written in Lisp, but uses AutoLisp to extend it.
> HotMeTaL? Interleaf? Abuse? A lot of CAD systems are using Lisp.
I recently checked the manual for the Windows version of HotMetal,
and there was no mention of Lisp at all. It appears to be a well
kept secret.
There's a browser and web server written in ML (at CMU), but they
only run on certain Unix machines. Meanwhile, MS are busy promoting
ActiveX, ISAPI, etc. No wonder so many people think that you need
C++ to write Internet software.
Lisp needs some much better PR, like a few killer apps written in
Lisp, and a lot of noise making sure that everybody knows it.
I do mean _a lot_, esp if you want to drown out the message that
"C++ is best", which is currently dominant. Believe it or not, but
there are actually a few people who don't even know Lisp _exists_.
On the other hand, perhaps Lisp is just for the elitists. Fair enough,
but that might explain why so few of us can use it. Please note the
"can". In theory, I can use Lisp, and I do use it. However, nobody
will know that I use it unless I tell them, and even then they're
unlikely to ever see the software I write in Lisp, as I can't give
them stand-alone binary.
--
<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
We're living on a knife edge, looking for the ground -- Hawkwind
In article <············@wildcard.demon.co.uk>,
············@wildcard.demon.co.uk wrote:
>In article <·······················@news.lavielle.com>
> ······@lavielle.com "Rainer Joswig" writes:
>
>> Ever heard of AutoCad? Reduce? MuMath? Never heard of Macsyma?
>
>From what I've read about AutoCad, it seems that it isn't actually
>written in Lisp, but uses AutoLisp to extend it.
>
>> HotMeTaL? Interleaf? Abuse? A lot of CAD systems are using Lisp.
GNU EMACS, AutoCAD, and Abuse all fall into the category of software with
a high-performance core in C/C++ and an interpreter for some dialect of
Lisp, principally so that they can be extended by use of a
highly-expressive language. It's interesting that Abuse, a side-scrolling
arcade-style action game, is extended via a Lisp interpreter. Guess
performance was acceptable after all.
>I recently checked the manual for the Windows version of HotMetal,
>and there was no mention of Lisp at all. It appears to be a well
>kept secret.
SoftQuad, the creators of HoTMetaL Pro and HoTMetaL Free, are a well-known
entity in a little-known market, namely the SGML market, where Scheme is
becoming an increasingly-accepted vehicle for implementing the
complexities of conformant SGML support. If you look around the various
HoTMetaL directories after installing, you will indeed find one (HoTMetaL
Free) or more (HoTMetaL Pro) .scm files.
>There's a browser and web server written in ML (at CMU), but they
>only run on certain Unix machines. Meanwhile, MS are busy promoting
>ActiveX, ISAPI, etc. No wonder so many people think that you need
>C++ to write Internet software.
The reason that so many people think that you need C++ to write Internet
software is that the Internet was built around UNIX, hence C, and C++ is
hair [sic] apparent to C.
>Lisp needs some much better PR, like a few killer apps written in
>Lisp, and a lot of noise making sure that everybody knows it.
I wonder why the above-mentioned "hybrid software" isn't compelling?
Perhaps because not everyone needs or wants it. It has occurred to me
more than once that in all of the instances in which I haven't cared about
some of Common Lisp's shortcomings, such as a huge price of admission in
terms of memory consumption, it's been for the obvious reason that Common
Lisp's baggage has been dwarved by the application-specific code that I've
brought to the party. In other words, I tend to use Common Lisp for large
projects--much, much larger than I'd be willing to contemplate writing,
let alone debugging, in C++. Which leads me to a follow-up thought: is it
perhaps possible that C/C++ are the McDonald's of software
development--billions served, utterly pervasive, highly consistent
results--while the Lisp family of languages is the Antoine's or the Ma
Maison--high price of admission, extremely high quality, and really only
applicable to special occassions, but on those special occassions you're
not going to go to McDonald's, right?
>I do mean _a lot_, esp if you want to drown out the message that
>"C++ is best", which is currently dominant. Believe it or not, but
>there are actually a few people who don't even know Lisp _exists_.
As there are people scratching their heads and asking "What's Antoine's?"
or "What's Ma Maison?" (Answer: Antoine's is perhaps the most famous
restaurant in New Orleans; Ma Maison is a restaurant of similar repute in
Los Angeles.)
>On the other hand, perhaps Lisp is just for the elitists.
Ha! I hadn't even read this far when I started to reply! How funny.
>Fair enough,
>but that might explain why so few of us can use it. Please note the
>"can". In theory, I can use Lisp, and I do use it. However, nobody
>will know that I use it unless I tell them
How will anyone _know_ that you use C++, either, unless you tell them?
They might _assume_ so. I've surprised people before by handing them a
piece of software that they "knew" was in C++, until I explained to them
that Oberon is a pretty cool language.
>and even then they're
>unlikely to ever see the software I write in Lisp, as I can't give
>them stand-alone binary.
Funny; I've got standalone binaries for the applications I build using
Macintosh Common Lisp. Granted, they're a bit hefty to fit on floppies,
but anything that takes >2 HD floppies will be cheaper to distribute on
CD-ROM anyway.
><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
>We're living on a knife edge, looking for the ground -- Hawkwind
--
To get random signatures put text files into a folder called �Random Signatures� into your Preferences folder.
In article <······················@ppp-18.ts-1.la.idt.net>
·····@chelsea.ios.com "Paul Snively" writes:
> GNU EMACS, AutoCAD, and Abuse all fall into the category of software with
> a high-performance core in C/C++ and an interpreter for some dialect of
> Lisp, principally so that they can be extended by use of a
> highly-expressive language. It's interesting that Abuse, a side-scrolling
> arcade-style action game, is extended via a Lisp interpreter. Guess
> performance was acceptable after all.
Have you noticed that the mainstream computer press tend not
to mention this? It's been a number of years since I last read
anything about AutoLisp in a magazine. I've hardly _ever_ seen
a reference to Emacs in a mag, but when I do, Lisp is never
mentioned. I must be reading the wrong mags, obviously.
My point (if you look back that far) was that Lisp doesn't have
a high profile. Nobody has yet disputed that. It's true that
products, like AutoCAD, that use Lisp have a high profile, but
that's not the same thing. If HotMetal is written in Lisp, where
does the manual say this? I've yet to read a review that mentions
it, either.
If magazines like Byte mentioned Lisp only 10% as often as C++
then Lisp might have a much higher profile that it does as present,
and _perhaps_ there might be more interest in it. I don't blame
such magazines for not covering Lisp as much as they used to,
as they've got so much more software to cover now.
> >I recently checked the manual for the Windows version of HotMetal,
> >and there was no mention of Lisp at all. It appears to be a well
> >kept secret.
>
> SoftQuad, the creators of HoTMetaL Pro and HoTMetaL Free, are a well-known
> entity in a little-known market, namely the SGML market, where Scheme is
> becoming an increasingly-accepted vehicle for implementing the
> complexities of conformant SGML support. If you look around the various
> HoTMetaL directories after installing, you will indeed find one (HoTMetaL
> Free) or more (HoTMetaL Pro) .scm files.
These files are binary, in the Windows version of HotMetal.
It's impossible to tell that they have any connection with
Scheme. Not everyone knows as much as we do about Lisp, so
most people will just have to guess that .scm is somehow
related to Scheme, and that Scheme is a dialect of Lisp, and
that perhaps HotMetal is written in Lisp.
That looks like a well kept secret to me.
> >There's a browser and web server written in ML (at CMU), but they
> >only run on certain Unix machines. Meanwhile, MS are busy promoting
> >ActiveX, ISAPI, etc. No wonder so many people think that you need
> >C++ to write Internet software.
>
> The reason that so many people think that you need C++ to write Internet
> software is that the Internet was built around UNIX, hence C, and C++ is
> hair [sic] apparent to C.
Plus, companies like MS are busy telling everyone that C/C++
is necessary. Perhaps they're saying this because that's what
they sell, but not everyone will be cynical to suspect that.
Tell a lie often enough...
> >Lisp needs some much better PR, like a few killer apps written in
> >Lisp, and a lot of noise making sure that everybody knows it.
>
> I wonder why the above-mentioned "hybrid software" isn't compelling?
> Perhaps because not everyone needs or wants it. It has occurred to me
> more than once that in all of the instances in which I haven't cared about
> some of Common Lisp's shortcomings, such as a huge price of admission in
> terms of memory consumption, it's been for the obvious reason that Common
> Lisp's baggage has been dwarved by the application-specific code that I've
> brought to the party. In other words, I tend to use Common Lisp for large
> projects--much, much larger than I'd be willing to contemplate writing,
> let alone debugging, in C++. Which leads me to a follow-up thought: is it
> perhaps possible that C/C++ are the McDonald's of software
> development--billions served, utterly pervasive, highly consistent
> results--while the Lisp family of languages is the Antoine's or the Ma
> Maison--high price of admission, extremely high quality, and really only
> applicable to special occassions, but on those special occassions you're
> not going to go to McDonald's, right?
This supports my suspicion that Lisp programmers are elitists. ;-)
Why are people so obsessed with using small apps? Perhaps coz
they have "small" jobs to do. This reminds me an example given
in comp.sys.super recently, comparing the big supers to the
much smaller machines that non-supercomputing people use.
(Super heroes vs Bycicle Repair Man.)
Curiously, VB programmers have promoted VB by claiming it has
virtues that sound similar to many of the virtues of Lisp.
Rapid development, easy reuse of tools (in the form of VBX
and OCX controls), friendly debugging, an FFI, etc. These
programmers could be the ultimate Bycycle Repair Men.
What VB _lacks_ is perhaps more important, but not enough to
stop it being extremely popular. Give MS the credit for that!
It's success is not necessarily only due to the qualities of
the product itself. VB lacks the introspection of CL, OO
features like classes, closures and functions as first class
objects.
My favourite distinction is a very simple one. Every time I
look at a Lisp, which in my case will be running under NT,
I ask myself if it would be better for Windows apps that just
happen to be written in Lisp, or Lisp apps that just happen
to run under Windows. I doubt that many Windows users will
care what language an app is written in, but they _will_ care
whether it functions as a good Windows app, exploiting the
features of that OS.
This should apply to any other OS, too. For example, I'd
expect Mac users to be no less demanding. This means that
users won't want an app that only runs in the development
enviroment that created it. They'll want a stand-alone app
that looks like all the other apps they use. Those apps
may well be written in C++, so Lisp will have to compete
with the capabilities of C++ for that OS.
Lisp may even have to compete with other development tools
like VB, HyperCard, etc - and now Java.
> >I do mean _a lot_, esp if you want to drown out the message that
> >"C++ is best", which is currently dominant. Believe it or not, but
> >there are actually a few people who don't even know Lisp _exists_.
>
> As there are people scratching their heads and asking "What's Antoine's?"
> or "What's Ma Maison?" (Answer: Antoine's is perhaps the most famous
> restaurant in New Orleans; Ma Maison is a restaurant of similar repute in
> Los Angeles.)
Do you think that this might be possible? Would the regulars
at Ma Maison or Antoine's want to attract the customers of
McDonald's? Would that be a good thing?
Fortunately, we're discussing a programming language. Why should
the users of Lisp be elitist?
> >On the other hand, perhaps Lisp is just for the elitists.
>
> Ha! I hadn't even read this far when I started to reply! How funny.
I'd be laughing if it wasn't so sad. I want to write software
that "ordinary people" can use. If I can't do it in Lisp, then
I'll have to use something else, like C++. Which is exactly
what I'm doing, and so are a lot of other people.
> >Fair enough,
> >but that might explain why so few of us can use it. Please note the
> >"can". In theory, I can use Lisp, and I do use it. However, nobody
> >will know that I use it unless I tell them
>
> How will anyone _know_ that you use C++, either, unless you tell them?
> They might _assume_ so. I've surprised people before by handing them a
> piece of software that they "knew" was in C++, until I explained to them
> that Oberon is a pretty cool language.
This is why I started writting a Lisp to C compiler. I _know_
I can fool people with it (once it supports a few useful features,
like a GUI, files, etc). I doubt I can do it with ACL.
> >and even then they're
> >unlikely to ever see the software I write in Lisp, as I can't give
> >them stand-alone binary.
>
> Funny; I've got standalone binaries for the applications I build using
> Macintosh Common Lisp. Granted, they're a bit hefty to fit on floppies,
> but anything that takes >2 HD floppies will be cheaper to distribute on
> CD-ROM anyway.
CD-ROM would be wonderful, but it's not always practical
Some users only have floppies, and some software is aimed
at exactly those users. Not because they use floppies, but
coz we _know_ they'll have an old machine. That's a "special
case", but it's a real one. Some users can't choose their
hardware, so we have to write the software they can use,
instead of the software we'd like them to use.
Ideally, we'd just demand that all users have a CD-ROM drive
and any other hardware needed to run our software. Perhaps
in an ideal world we'd all be using Macs, but the real world
isn't like that. I prefer to be pragmatic and look at the
things I can do. Sadly, that means I don't get to use Lisp
for work I do. If I get asked to use an OCX control, and
I don't have a Lisp that can use OCX controls, then...
As soon as I'm asked to write an app that ACL can deliver,
then I'll be happy to use it. _Very_ happy. That's coz I'm
pro Lisp. My boss thinks that HotMetal written Lisp is "cool",
so at least he's not anti Lisp. He used and loved Actor,
when it was available.
I'm optimistic, but it'll really depend on which Windows
features are supported by Lisps like ACL for Windows, and
it delivers them (image size, etc).
--
<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
We're living on a knife edge, looking for the ground -- Hawkwind
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
In article <··················@ms3.maus.de>
···········@ms3.maus.westfalen.de "Georg Bauer" writes:
> 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.
Has anyone actually _done_ this? OCX is tied very close to the API,
as I understand it. I don't know enough about ACL (the docs in the
web version leave out a of important details) to know whether you
could do this.
> if
> you can live with the needed resources of ACL - it's a bit of a memory hog.
This is the big problem. It may seem trivial to some people, but
they probably don't write Windows apps. Office apps for Windows are
heavily criticised for being too big, so a much smaller app (in terms
of features) that is significantly larger than it might be in C++
isn't going to win many friends.
In a highly competitive market, "details" like this can be critical.
> 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.
I'm learning ML at the moment, and I like it _a lot_. I'm still
looking for an industrial strength development system for Windows
that uses ML, but it's possible. There's also Haskell, and perhaps
some of the neat tools being developed with it will eventually
migrate to the platform that I'm using.
As for Dylan, Gwydion may be available in a few years from now.
That sounds _exactly_ like what I'm looking for. If it were
available today, and if it had OCX support, then I might be using
it commercially to development and deliver some killer multimedia
apps. (Just write some DirectX classes...)
> 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.
I've got a Mr Ed beta (0.7 release). It looks better than most of
the Scheme stuff I've seen for Windows, but the demo wasn't very
impressive. Well, it was only beta, after all. It's an early one,
and very basic.
I may need more than a beta before committing to such a tool,
esp when it's so obvious that C++ will already do what we need,
coz MS have gone to a lot of trouble to make sure that it will.
It's not obvious at all, at least from the version I have, that
Mr Ed can do what we need.
--
<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
We're living on a knife edge, looking for the ground -- Hawkwind
Hi!
CS>I'm learning ML at the moment, and I like it _a lot_. I'm still
CS>looking for an industrial strength development system for Windows
CS>that uses ML, but it's possible.
A industrial strength compiler is available (Objective CAML for Win95/NT
and HBC for Win95/NT). Both produce native code, the former needs Visual
C++ and Masm, but because of this integrates quite good with normal
C-Stuff.
CS>I may need more than a beta before committing to such a tool,
CS>esp when it's so obvious that C++ will already do what we need,
CS>coz MS have gone to a lot of trouble to make sure that it will.
CS>It's not obvious at all, at least from the version I have, that
CS>Mr Ed can do what we need.
Actually Mr. Ed can map Scheme classes to C++ classes and can do that
bidirectionally (you can inherit in a C++ class from a Scheme class), so
you can write low-level API stuff in C++ and connect that to high-level
stuff written in Scheme. And Mr. Ed has a integrated environment (actually
there are two available environments, one much like the Emacs environment
and the other more like a standard IDE).
bye, Georg
cyber_surfer [amongst other things]:
...
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.
...
i do not know what you are trying to say here. whatever lisp programmers
have "known and used" is on the fingertips of every sixteen year old who
can hold a keyboard these days. [in the case of lincoln-sudbury highschool
this was probably true more than a decade ago :)] java has nothing to do
with it, except packaging. new generation of programmers appear to know
the tricks of the trade, if not the history.
oz
In article <···············@nexus.yorku.ca>
··@nexus.yorku.ca "ozan s. yigit" writes:
> cyber_surfer [amongst other things]:
>
> ...
> 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.
> ...
>
> i do not know what you are trying to say here. whatever lisp programmers
> have "known and used" is on the fingertips of every sixteen year old who
> can hold a keyboard these days. [in the case of lincoln-sudbury highschool
> this was probably true more than a decade ago :)] java has nothing to do
> with it, except packaging. new generation of programmers appear to know
> the tricks of the trade, if not the history.
How many 16 year olds are using closures and higher order
functions? I don't know. Perhaps they're still at school,
and using MIT Scheme? I wouldn't say that every 16 year old
uses these things, even if they have learned to program.
Java has a lot "to do with it", coz that's the language that
appears to get the most attention, at least in the media.
In a few years we'll know just what _real_ impact Java will
have. Perhaps C++ is just a passing fad, and the majority of
programmers 10 years from now will be using Lisp, or something
like it (ML, Dylan, whatever).
I've seen more books about Java that've been published in
the last year than all the Lisp books I've seen. There are
certainly more Lisp books than I've seen, but there are also
a lot more Java books that I've not yet seen.
So, we can at least say that there's a lot of interest in
Java from book publishers. What can we conclude from this?
History is written by the winning side, but does that mean
that Java is "winning"? MS and Sun are heavily promoting
Java. Why should they tell anyone that the ideas in Java
originally came from languages like Lisp? I've not read
anything from MS that mentions Lisp.
I'm currently waiting to see if MS will offer Java as an
alternative to VBA (Visual Basic for Applications), as that
would allow any tools written for and with Java to work
with any of the MS apps that used to use VBA. (Imagine if
VB could generate code for the JVM.)
Since Apple have also adopted Java (boo, hiss / sulk),
perhaps they too will employ Java in a few key places,
where previously some other language has been used.
It might then be possible to write code for these apps
in _Lisp_. Today, a few apps like AutoCAD can be extended
in Lisp (e.g. AutoLisp), but wouldn't it be great if many
of the languages unique to a single app or vendor could
be replaced by Lisp?
This is why I suspect that Java could help Lisp. At the
very least it could open the eyes of a few programmers
who're obsessed with the low level view of programming
that C/C++ encourages. It might also help us give Lisp
a higher profile.
--
<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
We're living on a knife edge, looking for the ground -- Hawkwind
Speaking as a long time C/C++ programmer (with a soft spot for
Lisp/Scheme/Dylan), I'd like to point out a few things:
When choosing which language to use, I don't look around and say, "well,
Lisp is pretty cool, but I'm too obsessed with low-level views of
programming, so I'll use C/C++." It's much more along the lines of, "C
sucks, but lots of people will pay me lots of money to program in it. C
sucks, but it sucks in extremely well-documented ways. C sucks but it's a
popular language, so there are a wide variety of inexpensive tools to help
make it suck less."
Because I know C and C++ suck, I'm always on the lookout for new and
better programming lanaguages. That's why I learned Scheme, and why I've
been following Dylan since 1992. It's also why I'm learning Java.
As you chart the future of dynamic languages, please understand that we
heathens use C/C++ not because we're stupid, naive or prejudiced, but
because our standards forwhat makes a good language are different. We
look for more than just a good language design. We want an vast
infrastructure to support the language. We want it so badly that we are
willing to overlook major flaws in the language itself if the
infrastructure is good enough. We want it so bady that we will not
consider language like Dylan, which athough technically elegant, has
virtually no infrastructure supporting it.
Give me a language like Dylan and an infrastructure like C/C++, and I'll
adopt it immediately!
--
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".
In article <························@news.mcs.com>, ·······@spyglass.com
(John Brewer) wrote:
> because our standards forwhat makes a good language are different. We
> look for more than just a good language design. We want an vast
> infrastructure to support the language.
This is a very important point. It will be crucial for
a "success" of Dylan to get this infrastructure.
- Literature
- Code Libraries
- Consultants
- Education
- Programmers
- Magazines
- Support lines
- Sales channels
- Media attention
You *need* to create a whole market around it to really
reach the mass market.
Rainer Joswig
Cyber Surfer:
I recently checked the manual for the Windows version of HotMetal,
and there was no mention of Lisp at all. It appears to be a well
kept secret.
HotMetal internally uses scheme [descendant of a scheme i happen to
know well] but this is not user-visible unlike some of the bigger products
from SoftQuad. not a secret.
oz
From: Robert Sanders
Subject: Re: Lisp is alive, was "Re: Common LISP: The Next Generation"
Date:
Message-ID: <knhgp9a8ju.fsf@xena.mindspring.com>
······@lavielle.com (Rainer Joswig) writes:
> RPL is the programming language for HP28 and HP48. Guess what
> RPL stands for. Reverse Polish Lisp?
You're reaching. RPL is very similar to Forth, and has almost nothing
in common with Lisp. I wish it did.
-- Robert
From: Erik Naggum
Subject: Re: Lisp is alive, was "Re: Common LISP: The Next Generation"
Date:
Message-ID: <3051169529237741@arcana.naggum.no>
[Rainer Joswig]
| RPL is the programming language for HP28 and HP48. Guess what RPL
| stands for. Reverse Polish Lisp?
[Robert Sanders]
| You're reaching. RPL is very similar to Forth, and has almost nothing
| in common with Lisp. I wish it did.
hmmm. the only similarity to Forth I remember is the stack representation
of arguments and return values. one might as well say PostScript.
I have also heard that RPL stands for Reverse Polish Lisp internally to HP,
and it's not a joke. I wrote a fair amount of code in System RPL a few
years back (the internal language, related to RPL like Emacs Lisp to Emacs'
commands). RPL has dynamic types, type dispatch, garbage collection, many
functions with Lispy names, lambda forms (local variables), etc. it also
has a number of features that are not lispy at all, and which _could_ be
used to contradict any assessment of RPL as "Lispy".
#\Erik
--
those who do not know Lisp are doomed to reimplement it
In article <··············@xena.mindspring.com>, Robert Sanders
<········@mindspring.net> wrote:
> ······@lavielle.com (Rainer Joswig) writes:
>
> > RPL is the programming language for HP28 and HP48. Guess what
> > RPL stands for. Reverse Polish Lisp?
>
> You're reaching. RPL is very similar to Forth, and has almost nothing
> in common with Lisp. I wish it did.
Quoting the HP48 FAQ:
RPL
RPL is the name of the language used to program the HP48 and
HP-28 series calculators. RPL stands for "Reverse Polish Lisp".
It's interesting to note that an HP Journal article incorrectly
described RPL as "ROM-based Procedural Language".
Greetings,
Rainer Joswig
From: Georg Bauer
Subject: Lisp is alive, was "Re: Common LISP: The Next Generation"
Date:
Message-ID: <199609100720.a26098@ms3.maus.de>
Hi!
RS>You're reaching. RPL is very similar to Forth, and has almost nothing
RS>in common with Lisp. I wish it did.
Actually it does have much in common with Lisp: high level data structures,
recursion based programming (ok, it has normal structures and goto's, too),
runtime type informations (typed data objects), typeless variables.
Especially the data structures with it's high level lisps and total lack of
pointers are much more lisp like. Even anonymous functions are possible
(lambda-expressions), although it's a bit tricky.
BTW: RPL has nothing in common with Forth, except the order of notation,
since Forth doesn't have any high level data structures, doesn't have any
typing informations etc. The more Forth-like language in the HP48 is
Sys-RPL, where your drop all the funny stuff from User-RPL just to become a
bit faster.
Just because something looks like Forth, it doesn't have to be one ;-)
(But just because something has much in common with lisp, it doesnt have to
be one - RPL for example. It's lisp_like_, but not a full featured lisp,
that's right)
bye, Georg
* Cyber Surfer wrote:
> I recently checked the manual for the Windows version of HotMetal,
> and there was no mention of Lisp at all. It appears to be a well
> kept secret.
It is. It's actually in some kind of scheme dialect I think (with
some C runtime support). Perhaps someone at softquad reads this group
& could comment?
--tim
On 09 Sep 1996 11:29:04 +0100, Tim Bradshaw <···@aiai.ed.ac.uk> wrote:
>> I recently checked the manual for the Windows version of HotMetal,
>> and there was no mention of Lisp at all. It appears to be a well
>> kept secret.
>
>It is. It's actually in some kind of scheme dialect I think (with
>some C runtime support). Perhaps someone at softquad reads this group
>& could comment?
Looks like they used Scheme for what most SGML people are using it now: DSSSL (I
always forget how many S to write :-)), which is basically a Scheme-like
language for describing SGML stylesheets.
Oleg
* Robert Sanders wrote:
> ······@lavielle.com (Rainer Joswig) writes:
>> RPL is the programming language for HP28 and HP48. Guess what
>> RPL stands for. Reverse Polish Lisp?
> You're reaching. RPL is very similar to Forth, and has almost nothing
> in common with Lisp. I wish it did.
From the comp.sys.hp48 FAQ
RPL
RPL is the name of the language used to program the HP48 and
HP-28 series calculators. RPL stands for "Reverse Polish Lisp".
It's interesting to note that an HP Journal article incorrectly
described RPL as "ROM-based Procedural Language".
Of course they could be wrong! I've always thought that forth *was* a
bit similar to a reverse polish lisp actually, though it's a very long
time since I wrote forth.
--tim
From: ozan s. yigit
Subject: Re: Lisp is alive, was "Re: Common LISP: The Next Generation"
Date:
Message-ID: <OZ.96Sep10142621@nexus.yorku.ca>
> those who do not know Lisp are doomed to reimplement it
so is that what happens with all the scheme implementations?
mit scheme elk libscheme
skim psi guile
scm vscm mzscheme
mzscheme kava minischeme
rscheme scheme2c hobbit
chez rabbit oaklisp
macscheme fools oscheme
gambit T pcscheme
scheme48 bigloo stalin
scheme84 gscheme pseudo
s88 pixiescheme siod
umbscheme xscheme ...
:-]
············@wildcard.demon.co.uk (Cyber Surfer) writes:
> > At which time you spy, out of the corner of your eye, a place called
> > "The Smalltalk Bistro"...
>
> Ah, yes. The place that's suspended from a balloon that nobody
> can find, probably coz it's way too high up. Still, the brightly
> decorated walls are very attractive, and those bean bags...
Oh, the balloon--it's a Smalltalk Museum, didn't you know? Where have
you been for the last 15 years then? Stop gaping at it and look what
is around, just to be fair.
Since September 16, at <http://www.objectshare.com> you can find the
Smalltalk Express. It is a full Smalltalk/V Windows 2.0 plus the
WindowBuilder. Your application is an .EXE, and development and
runtime support stuff is packaged as DLLs. (Or at least they look
so). A moderate application (sort of a structured drawing package)
produces about 300k executable, a small (15 puzzle)--about 50k.
Runtime support DLLs are around 1M, and of course they are shareable
by multiple applications. Not bad, huh? As for the FFI: you can call
any function from any DLL, create callbacks in your code, create C
data structures to pass to Windoze calls. Four years ago when it was
released commercially, this ST/V+WB bundle would cost you about $700.
(Oh yes, and that "V" is "vee", not "5".) Now it is free and *not
crippled*. In fact, it is extended as compared to the old ST/V Win
2.0.
At <http://www.objectconnect.com> you can find Smalltalk MT with even
tighter Windows (95 and NT only) integration. It is still in beta,
and you can get it free. The planned price is around $300. It
provides a full OLE support and is basically equivalent to programming
for Windows with Borland C++ 2.0. It can generate native code
executables or DLLs, with functions exportable as if there were in C.
It feels less like a full-blown Smalltalk, though, and the library is
thinner.
At <http://www.intuitive.co.uk/dolphin> you can find a beta of Dolphin
Smalltalk. It is closer to the classic Smalltalk in spirit, with a
pretty full class library, compatible with the upcoming X3J20 ANSI
standard, bytecode-interpreted. They promise a native code JIT
compiler soon, as well as the OLE support plus some Internet-related
buzz (sorry, I forgot what--don't care much). They also promise to
set the price under $200.
On the heavier side of the spectrum, there is LearningWorks
<http://sumeru.stanford.edu/learningworks/>: a free Smalltalk using
the virtual machine of VisualWorks (which is, in turn, the proverbial
Balloon (Smalltalk-80) after 15 years of evolution). It is not a
vehicle for conquering Windoze, though: it is multi platform, and
support for each specific platform is weak. But it's free, and
performance-wise it will beat the hell out of ST/V and Dolphin ST.
I personally was much happier to see CMUCL for Linux than any of the
above. But if you are really into that Windoze dominance thing, a CL
built and looking *at least* like Smalltalk/V would be a good step
forward.
Where would it come from, though? I have no idea.
--Vassili
From: Cyber Surfer
Subject: Re: Lisp is alive, was "Re: Common LISP: The Next Generation"
Date:
Message-ID: <843063646snz@wildcard.demon.co.uk>
In article <··············@wintermute.hip.cam.org>
······@cam.org "Vassili Bykov" writes:
> Oh, the balloon--it's a Smalltalk Museum, didn't you know? Where have
> you been for the last 15 years then? Stop gaping at it and look what
> is around, just to be fair.
I've been exploring alternatives, like Lisp, for the last 10
years or so, and I was playing with Forth before that. Plus C
and assembly language when necessary. When I used CP/M-68K,
all I had was C and assembly, so I created my own Forth and
Lisp interpreters.
My tiny Pascal compiler generated asm code for a while, but
then I became interested in quadruples. Anyway, it was never
more than a _very_ tiny compiler - 1500 lines of C isn't much.
> Since September 16, at <http://www.objectshare.com> you can find the
> Smalltalk Express. It is a full Smalltalk/V Windows 2.0 plus the
> WindowBuilder. Your application is an .EXE, and development and
> runtime support stuff is packaged as DLLs. (Or at least they look
> so). A moderate application (sort of a structured drawing package)
> produces about 300k executable, a small (15 puzzle)--about 50k.
Excellent. I'll take a look at the weekend. It's been a long
time since I took any interest in Smalltalk, but this sounds
like the kind of runtime I want for Lisp.
> Runtime support DLLs are around 1M, and of course they are shareable
> by multiple applications. Not bad, huh? As for the FFI: you can call
> any function from any DLL, create callbacks in your code, create C
> data structures to pass to Windoze calls. Four years ago when it was
> released commercially, this ST/V+WB bundle would cost you about $700.
> (Oh yes, and that "V" is "vee", not "5".) Now it is free and *not
> crippled*. In fact, it is extended as compared to the old ST/V Win
> 2.0.
Yeah, back then $700 was too much for me. Last time I checked
ST/V, it didn't impress me. Now it should, esp if it's free.
I'm not about to complain about the cost of a download.
It seems like not too long ago when I noticed prices of ST
systems in 4 figures. That was when I finally gave up on ST.
Now I'll take another look.
Thanks.
> At <http://www.objectconnect.com> you can find Smalltalk MT with even
> tighter Windows (95 and NT only) integration. It is still in beta,
> and you can get it free. The planned price is around $300. It
> provides a full OLE support and is basically equivalent to programming
> for Windows with Borland C++ 2.0. It can generate native code
> executables or DLLs, with functions exportable as if there were in C.
This sounds even more like what I'm after. I'll definitely grab
it at the weekend. I like what I've seen so far.
> It feels less like a full-blown Smalltalk, though, and the library is
> thinner.
Well, there's always a downside.
> At <http://www.intuitive.co.uk/dolphin> you can find a beta of Dolphin
> Smalltalk. It is closer to the classic Smalltalk in spirit, with a
> pretty full class library, compatible with the upcoming X3J20 ANSI
> standard, bytecode-interpreted. They promise a native code JIT
> compiler soon, as well as the OLE support plus some Internet-related
> buzz (sorry, I forgot what--don't care much). They also promise to
> set the price under $200.
I think I'll wait for the next beta, unless I can't wait.
> On the heavier side of the spectrum, there is LearningWorks
> <http://sumeru.stanford.edu/learningworks/>: a free Smalltalk using
> the virtual machine of VisualWorks (which is, in turn, the proverbial
> Balloon (Smalltalk-80) after 15 years of evolution). It is not a
> vehicle for conquering Windoze, though: it is multi platform, and
> support for each specific platform is weak. But it's free, and
> performance-wise it will beat the hell out of ST/V and Dolphin ST.
It's worth knowing.
> I personally was much happier to see CMUCL for Linux than any of the
> above. But if you are really into that Windoze dominance thing, a CL
> built and looking *at least* like Smalltalk/V would be a good step
> forward.
I might also prefer CMUCL, based on what I've read about it.
As for Linux, I dunno. Perhaps when I get a machine I can run
it on, I'll try it (again). I'm not "into" any OS. I just use
what I have to.
That just happens to be Win32 right now, not because I chose
it, but because it was there. I get it for free, most of my
other tools. The exceptions are the tools I use for personal
projects. _Those_ tools are either free or way too expensive
for my pocket, so a few of them are still on my wishlist.
> Where would it come from, though? I have no idea.
I've no idea, either. Franz? Harlequin? I dunno.
Anyway, many thanks for the links.
--
<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
We're living on a knife edge, looking for the ground -- Hawkwind
From: Bruce Stephens
Subject: Killer apps for Scheme/Lisp (was Re: Lisp is alive, was "Re: Common LISP: The Next Generation")
Date:
Message-ID: <wwaloe8c6bh.fsf_-_@cantecler.math.ruu.nl>
>>>>> "mathew" == mathew <····@pobox.com> writes:
> So reluctantly, we go back to the C/C++ Burger King, and they make
> us a cup of instant coffee with non-dairy creamer. And it tastes
> pretty foul, but it is at least roughly what we wanted.
And you can take the cup home, and use it to put water, sand, or
coffee beans in, for that matter (even if it might not be quite
perfect).
I don't know what Common Lisp's application domain might be.
Presumably it's popular in AI type things (expert systems and the
like)?
I think there's a big market for something like VB for Unix. I think
something Scheme-like is probably right for the task, and I have hopes
that the Guile project will do it.
At best, it might be an embeddable scripting language with a nice
clean interface to Unix functionality (like Perl/scsh has, but with
expect functionality too), and with widgets for X (probably Tk based,
so it's much cheaper than Motif, with more functionality), and
optimally compilable for speed, all with optional dynamic loading on
those systems which support it.
So you can have a cheap-and-cheerful instant coffee, in a nice robust
plastic cup. But you can also change the coffee and cup if you like
(and most of the time they'll interface correctly), and there's enough
power and flexibility to allow you to make your own mugs if that's
what you want (and if you do, other people can just reuse ones you
made earlier).
On the other hand, the cups will probably have small holes in them
initially, the coffee will taste almost but not quite like the coffee
you were used to, the ingredients list will be incomplete and out of
date, and if you try making mugs you'll need to learn again in a
year's time because it'll have changed. But at least the price will
be right.
--
Bruce Stephens | email: ··········@math.ruu.nl
Utrecht University | telephone: +31 30 2534630
Department of Mathematics | telefax: +31 30 2518394
P.O. Box 80010, 3508 TA Utrecht, The Netherlands
>>>>> "Thant" == Thant Tessman <·····@interramp.com> writes:
> Meanwhile, at the secret SML Labs, they don't have any coffee, but
> they have been working on a highly potent form of caffeine. And
> they don't have any cream or sugar, or cups, but they do have a
> drawer full of freshly sterilized syringes.
though turbo-charged, the SML concoction has a disgusting, medicinally
sweet aftertaste, somewhat like cough syrup. in the future, direct
injection will render this irrelevant, but in the mean time those who
use SML insist enduring the flavour is `good for the soul'.
--
balance
equilibrium
death
http://www.cs.cmu.edu/~spot
····@cs.cmu.edu
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
[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.
#\Erik
--
those who do not know Lisp are doomed to reimplement it
In article <················@arcana.naggum.no>,
Erik Naggum <····@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 <·······@ichips.intel.com>
Not speaking for Intel.
In article <··········@news.jf.intel.com>, ·······@ichips.intel.com (Mike
Haertel) wrote:
> In article <················@arcana.naggum.no>,
> 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.
Well, these machines offer a lot "memory protection" at the
lowest levels: object access is "secure". That is
Lisp machines usually don't access memory as a sequence
of bytes. Lispms have an idea about arrays, objects,
numbers, strings, ... These are all real objects and
not some faceless sequence of bits. So the Lisp processor
checks access and modification of the data in memory (also
checks array bounds, number overflow, ...).
Compare that to typical machines today. You need memory protection
for processes, otherwise these stupid C software would overwrite
arbitrary memory. Result: code duplication, ugly interprocess
communication mechanisms, limited reuse, ...
So protection of software via different **address** spaces is not really
a such a topic on Lispms.
Still, you are right, we would need some secure module mechanism.
A mechanism that
also allows fast unloading of software and that protects
some modules against arbitrary modification (something
that the Newton OS lacks, too - which otherwise is kind of a Lisp machine:
hardware assisted GC, objects, functions, symbols, ...).
> 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.
We need a Timewarp Lisp? ;-)
> Protected OS's where all programs get their own address space
> give you a crude way to do this: launch a new program.
Unfortunately different programs share common resources even
on memory protected Unix systems. Let some software have
a bug resulting in a crash of your X-Windows server, guess
how many of these other programs running on your display
stay up and running? Zero? Recently I have seen a machine
(an IBM RS/6000) crashing because a corrupt file system. Guess
how many processes stayed up? Zero? On of our SUNs currently
has twice a months an TCP/IP error. Result: a reboot.
Years ago there was an OS error on early SPARCstations.
In a millisecond the monitor changed to complete black,
and the machine went completely down. It was a bit weird.
Ironically it was caused by large Lisp systems.
Greetings,
Rainer Joswig
In article <·······················@news.lavielle.com> ······@lavielle.com (Rainer Joswig) writes:
>In article <··········@news.jf.intel.com>, ·······@ichips.intel.com (Mike
>Haertel) wrote:
>
>> In article <················@arcana.naggum.no>,
>> 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.
>
>Well, these machines offer a lot "memory protection" at the
>lowest levels: object access is "secure". That is
>Lisp machines usually don't access memory as a sequence
>of bytes. Lispms have an idea about arrays, objects,
>numbers, strings, ... These are all real objects and
>not some faceless sequence of bits. So the Lisp processor
>checks access and modification of the data in memory (also
>checks array bounds, number overflow, ...).
Here's something I tried the other day:
(values-list (sort (package-use-list (find-package :somename))))
How easy is it to use the :somename package after that?
[Hint: it depends on exactly how SORT works]
Treating all the objects involved as objects didn't stop me from
messing them up. (Note to ML fans: nor would static typing have
helped.)
Now, when I mess things up in certain ways, I like being able to
kill Lisp and start over w/o rebooting my machine -- just one of
the reasons I prefer the standard OS approach. (Yes, I know
I could probably patch up the :somename package in various ways.)
>Compare that to typical machines today. You need memory protection
>for processes, otherwise these stupid C software would overwrite
>arbitrary memory. Result: code duplication, ugly interprocess
>communication mechanisms, limited reuse, ...
>
>So protection of software via different **address** spaces is not really
>a such a topic on Lispms.
If I could get all the same benefits w/o separate address spaces _as
such_, that would be fine with me. But that was not what Lisp
machines provided.
Lisp machines were wonderful things, in many ways. I can see why
someone might prefer them to Unix and the like. But I happen to
have a different preference.
>> 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.
InterLisp undo? But it had a number of problems, and D-machines
were very easy to mess up.
>> Protected OS's where all programs get their own address space
>> give you a crude way to do this: launch a new program.
>
>Unfortunately different programs share common resources even
>on memory protected Unix systems. Let some software have
>a bug resulting in a crash of your X-Windows server, guess
>how many of these other programs running on your display
>stay up and running? Zero?
Almost all of them. Indeed, many are running on a different
machine.
In any case, so what if there are one or two programs that can
mess everything up? (OS kernel bugs will always be a problem,
for instance.) Does that mean there's no benefit to keeping
it down to those one or two programs?
>Recently I have seen a machine
>(an IBM RS/6000) crashing because a corrupt file system. Guess
>how many processes stayed up? Zero? On of our SUNs currently
>has twice a months an TCP/IP error. Result: a reboot.
>Years ago there was an OS error on early SPARCstations.
>In a millisecond the monitor changed to complete black,
>and the machine went completely down. It was a bit weird.
>Ironically it was caused by large Lisp systems.
So what? Surely you don't believe that imperfect implies useless.
-- jd
In article <···················@cogsci.ed.ac.uk>, ····@cogsci.ed.ac.uk
(Jeff Dalton) wrote:
> Now, when I mess things up in certain ways, I like being able to
> kill Lisp and start over w/o rebooting my machine -- just one of
> the reasons I prefer the standard OS approach. (Yes, I know
> I could probably patch up the :somename package in various ways.)
Stuff like this seemed to make the development of CLOS an
unpleasant experience. Developers had to reboot their
Lisp machines when they messed up their CLOS implementation.
But Ivory machines are booting faster than my Mac. My MacIvory 3
comes up in roughly three minutes. And I can assure you I
have to reboot a Mac **much** more often then my Lisp
machine. A nice feature of the MacIvory is that you
can reconnect to the Lisp system after a reboot of the host
Macintosh.
Interestingly the Apple Newton has similar open architecture.
Still a lot of people think of Newton OS 2.0 very stable
compared to Mac OS 7.5 (well, one might say, no problem -
System 7.5 is a disaster of software stability.)
> So what? Surely you don't believe that imperfect implies useless.
Hmm, most of the time (given the completely open architecture)
Lisp machine based development environments tend to keep
running. While developing software on a Lisp machine
this is not that much an issue for *me*. Other people's
experience may be different. And for me
it is today still surprising that these machines (Ivories) had
quite good overall performance when given enough memory.
Rainer Joswig
In article <···················@ms3.maus.de> ···········@ms3.maus.westfalen.de (Georg Bauer) writes:
>Hi!
>
>JD>How easy is it to use the :somename package after that?
>JD>[Hint: it depends on exactly how SORT works]
>
>Of course - if you use _destructive_ routines, it destructs the structure.
>Works as designed. That has nothing to do with memory-protection. If you
>intentionally hit the power-switch, the machine will go down, regardless of
>any memory protection scheme.
No kidding. So what?
My point was that type checks, including the run-time checks on Lisp
machines, don't prevent me from messing things up in the way I
described. Then, on a Lisp machine, all I have is the Lisp. If I
mess it up, I have to try to fix it, or I have to reboot or something
similarly "heavy". With an ordinary OS, I can quit Lisp and start it
again while everything else continues to work. Moreover, my other
Lisp processes continue to work. (Yes, I often run > 1 Lisp at once.)
Since they don't share memory, messing up a package in one doesn't
mess it up in the others.
>The point is, you can't access the memory and bypass the typechecking of
>the hardware - like you can do easily in assembler for example. Lisp
>doesn't have a notion of a pointer, but more of a reference - it's a
>reference to a location in memory (that can be changed, of course), but
>that always carries a typetag with it. So you can only access the location
>in appropriate ways - and sort is a appropriate way to access a list (and
>if it is defined as being destructive, it will sort it in-place).
But that's *why* the type check doesn't stop me from messing
things up in the way I described. That's why I picked SORT
for my example rather than something that would be stopped
by type checks.
>JD>Now, when I mess things up in certain ways, I like being able to
>JD>kill Lisp and start over w/o rebooting my machine
>
>No problem with Symbolics or Interlisp-D. In Interlisp-D for example I have
>several ways. One is the undo, ok, that has some limitations. Then there is
>the possibiliy to do a (logout t) and drop all changes and revert to the
>last saved state. Under Symbolics I can do my experiments in a
>incrementally world and just drop the last incremental part. Or on both
>systems I can use the versioning facilities (Interlisp-D only on the Xerox
>machines and only for files).
Undo is great when it works. Reverting to the last saved state is
too much like rebooting and gets me involved with saved states,
which I'd rather avoid.
>JD>the reasons I prefer the standard OS approach. (Yes, I know
>JD>I could probably patch up the :somename package in various ways.)
>
>No need to patch up the package, under normal conditions.
How else am I supposed to fix the package-use-list?
> And of course: if
>you do a rm -r -f on a unix machine while logged in as root, you surely
>will mess up the system a bit, too. If the user breaks the machine it will
>be broken. Nothing special about that - happens on all systems.
Come on. That's a _terrible_ argument. I shouldn't care about
getting rid of a problem because some other problems remain?
Your logic here escapes me, I must say.
And we've been here before:
>JD>So what? Surely you don't believe that imperfect implies useless.
>
>No. But it's a bit funny to allow your favored OS the imperfectness, but
>don't allow it the lisp-machines.
I allow it; I just don't _prefer_ it.
-- jd
[Mike Haertel]
| Some of us like the additional protection afforded by running different
| programs in different address spaces.
for lack of an existing more general term, let me call it "non-interference
between processes", and agree that it is a winner. however, this _need_
not be done through address spaces or separate processes -- as long as the
abstract functionality is available, it is not important how it is
implemented. also, you're not the only one to desire this, so there should
be a good chance that something smart will be done.
(I prefer to talk about programs as data objects and processes as programs
that have been loaded into an execution environment.)
| 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?
sure, this is a real problem. I think this needs to be solved by having
the source code available alongside any compiled definition, so it can be
reproduced upon request and stuffed in a file. that would also afford
looking at the real source code of a function, as opposed the source code
before a redefinition somewhere. it wouldn't take much memory to keep
track of these definitions if they mainly reside in files.
| 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.
yes! I'd love that. but this would require that all symbols had a history
of the previous contents of their various slots that worked independently
of scoping. what should the effect of undoing a macro definition or an
inlined function definition be? should everything be timestamped such that
code would know whether they had been outdated? should undo operations
cascade such that dependent definitions are undone, too? this could become
very messy.
| Protected OS's where all programs get their own address space give you
| a crude way to do this: launch a new program.
but... they give a process no chance to permanently affect their "parents"
unless the parent wants to and is prepared to listen. this is a very
serious liability, insofar as few parents actually listen to wisdom from
their kids. ahem, sorry. I mean, insofar as no general protocol has been
defined to handle this well. in other words, the backing up you desire
should be voluntary, not compulsory, as it usually is.
#\Erik
--
those who do not know Lisp are doomed to reimplement it
In article <················@arcana.naggum.no>,
Erik Naggum <····@naggum.no> wrote:
>| 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.
>
>yes! I'd love that. but this would require that all symbols had a history
>of the previous contents of their various slots that worked independently
>of scoping. what should the effect of undoing a macro definition or an
>inlined function definition be? should everything be timestamped such that
>code would know whether they had been outdated? should undo operations
>cascade such that dependent definitions are undone, too? this could become
>very messy.
If you wanted to linear rollback (i.e. roll back from time t to time t - k)
only, you could do it fairly easily by making copy-on-write snapshots
of the process image at periodic intervals, and replaying all process
I/O operations from the last snapshot prior to (t - k) to bring it
forward to exactly t - k. Barring major copying garbage collections,
most process pages would remain the same between snapshots. You could
do this easily with a halfway decent operating system. Unfortunately
we seem to be stuck with lousy OS's.
This approach would be simple and easy to get right. It could actually
be implemented at the OS level without reference to the underlying
program, so undo could be a general service. However it would only
support linear undo. Actually I guess it could be made to support
nonlinear undo by first rolling back linearly to a point before all
changes, and then replaying an edited version of the original input.
The approach you were thinking of (implementing undo within the Lisp
system itself, rather than externally as an OS service) would be less
storage intensive, but potentially more complex and bug-prone.
--
Mike Haertel <·······@ichips.intel.com>
Not speaking for Intel.
Erik Naggum <····@naggum.no> writes:
>for lack of an existing more general term, let me call it "non-interference
>between processes", and agree that it is a winner. however, this _need_
>not be done through address spaces or separate processes
Witness the Burroughs B6700 and its operating system.
All processes, whether "threads" within a single user job or separate
jobs from separate users (not that the operating system made _that_ much
distinction), inhabited the same tree-structured address space. User
programs just didn't interfere with each other, and didn't take down the
operating system when they crashed, despite sharing an address space.
>| 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.
>yes! I'd love that. but this would require that all symbols had a history
>of the previous contents of their various slots that worked independently
>of scoping. what should the effect of undoing a macro definition or an
>inlined function definition be? should everything be timestamped such that
>code would know whether they had been outdated? should undo operations
>cascade such that dependent definitions are undone, too? this could become
>very messy.
Interlisp _had_ this a long time ago. It's all in the IRM. I've used it.
For example, after doing
5-> (LOAD "{goedel}/usr/ok/foo")
I could
6-> UNDO 5
and the load was completely undone, restoring previous definitions if any.
I _liked_ Interlisp.
--
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.
Hi!
EN>I'd like to see some understanding of the
EN>_fact_ that one's "environment" may also be the boundaries of what one
EN>may think about, just like our languages may limit what we can think
EN>about.
Actually I _did_ say I want to produce standalone-executables for _my_
environment. I know Lisp-Machines and Lisp-Environments - I do have a
Symbolics and several Xerox 1186 running. But my actual environment is a
normal notebook under DOS, and therefore I need standalone-executables. If
you give me a Symbolics-notebook, things may change ;-)
Ok, I do have a Xerox environment for DOS, so I do have a lisp-environment
for my personal use (so my above statement is not fully correct) - but
since I write programs that other have to use, I have to obey their
limitations.
This has nothing to do with the appearance, it has something to do with
limitations the system throws upon us.
bye, Georg
[Mike Haertel]
> 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.
[Erik Naggum]
> yes! I'd love that. but this would require that all symbols had a
> history of the previous contents of their various slots that worked
> independently of scoping.
How about something along the lines of the SmallTalk "changes" file
concept? It keeps a log of all changes made, in clear text, and in
such a format that it can be read into a running SmallTalk system.
If you screw up badly, you go back to the previous snapshot of the
image, edit the "changes" file to remove or fix what you did wrong,
before you roll it back in.
Something like this might be feasible for Lisp -- but not easy.
-tih
--
Tom Ivar Helbekkmo
···@Hamartun.Priv.NO
* Erik Naggum wrote:
> [Mike Haertel]
> | 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.
> yes! I'd love that. but this would require that all symbols had a history
> of the previous contents of their various slots that worked independently
> of scoping. what should the effect of undoing a macro definition or an
> inlined function definition be? should everything be timestamped such that
> code would know whether they had been outdated? should undo operations
> cascade such that dependent definitions are undone, too? this could become
> very messy.
Actually you can do it with VM tricks. The Xerox Lisp machines had
something that did just this by changing what happened to dirty pages.
You could then stop & restart the machine and it would be back just
before the point when you changed the behaviour. It was very useful
for loading huge systems which were likely to trash the machine...
I think that some supercomputer-class machines also have/had
checkpointing of some kind, presumably done via VM, which enabled you
to recover long computations in the case of crashes.
--tim
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, ····@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
From: Andreas Bogk <·······@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
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 <·······@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
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
In article <·················@enea.se>
·············@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. ;-)
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
I have it at last: 'And She Closed Her Eyes', by Stina Nordenstam
·····@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: ·····@ilog.com
Ilog, Inc. tel: (415) 944-7130
1901 Landings Dr. fax: (415) 390-0946
Mountain View, CA, 94043 url: http://www.ilog.com/
Erik Naggum <····@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.
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...]
Thomas Kwong <········@wilshire.com> wrote in article
<·············@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 <············@wildcard.demon.co.uk> writes:
>
> In article <·······················@news.lavielle.com>
> ······@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
In article <··············@rtp.ericsson.se> Raymond Toy <···@rtp.ericsson.se> writes:
> In article <·······················@news.lavielle.com>
> ······@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
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?
·······@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.
······@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
* 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
In article <···············@staffa.aiai.ed.ac.uk>,
Tim Bradshaw <···@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
In article <··········@zeppelin.convex.com>
······@convex.com "David Boles" writes:
> 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.
Some Lisps put the code into an image file, so the code would not
be shared with other instances of the same app, nor shared with apps
written with the same Lisp and using similar runtime code.
> 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?
Lisp people often appear to me to be ignoring the probem, or
pretending its not _their_ problem. Well, if they're wondering
why so few people want to use Lisp, then it _is_ their problem.
Most people don't feel that they should be using Lisp. They feel
the same way about ML, but ML can avoid a lot of the overheads
that Lisp forces on the user at delivery time.
Perhaps ML people are not suffering from such a bad case of denial? ;)
> >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.
Most users don't want to run an enviroment like CMUCL. This
argument is the kind of denial that I'm refering to. Fact it,
most people want stand alone apps. That's what they're used to,
and that's what they'll get from non-Lisp developers.
Could it be a coincidence that Lisp is so unpopular? Why do so
many Lisp people insist on making all the assumptions made in
the CL dialect of Lisp? Why does it have to be "all or nothing"?
> >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.
People use the kind of OS they use _because they can_. If you
can show that they _can't_, then perhaps they might change.
Meanwhile, Lisp people stick their heads in the sand and pretend
it isn't happening. Tsk.
Roll on Dylan. Or ML. Or whatever. It might even be Scheme, if
only a suitable Scheme enviroment were available for a popular
platform, that corporate developers might accept, which they
might if it could produce native code binaries using shared
libraries (ie DLLs, if the OS is Windows).
Take a look at VB. The language may be hideous, but the enviroment
is _very_ popular. It gives developers what they want, and they
used it in large numbers. VC++ is less friendly, but it's also
very popular. A Lisp or ML enviroment with those kind of features
could be a killer.
Curiously, the MS proposal for VRML scripting was ActiveVRML,
a language not entirely dissimilar to ML. Too bad everybody
hated it, and while the popular candidate was something that
used Java. Which would be more friendly to people relatively
new to programming? I think MS got it right, but their pages
for ActiveVRML have either moved or been "revoked".
> 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.
I don't see why anyone should listen to me, if they can ignore
Gabriel, but I'm not going to stop saying this. So, there's at
least three of us. Hmm.
Could this be the end of Lisp as we know it...? See below.
--
<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
We're living on a knife edge, looking for the ground -- Hawkwind
Cyber Surfer wrote:
[lots of stuff removed...]
> Take a look at VB. The language may be hideous, but the enviroment
> is _very_ popular. It gives developers what they want, and they
> used it in large numbers. VC++ is less friendly, but it's also
> very popular. A Lisp or ML enviroment with those kind of features
> could be a killer.
> [lots of stuff removed...]
This brings up a very good point. I am a relative newcomer to Scheme so
bear with me.
It is possible for me, today, to download a package for some flavor of Unix or
Windows that gives me an environment similar to VB but with Lisp as the
implementation language instead of Visual Basic? My OS of choice is UNIX but I'd
even resort to Win/32 if necessary.
Can I write X-windows GUIs with this Lisp language? Can I use widgets implemented
in C or C++?
Is a compiler available as well as an interpreter?
I don't really care about language purity - think of me as the typical Turbo Pascal programmer
who was just happy to get a better language than the next guy.
-Ron Perrella
From: Matt Grice
Subject: Re: Common LISP: The Next Generation
Date:
Message-ID: <322f1671.44808029@news>
Ronald Perrella <········@mindspring.com> wrote:
>Cyber Surfer wrote:
>
>[lots of stuff removed...]
>> Take a look at VB. The language may be hideous, but the enviroment
>> is _very_ popular. It gives developers what they want, and they
>> used it in large numbers. VC++ is less friendly, but it's also
>> very popular. A Lisp or ML enviroment with those kind of features
>> could be a killer.
>> [lots of stuff removed...]
>
To me, this seems to be a big part of the problem with Lisp and
friends (Dylan, Scheme, etc.) It's mind boggling to me that you can
shell out several K$ for a Lisp package and get something with the
incredibly amateurish user interfaces that I see. It looks like the
UI code was created in 1985 and only maintained since then... perhaps
this is the case. No matter how technically good a package may be,
it's hard to take seriously products whose interface is not only ugly,
but also not even in conformance with the platform they are delivered
on.
On another note, it doesnt seem to me that Lisp (or similar language)
executable size should be too much of a problem any longer if managed
correctly. A VB or MFC app may look small, but is using a runtime DLL
which is quite large. This is not a new concept, but perhaps one that
vendors have failed to capitalize on. You sneak that library in and
from then on everybody thinks your programs are small. :)
In article <·················@news> ······@iastate.edu "Matt Grice" writes:
> >Cyber Surfer wrote:
> >
> >[lots of stuff removed...]
> >> Take a look at VB. The language may be hideous, but the enviroment
> >> is _very_ popular. It gives developers what they want, and they
> >> used it in large numbers. VC++ is less friendly, but it's also
> >> very popular. A Lisp or ML enviroment with those kind of features
> >> could be a killer.
> >> [lots of stuff removed...]
> >
>
> To me, this seems to be a big part of the problem with Lisp and
> friends (Dylan, Scheme, etc.) It's mind boggling to me that you can
> shell out several K$ for a Lisp package and get something with the
> incredibly amateurish user interfaces that I see. It looks like the
> UI code was created in 1985 and only maintained since then... perhaps
> this is the case. No matter how technically good a package may be,
> it's hard to take seriously products whose interface is not only ugly,
> but also not even in conformance with the platform they are delivered
> on.
Yes, "cultural assimilation" is vital IMHO. Users of certain
platforms understand a set of GUI conventions and they then
expect every app to obey those conventions. It's confusing when
an app uses the conventions of another platform, or just ignores
all conventions and sets its own.
When you want cross-platform support for an app, this may be
forgivable to use a subset of conventions common to the supported
platforms, but it'll still be a problem for users.
> On another note, it doesnt seem to me that Lisp (or similar language)
> executable size should be too much of a problem any longer if managed
> correctly. A VB or MFC app may look small, but is using a runtime DLL
> which is quite large. This is not a new concept, but perhaps one that
> vendors have failed to capitalize on. You sneak that library in and
> from then on everybody thinks your programs are small. :)
Exactly. I've been saying that for some time. The P-system used
this technique! I find it hard to accept that modern Lisps can't
also do it. This is one of the reasons why C++ is dominating the
software industry. C may seem like a less sophisticated language
than Lisp, but C compilers for platforms that support shared
libraries, like Windows, have used it for some years now.
If Lisp is so much better than C/C++, why can't it also do this?
I don't think it's the language, tho there is a culture that may
prefer static linking to dynamic linking. In fact, you can find
people advocating running code _in the development enviroment_!
Most people would be horrified by this idea, but for Lisp people
it seems natural. It's okay for those of us who program in Lisp,
but most users don't even want a command prompt, never mind a
Lisp listener.
Perhaps it's this attitude that's holding Lisp back. That's why
I'm becoming more interested in alternatives, like Dylan and ML.
There's more of a "can do" attitude, and less of a "well, this
is how we've always done it" attitude. Sorry, but this kind of
thinking is not helping Lisp win friends.
--
<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
We're living on a knife edge, looking for the ground -- Hawkwind
In article <·················@news>, ······@iastate.edu (Matt Grice) wrote:
> shell out several K$ for a Lisp package and get something with the
> incredibly amateurish user interfaces that I see.
Your examples?
Do you think Apple Dylan has an "incredibly amateurish user interface"?
This stuff has been created with MCL. In my view it is something
more developers really would like to have.
Harlequin LispWorks? "An incredibly amateurish user interface"?
Xerox's Lisp stuff? MCL? Symbolics' Dynamic Windows?
In fact people have built some very nice user interface stuff in Lisp
(well, sadly the opposite is also true).
> this is the case. No matter how technically good a package may be,
> it's hard to take seriously products whose interface is not only ugly,
> but also not even in conformance with the platform they are delivered
> on.
In fact this is a problem. On the other hand there are some packages
which have enabled quite different user interfaces (-> CLIM)
which are cross platform. This may be desirable for some software.
> On another note, it doesnt seem to me that Lisp (or similar language)
> executable size should be too much of a problem any longer if managed
> correctly. A VB or MFC app may look small, but is using a runtime DLL
> which is quite large. This is not a new concept, but perhaps one that
> vendors have failed to capitalize on. You sneak that library in and
> from then on everybody thinks your programs are small. :)
Well, I would like to see Dylan and MCL shared libraries
as part of the MacOS. I think Lisp systems have
to implement services that really belong to
the operating system (like some sort of memory management
using GC). Both systems actually are using shared libraries.
If you ask Digitool for it, you may even be able
to compile your Lisp stuff to a shared library.
So this has already been done. There is also a standalone
app creator (for MCL 3.0), that doesn't include the development
environment into your application. So this has been done.
Other Lisp systems have delivery tools, too. There is
a price to pay for having a sophisticated *integrated* development
environment and wishing to deliver small executables.
But who says that you can't import a Lisp to C compiler
into your development environment (like CLICC) and
create small Lisp applications. But they would lack all
features that makes Common Lisp "dynamic".
Apple Dylan takes a different approach than most Lisp-like
development environments. There is an integrated
development environment and there are applications built
with the IDE. They talk via interprocess communication - you even
can have IDE and application running on different machines.
Crashing the machine where the application in development is
running won't crash your IDE.
You even can connect with your IDE to a delivered application,
inspect it, download code, execute code, debug it,
whatever you like (yes, you can disable that).
A local database stores the source records and can be queried
in a wide variety of ways.
There is really no reason for Lisp users and implementors
to be depressed and to be overly defensive. A more aggressive
way of promoting this stuff is necessary. Without the current
confusion that is part of the Lisp landscape. Period.
Rainer Joswig
In article <·······················@news.lavielle.com> ······@lavielle.com (Rainer Joswig) writes:
>Other Lisp systems have delivery tools, too. There is
>a price to pay for having a sophisticated *integrated* development
>environment and wishing to deliver small executables.
>But who says that you can't import a Lisp to C compiler
>into your development environment (like CLICC) and
>create small Lisp applications. But they would lack all
>features that makes Common Lisp "dynamic".
Why would they? Many of the dynamic features are just assignment,
after all.
-- jd
In article <···················@cogsci.ed.ac.uk>, ····@cogsci.ed.ac.uk
(Jeff Dalton) wrote:
> In article <·······················@news.lavielle.com>
······@lavielle.com (Rainer Joswig) writes:
> >create small Lisp applications. But they would lack all
> >features that makes Common Lisp "dynamic".
>
> Why would they? Many of the dynamic features are just assignment,
> after all.
What makes Common Lisp a "dynamic" language?
I was thinking about:
- eval
- compile
- class definition at runtime
- class redefinition at runtime
- subclassing at runtime
- changing the class of an object at runtime
stuff like that.
Rainer Joswig
In article <·············@mindspring.com>
········@mindspring.com "Ronald Perrella" writes:
> Cyber Surfer wrote:
>
> [lots of stuff removed...]
> > Take a look at VB. The language may be hideous, but the enviroment
> > is _very_ popular. It gives developers what they want, and they
> > used it in large numbers. VC++ is less friendly, but it's also
> > very popular. A Lisp or ML enviroment with those kind of features
> > could be a killer.
> > [lots of stuff removed...]
>
> This brings up a very good point. I am a relative newcomer to Scheme so
> bear with me.
I'll be patient. I'm a relative newcomer myself, having only
discovered Lisp about 10 years ago. I didn't get much experience
of Lisp during that time, as the Lisps available to me were
either of limited value (e.g. XLISP), or were only available
for a short duration (while I had that particular machine).
> It is possible for me, today, to download a package for some flavor of Unix or
> Windows that gives me an environment similar to VB but with Lisp as the
> implementation language instead of Visual Basic? My OS of choice is UNIX but
> I'd
> even resort to Win/32 if necessary.
I don't know of any Lisp for Windows that gives you an enviroment
like VB, but I'd certainly love to find one. I'd also be happy if
the language was ML instead of Lisp, so long as the Windows support
was strong enough. A bytecoded implementation, like CLISP or Caml
Light, would be perfect (VB is also bytecoded BTW).
I can't help you with Unix, as my only experience with it has been
on a very old 386 PC, for just an hour, or via telnet to a web server.
While I know of various Lisps for Unix that support X Windows, I've
never seen them in use, so I can't comment on them.
> Can I write X-windows GUIs with this Lisp language? Can I use widgets
> implemented
> in C or C++?
Perhaps Garnet and CLISP, or Scheme/Tk, will be what you're looking
for, but I can only guess.
> Is a compiler available as well as an interpreter?
This depends on the implementation. CLISP compiles Common Lisp code
to bytecodes, while Scheme 48 does the same for Scheme code. I've
used CLISP, but only for DOS, so I say what it's like with X Windows.
> I don't really care about language purity - think of me as the typical Turbo
> Pascal programmer
> who was just happy to get a better language than the next guy.
Yeah, I'll be happy with something better than C++, but it's
very subjective. Some may say that Perl/Tk is better than C++,
but I doubt I'll like it. Alternately, there's Java, which is
at least platform independant.
I'm hoping that Java can be used to build friendly front-ends
to existing Lisps, like CLISP, MIT Scheme, etc. That way, any
effort put into GUI support for a Lisp for single platform,
like Unix, can then be also used by that Lisp for any other
platform. Unless there's a 2nd MIT Scheme beta released this
year, it still only gives us a very plain Windows. If the UI
was written in Java, using sockets to talk to MIT Scheme, then
it would be easier to change this.
MIT Scheme isn't alone in using such a minimal user interface.
Right now, many non-commercial languages available for Windows
seem to give us only a very basic Windows support. This is fair
enough, as you can't get a free lunch. On the other hand, it
can give developers used to commercial Windows development tools
a bad impression. This is why I'd also recommend that you look
at the demos for the commercial Lisps.
Anyway, the Lisp FAQ will tell you what's available and where
you can get it from. The above comments are purely subjective. ;-)
--
<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
We're living on a knife edge, looking for the ground -- Hawkwind
Ok, so how about combining a portable GUI toolkit such as WxWindows or V
into Scheme? I can see that the problem here is choosing between enlarging
the language or extending it with libraries. However, without a choice,
scheme dies on the vine.
Also, you have to wonder about the language if the only examples of production
code are as esoteric as the ones previously mentioned (BTW the popular game
ABUSE seems to be coded in lisp).
As for using ML instead of Scheme or some other language such as Dylan, I have
to admit that this sounds like a cop-out -- I think we really want to try
and give Lisp a chance.
When I was still an undergrad, we always heard mythical stories about the
incredible power of Symbolics lisp-machines. Has it been that difficult to
mimic that environment on Unix or Win/32 ? Does anyone who has used one of
these machines have a comment on this?
Has Lisp become obsolete like Forth, having been put out of business by the
ever faster and better hardware?
-Ron Perrella
In article <············@mindspring.com>
········@mindspring.com "Ronald Perrella" writes:
> As for using ML instead of Scheme or some other language such as Dylan, I have
> to admit that this sounds like a cop-out -- I think we really want to try
> and give Lisp a chance.
The point I've been making is that "Lisp" as it exists todat doesn't
have a chance. What distingishes Dylan is the support _in the language_
for dynamic linking the runtime code, thru class sealing.
> When I was still an undergrad, we always heard mythical stories about the
> incredible power of Symbolics lisp-machines. Has it been that difficult to
> mimic that environment on Unix or Win/32 ? Does anyone who has used one of
> these machines have a comment on this?
Most Windows developers won't want the development enviroment to
be available at runtime. That idea is contrary to the way that
Windows users expect a machine to behave.
> Has Lisp become obsolete like Forth, having been put out of business by the
> ever faster and better hardware?
Forth is still alive, and there are still commercial Forth systems
being sold. It just has a very low profile. Well, it always had a
low profile, but now it could be a lot lower. The profile of C/C++
is certainly a _lot_ higher than Forth's.
--
<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
We're living on a knife edge, looking for the ground -- Hawkwind
In article <············@wildcard.demon.co.uk>,
············@wildcard.demon.co.uk wrote:
> > When I was still an undergrad, we always heard mythical stories about the
> > incredible power of Symbolics lisp-machines. Has it been that difficult to
> > mimic that environment on Unix or Win/32 ? Does anyone who has used one of
> > these machines have a comment on this?
>
> Most Windows developers won't want the development enviroment to
> be available at runtime. That idea is contrary to the way that
> Windows users expect a machine to behave.
What does make you think, that there hasn't been delivery
versions of Lisp machines?
Rainer Joswig
From: Will Ware
Subject: Re: Common LISP: The Next Generation
Date:
Message-ID: <DxCM4G.ALH@world.std.com>
Ronald Perrella (········@mindspring.com) wrote:
: Ok, so how about combining a portable GUI toolkit such as WxWindows or V
: into Scheme?
This has been done. Check out MrEd, developed by Matthew Flatt at Rice
University. I'm trying to pull the URL from memory, I think it's
something like
http://cs.rice.edu/PLT/mred/ or
http://cs.rice.edu/pub/PLT/mred/
If those don't work, try one of the standard search engines. MrEd is a
combination of WxWindows with MzScheme. MzScheme and MrEd run on MSWin
(all flavors), Unix/X, and the Mac.
--
-------------------------------------------------------------
Will Ware <·····@world.std.com> web <http://world.std.com/~wware/>
PGP fingerprint 45A8 722C D149 10CC F0CF 48FB 93BF 7289
From: CsO
Subject: Re: Common LISP: The Next Generation
Date:
Message-ID: <3233D05C.DC7@gecm.com>
Will Ware wrote:
| Ronald Perrella (········@mindspring.com) wrote:
| : Ok, so how about combining a portable GUI toolkit such as WxWindows
or V
| : into Scheme?
| This has been done. Check out MrEd, developed by Matthew Flatt at Rice
| University. I'm trying to pull the URL from memory, I think it's
Try
<http://www.cs.rice.edu/CS/PLT/packages/mred/index.html>
Ronald Perrella wrote:
[...]
> As for using ML instead of Scheme or some other language such as Dylan,
> I have to admit that this sounds like a cop-out -- I think we really
> want to try and give Lisp a chance. [...]
If you look past the syntax, ML feels more like Scheme than Scheme feels
like Common Lisp. And Dylan is mainly Scheme with a compiler-supported
object system based on generic functions. It even used to look like
Scheme.
I don't think there is any coping-out going on here.
-thant
--
Thant Tessman <·····@shoreline-studios.com>
On Wed, 04 Sep 96 14:47:37 GMT, Cyber Surfer <············@wildcard.demon.co.uk>
wrote:
>Curiously, the MS proposal for VRML scripting was ActiveVRML,
>a language not entirely dissimilar to ML. Too bad everybody
>hated it, and while the popular candidate was something that
>used Java. Which would be more friendly to people relatively
>new to programming? I think MS got it right, but their pages
>for ActiveVRML have either moved or been "revoked".
Too bad they had given up on it... I liked it from the first sight. Some VRML
2.0 gurus I talked with about ActiveVRML some time ago told me that there were
two main reasons against AVRML. First, the language lacked some non-obvious but
really needed features and there was no easy way to add them (I don't remember
which ones for now) and MW did not have any trouble with these. Second, AVRML
was all behaviour and some shapes, while the committee preferred an evolutional
road and made the shapes the emphasis of VRML2 while leaving behaviour for the
domain of external scripting languages.
Oleg
On 02 Sep 1996 11:47:32 +0100, Tim Bradshaw <···@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
Tim Bradshaw <···@aiai.ed.ac.uk> writes:
>Just because compiling a stand alone executable has always been the
>Unix way doesn't mean it has to be like that.
I am reading this in comp.lang.dylan.
Given the origins of Dylan, I think it is reasonable to point out that
in Apple's "other" dynamic object-oriented language, NewtonScript, it
genuinely isn't like that. A NewtonScript application joins a whole
bunch of other stuff, and expects to place incremental revisions over
a large bunch of useful stuff already sitting in ROM.
In fact they went for a very powerful Lisp/Self-like language precisely
*because* they wanted small applications to run on a small machine.
--
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.
* Cyber Surfer wrote:
> In article <·······················@news.lavielle.com>
> ······@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
In article <···············@staffa.aiai.ed.ac.uk>
···@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
We're living on a knife edge, looking for the ground -- Hawkwind
In article <············@wildcard.demon.co.uk>,
············@wildcard.demon.co.uk wrote:
> In article <···············@staffa.aiai.ed.ac.uk>
> ···@aiai.ed.ac.uk "Tim Bradshaw" writes:
>
> > >> Btw., CL-HTTP (from the MIT AI Lab) is the first HTTP 1.1 server.
> >
> > > Excellent. I'll point that out next time somebody claims that
> > > Lisp can't do anything useful. BTW, can it run under NT?
> >
> > Yes I think so. There is a version that runs under ACL for windows
> > and that runs under NT.
You may consider undertaking a coding project to help advance
CL-HTTP: http://wilson.ai.mit.edu/cl-http/projects.html .
Give the C weenies something to think about. There are
many interesting projects for students. There is a lot
to learn. And more to come. Better start now.
Just saw a television report from "CeBIT Home" (german computer fair
with some 200000 visitors in five days). The big topic was "multimedia"
and the web. Guess what they showed in this TV report?
Henry Lieberman's browsing assitent for Netscape. Agents as the
next thing beyond systems like Yahoo and AltaVista.
The software is, guess what, written in Macintosh Common Lisp.
And it was watching out for some pages about "programming
by example" and Lisp.
Last week I bought a german newspaper. They had a story about
how computers changed our live. They had a **nice** picture.
On the left a Connection Machine and on the right a Symbolics
Lisp machine console. Gets me thinking, where are we ten years
later? (Btw., I contacted a friend at the newspaper. I
got a scan and will donate it later to the "Online Symbolics
Museum" at http://www.brightware.com/~rwk/symbolics/ .).
On CeBIT Home the japanese company Toshiba presented a tiny
computer (the size of a paperback): 640x480 16bit color TFT
screen, DX4 75 like processor, 8-20 MB RAM, 270 MB disk,
PCMCIA slot. This thing was really small - a sub sub notebook.
It runs Windows 95. You think CL is to large? To large for what?
Better start coding now and produce some useful (Lisp) software.
Greetings,
Rainer Joswig
In article <·······················@news.lavielle.com>
······@lavielle.com "Rainer Joswig" writes:
> > > Yes I think so. There is a version that runs under ACL for windows
> > > and that runs under NT.
>
> You may consider undertaking a coding project to help advance
> CL-HTTP: http://wilson.ai.mit.edu/cl-http/projects.html .
> Give the C weenies something to think about. There are
> many interesting projects for students. There is a lot
> to learn. And more to come. Better start now.
I assume that you're suggesting that I port CL-HTTP? I'm not
a student, and I doubt that I'm qualified to port CL-HTTP. Also,
I've no particular use for CL-HTTP, as I've explained. It might
be an interesting exercise, but there are far better ways for
me to use my time.
Like it or not, MS are full of C/C++ weenies, so I have to be
one, too. :-( Take a look at the kind of stuff that MS are offering
to C/C++ programmers, and see how much of it can be used in ACL.
Can I write CGI code in Lisp? Not yet. That's why I started writing
a "toy" Lisp to C compiler.
> Just saw a television report from "CeBIT Home" (german computer fair
> with some 200000 visitors in five days). The big topic was "multimedia"
> and the web. Guess what they showed in this TV report?
> Henry Lieberman's browsing assitent for Netscape. Agents as the
> next thing beyond systems like Yahoo and AltaVista.
> The software is, guess what, written in Macintosh Common Lisp.
> And it was watching out for some pages about "programming
> by example" and Lisp.
Excellent. Too bad so few people use Macs. Imagine that Apple
runs into trouble. You can bet that some people will look for
mistakes to blame Apple's failure on. Lisp sounds like it could
be a perfect scapegoat. Let's hope that doesn't happen.
Meanwhile, most of the world uses Windows. Making a hit on
_that_ platform would do far more for Lisp than on the Mac.
> Last week I bought a german newspaper. They had a story about
> how computers changed our live. They had a **nice** picture.
> On the left a Connection Machine and on the right a Symbolics
> Lisp machine console. Gets me thinking, where are we ten years
> later? (Btw., I contacted a friend at the newspaper. I
> got a scan and will donate it later to the "Online Symbolics
> Museum" at http://www.brightware.com/~rwk/symbolics/ .).
Excellent. I remember that Germany has also been a place for
Atari ST users. The first native code Lisp compiler I used was
on that machine. However, I don't use an ST anymore...
Is anyone still buying Connection Machines and Symbolics Lisp
machines? I mean the hardware, not software only products, like
Open Genera. What was the story, BTW?
> On CeBIT Home the japanese company Toshiba presented a tiny
> computer (the size of a paperback): 640x480 16bit color TFT
> screen, DX4 75 like processor, 8-20 MB RAM, 270 MB disk,
> PCMCIA slot. This thing was really small - a sub sub notebook.
> It runs Windows 95. You think CL is to large? To large for what?
> Better start coding now and produce some useful (Lisp) software.
I don't think _CL_ is too large - that's just a language.
I'm concerned about the image size, simply because I know
that the clients who use my software are concerned about
such things. If they ask for software that can be delivered
on a single floppy, then that's what they get. I'm also
concerned about support for things like OCX, as there are
OCX controls that I need to use. If Lisp can't use OCX,
then I can't use Lisp.
In case I didn't make it clear before, I don't choose the
software I get paid to write. If you want to, you can only
write software that Lisp implementations can deliver. That
could be why so few apps use Lisp, and why those that do
have such a low profile.
If you're saying that we should choose Lisp and then
the software we can write with it, then I'd suggest that
you're ignoring the problem by sticking your head in the
sand. I'm writing multimedia Windows apps, not by choice
but _because I can_, and not insignificantly because I
get paid to. I know that I'm not unique in this respect.
If I could get paid to write something else, in Lisp,
then that's what I'd be doing. I'm working on it. I'm
rather unusual in _that_ respect. If I succeeded, then
I might say I was one of the lucky elite.
Do you really think that elitism helps Lisp? I don't.
I think it's at the heart of the problem. If you can live
with most people thinking that Lisp is dead, then this
isn't a problem for you. I'm dealing with it by doing
something very different, by looking for alternatives
like Dylan. Take a _close_ look at Dylan. _That's the
kind of Lisp I want, and in a few years I might get it.
--
<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
We're living on a knife edge, looking for the ground -- Hawkwind
In article <············@wildcard.demon.co.uk>,
············@wildcard.demon.co.uk wrote:
> I assume that you're suggesting that I port CL-HTTP?
No, not necessarily. But whoever wants to do some
Lisp and WWW coding should look at
http://wilson.ai.mit.edu/cl-http/projects.html .
There are a lot of interesting ideas (IMHO).
> Can I write CGI code in Lisp? Not yet.
Why not? Has been done. Hey, what makes you think
you can't write CGI scripts in Lisp?
> Excellent. Too bad so few people use Macs.
Yep, only some ten millions users. Not much.
> Meanwhile, most of the world uses Windows. Making a hit on
> _that_ platform would do far more for Lisp than on the Mac.
Windows doesn't interest me personally that much. Still,
a small, fast and sexy CL implementation for Windows (NT)
won't hurt and I'd surely would have a usage for it. ;-)
> such things. If they ask for software that can be delivered
> on a single floppy, then that's what they get.
Floppies are anachronisms. I'm not using floppies very often
these days. Which games are still being delivered on floppies?
Some Mac games are being delivered on three CD-ROMs.
> like Dylan. Take a _close_ look at Dylan.
I have Apple Dylan on my machine. Still CL
is much more stable, has a larger user base, has
tons of code, is supported, ... and does useful work for
me. I'd like to see CL advancing. (And Dylan lacks
Lisp's syntax! ;-) )
> _That's the
> kind of Lisp I want, and in a few years I might get it.
Why is it that PC users get this stuff years later?
**************************************************************
So what can we learn? What are other users or would be users
thinking? Seems like *some* PC users are not satisfied with
current choices. Other opinions? Seems like a lot of CL users
work on Unix, Macs or even Lispms. Is this perception correct?
Shouldn't the PC market be *much* larger than the others
combined?
**************************************************************
Rainer Joswig
In article <·······················@news.lavielle.com>, ······@lavielle.com
says...
>
>In article <··········@grandcanyon.binc.net>, ······@mailbag.com (William
>A. Barnett-Lewis) wrote:
>
>> We have been specific in saying over and over. Those of us who have to
>program
>> for the PC _need_ a truely windows aware Lisp: we need OCX capability, true
>> OLE compatability, dynamic linking to the system's DLLs, and for a price
>> somewhere low side of $500.
>
>Sounds interesting. If I'd use a PC I'd certainly would like
>to have it. Would there be a market for it? How big?
>What do you think?
>
>Rainer Joswig
Look at like this: What kind of market did Borland find for Delphi (sp?),
a rehash of Turbo Pascal that actually works & better than VB at that. It won't
be able to take the whole windows developer market, but even a few percentage
points of market share equals lots of $$$$ very quickly. I'd love to ditch VB &
VC++. Right now, I can't; no other tool will do what I need on a day to day
basis. This is the most aggrivating thing about it; the market exists, but not
where they ( the lisp companies) are looking.
William
Bill Newman wrote:
[lots deleted.]
>
> It's IMHO a tragedy that John Ousterhout didn't use Scheme instead of
> a warmed-over shell language as the basis of tcl. I think the result
> would probably have been even more successful than tcl/Tk: the
> command-line syntax could be the same (by eliding the outer
> parentheses if necessary), but the programming semantics would be
> enormously improved. With large programs in the native language a
> practical proposition, who knows how far it could have gone?[more deleted.]
>
> Bill Newman
Yes, it's a tragedy but one has to remember that John was probably not out to
save the world. He wrote a tool that was useful to his folks and figured others
might want it as well, as I far as I can tell from his book anyway.
TCL does have two qualities that made it good for his purposes:
1) it is easy to link with outside C programs and to call from C.
2) it resembles the Unix shell enough to allow "wish" and "tclsh" to function as
shells.
that seems like all he wanted...
-Ron Perrella
From: Bruce Tobin
Subject: Re: Common LISP: The Next Generation
Date:
Message-ID: <324A8632.2C5E@iwaynet.net>
William A. Barnett-Lewis wrote:
>
> We have been specific in saying over and over. Those of us who have to program
> for the PC _need_ a truely windows aware Lisp: we need OCX capability, true
> OLE compatability, dynamic linking to the system's DLLs, and for a price
> somewhere low side of $500.
I agree in principle, but you have to remember that OLE is,
deliberately, a moving target. The only company that has
historically been able to keep up with MS and ship OLE stuff
in a timely fashion is Borland, and even they have been slipping
lately. Besides, in a real environment (such as Delphi) you almost
never need to use OCX controls. It's easier and cheaper to
extend the stuff that's built into the environment, and the result
performs a lot better. As for the price, VB Enterprise was
considerably more expensive than $500 last time I looked.
Anyway, doesn't Allegro Win already provide dynamic linking to
DLL's?
> Until this happens, Lisp will remain what it is:
> a very good language for building huge monolithic vertical apps on large
> systems. And I'll still be stuck with Visual Basic because my wife and I happen
> to like to eat evry day.
>
> >Rainer Joswig
>
> William Barnett-Lewis
In article <·············@iwaynet.net> ······@iwaynet.net "Bruce Tobin" writes:
> William A. Barnett-Lewis wrote:
> >
> > We have been specific in saying over and over. Those of us who have to program> > for the PC _need_ a truely windows aware Lisp: we need OCX capability, true
> > OLE compatability, dynamic linking to the system's DLLs, and for a price
> > somewhere low side of $500.
>
> I agree in principle, but you have to remember that OLE is,
> deliberately, a moving target. The only company that has
> historically been able to keep up with MS and ship OLE stuff
> in a timely fashion is Borland, and even they have been slipping
> lately. Besides, in a real environment (such as Delphi) you almost
> never need to use OCX controls. It's easier and cheaper to
> extend the stuff that's built into the environment, and the result
> performs a lot better. As for the price, VB Enterprise was
> considerably more expensive than $500 last time I looked.
That fine so long as all you need are very simple things. It's the
more specialised controls that are so valuable.
> Anyway, doesn't Allegro Win already provide dynamic linking to
> DLL's?
Can ACL for Windows handle callback functions? The docs in the Lite
version impliy this, but I can't find any details. If it's possible
to use an OCX that way, it would still require adding a lot of code.
That takes time which many programmers won't have. So, they'll look
at ACL, they'll look at VC++, and choose the one that does what they
need right after you install it.
> > Until this happens, Lisp will remain what it is:
> > a very good language for building huge monolithic vertical apps on large
> > systems. And I'll still be stuck with Visual Basic because my wife and I
> happen
> > to like to eat evry day.
Painfully true. It's little good saying, "If I add this, it'll do
what we need." Deadlines can make this impractical. Saying that it's
possible in theory doesn't sell boxes. While MS will always have
an edge on their platforms, so do vendors like Borland, Symantec,
Watcom, and many others. Lisp vendors are way down the list.
A few of us will be priviledged enough to not have to worry about
this. I'll gladly write Lisp code for food, but nobody is asking
me to, or any other Windows developer I know. I blame memes from
MS for this sad state of affairs, and a complacency from the Lisp
community. On the other, to be fair, it looks like not many Lisp
people are using Windows, so why care?
I only care coz I've use Lisp for some of my own projects, and
I'd love to use it for the stuff I get paid for. Nobody I know
gives a shit about that, but it doesn't change how I feel. I still
prefer Lisp every time - it just makes no difference when I have
a deadline to meet, as it's always easier to use C/C++ instead.
It should be different, but the tools available for C/C++ (for
Windows) do actually make it _easier_. Go figure.
Yes, I should be writing Lisp code to make it easier to do these
things in Lisp, but as I've said repeatadly, I'm not paid to write
Lisp code - how do I get the time to use Lisp? How do we convince
the idiots who insist one creating and _selling_ so many C++ tools
that they should be using Lisp? While those tools exist in such
abundance, developers will be expected to use them.
Would anyone like to form a Lisp Developers Revolutionary Front,
and bomb the next C++ developers convention? ;-) I'm only asking
because it apears that the Lisp software available today ain't
good enough to stop these bastards. I don't think that bombs will,
either - there's too much money backing them.
Still, I can't shake the feeling of heresy whenever I think about
using Lisp to write software which so many people say MUST be written
in C++. Why is that? I know Lisp can, at least in theory, be used
to write exactly the same software as C++, but how do I convince
somebody who doesn't know Lisp as well as I do that this is possible?
If somebody can tell me that CGI code using ISAPI, or a general DLL,
or perhaps even an ActiveX control, can be written using Brand X,
then I'll be happy to buy a copy and use it to convince other people
that it can be done.
Meanwhile, please excuse me if I still use C++. <hawk, spit>
--
<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
We're living on a knife edge, looking for the ground -- Hawkwind
············@wildcard.demon.co.uk (Cyber Surfer) writes:
A few of us will be priviledged enough to not have to worry about
this. I'll gladly write Lisp code for food, but nobody is asking
me to, or any other Windows developer I know. I blame memes from
MS for this sad state of affairs, and a complacency from the Lisp
community. On the other, to be fair, it looks like not many Lisp
people are using Windows, so why care?
Why memes from MS? MS only jumped on the C++ bandwagon after other companies
did. MS is not the source of all of the software world's ills. In fact, I
seem to remember some (apocryphal?) quote from Bill Gates about Dylan, which
was very positive.
I only care coz I've use Lisp for some of my own projects, and
I'd love to use it for the stuff I get paid for. Nobody I know
gives a shit about that, but it doesn't change how I feel. I still
prefer Lisp every time - it just makes no difference when I have
a deadline to meet, as it's always easier to use C/C++ instead.
It should be different, but the tools available for C/C++ (for
Windows) do actually make it _easier_. Go figure.
Yes, I should be writing Lisp code to make it easier to do these
things in Lisp, but as I've said repeatadly, I'm not paid to write
Lisp code - how do I get the time to use Lisp? How do we convince
the idiots who insist one creating and _selling_ so many C++ tools
that they should be using Lisp? While those tools exist in such
abundance, developers will be expected to use them.
This worldview contains some very strange reasoning. In fact, you paint
yourself an idiot, just like those C++ vendors, since you admit yourself
that you choose to use C++ in spite of its perceived flaws. I suppose
the tool vendors share your view that there is no money in Li$p.
Would anyone like to form a Lisp Developers Revolutionary Front,
and bomb the next C++ developers convention? ;-) I'm only asking
because it apears that the Lisp software available today ain't
good enough to stop these bastards. I don't think that bombs will,
either - there's too much money backing them.
Your money too, apparently! Why not buy a Lisp compiler, and start
writing apps, or libraries that make programming in Windows easier, or
whatever?
Still, I can't shake the feeling of heresy whenever I think about
using Lisp to write software which so many people say MUST be written
in C++. Why is that? I know Lisp can, at least in theory, be used
to write exactly the same software as C++, but how do I convince
somebody who doesn't know Lisp as well as I do that this is possible?
Why be so concerned with convincing people? Use Lisp, do it better and faster
and with fewer bugs and comparable performance, and smart programmers will
be convinced. If you can't, maybe you should be open to the possibility that
C++ (or VB, or Delphi, or Java, or ...) is better for some things.
-- Brian
In article <····················@sccm.Stanford.EDU>
······@sccm.stanford.edu "Brian Rogoff" writes:
> Why memes from MS? MS only jumped on the C++ bandwagon after other companies
> did. MS is not the source of all of the software world's ills. In fact, I
> seem to remember some (apocryphal?) quote from Bill Gates about Dylan, which
> was very positive.
Well, if MS were to adopt Dylan, and release a development system
called Visual Dylan, I might feel a whole lot better. ;-) While
we can't blame MS for C++, they are at least _strongly_ supporting
the language.
> This worldview contains some very strange reasoning. In fact, you paint
> yourself an idiot, just like those C++ vendors, since you admit yourself
> that you choose to use C++ in spite of its perceived flaws. I suppose
> the tool vendors share your view that there is no money in Li$p.
I didn't say I chose C++. I said that I'm _paid_ to use it.
There's a hell of a difference. Show me a Lisp that can produce
a DLL using ISAPI, and I'll happily use it. Meanwhile, C++ is
what MS design their tools to use. If Franz or Harlequin could
offer us tools that support the _same features_ as C++, it would
be easy.
Some people here have suggested that Lisp can do the same things.
For example, if you use CL-HTTP. This may be true, but for some
odd reason most people want to use more "conventional" web servers.
Take a look at the comp.infosystems.www.servers.* newsgroups.
Why? It may be that they're simply ignorant of Lisp and software
like CL-HTTP. Would _you_ like to disillusion them? You'll need
a working example to offer as an alternative, as they'll be _very_
sceptical. Some people will even argue over which OS should be
used, never mind which _language_.
I can barely keep up with the tools I'm paid to use, never
mind develop new ones that work very differently, in Lisp.
> Would anyone like to form a Lisp Developers Revolutionary Front,
> and bomb the next C++ developers convention? ;-) I'm only asking
> because it apears that the Lisp software available today ain't
> good enough to stop these bastards. I don't think that bombs will,
> either - there's too much money backing them.
>
> Your money too, apparently! Why not buy a Lisp compiler, and start
> writing apps, or libraries that make programming in Windows easier, or
> whatever?
If I wasn't being paid to write C++ apps, then I might. If
commercial Lisps didn't cost silly prices like $2500. If MS
weren't spreading C++ memes so effectively. I'd need millions
to fight MS. Even if my efforts could make a differnce, which
might be the case if there were enough others like myself,
we'd be assuming that I have the time. Right now, I don't.
Would coding in Lisp make Windows development easier? Sorry
for being obsessed with a single platform, but that's the only
one I'm currently using. It's also a rather significant one,
considering the size of the market for Windows software.
> Still, I can't shake the feeling of heresy whenever I think about
> using Lisp to write software which so many people say MUST be written
> in C++. Why is that? I know Lisp can, at least in theory, be used
> to write exactly the same software as C++, but how do I convince
> somebody who doesn't know Lisp as well as I do that this is possible?
>
> Why be so concerned with convincing people? Use Lisp, do it better and faster
> and with fewer bugs and comparable performance, and smart programmers will
> be convinced. If you can't, maybe you should be open to the possibility that
> C++ (or VB, or Delphi, or Java, or ...) is better for some things.
Sure. Faster? I dunno about most Lisps, but ACL for Windows
appears to be rather slow at openning a dialog window. I can
live with that, but I don't know if everyone will. On the
other hand, HotMetal Pro also displays a certain sluggishness,
but I know that people can accept this.
In the case of ACL, I'd guess that it isn't loading a dialog
from the resource file. While I like the Interface Builder,
and the way it integrates with Lisp, this isn't the Windows
way of doing it. Consequently, it loses an edge that is a
major feature of Windows apps: to let Windows do a lot of
the hard work for an app. Issues like internationalisation
could be handled by adding code to the Interface Builder, or
by post-processing the code that it generates. We can still
say that Windows development tools already handle this.
So, is Lisp necessarily better? I'm not sure. ACL suffers
when you look at it from this point of view, which might be
expected for a Windows development tool. It's an excellent
_Lisp_ development tool. You might be amazed at how much
attention Windows people pay to the user interface, or how
critical people can be of apps that don't meet the high
standards set by the best Windows apps.
As for convincing people, like clients and employers, are
you suggesting that their opinions don't matter? Who the hell
is going to pay for the apps? These things _do_ matter, unless
you're self-employed or running the company yourself. I've
been unemployed long enough to appreciate this.
Why are so many Lisp people sure that the virtues of Lisp
are powerful enough to sell Lisp as an alternative to C++?
I can't even find a Lisp that compiles code to a DLL. I love
Lisp, but I can't ignore some of the failings of the various
implementations. Obviously, this is subjective. That's why
I'm trying to explain the significance of these issues.
--
<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
We're living on a knife edge, looking for the ground -- Hawkwind
I hear this commotion about Lisp Vs C++.... I beleive the best language is
the one that gets the job done the quickest. After all computers are
supposed to makes things quicker, easier and be more efficient than the
alternatives. Multi-Lingual programming is necessary to get the job done.
I use Lisp for applications under Interleaf and AutoCad, for Access
Programming I use BASIC, for Oracle I use SQL, for MS-DOS simple functions
I have batch functions, for complex functions Pascal and C, for simple UNIX
functions Shell scripts, for some engineering functions Fortran. The
choice of launguage is based on what language I have the best set of tools
for. I would not begin to try and develope OS file manipluations under
Access Basic, nor would I try to write a Lisp function for something that
could be thrown together in a few minutes in a Batch file (You should see
some of my batch files).
To insure a profitable future in programming, we need to evaluate the
language for the problem, not the problem for the language. This
flexability will provide our employers with the best solution which, in
turn, will hopefully convince them to listen to us when we suggest using
something different in the future.
As for Microsoft, I have mixed feelings about them but I wont discuss all
of them now. There is one project that I have heard they are undertaking
but I do not know the full details. They are suppossedly working on a
method of 'UNICODE' where multiple languages can be intermingled and
allowed to work together. In theory this sounds good. If anyone knows
more, please enlighten me.
[James Toebes]
| I beleive the best language is the one that gets the job done the
| quickest.
I have mixed feelings about this. Too frequently "gets the job done" means
90% of the job and exponential costs to approach 100% asymptotically. Too
often, this is because getting 100% of the job done requires as much effort
in a very powerful language (abstraction-wise) as is needed to get 90% of
the job done in less powerful languages that focus on manual labor instead
of mental labor to solve the problems. With the experience that getting
100% will mean skyrocketing costs, managers won't listen to arguments
against "get the job done" until they know what it _could_ mean with very
different tools. If you're an expert at hacking your way through the
jungle around a mountain, and want to build a road there, it takes courage
to investigate the option of digging a tunnel through the mountain, and
vastly different tools. I wouldn't want the decision to be based on who
gets to the other side first.
| As for Microsoft, I have mixed feelings about them but I wont discuss
| all of them now. There is one project that I have heard they are
| undertaking but I do not know the full details. They are suppossedly
| working on a method of 'UNICODE' where multiple languages can be
| intermingled and allowed to work together. In theory this sounds good.
| If anyone knows more, please enlighten me.
That's ISO 10646 Universal Multiple-octet Coded Character Set (UCS), also
known as Unicode 1.1, a character set standard that was intended to serve
as the foundation for the next generation of computer representation of
text, respecting all the world's written languages, extant and historic.
It embraces natural languages and a rich array of mathematical and other
symbols. I do not look forward to the time when programming language or
utility designers discover that they can use all of these symbols in their
syntax instead of inventing more and more complex multi-character "tokens",
but other than my fears (and a fundamental problem of implementability and
deployment in programming environments), it has very little to do with
programming languages.
#\Erik
--
I could tell you, but then I would have to reboot you.
> I have mixed feelings about this. Too frequently "gets the job done"
means
> ...
> I wouldn't want the decision to be based on who gets to the other side
first.
Let me explain what I mean by 'getting the job done'. That means
completing the job in a professional manner with all the bells and wistles.
It includes updateablilty, ease of maintenance, functionality and
efficiency. If you go back to my first letter you will notice my choice of
language for the project. For developing MS Access applications, BASIC is
my choice since access basic integrates efficiently with Access. If I chose
lisp, fortran, C++, ..., I would have to develop / aquire a set of tools
and library functions to perform the marriage. By using Access basic and
choosing something well integrated for the task, I have an application that
when I upgraded it from Access 2.0 to Access 7.0, I did not have to rework
a single function. I Choose Lisp for Interleaf and AutoCAD because they
integrate well there. I have a Lisp Shareware Package for AutoCAD that
provides functionality and Cross Platform Independance. If I have
developed in C++ for AutoCAD, I would have needed a seperate compiler and
tool set for every platform that AutoCAD exist on. (Not a financial
possibility.) By selecting the appropriate language for the Job, not the
Job for the Language, I have been much more efficient and productive.
> That's ISO 10646 Universal Multiple-octet Coded Character Set (UCS), also
..
I am not referring to UNICODE character set. The article I read (about 6
moths ago so I dont remember the source) was concering a multi-language
integrator. It allowed code written in any language to be readily
interpreted based on standard computer operations thus allowing programmers
to develop in both lisp, C++, Fortran, ... and have all programs
communicate together. All computer operations reguardless of the language
can be broken down to some basic functions line add two integers, store a
variable, compare two values, .... Once a program is broken down to this
level, Communication in the form of data exchane becomes relativle simple.
Function A in language X requires and Integer parameter and returns a
string. Function B in language Y calls Function A with an integer and a
string is returned. Extrapolated to OOP - Object A has a run function.
Programming language X can tell the object to run as well as programming
language Y. I realize this is a highly simplified explanation but It
explains the jist of the article. I have not seen anything else about it
since then so I don't know if someone was misinformed or what.
[James Toebes]
| Let me explain what I mean by 'getting the job done'.
Thanks.
| I am not referring to UNICODE character set.
Since Microsoft is a pusher of Unicode (ISO 10646) in Windows NT and also a
member of the Unicode Consortium, I find it amazing beyond compare if they
have called something else "Unicode", as well. Somebody must have confused
the name, at least.
| All computer operations reguardless of the language can be broken down
| to some basic functions line add two integers, store a variable,
| compare two values, ....
There's an ISO standard at some stage called "Language-independent
procedure calling". It sounds vaguely like the effort you mention. That
standard is highly optimized for languages with trivial representation of
objects, as found in languages with values and storage locations that are
typed at compile-time, only. It fails utterly to address the needs of
dynamic languages, of which several have arrived on the scene "recently".
I believe in creating "interfaces" or "trampolines" or whatever between
different languages' optimal data representations and function calling
mechanisms. Languages just differ too much in how they do things beyond
the most basic to be able to agree on a common format without seriously
hurting performance. Assuming, that is, that "performance" still means
something when this gets used. (In some existing systems, this overhead
can be ignored because it will always be much smaller than the next most
costly overhead, typically interprocess communication mechanisms.) I have
found that function calling mechanisms have been getting more and more
complex in recent years both on the CPU level and in the coding conventions
employed, to the point where a function should be quite long before it pays
to call it instead of inlining its body. Inlining code between languages
will be tricky at best, so the standard practice of creating large amounts
of teeny-weeny functions as accessors into larger objects will have a
tremendous cost overhead if those objects are not interchanged at the
highest possible level. This means that type definitions (e.g., struct and
class declarations) need to be shared across the language interface. This
is a non-trivial problem, not at all solved by reducing function calls to
interchange of some notion of "basic" building blocks. That whole concept
is seriously dated; I'd say it's _pre_-object-orientation.
#\Erik
--
I could tell you, but then I would have to reboot you.
> I find it amazing beyond compare if they
> have called something else "Unicode", as well. Somebody must have
confused
> the name, at least.
Thay would be me. I read the article a while ago and I don't remember what
they called it.
As for the inefficiencey in implementation of the concept. The system was
supposed to to read the language source code and generate compiles/run-time
code. This would simplify the whole process since the actual
internalization of all variables and code would be done by it. It
additionally needed an intepreter defined for each language it supported.
This allows you to still write code in whatever language you prefer and
still intermingle the operations. Again, I said the concept sounds good,
the implementation remains to be seen.
Hi!
JT>All computer operations reguardless of the language
JT>can be broken down to some basic functions line add two integers, store
JT>a
JT>variable, compare two values, .... Once a program is broken down to
JT>this
That's only partially true. Of course you can break down even Haskell or
Scheme down to simple machine operations. But what would be the price? If
you go down to this low abstraction level to get a machine-independend
code, optimizations get problematic. That's the reason why the RTL of the
GNU compiler is a quite high level of abstraction - so you can do some
optimizations. The lower you go the lesser optimizations you can do (you
should have done them to get that far ;-) ).
JT>level, Communication in the form of data exchane becomes relativle
JT>simple.
Hmm. Look at the backend of GNU-C and you will see that "relative" is
really relative in this case ;-)
And with higher languages you get the problem that every nice feature must
be reduced to simple abstract machine instructions. For example closures
must be completely removed, because there is no place in a abstract
von-Neumann machine for things like closures.
I doubt that Microsoft will respect things like this in there project - I
think that they will focus more on different hardware aspects, to be able
to develop and create native code for all supported NT-platforms. So the
abstraction level of there abstract machine will be quite low, I think.
But to look at it the other way: it's better to have an abstract machine on
lowest level, than haveing some higher-level abstract machine with the
wrong abstractions (Java-VM for example).
The problem is definitely solvable, as GNU-C shows. That brings me to a
point: why did no one ever write a RTL-interpreter?
bye, Georg
In article <················@naggum.no> ····@naggum.no "Erik Naggum" writes:
> I have mixed feelings about this. Too frequently "gets the job done" means
> 90% of the job and exponential costs to approach 100% asymptotically. Too
> often, this is because getting 100% of the job done requires as much effort
> in a very powerful language (abstraction-wise) as is needed to get 90% of
> the job done in less powerful languages that focus on manual labor instead
> of mental labor to solve the problems. With the experience that getting
> 100% will mean skyrocketing costs, managers won't listen to arguments
> against "get the job done" until they know what it _could_ mean with very
> different tools. If you're an expert at hacking your way through the
> jungle around a mountain, and want to build a road there, it takes courage
> to investigate the option of digging a tunnel through the mountain, and
> vastly different tools. I wouldn't want the decision to be based on who
> gets to the other side first.
The word I associate with this is 'leaverage'. Some tools give
you a lot of leaverage in a particular app domain. while others
just suck. I think this may have been what James was refering to.
The ability to reuse existing code gives you tremendous leaverage,
and many tools give you the ability to do this. Some techniques
will be specific to an individual platform, like Tk widgets (are
they available for NT, as well as Unix? I don't know), or OCX
controls. Some will depend on a specific language, like a class
or class library for C++, Smalltalk, CLOS, etc.
And then there are tools that generate code for you, from CASE
tools all the way down to silly little things like 'Wizards' and
'Experts'. The interface builders you get with some Lisps and
Lisp tools are in this group of tools.
One big difference between Lisp and C++ tools is that with Lisp,
the tools are likely to be integrated into the enviroment the
app runs in, along with the compiler and everything else, while
C++ development tools (the compiler, wizards, resource editors,
source editor etc) will tend to all be individual programs called
from a 'workbench' program.
Does this remind you of the distinction between an OS and a
Lisp Machine? Perhaps it's not just programming languages that
shape the way we look at software. It might be great if we
could convince people that integrating software into a single,
seamless, whole is a good idea, but there may be technologies
(like OLE) making this possible already, but without doing it
via a programming language, but the OS.
When you're only tools is a hammer, everything looks like a
nail. Could this work both ways? What should we really be
focussing on, the OS, the language, or the documents? Apple
and MS, and others, are saying it should be documents.
What's an application? A collection of things that don't fit
into a document? ;-)
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
"An operating system is a collection of things that don't fit into
a language. There shouldn't be one." -- 'Design Principles Behind
Smalltalk', Daniel Ingalls, Byte August 1981
From: Patrick Giagnocavo
Subject: Re: Common LISP: The Next Generation
Date:
Message-ID: <3254B0F1.41C6@earthlink.net>
Cyber Surfer wrote:
> A few of us will be priviledged enough to not have to worry about
> this. I'll gladly write Lisp code for food, but nobody is asking
> me to, or any other Windows developer I know. I blame memes from
> MS for this sad state of affairs, and a complacency from the Lisp
> community. On the other, to be fair, it looks like not many Lisp
> people are using Windows, so why care?
>
> I only care coz I've use Lisp for some of my own projects, and
> I'd love to use it for the stuff I get paid for. Nobody I know
> gives a shit about that, but it doesn't change how I feel. I still
> prefer Lisp every time - it just makes no difference when I have
> a deadline to meet, as it's always easier to use C/C++ instead.
> It should be different, but the tools available for C/C++ (for
> Windows) do actually make it _easier_. Go figure.
>
Well, why not try using the GCC compiler (c/c++) in conjunction with
some of the that take Lisp code and convert it to C or C++? Then you
can _write_ in Lisp, but compile in C/C++. I don't even know if you
have to use GCC, maybe the MSVC compiler would handle it too.
> Yes, I should be writing Lisp code to make it easier to do these
> things in Lisp, but as I've said repeatadly, I'm not paid to write
> Lisp code - how do I get the time to use Lisp? How do we convince
> the idiots who insist one creating and _selling_ so many C++ tools
> that they should be using Lisp? While those tools exist in such
> abundance, developers will be expected to use them.
>
So use the above - will your employer know the difference? Especially
if the utility outputs C++ - nobody really understands C++ code anyway.
:-)
Cordially
--Patrick
In article <·············@earthlink.net>
·····@earthlink.net "Patrick Giagnocavo" writes:
> Well, why not try using the GCC compiler (c/c++) in conjunction with
> some of the that take Lisp code and convert it to C or C++? Then you
> can _write_ in Lisp, but compile in C/C++. I don't even know if you
> have to use GCC, maybe the MSVC compiler would handle it too.
I'm writing a Lisp to C compiler (very slowly, of course),
using MSVC++. Either the GNU C++ docs I have aren't complete,
or there isn't support for producing DLLs, so I MSVC++ looks
like a better candidate. I can be certain that MSVC++ can
do what I require.
> > Yes, I should be writing Lisp code to make it easier to do these
> > things in Lisp, but as I've said repeatadly, I'm not paid to write
> > Lisp code - how do I get the time to use Lisp? How do we convince
> > the idiots who insist one creating and _selling_ so many C++ tools
> > that they should be using Lisp? While those tools exist in such
> > abundance, developers will be expected to use them.
> >
>
> So use the above - will your employer know the difference? Especially
> if the utility outputs C++ - nobody really understands C++ code anyway.
I'll need to get my compiler to support all the features needed
for writing the code I'm paid to write. I'm working on it, but
the compiler is currently at a very basic stage.
My plan is simple: write an incredibly simple compiler, ignoring
performance and concentrating on getting a compiler working with
a minimum of effort (i.e. time, which is short). Instead, I'll
concentrate on supporting the Win32 features I need to use. That
way, I'll be able to use the latest APIs from MS, and let the OS
do all the hard work.
So far, it looks like there should be very low runtime overheads,
despite the crude techniques I'm using. The GC was designed to
perform well with only a very small amount of memory, so it's a
mark/compact GC, instead of generational.
I'm optimistic.
--
<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
We're living on a knife edge, looking for the ground -- Hawkwind
From: Vassili Bykov
Subject: Re: Common LISP: The Next Generation
Date:
Message-ID: <538fql$2in@tandem.CAM.ORG>
············@wildcard.demon.co.uk (Cyber Surfer) wrote:
>
> I'm writing a Lisp to C compiler (very slowly, of course),
> using MSVC++. [...]
No surprises here. Why don't you write it in Lisp?
--Vassili
In article <··········@tandem.CAM.ORG> ······@cam.org "Vassili Bykov" writes:
> ············@wildcard.demon.co.uk (Cyber Surfer) wrote:
> >
> > I'm writing a Lisp to C compiler (very slowly, of course),
> > using MSVC++. [...]
>
> No surprises here. Why don't you write it in Lisp?
No, no. The compiler code is in CL, but the target code is for
MSVC++. Sorry for not making that clear. My goal is to be able
to write code for the Win32 platform, but if I can, I may also
support a more portable compiler, like GNU C++. Currently, there's
some code in the runtime that prevents this, and I'd like to
place the runtime code in a DLL, so until I discover how to create
a DLL using GNU C++, I'll have to continue with MSVC++ only.
--
<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
We're living on a knife edge, looking for the ground -- Hawkwind
············@wildcard.demon.co.uk (Cyber Surfer) writes:
> I didn't say I chose C++. I said that I'm _paid_ to use it.
> There's a hell of a difference. Show me a Lisp that can produce
> a DLL using ISAPI, and I'll happily use it. Meanwhile, C++ is
> what MS design their tools to use. If Franz or Harlequin could
> offer us tools that support the _same features_ as C++, it would
> be easy.
Ilog Talk generates DLLs on Windows NT and 95. I just checked out the
ISAPI spec to see how hard it would be to support using Talk, and the
answer looks good. Apparently the ISAPI spec requires your DLL to
export two functions: GetFilterVersion and HttpFilterProc. Producing
an ISAPI-compatible DLL with Talk would require you to write stub
versions of these functions in C++ which would call into Talk to do
the actual work. You could then link this tiny stub DLL with a DLL
produced by Talk's module system which does the actual implementation.
The structures used in these functions and any auxiliary API which
works on these structures can be bound to Talk using the automatic C++
binder, and you can also write the callback functions needed in the
_HTTP_FILTER_CONTEXT structure in Talk.
We're ready to take your order! Please contact ····@ilog.co.uk to
talk with our UK subsidiary.
-- Harley
-------------------------------------------------------------------
Harley Davis net: ·····@ilog.com
Ilog, Inc. tel: (415) 944-7130
1901 Landings Dr. fax: (415) 390-0946
Mountain View, CA, 94043 url: http://www.ilog.com/
In article <··············@laura.ilog.com>
·····@laura.ilog.com "Harley Davis" writes:
> Ilog Talk generates DLLs on Windows NT and 95. I just checked out the
> ISAPI spec to see how hard it would be to support using Talk, and the
> answer looks good. Apparently the ISAPI spec requires your DLL to
> export two functions: GetFilterVersion and HttpFilterProc. Producing
> an ISAPI-compatible DLL with Talk would require you to write stub
> versions of these functions in C++ which would call into Talk to do
> the actual work. You could then link this tiny stub DLL with a DLL
> produced by Talk's module system which does the actual implementation.
Yes, familiar with the ISAPI spec. It sounds like Ilog Talk could
be useful to me.
> The structures used in these functions and any auxiliary API which
> works on these structures can be bound to Talk using the automatic C++
> binder, and you can also write the callback functions needed in the
> _HTTP_FILTER_CONTEXT structure in Talk.
>
> We're ready to take your order! Please contact ····@ilog.co.uk to
> talk with our UK subsidiary.
Excellent! I can't promise to buy anything, as that'll depend
on things like the price. As long as it isn't anything silly,
then I'll be interested. If I've overlooked Ilog Talk in the
past, it may have been because it uses ISO Lisp, a dialect with
which I'm unfamiliar. Right now, I'm less concerned about that
than the prospect of coding in C++ every day.
I've ordered more info and your demo CD-ROM, via your website.
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
We're living on a knife edge, looking for the ground -- Hawkwind
Cyber Surfer <············@wildcard.demon.co.uk> wrote:
>Can I write CGI code in Lisp? Not yet. That's why I started writing
>a "toy" Lisp to C compiler.
You can write CGI code in Lisp (Scheme actually). I have code
that does just that. See
http://www.eval-apply.com/scheme/etcgi.html
The code is designed for MzScheme to ensure portability between
Unix and Windows 95 platforms. The code that accepts form
input is released, but I haven't cleaned up the HTML generation
code enough to put my name on it. I expect to be able to
get an alpha version out in a week or so.
To answer another question, the reason Lisp hardware died out was
mostly because the advances in stock hardware basically made
specialized hardware obsolete. Harlequin Lisp on a Pentium would
blow away an LMI lambda any day. It costs less, too. And you
can play Doom on it.
Cyber Surfer <············@wildcard.demon.co.uk> wrote:
>Can I write CGI code in Lisp? Not yet. That's why I started writing
>a "toy" Lisp to C compiler.
See http://www.eval-apply.com/scheme/etcgi.html
In article <··········@dublin.bitwise.net> ·····@capecod.net "Janet Bell" writes:
> Cyber Surfer <············@wildcard.demon.co.uk> wrote:
>
> >Can I write CGI code in Lisp? Not yet. That's why I started writing
> >a "toy" Lisp to C compiler.
>
> See http://www.eval-apply.com/scheme/etcgi.html
Actually, I'm interested in compiled CGI code using the ISAPI
interface. I've not yet found any code for doing this in Lisp.
If anyone has done this already, then I'll be very interested.
Anyway, I'll take a look at MzScheme, and try it with the web
server I'm using.
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
We're living on a knife edge, looking for the ground -- Hawkwind
In article <············@wildcard.demon.co.uk>, Cyber Surfer wrote:
>Can I write CGI code in Lisp? Not yet. That's why I started writing
>a "toy" Lisp to C compiler.
Precisely why can't you write CGI code in Lisp?
Nothing says that the CGI server must be written in Lisp for you
to use code written in Lisp.
Supposing your CGI server enforces (somehow) that your scripts *must*
be written in Perl, then you can just have the Perl script invoke
a Lisp program.
This discussion came up recently in the APL newsgroup. People have
this *silly* idea that it is necessary to use one and only one
language, and if that language can't be APL/J/Lisp/Scheme, then obviously
CGI/the Web cannot be accessed using APL/J/Lisp/Scheme.
Nothing can be further from the truth.
--
Christopher B. Browne, ········@unicomp.net, ············@sdt.com
Web: http://www.conline.com/~cbbrowne SAP Basis Consultant, UNIX Guy
Windows NT - How to make a 100 MIPS Linux workstation perform like an 8 MHz 286
In article <············@wildcard.demon.co.uk> ············@wildcard.demon.co.uk writes:
>
>Can I write CGI code in Lisp? Not yet. That's why I started writing
>a "toy" Lisp to C compiler.
Why couldn't you write CGI code in Lisp? I had little trouble doing
it.
Is this a common problem? Would it help if I made some Common
Lisp code for decoding query args available?
-- jeff
In article <··············@laura.ilog.com>
·····@laura.ilog.com "Harley Davis" writes:
> If the ISAPI API is available as C or C++ header file and is
> implemented in a .DLL, you can use Ilog Talk's C++ binding tool to
> automatically generate a Lisp interface to it. Ilog Talk is fully
> ported to Windows 95 and NT, includes a Lisp-to-C compiler, and
> supports the generation of DLLs containing Lisp code.
Excellent. I'll dig out my postscript printer...
> For more information, send mail to ····@ilog.co.uk or check out our
> Web site at <URL:http://www.ilog.com/>.
Been there, seen it. I didn't see any references to platforms,
and I've yet got around to setting up my printer again (I rare
_ever_ print anything, these days). I know, Ghostscript is
available,and I've installed several different versions, most
of which failed to work. As a result, I tend to ignore postscript
docs simply to save time - as my sigfile says, you can never
browse enough.
So, I'll try to overcome my aversion to displaying docs on paper. ;)
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
We're living on a knife edge, looking for the ground -- Hawkwind
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: ······@ils.nwu.edu
voice: (847) 491-7699
fax: (847) 491-5258
http://www.qrg.ils.nwu.edu/
==========================================
In article <··········@news.acns.nwu.edu>, ······@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
In C. Queinnec's book 'Les Langages Lisp' there is a reference
of an article [VH94]
Taming message passing: efficient method look-up for dynamically
typed languages.
Has anybody an idea how such 'taming' can be done in a lisp-like
language ?
Dieter
From: Scott Schwartz
Subject: Shared libraries are the problem, not the solution (was Re: Common LISP: The Next Generation)
Date:
Message-ID: <8gd900wrpr.fsf_-_@galapagos.cse.psu.edu>
······@iastate.edu (Matt Grice) writes:
| On another note, it doesnt seem to me that Lisp (or similar language)
| executable size should be too much of a problem any longer if managed
| correctly. A VB or MFC app may look small, but is using a runtime DLL
| which is quite large. This is not a new concept, but perhaps one that
| vendors have failed to capitalize on. You sneak that library in and
| from then on everybody thinks your programs are small. :)
I beg to differ. Hiding bloat in a dynamically linked library is
unhelpful if very many of those pages need to be touched at runtime,
even if they are shared with other processes. DLLs are
counterproductive because they delude people into thinking that their
executable is small, when in fact its working set is very large, with
the concommitant poor performance that people expect from Lisp.
From: Matt Grice
Subject: Re: Shared libraries are the problem, not the solution (was Re: Common LISP: The Next Generation)
Date:
Message-ID: <322f8c37.16704650@news>
········@galapagos.cse.psu.edu (Scott Schwartz) wrote:
>······@iastate.edu (Matt Grice) writes:
>| On another note, it doesnt seem to me that Lisp (or similar language)
>| executable size should be too much of a problem any longer if managed
>| correctly. A VB or MFC app may look small, but is using a runtime DLL
>| which is quite large. This is not a new concept, but perhaps one that
>| vendors have failed to capitalize on. You sneak that library in and
>| from then on everybody thinks your programs are small. :)
>
>I beg to differ. Hiding bloat in a dynamically linked library is
>unhelpful if very many of those pages need to be touched at runtime,
True, but is it more the case with Lisp then with MFC and VB? DO many
of the pages need to be touched at runtime? I assumed, perhaps
wrongly, that they do not.
>even if they are shared with other processes. DLLs are
>counterproductive because they delude people into thinking that their
>executable is small, when in fact its working set is very large, with
>the concommitant poor performance that people expect from Lisp.
If the working set is truly very large then speculating on
mainstreaming LISP is a waste of time, it's not going to happen. I am
not myself optimistic, but wanted to contribute a few areas where I
thought improvements needed to be made.
I assume you mean DLLs are counterproductive _in this instance_ but I
would not agree with that. If nothing else it would greatly reduce
disk space needed on a system with many executables. MFC and VB
would certainly not be as popular today if every app created with them
needed to contain within the executable their respective runtime
libraries.
If this would successfully delude people into thinking their programs
are small, that's a 'plus', not a problem. As with the user
interface, perception plays a large part in winning people over.
From: Tim Bradshaw
Subject: Re: Shared libraries are the problem, not the solution (was Re: Common LISP: The Next Generation)
Date:
Message-ID: <ey3u3t6acnm.fsf@staffa.aiai.ed.ac.uk>
* Jeff Dalton wrote:
> In article <···············@staffa.aiai.ed.ac.uk> Tim Bradshaw
> <···@aiai.ed.ac.uk> writes:
>> But C programs do this now. As far as I can see *everything* on Suns
>> (solaris 2.5) is linked with 750k of shared library, and anything that
>> does networking is 2meg and stuff that talks to X is 3 up. Lisp is
>> bigger still, but not *that* much bigger. (And of course, these vast C
>> programs don't perform that well either).
> Suns, though: who cares? Not Gatesland, don't you know.
Well is windows any smaller? I rather doubt it -- the thing's a mass
of DLLs, although I don't know what tools can tell you what ldd does
on Suns. Perhaps someone who knows Windows could tell us what typical
sizes are?
In fact, do any popular systems still generate really small
executables for C programs: small binary and not linked with megabytes
of shared library? I'm sure things like Plan 9 do, but what about the
various BSDs and Linux, and commercial Unixes, and Windows NT/95? If
they don't then the argument about Lisp being big isn't so clear any
more, instead the argument becomes about whether Lisp systems can
share code the way shared libraries (and shared executables) do.
Which is just as much of a problem of course.
--tim
From: Jeff Dalton
Subject: Re: Shared libraries are the problem, not the solution (was Re: Common LISP: The Next Generation)
Date:
Message-ID: <DxJL6s.1M2.0.macbeth@cogsci.ed.ac.uk>
In article <···············@staffa.aiai.ed.ac.uk> Tim Bradshaw <···@aiai.ed.ac.uk> writes:
>* Jeff Dalton wrote:
>> In article <···············@staffa.aiai.ed.ac.uk> Tim Bradshaw
>> <···@aiai.ed.ac.uk> writes:
>
>>> But C programs do this now. As far as I can see *everything* on Suns
>>> (solaris 2.5) is linked with 750k of shared library, and anything that
>>> does networking is 2meg and stuff that talks to X is 3 up. Lisp is
>>> bigger still, but not *that* much bigger. (And of course, these vast C
>>> programs don't perform that well either).
>
>> Suns, though: who cares? Not Gatesland, don't you know.
>
>Well is windows any smaller? I rather doubt it -- the thing's a mass
>of DLLs [...]
>
>In fact, do any popular systems still generate really small
>executables for C programs: small binary and not linked with megabytes
>of shared library? I'm sure things like Plan 9 do, but what about the
>various BSDs and Linux, and commercial Unixes, and Windows NT/95?
FreeBSD executables can be fairly small. NetBSD should be similar.
I don't know about Linux.
>If they don't then the argument about Lisp being big isn't so clear any
>more, instead the argument becomes about whether Lisp systems can
>share code the way shared libraries (and shared executables) do.
>Which is just as much of a problem of course.
Why would there be an argument? Why isn't the answer obviously "yes".
-- jd
From: Harley Davis
Subject: Re: Shared libraries are the problem, not the solution (was Re: Common LISP: The Next Generation)
Date:
Message-ID: <wkbufext8f.fsf@laura.ilog.com>
Tim Bradshaw <···@aiai.ed.ac.uk> writes:
> * Jeff Dalton wrote:
> > In article <···············@staffa.aiai.ed.ac.uk> Tim Bradshaw
> > <···@aiai.ed.ac.uk> writes:
>
> >> But C programs do this now. As far as I can see *everything* on Suns
> >> (solaris 2.5) is linked with 750k of shared library, and anything that
> >> does networking is 2meg and stuff that talks to X is 3 up. Lisp is
> >> bigger still, but not *that* much bigger. (And of course, these vast C
> >> programs don't perform that well either).
>
> > Suns, though: who cares? Not Gatesland, don't you know.
>
> Well is windows any smaller? I rather doubt it -- the thing's a mass
> of DLLs, although I don't know what tools can tell you what ldd does
> on Suns. Perhaps someone who knows Windows could tell us what typical
> sizes are?
The basic Windows DLL's for Win32 are:
GDI32.DLL: 130k
USER32.DLL: 44k
KERNEL32.DLL: 410k
The cost of these libraries is amortized over every single running
executable, and they implement the whole OS. For networking, you
typically just need winsock, which is about 65k.
In addition, there are typically tens or hundreds of others, depending
on what application software you've loaded. Some of the bigger ones
are OLE32, at 558k, and MFC, typically around 750k depending on the
version (often you need several).
To find out what DLLs are linked with an executable, use the dumpbin
command with the /imports option. This command comes with Visual C++;
I don't know what Borland supplies.
I compiled the following program:
#include <iostream.h>
main() { cout << "hi" << endl; }
The executable was 26k, and it imports about 40 symbols from
KERNEL32.DLL. Draw your own conclusions.
-- Harley Davis
-------------------------------------------------------------------
Harley Davis net: ·····@ilog.com
Ilog, Inc. tel: (415) 944-7130
1901 Landings Dr. fax: (415) 390-0946
Mountain View, CA, 94043 url: http://www.ilog.com/
······@iastate.edu (Matt Grice) writes:
> Ronald Perrella <········@mindspring.com> wrote:
>
> >Cyber Surfer wrote:
> >
> >[lots of stuff removed...]
> >> Take a look at VB. The language may be hideous, but the enviroment
> >> is _very_ popular. It gives developers what they want, and they
> >> used it in large numbers. VC++ is less friendly, but it's also
> >> very popular. A Lisp or ML enviroment with those kind of features
> >> could be a killer.
>
> To me, this seems to be a big part of the problem with Lisp and
> friends (Dylan, Scheme, etc.) It's mind boggling to me that you can
> shell out several K$ for a Lisp package and get something with the
> incredibly amateurish user interfaces that I see. It looks like the
> UI code was created in 1985 and only maintained since then... perhaps
> this is the case. No matter how technically good a package may be,
> it's hard to take seriously products whose interface is not only ugly,
> but also not even in conformance with the platform they are delivered
> on.
Low cost = high volume, or there's not a business going on. Most Lisp
companies are scared of the up-front marketing investment which would
be required to make a mass-market, low-price product out of Lisp.
They don't know how to package it for the mass market (and I'm not
just thinking of pretty boxes but of the kinds of issues raised
above), they've never tried to manage mass-market sales channels like
retail distributors, they wouldn't know how to support it (or reduce
the need for support) or publicize it. Finally, the truth is that
there's not very much money to be made in the language compiler/IDE
business at all, and especially in alternative languages. The best
recent shot has been Borland's Delphi, and its success has only been
moderate - it certainly hasn't gotten Borland out of hot water.
The other approach which has achieved moderate success (but is now
clearly dying) is SmallTalk's high price, low-volume, direct-sales
model. This approach only works until the low-end starts eating into
your market, which inevitably happens in high-tech. There are now
fewer arguments than ever to make in favor of a SmallTalk or Lisp
environment against a cheap, high-powered VB, or PowerBuilder, or
Java.
I guess what I'm saying is that MS will always win in markets where
they can afford not to be directly profitable if they don't screw
things up too badly. Visual L++, anyone?
-- Harley
-------------------------------------------------------------------
Harley Davis net: ·····@ilog.com
Ilog, Inc. tel: (415) 944-7130
1901 Landings Dr. fax: (415) 390-0946
Mountain View, CA, 94043 url: http://www.ilog.com/
* David Boles wrote:
> In article <···············@staffa.aiai.ed.ac.uk>,
> Tim Bradshaw <···@aiai.ed.ac.uk> wrote:
>> 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.
OK.
> 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.
But we can plug non standalone programs into the framework as well.
All the Unix scripting languages do this already! I'm trying to
suggest that Lisp could go for a model like that -- where the programs
that run rely on some other system for runtime support. My idea is
that it might be easier to factor out the runtime support and run
`fasl files' (or lisp source directly in the interpreter) than write
incredibly bright compilers that can generate very small executables
from a very rich environment by doing a lot of hairy analysis of
what's needed.
I figure that it's much harder to take a very comprehensive system and
prune it than to take a very spartan system (like C) and extend it
gradually until you get the enormous C-based programming systems we
see today. So it may be better to find a mechanism which means that
you don't have to do that after all -- lisp-as-a-shared-library,
server-based lisps, lisp as a shell interpreter, whatever.
Languages like perl already succeed in this to some extent -- perl is
clearly `larger' as a language (provides a lot of built in stuff) than
C but people accept it even though there's a 1/2Mb runtime out there
somewhere. scsh tries to do the same thing, although it doesn't
succeed so well because of slow startup times: I don't know why the
startup time is so slow, but I doubt it is anything inherent in
lisp/scheme since elk used to start very fast.
>> Just because compiling a stand alone executable has always been the
>> Unix way doesn't mean it has to be like that.
> 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.
I'm very interested in lisp adapting to Unix &c, I'm just trying to
suggest that there may be other ways than the
tiny-standalone-executable approach to the problem.
--tim
* Oleg Moroz wrote:
> On 02 Sep 1996 11:47:32 +0100, Tim Bradshaw <···@aiai.ed.ac.uk> wrote:
> 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).
But but. How big is Netscape this week? How big is Word? These
systems are just *vast*, but very popular. Small is good of course,
but fast and useful is clearly better. And solutions which let you
share the large image reduce the overhead a long way. I'm happy to
concede that Lisp systems often don't let you do this right now but
(see my other post) I question that going for a compiler that makes
small standalone executables is the only solution.
(And I don't want to get into `mine is smaller than yours' arguments,
but VC++ appears to be about 3 times as big as the Franz Allegro
development environment on my Sun (:-))
> 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).
yes but this is really a small overhead -- 1% of executable size or
something, which means it's typically only a really rather small
number of pages.
--tim
In article <···············@staffa.aiai.ed.ac.uk>, Tim Bradshaw
<···@aiai.ed.ac.uk> wrote:
>But but. How big is Netscape this week? How big is Word? These
>systems are just *vast*, but very popular.
Actually, I wouldn't go so far as to say that Netscape Navigator and
Microsoft Word are vast. I'd only go so far as to say that they're
half-vast.*
* Still don't get it? Try reading the sentence out loud.
--
To get random signatures put text files into a folder called �Random Signatures� into your Preferences folder.
In article <···············@staffa.aiai.ed.ac.uk> Tim Bradshaw <···@aiai.ed.ac.uk> writes:
I figure that it's much harder to take a very comprehensive system and
prune it than to take a very spartan system (like C) and extend it
gradually until you get the enormous C-based programming systems we
see today. So it may be better to find a mechanism which means that
you don't have to do that after all -- lisp-as-a-shared-library,
Here is the plan how to take over the world.
I do not see what stops someone from taking let's say Bigloo
Scheme and compiling libbigloo as shared library. You would need
to change couple of lines in Makefile (adding -fPIC to gcc
options and replacing "ar rc" to "gcc --shared") and you
immediately have 10K Scheme compiled executables. The next step
would be to write couple of hundred of enormously useful
utilities using this library (just about 1Meg) and put RPM
package in ftp.redhat.com:/pub/contrib. This way you sneak this
shared library and idea of small fast lisp programs on millions
home computers used by hackers that do not know what to do with
their computers and spare time --- an enviroment very friendly
for bizarre languages (think about it --- they even use Perl and
TCL!).
Use Gambit if you do not like bigloo. SCM is OK too, but it
needs SLIB and has pretty big startup time.
Next step would be enormously useful program using CMU CL ;-)
I suspect that the part with writing useful utilities would be
the most difficult.
······@spot.uchicago.edu (Alexey Goldin) writes:
> Here is the plan how to take over the world.
A few years ago there was an interesting thread along these lines
in the comp.lang.lisp.mcl group, the basic idea being that most
users wouldn't object at all to installing a relatively big
Mac OS "system extension" that would hold all of the MCL RTS in
order to "enable" their computer to run lisp "applets".
Espen Vestre
Espen Vestre <··@kvikk.telepost.no> wrote:
> A few years ago there was an interesting thread along these lines
> in the comp.lang.lisp.mcl group, the basic idea being that most
> users wouldn't object at all to installing a relatively big
> Mac OS "system extension" that would hold all of the MCL RTS in
> order to "enable" their computer to run lisp "applets".
Done as of MCL version 3.9, which shipped in June.
--
Dave Lamkins, http://www.teleport.com/~dlamkins/
CPU Cycles: Use them now, or lose them forever...
From: ·····@world.std.com (Will Ware)
Newsgroups: comp.lang.lisp,comp.lang.scheme
Date: Sat, 7 Sep 1996 06:02:40 GMT
[...] MrEd is a combination of WxWindows with MzScheme. MzScheme and
MrEd run on MSWin (all flavors), Unix/X, and the Mac.
I am afraid you must be mistaken. I just searched scheme-faq/part2 dated
13 Aug 1996 for -i \<rice\> and found only scheme88. So, obviously, this
MzScheme is just a figment of your imagination... :-)
Matt Birkholz <········@midnight.com.>
Finger ········@primenet.com for PGP 2.6.2 Public Key ID = 74305425
Key Fingerprint = B3 34 FB 3E 3C FE E8 57 AA B4 B2 95 A7 C0 1E AF
From: Tim Bradshaw
Subject: Re: Shared libraries are the problem, not the solution (was Re: Common LISP: The Next Generation)
Date:
Message-ID: <ey3zq30yodk.fsf@staffa.aiai.ed.ac.uk>
* Scott Schwartz wrote:
> I beg to differ. Hiding bloat in a dynamically linked library is
> unhelpful if very many of those pages need to be touched at runtime,
> even if they are shared with other processes. DLLs are
> counterproductive because they delude people into thinking that their
> executable is small, when in fact its working set is very large, with
> the concommitant poor performance that people expect from Lisp.
But C programs do this now. As far as I can see *everything* on Suns
(solaris 2.5) is linked with 750k of shared library, and anything that
does networking is 2meg and stuff that talks to X is 3 up. Lisp is
bigger still, but not *that* much bigger. (And of course, these vast C
programs don't perform that well either).
On another related topic: one of the problems with shared libraries
(or shared Lisp images) mentioned earlier was that large libraries
tend to scatter the things that are touched -- across the library,
causing many more pages to be touched than smaller libraries, even if
the same amount of code is run. Presumably systems with relocating
GCs could be written that would deal with this kind of problem
essentially without relinking -- you'd need to gather some statistics
on the program and then persuade the GC to relocate things in good
ways. Has anyone done this? Symbolics had an `optimize world'
command which I think may have done something similar, but I'm not
sure.
--tim
From: Jeff Dalton
Subject: Re: Shared libraries are the problem, not the solution (was Re: Common LISP: The Next Generation)
Date:
Message-ID: <DxHnx7.xp.0.macbeth@cogsci.ed.ac.uk>
In article <···············@staffa.aiai.ed.ac.uk> Tim Bradshaw <···@aiai.ed.ac.uk> writes:
>* Scott Schwartz wrote:
>
>> I beg to differ. Hiding bloat in a dynamically linked library is
>> unhelpful if very many of those pages need to be touched at * runtime,
*If*, with no evidence that the potential problem is actual.
>> even if they are shared with other processes. DLLs are
>> counterproductive because they delude people into thinking that their
>> executable is small, when in fact its working set is very large, with
>> the concommitant poor performance that people expect from Lisp.
No "if". Just the completely unsupported claim that DLLs delude
people.
>But C programs do this now. As far as I can see *everything* on Suns
>(solaris 2.5) is linked with 750k of shared library, and anything that
>does networking is 2meg and stuff that talks to X is 3 up. Lisp is
>bigger still, but not *that* much bigger. (And of course, these vast C
>programs don't perform that well either).
Suns, though: who cares? Not Gatesland, don't you know.
-- jd
From: Rainer Joswig
Subject: Re: Shared libraries are the problem, not the solution (was Re: Common LISP: The Next Generation)
Date:
Message-ID: <joswig-1009960026560001@news.lavielle.com>
In article <···············@staffa.aiai.ed.ac.uk>, Tim Bradshaw
<···@aiai.ed.ac.uk> wrote:
> the same amount of code is run. Presumably systems with relocating
> GCs could be written that would deal with this kind of problem
> essentially without relinking -- you'd need to gather some statistics
> on the program and then persuade the GC to relocate things in good
> ways. Has anyone done this? Symbolics had an `optimize world'
> command which I think may have done something similar, but I'm not
> sure.
Well, Symbolics uses a generational copying GC. This
reduces memory fragmentation. Also memory is
organized in "areas". You allocate objects in certain
areas. It is also possible to uses different memory
management algorithms for different areas. A bitmap
area may have different needs than a pathname area.
Areas also reduces memory fragmentation.
"Optimize World" improves paging performance (also
you can use (si:reorder-memory) ) by moving related data
and functions in contiguous memory locations.
(Genera 8.0 and later, "Site Operations", March 1990,
chapter 4.2).
From: Tim Bradshaw
Subject: Re: Shared libraries are the problem, not the solution (was Re: Common LISP: The Next Generation)
Date:
Message-ID: <ey3loehz5br.fsf@staffa.aiai.ed.ac.uk>
* Jeff Dalton wrote:
> In article <···············@staffa.aiai.ed.ac.uk> Tim Bradshaw <···@aiai.ed.ac.uk> writes:
>> [...] instead the argument becomes about whether Lisp systems can
>> share code the way shared libraries (and shared executables) do.
>> Which is just as much of a problem of course.
> Why would there be an argument? Why isn't the answer obviously "yes".
The answer seems to me to be `in theory yes, in practice, no'. Of
course it's possible, but I can't actually go out and buy a system
that lets me do shared library-type stuff in Lisp (can I?).
--tim
From: Scott Schwartz
Subject: Re: Shared libraries are the problem, not the solution (was Re: Common LISP: The Next Generation)
Date:
Message-ID: <8gn2yz7kjm.fsf@galapagos.cse.psu.edu>
Tim Bradshaw <···@aiai.ed.ac.uk> writes:
[posted and mailed]
| But C programs do this now. As far as I can see *everything* on Suns
| (solaris 2.5) is linked with 750k of shared library, and anything that
| does networking is 2meg and stuff that talks to X is 3 up. Lisp is
| bigger still, but not *that* much bigger. (And of course, these vast C
| programs don't perform that well either).
*Some* C programs do this now. Just because Solaris comes with a
bunch of bloated code doesn't make it good practice. "Not only is
unix dead, it's starting to smell bad" -- Rob Pike.
From: Oleg Moroz
Subject: Re: Shared libraries are the problem, not the solution (was Re: Common LISP: The Next Generation)
Date:
Message-ID: <323470d4.1353362@news-win.rinet.ru>
On 09 Sep 1996 11:52:29 -0400, ········@galapagos.cse.psu.edu (Scott Schwartz)
wrote:
>| But C programs do this now. As far as I can see *everything* on Suns
>| (solaris 2.5) is linked with 750k of shared library, and anything that
>| does networking is 2meg and stuff that talks to X is 3 up. Lisp is
>| bigger still, but not *that* much bigger. (And of course, these vast C
>| programs don't perform that well either).
>
>*Some* C programs do this now. Just because Solaris comes with a
>bunch of bloated code doesn't make it good practice. "Not only is
>unix dead, it's starting to smell bad" -- Rob Pike.
All of the Windows software (I won't cite the percentage :-)) uses DLLs if only
to use the system API. Windows/Win32 itself is not much more than a relatively
small (and mostly inaccessible from user-level programs) kernel plus many DLLs
that implement the functionality. The current state-of-things (as Microsoft
tells us developers) is to link with MSVCRT.DLL (which is C runtime library) and
MFC42.DLL (which is MFC DLL).
As for the pros and contras of using DLLs, I see much more pros (smaller
distribution size when you have many executables using one or more common DLLs,
ability to load them at run-time, suitability for delivering binary components
such as OLE objects, ask for more) than contras (are there any ? :-)).
Oleg
From: Christopher B. Browne
Subject: Re: Shared libraries are the problem, not the solution (was Re: Common LISP: The Next Generation)
Date:
Message-ID: <slrn539nc9.la6.cbbrowne@wolfe.brownes.org>
In article <················@news-win.rinet.ru>, Oleg Moroz wrote:
>As for the pros and contras of using DLLs, I see much more pros (smaller
>distribution size when you have many executables using one or more common DLLs,
>ability to load them at run-time, suitability for delivering binary components
>such as OLE objects, ask for more) than contras (are there any ? :-)).
It also has the advantage of making the executables more sharable.
It's unhelpful if you've got 2 binaries that are both 8MB in size, of
which 7.5MB represents common code. If the 7.5MB of common code was
dropped out into DLLs, at least it gets shared between the executables.
It is possible that the code bloated to 7.5MB "because it's using DLLs."
But that's not intrinsic to the use of DLLs.
I've run a whole lot of Digital OSF/1 programs that were 32K long
(plus libraries). If there was waste, at least it's only being wasted
once, and not 50 times.
--
Christopher B. Browne, ········@unicomp.net, ············@sdt.com
Web: http://www.conline.com/~cbbrowne SAP Basis Consultant, UNIX Guy
Windows NT - How to make a 100 MIPS Linux workstation perform like an 8 MHz 286
In article <··············@ips1.msfc.nasa.gov> ·······@ips1.msfc.nasa.gov (Raj P Manandhar) writes:
1 MB :-( and 750 KB, respectively, and half those values stripped. The
memory footprints are essentially the same as the static executable
sizes, unfortunately (240 4-KB pages), and the compiled hello.sc is
Oops, the RSS is in KB of course, not pages. So it's 240 KB.
--
Raj Manandhar (205) 544-3965 ···@msfc.nasa.gov
NASA/George C. Marshall Space Flight Center I'm not affiliated with
Code ES84 NASA.
Huntsville, AL 35812
My URL is http://xanth.msfc.nasa.gov/~raj/home.html
In article <··············@spot.uchicago.edu> ······@spot.uchicago.edu (Alexey Goldin) writes:
Here is the plan how to take over the world.
I do not see what stops someone from taking let's say Bigloo
Scheme and compiling libbigloo as shared library. You would need
This was easy enough to try (I got tired of the huge bigloo
executables myself a while ago). With Irix 5.3, I don't think a
recompile was even necessary, just a link with funny options of the
static library (I don't remember the details).
With this file as hello.sc:
(module hello)
(display "hello, world")
(display #\newline)
it compiles to a 22 KB dynamic executable (14k stripped). This is with
bigloo 1.8, gcc 2.6.3 (sorry, we'll upgrade some day), no
optimization. With bigloo -unsafe, it's 14 KB unstripped or
stripped. So the 10 KB goal is perhaps in sight, but not quite there
:-). Linking the libbigloo.a statically, the safe and unsafe sizes are
1 MB :-( and 750 KB, respectively, and half those values stripped. The
memory footprints are essentially the same as the static executable
sizes, unfortunately (240 4-KB pages), and the compiled hello.sc is
somewhat noticeably slower than "/bin/echo hello, world" (10 KB,
stripped, statically linked). More bad news: libbigloo.so is 2 MB,
libbigloo.a is 3.5 MB, and compiled with -g it's over 6 MB.
to change couple of lines in Makefile (adding -fPIC to gcc
options and replacing "ar rc" to "gcc --shared") and you
immediately have 10K Scheme compiled executables. The next step
would be to write couple of hundred of enormously useful
utilities using this library (just about 1Meg) and put RPM
package in ftp.redhat.com:/pub/contrib. This way you sneak this
shared library and idea of small fast lisp programs on millions
home computers used by hackers that do not know what to do with
their computers and spare time --- an enviroment very friendly
for bizarre languages (think about it --- they even use Perl and
TCL!).
Use Gambit if you do not like bigloo. SCM is OK too, but it
needs SLIB and has pretty big startup time.
Next step would be enormously useful program using CMU CL ;-)
I suspect that the part with writing useful utilities would be
the most difficult.
Since I haven't played with bigloo recently, especially cigloo, the
FFI header-file analyzer, I thought I would write a program to measure
the rusage, to see how difficult it would be, out of curiosity. It
doesn't quite work--the execvp dies with an invalid address if you
pass the child program any arguments. Any ideas, bigloo users? I think
this is something relating to garbage collecting (bigloo uses Boehm's
GC). Still, I found cigloo works OK, though it needs some handholding
since it doesn't understand the #ifdefed C++isms in the Irix header
files. Thus I had to paste the parts of the header files I needed into
a file I called getrusage.h, and run cigloo on it to get
getrusage.sch, which looks like (after one or two small edits and line
unwrapping):
(directives
(foreign
;; beginning of getrusage.c
(macro long RUSAGE_SELF "RUSAGE_SELF")
(macro int RUSAGE_CHILDREN "RUSAGE_CHILDREN")
(int errno "errno")
(macro string* sys_errlist "sys_errlist")
(int sys_nerr "sys_nerr")
(macro int execvp (string string*) "execvp")
(pid_t fork () "fork")
(pid_t waitpid! (pid_t int* int) "waitpid")
(int getrusage! (int s-rusage*) "getrusage")
(type s-timeval (struct (long tv_sec "tv_sec") (long tv_usec
"tv_usec")) "struct timeval")
(type s-rusage (struct (s-timeval ru_utime "ru_utime") (s-timeval
ru_stime "ru_stime") (long ru_maxrss "ru_maxrss") (long ru_ixrss
"ru_ixrss") (long ru_idrss "ru_idrss") (long ru_isrss "ru_isrss")
(long ru_minflt "ru_minflt") (long ru_majflt "ru_majflt") (long
ru_nswap "ru_nswap") (long ru_inblock "ru_inblock") (long ru_oublock
"ru_oublock") (long ru_msgsnd "ru_msgsnd") (long ru_msgrcv
"ru_msgrcv") (long ru_nsignals "ru_nsignals") (long ru_nvcsw
"ru_nvcsw") (long ru_nivcsw "ru_nivcsw")) "struct rusage")
(type pid_t long "pid_t")
(type string* (pointer string) "char **")
(type int* (pointer int) "int *")
;; end of getrusage.c
))
Here's rusage.sc, which compiles to a 57 KB safe unstripped dynamic
executable:
(module rusage
(main main)
(foreign
(include "sys/types.h")
(include "sys/time.h")
(include "sys/resource.h")
(include "unistd.h")
(macro int* c-null "NULL"))
(include "getrusage.sch"))
(define (main argv)
(if (or (null? argv)
(null? (cdr argv)))
(error "rusage" "usage" "rusage program [program-args...]"))
;;; (show-rusage "before" RUSAGE_SELF)
(let ((pid (fork)))
(cond ((< pid 0)
(error "rusage" "trying to fork" (errormsg)))
((= pid 0)
(if (execvp (cadr argv)
(let ((v (make-array-of-strings (cdr argv))))
(print v)
(do ((i 0 (+ i 1)))
((>= i (length (cdr argv)))
(newline))
(display (string*-ref v i))
(display #\space))
v))
(error "rusage" (cadr argv) (errormsg))))
(else
(begin
(if (< (waitpid! pid c-null 0) 0)
(error "rusage" "waitpid" (errormsg)))
(show-rusage (cadr argv) RUSAGE_CHILDREN)
;;; (show-rusage "after" RUSAGE_SELF)
)))))
(define (show-rusage label who)
(let ((rusage (make-s-rusage*)))
(if (< (getrusage! who rusage) 0)
(error "rusage" "getrusage" (errormsg)))
(display label) (display #\:) (display #\newline)
(display-rusage rusage) (display #\newline)
(display #\newline)))
(define (display-rusage rusage)
(let ((display-line (lambda (dispcons)
(display (car dispcons))
(display #\tab)
(display ((cdr dispcons) rusage))
(display #\newline)))
(map2-orderly (lambda (proc arg1s)
(do ((a1 arg1s (cdr a1))
(vals '()))
((null? a1)
(reverse vals))
(cons (apply proc (list (car a1)))
vals))))
(s-timeval->real (lambda (timeval)
(+ (s-timeval*-tv_sec
timeval)
(/ (s-timeval*-tv_usec
timeval)
1e6)))))
(map2-orderly display-line `(("user time"
. ,(lambda (r)
(s-timeval->real
(s-rusage*-ru_utime r))))
("sys time"
. ,(lambda (r)
(s-timeval->real
(s-rusage*-ru_stime r))))
("max rss " . ,s-rusage*-ru_maxrss)
("text size" . ,s-rusage*-ru_ixrss)
("data size" . ,s-rusage*-ru_idrss)
("stack size" . ,s-rusage*-ru_isrss)
("page recls" . ,s-rusage*-ru_minflt)
("page flts" . ,s-rusage*-ru_majflt)
("swaps " . ,s-rusage*-ru_nswap)
("input ops" . ,s-rusage*-ru_inblock)
("output ops" . ,s-rusage*-ru_oublock)
("msgs sent" . ,s-rusage*-ru_msgsnd)
("msgs recd" . ,s-rusage*-ru_msgrcv)
("volunt cs" . ,s-rusage*-ru_nvcsw)
("invol cs" . ,s-rusage*-ru_nivcsw)))))
(define (errormsg)
(if (> errno sys_nerr)
"Unknown error"
(string*-ref sys_errlist errno)))
(define (make-array-of-strings list-of-strings)
(do ((arr (make-string* (length list-of-strings)))
(i 0 (+ i 1))
(whats-left list-of-strings (cdr whats-left)))
((null? whats-left)
arr)
(string*-set! arr i ;(string-append
(car whats-left)
; (string (integer->char 0)))
)))
and the output of "rusage hello.unsafe":
hello, world
hello.unsafe:
user time 0.0874990000000
sys time 0.429999000000
max rss 228
text size 0
data size 0
stack size 0
page recls 96
page flts 10
swaps 0
input ops 15
output ops 0
msgs sent 0
msgs recd 0
volunt cs 104
invol cs 0
In case anyone is interested, the machine is an old SGI
PowerChallenge, which uses 33 or 40 MHz MIPS CPUs of 1992 vintage or
so. Note that the above program is not reliable because bigloo can't
deal with 32-bit integers properly--if I understand bigloo's integers,
it will print something odd after 13:37:03 UT on Jan 10, 2004 (I love
emacs calc). To conquer the world, one still needs to fix that, give
bigloo a real debugger, put dynamic loading into the interpreter,
shrink the memory footprint a bit more, sell and support a nice
development interface, and a few other things :-). But you can write
system utilities in bigloo, if it happens you don't need or care about
those things.
--
Raj Manandhar (205) 544-3965 ···@msfc.nasa.gov
NASA/George C. Marshall Space Flight Center I'm not affiliated with
Code ES84 NASA.
Huntsville, AL 35812
My URL is http://xanth.msfc.nasa.gov/~raj/home.html
Bryan O'Sullivan <···@serpentine.com> writes:
| s> *Some* C programs do this now.
|
| Effectively all C programs on all resonably modern non-embedded
| systems link against shared libraries these days.
The "do this" was referring to bloated libraries, not dynamic linking.
| s> Just because Solaris comes with a bunch of bloated code doesn't
| s> make it good practice.
|
| Solaris comes with approximately the same set of libraries as every
| other Unix variant.
Hence the comment that unix is starting to smell bad. Efficiency is
possible, but you have to want it. These days, no one seems to care.
SunOS manages to be much more memory efficient than Solaris.
| s> "Not only is unix dead, it's starting to smell bad" -- Rob Pike.
| Pike is hardly one to talk, if projects like sam and 8 1/2 are
| indicators of where his tastes lie.
I use those things every day, and I like them fine. If you want cute
icons, Inferno has them.
From: Bryan O'Sullivan
Subject: Re: Unclear thought is the problem, not the solution
Date:
Message-ID: <87k9u3fnbp.fsf_-_@serpentine.com>
s> *Some* C programs do this now.
Effectively all C programs on all resonably modern non-embedded
systems link against shared libraries these days.
s> Just because Solaris comes with a bunch of bloated code doesn't
s> make it good practice.
Solaris comes with approximately the same set of libraries as every
other Unix variant.
s> "Not only is unix dead, it's starting to smell bad" -- Rob Pike.
Pike is hardly one to talk, if projects like sam and 8 1/2 are
indicators of where his tastes lie.
<b
--
Let us pray:
What a Great System. ···@eng.sun.com
Please Do Not Crash. ···@serpentine.com
·····@P6 http://www.serpentine.com/~bos
"Not only is unix dead, it's starting to smell bad" -- Rob Pike.
[Bryan O'Sullivan]
| Pike is hardly one to talk, if projects like sam and 8 1/2 are
| indicators of where his tastes lie.
considering that the same institution and largely the same people created
Unix and failed monumentally to appreciate scalability back in the 70's, we
can safely draw the conclusion that they are attracted to cute little
immature things, but begin to hate them as soon as they grow up and start
to attract other guys, as well.
the reason Unix is starting to smell bad is that this once cute little
immature system still isn't potty-trained at age 25, but requires every
sysadm and every programmer to parttime as babysitter for this cretin that
now weighs 200 pounds and still makes a mess.
and what's their solution? create another cute little immature thing that
shows every sign of being just as bad at scalability and adaptability once
it gets out of the maternity ward.
when will we realize that all systems are going to weigh 200 pounds when
they grow old enough to be useful and that we might as well optimize for
their behavior at that size instead of reluctantly admitting that things
grow. well nutured, an operating system can grow to an ace student with
excellent health and 200 pounds of muscles, instead of beer-drinking slob
with 200 pounds of fat.
#\Erik
--
those who do not know Lisp are doomed to reimplement it
·······@netcom.com (Bill Newman) writes:
> PS. I haven't seen anything about guile on the Scheme newsgroup for a
> while. Does that mean that it's not going anywhere or that people
> have decided that guile doesn't belong there?
>
Guile is actually pushed for the first 'official' release, and you
shouldn't wait too long to see one. It moved from Tom Lord to
Jim Blandy, and the mailing list seems much more lively since then.
Miro