Help required on Limitations of Lisp
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 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
Erik Naggum
* 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.
Donald Fisk
"Hasita Shah" <phil...@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
Henry Baker
> "Hasita Shah" <phil...@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!
Emergent Technologies
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.
Kent M Pitman
Emergent Technologies <emer...@cape.com> writes:
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.)
David Hanley
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
Donald Fisk
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)
Espen Vestre
Donald Fisk <donal...@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))
David Hanley
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
Erik Naggum
* 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?
Tim Bradshaw
* 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
David Hanley
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
Bryant Brandon
In article <30882893...@naggum.no>, Erik Naggum <cle...@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: da...@col.hp.com (David E Allen)
Date: 1997/01/20
Message-ID: <5c0hs8$i...@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!
Raf Cavallaro
David Hanley wrote in message
<3468D017...@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
David Hanley
Espen Vestre wrote:
> Donald Fisk <donal...@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
Erik Naggum
* 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.)
Kelly Murray
In article <3468D017...@netright.com.delete.me.silly>, David Hanley <da...@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
Martin Rodgers
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
Matthias Hoelzl (tc)
theg...@airmail.net (Bryant Brandon) writes:
> Erik Naggum <cle...@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
Marc Wachowitz
Martin Rodgers wrote:
> Perhaps with Lisp you have to be more patient, until you reach a point
> where it all clicks and makes sense.
Huh? Both in my own experience, and from what I've been told by some
teachers, the fundamental principles of Lisp can be learned very quickly,
and for adequate problem areas applied more easily than lots of other
programming languages. The problems arise when someone supposedly wants
to learn Lisp, but in fact tries to express idioms from a very different
programming language in Lisp. The point isn't that one couldn't express
many different approaches in Lisp (there's probably not much to which an
expert can't adapt Lisp), but that people tend to confuse particular ways
of coding with more general problem solving.
One teacher who worked with linguists who had not even used a computer
before their course (this was quite a few years before the PC era),
reported that he was deeply impressed how soon these people were able
to write Lisp programs for their professional work, using Lisp to solve
their actual problems - not some toy stuff like what's common in courses.
Good teachers and good tutorials are certainly welcome, but the mental
approach to learning and programming is much more relevant than all the
technical problems together, as far as I can tell.
> 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.
[...]
Too many people in this profession are simply coders, usually not very
interested in the first place to think much beyond the horizon of turning
a pretty much worked out solution into executable code in one and only one
programming language, of which they've seen some examples.
Frankly, I'm not sure why I should want such people to touch Lisp - all
its flexibility won't help a closed mind. Don't misunderstand that - I'm
all for providing as much and as high quality an education to people being
interested in learning - i.e. enjoying to go beyond what they know, even
partially invalidating what they once "knew" - and removing barriers that
people can really invest energy and time in such things, not only for a
job, but in many different areas of life. However, the latter are really
philosophical/social/political problems (aka "economy has quite destructive
effects for humanity"), and the human condition won't be helped very much
by introducing just another few people to Lisp programming.
If you want more dull coders programming horrible applications in Lisp,
something like "Web Applications in Common Lisp" might help. If you want
more people to act intelligently and use the available tools skillfully,
I fear you're looking in the wrong corner for a solution. Bad programmers
using Lisp do still write bad programs - probably even more so than with
tools where the amount of damage they can do is limited by (in your or my
view perhaps irritating) technical constraints.
-- Marc Wachowitz <m...@ipx2.rz.uni-mannheim.de>
Robert D. Skeels
Nov 11, 1997 20:08, Raf Cavallaro <raf...@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 ath...@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
David H Wild
In article <MPG.ed3ce8c3...@news.demon.co.uk>,
Martin Rodgers
<mcr@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
___________________________/ dhw...@argonet.co.uk
Uploaded to newnews.dial.pipex.com on Thu,13 Nov 1997.19:37:45
Georg Bauer
David Hanley <da...@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
David Hanley <da...@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
Martin Rodgers
Marc Wachowitz wheezed these wise words:
> Martin Rodgers wrote:
> > Perhaps with Lisp you have to be more patient, until you reach a point
> > where it all clicks and makes sense.
>
> Huh? Both in my own experience, and from what I've been told by some
> teachers, the fundamental principles of Lisp can be learned very quickly,
> and for adequate problem areas applied more easily than lots of other
> programming languages. The problems arise when someone supposedly wants
> to learn Lisp, but in fact tries to express idioms from a very different
> programming language in Lisp. The point isn't that one couldn't express
> many different approaches in Lisp (there's probably not much to which an
> expert can't adapt Lisp), but that people tend to confuse particular ways
> of coding with more general problem solving.
Yes, the problem is when a programmer learns Lisp, as that implies
that they already "know" how programming is done. If the style of
programming that they learned is significantly different to Lisp's
style, then there could be problems. As you said, idioms.
One of the possible distinctions between different kind of languages
is that some languages are extensible. I get the strong impression
that this is a tough idea for many programmers. If their concept of
what a compiler can do comes from somewhere like the Dragon book, they
might not think of languages as possibly being interactive, with
incremental compilers, capable of compiling code into the compiler's
own environment.
Maybe there's a good reason for this omission, but it was only earlier
this year that I discovered that the comp.compilers FAQ didn't include
PJ Brown's book, Writing Interactive Compilers and Interpreters. It
could be that this book is too simple (too "basic" would be a bad pun)
for the comp.compilers folk, but it does at least do an excellent job
of explaining some compiler concepts that go beyond the traditional
batch compiler.
> One teacher who worked with linguists who had not even used a computer
> before their course (this was quite a few years before the PC era),
> reported that he was deeply impressed how soon these people were able
> to write Lisp programs for their professional work, using Lisp to solve
> their actual problems - not some toy stuff like what's common in courses.
Excellent. Now all we have to do is reach all the programmers whose
minds have already been currupted with batch oriented languages.
> Good teachers and good tutorials are certainly welcome, but the mental
> approach to learning and programming is much more relevant than all the
> technical problems together, as far as I can tell.
I agree. I'm just saying that this mental approach is either a rarity,
or that it gets very little press. There are certainly non-technical
reasons why a good tool might be neglected.
> Too many people in this profession are simply coders, usually not very
> interested in the first place to think much beyond the horizon of turning
> a pretty much worked out solution into executable code in one and only one
> programming language, of which they've seen some examples.
Yep, too many "9 to 5" programmers.
> Frankly, I'm not sure why I should want such people to touch Lisp - all
> its flexibility won't help a closed mind. Don't misunderstand that - I'm
> all for providing as much and as high quality an education to people being
> interested in learning - i.e. enjoying to go beyond what they know, even
> partially invalidating what they once "knew" - and removing barriers that
> people can really invest energy and time in such things, not only for a
> job, but in many different areas of life. However, the latter are really
> philosophical/social/political problems (aka "economy has quite destructive
> effects for humanity"), and the human condition won't be helped very much
> by introducing just another few people to Lisp programming.
Alas, improving the human condition isn't necessarily how the market
operates. What does the market reward?
> If you want more dull coders programming horrible applications in Lisp,
> something like "Web Applications in Common Lisp" might help. If you want
> more people to act intelligently and use the available tools skillfully,
> I fear you're looking in the wrong corner for a solution. Bad programmers
> using Lisp do still write bad programs - probably even more so than with
> tools where the amount of damage they can do is limited by (in your or my
> view perhaps irritating) technical constraints.
I'm assuming that there are some good programmers out there who don't
yet know of Lisp, or that they've only heard of Lisp from people who
don't know what they're talking about. We know that such people exist,
as we've seen both kind here in comp.lang.lisp. I don't expect "dull
coders" to want to read "Web Applications in Common Lisp". I'd expect
to find anyone reading such a book to be unusually curious! My point
is that such a book would quickly reward such a reader with the
message, "Lisp can do things that you already do, and it may even help
you do them better, faster, etc."
Alternately, you could just assume that anyone who doesn't already
know Lisp never will, and wouldn't want to. I'm trying to be a little
more positive than that. What can we offer the curious programmer,
whop is currently browsing bookshelves full of books about web
development, visual programming, Java, Perl, etc? It's possible to
find a Lisp book in there, but it's also easy, from a quick flick thru
the pages, to get the wrong impression. Not everyone realises how much
of today's coding is approaching the complexity of AI, or how much
of it becoming AI itself. _We_ may know that, but how do we
communicate it? To many, AI is still a dirty word (well, two words).
And what do we find in so many Lisp books?
It's possible to attract readers looking for one thing, like web apps,
and to give them a whole lot more. PJ Brown did that. His book wasn't
just about compilers, it's also about good programming style. That 2nd
message has a lower profile, but he uses the compiler angle to talk
about something that any programmer should be able to understand. The
level at which he wrote about compiler theory should be intimidating
to anyone who is comfortable with strings.
Nearly 20 years later, what angle would be appropriate today?
Martin Rodgers
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?
Erik Naggum
* 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!
Per Bothner
In article <B08FEDC...@207.217.3.98>,
Robert D. Skeels <ath...@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 <raf...@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 bot...@cygnus.com http://www.cygnus.com/~bothner
Martin Rodgers
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.
Graham Hughes
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Martin" == Martin Rodgers <mcr@this_email_address_intentionally_left_crap_wildcard.demon.co.uk> writes:
Martin> Yes, the problem is when a programmer learns Lisp, as that
Martin> implies that they already "know" how programming is done. If
Martin> the style of programming that they learned is significantly
Martin> different to Lisp's style, then there could be problems. As
Martin> you said, idioms.
This can be a difficult nut to crack. I've gotten better at it over
the years (I've worked with at least one language from each major
``family'' -- pure OO, functional, logic, procedural, etc.), and the
only way I've been able to do it at all reliably is this: don't learn
a language from a tutorial, or a reference manual. Pick up a bit of
code and stare at it until it starts to make sense. *Then* go back to
the tutorial and reference manual.
Basically, this has you absorbing the idioms of the language by
osmosis. It's how I learned Scheme, Prolog, and PostScript. I
learned Mercury (a statically typed, very heavily compiled version of
Prolog) with minimal Prolog experience by taking the nontrivial
examples and looking at them until they started to make sense. The
alternative is horrible: when I was young, I worked with AutoLISP and
became disgusted with the language when I couldn't figure out how to
loop. (Recursion hadn't occurred to me yet...)
OTOH, I have the time to do this.
- --
Graham Hughes <graham...@resnet.ucsb.edu> / Never attribute to malice that
MIME OK, PGP preferred / which can adequately be
http://A31147.resnet.ucsb.edu/~graham/ / explained by stupidity.
/ -- Hanlon's Razor
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQCVAwUBNGwcpSqNPSINiVE5AQFIKgQAq9tvDPN7GDY2zo40QYkKZeuOy+SR2VU/
cPmWp7dlPGcalcl8WJEAvkRS2IVFscBVUFjO+7tjirp0gQZOwyVslftZ6tXdy1cg
jYuscvwwPUu6qIEk5jkQFyQDykU10eTQXI1wzBV1JNLAoG5w+44o3PElpqlOiHrb
5Bi//ns46H4=
=3yi5
-----END PGP SIGNATURE-----
Martin Rodgers
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.
Rainer Joswig
In article <MPG.ed7c5137...@news.demon.co.uk>,
mcr@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.
Martin Rodgers
Graham Hughes wheezed these wise words:
> This can be a difficult nut to crack. I've gotten better at it over
> the years (I've worked with at least one language from each major
> ``family'' -- pure OO, functional, logic, procedural, etc.), and the
> only way I've been able to do it at all reliably is this: don't learn
> a language from a tutorial, or a reference manual. Pick up a bit of
> code and stare at it until it starts to make sense. *Then* go back to
> the tutorial and reference manual.
This is why I prefer tutorials that spend half the book on the
language, and the rest on _using_ the language. I learned Pascal from
a book that wasn't intended to teach Pascal, but was instead about
tool building _in any language_. It just happened to use Pascal.
I learned Lisp from the 1st edition of W&H, followed by the 2nd and
3rd editions and other Lisp books. It was interesting to see how the
code changed between each edition of W&H.
> Basically, this has you absorbing the idioms of the language by
> osmosis. It's how I learned Scheme, Prolog, and PostScript. I
> learned Mercury (a statically typed, very heavily compiled version of
> Prolog) with minimal Prolog experience by taking the nontrivial
> examples and looking at them until they started to make sense. The
> alternative is horrible: when I was young, I worked with AutoLISP and
> became disgusted with the language when I couldn't figure out how to
> loop. (Recursion hadn't occurred to me yet...)
Yeah, I learned Basic from a referene manual. The result was some
pretty ghastly code. Then I started reading books like Elements of
Programming Style and Software Tools. My Basic and assembly code
improved after that. I experiemented by applying ideas to see if they
helped, and they did.
I was playing with what I now thinking of prefix notation (I was so
close; all I needed was expression nesting) when I discovered Forth.
A few years later, I began exploring Lisp. One lead to the other.
> OTOH, I have the time to do this.
Same here. I spent two weeks of evenings to write my first Forth. One
week to get the system to the point where it could compile the rest of
the system, one week to recover from the shock of succeeding, and
another week to write the rest of the code. My 3rd Forth was written
in 3 weeks, as I wrote a simple Forth meta compiler and used it to
build the new system. I'm still using that compiler today, altho I
don't do much in Forth anymore. Lisp has taken over.
If I were more like most programmers that I know, I'd only be coding 9
to 5, or I'd focus solely on _one_ language in order to maximise my
investment (time and money). I don't look at it like that. New ideas,
new experiences, new tools...How do we put a price on such things?
My time has been repaid in many ways that I can't quantify. Since I
can't quantify them, I can't easily share them with other people, by
pointing at a schedule and saying, "This time was cut by doing
_this_!" Worse, my skills can applied in any language, even C++. It
matters to me that these skills and experiences came from using Forth,
Lisp, and other equally non-mainstream languages, but since nobody
else needs see this (you might see it in my code, I certainly see it,
but most people probably won't), the "only code in C++" bigots can't
use it against me. I love it.
Martin Rodgers
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.
Martin Rodgers
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.
Rob Warnock
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 rp...@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
Marc Wachowitz
Martin Rodgers wrote:
> Excellent. Now all we have to do is reach all the programmers whose
> minds have already been currupted with batch oriented languages.
Well, in my view, being "interactive" vs. "batch-compiled" isn't even part
of the most relevant aspects of Lisp (or in fact, some Lisp dialects). It
may not be politically correct here ;-), but I do development - regardless
of the programming language being used - mostly by thinking/coding, without
much interaction, and as far as it's appropriate (and if time permits), I'd
rather write a "batch-compiled" test program for some software component -
which can be re-executed and mechanically checked again and again as the
system evolves - instead of doing lots of interactive testing (not even to
mention programming new stuff interactively). Self-descriptive code - and
in cases where that isn't sufficient, good documentation in the code - are
much more important for me than any dynamic evaluation.
> Alas, improving the human condition isn't necessarily how the market
> operates. What does the market reward?
"The market" - paired with lots of people making it into a religion - is
a self-fulfilling prophecy, only that the prophecy isn't what the followers
generally want or expect it to be. As someone who's a bit out of fashion
these days expressed it, history is unfolding behind the back of unconscious
humanity. However, I guess this isn't the appropriate forum for discussions
of a critical theory of society (including economy).
> I'm assuming that there are some good programmers out there who don't
> yet know of Lisp, or that they've only heard of Lisp from people who
> don't know what they're talking about.
If "good programmers" is meant in the sense I've alluded to in the previous
post, they won't blindly believe such unfounded rumours, but either find out
for themselves, or if their interests/priorities go into other directions,
just honestly know that they don't know, and not pretend otherwise (whether
to themselves or to other people).
> Alternately, you could just assume that anyone who doesn't already
> know Lisp never will, and wouldn't want to.
That's certainly not my position. However, I'd say that one can expect a
curious programmer to actively look around for his or her areas of interest,
and in these days of the web, one can find out quite easily about lots of
different programming languages and the associated methodologies, even if
one's nearest book store doesn't happen to carry many titles about the area.
You know, the word "study" (not necessarily implying university education)
means "making an effort", and if I should take someone seriously in this
field, I won't consider someone who merely glimpses over the little bit of
information which is readily delivered almost to one's home or office (this
is not to say that information channels of all kinds shouldn't be improved
where possible, but they are are poor excuse for lack of initiative and
reflection on what one is doing).
> It's possible to attract readers looking for one thing, like web apps,
> and to give them a whole lot more. PJ Brown did that. His book wasn't
> just about compilers, it's also about good programming style.
Would you call someone a good professional programmer if he or she didn't
ever have think and read about programming style and program organization,
even without getting that as background message from some other book? I'd
surely hesitate to do so. This attitude of learning a heap of application-
specific tricks and details, but never seriously caring for fundamental
principles of program design and implementation, is a disease of which one
has to be cured if one wants to be a professional programmer, IMO. That a
lot of people in the field get by without this is one (certainly not the
only) reason for the poor quality of the products.
-- Marc Wachowitz <m...@ipx2.rz.uni-mannheim.de>
Martin Rodgers
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. ;)
Tim Bradshaw
* 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
Martin Rodgers
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.
David Hanley
Georg Bauer wrote:
> David Hanley <da...@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
Martin Rodgers
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.
Reginald S. Perry
thor...@visi.com (David Thornley) writes:
> Face it, guys, the capitalist system is very inefficient about rewarding
> excellence; it's usually better at rewarding mediocrity. For most
> companies, the computer systems are not the heart of the business, and
> making them superbly efficient is unlikely to help the business nearly
> as much as making the wrong choice is likely to hurt it. It's
> expensive to make changes, and the upside is likely to be streamlining
> a medium-sized chunk of their staff work. It's a matter of optimization.
> It may not be worth it.
>
I am not sure about the validity of what you imply above. I look at
this problem as being largely customer driven. If cars or bridges were
as poorly designed as some commercial software that I have on this PC
next to me, lawyers would be in lawsuit heaven. As it is, as long as
the customers accept crap, and spend their good money on crap, they
will be sold that crap at the highest price they are willing to pay,
delivered to them via the six-pack of crappy programmers that the
manager picked up at the local programmers store.
I think this is starting to change as consumer software becomes more
demanding and the price point for decent hardware remains the
same. People start to notice that they are spending hard earned money
on crap.
> >Too many people in this profession are simply coders, usually not very
> >interested in the first place to think much beyond the horizon of turning
> >a pretty much worked out solution into executable code in one and only one
> >programming language, of which they've seen some examples.
> >
> That's a demographic issue. There aren't enough first-rate programmers
> (like us :-) to go around. It's generally easier to hire a bunch of
> coders than a smaller number of really good people, and generally
> also more comfortable. Managing coders is like herding sheep, while
> managing top programmers is like herding cats.
>
This is always going to be true. I think that the problem is that
management needs to understand the issues a bit better. That wont
happen until people start losing serious money for being stupid.
>
> Right now, I have no faith that my favorite Lisp vendor, Digitool, is
> going to survive this century. I have no doubt that I will continue
> to have first-rate C++ development environments for years to come.
>
Well I am not sure about Digitool. That depends a bit too much on the
fortunes of Apple, but if Apple survives, I dont see Digitool going
anywhere soon.
> Yes, this would make comp.lang.lisp a much less fun place. We'd get
> five people a week asking why (delete 1 foo) doesn't always work,
> inflammatory style wars on car/first and setf/setq, that sort of thing.
> We'd constantly see Lisp abused in horrible ways, and people complaining
> loudly that a Lisp implementation doesn't work the way they want it
> to, regardless of standards.
> >
> >If you want more dull coders programming horrible applications in Lisp,
> >something like "Web Applications in Common Lisp" might help.
> >
> Exactly what I want! Let them pay for Franz and Harlequin and Digitool
> employees designing and building the Lisps of tomorrow, so that we
> can buy those Lisps tomorrow!
>
>
I dont think that Lisp will ever have the industry of "Lisp for
Dummies". This is a good thing. It seems that out of the Lisp vendors,
that Harlequin sells a Lisp system but its not their reason for being
and in spite of that, or maybe because of that, its a pretty darn nice
environment. So I dont think they are going anywhere anytime soon. It
also looks like Franz has a cottage industry of specialized
applications for which people need Lisp. So I have confidence that
they will be around for a while also. Harlequin has brought the price
of Lisp systems into the realm of us little guys so I am actually a
happy camper.
>
> --
> David H. Thornley | These opinions are mine. I
> da...@thornley.net | do give them freely to those
> http://www.thornley.net/~thornley/david/ | who run too slowly.
-------------------
Reginald S. Perry e-mail: pe...@zso.dec.com
Digital Equipment Corporation
Performance Manager Group
http://www.UNIX.digital.com/unix/sysman/perf_mgr/
The train to Success makes many stops in the state of Failure.
John Arley Burns
mcr@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin Rodgers) writes:
> Marc Wachowitz wheezed these wise words:
>
> > Well, in my view, being "interactive" vs. "batch-compiled" isn't even part
> > of the most relevant aspects of Lisp (or in fact, some Lisp dialects). It
> > may not be politically correct here ;-), but I do development - regardless
> > of the programming language being used - mostly by thinking/coding, without
> > much interaction, and as far as it's appropriate (and if time permits), I'd
> > rather write a "batch-compiled" test program for some software component -
> > which can be re-executed and mechanically checked again and again as the
> > system evolves - instead of doing lots of interactive testing (not even to
> > mention programming new stuff interactively). Self-descriptive code - and
> > in cases where that isn't sufficient, good documentation in the code - are
> > much more important for me than any dynamic evaluation.
>
> Snap! The compilers I use are also mostly batch oriented. Even Lisp
> compilers, if you count Scheme.
>
> > "The market" - paired with lots of people making it into a religion - is
> > a self-fulfilling prophecy, only that the prophecy isn't what the followers
> > generally want or expect it to be. As someone who's a bit out of fashion
> > these days expressed it, history is unfolding behind the back of unconscious
> > humanity. However, I guess this isn't the appropriate forum for discussions
> > of a critical theory of society (including economy).
>
> Agreed. Nobody listens to me, anyway.
I listen!
>
> > If "good programmers" is meant in the sense I've alluded to in the previous
> > post, they won't blindly believe such unfounded rumours, but either find out
> > for themselves, or if their interests/priorities go into other directions,
> > just honestly know that they don't know, and not pretend otherwise (whether
> > to themselves or to other people).
>
> If I wish I could met more of these programmers, as they seem to be in
> a minority. I hope that's just my own experience, but I see shelves of
> magazines and books that suggest otherwise. Then there are all those
> adverts for jobs requiring C++ or VB. I wouldn't worry about it if I
> didn't keep finding bugs and hairy code in those magazines and books!
>
> > > Alternately, you could just assume that anyone who doesn't already
> > > know Lisp never will, and wouldn't want to.
> >
> > That's certainly not my position. However, I'd say that one can expect a
> > curious programmer to actively look around for his or her areas of interest,
> > and in these days of the web, one can find out quite easily about lots of
> > different programming languages and the associated methodologies, even if
> > one's nearest book store doesn't happen to carry many titles about the area.
>
> I try to encourage this, where ever I can.
>
> > You know, the word "study" (not necessarily implying university education)
> > means "making an effort", and if I should take someone seriously in this
> > field, I won't consider someone who merely glimpses over the little bit of
> > information which is readily delivered almost to one's home or office (this
> > is not to say that information channels of all kinds shouldn't be improved
> > where possible, but they are are poor excuse for lack of initiative and
> > reflection on what one is doing).
>
> Most of the Windows developers I know seem to spent their time reading
> SDK documentation instead of languages. There are all kinds of info,
> and not all of it will lead a programmer to new programming ideas.
>
> > Would you call someone a good professional programmer if he or she didn't
> > ever have think and read about programming style and program organization,
> > even without getting that as background message from some other book? I'd
> > surely hesitate to do so. This attitude of learning a heap of application-
> > specific tricks and details, but never seriously caring for fundamental
> > principles of program design and implementation, is a disease of which one
> > has to be cured if one wants to be a professional programmer, IMO. That a
> > lot of people in the field get by without this is one (certainly not the
> > only) reason for the poor quality of the products.
>
> Agreed. I can appreciate the amount of time that studying a new tool,
> SDK, API, etc can consume. However, I've a greater appreciation for
> new programming experiences. All I see in the C++ tools I've used in
> greater automation for the tedium created by C++ frameworks.
>
> The image I have is of C++ programmers hammering hot nails into their
> flesh, and then discovering that the nails don't need to be _quite_ so
> hot. They then jump and down and hail it as a revolutionary change.
> Later, somebody discovers that the nails can be room temperature, or
> that they can be replaced with sharp needles.
>
> At each step the pain becomes relatively more bareble, but it still
> hurts. It takes them a while to realise this. What no C++ programmer
> seems to ask is why they are they inserting bits of metal into their
> flesh. It's just taken for granted that they need to do this. After
> all, haven't they always had to do this?
>
> Using Lisp, on the other hand, is like sitting on a beanbag. There are
> people who can't believe this can be done. When I began reading this
> newsgroup, 5 years ago, I could see programmers who refused to believe
> in this "heresy", and felt a bizzare need to tell us Lisp people that
> we were doing things "wrong". For the last few years, I've been
> equally bemused by the people saying that Java is "wrong", or won't
> work, and various other nonsense that has also been said about Lisp.
>
> The more things change, eh?
John Arley Burns
mcr@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
David Hanley <da...@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 ;}
Martin Rodgers
Reginald S. Perry wheezed these wise words:
> I dont think that Lisp will ever have the industry of "Lisp for
> Dummies". This is a good thing.
This is not what I'd want, either. However, I don't believe that
everyone who writes software but who doesn't use Lisp as a "dummy".
The point that I've been trying to make is that Lisp isn't just for
the gurus writing large and spectacularly complex software. This may
well be the kind of software that CL was designed for, but today's
business apps are approaching the size and complexity where Lisp can
help. Even relatively mundane apps like web servers have been written
in Lisp! The business world is currently wetting itself over these
things, but where are the Lisp systems that bundle a web server?
There _are_ people interested in using Lisp to write business
software. This is a time of great opportunities, when whole new
app domains are emerging. (Groupware _finally_ hits the bigtime.)
In spite of the all the advantages that Lisp has over other languages,
the deluge of tools to exploit these networking opportunities are not
targetting Lisp, but languages like C++ and VB.
Maybe it's different for Unix (I recall reading something about www Tk
widgets), but this is certainly the case for Windows. (Let's please
leave the advocacy issues out of this. It won't change the zeitgeist.)
It's tempting to think that just because, let's say, CL-HTTP is
written in Lisp that it can beat the crap out of anything else. Alas,
this is not always the case. We may need more than just a sense of
superiority in order to compete in a tough market. It could be that
Lisp has a safe niche (or several), and that competition isn't as
tough. It could be that I'm just unfamiliar with such a niche, and so
I'm a little sceptical. YMMV.
Right now, I'm more familiar with a niche or two currently dominated
by non-Lisp tools. That doesn't make me wrong, necessarily. It just
gives me a different point of view. If I were the only one with this
POV, then I wouldn't bother to mention it here. I'm only mentioning it
now because it looks like David Thornley and I might be agreeing on a
few things. I certainly have some sympathy with what he's saying here.
> Harlequin has brought the price of Lisp systems into the realm of
> us little guys so I am actually a happy camper.
I'm also happy. If someone would pay me to write code in Lisp, I'd be
even happier, but I guess that's a different matter. I'd be happy
coding in Lisp even if nobody paid me to do _anything_ (Been There,
Done That). In fact, I'd have even more time for using Lisp.
Now even an unemployed Lisp programmer can afford a commercial CL. ;)
Martin Rodgers
John Arley Burns wheezed these wise words:
> I listen!
As I've noticed. ;)
Thanks.
Martin Rodgers
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.
Rainer Joswig
In article <MPG.edb69f3e...@news.demon.co.uk>,
mcr@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin
Rodgers) wrote:
> help. Even relatively mundane apps like web servers have been written
> in Lisp! The business world is currently wetting itself over these
> things, but where are the Lisp systems that bundle a web server?
MCL comes with CL-HTTP on the CD ROM. Some
applications you can buy are written with MCL using CL-HTTP.
There are even demo applications available.
Btw., *one* reason for the ongoing development of Symbolics
Genera is surely the White House web application of
CL-HTTP for document distribution. I would consider this
to be a very successful web application of Lisp.
> targetting Lisp, but languages like C++ and VB.
CL-HTTP has been ported by Harlequin to LispWorks. The current
devo of CL-HTTP should basically work with LWW 4.0.1 (you may need
some patches from Harlequin, too) You can start hack Web applications
with LWW (which, hint, hint, has an ODBC interface). Well,
atleast my copy of LispWorks can run CL-HTTP.
Martin Rodgers
Rainer Joswig wheezed these wise words:
> MCL comes with CL-HTTP on the CD ROM. Some
> applications you can buy are written with MCL using CL-HTTP.
> There are even demo applications available.
Excellent. Well done Digitool!
> Btw., *one* reason for the ongoing development of Symbolics
> Genera is surely the White House web application of
> CL-HTTP for document distribution. I would consider this
> to be a very successful web application of Lisp.
Just not very competitive with rival web technology. CL-HTTP alone is
lagging behind the top commercial web servers, while Genera is a lot
more expensive, unless you already have an Alpha machine running
OSF/1. It's successful in the sense that it works, and if that's all
you care about, then it's fine.
However, in the web hosting market, you'll find that many others are
rather more demanding. FoxNet also works, but I doubt that you'll find
it running on many corporate webservers. Of course, you can ignore the
corporate market if you wish.
> > targetting Lisp, but languages like C++ and VB.
>
> CL-HTTP has been ported by Harlequin to LispWorks. The current
> devo of CL-HTTP should basically work with LWW 4.0.1 (you may need
> some patches from Harlequin, too) You can start hack Web applications
> with LWW (which, hint, hint, has an ODBC interface). Well,
> atleast my copy of LispWorks can run CL-HTTP.
Patches? I've got LWW 4.0.1 but I didn't know there were any patches
for it yet.
Ok, so there's at least one web tool for Lisp that runs under Windows.
That's a start, but we're hardly deluged in Lisp tools. (See below).
Meanwhile, web tools for C++, VB, etc have been available for well
over a year, and more keep appearing. It's hard to keep track of them.
Perhaps Lisp programmers only need one web server, if it's good
enough? I would think that this is the case. Using LispWorks and CL-
HTTP, it shouldn't be necessary to use a template language for feeding
database results into an HTML page. Lisp itself will do.
My hope is that Lisp-based web development is one of those activities
that is mainly done in-house, and is therefore "invisible". You're not
likely to read about it in mainstream development magazines or the
specialised web development rags. Right now, Java seems to bet getting
most of the software development attention for the web.
Nor do I expect to see mainstream Windows development mags publishing
features on how to use CL-HTTP for your web server. This could be
done, of course, but it's more likely that most of the editorial staff
have been bought off by MS. See the September 1994 issue of Windows
Tech Journal, in which the editor reported the MS practice of inviting
magazine editors to "serve as a member of Microsoft's Visual C++
development team." This coz the mag all their MS advertising, but the
price was worth it, IMHO. It's important to know how much (or how
little) you can trust what you read in the press.
Or maybe I'm being just a little too cynical? I dunno, but I hope so.
Not that I'd wish my cynicism to stop anyone from using Lisp! One of
my rules is: Do it _because you can_. I use Lisp _because I can_.
The only real problem with CL-HTTP is that not enough people know
about it. If Harlequin bundle it with LWW and place adverts for it in
mainstream development mags, the message should get to a few people.
Match non-Lisp based web servers feature for feature, make sure it's
as easy to administrate as the rivals, add remote admin, and then sell
it as rocket powered web technology, and you could compare all the
other web servers to steam power. The "rocket powered" label would be
more convincing if it wasn't based on an assumption that Lisp alone is
enough to make an app superior. Most people don't know this.
Oh, and make sure that the Harlequin website uses it. ;) That's the
real testimony. Point visitors to the Whitehouse site and any others
that use CL-HTTP. In other words, give it some marketing. Sell it.
ATM, Harlequin's website doesn't seem to mention CL-HTTP.
Barry Margolin
In article <wzra8ew...@urquan-kohr-ah.mesas.com>,
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, bar...@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.
Reginald S. Perry
mcr@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin Rodgers) writes:
> Reginald S. Perry wheezed these wise words:
>
> > I dont think that Lisp will ever have the industry of "Lisp for
> > Dummies". This is a good thing.
>
> This is not what I'd want, either. However, I don't believe that
> everyone who writes software but who doesn't use Lisp as a "dummy".
> The point that I've been trying to make is that Lisp isn't just for
> the gurus writing large and spectacularly complex software. This may
> well be the kind of software that CL was designed for, but today's
> business apps are approaching the size and complexity where Lisp can
> help. Even relatively mundane apps like web servers have been written
> in Lisp! The business world is currently wetting itself over these
> things, but where are the Lisp systems that bundle a web server?
>
While I agree that Lisp isn't for gurus only (I am nowhere near being a
guru), there is a large amount of tunnel vision in our industry. I
don't think that its worth my effort to attempt to adjust the
limitations of other programmers. I'm too busy trying to correct my
own limitations. :-)
What we can do is slowly try to infiltrate Lisp into our jobs by
slowly convincing our managers to allow us to use Lisp on certain side
projects and slowly move it up the chain. This is a tough route. I
chose this route and got project approval, but resource shortages made
it so that I have to hack more "popular" languages to keep the project
on track. But I did get management to purchase everything I need to
keep the side project alive until we get more resources.
Lisp has been around for a very long time, through several phases
where one would have thought that the language would have died
out. But its still here. The software industry is coming to the point
where time-to-market, quality, and timely response to users' requests
for features are becoming more mutually exclusive or very expensive
to accomplish. The Lisp vendors are starting to respond vigorously to
requests for certain features to the product, like the possibility of
generating DLLs and such so I think that we will come to a point where
I can release a DLL and normal users wont know and wont care what
language was used.
> There _are_ people interested in using Lisp to write business
> software. This is a time of great opportunities, when whole new
> app domains are emerging. (Groupware _finally_ hits the bigtime.)
> In spite of the all the advantages that Lisp has over other languages,
> the deluge of tools to exploit these networking opportunities are not
> targetting Lisp, but languages like C++ and VB.
>
Well it sort of depends on the type of tool that you are looking
for. Some of this stuff would be fitting square pegs into round
holes. Could you give me some examples?
Juliusz Chroboczek
[crossposted to comp.lang.ml: we need a good flamewar]
In article <64ptde$ci6$1...@darla.visi.com>,
thor...@visi.com (David Thornley) paraphrased Him:
DT> Dijkstra claimed that languages like Basic warp programmers, but
DT> it seems to me that the whole Fortran/Basic/Pascal/Modula/C/C++/Java
DT> family (apologies to languages left out) warps programmers. They
DT> start to see everything in terms of a procedural language with
DT> static typing.
Symmetrically, we Lisp programmers get our vision of things warped by
using a dynamically typed language.
Some time ago, I was speaking with a die-hard ML programmer (this is
Edinburgh, after all). After a while, he asked me:
`Do you really feel your programming style is cramped by ML's strong
typing? I mean, do you often write a function that couldn't be
typed in ML?'
I started to give an example about a searching function which returns
a string on success and NIL on failure.
`I'd just raise an exception on failure!' (that's ML-speak for
throwing out of a scope)
I then realised that because ML is strongly typed, ML programmers are
likely to use techniques that we don't need in Lisp. And, sure
enough, looking back at the code I wrote back in my ML days, it is
full of exception catching. While my last 3000 lines of Lisp have
three catch forms (plus a few error handlers, but I think that's a
different issue).
I don't know which way is right. C's way of always returning a value,
even on error, is definitely wrong. But what should be done in an
exceptional situation which is not an error? Lisp often chooses to
return NIL (or some other distinguished value), while ML raises an
exception. But the point is that I would not have become aware of
this choice had I not learnt a modern strongly typed language (ML).
(Similarly, one might argue that the purely functional nature of
Haskell led Wadler to use Moggi's ideas about monads, which would
never have been used in programming otherwise.)
DT> Face it, guys, the capitalist system is very inefficient about
DT> rewarding excellence; it's usually better at rewarding mediocrity.
Right. And C and C++ programmers will be the first against the wall
when the Revolution comes. (A ghost is haunting Europe, the ghost of
Dynamic Typing.)
Sincerely yours,
J. Chroboczek
Rainer Joswig
Martin Rodgers wrote:
> Just not very competitive with rival web technology. CL-HTTP alone is
> lagging behind the top commercial web servers,
CL-HTTP was the *first* serverto do HTTP 1.1. The guys at W3C sometimes
did debug their HTTP 1.1
code connecting to CL-HTTP.
It comes with proxy and web walker functionality.
It does support virtual hosts and you can run multiple
HTTP protocols inside the image. You can develop your own
protocol or protocol extensions just by writing CLOS code
and extending the server's object-oriented architecture..
The White House installation has demonstrated joint
development for mail and web based applications from
one code base, integration into an object-oriented database,
URNs, ... Only two web servers are somewhat comparable
(for example Jigsaw), but with a more primitive architecture.
Additionaly the CL-HTTP code is ultra portable (Windows, Windows NT,
Mac OS, Lispm, Unix) using many different
Common Lisp systems (CMU CL, ACL NT, ACL PC, ACL Unix, LW, LWW,
LCL, MCL, SCL). Not bad for a niche language.
> It's successful in the sense that it works,
Successful means, it runs applications people care about, like theWhite
House document distribution, Medical Expert systems
with web interface, tutoring systems, city information systems,
chat systems, ...
> Perhaps Lisp programmers only need one web server, if it's good
> enough?
There are atleast three different web servers for Common Lisp alone.
> ATM, Harlequin's website doesn't seem to mention CL-HTTP.
Go to the links page.
I think it is a good move for Harlequin (especially Martin Simmons) to
support
CL-HTTP. It is currently a standard for web development in Common Lisp
and everyone is invited to use CL-HTTP (according to the license) and
to improve the tool for the benefit of all users. Thank god it's freely
available.
How about getting the latest CL-HTTP devo, get the patches from
Harlequin,
and help improving the LWW port?
Pierre Mai
>>>>> "MW" == Marc Wachowitz <m...@ipx2.rz.uni-mannheim.de> writes:
MW> Would you call someone a good professional programmer if he or
MW> she didn't ever have think and read about programming style
MW> and program organization, even without getting that as
MW> background message from some other book? I'd surely hesitate
MW> to do so. This attitude of learning a heap of application-
MW> specific tricks and details, but never seriously caring for
MW> fundamental principles of program design and implementation,
MW> is a disease of which one has to be cured if one wants to be a
MW> professional programmer, IMO. That a lot of people in the
MW> field get by without this is one (certainly not the only)
MW> reason for the poor quality of the products.
This just bears repeating over and over!!!
People are just _so_ small-minded, whether w.r.t. programming
languages, methodologies, style, operating systems, etc.
Rarely does one see a programmer sitting down and evaluating possible
tools/solutions when confronted with a new problem. Mostly the
attitude is "I have/can use XYYADFZ. What do you want me to do?", and
then just spending many manhours trying to implement a "solution",
which with proper tools would have been solved in 2 minutes, leaving
28 minutes for documentation and testing, and the other half hour for
lunch ;)
This not only leads to the poor code/implementation reuse we see in
the industry, but also to the high-cost, low-reliability,
poorly-documented "solutions" we see.
Changing this is one of the main goals to solve before computing will
enter a new level of productivity/security, that will allow it to
leave it's "wild-west" era and move on to become a civilized and
responsible citizen in todays world, contributing towards solving
humanities most pressing problems...
Sadly, nowadays the trend seems to move even more towards
one-tool/one-paradigma programmers...
Regs, Pierre.
Georg Bauer
David Hanley <da...@netright.com.delete.me.silly> wrote:
> Gee---I wonder which they'll choose.
Actually someone did that by telling them to use this brain-damaged Unix
shells. So why shouldn't they learn something different? Each
Microsoft-User learns using this Word-Shell or this Excel-Shell. What's
so big a deal about it?
_You_ may personally have misconceptions about Lisp-systems. But that
remains totally _your_ problem. You can't argue that _we_ (we as the
bunch of Lisp-users) are on the wrong track just because _you_ don't see
the benefits. You may argue that _you_ can't use Lisp for the mentioned
reasons because _you_ are unable to see the solutions to the problems.
But that isn't a fault of Lisp. It's totally yours.
BTW: It's really funny to deny Lisp any commercial value by arguing with
programs in the shell-util area. When did you last sell "cat" or "tee"
or "hello world"? But when you can sell Word or Excel, you can sell
programs written in Lisp, too. People _don't_ see executable size.
Actually only people from the C-camp argue with executable size - and
then go on and write monsters like Word or Excel.
And - as many pointed out - there are several Lisp-implementations that
make use of DLLs or shared-libraries for there runtime system.
And a last thought: when you have to build a bunch of utilities, you are
maybe better off writing them to a Lisp shell. Just put one of the many
algebraic syntaxes on top of the Lisp shell and people won't even notice
the difference. Except that the system will be much more powerfull.
bye, Georg
Martin Rodgers
Espen Vestre wheezed these wise words:
> do you have any examples of actual "top commercial web servers"?
I regularly use WebSite, and I've (briefly) used IIS. I'm familiar
with the experiences of people using other servers.
> My experience is that they're all overhyped.
YMMV. What is that seems overhyped? Is there something that they don't
do that you need, or that they do that you don't need?
> Speaking e.g. of Netscape,
Ah, well. I can't comment on their servers. Note the plural - not
everyone needs every feature, so pick the server that matches your
needs.
> their software (client or server) may be feature-rich, but it's
> usually very slow and extremely bloated (gee, I think my netscape client
> just passed 40MB of RAM usage).
I certainly can't comment on performance. I've only been able to
measure performance under "lab conditions", which means stressing the
server to simulate real loads. The online server that I use is either
very lightly loaded, or copes very well with its daily loading.
The Netscape client? The browser? That's a different issue. Out of
curiousity, how does it compare with GNUScape? While Emacs still has a
rep for large memory demands, I've not noticed this with the Windows
version. (OTOH, I've not used GNUScape.) Emacs here uses about 3 MB
working set, 257 MB for the peak virtual size, while the Netscape®
Communicator 4.03 working set is 7 MB, peak virtual size 40 MB (approx
sizes). This current Netscape process has a fault count of 3K, FWIW.
YMMV, esp if you use a different OS. (I currently use NT 4.0.)
> you might be right! I'm developing our second lisp-based webserver now,
> but it will only be used for internal purposes.
Private internal servers can be the most fun, IMHO. You have the most
freedom to try new ideas, and do whatever you like. That's perfect for
development work. Next, you can have internal servers that are shared
with other network users. They can also be fun. And then there're the
online servers that anyone can see - but not everyone can access, or
not access every part of the server, or every site on the server.
> Hmm, I actually think that more and more people are getting to know it.
More Lisp people, certainly. ;) And people who read web server FAQs.
> And the Franz web site had a cover story on it.
Yep. More preaching to the converted, but at least they mention it.
Anyway, how many people are using CL-HTTP but not Lisp? Lisp would
seem to be a prerequisite.
> Hmm, it _would_ perhaps be an idea to make a "thing-that-goes-bing"
> commercially packaged version of CL-HTTP in order to assist eager
> programmers to convince their bosses ;-) What do the CL-HTTP community
> think of this?
This is exactly what I'm hoping will happen. With so many web servers
that work "out of the box", CL-HTTP is at a severe disadvantage. Now,
bundle it with a commercial Lisp system that installs CL-HTTP at the
same time, with a menu item that runs the server, another menu item or
script that creates a stand alone binary, plus some simple admin user
interface for quick results, and maybe CL-HTTP could geta foot in the
door. Then the sales pitch can begin!
It may sound like the smart people who will use a server like CL-HTTP
don't need such hand-holding, but as you pointed out, it may be their
bosses that need convincing, not the programmers. An app like a web
server also suffers from the image of being simple enough to manage
without a programmer. Well, if all you want to do is deliver simple
objects, like pages, images, sounds etc, then that's fine. The more
interesting work requires some programming, even if it's only writing
database templates. The best results demand a lot more than this.
CL-HTTP might be used more if it were targetted at the people who want
to go way beyond the traditional (yep, we can now use that word to
describe the web apps built using familiar and well-worn database
tech) apps. Alas, at least one web server FAQ that mentions CL-HTTP
misses the "power web server" potential. It more or less dismisses it
as a curiousity, an afterthought at the end of the server list. This
isn't a good way to tell people about a power tool.
In contrast, the CL-HTTP web pages are very well written, IMHO. Anyone
who gets as far as the first page will see that this is a serious
server, with good support for the HTTP 1.1 features.
David Hanley
Pierre Mai wrote:
> This just bears repeating over and over!!!
>
> People are just _so_ small-minded, whether w.r.t. programming
> languages, methodologies, style, operating systems, etc.
>
> Rarely does one see a programmer sitting down and evaluating possible
> tools/solutions when confronted with a new problem. Mostly the
> attitude is "I have/can use XYYADFZ. What do you want me to do?", and
> then just spending many manhours trying to implement a "solution",
> which with proper tools would have been solved in 2 minutes, leaving
> 28 minutes for documentation and testing, and the other half hour for
> lunch ;)
It's worse than that. Most people simply don't design code for
thefuture. When I write code in an application, unless I'm dead sure I'll
never extend it, or need to use the code elsewhere, I write the code in
the mose general&bulletproof way that I can--so that it will be very, very
easy to extend it later, use it in a slightly different way, in the same
or
a different application.
Most other people's code I see is desaigned to do exactly what that
spec says( if they're lucky--usually it's not conforming ) and if the
spec changes or expands, even a bit, they have to dump the old code,
or write new code.
Functional & interactive languages make it much easier to write
code that is very general and can be used later for a slightly different
purpose. But your everage programmer doesn't understand this anyways.
dave
Tim Bradshaw
* Martin Rodgers wrote:
> Just not very competitive with rival web technology. CL-HTTP alone is
> lagging behind the top commercial web servers,
CL-HTTP is miles ahead of any of the competition that I know of, for
any lisp-based application. It's almost trivial to write things that
export & import information directly from & to the structures in the
program. CL-HTTP was also the first fully http-1.1 server (is it
still?).
(of course the `for any lisp-based application' qualifier above may be
seen as significant).
> while Genera is a lot
> more expensive, unless you already have an Alpha machine running
> OSF/1. It's successful in the sense that it works, and if that's all
> you care about, then it's fine.
You don't need genera for cl-http.
--tim
Dan Higdon
Juliusz Chroboczek wrote in message
<64t0bd$o2s$1...@goldenapple.srv.cs.cmu.edu>...
>I started to give an example about a searching function which returns
>a string on success and NIL on failure.
>
> `I'd just raise an exception on failure!' (that's ML-speak for
> throwing out of a scope)
Funny, I'd just return a 'string option'. That way, it's either
NONE or SOME x. Simple, no exceptions required. :-)
I tend to agree that exceptions can be overused, fwiw.
>Right. And C and C++ programmers will be the first against the wall
>when the Revolution comes. (A ghost is haunting Europe, the ghost of
>Dynamic Typing.)
Hey! I program in ML too! :-)
Dan Higdon (hd...@charybdis.com)
Tim Bradshaw
* Martin Rodgers wrote:
> This is exactly what I'm hoping will happen. With so many web servers
> that work "out of the box", CL-HTTP is at a severe disadvantage. Now,
> bundle it with a commercial Lisp system that installs CL-HTTP at the
> same time, with a menu item that runs the server, another menu item or
> script that creates a stand alone binary, plus some simple admin user
> interface for quick results, and maybe CL-HTTP could geta foot in the
> door. Then the sales pitch can begin!
But `working out of the box' pretty much means `serving a bunch of
html files', or perhaps serving data from some relational database.
Well, CL-HTTP can do that, sure, but it's hardly an interesting
application, is it?
What you want is a web server that lets you do things that are
interesting with the web: dynamically created web pages, web
interfaces to large SW systems, &c &c. A system like that will not
run out of the box, because you're going to have to bite the bullet
and write programs. Writing such programs using CL-HTTP is a delight,
especially after fighting with perl CGI scripts.
In fact, to go off at yet another tangent, this `run out of the box'
idea is one of the most pervasive & dangerous misconceptions currently
around. Non-trivial applications do not run out of the box. I hear
so many people say `just get NT and office 97 and blah and we can just
run our MIS system on the web and it will have no maintenance and it
will just work and all the problems are solved', and this is just
obvious crap: how do we do access control? who is going to run the NT
box? who does the backups? Sure, these tools may make things somewhat
easier, but they do not solve the interesting problems, because the
greater part of these problems is hard, idiosyncratic, and require
thought and time -- that's why they're interesting. There is no
silver bullet.
--tim
Matthias Blume
In article <64t0bd$o2s$1...@goldenapple.srv.cs.cmu.edu> Juliusz Chroboczek <j...@dcs.ed.ac.uk> writes:
[ a moderately lengthy discussion of how different programming styles
handle cases where a function cannot return a "normal" result;
claiming that ML programmers would usually use exceptions for this
purpose ]
There are (at least) two ways of doing this in ML. If the condition
is more like an "error" (and probably rare) then I would prefer
exceptions. A typical example would be division, where division by 0
is the exceptional case. I personally use exceptions very little.
In situations where the "out of band" value is more frequent I would
have the function return an "option" type. The nice thing about this
is that the ML type checker will force the user of the function to
handle the special case. As a programmer, one cannot easily forget
about it. A typical example where options are useful would be a table
lookup (e.g., a compiler's symbol table).
The drawback of C's (and Lisp's) habit of returning an "impossible"
value is that it is not always obvious what the impossible value
should be. In the typed world of C, the return type of getchar was
artificially widened to include *many* impossible values just so we
can have it return -1 as well as all possible unsigned character
values. In the untyped world of Lisp, it is often the case that there
is no "impossible" return value, in which case the technique of
returning one breaks down. (ML's type system can always make up a
bigger type that can encode every "possible" value plus any number of
additional "impossible" ones.)
The only good way of doing things right in Lisp would be to resort to
passing multiple continuations explicitly. Of course, this avenue is
also open in ML (but less so in C because of its lack of higher-order
functions).
--
-Matthias
Martin Erwig
In article <64t0bd$o2s$1...@goldenapple.srv.cs.cmu.edu>, Juliusz Chroboczek
<j...@dcs.ed.ac.uk> wrote:
> ...
>
> I started to give an example about a searching function which returns
> a string on success and NIL on failure.
>
> `I'd just raise an exception on failure!' (that's ML-speak for
> throwing out of a scope)
>
> ...
>
> I don't know which way is right. C's way of always returning a value,
> even on error, is definitely wrong. But what should be done in an
> exceptional situation which is not an error? Lisp often chooses to
> return NIL (or some other distinguished value), while ML raises an
> exception.
I think the usual way to do it in ML is to use the option type:
datatype 'a option = NONE | SOME of 'a
If your function should succesfully return a value x, then you
return SOME x instead, otherwise you return NONE. Of course, you
have to inspect the return value on the client side to get the
actual value x, eg, by pattern matching. Some might say this leads
to more complex programs. At least the programs get a bit longer
(though in some cases you can use short cuts); the good thing is
that the program text tells you rather clearly what is really
going on.
Martin
--
er...@fernuni-hagen.de
http://www.fernuni-hagen.de/inf/pi4/erwig/
Martin Rodgers
Reginald S. Perry wheezed these wise words:
> While I agree that Lisp isn't for gurus only (I am nowhere near being a
> guru), there is a large amount of tunnel vision in our industry. I
> don't think that its worth my effort to attempt to adjust the
> limitations of other programmers. I'm too busy trying to correct my
> own limitations. :-)
I feel the same way.
> Well it sort of depends on the type of tool that you are looking
> for. Some of this stuff would be fitting square pegs into round
> holes. Could you give me some examples?
Examples? See the various Windows development magazines, as you'll
find adverts and reviews for many of them. Some mags list new tools,
and it's not unusual to see web-related tools appearing in these
pages. It might not be so easy to find such tools on the web unless
you look for them.
At least I've not yet seen a FAQ for server addons, like the kind of
list you can find in the web server FAQs. The Windows web server FAQ
<URL:http://info.ox.ac.uk/help/wwwfaq/swinnt95.htm> lists CL-HTTP and
describes it like this:
> It is available on many platforms, and can be programmed at a
> remarkably high level, using Lisp code to generate much of the
> output of the server. An interesting option when development
> time is limited.
That last line doesn't sound encouraging, like the author has some
doubts. So comments like this made for any of the other servers, altho
the choice of listed features is curious. Why mention that some
servers are multi-threaded and not others? Availability of space?
Many web tools are just things like database interfaces. However, as
that's a very useful tool in a corporate world, this is far from
insignificant. Some other tools may be little more than TCP/IP
components, altho they do tend to come with source code examples for
many Internet apps, like SMTP, FTP, etc.
These tools tend to build on what Windows developers will already
know, exploiting tools they're already familiar with. Even if the
languages are inferior to Lisp, that leverage helps a lot. Throw a
familiar SQL query into an HTML template, and bam! You've got a web
app. There's a big demand for that. CL-HTTP probably isn't going to
compete well at that level, but as the server tasks get more complex,
Cl-HTTP will gain a killer edge over the more primitive tools.
The really interesting tools are being built on top of the basic
networking tools. Much of that kind of work is done in-house, but you
can read about some examples in magazines like Byte. There's probably
little of it that can't easily be done in Lisp, but I've yet to read
_any_ "how to" style articles using Lisp. This may be because Lisp
programmers find it so much easier that we don't need a "how to"! Such
an article be useful for explaining to others less Lisp-literate than
ourselves why we use Lisp, and that this is not just "An interesting
option when development time is limited."
Ken Tilton
Juliusz Chroboczek wrote:
>
> I started to give an example about a searching function which returns
> a string on success and NIL on failure.
>
> `I'd just raise an exception on failure!' (that's ML-speak for
> throwing out of a scope)
>
> likely to use techniques that we don't need in Lisp. And, sure
> enough, looking back at the code I wrote back in my ML days, it is
> full of exception catching.
[...]
>
> I don't know which way is right. C's way of always returning a value,
> even on error, is definitely wrong. But what should be done in an
> exceptional situation which is not an error?
I vote for the Lisp way.
First, it /sounds/ perfectly reasonable that a function asked to search
for something in a collection matching some criteria should be able to
say "Nothing". That is not an exception, that is a reasonable and normal
result.
An exception would be something like searching for a customer with an
invalid customer number (it flunks some check-digit test). You /could/
just say "Nothing", but that is not completely forthcoming; better to
say "Invalid query" and then you /do/ want to raise an exception, not
attempt to convey the exception in the return value.
Can one /conceive/ of failed search as an exception, justifying ML's
approach? Sure. I once had to live with a library routine that treated
/successful/ search as an exception! The programmer's reasoning: if you
are adding something to a collection, and checking first to see if it
already exists, then successful search is bad. <sigh>
So ML can conceive of failed search as an exception, but it's wrong. <g>
It is what they are forced into by strong-typing.
The second thing telling me the Lisp way is right is--I have a theory:
When two approaches can both be made to work, you can still tell which
one is right. The wrong approach requires more contortions ("looking
back at the code I wrote back in my ML days, it is full of exception
catching"). The right approach (when blended in during on-going
development) usually lets me /take out/ contortions, simplifying my code
in ways unanticipated when I conceived the change. OK, OK, Occam got
there first. :)
-- Ken
Martin Rodgers
Tim Bradshaw wheezed these wise words:
> CL-HTTP is miles ahead of any of the competition that I know of, for
> any lisp-based application. It's almost trivial to write things that
> export & import information directly from & to the structures in the
> program. CL-HTTP was also the first fully http-1.1 server (is it
> still?).
Yet it still lacks some critical features, like SSL.
> (of course the `for any lisp-based application' qualifier above may be
> seen as significant).
If you're only comparing it with other Lisp apps, then CL-HTTP appears
to have has no compeition. However, compare it with the servers listed
in the web server FAQs (comp.infosystems.www.*), and it looks rather
different. Of course, if CL-HTTP were a commercial app, then the admin
and security, features found in commercial web servers might be added
to CL-HTTP. Maybe even the commerce features, too.
> You don't need genera for cl-http.
Exactly. And it's just as well! The cost of a server can include the
whole machine, hardware, OS, and web server.
Francois-Rene Rideau
thor...@visi.com (David Thornley) writes:
> Face it, guys, the capitalist system is very inefficient about rewarding
> excellence; it's usually better at rewarding mediocrity. For most
> companies, the computer systems are not the heart of the business, and
> making them superbly efficient is unlikely to help the business nearly
> as much as making the wrong choice is likely to hurt it. It's
> expensive to make changes, and the upside is likely to be streamlining
> a medium-sized chunk of their staff work. It's a matter of optimization.
> It may not be worth it.
I am not sure about the validity of what you imply above. I look at
this problem as being largely customer driven. If cars or bridges were
as poorly designed as some commercial software that I have on this PC
next to me, lawyers would be in lawsuit heaven. As it is, as long as
the customers accept crap, and spend their good money on crap, they
will be sold that crap at the highest price they are willing to pay,
delivered to them via the six-pack of crappy programmers that the
manager picked up at the local programmers store.
I think this is starting to change as consumer software becomes more
demanding and the price point for decent hardware remains the
same. People start to notice that they are spending hard earned money
on crap.
Well, the problem is that mass-communication, advertisement, etc,
are currently producer-driven, not consumer-driven at all. Hence,
we do NOT have a fair market that'd allow liberalistic economy to
work well. Consequently, what consumers purchase is crap and will
stay so according to all non-obvious criteria. If you want things
to improve, you should help appear consumer-driven communication,
and its consequence, consumer-controlled market. [This reminds me
of articles by Bastiat, written in 1850, about the egoistic inte-
rest of producers leading to ruin, while those of consumers leads
to prosperity]. I don't see a consumer-driven economy appearing
any time soon, but still I hope it's possible, and will try to
make it happen sooner by convincing people of its necessity.
Regards,
== Faré -=- (FR) François-René Rideau -=- (VN) Уng-Vû Bân -=- rid...@ens.fr ==
Join a project for a free reflective computing system! | 6 rue Augustin Thierry
TUNES is a Useful, Not Expedient System. | 75019 PARIS FRANCE
http://www.eleves.ens.fr:8080/home/rideau/Tunes/ -=- Reflection&Cybernethics ==
Daniel Wang
Juliusz Chroboczek <j...@dcs.ed.ac.uk> writes:
> [crossposted to comp.lang.ml: we need a good flamewar]
>
I started to give an example about a searching function which returns
> a string on success and NIL on failure.
>
> `I'd just raise an exception on failure!' (that's ML-speak for
> throwing out of a scope)
>
> I then realised that because ML is strongly typed, ML programmers are
> likely to use techniques that we don't need in Lisp. And, sure
> enough, looking back at the code I wrote back in my ML days, it is
> full of exception catching. While my last 3000 lines of Lisp have
> three catch forms (plus a few error handlers, but I think that's a
> different issue).
>
As an ML hacker you really have two choices raise an execption or use the
option type. i.e.
- fun silly fail s =
if fail then NONE
else (SOME s)
val silly = fn : bool -> 'a -> 'a option
- silly true "string";
val it = NONE : string option
- silly false "string";
val it = SOME "string" : string option
- silly true 0;
val it = NONE : int option
- silly false 0;
val it = SOME 0 : int option
The type system will then force you to check and deal with all the
exceptional cases. You need not resort to handlers.
Martin Rodgers
Tim Bradshaw wheezed these wise words:
> But `working out of the box' pretty much means `serving a bunch of
> html files', or perhaps serving data from some relational database.
And a _lot_ more. CL-HTTP already has some of these things, like web
based admin, authentication and access control.
> Well, CL-HTTP can do that, sure, but it's hardly an interesting
> application, is it?
Maybe not to research people. Perhaps I'm playing Devil's Advocacte,
by looking at Cl-HTTP from the world of commerce.
> What you want is a web server that lets you do things that are
> interesting with the web: dynamically created web pages, web
> interfaces to large SW systems, &c &c. A system like that will not
> run out of the box, because you're going to have to bite the bullet
> and write programs. Writing such programs using CL-HTTP is a delight,
> especially after fighting with perl CGI scripts.
It depends on what you mean by "dynamic". You can generate pages
dynamically from databases. I've seen entire websites that work this
way. You do indeed need to write the templates for the dynamic pages,
but it doesn't need to be done in _perl_ (yuk). It's not only Lisp
programmers who're repulsed by perl. That's why there are alternatives
to perl, like template languages with embedded SQL.
> In fact, to go off at yet another tangent, this `run out of the box'
> idea is one of the most pervasive & dangerous misconceptions currently
> around. Non-trivial applications do not run out of the box. I hear
> so many people say `just get NT and office 97 and blah and we can just
> run our MIS system on the web and it will have no maintenance and it
> will just work and all the problems are solved', and this is just
> obvious crap: how do we do access control? who is going to run the NT
> box? who does the backups? Sure, these tools may make things somewhat
> easier, but they do not solve the interesting problems, because the
> greater part of these problems is hard, idiosyncratic, and require
> thought and time -- that's why they're interesting. There is no
> silver bullet.
Doing anything dynamic with a web server requires some work. The
phrase "out of the box" refers to the amount of time requires to get
something working, however basic. Today's commercial web servers can
be installed in minutes, and it only takes a little longer to connect
them to a databae and start delivering pages. That's a big selling
feature - you can impress the hell out of people with very little time
and effort.
This won't matter to everyone, but I'm giving one reason why CL-HTTP
won't impress everyone. Whether those people matter or not is
debatable. After all, CL-HTTP isn't really competing with the
commercial web servers.
The OS overheads don't matter - there'll be overheads like backups for
_any_ kind of server. Some people choose NT, some choose Unix, and
others may choose something else. IME they do this because of past
experience with than OS. Pick something you know and can quickly get
results with, because time costs money. And life is short.
Lisp can't work miracles. The question here is: Can CL-HTTP make
creating dynamic web apps easier than commercial web servers? This
will depend on the domain; research, commerce, whatever. If you wish
to ignore commerce, then I'm sure that CL-HTTP will do very nicely.
I'd certainly use CL-HTTP, if I were choosing a web server.
As the subject of this thread is "Limitations of Lisp", I'd suggest
that Lisp's limitations are also it's strengths. And vica versa.
Of course, this is true of everything, so it probably isn't much help.
It's hard to please everyone. Maybe no software can do that...
Espen Vestre
mcr@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin Rodgers) writes:
> Just not very competitive with rival web technology. CL-HTTP alone is
> lagging behind the top commercial web servers, while Genera is a lot
do you have any examples of actual "top commercial web servers"?
My experience is that they're all overhyped. Speaking e.g. of Netscape,
their software (client or server) may be feature-rich, but it's
usually very slow and extremely bloated (gee, I think my netscape client
just passed 40MB of RAM usage).
> My hope is that Lisp-based web development is one of those activities
> that is mainly done in-house
you might be right! I'm developing our second lisp-based webserver now,
but it will only be used for internal purposes.
> The only real problem with CL-HTTP is that not enough people know
> about it. If Harlequin bundle it with LWW and place adverts for it in
> mainstream development mags, the message should get to a few people.
Hmm, I actually think that more and more people are getting to know it.
And the Franz web site had a cover story on it.
> Match non-Lisp based web servers feature for feature, make sure it's
> as easy to administrate as the rivals, add remote admin, and then sell
> it as rocket powered web technology, and you could compare all the
> other web servers to steam power. The "rocket powered" label would be
> more convincing if it wasn't based on an assumption that Lisp alone is
> enough to make an app superior. Most people don't know this.
Hmm, it _would_ perhaps be an idea to make a "thing-that-goes-bing"
commercially packaged version of CL-HTTP in order to assist eager
programmers to convince their bosses ;-) What do the CL-HTTP community
think of this?
--
regards,
Espen Vestre
Telenor Nextel AS
Norway
Reginald S. Perry
mcr@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin Rodgers) writes:
> Reginald S. Perry wheezed these wise words:
>
> > Well it sort of depends on the type of tool that you are looking
> > for. Some of this stuff would be fitting square pegs into round
> > holes. Could you give me some examples?
>
> Examples? See the various Windows development magazines, as you'll
> find adverts and reviews for many of them. Some mags list new tools,
> and it's not unusual to see web-related tools appearing in these
> pages. It might not be so easy to find such tools on the web unless
> you look for them.
>
You seem to want a Lisp counterpart for every C/C++/Java component out
there. This is not something that is going to happen anytime soon. And
maybe it shouldn't. I see a lot of developers using tools that they
are forced either to warp their spec or warp the intended usage of the
tool to solve their problem instead of just building the tool
in-house. The illusion is that the former takes less time than the
latter, but I am not so sure. You have to measure the final design in
contrast to what would have happened had you not warped the spec. In
addition some things do look more straightforward than the C
counterpart. For example Harlequin's CAPI looks easier to use than Motif.
>
> Many web tools are just things like database interfaces. However, as
> that's a very useful tool in a corporate world, this is far from
> insignificant. Some other tools may be little more than TCP/IP
> components, altho they do tend to come with source code examples for
> many Internet apps, like SMTP, FTP, etc.
>
> These tools tend to build on what Windows developers will already
> know, exploiting tools they're already familiar with. Even if the
> languages are inferior to Lisp, that leverage helps a lot. Throw a
> familiar SQL query into an HTML template, and bam! You've got a web
> app. There's a big demand for that. CL-HTTP probably isn't going to
> compete well at that level, but as the server tasks get more complex,
> Cl-HTTP will gain a killer edge over the more primitive tools.
>
I think that you are trying to move CL-HTTP out of its intended
realm. If I just want to serve web pages and run a CGI script here and
there, just use Apache and perl. Its free and runs just about
everywhere. If you feel insecure with that, use IIS. It comes with NT
Server. But if you are tired of having to invent wierd ways to
maintain state between transactions, and/or have novel ideas on how
you want to deliver information to the web, then the other tools are
quite inadequate for the job and CL-HTTP is the way to go.
Now I would say that there may be areas in which CL-HTTP could
improve, but I would say that as more people start to use it, you will
have people interested in performance. The thing is that there are so
many cool things that you can do with a server as dynamic as CL-HTTP,
that people are playing with their cool ideas, as they should. I would
say that people like me who are comming in on the ground floor and
slowly learning things should probably contribute the more mundane
things like SMTP, FTP, maybe get more ambitious at some point and do
IMAP, and other network tools of that ilk, and work on documenting the
server and such. This will let the gurus push the envelope while still
getting the server into good enough shape to allow people who just
want to serve web pages with a lisp web server be able to get started
quickly. So I dont think I can complain about what a free product
lacks unless I am willing to put that feature in, if no one else is
interested at the time. This is what the free software movement is
about right? Especially for something like CL-HTTP where most people
are very interested in novel ways of doing dynamic content creation
and presentation.
> The really interesting tools are being built on top of the basic
> networking tools. Much of that kind of work is done in-house, but you
> can read about some examples in magazines like Byte. There's probably
> little of it that can't easily be done in Lisp, but I've yet to read
> _any_ "how to" style articles using Lisp. This may be because Lisp
> programmers find it so much easier that we don't need a "how to"! Such
> an article be useful for explaining to others less Lisp-literate than
> ourselves why we use Lisp, and that this is not just "An interesting
> option when development time is limited."
> --
Like I said before, I dont know how to lead someone to a particular
programming language or convince someone that Lisp is nicer than
something else. When I mention Lisp to some co-workers I just get the
look of the crazy one touched by the Gods whom they should just smile
at but not touch. :-)
I say lets stop wasting valuable time trying to do that and spend more
time writing the mundane apps on the way to attempting to become gurus
ourselves.
-Reggie
Marco Antoniotti
Juliusz Chroboczek <j...@dcs.ed.ac.uk> writes:
>
> [crossposted to comp.lang.ml: we need a good flamewar]
>
> In article <64ptde$ci6$1...@darla.visi.com>,
> thor...@visi.com (David Thornley) paraphrased Him:
>
> DT> Face it, guys, the capitalist system is very inefficient about
> DT> rewarding excellence; it's usually better at rewarding mediocrity.
>
> Right. And C and C++ programmers will be the first against the wall
> when the Revolution comes. (A ghost is haunting Europe, the ghost of
> Dynamic Typing.)
>
Hey! We even have the right name for our language "Common Lisp"
(commonlisp, communlisp ...) and a "Stalin" compiler for Scheme :)
--
Marco Antoniotti
==============================================================================
California Path Program - UC Berkeley
Richmond Field Station
tel. +1 - 510 - 231 9472
Tim Bradshaw
* Juliusz Chroboczek wrote:
> I don't know which way is right. C's way of always returning a value,
> even on error, is definitely wrong. But what should be done in an
> exceptional situation which is not an error? Lisp often chooses to
> return NIL (or some other distinguished value), while ML raises an
> exception. But the point is that I would not have become aware of
> this choice had I not learnt a modern strongly typed language (ML).
> (Similarly, one might argue that the purely functional nature of
> Haskell led Wadler to use Moggi's ideas about monads, which would
> never have been used in programming otherwise.)
I'd add to that the technique of returning multiple values --
typically one being the answer, and another being a success flag.
That way you can remain strongly-typed but still indicate failure
succinctly. I do this a lot, though I'm not sure where I get it from
other than finding CL's condition system a bit hairy.
--tim
Rainer Joswig
In article <MPG.edd584be...@news.demon.co.uk>,
mcr@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin
Rodgers) wrote:
> won't impress everyone. Whether those people matter or not is
> debatable. After all, CL-HTTP isn't really competing with the
> commercial web servers.
Why don't you get it? People are already *selling* web servers
based on CL-HTTP. Those may not need be using Lisp at all.
Rainer Joswig
In article <MPG.edd10716...@news.demon.co.uk>,
mcr@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin
Rodgers) wrote:
> This is exactly what I'm hoping will happen. With so many web servers
> that work "out of the box", CL-HTTP is at a severe disadvantage. Now,
> bundle it with a commercial Lisp system that installs CL-HTTP at the
> same time, with a menu item that runs the server, another menu item or
> script that creates a stand alone binary, plus some simple admin user
> interface for quick results, and maybe CL-HTTP could geta foot in the
> door. Then the sales pitch can begin!
Guess what, load CL-HTTP into MCL and you get a basic menu for the
server (you can start, stop, inspect, change debug settings, edit code,
load code, get pages, open urls in a local browser,
find documentation, load demos, ...
...
(defun development-items ()
(list (make-about-menu-item)
(make-release-notes-menu-item)
(make-license-menu-item)
(make-mac-readme-menu-item)
(when (fboundp 'ccl::open-url)
(make-open-url-item))
(divider-item)
(make-preferences-menu-item)
(make-load-configuration-menu-item)
(make-save-configuration-menu-item)
(divider-item)
(make-startup-menu-item)
(make-start-server-menu-item)
(make-stop-server-menu-item)
#+open-transport(make-reset-network-menu-item)
(divider-item)
(make-menu-from-inspect-menu-description)
(make-find-documentation-menu-item)
; (make-show-documentation-menu-item)
(make-menu-from-tool-menu-description)
(divider-item)
(make-toggle-var-item 'http:*debug-server*
"Debug Server"
"On error the server enters a break loop.
Not for production use.")
(make-toggle-var-item 'ccl::*use-resolver*
"Use DNS Resolver"
"Controls the MCL DNS resolver code.")
(make-toggle-var-item 'http:*log-resolve-ip-addresses*
"Resolve IP Adresses for Logging"
"All IP Addresses will be resolved for the
log. For production servers you may want to turn it off.")
(when (or (fboundp 'http::show-url)
(fboundp 'http::show-url-headers)
(boundp 'http::*debug-client*))
(divider-item))
(when (boundp 'http::*debug-client*)
(make-toggle-var-item 'http::*debug-client*
"Debug Client"
"On error the client enters a break loop.
Not for production use."))
(when (fboundp 'http::show-url)
(make-show-url-item))
(when (fboundp 'http::show-url-headers)
(make-show-url-headers-item))
(when (fboundp 'http::show-raw-url)
(make-show-raw-url-item))
(when (fboundp 'http::show-url-options)
(make-show-url-options-item))
(when (fboundp 'http::show-url-trace)
(make-show-url-trace-item))
(when (fboundp 'http::enable-proxy-service ) (divider-item))
(when (fboundp 'http::enable-proxy-service)
(make-toggle-menu-item 'http::proxy-service-enabled-p
'http::enable-proxy-service
'http::disable-proxy-service
"Enable Proxy"
"CL-HTTP provides a proxy
service."))
(when (boundp 'http::*debug-proxy*)
(make-toggle-var-item 'http::*debug-proxy*
"Debug Proxy"
"On error the proxy enters
a break loop.
Not for production use."))
(when (boundp 'http::*proxy-caching-p*)
(make-toggle-var-item 'http::*proxy-caching-p*
"Use Caching for Proxy"
"The Proxy caches requests."))
(divider-item)
(make-edit-system-menu)
(make-action-system-menu :load
"Load CL-HTTP System")
(make-action-system-menu :compile
"Compile CL-HTTP System")
(make-action-system-menu :compile-load-always
"Compile and Load (Always) CL-HTTP System")
(make-action-system-menu :compile-load
"Compile and Load CL-HTTP System")
(make-load-extensions-menu)))
You just need to start your save Lisp image
and choose "Start Server with Demos with DNS" from
the CL-HTTP menu. Off you go.
Once I have a usable CLIM for MCL and/or LWW, I'll start writing a CLIM based
user environment for CL-HTTP.
How about stop whining and writing some code?
Martin Rodgers
Rainer Joswig wheezed these wise words:
> Why don't you get it? People are already *selling* web servers
> based on CL-HTTP. Those may not need be using Lisp at all.
Do you mean that they may be stand-alone apps, not requiring a full
Lisp system in order to run CL-HTTP? That's great, because it reduces
the cost per machine when a commercial CL is used.
I _do_ get it, Rainer. I just have the ability to see things from the
point of view of the people who _don't_. Please don't confuse me with
those other people.
If CL-HTTP is competing with commercial web servers as a package
(complete machine setup or prebuilt server binary), by Lisp
developers, then this is no different to how any other web server is
being used commercially.
There are two distinctions that I'm making here. One is between
servers that are themselves commercial, i.e. you have to pay in order
to use them (apart from free evaluation, if that option is available)
and there are restrictions on the number of machines on which they can
be installed. The other distinction is between servers used for
commercial and non-commercial applications. The latter is a tricky
one, as it may depend on who hosts the site and what they consider to
be commercial.
Perhaps it's possible to make it clearer how other people (non-Lisp?)
see CL-HTTP? The web FAQ leads us to the webcompare site, which has
the following page for CL-HTTP:
<URL:http://webcompare.internet.com/compare/clhttp.html>
Martin Rodgers
Rainer Joswig wheezed these wise words:
> > Yet it still lacks some critical features, like SSL.
>
> Critical for whom?
Anyone who wants security. For example, anyone wishing to trade via
their website. As I said yesterday, not everyone will want to do such
things. I don't expect researchers to do this, but they might have
other uses for SSL.
Note every server can offer every feature, and every server has a few
weaknesses. It would unreasonable to expect a free server to compete
with the most popular commercial web servers. In spite of this, I
think that CL-HTTP is a very capable server. I'm happy to see that I'm
not the only one:
<URL:http://webcompare.internet.com/compare/clhttp.html>
This won't impress everyone, nor should we expect it to. However, a
side by side comparison with commercial servers can still show that
CL-HTTP can give some healthy competition. Whether or not it meets
your needs will vary, depending on the nature of your needs.
This is why I pointed out the lack of SSL. I'm not condemning CL-HTTP
by saying that some people will consider this to be critical. YMMV.
We choose CL-HTTP. Many others don't. Is that heresy or observation?
Is it wrong to offer reasons why people may overlook this fine server?
Is that the same as endorsing such a choice? I hope not.
> How about implementing SSL in Lisp? Definitely more needed
> than just another Lisp compiler.
That's debatable. If someone writes a tool, like a compiler, that does
something not currently done by an existing tool, that could be worth
doing. You may have no use for that tool, but others might. The
programmer who writes it could do it because _they_ have a use for it.
It's hard for anyone else to deny that.
If you wish to tell me what my priorities are, then pay for my time.
Martin Rodgers
Rainer Joswig wheezed these wise words:
> Guess what, load CL-HTTP into MCL and you get a basic menu for the
> server (you can start, stop, inspect, change debug settings, edit code,
> load code, get pages, open urls in a local browser,
> find documentation, load demos, ...
Excellent. That's exactly what CL-HTTP needs, IMHO.
> Once I have a usable CLIM for MCL and/or LWW, I'll start writing a CLIM based
> user environment for CL-HTTP.
Even better!
> How about stop whining and writing some code?
How about paying attention? How about not assuming that because I have
something to say that you don't like, that I don't write code or don't
have a right to an opinion. How about accepting that someone you don't
agree with may still express an opinion? How about not assuming that
Lisp will just win _because it's Lisp_?
You can go into hyper-critical mode if you like, which is why I
refered to "Devil's Advocate" in an earlier post. You're not the only
one who can be hyper-critical - this what I've been doing, in order to
make a point. Not everyone automatically sees Lisp and says, "This
will beat everything else. It's just what I need." Quite the opposite,
in fact.
I'm _not_ knocking CL-HTTP. I'm putting it into context. If this was
the only web server available, there'd be nothing to compare it to. As
this is not the case, I'm comparing to the alternatives.
How about accepting that here are alternatives for CL-HTTP to compete
with? Maybe you won't choose anything but a Lisp-based solution, and
perhaps nobody demands that you justify your choice, but this is not
the case for everyone. In many cases, when this is the case, the
choice won't be Lisp, it'll be C++. (Note the number of servers with
C++/CGI support.) These people will automatically choose C++, just as
_we_ (yep, me too) automatically choose Lisp.
Writing code isn't always the answer, esp if your time is payed for by
people who choose C++. Sometimes the developers themselves choose it!
This is why I'm interested in comparing CL-HTTP with the alternatives,
and trying to be just a little objective. If CL-HTTP can survive such
a comparison, doesn't it look good? If you're going to choose CL-HTTP
anyway, this is not an issue, but...
How about checking the subject of this thread? Automatically choosing
Lisp and Lisp-based solutions doesbn't always the question that
started this thread. How about that?
Martin Rodgers
Reginald S. Perry wheezed these wise words:
> You seem to want a Lisp counterpart for every C/C++/Java component out
> there.
No, that's not what I want. My point is that's what most people
looking for web solutions will want, because that's what they've been
lead to believe is the way it's done. For us to show that there are
other ways, we have to offer a very good counter argument to the
"orthodox" solutions.
> This is not something that is going to happen anytime soon.
I agree. Perhaps this is because of a lack of communication. If we
simply state that "Lisp is best", then we're doing no more than the
people who say, "C++ is best", or "Java is best", and the many other
variations of that argument.
I'm not necessarily interested in doing the same things as C++ folk.
If I was, then I'd just use C++. OTOH, we don't have to reject
everything (throwing out the baby with the bathwater), and I don't
that will help whoever started this thread asking for "Help required
on Limitations of Lisp".
> I think that you are trying to move CL-HTTP out of its intended
> realm. If I just want to serve web pages and run a CGI script here and
> there, just use Apache and perl. Its free and runs just about
> everywhere. If you feel insecure with that, use IIS. It comes with NT
> Server. But if you are tired of having to invent wierd ways to
> maintain state between transactions, and/or have novel ideas on how
> you want to deliver information to the web, then the other tools are
> quite inadequate for the job and CL-HTTP is the way to go.
Strangely, most people see _Lisp_ as the weird ways of doing things.
Hence the "Help required on Limitations of Lisp" question.
I'm not arguing in favour of C++. If I'm playing Devil's Advocate,
it's only to explain why anyone would wish to ask about "Limitations
of Lisp", instead of just using it.
> I say lets stop wasting valuable time trying to do that and spend more
> time writing the mundane apps on the way to attempting to become gurus
> ourselves.
Is it a waste of time to help answer a question? Or does the subject
of this thread, "Help required on Limitations of Lisp" (I'm ignoring
the "Lisp OS" for the sake of a quiet life), not tell you something?
Do you have a better argument than "Lisp is best"? Unless I'm
mistaken, just saying that "Lisp is best" doesn't explain what the
limitations of Lisp may or _may not_ be. It doesn't address the issue.
So what should a programmer do, if their boss doesn't understand Lisp,
and don't wish to? Just use Lisp anyway, and see what happens? How
about offering something more constructive? Maybe "Quit your job and
look for some place where they appreciate Lisp"? Yeah, right.
At least I'm trying to answer the question, instead of denying that it
was asked. Let's see that question again:
> 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.
IMHO the biggest limitation of Lisp is the "C++ is best" crowd and
their complete hostility to the "Lisp is best" crowd. Maybe the lack
of communication is the results of absolutist "X is best" attitudes?
A little perspective can do wonders for seeing the other side's point
of view, and that's the first step toward communication.
In other words, people are the problem. ;)
Rainer Joswig
In article <MPG.ede0c3f2...@news.demon.co.uk>,
mcr@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin
Rodgers) wrote:
> Do you mean that they may be stand-alone apps, not requiring a full
> Lisp system in order to run CL-HTTP?
Sure. We are talking about applications here. Not about development
systems.
> If CL-HTTP is competing with commercial web servers as a package
> (complete machine setup or prebuilt server binary), by Lisp
> developers, then this is no different to how any other web server is
> being used commercially.
That's what I'm saying.
> Perhaps it's possible to make it clearer how other people (non-Lisp?)
> see CL-HTTP? The web FAQ leads us to the webcompare site, which has
> the following page for CL-HTTP:
> <URL:http://webcompare.internet.com/compare/clhttp.html>
I'm not sure if this is really helpful, if the information comes
from people who may never have used CL-HTTP.
Jon Thackray
Ken Tilton <ti...@bway.net> writes:
>
> Juliusz Chroboczek wrote:
> >
> > I started to give an example about a searching function which returns
> > a string on success and NIL on failure.
> >
> > `I'd just raise an exception on failure!' (that's ML-speak for
> > throwing out of a scope)
> >
> > I then realised that because ML is strongly typed, ML programmers are
> > likely to use techniques that we don't need in Lisp. And, sure
> > enough, looking back at the code I wrote back in my ML days, it is
> > full of exception catching.
There is no particular reason for this to be the case. My personal
belief is that exceptions are for exceptional circumstances.
> [...]
>
> >
> > I don't know which way is right. C's way of always returning a value,
> > even on error, is definitely wrong. But what should be done in an
> > exceptional situation which is not an error?
>
> I vote for the Lisp way.
>
> First, it /sounds/ perfectly reasonable that a function asked to search
> for something in a collection matching some criteria should be able to
> say "Nothing". That is not an exception, that is a reasonable and normal
> result.
And ML can do this. Instead of using a function
search : key * table -> value
use
search : key * table -> value option
> An exception would be something like searching for a customer with an
> invalid customer number (it flunks some check-digit test). You /could/
> just say "Nothing", but that is not completely forthcoming; better to
> say "Invalid query" and then you /do/ want to raise an exception, not
> attempt to convey the exception in the return value.
And ML can do this as well.
> Can one /conceive/ of failed search as an exception, justifying ML's
> approach? Sure. I once had to live with a library routine that treated
> /successful/ search as an exception! The programmer's reasoning: if you
> are adding something to a collection, and checking first to see if it
> already exists, then successful search is bad. <sigh>
This is not ML's approach, it is simply the approach of one particular
ML programmer. There is nothing to stop you providing several search
routines, each for a particular purpose, one of which might be the
above example.
> So ML can conceive of failed search as an exception, but it's wrong. <g>
Actually, it is you that is wrong here.
> It is what they are forced into by strong-typing.
And that is also incorrect.
> The second thing telling me the Lisp way is right is--I have a theory:
> When two approaches can both be made to work, you can still tell which
> one is right. The wrong approach requires more contortions ("looking
> back at the code I wrote back in my ML days, it is full of exception
> catching"). The right approach (when blended in during on-going
> development) usually lets me /take out/ contortions, simplifying my code
> in ways unanticipated when I conceived the change. OK, OK, Occam got
> there first. :)
I think you'll find ML is as capable of right ways and wrong ways as
Lisp.
--
Dr. Jon Thackray jo...@harlequin.co.uk 44 1223 872522 (voice)
Harlequin Ltd. 44 1223 873873 (fax)
Barrington Hall
Barrington
Cambridge CB2 5RG
England
Rainer Joswig
In article <MPG.edd50012...@news.demon.co.uk>,
mcr@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin
Rodgers) wrote:
> Yet it still lacks some critical features, like SSL.
Critical for whom?
How about implementing SSL in Lisp? Definitely more needed
than just another Lisp compiler.
Ken Tilton
Matthias Blume wrote:
>
> In article <64t0bd$o2s$1...@goldenapple.srv.cs.cmu.edu> Juliusz Chroboczek <j...@dcs.ed.ac.uk> writes:
>
> [ a moderately lengthy discussion of how different programming styles
> handle cases where a function cannot return a "normal" result;
> claiming that ML programmers would usually use exceptions for this
> purpose ]
>
[snip]
>
> In situations where the "out of band" value is more frequent I would
> have the function return an "option" type.
As several mail respondents noted, I wa sunaware of the 'option' option.
:)
Still sounds like unnecessary work just to say "nothing found"; now I am
unwrapping an option instead of trapping an exception. Strong-typing
(with all its advantages) is still contorting my code.
>
> The drawback of C's (and Lisp's) habit of returning an "impossible"
> value is that it is not always obvious what the impossible value
> should be.
True, but in the case of "search", I do not see "nothing" as an
impossible result.
> In the untyped world of Lisp, it is often the case that there
> is no "impossible" return value, in which case the technique of
> returning one breaks down.
True. Then Lispers have to return multiple values.
-- Ken
Reginald S. Perry
mcr@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin Rodgers) writes:
> Reginald S. Perry wheezed these wise words:
>
> > You seem to want a Lisp counterpart for every C/C++/Java component out
> > there.
>
> No, that's not what I want. My point is that's what most people
> looking for web solutions will want, because that's what they've been
> lead to believe is the way it's done. For us to show that there are
> other ways, we have to offer a very good counter argument to the
> "orthodox" solutions.
>
Well its a little tough to use CL-HTTP in this context because its
initial goal was different then say the Apache team's goal. Now if you
say you would like to see CL-HTTP be feature compatible with the other
web servers then I bet the gurus would say "*yawn* thats nice" because
their interests are a lot different. I think that it will eventually
get to this point but that what may happen is that the people who are
first learning the system will probably contribute the things that
flesh out the features that they feel they need as a first project to
cut their teeth on. This is because the focus for CL-HTTP (I think) was
not to make a server that does everything the commercial servers do,
but to do the sort of cool things that can only be done in a dynamic
environment while still being able to do web server stuff. If it was a
commercial product, it would have been clear from the outset that in
order to sell product it would have to do *all* of the things
commercial web servers do *at least as well* and also do its special
cool stuff. Since its a volunteer project, all of the little bells and
whistles may not be there, but I assert that this is only until
someone puts them in.
> > This is not something that is going to happen anytime soon.
>
> I agree. Perhaps this is because of a lack of communication. If we
> simply state that "Lisp is best", then we're doing no more than the
> people who say, "C++ is best", or "Java is best", and the many other
> variations of that argument.
>
> I'm not necessarily interested in doing the same things as C++ folk.
> If I was, then I'd just use C++. OTOH, we don't have to reject
> everything (throwing out the baby with the bathwater), and I don't
> that will help whoever started this thread asking for "Help required
> on Limitations of Lisp".
>
> > I think that you are trying to move CL-HTTP out of its intended
> > realm. If I just want to serve web pages and run a CGI script here and
> > there, just use Apache and perl. Its free and runs just about
> > everywhere. If you feel insecure with that, use IIS. It comes with NT
> > Server. But if you are tired of having to invent wierd ways to
> > maintain state between transactions, and/or have novel ideas on how
> > you want to deliver information to the web, then the other tools are
> > quite inadequate for the job and CL-HTTP is the way to go.
>
> Strangely, most people see _Lisp_ as the weird ways of doing things.
> Hence the "Help required on Limitations of Lisp" question.
>
> I'm not arguing in favour of C++. If I'm playing Devil's Advocate,
> it's only to explain why anyone would wish to ask about "Limitations
> of Lisp", instead of just using it.
>
Its always hard to say what the limitations of a certain language
is. Especially when the people you are talking about are thinking more
about the particular implementations out there than the language
itself. If I look only at MSVC++ I would say that C++ is hard to
optimize but the Watcom C++ compiler and the DEC C++ complier show this
to be untrue.
This started out as a discussion on the limitations of Lisp but then
you wanted to explore how to get more people using Lisp. When I think
only about the question about the limitations of Lisp, I look at CLOS
the condition system, and how extensible the language is and I see
that the only limitations are in our heads. It just depends on what
one wants out of a language. The languages that are interesting to me
at this point in my life are Lisp, SML, and Modula-3. Meanwhile I earn
a living programming in C++ and Java. Go Figure.
>
> At least I'm trying to answer the question, instead of denying that it
> was asked. Let's see that question again:
>
> > 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.
>
> IMHO the biggest limitation of Lisp is the "C++ is best" crowd and
> their complete hostility to the "Lisp is best" crowd. Maybe the lack
> of communication is the results of absolutist "X is best" attitudes?
> A little perspective can do wonders for seeing the other side's point
> of view, and that's the first step toward communication.
>
> In other words, people are the problem. ;)
Actually this is not a very precise question. It all depends on what
one wants to do, which is why the discussion fell off of the beaten
path. At zeroth level there is nothing that you can do in other
languages that you cannot do in Lisp. Lisp has ran on huge machines,
tiny embedded controllers and everything in between. So the question
that this person could be asking is why should they use Lisp instead
of some other language. I cannot answer this for them, I can only say
why I like Lisp. And since Lisp is a family of languages you should
probably say which Lisp you have in mind when you are talking about
things. The one I like the most is ANSI Common Lisp. So when I say
Lisp, this is the Lisp I mean.
Software Engineering, while trying to be as precise a discipline as say
Civil Engineering, is currently more art than engineering. So I use
the programming language as a form of expression, trying to map the
abstract ideas in my head into instructions for the machine. Lisp
seems to provide me with the greatest range of expression, allowing
one to try out things and have the correct solution evolve instead of
having to work out lots of details up front. I like tools that let me
work the way I want and does not force me into their way of
working. Lisp seems to be that tool. The languages that we now use
like C, C++, and Java, force me to do a lot of up-front thinking about
low level details of the problem which I wont really understand until
I have worked out possible solutions, when I have possible solutions
*then* I will know which data structures and such I can use. Its
easier to work out generalized frameworks to sit your solution on in
Lisp. I think this is because generic functions which have multiple
dispatch allow more expression than the other single dispatch OO
languages.In C++ the STL allows a bit of this kind of power, but look
at the infrastructure they had to construct to do it. *Sheesh*
Now I feel that I haven't even scratched the surface of what I can do
with the environment. It takes some time to actually get comfortable
with being able to do pretty much what I want instead of changing what
I want so that it will compile in the language of the day. So having
while Lisp on your resume is not a sure-fire way to get a job, I would
say that the way that I now think about attacking problems is a result
of exposure to Lisp and I believe that as I gain mastery of Lisp and
being able to take advantage of its idioms, I will become a better
programmer.
Now does this answer the question? I would bet not.
Martin Rodgers
Reginald S. Perry wheezed these wise words:
> Well its a little tough to use CL-HTTP in this context because its
> initial goal was different then say the Apache team's goal. Now if you
> say you would like to see CL-HTTP be feature compatible with the other
> web servers then I bet the gurus would say "*yawn* thats nice" because
> their interests are a lot different.
Agreed.
> I think that it will eventually
> get to this point but that what may happen is that the people who are
> first learning the system will probably contribute the things that
> flesh out the features that they feel they need as a first project to
> cut their teeth on. This is because the focus for CL-HTTP (I think) was
> not to make a server that does everything the commercial servers do,
> but to do the sort of cool things that can only be done in a dynamic
> environment while still being able to do web server stuff.
There are certainly things being done in CL-HTTP that exploit Lisp
well. Interfacing a web server to Lisp code is a good example. If you
don't already use or know Lisp, this probably won't mean much, so it
might not help answer the question that started this thread, but it's
a point worth making.
> If it was a
> commercial product, it would have been clear from the outset that in
> order to sell product it would have to do *all* of the things
> commercial web servers do *at least as well* and also do its special
> cool stuff. Since its a volunteer project, all of the little bells and
> whistles may not be there, but I assert that this is only until
> someone puts them in.
Exactly. This may well be the kind of "limitation" that the subject of
this thread is asking about. In this case, it's a specific app, but if
that app is used to show how well Lisp can do things, then it may well
be relevant here. It's really a strength, but if it appears to be a
limitation to some people, then that's what'll be - for them.
We can just shrug our shoulders and ignore this, and that's the
easiest way to deal with it. I'm not sure it's a constructive answer,
but in the context of this thread, only Hasita Shah can know that.
> Its always hard to say what the limitations of a certain language
> is. Especially when the people you are talking about are thinking more
> about the particular implementations out there than the language
> itself. If I look only at MSVC++ I would say that C++ is hard to
> optimize but the Watcom C++ compiler and the DEC C++ complier show this
> to be untrue.
Object code quality is only one way of measure a compiler's value.
Just like with Lisp, really. One of Lisp's great strength's is the
quality of Lisp environments. However, in CL a significant part of the
environment is defined by the language, while this is not always the
case in other languages.
The tools that come with a language implementation add value to it.
> This started out as a discussion on the limitations of Lisp but then
> you wanted to explore how to get more people using Lisp.
No. I'm thinking specifically of Hasita Shah, who started this thread.
With so little information about an individual's requirements, it's
hard to say how well Lisp can help them. We can give some examples of
how Lisp can do useful things, and CL-HTTP can do this nicely. It has
the advantage of having a familiar and easily appreciated purpose.
It also makes it easily to compare with non-Lisp solutions, to see how
a Lisp solution can do things differently.
> When I think
> only about the question about the limitations of Lisp, I look at CLOS
> the condition system, and how extensible the language is and I see
> that the only limitations are in our heads. It just depends on what
> one wants out of a language. The languages that are interesting to me
> at this point in my life are Lisp, SML, and Modula-3. Meanwhile I earn
> a living programming in C++ and Java. Go Figure.
I'm in a similar position, except that my prefered languages would be
Lisp, O'Caml, and Haskell. At least, these are the languages I use for
my own projects. Like you, I get paid to use C++ and Java.
Will this be of some help to a student? I expect so. There are many
students who learn Lisp, even if they later get a job using something
else. This is not uncommon. Plus, you can learn programming in Lisp
that can help you when using other languages. My style of C coding
uses small functions, which I'm sure comes from using Forth and Lisp.
> > In other words, people are the problem. ;)
>
> Actually this is not a very precise question. It all depends on what
> one wants to do, which is why the discussion fell off of the beaten
> path. At zeroth level there is nothing that you can do in other
> languages that you cannot do in Lisp. Lisp has ran on huge machines,
> tiny embedded controllers and everything in between. So the question
> that this person could be asking is why should they use Lisp instead
> of some other language. I cannot answer this for them, I can only say
> why I like Lisp. And since Lisp is a family of languages you should
> probably say which Lisp you have in mind when you are talking about
> things. The one I like the most is ANSI Common Lisp. So when I say
> Lisp, this is the Lisp I mean.
Agreed. This is why I like the phrase, "Your Mileage May Vary" so
much. I frequently see that it does. We need more details about a
person's requirements if we wish to discuss a specific option. I find
that my own requirements can vary. Some things I find easier to do in
CL, others in Scheme, and so on. A lot of this depends on the tools
available how well their features match my requirements for that
project.
> Software Engineering, while trying to be as precise a discipline as say
> Civil Engineering, is currently more art than engineering. So I use
> the programming language as a form of expression, trying to map the
> abstract ideas in my head into instructions for the machine. Lisp
> seems to provide me with the greatest range of expression, allowing
> one to try out things and have the correct solution evolve instead of
> having to work out lots of details up front. I like tools that let me
> work the way I want and does not force me into their way of
> working. Lisp seems to be that tool. The languages that we now use
> like C, C++, and Java, force me to do a lot of up-front thinking about
> low level details of the problem which I wont really understand until
> I have worked out possible solutions, when I have possible solutions
> *then* I will know which data structures and such I can use. Its
> easier to work out generalized frameworks to sit your solution on in
> Lisp. I think this is because generic functions which have multiple
> dispatch allow more expression than the other single dispatch OO
> languages.In C++ the STL allows a bit of this kind of power, but look
> at the infrastructure they had to construct to do it. *Sheesh*
I'm very cautious about using any C++ features. I feel like I'm
building a house on loose sand. Lisp is much more stable, but the slow
rate of change can also be a kind of disadvantage. This is why some
people use the latest C++ tools. The language may such farts from dead
cats, but when you can guantee support for the latest OS features,
and time is painfully short, the options available might not be ideal.
Lisp is a better long term bet. Java is a good midrange bet. C++? Hmm.
Short term and highly over-rated IMHO. Alas, short term is what many
people are satisfied with. Fortunately, this may be irrelevant to a
student wishing to learn a good programming language. You can choose
Lisp and have a powerful too for life.
The software you write in Lisp should still have a life many (10? 20?
30?) years from now. I wouldn't say the same thing for C++ code. Some
C++ code may survive 20 years, but by then it'll be a very "dusty
deck". C++ code will be more dusty than any Common Lisp code, I bet. I
have C++ code from just few years ago that is already dusty, because
the language has changed dramatically! This has been a problem with C
compilers since I first started using the language, back in the early
80s. Each time I change to a different compiler, the language changed.
Then ANSI C appeared, and things might have improved, and if you can
code in pure ANSI C, maybe they have. Choose C++ and history repeats
itself, only with more pain. Consider:
"C makes it easy to shoot yourself in the foot. C++ makes it
harder, but when you do, it blows away your whole leg."
-- Bjarne Stroustrup on C++
I don't doubt it. By contrast, I feel that using Lisp is like falling
on a floor of big cushions. It's very soft, I can roll around and have
fun, and do useful things without getting hurt.
> Now I feel that I haven't even scratched the surface of what I can do
> with the environment. It takes some time to actually get comfortable
> with being able to do pretty much what I want instead of changing what
> I want so that it will compile in the language of the day. So having
> while Lisp on your resume is not a sure-fire way to get a job, I would
> say that the way that I now think about attacking problems is a result
> of exposure to Lisp and I believe that as I gain mastery of Lisp and
> being able to take advantage of its idioms, I will become a better
> programmer.
This is my experience, too. There's a slow learning curve, but it's
comfortable, and once you get going there's a stream of pleasant
suprises. Unlike some other languages, which will initially look very
attractive (partly coz so many other people are using them), and then
one day you begin to experience a series of painful suprises.
No wonder there C++ folk who compare their chosen language to using a
sharp knife. We, however, might compare Lisp to a sharp knife with a
_handle_ which will help us avoid a lot unnecessary cuts.
> Now does this answer the question? I would bet not.
Perhaps Hasita Shah could answer that one? I don't know.
Mitchell Wand
Ken Tilton <ti...@bway.net> writes:
> As several mail respondents noted, I wa sunaware of the 'option' option.
> :)
>
> Still sounds like unnecessary work just to say "nothing found"; now I am
> unwrapping an option instead of trapping an exception. Strong-typing
> (with all its advantages) is still contorting my code.
No, strong typing is just forcing you to do what you should always do-- namely
check to see whether the operation succeeded.
How many times in C do you forget to check the result of your mallc
if (p = malloc(...)) { ....} ?
<pardon my poor C>
The type system merely checks that you've done this before using the result.
If you don't want to check it immediately, you can pass the result around and
check it when needed.
--Mitch
Mitchell Wand Internet: wa...@ccs.neu.edu
College of Computer Science, Northeastern University
360 Huntington Avenue #161CN, Boston, MA 02115 Phone: (617) 373 2072
World Wide Web: http://www.ccs.neu.edu/home/wand Fax: (617) 373 5121
From: John Penix <jpe...@mingus.ececs.uc.edu>
Newsgroups: comp.lang.ml
Subject: measuring execution time
Organization: University of Cincinnati, ECE/CS News Server
Distribution: world
Path: not-for-mail
Reply-To: John Penix <jpe...@mingus.ececs.uc.edu>
Approved: comp-l...@cs.cmu.edu
hi, sorry to post this, but all of our ml books (except the crappy one
I have) are checked out of the library..
is there support for measuring execution time of ML programs?
thanks much,
John
--
John Penix University of Cincinnati ECECS
jpe...@ececs.uc.edu Knowledge-Based Software Engineering Lab
<a http://www.ececs.uc.edu/~jpenix/>I</a>
"I am, I exist, that is certain. But how often?" - Descartes
From: Xavier Leroy <Xavier...@see.my.sig.for.address>
Newsgroups: comp.lang.ml
Subject: Re: static typing considered harmful
Organization: INRIA Rocquencourt, projet Cristal
Distribution: world
Path: usenet
References: <64ddl4$ois$2...@trumpet.uni-mannheim.de>
<64ptde$ci6$1...@darla.visi.com>
<64t0bd$o2s$1...@goldenapple.srv.cs.cmu.edu>
<651vn3$jnk$1...@goldenapple.srv.cs.cmu.edu>
Sender: xle...@cadet.inria.fr
Reply-To: Xavier Leroy <Xavier...@see.my.sig.for.address>
Approved: comp-l...@cs.cmu.edu
"Bruce J. McAdam" <b...@dcs.ed.ac.uk> writes:
> This morning, Stefan Kahrs gave a talk, `When Types Get in the Way', to
> the ML-Club here in Edinburgh. This was largely a collection of
> examples showing situations when the type system becomes a nuisance in
> some way or another.
I had a look at the slides, and the examples show situations where the
*ML* type system goes in the way, but richer type systems
(e.g. with some amount of polymorphic recursion) would work fine.
So, it seems to me that the conclusions of this talk are more along
the lines of "we need better type systems" rather than "let's get rid
of static typing altogether".
- Xavier Leroy
--
Valid e-mail address (without the underscores): Xavier.Leroy@i_n_r_i_a.f_r
This is a protection against junk mail. Apologies for the inconvenience.
Home page: http://pauillac.inria.fr/~xleroy/
From: f...@mundook.cs.mu.OZ.AU (Fergus Henderson)
Newsgroups: comp.lang.lisp,comp.lang.ml
Subject: Re: Static Typing
Organization: Comp Sci, University of Melbourne
Distribution: world
Path: mundook.cs.mu.OZ.AU!fjh
References: <64ddl4$ois$2...@trumpet.uni-mannheim.de> <64ptde$ci6$1...@darla.visi.com> <64t0bd$o2s$1...@goldenapple.srv.cs.cmu.edu> <64v91f$jhv$1...@goldenapple.srv.cs.cmu.edu> <651rvt$i7a$1...@goldenapple.srv.cs.cmu.edu> <6527fg$mmo$1...@goldenapple.srv.cs.cmu.edu> <652c56$od6$1...@goldenapple.srv.cs.cmu.edu>
Reply-To: f...@mundook.cs.mu.OZ.AU (Fergus Henderson)
Approved: comp-l...@cs.cmu.edu
Marco Antoniotti <mar...@infiniti.path.berkeley.edu> writes:
>David Hanley <da...@netright.com.delete.me.silly> writes:
>
>> ML has multiple return value as well:
>>
>> (value,flag)=search(table,key);
>>
>> Will initlaize both values in ML.
>
>Technically (and AFAIK) ML does not have multiple values in the sense
>of Common Lisp.
In which technical sense do you mean?
>The CL MVs are crafted in such a way to enable compilers and
>interpreters to allocate the values on the stack. I don't think (if
>memory does not fail me) that ML has constructs for doing exactly the
>same.
It is certainly possible for ML compilers to allocate multiple return
values on the stack, or even better to return them in registers.
(Whether or not existing ML implementations do so is a different question.
But if you're worried about efficiency, I suspect that if you look at the
big picture, then a statically typed language like ML is likely to be more
efficient than a dynamically typed language like Lisp.)
--
Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger f...@128.250.37.3 | -- the last words of T. S. Garp.
From: f...@mundook.cs.mu.OZ.AU (Fergus Henderson)
Newsgroups: comp.lang.lisp,comp.lang.ml
Subject: Re: Static Typing
Organization: Comp Sci, University of Melbourne
Distribution: world
Path: mundook.cs.mu.OZ.AU!fjh
References: <64ddl4$ois$2...@trumpet.uni-mannheim.de> <64ptde$ci6$1...@darla.visi.com> <64t0bd$o2s$1...@goldenapple.srv.cs.cmu.edu> <64v91f$jhv$1...@goldenapple.srv.cs.cmu.edu> <651rvt$i7a$1...@goldenapple.srv.cs.cmu.edu>
Reply-To: f...@mundook.cs.mu.OZ.AU (Fergus Henderson)
Approved: comp-l...@cs.cmu.edu
Ken Tilton <ti...@bway.net> writes:
>As several mail respondents noted, I wa sunaware of the 'option' option.
>:)
>
>Still sounds like unnecessary work just to say "nothing found"; now I am
>unwrapping an option instead of trapping an exception. Strong-typing
>(with all its advantages) is still contorting my code.
In lisp, you would still need to check that the result was not null.
Why is unwrapping an option any worse? As I see it,
the only significant difference is that if you forget this step,
then in ML you get a type error at compile time, whereas in Lisp if you
forget to check that the result wasn't null then you will get a runtime error.
--
Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger f...@128.250.37.3 | -- the last words of T. S. Garp.
From: Erik Naggum <cle...@naggum.no>
Newsgroups: comp.lang.lisp,comp.lang.ml
Subject: Re: Static Typing
Organization: Naggum Software; +47 8800 8879; http://www.naggum.no
Distribution: world
Path: not-for-mail
References: <64ddl4$ois$2...@trumpet.uni-mannheim.de> <64ptde$ci6$1...@darla.visi.com> <64t0bd$o2s$1...@goldenapple.srv.cs.cmu.edu> <64v91f$jhv$1...@goldenapple.srv.cs.cmu.edu> <651rvt$i7a$1...@goldenapple.srv.cs.cmu.edu> <6527fg$mmo$1...@goldenapple.srv.cs.cmu.edu>
Reply-To: Erik Naggum <cle...@naggum.no>
Approved: comp-l...@cs.cmu.edu
* David Hanley
| I don't see how this is due to static typing. How exactly are you going
| to do this in lisp without exceptions, multiple return values, or
| multiple return types?
multiple return types? there's never more than one type (of each returned
value, that is). remember that Lisp has a type hierarchy, quite unlike
most statically typed languages. every type is a subtype of type t.
if all types and values are conceptually possible success values from a
function, any freshly consed object passed by the caller to the function
can be returned on failure, and is guaranteed not to be confused with a
success value. e.g., `read' can return _anything_, yet there is a need for
a guaranteed unique value to mean "end of file":
(let* ((eof (cons nil nil))
(object (read stream nil eof)))
(if (eq object eof)
(iff-eof)
(iff-real-object)))
#\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
David Hanley
Marco Antoniotti wrote:
> David Hanley <da...@netright.com.delete.me.silly> writes:
>
> >
> >
> >
> > Ken Tilton wrote:
> >
> ...
> >
> > I don't see how this is due to static typing. How exactly are you
> > going to do this in lisp without exceptions, multiple return values,
> > or multiple return types? ML has multiple return value as well:
> >
> > (value,flag)=search(table,key);
> >
> > Will initlaize both values in ML.
>
> Technically (and AFAIK) ML does not have multiple values in the sense
> of Common Lisp.
In the purest sense, yes, it return a single value, which is a tuple.As a
practical programming issue, it doesn't make much difference.
> The CL MVs are crafted in such a way to enable compilers and
> interpreters to allocate the values on the stack. I don't think (if
> memory does not fail me) that ML has constructs for doing exactly the
> same. (Even if the idiom you posted achieves pretty much the same
> effect).
I beleive this is unspecified. I could certianly concieve of an MLcompiler
using the stack for multiple return values. In fact, because
the types are typically known, the calling function could allocate
the tuple on the stack and pass it to the multiple-return-function,
which would then fill in the tuple.
dave
From: Mitchell Wand <wa...@ccs.neu.edu>
Newsgroups: comp.lang.lisp,comp.lang.ml
Subject: Re: Static Typing
Organization: Northeastern University, College of Computer Science
Distribution: world
Path: not-for-mail
References: <64ddl4$ois$2...@trumpet.uni-mannheim.de>
<64ptde$ci6$1...@darla.visi.com>
<64t0bd$o2s$1...@goldenapple.srv.cs.cmu.edu>
<64v91f$jhv$1...@goldenapple.srv.cs.cmu.edu>
<651rvt$i7a$1...@goldenapple.srv.cs.cmu.edu>
Reply-To: Mitchell Wand <wa...@ccs.neu.edu>
Approved: comp-l...@cs.cmu.edu
Ken Tilton <ti...@bway.net> writes:
<pardon my poor C>
--Mitch
thanks much,
John
- Xavier Leroy
Marco Antoniotti <mar...@infiniti.path.berkeley.edu> writes:
Ken Tilton <ti...@bway.net> writes:
* David Hanley
Fergus Henderson
Fergus Henderson
Emergent Technologies
> [ a moderately lengthy discussion of how different programming styles
> handle cases where a function cannot return a "normal" result;
> claiming that ML programmers would usually use exceptions for this
> purpose ]
No one seems to have mentioned continuation passing style.
From: David Hanley <da...@netright.com.delete.me.silly>
Newsgroups: comp.lang.lisp,comp.lang.ml
Subject: Re: Static Typing
Organization: netright Technologies
Distribution: world
Path: usenet
References: <64ddl4$ois$2...@trumpet.uni-mannheim.de>
<64ptde$ci6$1...@darla.visi.com>
<64t0bd$o2s$1...@goldenapple.srv.cs.cmu.edu>
<64v91f$jhv$1...@goldenapple.srv.cs.cmu.edu>
<651rvt$i7a$1...@goldenapple.srv.cs.cmu.edu>
<6527fg$mmo$1...@goldenapple.srv.cs.cmu.edu> <652c56$od6$1...@goldenapple.srv.cs.cmu.edu>
Reply-To: da...@netright.com.delete.me.silly
Approved: comp-l...@cs.cmu.edu
Marco Antoniotti wrote:
> David Hanley <da...@netright.com.delete.me.silly> writes:
>
> >
> >
> >
> > Ken Tilton wrote:
> >
> ...
> >
> > I don't see how this is due to static typing. How exactly are you
> > going to do this in lisp without exceptions, multiple return values,
> > or multiple return types? ML has multiple return value as well:
> >
> > (value,flag)=search(table,key);
> >
> > Will initlaize both values in ML.
>
> Technically (and AFAIK) ML does not have multiple values in the sense
> of Common Lisp.
In the purest sense, yes, it return a single value, which is a tuple.As a
practical programming issue, it doesn't make much difference.
> The CL MVs are crafted in such a way to enable compilers and
> interpreters to allocate the values on the stack. I don't think (if
> memory does not fail me) that ML has constructs for doing exactly the
> same. (Even if the idiom you posted achieves pretty much the same
> effect).
I beleive this is unspecified. I could certianly concieve of an MLcompiler
using the stack for multiple return values. In fact, because
the types are typically known, the calling function could allocate
the tuple on the stack and pass it to the multiple-return-function,
which would then fill in the tuple.
dave
From: Mitchell Wand <wa...@ccs.neu.edu>
Newsgroups: comp.lang.lisp,comp.lang.ml
Subject: Re: Static Typing
Organization: Northeastern University, College of Computer Science
Distribution: world
Path: not-for-mail
References: <64ddl4$ois$2...@trumpet.uni-mannheim.de>
<64ptde$ci6$1...@darla.visi.com>
<64t0bd$o2s$1...@goldenapple.srv.cs.cmu.edu>
<64v91f$jhv$1...@goldenapple.srv.cs.cmu.edu>
<651rvt$i7a$1...@goldenapple.srv.cs.cmu.edu>
Reply-To: Mitchell Wand <wa...@ccs.neu.edu>
Approved: comp-l...@cs.cmu.edu
Ken Tilton <ti...@bway.net> writes:
> As several mail respondents noted, I wa sunaware of the 'option' option.
> :)
>
> Still sounds like unnecessary work just to say "nothing found"; now I am
> unwrapping an option instead of trapping an exception. Strong-typing
> (with all its advantages) is still contorting my code.
No, strong typing is just forcing you to do what you should always do-- namely
<pardon my poor C>
--Mitch
thanks much,
John
- Xavier Leroy
Newsgroups: comp.lang.lisp,comp.lang.ml
Subject: Re: Static Typing
Organization: Comp Sci, University of Melbourne
Distribution: world
Path: mundook.cs.mu.OZ.AU!fjh
References: <64ddl4$ois$2...@trumpet.uni-mannheim.de> <64ptde$ci6$1...@darla.visi.com> <64t0bd$o2s$1...@goldenapple.srv.cs.cmu.edu> <64v91f$jhv$1...@goldenapple.srv.cs.cmu.edu> <651rvt$i7a$1...@goldenapple.srv.cs.cmu.edu> <6527fg$mmo$1...@goldenapple.srv.cs.cmu.edu> <652c56$od6$1...@goldenapple.srv.cs.cmu.edu>
Reply-To: f...@mundook.cs.mu.OZ.AU (Fergus Henderson)
Approved: comp-l...@cs.cmu.edu
Marco Antoniotti <mar...@infiniti.path.berkeley.edu> writes:
>David Hanley <da...@netright.com.delete.me.silly> writes:
>
>> ML has multiple return value as well:
>>
>> (value,flag)=search(table,key);
>>
>> Will initlaize both values in ML.
>
>Technically (and AFAIK) ML does not have multiple values in the sense
>of Common Lisp.
In which technical sense do you mean?
>The CL MVs are crafted in such a way to enable compilers and
>interpreters to allocate the values on the stack. I don't think (if
>memory does not fail me) that ML has constructs for doing exactly the
>same.
It is certainly possible for ML compilers to allocate multiple return
values on the stack, or even better to return them in registers.
(Whether or not existing ML implementations do so is a different question.
But if you're worried about efficiency, I suspect that if you look at the
big picture, then a statically typed language like ML is likely to be more
efficient than a dynamically typed language like Lisp.)
--
Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger f...@128.250.37.3 | -- the last words of T. S. Garp.
From: f...@mundook.cs.mu.OZ.AU (Fergus Henderson)
Newsgroups: comp.lang.lisp,comp.lang.ml
Subject: Re: Static Typing
Organization: Comp Sci, University of Melbourne
Distribution: world
Path: mundook.cs.mu.OZ.AU!fjh
References: <64ddl4$ois$2...@trumpet.uni-mannheim.de> <64ptde$ci6$1...@darla.visi.com> <64t0bd$o2s$1...@goldenapple.srv.cs.cmu.edu> <64v91f$jhv$1...@goldenapple.srv.cs.cmu.edu> <651rvt$i7a$1...@goldenapple.srv.cs.cmu.edu>
Reply-To: f...@mundook.cs.mu.OZ.AU (Fergus Henderson)
Approved: comp-l...@cs.cmu.edu
Ken Tilton <ti...@bway.net> writes:
Brian Rogoff
On 21 Nov 1997, Emergent Technologies wrote:
>
> > [ a moderately lengthy discussion of how different programming styles
> > handle cases where a function cannot return a "normal" result;
> > claiming that ML programmers would usually use exceptions for this
> > purpose ]
>
> No one seems to have mentioned continuation passing style.
Also, Icon's failure semantics and goal directed evaluation deserve
mention here, as this kind of code seems to be exactly the motivation for
that langauge's peculiar control flow constructs.
-- Brian
From: matt...@wiener.cs.uga.edu (Graham Matthews)
Newsgroups: comp.lang.ml
Subject: Re: static typing considered harmful
Organization: The University of Georgia
Distribution: world
Path: wiener!matthews
References: <64ddl4$ois$2...@trumpet.uni-mannheim.de> <654hma$j4q$1...@goldenapple.srv.cs.cmu.edu>
Reply-To: matt...@wiener.cs.uga.edu (Graham Matthews)
Approved: comp-l...@cs.cmu.edu
"Bruce J. McAdam" <b...@dcs.ed.ac.uk> writes:
: > This morning, Stefan Kahrs gave a talk, `When Types Get in the Way', to
: > the ML-Club here in Edinburgh. This was largely a collection of
: > examples showing situations when the type system becomes a nuisance in
: > some way or another.
Xavier Leroy (Xavier...@see.my.sig.for.address) wrote:
: I had a look at the slides, and the examples show situations where the
: *ML* type system goes in the way, but richer type systems
: (e.g. with some amount of polymorphic recursion) would work fine.
: So, it seems to me that the conclusions of this talk are more along
: the lines of "we need better type systems" rather than "let's get rid
: of static typing altogether".
On this topic: I was wondering if any of the major FP groups (NJ-SML,
Caml, the Haskell groups, the Clean group, etc) have any kind of
documentation describing where the type system of their language is
going, and when it is planned to get there? For example I hear rumours
of adding existential types to Caml, but is that going to happen, and
if so when? Likewise the Glasgow Haskell people appear to have got a
decent grant to extend Haskell's type system, but I don't know details
or deadlines. Why I am asking this question? Well apart from intellectual
curiosity, I am also wanting to review some functional languages as
implementation languages for a soon to start project -- hence I want
to know where these languages are going.
graham
From: Victor Winter <vlw...@sandia.gov>
Newsgroups: comp.lang.ml
Subject: fonts
Organization: Sandia National Laboratories
Distribution: world
Path: not-for-mail
Reply-To: Victor Winter <vlw...@sandia.gov>
Approved: comp-l...@cs.cmu.edu
I want to print "hello world" to the screen and have the
text appear in blue (instead of black). How can I do this?
cheers,
Victor
--
---------------------------------------------------------------------
Victor L. Winter, Ph.D. Voice: (505) 284-2696
FAX: (505) 844-9478
High Integrity Software Systems Engineering
PO Box 5800, Department 2615,
Sandia National Laboratories,
Albuquerque, NM 87185-0535
---------------------------------------------------------------------
From: Emergent Technologies <emer...@cape.com>
Newsgroups: comp.lang.lisp,comp.lang.ml
Subject: Re: Static Typing
Organization: A poorly-installed InterNetNews site
Distribution: world
Path: not-for-mail
References: <64ddl4$ois$2...@trumpet.uni-mannheim.de>
<64ptde$ci6$1...@darla.visi.com> <64t0bd$o2s$1...@goldenapple.srv.cs.cmu.edu>
<64v91f$jhv$1...@goldenapple.srv.cs.cmu.edu>
<651rvt$i7a$1...@goldenapple.srv.cs.cmu.edu>
Reply-To: Emergent Technologies <emer...@cape.com>
Approved: comp-l...@cs.cmu.edu
Martin Rodgers
Georg Bauer wheezed these wise words:
> And a last thought: when you have to build a bunch of utilities, you are
> maybe better off writing them to a Lisp shell. Just put one of the many
> algebraic syntaxes on top of the Lisp shell and people won't even notice
> the difference. Except that the system will be much more powerfull.
I think that this is a cultural issue, rather than a language issue.
Lisp isn't the only language to use a listener, nor is it the only one
to be viewed with suspicion by the C bigots. Coincidence? I wonder.
A listener gives you a loosely structured interface, which is ideal
for programmers and power users. Perhaps this is why it's not so
popular with some people? Could it be that most users prefer a tightly
structured interface? Such an interface may be simpler and easier to
learn for many people. If these are the people who use the software,
and/or who pay for it, then this is what they'll get.
In an ideal world, we'd _all_ be power users. Alas, the world is full
of people with different desires. This complicates matters. There's no
"one size fits all" solution. Fortunately, the world is full of
solutions. ;)
My favourite solutions give me the choice of using a listener when I
want one, and not using one when I don't. This is where I disagree
with many C programmers. I could probably find a C system with a
listener, but most C people confuse this with a batch language.
Their alternative is a tightly structured system called an IDE, which
is like wearing a straight jacket. Even some C programmers find them
limited and frustrating. Some suggest that "plug-ins" can help. This
is a step toward a more loosely structured system.
If I sometimes ask for a more tightly structured Lisp system, it's coz
I often write code for tightly structured systems. It seems to me that
this should be possible for Lisp, even if not everyone can understand
why it will be desirable for some of us. As I said above, the world is
full of solutions...and it's also full of users.
Any flames I get for posting this may be the result of conflicting
culturals. ;) The cultures of users vs programmers...? Hmm.
Fergus Henderson
Brian Rogoff <b...@shell5.ba.best.com> writes:
>On 21 Nov 1997, Emergent Technologies wrote:
>>
>> > [ a moderately lengthy discussion of how different programming styles
>> > handle cases where a function cannot return a "normal" result;
>> > claiming that ML programmers would usually use exceptions for this
>> > purpose ]
>>
>> No one seems to have mentioned continuation passing style.
>
>Also, Icon's failure semantics and goal directed evaluation deserve
>mention here, as this kind of code seems to be exactly the motivation for
>that langauge's peculiar control flow constructs.
Sorry, can't resist the opportunity for a plug ---
if you're looking for a modern, statically typed functional programming
language with support for Icon-style "failure semantics and goal
directed evaluation", try Mercury. See <http://www.cs.mu.oz.au/mercury>.
Rainer Joswig
In article <MPG.ee14bad3...@news.demon.co.uk>,
mcr@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin
Rodgers) wrote:
> A listener gives you a loosely structured interface,
I doubt you have ever seen or used a "Lisp Listener"?
> My favourite solutions give me the choice of using a listener when I
> want one, and not using one when I don't. This is where I disagree
> with many C programmers. I could probably find a C system with a
> listener, but most C people confuse this with a batch language.
???
> Their alternative is a tightly structured system called an IDE, which
> is like wearing a straight jacket. Even some C programmers find them
> limited and frustrating. Some suggest that "plug-ins" can help. This
> is a step toward a more loosely structured system.
???
> If I sometimes ask for a more tightly structured Lisp system, it's coz
> I often write code for tightly structured systems. It seems to me that
> this should be possible for Lisp, even if not everyone can understand
> why it will be desirable for some of us. As I said above, the world is
> full of solutions...and it's also full of users.
???
I'm not sure I could understand your posting fully. ;-)
Martin Rodgers
Rainer Joswig wheezed these wise words:
> > A listener gives you a loosely structured interface,
>
> I doubt you have ever seen or used a "Lisp Listener"?
That's a cheap shot, Rainer. Real cheap.
I've seen a fair number of Lisp listeners, and listeners for other
languages, too. I've even written a few.
> > My favourite solutions give me the choice of using a listener when I
> > want one, and not using one when I don't. This is where I disagree
> > with many C programmers. I could probably find a C system with a
> > listener, but most C people confuse this with a batch language.
>
> ???
Even the compiler has an interface, and some compilers give a choice
of interfaces. In Lisp, for example, you can often run the compiler
from the Lisp listener.
Sometimes you also have the option of using a command line interface.
In other words, a batch interface.
> I'm not sure I could understand your posting fully. ;-)
Then I'll explain. ;)
Users and programmers can have very different views of computer
software. Users will often not require the same freedom as a
programmer. The programmer may prefer not to give the user the same
degree of freedom.
Of course, this isn't unique to Lisp, but the tradition of a listener
does make it a little more obvious, while some languages have a
tradition of using a batch oriented interface. C, for example.
Recall a few years ago, when a C programmer (not alone) was trying to
convince people in a fair number of newsgroups that Lisp wasn't as
good as C. He posted some C code that allegedly adjusted the contrast
in a bitmap, reading from the standard input, scaling the value, and
then writing it to the standard output. Ignoring the many technical
flaws in this code, it assumes that the user will accept a batch style
interface for a task like this.
The Lisp programmer who responded did so with a simple and very short
point. He wouldn't use a file for the bitmap; he'd use a variable.
The implication is that both programmers were thinking in terms of a
loosely structured system, typing commands at a prompt of some kind.
A listener, perhaps?
However, can you imagine how a typical user might alter the contrast
in an image? Probably by using an like Photoshop. This is a tightly
structured system, with a window for each image (a variable) and an
interface that allows the user to invoke editing commands, like
adjusting the constrast.
Plug-ins make the system extensible (more loosely structured), within
limits set by Adobe. It's not in their interest to make to many of the
internals of an app accessible to programmers, never mind users.
So, sometimes limitations are put there deliberately. They're an
intentional feature of the design, reflecting the desires of the
people who create and use the software. Features of a language
environment may not always be ideal for the delivered application,
even if they do help the programmer write that app.
Is that clearer?
Rainer Joswig
In article <MPG.ee1eb788...@news.demon.co.uk>,
mcr@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin
Rodgers) wrote:
> Rainer Joswig wheezed these wise words:
>
> > > A listener gives you a loosely structured interface,
> >
> > I doubt you have ever seen or used a "Lisp Listener"?
>
> That's a cheap shot,
I was referring to the DW-based "Lisp Listener" (hence
the double quotes) of Genera.
> Is that clearer?
I'm still not very sure what you are talking about and why.
Richard A. O'Keefe
mcr@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