I am a student who has been asked to prepare a report on limitations of
Lisp. However, I have never used Lisp before and cannot get reference
material on it here in Kenya. I would be grateful if someone could try and
explain to me about Lisp and its limitations as a programming language.
Thanks a lot!
Hasita Shah
From: Erik Naggum
Subject: Re: Help required on Limitations of Lisp
Date:
Message-ID: <3088068138912331@naggum.no>
* Hasita Shah
| I am a student who has been asked to prepare a report on limitations of
| Lisp. However, I have never used Lisp before and cannot get reference
| material on it here in Kenya.
I suggest you report the limitations of your teacher's pedagogical skills
to whoever has the authority to fire him and refund any expenditures you
may have accumulated.
there are many things that can fruitfully be requested of students with
little or no experience or knowledge to report on, in the hopes that
throwing a whole class into deep water will eventually let a few survivors
make it to land, but I am uncertain both of the nature of those who survive
under such conditions and of the usefulness of focusing on the limitations
of unknown languages. even after many years of study, it takes bright and
conscientious students to be able to distinguish their own limitations from
those of the language under study. limitations of a language usually
surface in practical use: when the amount of manual labor required to
obtain a needed behavior is growing out of proportions, one may be looking
at the limitation of a language, whether it be its specification or its
implementation, but even then most likely the implementation.
not that "the limitations of Lisp" wouldn't be an interesting report, but I
would much rather it be prepared by somebody with at least 20 years of
experience with the language and the specification, plus at least 5
different implementations, than an ignorant student under pressure.
you can still get access to reference material if you're on the Internet.
point your browser to <URL:http://www.harlequin.com/books/HyperSpec/>.
this is the specification for Common Lisp (or, as they point out, a derived
product of the specification as published by American National Standards
Institute (ANSI)).
#\Erik
--
if you think this year is "97", _you_ are not "year 2000 compliant".
see http://sourcery.naggum.no/emacs/ for GNU Emacs 20-related material.
"Hasita Shah" <········@iconnect.co.ke> wrote:
>I am a student who has been asked to prepare a report on limitations of
>Lisp. However, I have never used Lisp before and cannot get reference
>material on it here in Kenya.
Nice to see Kenya's at last made it onto the Internet. You can
download free implementations of Lisp from various WWW pages.
> I would be grateful if someone could try and
>explain to me about Lisp and its limitations as a programming language.
It's possible to express any computable algorithm in Lisp. It's
completely general purpose, supports both functional, procedural and
object-oriented programming styles. It's also extensible, so that if
you ever need a feature the language doesn't support, you can always
extend the language to incorporate that feature. If you don't like
the syntax, you can change the syntax using read macros.
I can't think of any serious limitations. Occasionally, you'll find
an implementation of another language to be better for a particular
purpose, e.g. Java or TCL for graphical interfaces might be better
than what is offered by many vanilla Lisps. There are some languages
which are better for specific purposes, e.g. SNOBOL beats everything
else at string processing. I think array processing code looks
neater in C or Pascal than it does in Lisp, though that's a matter
largely of personal taste, and it would be perfectly possible to write
the appropriate read macros to rectify the situation -- I just can't
be bothered.
A common fallacy is that Lisp is slow. That is a bit like saying
that German is loud. Speed depends on the implementation, not on the
language.
>Thanks a lot!
>Hasita Shah
Le Hibou http://homepages.enterprise.net/hibou/
"What the ... This is Lambic! Where's my culture of amoebic
dysentery?" -- Gary Larson
> "Hasita Shah" <········@iconnect.co.ke> wrote:
> >I am a student who has been asked to prepare a report on limitations of
> >Lisp. However, I have never used Lisp before and cannot get reference
> >material on it here in Kenya.
The report will be short and elegant, just like programs in the language. At
least your report will be vastly shorter than a similar report on the
limitations of nearly every other language.
Use www.altavista.digital.com and www.dejanews.com to find the good
stuff about Lisp from the net.
Good luck!
From: Emergent Technologies
Subject: Re: Help required on Limitations of Lisp
Date:
Message-ID: <ug1p4r6rn.fsf@cape.com>
Limitations of Lisp:
1. No more powerful than a Turing machine; able to compute only
recursively enumerable functions.
2. Only able to compute functions in P in a reasonable amount of
time; takes too long on NP functions.
Emergent Technologies <········@cape.com> writes:
> Limitations of Lisp:
>
> 1. No more powerful than a Turing machine; able to compute only
> recursively enumerable functions.
>
> 2. Only able to compute functions in P in a reasonable amount of
> time; takes too long on NP functions.
I was going to post something similar. :-)
3. Victim of substantial misinformation campaigns suggesting
it has limitations that are probably imagined.
See http://world.std.com/~pitman/PS/dpANS.html
(Since the time of writing this article, CL has become an ANSI standard
but the points it makes about various supposed crticisms of Lisp
are still relevant.)
Hasita Shah wrote:
> I am a student who has been asked to prepare a report on limitations of
> Lisp. However, I have never used Lisp before and cannot get reference
> material on it here in Kenya. I would be grateful if someone could try and
> explain to me about Lisp and its limitations as a programming language.
At the risk of attempting to be helpful, I'll try to answer this
question.There's two things in your question which are a bit ill-defined.
LISP
defines a family of several programming languages. For the purpose of
this response, I will assume you mean common lisp, the variety which
seems most popular for real-world use.
I would say that the limitations of lisp are typically in various
implementations, and, while not intrinsic to the language, some are
very common.
1) The flexibility makes it hard to deliver compact executables.
2) Many systems do not have high-quality optimizers so code will
sometimes be substantially slower than other languages.
3) Programming enviorments are typically several years behind
those available in many other languages.
On the strong side, lisp's extreme flexibility leads to short
software prototyping and development cycles.
dave
David Hanley wrote:
> 1) The flexibility makes it hard to deliver compact executables.
However, machines nowadays have fairly large memories, so compact
executables are seldom required.
> 2) Many systems do not have high-quality optimizers so code will
> sometimes be substantially slower than other languages.
This is true, but as you make clear, it's a system limitation
rather than a language limitation.
> 3) Programming enviorments are typically several years behind
> those available in many other languages.
Such as? In practice, for developing code in other languages, I
use Emacs (which was written in Lisp), have to save the code,
then compile it, then run it. I debug it by putting in printf
or writeln statements. In Lisp I'd have trace and break, the
editor and listener would be integrated, and compilation would be
done when the functions are loaded. This is comparing vanilla Lisp
implementations with vanilla C or Pascal implementations.
> On the strong side, lisp's extreme flexibility leads to short
> software prototyping and development cycles.
True.
So why are people (including, sometimes, myself) using Java, often
abandoning Lisp in the process?
(1) Lack of an agreed byte code means there's no portability of
object code, and no way of safely downloading and executing compiled
Lisp over the Internet.
(2) Lisp is not integrated with the Internet the way Java is.
(3) Lack of an agreed standard for graphics.
These are not intrinsic limitations. They're the result of the
Lisp community not getting its act together. They can be overcome.
In the case of (1), Lisp has a potential advantage over Java: its
primitives do complex things, and so the overheads of fetch and
interpret are often less than compiling in-line or subroutine calls.
The result is that byte-code interpreted Lisp is not significantly
slower than native-code compiled Lisp. In the case of (2) and
(3), Lisp can catch up.
> dave
--
Le Hibou (mo bheachd fhe/in: my own opinion)
"What the ... This is Lambic! Where's my culture of amoebic
dysentery?"
-- Gary Larson
Donald Fisk <···········@bt-sys.bt.spamblock.co.uk> writes:
> David Hanley wrote:
>
> > 1) The flexibility makes it hard to deliver compact executables.
>
> However, machines nowadays have fairly large memories, so compact
> executables are seldom required.
add to that the fact that mainstream applications have passed
lisp in size long ago. On a Macintosh, MCL is a high-speed dwarf
compared to Microsoft Office. On my Sun workstation, the stand-alone
CL-HTTP webserver (full-featured, including the Allegro CL compiler)
has a slightly smaller footprint on the disk than the Netscape client
(in terms of memory Netscape uses 10-20% more on startup and needs
twice as much as CL-HTTP after one week's runtime).
--
(regards
(espen vestre))
Espen Vestre wrote:
> Donald Fisk <···········@bt-sys.bt.spamblock.co.uk> writes:
>
> > David Hanley wrote:
> >
> > > 1) The flexibility makes it hard to deliver compact executables.
> >
> > However, machines nowadays have fairly large memories, so compact
> > executables are seldom required.
>
> add to that the fact that mainstream applications have passed
> lisp in size long ago. On a Macintosh, MCL is a high-speed dwarf
> compared to Microsoft Office. On my Sun workstation, the stand-alone
> CL-HTTP webserver (full-featured, including the Allegro CL compiler)
> has a slightly smaller footprint on the disk than the Netscape client
> (in terms of memory Netscape uses 10-20% more on startup and needs
> twice as much as CL-HTTP after one week's runtime).
I agree that for larger applications lisp applications may well be
smaller than their C/C++/ctc counterparts. A problem is that small
application may require static binding to very large libraries.
dave
David Hanley <·····@netright.com.delete.me.silly> wrote:
> A problem is that small
> application may require static binding to very large libraries.
Why? Small functions I call from the environment. Same as I call small
programs under Unix from the shell - and don't count in the shell into
the application size of the small utility.
bye, Georg
Georg Bauer wheezed these wise words:
> Why? Small functions I call from the environment. Same as I call small
> programs under Unix from the shell - and don't count in the shell into
> the application size of the small utility.
This argument is as contrived as the "Hello, World" argument used to
justify C. Not everyone runs apps in the development environment.
In fact, damn few people do that!
Try looking at the real world for a change. It's unfortunate that Lisp
machines aren't running on every desktop, but ignoring the reasons why
won't help. Whether right or wrong, the mainstream orthordoxy is to
run each app in its own process and protected memory space. Is the
Lisp orthordoxy to run code in a Lisp machine? If so, then this _may_
explain why it is that someone would ask about the "Limitations of
Lisp" instead of the advantages. If you do things differently from the
mainstream orthordoxy, you'll be seen by those who believe in that
orthordoxy to be weird. (See the origins of the word 'wierd' - it's
not a bad thing at all, but most people _think_ it is. Stigma.)
In other words, your view is valid, but so is the mainstream view, if
only because most people will say it is. "Valid" in this context means
"accepted and used by people", and nothing more. People will use
whatecer they use _because they can_. We may think it strange that so
many people use C/Cobol/Basic/etc, but they see us the same way.
It isn't even necessary for one group to understand the other. You
only need to _think_ that you understand. The operative phrase is
"because they can". Once you understand that, nothing else matters.
They do it because they can, because you can't stop them, and because
they don't see any need to stop themselves. Eventually they may learn
to see things as we do, or they may discover some other truth. They
may arrive at the understanding we have by a different route, or they
may never arrive at all. Whatever they do, it'll be because they can.
--
Please note: my email address is munged; You can never browse enough
"Oh knackers!" - Mark Radcliffe
* Martin Rodgers wrote:
> Georg Bauer wheezed these wise words:
>> Why? Small functions I call from the environment. Same as I call small
>> programs under Unix from the shell - and don't count in the shell into
>> the application size of the small utility.
> This argument is as contrived as the "Hello, World" argument used to
> justify C. Not everyone runs apps in the development environment.
> In fact, damn few people do that!
In fact, almost everyone does that. They just use the development
environment for a different language which isn't compatible with the
Lisp one. Either way you lose of course.
--tim
Tim Bradshaw wheezed these wise words:
> In fact, almost everyone does that. They just use the development
> environment for a different language which isn't compatible with the
> Lisp one. Either way you lose of course.
I think it depends on whether you need to know that a language is in
there, somewhere. Most people don't know and don't care. In other
words, there are are environments which target "users" and
environments that target "developers".
Power users need not make this distinction, of course. Most apps don't
include any kind of "user language", as they're too small and simple.
The bigger apps, like spreadsheets, can make end user programming
possible with a relatively smooth learning curve. The serious
programming languages are designed by and for developers, and are
rather less suitable for users. This is a casual user / power user
distinction. Some people will sacrifice power for quick results.
You only lose if you find yourself fighting the machine, or the people
who control the machine. We used to hear people complaining about how
unsuitable computer keyboards were for touch typing. Lab engineers
were blamed for designing keyboards for themselves instead of touch
typists. Eventually this changed.
If computers could only be used by programmers and engineers...we'd
probably be a lot happier. ;) I frequently have to remind myself that
I'm also a user, even if that makes me a power user. This is why I
decided, in the early 80s, to never design user interfaces for users.
15 years later, my own UI designs are still hard to use without either
the docs, or the source code. Everything else I write is designed by
people who have a much better idea of what a user can cope with, based
on years of experience supporting them.
OTOH, I have a far better idea what programmers can cope with, being
one myself, and using for years software targetted directly at
programmers (compilers, linkers, assemblers, meta compilers, etc).
IME, tools designed for programmers can greatly differ from tools
designed for users. It's frustrating, but it's getting better. It's
not so hard now to include a script language in an app, whatever the
platform may be.
As I said above, you only lose if you find yourself fighting the
machine, or the people who control the machine. Lisp is one way to
help relax the control that other people have over the machine and
what you can do with it. Lisp is not the only way, but some of the
other ways might not necessarily be so different from the Lisp way.
--
Please note: my email address is munged; You can never browse enough
"Oh knackers!" - Mark Radcliffe
Donald Fisk wrote:
> David Hanley wrote:
>
> > 1) The flexibility makes it hard to deliver compact executables.
>
> However, machines nowadays have fairly large memories, so compact
> executables are seldom required.
Well, it depends. If it's going to be distributed, it helps. It
wouldnbe tough to write 'zip' in lisp with most common lisp systems,
because of
executable size. However, some modern applications are large enough
that an extra 1.5 MB might not matter.
Some 'applications' are actually a number of small executables.
For example, the product I'm working on now is ~25 executables.
if each one require static binding to ~1.5 MB, w're talking
~40 MB in statically-bound code. It would be nice if some of this could
be alleviated with a lisp DLL or VM.
> > 3) Programming enviorments are typically several years behind
> > those available in many other languages.
>
> Such as? In practice, for developing code in other languages, I
> use Emacs (which was written in Lisp), have to save the code,
> then compile it, then run it. I debug it by putting in printf
> or writeln statements. In Lisp I'd have trace and break, the
> editor and listener would be integrated, and compilation would be
> done when the functions are loaded. This is comparing vanilla Lisp
> implementations with vanilla C or Pascal implementations.
Well, if that is the yardstick for comparison, yes, lisp is asgood
or better. But there are many very high-quality java
development enviornemnts available. Visual cafe, jbuilder,
VisualAge, etc.
If tools of a similar quality were available for Lisp, I could
seriously
justify using it on my job.
dave
From: Erik Naggum
Subject: Re: Help required on Limitations of Lisp
Date:
Message-ID: <3088257863633044@naggum.no>
* David Hanley
| Some 'applications' are actually a number of small executables. For
| example, the product I'm working on now is ~25 executables. if each one
| require static binding to ~1.5 MB, w're talking ~40 MB in
| statically-bound code. It would be nice if some of this could be
| alleviated with a lisp DLL or VM.
why static binding? would you still need 25 executables in Lisp?
* (whoever)
| > > 3) Programming enviorments are typically several years behind
| > > those available in many other languages.
that's because those other languages _require_ such environments to be
useful, while Lisp systems get by easily without. it doesn't make sense to
do more than is necessary to solve a given problem, especially if what you
do extra has zero impact on your earnings and a major impact on your costs.
to make C++ usable at _all_, it _has_ to have those environments, so it
makes perfect business sense to build them, too. note that C++ programmers
are approaching Lisp programmers in terms of productivity through the use
of these environments, but Lisp programmers are still way ahead.
also note that Lisp was years _ahead_ of other languages for a long, long
time, and that many of the ideas from the Lisp world have been adopted by
the other world. also note that Lisp systems have remained largely
constant in size since about 1990, even falling in size, while Microsoft
products easily require 100 times more memory and 50 times more powerful
CPUs to do exactly the same ting (as far as user productivity is concerned)
as they did in 1990. why are people still concerned with the size of Lisp
programs?
* David Hanley
| Well, it depends. If it's going to be distributed, it helps. It would
| be tough to write 'zip' in lisp with most common lisp systems, because of
| executable size. However, some modern applications are large enough that
| an extra 1.5 MB might not matter.
if people insist on running every function from the command line, then it's
going to be a problem, but I never saw anybody complain about Word Macros
in Visual Basic on the grounds that you had to load all of Word 7 to run a
snippet of code. or that to run an X application you had to fire up X
first. or that to run a Unix command you had to boot a machine, log in and
run a shell. all of these environments issues are taken for granted. in
other words: it depends on what you consider your environment. when most
users spend their entire working day in a single application, what good
does it really do to complain about the size of a standalone program when a
function call would have far smaller costs when run inside an application
the user is already running than a standalone program could ever hope for?
#\Erik
--
if you think this year is "97", _you_ are not "year 2000 compliant".
see http://sourcery.naggum.no/emacs/ for GNU Emacs 20-related material.
Erik Naggum wrote:
> * David Hanley
> | Some 'applications' are actually a number of small executables. For
> | example, the product I'm working on now is ~25 executables. if each one
> | require static binding to ~1.5 MB, w're talking ~40 MB in
> | statically-bound code. It would be nice if some of this could be
> | alleviated with a lisp DLL or VM.
>
> why static binding? would you still need 25 executables in Lisp?
Static binding because none of the lisp windows compilers I'm
aware of have a seperate .dll for lisp. if they did, it would solve
the problem right off.
>
>
> * (whoever)
> | > > 3) Programming enviorments are typically several years behind
> | > > those available in many other languages.
>
> that's because those other languages _require_ such environments to be
> useful, while Lisp systems get by easily without.
Hmmm... I would agree that these are less useful it lisp, but theywould be
useful in any case. Tightly integerated gui builders,
graphical object inspectors, executables-on-a-button-click, etc,etc.
If they weren't useful in a lisp enviormnent, I wouldn't be gritting my
teeth due to their abscence.
> it doesn't make sense to
> do more than is necessary to solve a given problem, especially if what you
> do extra has zero impact on your earnings and a major impact on your costs.
If it shortens your development cycle, it sure does have an effect on
earnings.
> to make C++ usable at _all_, it _has_ to have those environments, so it
> makes perfect business sense to build them, too. note that C++ programmers
> are approaching Lisp programmers in terms of productivity through the use
> of these environments, but Lisp programmers are still way ahead.
I agree that it is generally easier to program in lisp, and that it's
betterfor many purposes, but I don't think you can really substantiate this
claim either way. You can always create a contrived enough test case
to get the results you want.
1) A data simulation that requires a lot of tweaking: lisp wins.
2) A gui with COM/WIN32/etc integration: C++ wins.
3) A web applet: Java wins.
> also note that Lisp was years _ahead_ of other languages for a long, long
> time, and that many of the ideas from the Lisp world have been adopted by
> the other world.
And....???
> also note that Lisp systems have remained largely
> constant in size since about 1990, even falling in size, while Microsoft
> products easily require 100 times more memory and 50 times more powerful
> CPUs to do exactly the same ting (as far as user productivity is concerned)
> as they did in 1990. why are people still concerned with the size of Lisp
> programs?
You are stubbornly ignoring the issue. Using C/C++ I can, and do,make
fairly useful 100K windows apps that start in a fraction of a second
when clicked as an icon. The size of enviorments or a particular application
is irrelevant.
This is particularly true for an obvious reason: people aren't going to
make
big lisp apps unless they can do some small ones first. If people can't make
small apps in lisp, they're not going to progress to big ones. Very simple.
By the way, can you exaplin how user productivity is tied to CPU
power in your model?
> * David Hanley
> | Well, it depends. If it's going to be distributed, it helps. It would
> | be tough to write 'zip' in lisp with most common lisp systems, because of
> | executable size. However, some modern applications are large enough that
> | an extra 1.5 MB might not matter.
>
> if people insist on running every function from the command line, then it's
> going to be a problem, but I never saw anybody complain about Word Macros
> in Visual Basic on the grounds that you had to load all of Word 7 to run a
> snippet of code. or that to run an X application you had to fire up X
> first. or that to run a Unix command you had to boot a machine, log in and
> run a shell. all of these environments issues are taken for granted.
Yes, exactly. Word macros are specifically designed to work on
worddocuments, and only make sense in that context, same for graphical
applications
and a graphical enviorment.
To place lisp in the same context makes no sense at all--it's a general
purpose language that ought to be good for writing all sorts of applications.
If I make a handy-dandy program that I want to distribute to a lot of users,
(say a file compresion program) no one will use it if they have to fire up
a lisp enviornment first to run it.
> in
> other words: it depends on what you consider your environment. when most
> users spend their entire working day in a single application,
I've not notice this.
> what good
> does it really do to complain about the size of a standalone program when a
> function call would have far smaller costs when run inside an application
> the user is already running than a standalone program could ever hope for?
What you seem to be suggesting here is that the user works in alisp shell.
That's unrealistic in the basic sense, but a lisp OS will
solve the issue. How can users be induced to run a lisp OS?
What if the lisp OS is a virtual machine that runs under the OS,
like a Java VM? The "exectuables" would be bytecode with a tiny
stub header that would feed them to the VM for execution. So you can
click on an icon on the desktop and run a compact lisp executable.
There would only be one VM running at a given time. If there's
two applications running, they will simply run as seperate threads in the same
VM space, for RAM savings.
How about the problem of application paucity? Well, what if the VM
is a java VM with extra lisp instructions? There are quite a few useful
utils, apps and widgets in java already available. There are VM's too,
which could simply be extended. This would be a very effective
way to get a LISP os off the ground.
It's an idea....
dave
From: Raf Cavallaro
Subject: Re: Why a lisp OS? Re: Help required on Limitations of Lisp
Date:
Message-ID: <64ba4f$nv2@news-central.tiac.net>
David Hanley wrote in message
<·················@netright.com.delete.me.silly>...
> Yes, exactly. Word macros are specifically designed to work on
>worddocuments, and only make sense in that context, same for graphical
>applications
>and a graphical enviorment.
>
> To place lisp in the same context makes no sense at all--it's a general
>purpose language that ought to be good for writing all sorts of
applications.
>If I make a handy-dandy program that I want to distribute to a lot of
users,
>(say a file compresion program) no one will use it if they have to fire up
>a lisp enviornment first to run it.
I believe this is one of the reasons that the Dylan language/Lisp dialect
was designed.
Clearly, small deliverables are something a general purpose programming
language should be able to accomplish, and common Lisp has problems with
this.
BTW, I like the idea of common Lisp compiled to Java byte codes. Are there
any developments along these lines in the works? Are Java's reflection
capabilities sufficient to the task of representing Lisp closures?
Raf
From: Robert D. Skeels
Subject: Lisp to J-code (was: Why a lisp OS...)
Date:
Message-ID: <B08FEDCC-B6A36@207.217.3.98>
Nov 11, 1997 20:08, Raf Cavallaro <·······@pop.tiac.net> wrote:
>BTW, I like the idea of common Lisp compiled to Java byte codes. Are
there
>any developments along these lines in the works? Are Java's reflection
>capabilities sufficient to the task of representing Lisp closures?
Kawa is a free Scheme interpreter in Java that compiles Scheme to J-code.
<http://www.copsol.com/sgmlimpl/tools/kawa/faq.html>
A few R4RS items are missing. Kawa supposedly allows access to Java's
classes and methods. I haven't tried it myself as I can't figure out how to
set the Kaffe classpath under MkLinux. Should try under MacOS someday, but
that would require getting the JDK to run with MRJ 1.5
(eqv? InternetC++ Java)
=> #t
(member? 'Java cryptic-language)
=> #t
(cool? (and Scheme Dylan))
=> #t
Robert D. Skeels ······@earthlink.net | "created and sent via the
Los Angeles, CA illustration & design | Cyberdog mail system"
http://home.earthlink.net/~athene | eti kai nun Hellada phileo
IBM 350 MHz PowerPC 604e unveiled: world's fastest microcomputer cpu
From: Per Bothner
Subject: Re: Lisp to J-code (was: Why a lisp OS...)
Date:
Message-ID: <64grku$deu$1@rtl.cygnus.com>
In article <··············@207.217.3.98>,
Robert D. Skeels <······@earthlink.net> wrote:
>Kawa is a free Scheme interpreter in Java that compiles Scheme to J-code.
> <http://www.copsol.com/sgmlimpl/tools/kawa/faq.html>
The actual official Kawa web page is at:
http://www.cygnus.com/~bothner/kawa.html.
>Nov 11, 1997 20:08, Raf Cavallaro <·······@pop.tiac.net> wrote:
> Are Java's reflection
> capabilities sufficient to the task of representing Lisp closures?
Kawa does not use Java's reflection features to implement closures.
Instead it uses helper objects (currently arrays) to represent the
captured environments. This is similar to how Java inner classes
are implemented, though Kawa pre-dates inner classes.
It is likely that future versions of Kawa will use the Java
reflection features more heavily.
--
--Per Bothner
Cygnus Solutions ·······@cygnus.com http://www.cygnus.com/~bothner
From: Erik Naggum
Subject: Re: Why a lisp OS? Re: Help required on Limitations of Lisp
Date:
Message-ID: <3088289335876823@naggum.no>
* David Hanley
| Static binding because none of the lisp windows compilers I'm aware of
| have a seperate .dll for lisp. if they did, it would solve the problem
| right off.
I have talked to some people who profess to understand this DLL business,
and although they went on and on about how good and new this was (I think
the first time I used shared objects where high segments under TOPS-10 in
1980 or so), it never became clear to me exactly how much you pay for it.
one grudgingly admitted to a cost of about 5% overhead in a call-heavy
environment compared to static linking. some of the *huge* Windows
applications appeared to run 20% _faster_ with static linking than with
DLLs in a test but this was not even commented on. I guess DLLs are more
politically correct than performance.
| If it shortens your development cycle, it sure does have an effect on
| earnings.
I believe this is an unsubstantiated myth. the evidence that it is true is
simply lacking. "first-to-market" is _not_ the guarantee of success that
many (managers) believe it is. (those winners who were "first to market"
were not really _first_, they were first to hit _big_.) nothing suggests
that frequent releases is a guarantee of success, either. still, many
(managers) believe this, too, like gospel.
| I agree that it is generally easier to program in lisp, and that it's
| betterfor many purposes, but I don't think you can really substantiate
| this claim either way. You can always create a contrived enough test
| case to get the results you want.
if so, it would be very interesting indeed to look at the test cases.
various strongly substantiated reports indicate from 30% sustained average
(Richard P. Gabriel, on Lucid) to 10-fold peak advantage for Lisp/CLOS over
C++.
| > also note that Lisp was years _ahead_ of other languages for a long,
| > long time, and that many of the ideas from the Lisp world have been
| > adopted by the other world.
|
| And....???
I'm trying to point out to you that you criticize a snapshot of Lisp, while
you are obviously willing to judge other languages in terms of a process of
ongoing changes and improvements. this may be because you think that Lisp
is a "finished" language in the sense that you don't expect further changes
or development. again, this is _your_view_of_Lisp_, and has very little to
do with Lisp itself. that you also limit what Lisp is so that it _cannot_
be whatever would have been a winner indicates that you either ignore or
don't know the past.
| You are stubbornly ignoring the issue.
geez, first DLLs and now this. are you a member of the Martin Rodgers fan
club, too?
| This is particularly true for an obvious reason: people aren't going to
| make big lisp apps unless they can do some small ones first.
oh, I see, so this is "obvious", which means you won't even _attempt_ to
elaborate and you will accuse people of "stubbornly ignoring foo", for
suitable values of "foo" if they reject your "obvious" claim. great!
FYI, this is _your_ view of Lisp and of applications. you may find people
who agree with you, but the important thing with beliefs is to challenge
them and find contrary views. your response to that is, of course, that
I'm "stubbornly ignoring the issue", as if we had a government approved
agenda and I was somehow in violation of it by bringing up ideas and angles
that you are dead set against considering.
| If people can't make small apps in lisp, they're not going to progress to
| big ones. Very simple.
it's actually amusing, in a sad and tragic sense, that you have already
decided on this and is impervious to empirical evidence to the contrary.
| By the way, can you exaplin how user productivity is tied to CPU power in
| your model?
FWIW, they are clearly unrelated. users are no more productive with 50
times faster CPU's with 100 times more memory if they use the latest and
greatest software from Microsoft. an acute observation from at least 20
years ago was that every program grew to consume all available resources.
this observation has been strongly reinforced on the Windows platform.
as for productivity in real money terms: according to a report in the
Economist earlier this year, the cost of producing any piece of business
communication dropped along with advances in computers from 1950 through
1980. from 1985 through 1995, it rose sharply enough to consume all
earnings made since 1950. it is significantly more expensive to produce a
business letter in 1997 than it was in 1950. despite many technological
advances with a very high price tag, a secretary does not produce any more
measurable output now than in 1950 -- in fact, the evidence suggests that
obtaining _half_ the productivity of a 1950's secretary in 1997 is a major
feat. the fact that managers write their own reports at down to 1/10th of
the speed of a secretary that used to be paid 1/10th of their salary also
means that the time spent producing a letter or a report can cost as much
as 100 times more than it did in 1950, when managers scribbled unreadable
notes and very quick and efficient typists corrected their spelling,
grammer, and language and adhered to "company style" effortlessly.
there are other areas where computers have introduced major advances, such
as communication, but this didn't happen until wide area networks began to
be deployed in the mid-90's, and this was clearly _not_ due to massive
increases in CPU and memory on the disconnected PC's, who _still_ are not
very good at interchanging information. (they're _very_ good at being the
same kind of propaganda and marketing reception equipment as TV's, though.)
| To place lisp in the same context makes no sense at all--it's a general
| purpose language that ought to be good for writing all sorts of
| applications. If I make a handy-dandy program that I want to distribute
| to a lot of users, (say a file compresion program) no one will use it if
| they have to fire up a lisp enviornment first to run it.
"you are stubbornly ignoring the issue."
it's _your_view_ of Lisp that is at fault here, not Lisp. people _were_
willing to run Windows as a separate environment apart from their usual DOS
commands to run "Windows software". people are willing to fire up various
programming environments (except they aren't called that) to run useful
programs _inside_ them already, many of them in your neighborhood (i.e.,
Windows), such as Excel or Word.
| > in other words: it depends on what you consider your environment. when
| > most users spend their entire working day in a single application,
|
| I've not notice this.
that suggests to me that you may have neglected to notice other aspects of
the users of which you speak so generally in such specific terms, as well.
| > what good does it really do to complain about the size of a standalone
| > program when a function call would have far smaller costs when run
| > inside an application the user is already running than a standalone
| > program could ever hope for?
|
| What you seem to be suggesting here is that the user works in alisp shell.
uh, now I wonder if you have noticed much around you at all. how do people
interact with their (Windows) environment today if it is _not_ that they
work in what is effectively a C++ shell? would they have to type in C++
code for you to consider it a C++ environment? they fire up "apps" (what a
godawful abbreviation) _inside_ that environment, and some of them may have
to start up the whole environment first (remember the DOS command grossly
misnamed "win"?). Unix users work in a shell that works hard to make it
immaterial if a "command" is a builtin or a "function" residing on disk as
a separate program. whether a program is a part of the "shell" or is fired
up in a separate (operating system) process should not matter to the user.
indeed, that it matters to _you_ is symptomatic of a strained relationship
with environments, programming or otherwise. other Windows users seem to
be equally tied up in their _particular_ environment, completely forgetting
any semblance of conceptualization of "environment" or its purpose for a
computer user. I wonder why this is. I wonder if this is a contributing
cause to my strongly disliking the Microsoft "environments", too.
| That's unrealistic in the basic sense, but a lisp OS will solve the
| issue. How can users be induced to run a lisp OS?
this, again, suggests that you have a _very_ narrow view of Lisp. it is
apparent that you don't even think of Lisp as an environment, much less an
environment-building language. I do. to you, Lisp is a language, and any
application is built "with Lisp, on top of my existing environment", which
is Windows, right? in a sense, Windows is a result of the way C++ builds
environments, like Unix is a result of how C does it. if you had looked at
the Lisp machines, you would have seen what kind of an environment Lisp can
build. likewise, the Emacs programming and text processing environment
(I'll bet you classify Emacs as an "editor") is a result of what it is easy
and convenient to do in Emacs Lisp.
also, users aren't induced to run operating systems or even applications --
they are induced to do whatever is necessary to continue to get paid. many
programmers complain that even _they_ cannot choose their own tools, for
fear of losing their jobs. (this appears, for some _odd_ reason, to apply
mostly to Windows programmers.)
#\Erik
--
if you think this year is "97", _you_ are not "year 2000 compliant".
see http://sourcery.naggum.no/emacs/ for GNU Emacs 20-related material.
In article <················@naggum.no>, Erik Naggum <······@naggum.no> wrote:
[...]
>various strongly substantiated reports indicate from 30% sustained average
>(Richard P. Gabriel, on Lucid) to 10-fold peak advantage for Lisp/CLOS over
>C++.
Hey, while I'm here, what would you recommend as a good way to learn
about CLOS? I'm hoping for something a bit more specific than "just use
it." I try that, but I'm used to the C++ object model which is apparently
the exact opposite of CLOS. C++ has objects bound to functions while CLOS
has the functions bound to the objects.
[...]
>| By the way, can you exaplin how user productivity is tied to CPU power in
>| your model?
>
>FWIW, they are clearly unrelated. users are no more productive with 50
>times faster CPU's with 100 times more memory if they use the latest and
>greatest software from Microsoft. an acute observation from at least 20
>years ago was that every program grew to consume all available resources.
>this observation has been strongly reinforced on the Windows platform.
This is also very true on the Mac. On my old 8+ year-old IIci running
Netscape 1.1N, things went much more quickly than my brand new Quadra 650
with an upgrade card running Netscape 3. Also, my C++ environment,
Codewarrior, has such an overblown GUI that it just crawls along.
Suprisingly, the compiler is lightning-fast. Go figure.
Another unfourtinate effect of "progress" has been OS8. The new macs
running the new system are slower than the old macs running the old
system. Maybe we should turn the clock back a few years and start all
over?
For fun go to dejanews and look at comp.sys.mac.programmer.codewarrior
about a year back. All of this was discussed in great detail.
-------------
Subject: Re: I got CW11. Here's how I feel.
From: ·····@col.hp.com (David E Allen)
Date: 1997/01/20
Message-ID: <··········@nonews.col.hp.com>
Newsgroups: comp.sys.mac.programmer.codewarrior
: I can only sympathize with programmers with slow 68k machines like yours.
And only a couple years ago the 68k machines were "fast". But software's one
and only job in life is to fill up ram and disk and choke all but the fastest,
newest cpu's. :-( I still find that perplexing, but I don't know of anyone
who is breaking that rule... How long before we will be sympathizing for those
with the "slow" powerpc machines? :-(
But thanks to Ron's suggestions, I bought the "Discovering Programming on
the Mac", which has CW8, and does a respectable job. I think I'll stick with
that rev and leave the glorious new stuff to those with tons of ram and disk
and cpu...
dave allen, colorado springs
--------------
[snip of remaining mild flamage, however accurate]
>#\Erik
>--
>if you think this year is "97", _you_ are not "year 2000 compliant".
>
>see http://sourcery.naggum.no/emacs/ for GNU Emacs 20-related material.
B.B. --I am not a goat!
From: Matthias Hoelzl (tc)
Subject: Re: Why a lisp OS? Re: Help required on Limitations of Lisp
Date:
Message-ID: <87k9eew284.fsf@gauss.muc.de>
········@airmail.net (Bryant Brandon) writes:
> Erik Naggum <······@naggum.no> wrote:
> >various strongly substantiated reports indicate from 30% sustained average
> >(Richard P. Gabriel, on Lucid) to 10-fold peak advantage for Lisp/CLOS over
> >C++.
>
> Hey, while I'm here, what would you recommend as a good way to learn
> about CLOS? I'm hoping for something a bit more specific than "just use
> it." I try that, but I'm used to the C++ object model which is apparently
> the exact opposite of CLOS. C++ has objects bound to functions while CLOS
> has the functions bound to the objects.
If you are looking for a complete book on CLOS programming I can
recommend you
Object Oriented Programming in Common Lisp
A Programmer's Guide to CLOS
Sonya E. Keene
Addison-Wesley 1988
ISBN 0-201-17589-4
If you are just looking for some chapters where you can see what
programming with CLOS looks like you might want to read Chapter 14 in
Winston & Horn's Lisp (3rd edition) and chapters 21 to 24 for examples
of applications, or Chapter 11 in Paul Graham's ANSI Common Lisp.
For a rapid overview that includes some comparisons with C++ see
Appendix A of
The Art of the Metaobject Protocol
Gregor Kiczales, Jim des Rivi`eres and Daniel G. Bobrow
The MIT Press, 1991
ISBN 0-262-11158-6 (hardcover)
ISBN 0-262-61074-4 (paperback)
Matthias
Erik Naggum wheezed these wise words:
> I guess DLLs are more politically correct than performance.
That's a good way of putting it. Of course, this ignores all the other
applications of DLLs, like linking to code that you didn't write, or
letting other people's code link to yours. Static linking won't help
there, as it isn't common for Windows apps to be delivered as unlinked
.OBJ files. DLLs, on the other hand, have always been a part of
Windows, as has the use of callbacks and other features that can
exploit code in a DLL.
> | If it shortens your development cycle, it sure does have an effect on
> | earnings.
>
> I believe this is an unsubstantiated myth.
I also have doubts about the "time to market" argument, as the issues
are far more complex than merely when you deliver the code. If you
have a deadline to meet, it helps if you can deliver code as close to
it, if not actually before it, as possible. The market appears to be
sometimes forgiving when it shouldn't, and unforgiving when sometimes
it should.
On the other hand, consider in-house development. There a hell of a
lot of that, even if it does have a low profile. There's also contract
work. All of which can benefit from rapid development., if only
because it gives developers time for a life as well as work.
> | You are stubbornly ignoring the issue.
>
> geez, first DLLs and now this. are you a member of the Martin Rodgers fan
> club, too?
You might not recognise these issues as important, but why not accept
that others do? Not that I necessarily agree with David Hanley on
this, but why doubt him when he says he can do something? Perhaps he
can write better code that MS! that wouldn't be hard to believe.
Also, 100K apps are very different from the monsters that can be found
in, say, MS Office.
> it's _your_view_ of Lisp that is at fault here, not Lisp. people _were_
> willing to run Windows as a separate environment apart from their usual DOS
> commands to run "Windows software". people are willing to fire up various
> programming environments (except they aren't called that) to run useful
> programs _inside_ them already, many of them in your neighborhood (i.e.,
> Windows), such as Excel or Word.
The key point here is that these apps aren't called programming
environments, nor do they look like programming environments.
There's a hell of a difference between Excel and LWW!
"User programming" has been a part of apps for many years, but users
don't need to know anything about programming in order to use these
apps. Let's not confuse the user's view of an app with the the power
user's view. The power user may think nothing of programming, but if
we can't all users to be power users.
It can certainly be useful to blur the distinctions between user and
programmer, and as you've pointed out, Emacs exploits this blurring.
So do Unix shells. Power tools for power users.
Curiously, it has been a dream of Bill Gates to make scripting
available to every part of the OS, and this too sounds like a power
tool. Even stranger, MS are doing this! I'm not sure they're doing it
well, but it's not yet clear to me how all of it will, and I've not
seen any of the SDK releases for the last few years.
So, it seems to me that many people are heading in the same direction,
but approaching from different directions. Add to that the confusion
of OS and language politics, as it's no wonder that there's so much
misunderstanding. (Consider the "Doomed Rivals" chapter in Richard
Dawkins' book, The Blink Watchmaker. Dawkins blames the confusion on
Darwin's 9th edition of a certain book.)
It's very tempting to dismiss anyone who does things a little
differently from us as wrong or stupid, but if we do this, then we
shouldn't be suprised if they do the same thing to _us_. After all,
we're doing things different to them, are we not? What makes us so
special that everyone should recognise our superiority?
--
Please note: my email address is munged; You can never browse enough
"Oh knackers!" - Mark Radcliffe
From: Erik Naggum
Subject: Re: Why a lisp OS? Re: Help required on Limitations of Lisp
Date:
Message-ID: <3088448477038896@naggum.no>
* Martin Rodgers
| Curiously, it has been a dream of Bill Gates to make scripting available
| to every part of the OS, and this too sounds like a power tool. Even
| stranger, MS are doing this!
yeah, right. the only thing we can trust Bill Gates to make is yet another
phenomenally braindamaged design in a new piece of crappy software that
makes hostile viruses wreak even more havoc, even easier! when every Intel
CPU in the world runs his virus transport software, he can take over the
whole world. just imagine how useful it would be (to him) to put a virus
in some ActiveX junk on the Microsoft home pages and seconds later have all
Pentium computers at the Department of Justice mysteriously crash _hard_
with the CMPXCHG8B bug. if I were in Bill Gates' shoes, I'd sure wish I
could stop law enforcement with such simple means. law-abiding citizens:
just say NO!
#\Erik
--
if you think this year is "97", _you_ are not "year 2000 compliant".
see http://sourcery.naggum.no/emacs/ for GNU Emacs 20-related material.
Erik Naggum wheezed these wise words:
> if I were in Bill Gates' shoes,
When I want anti-MS diatribes, I read comp.lang.java.advocacy.
--
Please note: my email address is munged; You can never browse enough
"Oh knackers!" - Mark Radcliffe
···@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin Rodgers) writes:
> Erik Naggum wheezed these wise words:
>
> > if I were in Bill Gates' shoes,
>
> When I want anti-MS diatribes, I read comp.lang.java.advocacy.
> --
> Please note: my email address is munged; You can never browse enough
> "Oh knackers!" - Mark Radcliffe
Many of us here use lisp in a free software environment. Gates would
rather (his own quotation) every computer in the world run
Windows. This makes us inherintly enemies.
John Arley Burns wheezed these wise words:
> Many of us here use lisp in a free software environment. Gates would
> rather (his own quotation) every computer in the world run
> Windows. This makes us inherintly enemies.
This attitude is not unique to Lisp programmers. Whether I agree with
you or not is irrelevant - esp here, in comp.lang.lisp.
Followup set to comp.os.ms-windows.advocacy.
--
Please note: my email address is munged; You can never browse enough
"Oh knackers!" - Mark Radcliffe
From: Kelly Murray
Subject: Re: Why a lisp OS? Re: Help required on Limitations of Lisp
Date:
Message-ID: <64bbkn$5f4$1@news2.franz.com>
In article <·················@netright.com.delete.me.silly>, David Hanley <·····@netright.com.delete.me.silly> writes:
>> ..mucho snippero..
>>
>> What you seem to be suggesting here is that the user works in alisp shell.
>> That's unrealistic in the basic sense, but a lisp OS will
>> solve the issue. How can users be induced to run a lisp OS?
>>
>> What if the lisp OS is a virtual machine that runs under the OS,
>> like a Java VM? The "exectuables" would be bytecode with a tiny
>> stub header that would feed them to the VM for execution. So you can
>> click on an icon on the desktop and run a compact lisp executable.
>> There would only be one VM running at a given time. If there's
>> two applications running, they will simply run as seperate threads in the same
>> VM space, for RAM savings.
>>
You're suggesting exactly what Erik was talking about.
If you've got a Lisp running on your machine that can be SHARED
by all your lisp applications, then the size of a Lisp is a non-issue,
and startup times for applications are instant, and in fact,
because the Lisp environment/library is so rich, major applications
can be written using very little code. It does matter if it's a VM,
or natively compiled code.
A LispOS takes this a step farther, and says why do you even NEED
an OS, when all the useful applications are written
as small Lisp "applets"?
This is great, except for the true state of the world doesn't match.
Where are all the lisp "applets" and needed utilities?
And where is a Lisp environment that can be actually BE SHARED
by multiple lisp applications? I think both are missing.
-Kelly Murray
David Hanley wheezed these wise words:
> Static binding because none of the lisp windows compilers I'm
> aware of have a seperate .dll for lisp. if they did, it would solve
> the problem right off.
Gambit C for Win32 lets you link to a runtime DLL. This is probably
the reason why I'm writing more Scheme than CL code recently. Ideally,
it would be possible to do this with a CL compiler. Unfortunately, the
choice of CL compilers for Win32 is limited, and I've not yet found
one that works in this way.
No doubt a CL to C compiler could be ported to Win32 and modified to
support placing the runtime in a DLL. As noted above, this has been
done with Gambit C, so why not CLiCC or Eclipse? There's probably
nothing to stop this from being done - it just hasn't been done yet.
I'd be happy to pay for such a compiler, if it included support for as
many Win32 features as, say, LWW. Meanwhile, when I want a CL for
Win32, I'll use LWW and live with static linking, or use Gambit C for
all those "tiny" apps that make static linking look expensive.
> Hmmm... I would agree that these are less useful it lisp, but theywould be
> useful in any case. Tightly integerated gui builders,
> graphical object inspectors, executables-on-a-button-click, etc,etc.
All highly desirable features. Once you get used to them, and you're
expected to use them, it's hard to live without them.
I've seen two styles of interface builders. One is the kind that edits
relationships between interface elements, and the other edits the
positions of elements within a "form". The former is used by ACL/PC
and LWW, while the latter is used by VC++, VB, etc. When you're
interested in very fine details of the user interface, the latter can
give you more control. A layout manager lets the machine handle more
of these details, which is great for the programmer, but not so great
for the user who knows _exactly_ what the user interface should look
like, sometimes down to the pixel level.
Both interface builder styles are valid, IMHO, as they satisfy
different needs. The "executables-on-a-button-click" point is another
such issue. Not all programmers need to create an executable often
enough to justify this. If a Lisp environment lacks such a button,
then maybe that tells us about the needs of most Lisp programmers.
Similarly, the presence of such a button in an IDE for C++, VB, Java,
or whatever, tells us about the needs of other groups of programmers.
Again, I think that these needs are equally valid. I just don't expect
to see many C++ environments with a listener window!
> If they weren't useful in a lisp enviormnent, I wouldn't be gritting my
> teeth due to their abscence.
I know the feeling. I'm reminded of Kent Pitman's recent post in which
he mentioned choice space. Should we rationalise this absence and make
a virtue out of it? I don't know. On the other hand, I can appreciate
why some C++ programmers, used to these features, are so appalled by
the lack of them in environments for other languages, like Lisp or
Java. It's a valid need, even if it's one not shared by all
programmers. So they gravitate to the tools that _do_ provide them.
> If it shortens your development cycle, it sure does have an effect on
> earnings.
Yep. Consider how much time it costs to add these features to an
environment. While the time should eventually pay for itself, how many
days will it take to write that code? IMHO it makes sense for the
vendor to add the code, so that their time can be easily - and more
quickly - repaid. For those of us who merely use the tools, we don't
even have the time. It's our personal time, and that's even more
expensive than the time we get paid for.
> 1) A data simulation that requires a lot of tweaking: lisp wins.
> 2) A gui with COM/WIN32/etc integration: C++ wins.
> 3) A web applet: Java wins.
The right tool for the job.
> And....???
And a lot of people are either ignorant of Lisp's superiority, or
they're ignoring it. Fortunately ignorance is not the same as
stupidity, but you can convince them that Lisp is still alive,
you first have to get these people to listen to you.
Maybe they're confusing Lisp with Cobol...? _We_ know there's a
difference, but does a Lisp newbie? I wonder. Stigma is a problem.
> You are stubbornly ignoring the issue. Using C/C++ I can, and do,make
> fairly useful 100K windows apps that start in a fraction of a second
> when clicked as an icon. The size of enviorments or a particular application
> is irrelevant.
Size is still being used a metric, so I think that Erik is making a
fair point here. However, he may be missing another point, which is
that C++'s problems aren't yet large enough to counter the C++ myths.
C++ has code bloat, but that appears to be ignored by many people,
while Lisp has the stigma of age. As if age could be a problem instead
of a virtue, like maturity.
IMHO C++ has stagnation and inbreeding, but do these things hurt C++?
I think they will, and there are compiler writers who certainly say
so. Not that everyone listens, mind you.
> This is particularly true for an obvious reason: people aren't going to
> make
> big lisp apps unless they can do some small ones first. If people can't make
> small apps in lisp, they're not going to progress to big ones. Very simple.
This is why I use Gambit C. I can write small and very fast code with
it. In theory, I could also do this in CL. It's just easier to use
Gambit C, as that compiler is already available.
The old argment in favour of C is the "Hello, World" app. I don't
think this is a weak argument because that's not a useful app, but
because it doesn't scale well. It does, however, make it appear easy
to learn C. It's only later that you discover how hairy the language
is! By then you've already learned C, so the damage is done. You'll
believe that you can write code in it. Worse, you _can_ write code in
it! Hairy code, but it's still code.
Perhaps with Lisp you have to be more patient, until you reach a point
where it all clicks and makes sense. This is why I'm not suprised that
so few programmers discover Lisp, never mind the virtues of using
Lisp. Too many programmers just don't have the time to _learn_.
Instead, they can find loads of people telling them how wonderful
C/C++ is, so it must be true. How can those weird Lisp people be
right, when all they do is talk about "reflection", "functional
closures", and other jargon? IME, the programmers most negative about
Lisp are those who don't know what these terms mean, never mind how
useful such features might be. So we also have a jargon stigma.
How about you and me write a book called, "Common Lisp for C++
Programmers"? We could teach Lisp using exactly the kind of code that
can be found in many C++ tutorials, thus avoiding the AI stigma, with
loads of emphesis on solutions to "real world" problems, like database
and networking apps. The final code example could be a simple web
server with CGI support, mapping queries to function calls, plus
dynamically pouring results from database queries into HTML pages.
There are enough commercial web server tools that do this to class
such a server as pretty damn "real world"!
Hmm. Maybe a better title would be "Web Applications in Common Lisp"?
That would grab more attention on the bookshelves, which in turn would
give Lisp a higher profile, leading to less ignorance of Lisp, etc.
It might even sell a few more commercial Lisp systems...
--
Please note: my email address is munged; You can never browse enough
"Oh knackers!" - Mark Radcliffe
From: David H Wild
Subject: Re: Why a lisp OS? Re: Help required on Limitations of Lisp
Date:
Message-ID: <47e80e3140dhwild@argonet.co.uk>
In article <·························@news.demon.co.uk>,
Martin Rodgers
<···@this_email_address_intentionally_left_crap_wildcard.demon.co.uk>
wrote:
> The old argment in favour of C is the "Hello, World" app. I don't
> think this is a weak argument because that's not a useful app, but
> because it doesn't scale well. It does, however, make it appear easy
> to learn C. It's only later that you discover how hairy the language
> is! By then you've already learned C, so the damage is done. You'll
> believe that you can write code in it. Worse, you _can_ write code in
> it! Hairy code, but it's still code.
I used to work at a management training centre before desktop machines came
in. One of the things that we did for senior managers was to let them do a
small program, in BASIC, with the intention of showing them how important
was the attention to detail needed. We found, however, that they were going
away with the idea that "Programming's easy! I did some with only half an
hour of explanation, so for a professional it should be an absolute
doddle." They forgot completely that they had been given a line by line
specification and that there was a professional there to explain all the
details and hold their hands when necessary. We had to get rid of this from
the course.
--
__ __ __ __ __ ___ _____________________________________________
|__||__)/ __/ \|\ ||_ | /
| || \\__/\__/| \||__ | /...Internet access for all Acorn RISC machines
___________________________/ ······@argonet.co.uk
Uploaded to newnews.dial.pipex.com on Thu,13 Nov 1997.19:37:45
David Hanley <·····@netright.com.delete.me.silly> writes:
> This is particularly true for an obvious reason: people aren't going to
> make
> big lisp apps unless they can do some small ones first. If people can't make
> small apps in lisp, they're not going to progress to big ones. Very simple.
Gnus and Emacs all run quite well and are very large programs. Myth
debunked ;}
From: Barry Margolin
Subject: Re: Why a lisp OS? Re: Help required on Limitations of Lisp
Date:
Message-ID: <64shcu$1re@tools.bbnplanet.com>
In article <··············@urquan-kohr-ah.mesas.com>,
John Arley Burns <······@urquan-kohr-ah.mesas.com> wrote:
>David Hanley <·····@netright.com.delete.me.silly> writes:
>
>> This is particularly true for an obvious reason: people aren't going to
>> make
>> big lisp apps unless they can do some small ones first. If people can't make
>> small apps in lisp, they're not going to progress to big ones. Very simple.
>
>Gnus and Emacs all run quite well and are very large programs. Myth
>debunked ;}
Hardly. Emacs is a big Lisp app, but it was implemented by someone
(Stallman) who's a master programmer and already had over a decade of
experience programming in Lisp. Presumably he started out writing small
Lisp apps in the 70's. In between he worked on a Lisp OS (he contributed
to the OS for the LMI Lambda). He'd also previously implemented an Emacs
editor in an even more obscure language (TECO).
I don't know the history of GNUS, so I can't comment on that, except to say
that incremental add-ons to an existing facility have different
requirements from developing new applications from scratch.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Cambridge, MA
Support the anti-spam movement; see <http://www.cauce.org/>
Please don't send technical questions directly to me, post them to newsgroups.
David Hanley <·····@netright.com.delete.me.silly> wrote:
> Well, it depends. If it's going to be distributed, it helps. It
> wouldnbe tough to write 'zip' in lisp with most common lisp systems,
> because of
> executable size.
Why? I have a function (compress "pathname" "outputpathname") in my lisp
environment. The function takes up approx. 5K (estimated from the
compiled code). What's so big about that?
Don't count the Lisp-environment. That's just my notion of a shell.
Actually MCL is much smaller than the Win95 Explorer and does take only
slightly more memory than the MacOS Finder.
Or do _you_ count in the size of the Visual C++ MFC*.DLL and the
associated C++ runtime libraries for Win95? They take up much more
memory than MCL on a Mac.
Nah, the size-argument is mostly ridiculous in the modern OS market. The
sizes - and memory usage - of MCl or ACL (don't know about LWW) don't
count in times of many-megabyte-memory systems like Windows95 or
possibly NT.
bye, Georg
Georg Bauer wheezed these wise words:
> Or do _you_ count in the size of the Visual C++ MFC*.DLL and the
> associated C++ runtime libraries for Win95? They take up much more
> memory than MCL on a Mac.
The difference between the MFC runtime and the runtime for a Lisp
system like ACL/PC or LWW is that you can dynamically link the MFC
runtime. That can easily be 1 MB of code for MFC 4.0. Later versions
may be larger.
I'm not trying to defend C++, but this the way that a C++ programmer
will look at this issue. In fact, it may be more of a Windows than a
C++ thing. C++ isn't the only language to exploit dynamic linking.
> Nah, the size-argument is mostly ridiculous in the modern OS market. The
> sizes - and memory usage - of MCl or ACL (don't know about LWW) don't
> count in times of many-megabyte-memory systems like Windows95 or
> possibly NT.
Strangely, this isn't mentioned much by Windows developers. I don't
recall reading any reviews of Windows development tools that have
mentioned this. It's possible that all these reviewers have "blinkers"
that prevent them from seeing this issue as it really is. It may also
be possible that they're not considering the demands of monster apps
because most Windows developers don't write monster apps.
Perhaps we should be discussing the limitations of perspective instead
the limitations of a language? For some kinds of app, code sharing
will be a critical feature. Install enough of these apps on a machine
and the disk space saving may be sufficiently significant in order to
justify dynamic linking. Of course dynamic linking uses large amounts
of memory, as DLLs tend to have the same base load address, so the
code will need to be relocated at load time. There are, however, other
savings. High memory demands don't seem to hurt people badly enough to
kill the popularity of DLLs.
Could it be that some tools have better support for dynamic linking
than others, and that developers choose these tools will be more ready
to recognise this as useful? Could it also be that if your tools have
poor support for dynamic linking then you'll be more likely to try to
rationalise and justify _not_ using dynamic linking?
I don't know. I just note that this isn't even a question for Windows
developers. Windows has always had dynamic linking. I don't know about
the early Windows SDKs, but Windows development has for many years had
very good support for C programmers. Maybe it's just a coincidence
that it's very easy to exploit dynamic linking in C.
Now, ideally we reshape the universe to support Lisp, and thus banish
all forms of dynamic linking. Unfortunately, it's several decades too
late to do that. I recall that a PL/I compiler had support for dynamic
linking the runtime on at least one platform. The p-system is another
example of a language/OS exploiting dynamic linking. At least one Unix
has benefitted from using dynamic linking. Early versions of a certain
Steve Jobs OS were criticised for paging heavily, and it was suggested
that dynamic linking would change this. Sun have used it, too.
Feature or bug? Who cares. The real question is whether _Lisp_ should
exploit it, or leave it to languages like C. Is it really so hard to
exploit dynamic linking in Lisp, or is it just one of those silly
political "not invented here" things?
BTW, I recall reading that WCL supports dynamic linking. Go figure.
--
Please note: my email address is munged; You can never browse enough
"Oh knackers!" - Mark Radcliffe
In article <·························@news.demon.co.uk>,
···@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin
Rodgers) wrote:
> Georg Bauer wheezed these wise words:
>
> > Or do _you_ count in the size of the Visual C++ MFC*.DLL and the
> > associated C++ runtime libraries for Win95? They take up much more
> > memory than MCL on a Mac.
>
> The difference between the MFC runtime and the runtime for a Lisp
> system like ACL/PC or LWW is that you can dynamically link the MFC
> runtime. That can easily be 1 MB of code for MFC 4.0. Later versions
> may be larger.
Macintosh Common Lisp uses shared libraries. The kernel, the compiler and
the library are each a shared library. Those are shared by
Lisp applications.
--
http://www.lavielle.com/~joswig/
Rainer Joswig wheezed these wise words:
> Macintosh Common Lisp uses shared libraries. The kernel, the compiler and
> the library are each a shared library. Those are shared by
> Lisp applications.
That's excellent news.
Thanks.
--
Please note: my email address is munged; You can never browse enough
"Oh knackers!" - Mark Radcliffe
Martin Rodgers wrote:
+---------------
| Of course dynamic linking uses large amounts of memory, as DLLs tend
| to have the same base load address, so the code will need to be relocated
| at load time.
+---------------
Just a note that for many years on Unixes such as SGI's Irix (and others,
I presume) there's been the notion of "quickstarting" a collections of DSOs
(a.k.a. DLLs), meaning that they're rewritten (either at build time or later,
when a "re-quickstart" program is run) so their addresses don't conflict.
This allows them to be linked into a process's address space without the
overhead of relocating anything at run time. [If a quickstart failure is
detected, then "rld" silently does the needed relocations the hard way.]
Installed applications known to the system (how they're "known" varies
by OS, but usually it's taken care of for any "installed product") will
automatically be re-quickstarted when new versions of DSOs (DLLs) are
installed.
This has proved so effective (on those OSs that provide it) that almost
nothing is statically linked any more.
-Rob
p.s. Try "man rqs" or "man rqsall" to see if it exists on your system.
-----
Rob Warnock, 7L-551 ····@sgi.com http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673 [New area code!]
2011 N. Shoreline Blvd. FAX: 650-933-4392
Mountain View, CA 94043 PP-ASEL-IA
Rob Warnock wheezed these wise words:
> This has proved so effective (on those OSs that provide it) that almost
> nothing is statically linked any more.
ISTR that this can also be done with Win32 DLLs, by altering the base
load addresses for each DLL after linking. It's not ideal, but I guess
it can be done. Since some of the DLLs will be part of the OS, the
value of this optimisation may be limited.
Also, components are often shared between apps, so its not just the
system DLLs that complicate things. OTOH. there may be space savings
when a number of components share code, like several OCX controls that
use MFC are used by an app. Components unique to an app can easily be
optimised to avoid load address conflicts.
Life is full of trade-offs. ;)
--
Please note: my email address is munged; You can never browse enough
"Oh knackers!" - Mark Radcliffe
Wade Hennessey wheezed these wise words:
> WCL does support dynamic linking. The executable for "hello world" is 41k on
That's what I remember reading a few years ago. if I used a SPARC
machine, I'd be very happy with WCL.
Thanks.
--
Please note: my email address is munged; You can never browse enough
"Oh knackers!" - Mark Radcliffe
···@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin Rodgers) writes:
>Feature or bug? Who cares. The real question is whether _Lisp_ should
>exploit it, or leave it to languages like C. Is it really so hard to
>exploit dynamic linking in Lisp, or is it just one of those silly
>political "not invented here" things?
The PSL (Lisp) system for B6700s _depended_ on dynamic linking for compilation.
There are Lisp systems now where the Lisp environment is one or more DLLs.
--
John �neas Byron O'Keefe; 1921/02/04-1997/09/27; TLG,TLTA,BBTNOTL.
Richard A. O'Keefe; RMIT Comp.Sci; http://www.cs.rmit.edu.au/%7Eok
Richard A. O'Keefe wheezed these wise words:
> The PSL (Lisp) system for B6700s _depended_ on dynamic linking for compilation.
> There are Lisp systems now where the Lisp environment is one or more DLLs.
I didn't say that no Lisp ever did it. I fondly recall using Cambridge
Lisp, which dyamically linked - and unlinked - code. So I don't doubt
that it can be done! I've seen it done.
I asked if it was hard to do. There are at least two commercial Lisps
for Windows that _don't_ dynamically link to Lisp code in DLLs.
Is PSL available for Windows? Cambridge Lisp? Why don't ACL/PC or LWW
do what these Lisps did? Do Window DLLs make it harder to do, or is it
just one of those silly political "not invented here" things?
The quotes around the phrase "not invented here" are every important.
Page 11 of the 1992 DRM gives some reasons for using dynamic linking.
On Page 14 Ike Nassi made a distinction between CL and Dylan that _may
possibly_ explain the lack of dynamic linking of Lisp code in a Lisp
system: "Common Lisp is aimed primarily at the Lisp community, while
Dylan is accessible to application developers unfamiliar with Lisp.
Common Lisp is oriented towards exploratory programming with delivery
capability, while Dylan is oriented more towards delivery with
exploratory capability."
Is this a fair summary? If so, has this changed since 1992? Even if
Dylan isn't considered to be a Lisp (I'm not saying that, BTW), it may
be close enough to Lisp for us to consider what Ike Nassi's words are
telling us. Perhaps only DylanWorks users can tell us that. ;)
--
Please note: my email address is munged; You can never browse enough
"There are no limits." -- ad copy for Hellraiser
Georg Bauer wrote:
> David Hanley <·····@netright.com.delete.me.silly> wrote:
>
> > Well, it depends. If it's going to be distributed, it helps. It
> > wouldnbe tough to write 'zip' in lisp with most common lisp systems,
> > because of
> > executable size.
>
> Why? I have a function (compress "pathname" "outputpathname") in my lisp
> environment. The function takes up approx. 5K (estimated from the
> compiled code). What's so big about that?
Nothing, It's a small source and function.
> Don't count the Lisp-environment. That's just my notion of a shell.
> Actually MCL is much smaller than the Win95 Explorer and does take only
> slightly more memory than the MacOS Finder.
That's great, but very often one must ship an execuatable to a
client(s).If the executable is 2MB for a relatively simple program, this may
cause
problems. It might not! It depends. But it _can_ be a problem.
> Or do _you_ count in the size of the Visual C++ MFC*.DLL and the
> associated C++ runtime libraries for Win95? They take up much more
> memory than MCL on a Mac.
So? They already exist, or are installed once. If lisp systemshad a VM
or some DLL they could link to at runtime people wouldn't
counti ut either. But people _do_ notice .exe size.
dave
* Donald Fisk wrote:
> David Hanley wrote:
>> 1) The flexibility makes it hard to deliver compact executables.
> However, machines nowadays have fairly large memories, so compact
> executables are seldom required.
But caches are not that large, so executables with good locality are
required, and there's a reasonable correlation between large
executable & poor locality unfortunately. In fact, if the stuff in the
executable that's making it big is actually ever used, poor locality
is more-or-less inevitable in some sense, though a bright system
should be able to minimise it by ensuring things that happen together
are close together in the image.
--tim