From: Harley Davis
Subject: Re: Lisp is alive, was "Re: Common LISP: The Next Generation"
Date:
Message-ID: <wk91aajucz.fsf@laura.ilog.com>
············@wildcard.demon.co.uk (Cyber Surfer) writes:
> Anyway, thanks. It doesn't change the point I was making, which
> is that Java is missing a lot of important Lisp-like features,
> like closures. Odd how some people are _adding_ these things
> to Java, isn't it? Why didn't the designers of Java do that
> themselves? Tsk.
Actually, as far as I know the next version of Java does include
closures. You can define an embedded class anywhere, even in a method
body, and it accesses lexically defined variables like a closure.
-- Harley
-------------------------------------------------------------------
Harley Davis net: ·····@ilog.com
Ilog, Inc. tel: (415) 944-7130
1901 Landings Dr. fax: (415) 390-0946
Mountain View, CA, 94043 url: http://www.ilog.com/
From: Cyber Surfer
Subject: Re: Lisp is alive, was "Re: Common LISP: The Next Generation"
Date:
Message-ID: <842908513snz@wildcard.demon.co.uk>
In article <··············@laura.ilog.com>
·····@laura.ilog.com "Harley Davis" writes:
> Actually, as far as I know the next version of Java does include
> closures. You can define an embedded class anywhere, even in a method
> body, and it accesses lexically defined variables like a closure.
Excellent. Now all we have to do us tell all those Java people
that Lisp has had closures for _years_. After that, we can tell
C++ programmers how Lisp has had macros that wipe the floor with
templates. ;-)
Perhaps someday Java will have decent higher order functions
(err, methods), and it'll look even more like Lisp. Just like
Dylan does, today. The difference is that Java is running on a
great number of desktops _today_, while Dylan is...not here yet.
So, Java gets a head start, Dylan sneaks up on everyone, and
Lisp stays just where it is, where very few people notice it.
Hmm.
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
From: Glenn Ehrlich
Subject: Re: Lisp is alive, was "Re: Common LISP: The Next Generation"
Date:
Message-ID: <323f7b48.3843721@news.primenet.com>
············@wildcard.demon.co.uk (Cyber Surfer) wrote:
>In article <··············@laura.ilog.com>
> ·····@laura.ilog.com "Harley Davis" writes:
>
>> Actually, as far as I know the next version of Java does include
>> closures. You can define an embedded class anywhere, even in a method
>> body, and it accesses lexically defined variables like a closure.
>
>Excellent. Now all we have to do us tell all those Java people
>that Lisp has had closures for _years_. After that, we can tell
>C++ programmers how Lisp has had macros that wipe the floor with
>templates. ;-)
>
>Perhaps someday Java will have decent higher order functions
>(err, methods), and it'll look even more like Lisp. Just like
>Dylan does, today. The difference is that Java is running on a
>great number of desktops _today_, while Dylan is...not here yet.
>So, Java gets a head start, Dylan sneaks up on everyone, and
>Lisp stays just where it is, where very few people notice it.
>
I would like to think that this is the "master plan" for Java, as envisoned by
Gosling and Steele. They both have a lot of Lisp background, you know.
Maybe they thought that the only way to introduce Lisp is to disquise it
underneath the facade of the Web, C++, and visual environments.
If someday Java has closures, hygienic macros, and all of the other Lisp-family
goodies, does it really matter if it doesn't have parenthesis? Isn't the
semantics more important the syntax?
I think one of the really valuable lessons that Dylan has shown is that you can
have a successful infix syntax *and* have all of the Lisp goodies.
I'm hoping that Java does expand in this way.
What would you rather use: Java or Visual Basic?
--
Glenn Ehrlich
······@primenet.com
From: Erik Naggum
Subject: Re: Lisp is alive, was "Re: Common LISP: The Next Generation"
Date:
Message-ID: <3052030527425472@naggum.no>
[Glenn Ehrlich]
| Isn't the semantics more important the syntax?
generally speaking, if this were true, we would not see the syntax-fixation
that the whole industry is built on. syntax _distinguishes_ programming
languages from each other; the semantics is only a question of how much of
the syntax you need to implement it. e.g., if CFRONT can produce C code
from C++, so can a human. syntax can help automate the expression of the
semantics in very important ways, or serve to frustrate the same process.
however, certain operations are possible (that is, sufficiently easy) on
certain syntaxes, which leads me to the more specific interpretation.
one part of the reason why I like Lisp is that I and the compiler can use
the same functions to read and write the source code, not only in macros,
but in codewalkers and automated editing tasks. `read'ing Java or any of
the C-family languages is dreadfully painful. writing out what you have
read in is somewhat easier, but not much.
| I think one of the really valuable lessons that Dylan has shown is that
| you can have a successful infix syntax *and* have all of the Lisp
| goodies.
_all_ of the Lisp goodies? except macros, except `read' on source code,
except `pprint', except ...
#\Erik
--
those who do not know Lisp are doomed to reimplement it
From: Cyber Surfer
Subject: Re: Lisp is alive, was "Re: Common LISP: The Next Generation"
Date:
Message-ID: <843073365snz@wildcard.demon.co.uk>
In article <················@naggum.no> ····@naggum.no "Erik Naggum" writes:
> one part of the reason why I like Lisp is that I and the compiler can use
> the same functions to read and write the source code, not only in macros,
> but in codewalkers and automated editing tasks. `read'ing Java or any of
> the C-family languages is dreadfully painful. writing out what you have
> read in is somewhat easier, but not much.
I also like this feature of Lisp. Sadly, it appears that not many
non-Lisp people appreciate it. I'm not even sure if many non-Lisp
programmers _know_ that Lisp can do this.
Of course parsing languages like C is hard. That's why few people
bother doing it. How many programmers miss being able to write code
can parse the code they write? I'd bet that there are very few,
considering how many programmers have yet to discover Lisp.
It's a viscious circle. How can they appreciate Lisp until they
use it, and why should they use it unless they can appreciate it?
There may be free Lisps for most (if not all) platforms, but you
know how hard some programmers will resist new languages. They'll
need a good reason to install and play with a Lisp.
We're the enlightened ones. I think we should consider how Lisp
looks to the unenlightened, but I've said that already. ;)
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
From: Erik Naggum
Subject: Re: Lisp is alive, was "Re: Common LISP: The Next Generation"
Date:
Message-ID: <3052137838003931@naggum.no>
[Cyber Surfer]
| There may be free Lisps for most (if not all) platforms, but you
| know how hard some programmers will resist new languages.
some, perhaps, but the rush to C++ and Java showed me that programmers will
drop their "favorite" language in the blink of an eye and embrace something
new and "hot".
however, I think the problem is more likely that text book authors are
doing Lisp an enormous disfavor by mentioning it at all. recently, I had a
look at David Harel : Algorithmics : The Spirit of Computing, from 1992,
and its treatment of Lisp might as well have been written in 1962.
and then there's the entries in Encyclop�dia Britannica, which I have
mentioned here previously:
LISP (List Processor) is a language that is powerful in manipulating
lists of data or symbols rather than processing numerical data. In
this sense, LISP is unique. It requires large memory space and, since
it is usually processed by an interpreter, is slow in executing
programs. LISP was developed in the late 1950s and early 1960s by a
group headed by John McCarthy, then a professor at the Massachusetts
Institute of Technology. At that time, LISP was radically different
from other languages, such as FORTRAN and ALGOL. Several versions have
been developed from the LISP 1.5 introduced by McCarthy; Common LISP,
released in 1984, is becoming the de facto standard of LISP.
Other languages are functional, in the sense that programming is done
by calling (i.e., invoking) functions or procedures, which are sections
of code executed within a program. The best-known language of this
type is LISP (from List Processing), in which all computation is
expressed as an application of a function to one or more "objects."
Since LISP objects may be other functions as well as individual data
items (variables, in mathematical terminology) or data structures, a
programmer can create functions at the appropriate level of abstraction
to solve the problem at hand. This feature has made LISP a popular
language for artificial intelligence applications, although it has been
somewhat superseded by logic programming languages such as Prolog (from
Programming in Logic).
LISP (List Processing) can be used to manipulate symbols and lists
rather than numeric data; it is often used in artificial-intelligence
applications.
| They'll need a good reason to install and play with a Lisp.
that good reason is called "curiosity". a programmer who does not possess
curiosity should not be allowed to write code for others. and if we cannot
trust the curiosity of programmers, nothing will ever happen. however, the
curious programmer should be able to find some _correct_ and _updated_
information about Lisp where he might be likely to look.
#\Erik
--
those who do not know Lisp are doomed to reimplement it
From: Cyber Surfer
Subject: Re: Lisp is alive, was "Re: Common LISP: The Next Generation"
Date:
Message-ID: <843229702snz@wildcard.demon.co.uk>
In article <················@naggum.no> ····@naggum.no "Erik Naggum" writes:
> | There may be free Lisps for most (if not all) platforms, but you
> | know how hard some programmers will resist new languages.
>
> some, perhaps, but the rush to C++ and Java showed me that programmers will
> drop their "favorite" language in the blink of an eye and embrace something
> new and "hot".
If there's good enough support for it, yes they will. A lot of
people I know who are using Java are doing it with "workbenches"
like Cafe. If there was a Lisp that looked like this, most Lisp
people would hate it, but a lot of Lisp-haters might prefer it.
We tend to prefer what we're used to, or so I suspect.
All the C++ compilers I've used or read about used similar
enviroments, if that's the right word for them. A few were
terrible, but no worse - exactly the same, in fact - as what
that vendor had previously offered for C.
The keyword, I feel, is compromise. When you try a new language,
you have to compromise by giving up a few habits you've used
with other languages. Lisp systems tend to demand that we do
a lot of things differently from C/C++. We see that as a feature,
but many will see it as a bug. Smalltalk has the same problem.
It's _different_ from C++. Very different. That means we have
to introduce the ideas gently - which Java appears to be doing.
> however, I think the problem is more likely that text book authors are
> doing Lisp an enormous disfavor by mentioning it at all. recently, I had a
> look at David Harel : Algorithmics : The Spirit of Computing, from 1992,
> and its treatment of Lisp might as well have been written in 1962.
Yes, I'd expect Lisp in 1962 to be totally irrelevant to today's
Lisps. There may possibly be some historical interest, but apart
from that, very few of us should need to know about such relics.
Just like Fortran 66! Today, Fortran programmers can (or should)
be using F90. Modern Lisp programmers might easily be using CL
or Scheme. Not the Lisps that came before these modern dialects.
Even CL and Scheme reflect more than their age. Most non-Lispers
won't understand the point of the syntax, and without that, the
enture language looks silly. I know, semantics should come before
syntax, but that's _not_ how most people look at Lisp. I know,
coz I remember being in that position myself, in the early 80s.
The difference is that I gave in to my curiousity. Too many others
will, as I've said before, just argue over the differences between
C and Pascal. <sigh> _What_ differences? Compared to Lisp, these
two languages are practically the same!
What hope does Lisp have, with its archaic syntax? I know it's
useful, but is that enough to win even one percent of the hordes
rushing to emrace Java? I think not. It's a syntax that _feels_
like something from 1962. The only reason I love it is that I've
never felt comfortable with infix. Ok, I'm odd.
> and then there's the entries in Encyclopdia Britannica, which I have
> mentioned here previously:
>
> LISP (List Processor) is a language that is powerful in manipulating
> lists of data or symbols rather than processing numerical data. In
> this sense, LISP is unique. It requires large memory space and, since
> it is usually processed by an interpreter, is slow in executing
> programs. LISP was developed in the late 1950s and early 1960s by a
> group headed by John McCarthy, then a professor at the Massachusetts
> Institute of Technology. At that time, LISP was radically different
> from other languages, such as FORTRAN and ALGOL. Several versions have
> been developed from the LISP 1.5 introduced by McCarthy; Common LISP,
> released in 1984, is becoming the de facto standard of LISP.
>
> Other languages are functional, in the sense that programming is done
> by calling (i.e., invoking) functions or procedures, which are sections
> of code executed within a program. The best-known language of this
> type is LISP (from List Processing), in which all computation is
> expressed as an application of a function to one or more "objects."
> Since LISP objects may be other functions as well as individual data
> items (variables, in mathematical terminology) or data structures, a
> programmer can create functions at the appropriate level of abstraction
> to solve the problem at hand. This feature has made LISP a popular
> language for artificial intelligence applications, although it has been
> somewhat superseded by logic programming languages such as Prolog (from
> Programming in Logic).
>
> LISP (List Processing) can be used to manipulate symbols and lists
> rather than numeric data; it is often used in artificial-intelligence
> applications.
Yes, even Prolog has a more sophisticated parser than Lisp. ;-)
> | They'll need a good reason to install and play with a Lisp.
>
> that good reason is called "curiosity". a programmer who does not possess
> curiosity should not be allowed to write code for others. and if we cannot
> trust the curiosity of programmers, nothing will ever happen. however, the
> curious programmer should be able to find some _correct_ and _updated_
> information about Lisp where he might be likely to look.
I agree that curosity is vital, but there's a very short
supply of it. Plus, advertising and marketting people are
working to make damn sure that any curious programmers
discover C++, Java, or whatever the vast piles of money
thrown their way by MS etc.
Where's the advertsing to promote Lisp? Which mainstream
programming mags can it be found in? I'd like to know so
I can buy those mags. It's an informatation war. I like
Richard Dawkins idea of memes. The Lisp memes are currently
heavily outnumbered by the C++ and Java memes being spread
by all those adverts, junk mail, etc. I don't remember
receiving _any_ junk mail for Lisp products that I didn't
explicitly ask for, and yet piles of paper covered in C++
and Java memes go into my bin almost daily.
BTW, the uk.comp.lang.lisp newsgroup may soon be removed,
due to a lack of posts for the last 3 months. <sigh>
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
From: Erik Naggum
Subject: Re: Lisp is alive, was "Re: Common LISP: The Next Generation"
Date:
Message-ID: <3052297391247606@naggum.no>
[Cyber Surfer]
| I agree that curiosity is vital, but there's a very short supply of it.
if you actually think this is true, it would explain why you have so many
problems as seem to have. if there is _anything_ that can be used to sort
a programmer from your random joe, it is a monumentally higher level of
curiosity. people who aren't curious _enough_ don't pursue programming.
| BTW, the uk.comp.lang.lisp newsgroup may soon be removed, due to a lack
| of posts for the last 3 months. <sigh>
I removed it from the Newsgroups line.
"Cyber Surfer" (what a moronic net name!), whatever your real persona is
like, please consider whether the only relevant issue in this world is
popularity. please consider whether anything of importance is shared by
the masses. start with your own personal convictions, ideas, likes and
dislikes. would you _want_ them to be in the middle of mainstream? take
political ideas -- would you want the political landscape to be _flat_?
take practical politics -- would you want the average joe to decide your
country's military strategy?
and please consider quitting that incessant whining of yours. some of us
write ten times as many lines of Common Lisp code for every one of your
lines of posted whining. if you don't hear about it, it may well be
because any serious Lisper is not interested in suffering your endless list
of "buts" and your incredible negativism. maybe Lisp just isn't for you,
but by now it is bordering on the bloody obvious that it is not Lisp's
fault or even related to Lisp.
#\Erik
--
those who do not know Lisp are doomed to reimplement it
From: Cyber Surfer
Subject: Re: Lisp is alive, was "Re: Common LISP: The Next Generation"
Date:
Message-ID: <843335875snz@wildcard.demon.co.uk>
In article <················@naggum.no> ····@naggum.no "Erik Naggum" writes:
> if you actually think this is true, it would explain why you have so many
> problems as seem to have. if there is _anything_ that can be used to sort
> a programmer from your random joe, it is a monumentally higher level of
> curiosity. people who aren't curious _enough_ don't pursue programming.
Perhaps we could say that there're relative degrees of curiousity?
I'm not sure. I'm told that there are "9 to 5" programmers, and they
sound very much like programmers without much, if any, curiousity.
For those of us who're definitely not "9 to 5" programmers, it may
simply depend on how much pressure a programmer is under. How far
should a programmer look? As I've said, there's massive amounts of
advertising offering tools that use C++, and a very significant part
of the software industry saying that software should be written in
C/C++. Even when this is not being said, it's being implied by the
lack of coverage of alternative languages in the mainstream mags.
I can remember a time when mainstream magazines would write about
Lisp and even more esoteric languages. Today, it's more like to be
Perl and Java. If you read Lisp Pointers or Forth Dimensions, you'll
find plenty of alternate memes, but I've never seen these publications
on newstands.
I'd love this to change. That's why my favourite developers mag
(for Windows developers, anyway) is Windows Tech Journal. This is
the mag which MS withdrew their advertising from, just coz the
editor has a free mind, and doesn't wish to play by the biased
rules that MS prefer. The editor himself reviewed ACL for Windows,
favourably, so this is not somebody who thinks that Lisp sucks.
> | BTW, the uk.comp.lang.lisp newsgroup may soon be removed, due to a lack
> | of posts for the last 3 months. <sigh>
>
> I removed it from the Newsgroups line.
RIP uk.comp.lang.lisp.
> "Cyber Surfer" (what a moronic net name!), whatever your real persona is
> like, please consider whether the only relevant issue in this world is
> popularity. please consider whether anything of importance is shared by
> the masses. start with your own personal convictions, ideas, likes and
> dislikes. would you _want_ them to be in the middle of mainstream? take
> political ideas -- would you want the political landscape to be _flat_?
> take practical politics -- would you want the average joe to decide your
> country's military strategy?
Personal abuse?
See <URL:http://www.enrapture.com/cybes/faq.html> for an explanation
of the name. You've just missed the irony. ;-)
You'll also find my name...
> and please consider quitting that incessant whining of yours. some of us
> write ten times as many lines of Common Lisp code for every one of your
> lines of posted whining. if you don't hear about it, it may well be
> because any serious Lisper is not interested in suffering your endless list
> of "buts" and your incredible negativism. maybe Lisp just isn't for you,
> but by now it is bordering on the bloody obvious that it is not Lisp's
> fault or even related to Lisp.
The reason I don't write much Lisp code is because I don't have
the time - I'm too busy writing bloody C++ code. I'm not alone,
either.
You're lucky that you can afford to use Lisp, If you think that
it's just a matter of choice for the rest of us, then you're either
blind or a stubborn elitist. The hordes of C++ programmers use this
monstrosity because _they can_. You use Lisp because _you can_.
I'd like to join you, but I'm damn lucky to have the job I'm in
today, so it's just not an option. Yet.
You can call this whining if you like, but can you show that
there isn't a huge demand for C++ programmers? Most people I
know would think you're daft if you're using Lisp. I'd say
they think this coz they're paid to code in C/C++. Memes.
Perhaps you think what you do because you're paid to program
in Lisp, but I don't know that. I _agree_ with you, but it
makes no difference to the people with C++ memes in their heads.
Lisp _is_ for me, but only when I'm programming in my own
time. I'd like to change that. Do you have anything contructive
to offer? Does anybody? I'm serious, You've done nothing but
convince me that my fears were not groundless.
Thanks. This hurts, but it's important to know these things.
Now I have even less hope than before, but more determination
to write my own Lisp compiler. It's a way of saying fuck you
all - esp MS and all the bastards who insist we use C++. I've
hated these people for years, for killing my dreams.
Of course, I can write and use my own compilers, and I've been
doing it for some time now, but I want to share these things.
I want to share the _memes_. Other people can write far better
compilers than I can - but they won't, unless have the Lisp
memes in their heads. That's my vision - not to make more money,
but to make programming more fun and satisfying. That'll make
_somebody_ more money, but I don't care who it is, so long as
it happens. I don't believe it'll happen while a few elists insist
that there's no problem, that the memes are only for the select
few who can appreciate them.
I believe that a great deal more of us could appreciate them,
if we're given the chance. _If_ we're given the chance.
Hopefully, this is more of a rant than a whine. I can easily
rant about the virtues of Lisp, if anybody will listen. ;-)
At least you have some idea what I'm talking about.
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
Check the viewpoint of the Garnet developer's in the Garnet faq. Their
consensus was that the C++ code (at least with the compilers in use on the
platforms they tested on) was simply faster for a given programming task
than the lisp code. (Incidentally, there is a patch on the clisp ftp site
for improving performance with garnet). You only have to program it a few
times (development plus maintenance). Your customers have to use it a
million times.
I like lisp for the lack of syntactic idiosyncrasies. It may look strange
to the newbie on first sight, but one can learn it faster than a C-like
language, because there are less syntactic details and context-dependent
semantic gotchas to remember. A few simple constructs, and you can build
anything with it (though I wouldn't use it for systems code that runs
directly on the metal).
But I don't expect it to outperform C/C++ or Ada or Fortran or Prolog; I
just expect it to be working sooner with less of my time spent to get it
debugged. Lisp makes it easy to manage scope.
But if I have a commercial product for ram- and cpu-limited hardware, my
customers don't care how difficult or expensive the development process is
for me. They only look at the price tag and the job they want done. If my
competitor writes a program in C/C++ that does the same thing correctly
three times faster for the same price, that is what they will buy.
Lisp's commercial strength seems to be in complex code that would take a
prohibitively long time to develop and debug in procedural languages,
running on hardware well beyond the average desktop (with doubtless some
exceptions). As the average desktop gets faster, lisp may find a
resurgence of popularity in commercial programming environments. Fast
enough for the customer is fast enough, and programming labor costs should
be lower than for a C++ shop.
But that only applies to desktops as they are now. If you look at machines
like "network computers", the perspective is going to be similar to that
for embedded systems programming. Ram/rom is part of unit cost, and lisp
in most implementations makes more luxurious use of than other languages
that can get the job done.
Regards, Clayton Weaver ······@eskimo.com (Seattle)
From: Cyber Surfer
Subject: Re: Lisp is alive, was "Re: Common LISP: The Next Generation"
Date:
Message-ID: <843485429snz@wildcard.demon.co.uk>
In article <·······································@eskimo.com>
······@eskimo.com "Clayton Weaver" writes:
> Check the viewpoint of the Garnet developer's in the Garnet faq. Their
> consensus was that the C++ code (at least with the compilers in use on the
> platforms they tested on) was simply faster for a given programming task
> than the lisp code. (Incidentally, there is a patch on the clisp ftp site
> for improving performance with garnet). You only have to program it a few
> times (development plus maintenance). Your customers have to use it a
> million times.
I've never looked closely enough at Garnet to discover a performance
difference between C++ and Lisp. In fact, performance differences
between these two languages don't even remotely interest me. If I could
use Lisp as an alternative to C++, then I might.
As for Garnet, I suspect I might easily prefer it to MFC. ;-)
> I like lisp for the lack of syntactic idiosyncrasies. It may look strange
> to the newbie on first sight, but one can learn it faster than a C-like
> language, because there are less syntactic details and context-dependent
> semantic gotchas to remember. A few simple constructs, and you can build
> anything with it (though I wouldn't use it for systems code that runs
> directly on the metal).
There's no need to sell me the Lisp meme - I've had it for years.
Even before I discovered Lisp, I was looking for something very
much like it. I just didn't know that Lisp was it.
> But I don't expect it to outperform C/C++ or Ada or Fortran or Prolog; I
> just expect it to be working sooner with less of my time spent to get it
> debugged. Lisp makes it easy to manage scope.
Yep, I know. I love it. That's why I'm so frustrated.
BTW, is there some CL code for doing FTP for ACL for Windows?
I'm don't know if ANSI CL has any support for sockets, but that
might help make some CL FTP code portable enough that I can use
use it without having to understand it (and edit it) first.
Meanwhile, Perl does exactly what I want, so that's what I'm
using today. It makes me sick, but it's there and it works.
Today. If I had the ActiveX SDK, I might be using C/C++ instead.
Perhaps I'm lucky that I don't, but I already have some C code
to do most of what I want, except for the FTP bit. That's why
I'm rewritting it in Perl instead of C or even Lisp.
Obviously, I should just spend the $2500. That's a lot of money
for just one utility, but I'm sure there'll be others. It'd be
great fun to say, "Yeah, you can do it like that, but when _I_
upload loads of files, I can do it using this neat util I wrote
in Lisp. Why Lisp? Coz it was dead easy." That doesn't explain
the high price, but I don't have to mention that, do I?
I just wonder, tho. If a colleague then wants to use my ftp
utility, does that count as a commercial application? This
is only an issue for some development systems, but I wonder
if, let's say, I'm doing this in a few years time, using a
system like Gwydion that makes a distinction between commercial
use and non-commercial use (like a personal utility?), would
that count? It wouldn't be for a client, exactly. Not unless
the file upload was done for a client, anyway.
That may be why I'd have to pay for ACL myself. Unless the
Lite version includes sockets, I can't write the util. However,
I can do it in Java or Perl _today_, for "free".
What would you recommend that I do? I know I can do it in
Perl - I'm doing it right now. I bet I could do it in Java,
eventually. Someday I'll be able to do it in Lisp, like when
I get comfortable enough with sockets to translate the Perl
code I've got into CL. Right now, that would demand too much
of my time, which is supposed to be devoted to C coding at
the moment.
This is not an unusual choice. Programmers have to make
choices like it everyday. It's not always easy. While I
might be able to take a risk, in my own time, I can't do
it with somebody else's time. That's not what they want.
We all have to use our judgement in these matters.
> But if I have a commercial product for ram- and cpu-limited hardware, my
> customers don't care how difficult or expensive the development process is
> for me. They only look at the price tag and the job they want done. If my
> competitor writes a program in C/C++ that does the same thing correctly
> three times faster for the same price, that is what they will buy.
Sadly, this is true. Sometimes there's so much misinformation
floating about that a client might be forgiven for feeling that
C++ is "safe", so they should buy that produce and not the one
written using some "unknown" tool(s). Lisp isn't "unknown",
but it's not as well known as C++. Also, some of the other tools
needed for an app might not even be designed with Lisp in mind.
This shouldn't be a problem, but it can be. MS are very good at
arranging that kind of thing. Hence the Anti Trust issue.
Perhaps the answer is to not use MS products, but if that's
what the client wants, we dares to argue with them? Only those
who can choose their clients.
> Lisp's commercial strength seems to be in complex code that would take a
> prohibitively long time to develop and debug in procedural languages,
> running on hardware well beyond the average desktop (with doubtless some
> exceptions). As the average desktop gets faster, lisp may find a
> resurgence of popularity in commercial programming environments. Fast
> enough for the customer is fast enough, and programming labor costs should
> be lower than for a C++ shop.
That's the kind of software I'd love to be writting. We're
getting there. If ACL for Windows supported OCX controls,
then I might be using it today, if only for demos. Finding
the right app for Lisp isn't easy when you're doing multimedia,
but I'm looking for it. Perhaps the answer is a totally
different app domain, since I have no direct contact with
our clients (haha, a programmer? talking to clients?), I'm
not sure what they might need.
I would dearly love to do a DirectX demo using ACL for
Windows. The only way I can see it being done today would
be to call DirectX indirectly, via functions in a DLL.
When I get the time, the DirectX SDK, upgrade the OS on
my machine so it can use it, and a couple of other things,
then I may begin to work on it.
> But that only applies to desktops as they are now. If you look at machines
> like "network computers", the perspective is going to be similar to that
> for embedded systems programming. Ram/rom is part of unit cost, and lisp
> in most implementations makes more luxurious use of than other languages
> that can get the job done.
Yep. I recently compared the code size of the final image
produced by my Scheme to C compiler, with the image size
of a very simple C program. The difference was barely one
that you could measure! That's one advantage of using Win32
and VC++ - there's a hell of lot of overhead! I serious
expect to be able to take my toy compiler, when it gets
a little more capable, and its mark/sweep GC, and use it
write multimedia apps that nobody can tell came from a
Lisp compiler. What people should notice is what the app
_does_, not which tools were used to create it. Strangely,
that might be easier to do in a multimedia app...
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
> Check the viewpoint of the Garnet developer's in the Garnet faq. Their
> consensus was that the C++ code (at least with the compilers in use on the
> platforms they tested on) was simply faster for a given programming task
> than the lisp code.
My second implementations of a given system can be faster, too.
This is no surprise to me.
Unless we see a better comparision with more data
I can't say that much about it.
> (Incidentally, there is a patch on the clisp ftp site
> for improving performance with garnet).
CLISP is not what I have in mind when I think of speed.
> You only have to program it a few
> times (development plus maintenance). Your customers have to use it a
> million times.
You use it daily. You may have to maintain it many many years.
Much of the cost of software is maintenance.
> But I don't expect it to outperform C/C++ or Ada or Fortran or Prolog;
Why not? There are enough examples where people showed that
certain Lisp implementations can generate fast code, comparable
to C++ and Fortran.
Lisp is a family of languages with many diverse strengths and weaknesses.
I won't expect the tiny interpreter (design as an extension language)
to have the same performance characteristics than a compiler-based
implementation doing type inference.
Btw., if you have a complaint about the speed of MCL, let
the developers know - write to ········@digitool.com
and describe your problem.
> But if I have a commercial product for ram- and cpu-limited hardware,
These are two constraints: few ram and slow processor. Lisp
already has found uses in this field. As I indicated
in a previous post the programming language for the
HP calculator took a lot of the ideas of Lisp. The Newton
has also a runtime system with Lisp-like semantics (typed data,
functions and closures, objects, GC, symbols, ...). There
are more examples. These were specially designed with the
memory and speed constraints in mind.
> competitor writes a program in C/C++ that does the same thing correctly
> three times faster for the same price, that is what they will buy.
What's a price? The price to develop it? To make it run in a way users
may think the software is correct? To prove correctness?
To change the software to make it run correct? To enhance the software?
To redesign the software? To port the software?
The price to understand the source two years later?
The price to ship updates or new versions?
Which of these price factors do you or your customers calculate?
> Lisp's commercial strength seems to be in complex code that would take a
> prohibitively long time to develop and debug in procedural languages,
> running on hardware well beyond the average desktop (with doubtless some
> exceptions).
I strongly doubt that this is the only strength. Personally
I was able to do useful work in Lisp on 68k machines which
are slow by today's standards. Look at the Lisp machines from
Xerox. Very nice. Tiny by today's standards.
As I already said, Lisp is diverse. We have Lisp for
embedded systems, extension languages, portable implementations,
Lisp-based operating systems, expert-system shells,
MPP-computers, ... Each of these has very different space/speed/...
constraints.
> for embedded systems programming. Ram/rom is part of unit cost, and lisp
> in most implementations
Lisp has already being used for small embedded systems. For an
newer system see the "L" system by ISR.
> makes more luxurious use of than other languages
> that can get the job done.
Java and the Java VM are strongly tied to each other. This is what
it makes a **bad** candidate for a cross platform architecture
supporting more than Java. Sure if you have the whole Java
system in ROM it looks like it is small. Still the Newton OS
can work with even tougher memory constraints (the Newton's
ROM is larger because it already has more functionality in it)
due to its prototype-based object system.
Rainer Joswig
From: Marcus Daniels
Subject: Re: Lisp is alive, was "Re: Common LISP: The Next Generation"
Date:
Message-ID: <rfin2yilhi5.fsf@sayre.sysc.pdx.edu>
>>>>> "CS" == Cyber Surfer <············@wildcard.demon.co.uk> writes:
CS> I'm serious, You've done nothing but convince me that my fears
CS> were not groundless.
They were not groundless. It is hopeless. Bye?!
From: Janice M. Eisen
Subject: Re: Lisp is alive, was "Re: Common LISP: The Next Generation"
Date:
Message-ID: <52b8tu$n62@universe.digex.net>
Has anyone checked out the STELLA language concept, which can be
translated into either Common LISP or C++?
It's part of the LOOM project at ISI (http://www.isi.edu), and it doesn't
seem to be available independently. PowerLOOM, which is planned to be
available in Dec. 96, is written in STELLA, as is much of STELLA itself
(apparently).
"STELLA resembles a simplified version of Lisp, extended to include
strong typing and a modern object system." -- from
http://www.isi.edu/isd/LOOM/Stella/index.html
Apologies if everyone already knows about this.
Ken Meltsner (on his wife's account)
In article <··········@universe.digex.net>,
Janice M. Eisen <···@universe.digex.net> wrote:
>Has anyone checked out the STELLA language concept, which can be
>translated into either Common LISP or C++?
It's hard for me to take seriously any evaluation of Common Lisp's
state that includes the following (directly from their home page):
... However, Common Lisp has several drawbacks: Its
performance is slow (as compared to a C++ program); it does not
interface well to tools and applications in commercial environments
(e.g., to C++ and CORBA); and it fails to incorporate recent object
system trends (e.g., collections, iterators, and parameterized
types). As a result, customer demand and vendor support for Lisp is
declining, creating yet another reason to abandon Lisp.
The "drawbacks" are the usual collection of misrepresentations and
half-facts.
The first "drawback", Common Lisp's speed, which while not down to the
C level of machine efficiency, can certainly be more than adequate for
many applications. All it takes is the right algorithm for the
problem, care in coding, and a modern optimizing compiler, as with any
other language. Look at Fateman's work with arithmetic optimization
for a reality check.
I contend Lisp's biggest problem, discounting parenthetophobia, is
that it is taught poorly. People still think it's about linked lists
and recursive programming, when clearly there's a lot more to modern
Lisps than just cons cells and lambda expressions. The resulting code
uses large lists like arrays (I have actually seen this!), runs slower
than molasses in January, and management winds up blaming the language
rather than the inadequately trained programmer.
The second "drawback", interfacing, is a bit of a chicken-and-egg
problem. Languages that aren't "popular" (read: promoted by mass
marketers like Microsoft, IBM, Borland, et al) don't get included in
the creation of standards like CORBA. Because they aren't included,
they become less "popular".
Meanwhile in the real world, our team is working in C++ and Lisp,
integrated with some pain but running smoothly now.
The third "drawback" mentioned is actually a drawback of C++!! I
believe that collections, iterators, and parameterized types are
merely programming idioms that a generalized macro facility could
handle. Common Lisp doesn't have these "features" because *it doesn't
need them*.
Given this bogus justification for STELLA's existence, I am not really
encouraged to investigate it any deeper.
-- Chuck Fry, Lisp bigot
--
Chuck Fry Work: ······@ptolemy.arc.nasa.gov Play: ······@best.com
I alone am responsible for the contents of this post.
Keep NASA and Caelum Research out of this.
From: Sean Foderaro
Subject: Re: Lisp is alive, was "Re: Common LISP: The Next Generation"
Date:
Message-ID: <JKF.96Sep24111737@tiger.Franz.com>
>> BTW, is there some CL code for doing FTP for ACL for Windows?
I recently wrote an ftp client. I'll send you a copy. I'm working on
an nntp client as well, and plan to continue working on code
for other popular protocols (pop, imap, http, irc).
While these are a challenge to write in other languages (like C or Java)
they are almost too easy to do in Lisp.
- john foderaro
From: Cyber Surfer
Subject: Re: Lisp is alive, was "Re: Common LISP: The Next Generation"
Date:
Message-ID: <843654928snz@wildcard.demon.co.uk>
In article <·················@tiger.Franz.com>
···@Franz.com "Sean Foderaro" writes:
>
> >> BTW, is there some CL code for doing FTP for ACL for Windows?
>
> I recently wrote an ftp client. I'll send you a copy. I'm working on
> an nntp client as well, and plan to continue working on code
> for other popular protocols (pop, imap, http, irc).
> While these are a challenge to write in other languages (like C or Java)
> they are almost too easy to do in Lisp.
Indeed, it took me almost not time at all to create a finger server,
and only a little longer for a very crude http server.
Perhaps someday I'll add a meta-language (either compiling to CL,
or interpreting) for CGI, and a compiler that can create C++ code
for ISAPI DLLs. While I can justify doing this for fun, it might
also one day save me some time and effort.
Thanks for the ftp client. I'll play with it in a few days - right
now, I have some C code to port from Unix to Win32. Eventually, I'll
do some more work on my http server.
Thanks.
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
In article <············@wildcard.demon.co.uk>,
············@wildcard.demon.co.uk wrote:
>Indeed, it took me almost not time at all to create a finger server,
>and only a little longer for a very crude http server.
>
>Perhaps someday I'll add a meta-language (either compiling to CL,
>or interpreting) for CGI, and a compiler that can create C++ code
>for ISAPI DLLs. While I can justify doing this for fun, it might
>also one day save me some time and effort.
Before you put too much effort into this project (unless you're doing it
for your enjoyment), check out the full-featured HTTP server at
http://www.ai.mit.edu/projects/iiip/doc/cl-http/home-page.html
--
Dave Lamkins, http://www.teleport.com/~dlamkins/
CPU Cycles: Use them now, or lose them forever...
From: Cyber Surfer
Subject: Re: Lisp is alive, was "Re: Common LISP: The Next Generation"
Date:
Message-ID: <843722663snz@wildcard.demon.co.uk>
In article <···································@news.teleport.com>
········@teleport.com "David B. Lamkins" writes:
> >Indeed, it took me almost not time at all to create a finger server,
> >and only a little longer for a very crude http server.
> >
> >Perhaps someday I'll add a meta-language (either compiling to CL,
> >or interpreting) for CGI, and a compiler that can create C++ code
> >for ISAPI DLLs. While I can justify doing this for fun, it might
> >also one day save me some time and effort.
>
> Before you put too much effort into this project (unless you're doing it
> for your enjoyment), check out the full-featured HTTP server at
> http://www.ai.mit.edu/projects/iiip/doc/cl-http/home-page.html
I'm aware of it. What I need is something to help me develop and
prototype CGI code for web servers that use ISAPI. While CL-HTTP
may be a fine web server, it's not one that I can use right now.
My goal is not to replace an existing web server with one that uses
Lisp, but to make writting CGI code using C++/ISAPI easier.
Like it or not, some clients don't use Lisp for their web servers.
Thanks.
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
············@wildcard.demon.co.uk (Cyber Surfer) writes:
> My goal is not to replace an existing web server with one that uses Lisp,
> but to make writting CGI code using C++/ISAPI easier.
If what you need is a Lisp that integrates well with C++, and are willing
to accept Scheme as your Lisp, you could consider esh (for Solaris/SunOS)
or DEC's Scheme->C (for Solaris/SunOS, most other UNIX platforms and Windoze).
Both systems are designed for embedding into C/C++ applications (allowing
C/C++ to call Scheme) and make calling C/C++ code from Scheme easy by
automagically generating Scheme wrappers from header files (using "ix" for
esh and "cdecl" for Scheme->C).
Both are available via anonymous ftp. What else do you need?
In article <·················@OASIS007.msc.ie>
········@msc.ie "Russell Ritchie" writes:
> If what you need is a Lisp that integrates well with C++, and are willing
> to accept Scheme as your Lisp, you could consider esh (for Solaris/SunOS)
> or DEC's Scheme->C (for Solaris/SunOS, most other UNIX platforms and Windoze).
I need Win32 support. Not "Windoze".
> Both systems are designed for embedding into C/C++ applications (allowing
> C/C++ to call Scheme) and make calling C/C++ code from Scheme easy by
> automagically generating Scheme wrappers from header files (using "ix" for
> esh and "cdecl" for Scheme->C).
>
> Both are available via anonymous ftp. What else do you need?
Full Win32 support. The C++ tools I have aren't even up to date.
It doens't look like the Windows support in DEC's compiler has
been updated for well over a year, and is Win16, not Win32.
I could in theory add Win32 support. In practice, who knows?
That'll depend on how much work would be required. A DIY
solution isn't available to everyone. If I had the time to
work on such things, then I would. If somebody else did, then
they might have done it already.
Any tool that already has Win32 support will get looked at
before one that doesn't. This is just being practical. There
are quite a few of these tools...
I'm not giving up on the idea of using Lisp, of course. I'm
just not restricting myself to Lisp, or the Lisps currently
available. However, if I ever get the time, I'll see what I
can do with DEC's compiler. You never know, do you?
Thanks.
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
From: William A. Barnett-Lewis
Subject: Re: Lisp is alive, was "Re: Common LISP: The Next Generation"
Date:
Message-ID: <524p6i$4sm@grandcanyon.binc.net>
In article <················@naggum.no>, ····@naggum.no says...
>and please consider quitting that incessant whining of yours. some of us
>write ten times as many lines of Common Lisp code for every one of your
>lines of posted whining. if you don't hear about it, it may well be
>because any serious Lisper is not interested in suffering your endless list
>of "buts" and your incredible negativism. maybe Lisp just isn't for you,
>but by now it is bordering on the bloody obvious that it is not Lisp's
>fault or even related to Lisp.
>
So sorry dude, but your compliants are far more annoying than his. I know I
don't use Lisp or Smalltalk or any other real language for 99% of the code I
put out; unfortunatly I don't have a whole lot of choice in the matter. I keep
bitching for a _real_ windoze implementation. Now, if I had the money and time,
I'd buy a source license to Medley & do a real win32 port of the best
environment I've used. But the closest I'll get to that is my copy of Allen's
"Anatomy of Lisp"...So chill. I'm glad you can use Lisp for your real work.
I've got Visual Basic & Oracle's Developer 2000; yeah, freaking, thrill...so
pardon me if I'm more sensitive to CS's position than yours.
>#\Erik
>--
>those who do not know Lisp are doomed to reimplement it
And those who do, mearly (?) want to?
William Barnett-Lewis
From: Erik Naggum
Subject: Re: Lisp is alive, was "Re: Common LISP: The Next Generation"
Date:
Message-ID: <3052468218485663@naggum.no>
[William A. Barnett-Lewis]
| I'm glad you can use Lisp for your real work. I've got Visual Basic &
| Oracle's Developer 2000; yeah, freaking, thrill...so pardon me if I'm
| more sensitive to CS's position than yours.
(Geez.) I first saw The Little Lisper in 1978 or so, and I found it about
twice as neat and cool as the world now finds "Java". I acquired a new way
of thinking about problems, instead of yearning for the unachievable. In
practical terms, what I came away with was very close to what Paul Graham
writes about his books on Common Lisp: build the language up towards your
problem, and build the solution in that (new) language; I have implemented
numerous tiny, application-specific languages over the years, both to be
able to think better, but also to simplify the often boring and uninspiring
programming tasks. To me, one program's input is just another program's
output, unless I care to feed it by hand, and often I don't, and whether
that program is the compiler or an application program is irrelevant.
If you hate your language of "choice" and love Lisp, write tools in Lisp to
write your programs for you in that language. Nobody ever forced you to do
all that programming as manual labor, anyway, did they? Incidentally, that
was how I _started_ programming in Lisp for real, three years ago, when I
was forced to use C++ (an abomination if there ever is one). The Lisp side
of my work just grew until I could stop caring about _stupid_ issues in C++
-- my C++-code "generator" took care of them, and then I could drop C++.
Over the years since 1978, I have used Lisp systems that were not usable
for delivery, for obvious reasons such as being too expensive memory- or
money-wise. I chose languages that could deliver, but I never lost sight
of the idea that a _program_ is just another form of _data_. Finally, when
I got a real computer, several Lisp systems were available, and some of
them even produce small executables (e.g., Wade Hennessey's WCL). I began
using GNU Emacs for real (i.e., programming GNU Emacs to do what I did
manually), and have added a function or two a day to my C-generator that is
supposed to write C that works on all systems by virtue of being compiled
into C on that system according to the system's configuration parameters.
(This as opposed to writing for all systems at once, which one has to do
with GNU `configure', as smart as that solution is.)
What I see from those who whine about the tools they can use are people who
has been explained all the rules of chess, but who complains that it is a
stupid game because one cannot win in one, big move. Failure to appreciate
that many moves are necessary, indeed that the beauty of the game is the
combinatory effect of the moves, seems to be the underlying cause of a
large number of ills in the computer world, including the need to use only
one tool or language to generate "small executables". And, yes, I think
that's stupid, and no, I don't think I'm a genius -- I was probably just
lucky enough not to be "destroyed" by excessively stupid computers when I
was young. (The first real computer I used was a DECSYSTEM-10 running
TOPS-10, and I wrote table-driven programs and interpreters in MACRO-10,
too. Come to think of it, the MACRO system in MACRO-10 may also have had a
serious influence on my later programming style.) However, I doubt that
"first exposure" has that much power of people's perceptions, and _luck_
shouldn't play that big a part in people's life when the experiences are
communicable if only people would listen.
Put it another way, learning about Lisp, and then learning Lisp, was like
reading a novel with grand, heroic characters who solved big problems with
efficient, effective weapons, strategies, and skills. From many kinds of
art, I can see an image of how the world _could_ be and in a sense _should_
be that I can carry into a world filled with violence, pestilence, death,
manual labor, and taxes, and set a meta-goal for myself: realizing the best
kinds of of goals I should set for myself.
Still, I get seriosly annoyed when people complain for months on end about
some problem that I have been able to solve for myself, and others seem to
have solved for themselves. Maybe is there no market for these kinds of
programming tools, possibly because they are so personalized, but that does
most emphatically _not_ mean that the world is horrible place dominated by
Bill Gates, with him dictating people's every move.
#\Erik
--
those who do not know Lisp are doomed to reimplement it
From: Russell Ritchie
Subject: Re: Integrating Lisp with C++ (was "Lisp is alive")
Date:
Message-ID: <l3k9stoe1g.fsf@OASIS007.msc.ie>
············@wildcard.demon.co.uk (Cyber Surfer) writes:
> [I need] Full Win32 support. The C++ tools I have aren't even up to date.
> It doens't look like the Windows support in DEC's compiler has
> been updated for well over a year, and is Win16, not Win32.
DEC's Scheme->C supports win32 and win16, and has done for well over a year.
Perhaps the win32 patch file (NT-15mar93.patches, dated Mar 14 1995) could
have been better named, but Windoze 95 didn't actually exist back then. As
far as I'm aware the win32 API hasn't changed (at the level required by the
Scheme interpreter and library) in that time. There may have been changes to
the GUI API to support the Windoze 95 look and feel, but the basic system runs
as a console application. Anyway, that's what cdecl is for :-).
> I could in theory add Win32 support. In practice, who knows?
> If somebody else did, then they might have done it already.
It has been done--I did it prior to the Windows NT 3.51 release.
> However, if I ever get the time, I'll see what I can do with DEC's
> compiler. You never know, do you?
Well, since you asked so nicely... You can build the interpreter and the
shared dll on win32 using Visual C++ version 2.2. (I see no reason why 4.0
shouldn't work, I just haven't tried.) You can also build and use the
compiler although a trivial amount of work remains to allow the command line
arguments to be supplied if you need them (they currently still try to special
case on win16).
Wrap that MFC API with cdecl and a SOS framework, then write a meta-circular
GUI development environment to prove how easy-to-use it is and the world will
beat a path to your ftp server. Or not. Have fun.
In article <··············@OASIS007.msc.ie>
········@msc.ie "Russell Ritchie" writes:
> DEC's Scheme->C supports win32 and win16, and has done for well over a year.
> Perhaps the win32 patch file (NT-15mar93.patches, dated Mar 14 1995) could
> have been better named, but Windoze 95 didn't actually exist back then. As
> far as I'm aware the win32 API hasn't changed (at the level required by the
> Scheme interpreter and library) in that time. There may have been changes to
> the GUI API to support the Windoze 95 look and feel, but the basic system runs
> as a console application. Anyway, that's what cdecl is for :-).
I'm aware of this. I have the NT patch file, but I'm currently
unable to decode it. It's on my ToDo list, right after upgrading
the UU software I'm using.
As I've said before, this is just one of a number of options that
I'm looking at. Some look more promising than others, depending
on factors like the amount of work (i.e. time) required to get the
thing working. As I'm not looking specifically for a Scheme to C
compiler, but _any_ tool that'll help me.
Tools that have a simple install, work immediately, and have direct
support for the APIs I need, may well get my attention sooner than,
let's say, DEC's Scheme to C compiler. This is not a comment on the
quality of that tool, but a reflection of the demands made by the
need to meet deadlines etc.
> > I could in theory add Win32 support. In practice, who knows?
> > If somebody else did, then they might have done it already.
>
> It has been done--I did it prior to the Windows NT 3.51 release.
No doubt. Do you mean that it has support for the latest Win32 APIs?
It might be more than a little unfair to compare this Lisp compiler
with VC++ 4.2, with its IDE and various wizards, but that's what a
lot of Windows developers _will do_. Even if I had the time to get
DEC Scheme to C compiler working, which I hope to do RSN, I've no
idea if it can create a DLL. If it can't do this, then I'll have
to add it, which will take more time.
> > However, if I ever get the time, I'll see what I can do with DEC's
> > compiler. You never know, do you?
>
> Well, since you asked so nicely... You can build the interpreter and the
> shared dll on win32 using Visual C++ version 2.2. (I see no reason why 4.0
> shouldn't work, I just haven't tried.) You can also build and use the
> compiler although a trivial amount of work remains to allow the command line
> arguments to be supplied if you need them (they currently still try to special
> case on win16).
I don't have a copy of VC++ 2.2 - I don't even have VC++ 4.2. What
I have is 4.0, which is...missing a lot of features that I need,
and apparently full of bugs. I can confirm that VC++ 4.0 has trouble
compiling the interpreter, but I'm hoping that the problem is a
trivial one that'll not take long to find and fix. If I get it
working, I'll let you know.
> Wrap that MFC API with cdecl and a SOS framework, then write a meta-circular
> GUI development environment to prove how easy-to-use it is and the world will
> beat a path to your ftp server. Or not. Have fun.
Sure, if and when I get the time. I really doubt it, as I have more
than enough things to do already, and I get paid for them, giving
them a significantly higher priority. Compilers like DEC's will
always lose under these conditions. There may be a number of ways
in which to change the conditions, like quiting my job, or convincing
my boss that a Lisp to C compiler is more vital to our success as
a company than meeting the demands of clients. Wish me luck...
I can hardly complain about a free lunch, even if I'm prepared to
spend (my own) money on the tools that (I believe) I need, which
I am. I'm trying hard not to sound bitter, but I'm not sure it's
working. I just hate using C++ instead of Lisp. As others have
pointed out, I _do_ have a choice. I can insist on using Lisp
(but _who_ pays for it?), or quit my job. It's not a great choice,
but I'm saving my money anyway, as I'm sure I'll need it.
My current favourite (I'll know more when I get more info, which
should be any day) is Ilog Talk. It looks like it'll work _now_,
without needing much, if any, work. Since time is critical, and
it takes almost no time at all to spend 22K francs, this may well
be the one for me. When I have the money, that is. Meanwhile, I
can use my time profitably, meeting deadlines etc.
Anyway, thanks. I'm at least considering Lisp as an option for
work, rather than just using it in my own time, or ignoring it
completely, as many seem to be doing. So there's hope. ;)
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
Thomas, while I think your description of the problem is correct, I
have a few remarks.
1) MCL is a Common Lisp that is/has:
- Threads
- A price comarable to PC C++ environments
- A useable runtime licence policy (pay once, ship as many as you
want). I agree 100% that most other schemes are just inacceptable
and that just free runtime licenses would be important to make
a new language beeing accepted when comared to C++, Java etc.
The drawback is, of course, that it forces you to use/buy a Mac, which
is not the preferred Web server platform for most people. But maybe
the problem of getting some complicated application to run outwights
this.
2) There are a number of free Lisp implementations of a quality
comarable at least to perl.
3) perl has more disadvantages than just beeing unusable (for me) for
sources with more than 100 lines.
- No real debugger
- No GUI-based environment of the quality like commercial CL
implementations have.
- Only one implementation. Trigger a bug and you'll be in
problems. In CL, you'll have to change you FFI routines, but the
complex program part will remain unchanged.
- Cannot be compiled. For me and my customers, this is a
requirement for many projects. We need to be able to move a
project to Servers not under our control and the source should
not be accessable there.
3) Isn't the FFI of perl very complicated and poorly documented, at
least compared to that of most Lisp systems? Or do you mean you don't
need an FFI in perl, since it has most Unix stuff build in (would be
reasonable)?
4) Is there a cheap Smalltalk system? It is some time since I looked
into Smalltalk prices, but they were at least 3 times as high as
Borland/Visual C++. Really, let me know.
5) I don't think there actually is a book on perl for Web usage that
covers more than the basics and a few gimmics. You are right that
there is no Lisp book that covers what you describe here, but I
don't think the availiable perl books are right to become a real
hacker for dynamic, advanced Web applications.
6) There is at least one Scheme implementation specialized in beeing
used in a Web environment. I forgot the name (SIOD?), but if I
remember right, it covers most of what you want. It is probably slow,
but it will include a tutorial and exaples, I assume. Combined with
some Scheme-specific gimmics, that might look good.
7) Other things to look at: CL-httpd and scsh. Cl-httpd implements
some nice ideas a Web-programmer should be interested in, whatever
language he/she uses.
So, what do *I* use for my Web work? I use C, just for performance and
beeing portable across systems and implementations. What I miss most
is some OOP support and threads. Java provides these, beeing at least
portable where the JDK is availiable. Currently, I'm taking a deep
look into Java.
BUT,
my current language choice is influenced by some circumstances that
may change:
- Currently, my applications are not very complex.
- Currently, it is more important to be fast and reliable that to be
complex.
- I have no real competitor for the application area I'm currently in,
at least none that can take more project and will try to take them
over from me.
Currently, the customers for Web applications mostly try to "be in the
game", they need reliable, working projects that show their presence
in the market. Beeing more useful than desktop applications is mostly
not an issue. It it was, it couldn't be implemented now, because the
Web hype lead all people beeing capable of writing Web applications to
implement trivial things.
I expect the situation to change. Somewhere in the future, I will face
competitors who will provide application usefulness that I can't
provide with my current tools.
Then, the complexity of applications on the Web will be what desktop
applications are today, but with some differences, when it comes to
tools coice:
- I can choose whatever platform I want for my server and therefore as
platform for the programs I write.
- Since the Java hype, people are much more likely to accept a
developer's language choice. Ever today, I see a lot of applications
coming up developend in Modula-3, Scheme, python etc. in areas where
everything else than C (not even C++) would have had a chance
before.
- Much of the machine load is on machines I'll have to provide. When I
use a solution that takes up more resources, I can choose whether to
buy a bigger machines or reimplement whatever is the problem. I will
no longer have to program for the usual client machine.
What will I do when I have to write the most flexible solution for a
given problem?
- I'll seriously think over buying a Macintosh just to run MCL and
another one to put outside my firewall. Well, even more I hope that
MCL will be ported to some other platform or that a comparable Lisp
for some other platform I like more shows up.
- I'll see whether some Scheme implementation is mature and offers the
Web features I want. There's a good chance, couting the FSF Guile
effort, Utexas' Rscheme and Olin Shivers work on scsh. That migh
include to work such feature for an implementation I happen to
like.
- I will certainly see what Harlequin's Dylanworks provides.
- Java is not bad, really. Especially, it might be the right choice if
I will not longer be an individual that buys some amoung of
additional programmer's time. I find it quite easy to look over Java
modules to see whether to trust them. C is out of question when it
comes to review other's code, and for Lisp I might find not enough
people.
- I will - maybe - use some distributed OOP system like Xerox Parc's
ILU and choose language on a per-module basis, not
per-project. Then, I use Lisp for whatever module it needs it and
let others use it from other languages.
I think choosing a language for Web projects in an environment with
competition will not depend on the positive sides of each language,
but on the negative sides.
A quote of Thomas article follows. No more comments from me below.
···@intentionally.blank-see.headers writes:
>In article <················@naggum.no> Erik Naggum <····@naggum.no> writes:
> | They'll need a good reason to install and play with a Lisp.
> that good reason is called "curiosity".
>Well, whenever I get involved in a new project, I give Lisp serious
>consideration. My group is looking into building a bunch of dynamic
>Web services, so I just went through evaluating all of this again.
>People are willing to learn a new language, and they have a lot of
>choices. Java, Perl, Python, Tcl, C++, etc. They realize quickly
>that something dynamic would be nice. The language needs to be fairly
>standard so that co-workers can pick up a book and learn about it.
>This also requires multithreading and database integration (hence an
>FFI). It needs to run under UNIX and NT (since those are the
>platforms we deliver on). We may also want a standard GUI toolkit.
>The only Lisp implementations that satisfy those constraints to my
>knowledge are Harlequin and Allegro. They are both excellent
>products. However to the tune of >$4000 (yes, that's right, that's
>how much those licenses cost for people outside academia), you can
>hardly just buy them "out of curiosity". Now that the 80's are over,
>management actually wants some kind of concrete justification for
>this. With non-trivial runtime licenses, there are serious concerns
>about whether we could ever use them in any product (mainly because of
>the legal and managerial hassles involved, not even so much because of
>the cost). Long term product maintenance is also an issue (who in
>development/support is going to pick up maintenance of CL software)?
>And few of my coworkers are willing to invest much time learning a new
>language on the 30-60 day evaluation license you get with those
>implementations. (Allegro's FreeLisp is a nice idea, but only runs on
>Windows.)
>The alternative is all too persuasive to people who weren't brought up
>on Lisp: go out, buy a few books on "Learning Perl in 48 Hours" and
>"Writing Dynamic Web Applications in Perl (CD with Perl and sample for
>Windows and major UNIX platforms included)", type "perl" at the
>prompt, and go. No licensing hassles, no need for multithreading
>(small footprint), shallow learning curves (doing small things is easy
>in Perl--you only recognize the mess you got yourself into later),
>source level debugging, and complete cross platform availability.
>Despite all the bad things that can be said about Perl, it actually is
>a highly dynamic and expressive language (of course, it's also slow,
>not robust, and idiosyncratic), so people actually do get the same
>feeling of power they get with Lisp.
>I have found it difficult to argue or work against that. I also find
>it difficult to put in an order for, say, $30000 in software licenses
>for something that neither is hyped up much these days nor for which I
>can make a reasonable business justification, in particular when systems
>that are hyped up much more (Java, Smalltalk, etc.) are either essentially
>free or a fraction of the cost.
>If I got my facts wrong and you know of a cheap, multithreaded
>CommonLisp and books like "Learning CommonLisp in 21 Days",
>"Practical String Processing in CommonLisp", and "Writing Web
>Applications in CommonLisp", do let me know (the last one may
>actually be in the works I hear).
>Thomas.
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@wavehh.hanse.de> http://www.bik-gmbh.de/~cracauer
"As far as I'm concerned, if something is so complicated that you can't ex-"
"plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin
From: Patrick Logan
Subject: Re: "report from the front": can we choose Lisp?
Date:
Message-ID: <325075CB.225@ccm.hf.intel.com>
Martin Cracauer wrote:
> 4) Is there a cheap Smalltalk system? It is some time since I looked
> into Smalltalk prices, but they were at least 3 times as high as
> Borland/Visual C++. Really, let me know.
There are a couple of new vendors with beta Smalltalk systems on the
Web. And ParcPlace-Digitalk now has an older version of their Smalltalk/V
for Windows *free* including the WindowBuilder GUI builder and TCP
support.
Search for "Smalltalk MT", "Dolphin Smalltalk", and "Smalltalk Express".
--
······················@ccm.hf.intel.com
Strange women, laying in ponds, distributing swords
is no basis for a system of government.
-Monty Python and the Holy Grail
From: Mike Haertel
Subject: Re: Lisp is alive, was "Re: Common LISP: The Next Generation"
Date:
Message-ID: <51s041$hmj@news.jf.intel.com>
In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
>one part of the reason why I like Lisp is that I and the compiler can use
>the same functions to read and write the source code, not only in macros,
>but in codewalkers and automated editing tasks. `read'ing Java or any of
>the C-family languages is dreadfully painful. writing out what you have
>read in is somewhat easier, but not much.
Of course, when using lisp "read" you lose comments and other formatting.
So it's suitable, perhaps, for writing source-code munging tools which
are expected to produce results for machine consumption only.
But if you want to write a source-code formatter like "indent", or a pretty
printer, it's just about as difficult in Lisp as any other language, because
of the non-syntactic stuff you have to deal with.
From: Erik Naggum
Subject: Re: Lisp is alive, was "Re: Common LISP: The Next Generation"
Date:
Message-ID: <3052160011407240@naggum.no>
[Mike Haertel]
| Of course, when using lisp "read" you lose comments and other
| formatting.
a reader-macro bound to #\; may gobble up the the rest of the line and
return it as a list (|;| "rest of line"). similarly for #|...|#. the
formatting would be lost, but if it was generated by machine, it can be
regenerated without loss, which is my second point...
| So it's suitable, perhaps, for writing source-code munging tools which
| are expected to produce results for machine consumption only.
there is very little variation in formatting styles for Lisp compared to
other languages. when there is variation, the pretty-printer can be
customized by the same programmer that wrote the source code. I don't
think a Lisp programmer would indent by hand, and even those that don't
follow customary formatting styles modify the pretty-printer to suit their
needs. in effect, the code that they write is already indented by machine.
| But if you want to write a source-code formatter like "indent", or a
| pretty printer, it's just about as difficult in Lisp as any other
| language, because of the non-syntactic stuff you have to deal with.
you really should take a look at GNU Emacs' lisp-mode and cc-mode. you
betray ignorance of existing systems that implement "indent" for numerous
languages and their relative sizes and complexity. cc-mode is at least an
order of magnitude more complex than lisp-mode, including the support
mechanisms.
#\Erik
--
those who do not know Lisp are doomed to reimplement it
From: Cyber Surfer
Subject: Re: Lisp is alive, was "Re: Common LISP: The Next Generation"
Date:
Message-ID: <843065668snz@wildcard.demon.co.uk>
In article <················@news.primenet.com>
······@primenet.com "Glenn Ehrlich" writes:
> I would like to think that this is the "master plan" for Java, as envisoned by
> Gosling and Steele. They both have a lot of Lisp background, you know.
That thought has occured to me, too. ;-)
> Maybe they thought that the only way to introduce Lisp is to disquise it
> underneath the facade of the Web, C++, and visual environments.
That might also be the plan with Dylan, but we'll have to wait
and see. Java is happening right now.
> If someday Java has closures, hygienic macros, and all of the other Lisp-family
> goodies, does it really matter if it doesn't have parenthesis? Isn't the
> semantics more important the syntax?
>
> I think one of the really valuable lessons that Dylan has shown is that you can
> have a successful infix syntax *and* have all of the Lisp goodies.
Certainly! That's the reason why I'm more positive about Dylan
than some others. With Java, we have another advantage. Once the
JVM is in place on every desktop, we can piggyback other languages,
like Scheme. This is already happening. Now, if a few Lisps systems
like MIT Scheme, could use a front end using the JVM, we could
"standardise" the user interface. MIT Scheme could look the same
on every platform it runs on, coz the enviroment's GUI uses a
widget server written in Java (or Scheme code compiled for the JVM).
What has syntax got to do with it?
> I'm hoping that Java does expand in this way.
I'm hoping that existing software can exploit it, too.
> What would you rather use: Java or Visual Basic?
Java! Everytime. VB makes me feel sick, but the enviroment is ok.
Delphi demonstrates that this kind of thing is not unique to VB.
We know that, but it needs to be _demonstrated_.
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind